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.
blair@obdient.UUCP (Doug Blair) (02/22/88)
Dominic: I sent this to you via email, but afterwords I realized that I'd written a small book! :-) Perhaps this information will be helpful to other new installations on the net, so I'm posting it as well. I don't claim that all this is 100% applicable to your situation butr it should get you started. > Wanted: information concerning security of usenet and uucp connections. One of the best discussions around on this is found in the book: Unix Communications by The Waite Group. It's a Howard Sams book for about $20.00. Same price range is Unix System Administration by David Fielder and Bruce Hunter. Both should be in any major chain- type bookstore (B. Dalton, Walden Books, etc) that has a computer book depoartment. We faced many of these problems in setting up our unix and after digesting these books felt we had a good grasp of the problems. > Questions: 1) What access (if any) do outsiders have to local system > (ie. can they request files on system such as > /etc/password) Outside users can only do what you allow them to do. To restrict individual's access you must change the permissions on sensitive files or perhaps make them login in a restricted shell like rsh. Outside systems can only execute a few selected commands (which are stored in /usr/lib/uucp/Permissions under HDB on our system). I think the corresponding file is L.cmds in non-HDB systems. Usually these are limited to rnews, rmail and lp. HDB allows you to specify which systems can execute which other commands you want to allow, if any. Under normal conditions outside systems, even those that login with a "generic id" like nuucp, can only request or send files to the /usr/spool/uucppublic directories. Those files must first be put there by a command on your local system like uuto, so unless one of your users puts the passwd file there intentionally it's pretty solid. > 2) How secure is uucp security - ie USERFILE and L.cmds > Can anyone get around them from a remote system? It's important to realize the difference between a remote system and a remote user - someone logged in from an outside site. If one of your normal users loses their passwords then a nasty human can log in and do all the things the regular user can do. The best way to fight this kind of loss seems to be in enforce password aging and make LOTS of REGULAR backup files. Such a bad guy appears the same wether logged in via terminal or via cu or tip from another computer. The only normal linkage between your computer system and another is one that you set up youself - usually uucp. We are interconnected with only three other sites for unattended operation of our system. None of these has given the others permission to request any kind of job on our system other than rnews and rmail, so even if a user on one of those systems examines their phone number and password files to determine how their machine logs into ours, the only thing they could do is send us news or mail. Once the machine login has been used the tty comes up in a different shell: uucico instead of sh, csh or ksh. uucico's activities are limited to the commands in the Permissions file and the publlic directories. > 3) Can "intruders" be traced? Do facilities exist to monitor > bad attempts of logging into a Unix system? I've forgotten (OK, deleted the line) if you're a ucb site. The lastlog file will give you an idea of how often a login is being used (a non- machine login at 2am is unusual, right?). You can run a short script from cron to see who's logged in and what they're doing every 5-10 minutes, sort and grep this to find something unusual, but even the most sophisticated systems can't do anything more than determine which login is being used for unauthorized activity - you still have no way of finding out who is using the terminal associated with the login. Yes, you can monitor bad login attempts. The standard login program does not, but there is a public domain modified version of login that I've seen posted to the net for use on public access unix systems such as chinet. This program writes all of the data associated with any login not successful on the first attempt to a logfile which you can later review. Any attempt to login unsuccessfully several times in succession using the same user id can be trapped and a "Sorry" message sent to the terminal (this by way of apologising to the person who has forgotten their password). I know the source is on chinet and can sent it to you.... > 4) How secure is the software which implements the exclusions > mentioned above (as well as others related)? You'll have to look at the sourcecode and judge for yourself. > 5) How can we audit these events? See above > 6) Is there a methodology for auditing local users activity to > remote sites - especially over usenet? usenet is a collection of programs which does nothing more than transfer news articles around the net - this via uucp. So the uucp monitoring facilities will indicate how much traffic is going on. The uulog program dumps a log of the systems called, size of files sent, owners of these files, times sent and so forth, but doesn't normally show the type of content of those files. This can be used to estimate wether files are news articles (because the owner would be the owner of postnews, usually news or usenet), mailed replys to articles (owned by individual users) or machine to machine transfers (owned by the machine's login). The uulog file will also show attempts to execute programs from remote sites (with messages like "/usr/bin/cu attempted - access to remote file system denied"). It is important to remember that your machine is only connected to neighboring machines - so any command it gets only works if you've said it can do so in your Permissions file. uulog will document all such attempts. > 7) What facilities/manuals should be examined to ensure security? Virtually ALL of a normal (ie: non-defense-department-super-secret) unix installation's security problems can be resolved by addressing PHYSICAL security: don't let anyone see your password, never leave a terminal while logged in, lock the door to your office on your lunch hour, never write your passowrd in your wallet, change passwords frequently, etc etc. The next issue (after access to terminals and logins) is restricting access to sensitive data - payrolls, acedemic records, manuscripts, engineering data, etc. I think the user-group-world permissions do a fair job of this for most small/medium business installations and most academic situations. There are lots of books on system security which tell you of the obvious loopholes (like getting an unrestricted shell via the ! shell escape in vi) which you should read but I think the most overlooked loophole is the number of people to whom you give permission to become superuser for a quick "just this one time because I'm not at my terminal" kind of job. I was amazed at the number of times I did this in my first two months. TGhe tasks accomplished by superuser and root logins are special enough to only be done by one or two people. That's WHY unix systems have system administrators. There you have it - some secure thoughts from a budding unix administrator! Hope this helps.... Doug Blair --- -- =============================================================================== | Doug Blair ... ihnp4!laidbak!obdient!blair | | "I'm not a Consultant, but I play one on TV." | | Obedient Software Corporation, 1007 Naperville Road, Wheaton, IL 60187 | ===============================================================================
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)