Path: utzoo!utgpu!water!watmath!clyde!att-cb!ihnp4!laidbak!obdient!blair From: blair@obdient.UUCP (Doug Blair) Newsgroups: comp.unix.questions Subject: Re: Usenet Security Summary: intro uucp security Keywords: usenet uucp security access intruders Message-ID: <375@obdient.UUCP> Date: 21 Feb 88 17:23:11 GMT References: <108@tron.UUCP> Organization: Obedient Software Corp, Wheaton, IL Lines: 159 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 | ===============================================================================