celozzi@tron.UUCP (Dominic J Celozzi) (02/18/88)
Wanted: information concerning security of usenet and uucp connections. In particular, consider the following scenario: VAX running Ultrix 2.0 dial-out uucp connections only polls newsfeed once daily Questions: 1) What access (if any) do outsiders have to local system (ie. can they request files on system such as /etc/password) 2) How secure is uucp security - ie USERFILE and L.cmds Can anyone get around them from a remote system? 3) Can "intruders" be traced? Do facilities exist to monitor bad attempts of logging into a Unix system? 4) How secure is the software which implements the exclusions mentioned above (as well as others related)? 5) How can we audit these events? 6) Is there a methodology for auditing local users activity to remote sites - especially over usenet? 7) What facilities/manuals should be examined to ensure security? Please do not begin a discussion concerning the theoretical history of unix vs. "secure" systems. I am only interested in practical applications / practices which will aid in the monitoring of outgoing/incoming activities, as well as those which raise might raise concern to the security guys. Thank you for your cooperation, Dominic J Celozzi UUCP-Path: uunet!umbc3!tron!celozzi
mikel@codas.att.com (Mikel Manitius) (02/21/88)
In article <108@tron.UUCP>, celozzi@tron.UUCP (Dominic J Celozzi) writes: > > Wanted: information concerning security of usenet and uucp connections. Very simple, if you've got a UNIX machine with a modem, it's not secure. -- Mikel Manitius mikel@codas.att.com
daveb@geac.UUCP (David Collier-Brown) (02/21/88)
In article <108@tron.UUCP>, celozzi@tron.UUCP (Dominic J Celozzi) writes: >> Wanted: information concerning security of usenet and uucp connections. In article <2739@codas.att.com> mikel@codas.att.com (Mikel Manitius) writes: >Very simple, if you've got a UNIX machine with a modem, it's not secure. To be a bit more specific (:-)), if you have a normal unix system providing mail which takes the site!site!name notation, you are subject to having the forwarding mechanism ship all sorts of "interesting" things through, and if your normal uucp "security" has been reduced below the default for reasons of usability, you can find yourself executing a virus.. A C-secure unix is no help here: you need a B- or C-secure machine, and a secure communications processor (the A-secure gutted Unix of yore). Uucp is formally insecure. --dave ps: the letters refer to a US security standard. B means your are resistant to penetration and have a second, separate set of non-overridable file permissions (as a minimum). C is less so, and D means "you flunked". -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
kurt@hi.unm.edu (Kurt Zeilenga) (02/22/88)
In article <2739@codas.att.com> mikel@codas.att.com (Mikel Manitius) writes: >In article <108@tron.UUCP>, celozzi@tron.UUCP (Dominic J Celozzi) writes: >> >> Wanted: information concerning security of usenet and uucp connections. > >Very simple, if you've got a UNIX machine with a modem, it's not secure. It's simplier than that. If you got a UNIX machine and it's turned on, it's not secure. :*D >-- > Mikel Manitius > mikel@codas.att.com -- Kurt (zeilenga@hc.dspo.gov)
bzs@bu-cs.BU.EDU (Barry Shein) (02/22/88)
>>Very simple, if you've got a UNIX machine with a modem, it's not secure. >It's simplier than that. If you got a UNIX machine and it's turned >on, it's not secure. :*D That's worse, to boot it single-user you usually turn it off first, -B
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/22/88)
In article <23504@hi.unm.edu> kurt@hi.unm.edu (Kurt Zeilenga) writes: >In article <2739@codas.att.com> mikel@codas.att.com (Mikel Manitius) writes: >>Very simple, if you've got a UNIX machine with a modem, it's not secure. >It's simplier than that. If you got a UNIX machine and it's turned >on, it's not secure. :*D Come on; security comes in differing degrees. It is thought that UNIX can be brought up to DOD B-2 level with some amount of effort, and still look enough like UNIX to support most UNIX-based applications. There are already at least two UNIX implementations approved at level C-1 or higher (so I'm told; I don't have one). One way to not lose an appreciable degree of security due to modem access (assuming telephone line tapping is ruled out) is to have the system check an incoming user ID against an internal list and call back the phone number contained in the internal list to establish the real working connection. The weakest link in many installations is physical security -- for example, on an Ethernet with lots of Sun workstations, unless the cable and workstations have controlled access it is possible for a workstation to be subverted and super-user access to the whole local net to be obtained (assuming typical installation; at least SOME unauthorized access would be obtainable in general). Our favorite method of achieving acceptable security is to keep our systems in controlled-access vaults. Of course they can't have normal network connections to areas outside the vaults. This solves most security problems very simply (but not simultaneous multi-level compartmentalized access control). If you're really concerned with computer security, get in touch with the National Computer Security Center; they specialize in this.
flaps@csri.toronto.edu (Alan J Rosenthal) (02/23/88)
In article <7311@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes: >One way to not lose an appreciable degree of security due to modem >access (assuming telephone line tapping is ruled out) is to have >the system check an incoming user ID against an internal list and >call back the phone number contained in the internal list to >establish the real working connection. Doesn't this just put the shoe on the other foot? If you call the other system back, you have to prove that it's you calling back. In other words, I'm saying that it seems to me that this could work only between a secure system and a not-so-secure system. Two systems cannot both use this strategy to talk to each other. ajr -- If you had eternal life, would you be able to say all the integers?
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/24/88)
In article <1988Feb22.175256.12780@jarvis.csri.toronto.edu> flaps@csri.toronto.edu (Alan J Rosenthal) writes: >In article <7311@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes: >>call back the phone number contained in the internal list to >>establish the real working connection. >Doesn't this just put the shoe on the other foot? If you call the >other system back, you have to prove that it's you calling back. I was assuming that we were just concerned about dial-in penetration of a system, from that (single) system administrator's point of view. Genuine mutual authentication of identities is a difficult matter. There have been several studies and proposals for this during the last 10 years or so, usually based on use of "one-way" encryption functions. There are operational problems, such as getting the initial identity registration validated..
trb@ima.ISC.COM (Andrew Tannenbaum) (02/25/88)
I'll address dial-in security and uucp security here.
I don't quite know what usenet security problem is in question.
It's wise to buy a cheap UNIX box and make it your uucp/mail/news
gateway. Don't put any vital info on the machine, and you'll have
nothing to lose. If you are concerned about security, the minimal
expense will we well invested. Connect the gateway to your work
machines with ethernet, and remove any dangerous programs (like rlogin,
for instance) from the gateway machine. If you're serious about
security, you don't put phones on your machine. With the cost of
hardware and the cost of security these days, it's silly to put
uucp lines on a machine that you are worried about.
uucp systems other than BNU (aka honey danber, or the latest AT&T
uucp) use USERFILE, which, while it may be used to restrict access
to remote users, is hard to customize on a per system/per user basis.
The code and documentation is arcane, and has been rewritten many times
by many people in an attempt to get it to work.
You longtime uucp users might say "it works for me..." I suggest that
you spend some time fiddling with the USERFILE setting up different
sites and users at different levels of security, and read the chkpth()
code, and see how goofy it is. It might work in 4.3bsd, but in
general, USERFILE processing is buggy, and most sites simply put
, /
or
, /usr/spool/uucp
in there. Actually, I think ", /" doesn't work in most older uucp's, you
have to put the line in twice because of weird parsing problems with null
USERFILE descriptors.
The BNU Permissions file takes some getting used to. It's more verbose,
more flexible, and cleaner. The Permissions file has been one of the major
selling points for BNU uucp. I have never had a problem bringing up
BNU under new UNIX system, AT&T or BSD based.
If you don't have dial-ins, you don't have intruders logging in over
them. Assuming you want uucp dial-ins, there is a way to make them
quite secure. (I learned this method from Brian Redman - ber of honey
danber fame.) Hack up a copy of login that only allows uucp's to log
in, and only forks uucico. You could post your /etc/passwd to usenet,
and no one would be able to log in over those uucp-only lines. It
would be wise to keep your user dial-in phone numbers secret ("security
through obscurity," as I've heard Karl Heuer, the Walking Lint, call
it). Segregating your user dial-ins from your uucp dial-ins only
involves the base cost of phone lines, it isn't changing the i/o load
any.
It's a good idea to give your uucp dial-in users separate /etc/passwd
entries. This makes it easier to monitor per-user access, both using
the uucp log files and the "last" command to peruse the wtmp records.
If you want to monitor use of uucp or netnews posting, you can use the
log files provided by these systems, or if you find them unsatisfactory,
you can easily write front-end shell scripts to provide your own
logging.
Andrew Tannenbaum Interactive Boston, MA +1 617 247 1155blarson@skat.usc.edu (Bob Larson) (02/25/88)
In article <1988Feb22.175256.12780@jarvis.csri.toronto.edu> flaps@csri.toronto.edu (Alan J Rosenthal) writes: >In article <7311@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes: >>One way to not lose an appreciable degree of security due to modem >>access (assuming telephone line tapping is ruled out) is to have >>the system check an incoming user ID against an internal list and >>call back the phone number contained in the internal list to >>establish the real working connection. >Doesn't this just put the shoe on the other foot? If you call the >other system back, you have to prove that it's you calling back. This is easy to solve, include a temporary password with the first call. The called back system will then know that the system calling it knows a random password it just generated and sent to one other system. (There should be an exparation time on the password, related to the maximum time the call back will take.) System A calls System B to and says "Hi, I'm system A, use Password xxxyyyz and call me back." System B then calls system A and says "I'm system B, someone told me to call and use password xxxyyyz." A possible improvement would be to not have system A hang up and not tell it's password until the other system has called back. This is NOT secure from phone taps. -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%fns1@ecla.usc.edu oberon!fns1!info-prime-request
csg@pyramid.pyramid.com (Carl S. Gutekunst) (02/25/88)
Bravo, Andy! Concise, complete, and correct. Just some comments: In article <893@ima.ISC.COM> trb@ima.UUCP (Andrew Tannenbaum) writes: >Actually, I think ", /" doesn't work in most older uucp's, you have to put >the line in twice because of weird parsing problems with null USERFILE >descriptors. Correct. That problem was finally fixed in Tom Truscott's late 4.2BSD version, and is still present in many BSD-based systems, including Sun. For more info, see the 4.3BSD USERFILE(5) man page. >The Permissions file has been one of the major selling points for BNU uucp. The security features of BNU/HDB are *THE* selling point, in my opinion. The 4.3BSD UUCP is nearly the equal of HDB in many repects, and the newest version will be superior in many. But when it comes to security, HDB reigns surpreme and will for the forseeable future. Any site that plans to use UUCP and wants to be secure should be running HDB. <csg>
wolfgang@mgm.mit.edu (Wolfgang Rupprecht) (02/25/88)
In article <7311@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes: >One way to not lose an appreciable degree of security due to modem >access (assuming telephone line tapping is ruled out) is to have >the system check an incoming user ID against an internal list and >call back the phone number contained in the internal list to >establish the real working connection. Call-back is a great hack. Unfortunately it only works if the Unix system can insure that the phone connection is truly broken when Unix hangs up the modem. Some phone exchanges seem to have bugs that allow the call originator to keep the connetion open, even if the call recipient hangs up. The call-back scheme would fail miserably if the dial-back modem merrily dialed away on a phone line that still had the initial call-in connection active. The call-in hacker could even send a phoney dial tone down the line, if he wanted to embellish the charade a bit. --- Wolfgang Rupprecht ARPA: wolfgang@mgm.mit.edu (IP 18.82.0.114) 326 Commonwealth Ave. UUCP: mit-eddie!mgm.mit.edu!wolfgang Boston, Ma. 02115 TEL: (617) 267-4365
tsl@netsys.UUCP (Tom Livingston) (02/26/88)
In article <3206@bloom-beacon.MIT.EDU> wolfgang@mgm.mit.edu (Wolfgang Rupprecht) writes: >Call-back is a great hack. Unfortunately it only works if the Unix >system can insure that the phone connection is truly broken when Unix >hangs up the modem. Some phone exchanges seem to have bugs that allow >the call originator to keep the connetion open, even if the call >recipient hangs up. The call-back scheme would fail miserably if the >dial-back modem merrily dialed away on a phone line that still had the >initial call-in connection active. The call-in hacker could even send >a phoney dial tone down the line, if he wanted to embellish the >charade a bit. Callback security is something that is rather easy (for the amount of security) but can't be ignored either... Many (dare I say most?) phone systems will give you an appreciable amount of time to stay on the line after one party has hung up, but the call stays connected (this is for some good reasons, but also happens as an accident). A good way is to either use another line for outdials or keep the phone on hook for a good long time (60 seconds would be enough). Problems and good points of the various types are: Standard callback (one line, small wait time) -- Very easy to keep the line open and connected. Dial tones can indeed be faked by a cheap recorder, 3 line or conference calling, or even whistling (yes, really!). But, it does give a good amount of security, and often gives you enough so that the 'random' intruder will go on to easier targets. Timed callback (one line, appreciable wait time) -- Very good security, but an intruder still can drop the connection, call back, and let it ring until it is picked up and starts to dial out. This can be enhanced several ways. Two line callback -- Very good security, an intruder would have to scan for the outdial line, happen to get it _when_ it was outdialing, but then the intruder would not have to know a vaild 'ID' code... just wait on the line until it was used for an outdial. Note -- Realistically, to my knowledge, there is no good way to find an outdial without being inside the company, or X-REFing the in-dial with all other lines owned, and then determing which the outdial was. Not an easy task, and it would not generally be attempted. >Wolfgang Rupprecht (wolfgang@mgm.mit.edu) _____________ / --/ __ _______ (_/ (_) / / / <_ Livingston { decuac,ihnp4 }!netsys!tsl
rob@philabs.Philips.Com (Rob Robertson) (02/27/88)
In article <15477@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >The security features of BNU/HDB are *THE* selling point, in my opinion. The >4.3BSD UUCP is nearly the equal of HDB in many repects, and the newest version >will be superior in many. But when it comes to security, HDB reigns surpreme >and will for the forseeable future. Any site that plans to use UUCP and wants >to be secure should be running HDB. older versions of HDB have a hole whereby clever hackers CAN manage to get a shell. honest rob -- william robertson rob@philabs.philips.com
arthure@sco.COM (Arthur Evans) (03/02/88)
In article <5875@netsys.UUCP> tsl@netsys.UUCP (Tom Livingston) writes:
) Two line callback -- Very good security, an intruder would have to scan
)for the outdial line, happen to get it _when_ it was outdialing, but then
)the intruder would not have to know a vaild 'ID' code... just wait on the
)line until it was used for an outdial. Note -- Realistically, to my
)knowledge, there is no good way to find an outdial without being inside
)the company, or X-REFing the in-dial with all other lines owned, and then
)determing which the outdial was. Not an easy task, and it would not
)generally be attempted.
Also, note that with the computerized phone systems that
many companies use, it may be possible to prevent a given
line from being used as a dial-in at all, preventing the
sort of attack you describe.
arthur
--
This is me. Who are you?jpp@slxsys.specialix.co.uk (John Pettitt) (03/02/88)
From article <3206@bloom-beacon.MIT.EDU>, by wolfgang@mgm.mit.edu (Wolfgang Rupprecht): > Call-back is a great hack. Unfortunately it only works if the Unix > system can insure that the phone connection is truly broken when Unix > hangs up the modem. Some phone exchanges seem to have bugs that allow > the call originator to keep the connetion open, even if the call > recipient hangs up. The call-back scheme would fail miserably if the > dial-back modem merrily dialed away on a phone line that still had the > initial call-in connection active. The call-in hacker could even send > a phoney dial tone down the line, if he wanted to embellish the > charade a bit. The simple answer to the 'phoney dial tone' trick is to use another line for the dial back - preferably one that has been set at the exchange to not accept incomming calls (we can, I'm told get this in the uk). The more outgoing lines available the better as this lowers the odds on interception. Several uucp implementations are far from secure. Apart from getting HDB uucp one approach used is to put a Xenix/Unix based PC system in as a comms system (volume permitting) and to then implement an internal 'wire' link to the rest of the systems, with the other systems calling the server system which must contain no valuable information. This will defeat at lest one well known bug in some versions of uucp. (No I am not going to say what versions, or what the bug is) It must be said that most security problems are of the 'door left unlocked' type and not clever hacks. All the security software in the world won't help if it's not used correctly! John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, England, KT7 0TR {backbone}!mcvax!ukc!pyrltd!slxsys!jpp jpp@slxsys.specialix.co.uk Tel: +44-1-398-9422 Fax: +44-1-398-7122 Telex: 918110 SPECIX G >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< -- John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, England, KT7 0TR {backbone}!mcvax!ukc!pyrltd!slxsys!jpp jpp@slxsys.specialix.co.uk Tel: +44-1-398-9422 Fax: +44-1-398-7122 Telex: 918110 SPECIX G >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
jc@minya.UUCP (John Chambers) (03/05/88)
In article <3206@bloom-beacon.MIT.EDU>, wolfgang@mgm.mit.edu (Wolfgang Rupprecht) writes: > > Call-back is a great hack. Unfortunately it only works if the Unix > system can insure that the phone connection is truly broken when Unix > hangs up the modem. Some phone exchanges seem to have bugs that allow > the call originator to keep the connetion open, even if the call > recipient hangs up. Uh, this isn't always a bug. I've worked in places that got sufficiently many threatening phone calls that they got the phone company to arrange for call termination only when the local end hung up. That way, if you got a weird call, you could leave the phone off the hook, and ask one of the secretaries (via another phone line, usually) to trace the call. One place even had sets on the secretaries' desks that would show the number of the calling party. It was then easy enough to call the phone company and ask for the physical location of that number, then call the police... Of course, if you have this kind of service, then you can subvert the call-back scheme exactly as Wolfgang describes. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)