skip to primary navigationskip to content

So you want to run a secure Unix system, do you?

Author: Bob Dowling and Ben Harris
$Date: 2004/12/13 15:26:20 $
Leaflet: U16

This document is just to get you started; it is not exhaustive. The Computing Service offers the advice in this document only as a guide to the sort of problems of which a Unix System Administrator should be aware and accepts no responsibility for any problems which may arise from its application to particular systems outside the control of the Service.

You should assume that every Unix box is shipped insecure.

Following all the advice in this document will not make your system "absolutely secure" (there's no such animal) but will make it more secure than most. Think of it like the neighbourhood watch; it doesn't reduce crime, it just makes it go elsewhere where there are easier pickings.

You are the system administrator of a Unix box connected to the Internet. Possibly you are going to be the only user. If so, resist the temptation to run as root all the time; set yourself up a non-privileged account.

You have a responsibility to your users to keep your system secure. If it succumbs to enemy action, all your users' work is put at risk.

You also have a responsibility to all the other users of the Internet. If your system falls, it can be used as the launch pad for a host of other attacks. If root is compromised on your system every other system on your local network is almost certainly compromised immediately. If you are lax in your security and as a result the rest of your department loses its machines you are not going to be popular!

Spend at least a fortnight getting familiar with your system. Understand what the files and commands really do. This will take a huge chunk out of your research time, but that's too bad; it's the price you have to pay for the convenience of a system on the Internet.

You need to be familiar with your particular machine to know how to fix the problems described later on. The problems are generic; the fixes are machine-specific.

Expect to spend two to three hours every week looking after your machine.

Read some books on Unix system administration and security:

  • Essential System Administration written by Æleen Frisch, and published by O'Reilly & Associates. ISBN: 0-937175-80-3.
  • The manual pages on your own particular system.
  • Practical Unix Security written by Simson Garfinkel and Gene Spafford, and published by O'Reilly & Associates. ISBN: 0-937175-72-2.
  • The Cuckoo's Egg written by Clifford Stoll, and published by The Bodley Head. ISBN: 0-370-31433-6. Do try the Chocolate Chip Cookie recipe.

Take backups!

  • Make sure you know how to take full system backups.
  • Are any of your system partitions larger than your tapes? If so, make sure you know how to take multi-volume backups.
  • Make sure you know how to take incremental backups as well.
  • Plan a regular schedule for backups.
  • Make sure you know how to do a restore that includes the main dump and subsequent incremental dumps. (Using multi-volume backups if necessary.)
  • Practice!
  • Keep your backups away from the machine.
  • Have more than one set of backup tapes so that you are never in the situation where your only backup is on the tape in the machine it is a backup of.

Common blunders

  • Do you have any accounts without passwords? Look in /etc/passwd and any shadow password file your system might have.
  • Do you have any user accounts with the same numeric user ids?
  • Are your NFS exports correct? The default behaviour is often to export read-write to the entire Internet!
  • Are your NFS imports correct? Are imports from machines you don't trust marked nosuid and nodev? Some systems permit users to do NFS mounts (either directly or through the automounter). You should either block this or at least ensure that user mounts are nosuid and nodev.
  • Are you using YP (a.k.a. NIS) to share information between machines? If you are, check to see if your YP server(s) can be constrained to pass information only to the correct hosts. Slightly more subtly, but important nonetheless, check to see if your YP clients can be constrained to accept information only from the correct hosts. Some vendors supply hooks for one or the other but not both. Are you still using the default (and therefore well-known) domainname noname?
  • If it exists, does your /etc/hosts.equiv file have safe contents? And your users' .rhosts files? (NB: A "+" means that any machine is trusted.)
  • Does your X server start up without any X authorisation checking enabled? Run the command xhost and see what it says. Anything more than "access control enabled, only authorized clients can connect" is cause for concern.
  • Are you offering an anonymous FTP service? (Possibly inadvertantly?) ftp to your own machine, try logging in as user anonymous and try to get a copy of your machine's /etc/passwd file. If you can do it, then so can anyone else. Even if you can't, do you really need to provide anonymous FTP?
  • If you do have to offer an anonymous FTP service, can it be used by third parties as a drop-box? Check that there are no directories to which you can upload a file and then download it again.

It is wise to switch off explicitly any network facilities that you do not intend to use.

  • Check your start up scripts and the /etc/inetd.conf file to determine what network services you are providing.
  • Run netstat -a and rpcinfo -p to see what TCP/UDP ports and RPC services you have open.
  • We have already covered FTP and TFTP. If you are providing FTP (anonymous or not) make sure that none of the non-user accounts can make incoming FTP connections.
  • If you do not intend to receive incoming mail on your system then disable the network mail listener.
  • Decide if you want to support external use of finger and rusers to scan your machine's users.

Who can watch you type in your password?

  • If you only ever log on to your computer at its console then this section need not concern you.
  • Potentially, any machine on the same ethernet as your machine can be made to read every piece of data you send out over the network, such as your userid and password.
  • Typically, this means every machine in your College or on your site can read any data you transmit or receive over the network.
  • Think before you log in over the network, especially as root.
  • This is where judicious use of .rhosts files can be useful.
  • Use SSH. This provides fairly watertight security from network attacks, but doesn't help if the source or destination host is compromised.

Read the appropriate CERT advisories.

  • The CERT is the ``Computer Emergency Response Team''. It was set up after the Morris Worm devastated the Internet in 1988 and made people aware that security was important. (The Worm was a program written by Robert Morris Jr. that used Internet connectivity and certain security loopholes to spread itself from one Unix machine to many others.
  • It publishes ``advisories'' about security holes from time to time. These are published once the vendors concerned have produced patches, usually several months (and sometimes years) after the holes are known to the enemy.

Install the appropriate security patches for your system.

  • If you have bought software maintenance for your system through a University deal (Sun through the central maintenance contract, Silicon Graphics through the 100-seat licence or Digital through the DECCampus deal) then contact Unix Support and ask for the current set. We should be able to provide them fairly swiftly.
  • If you buy your system directly from a vendor and arrange maintenance through that vendor, phone them up and ask yourself. If the vendor or reseller proves to be useless, Unix Support may be able to help.

Educate your users to keep their accounts secure.

Users should...

  • never lend their accounts to someone else.
  • be careful about what other accounts they trust.
  • pick good passwords
  • not leave their passwords lying around, written on a Post-It stuck to the computer etc.

(This all sounds easy. Now consider what you will do if you discover it is your supervisor or head of department breaching these guidelines.)

Are your users secure from each other?

  • Your users may all trust one another and all be trustworthy. But if one user's account gets successfully attacked and your system is internally insecure then all your other users are immediately vulnerable.
  • Do any of your users keep world-writable files?
  • Do any of your users keep passwords in world-readable files? (In fact, users should not keep passwords in any files. If root falls on your machine then the contents of the file are exposed and this gives the enemy a trivial route onto other systems.)

Read the appropriate news groups to keep up to date.

This will easily account for about half an hour of your weekly administration time.
is a local low-traffic group that carries computer security announcements, and should be read by everyone who runs a system in the University. It's also accessible through a Web interface.
is the corresponding discussion group, and is worth reading as well.
is the local Unix news group. Topics specific to Unix systems within the University of Cambridge are discussed here. You should read this (low traffic) group.
is the local computing announcements group. Read this one as well. Again, it's a low traffic group.
is a low-traffic group that carries the CERT advisories as they are announced. You must read this newsgroup.
is a fairly high-traffic group, most of which can be skipped but which has the occasional gem in it. This group is worth skim reading.
is becoming less relevant now that the Unix-specific group has been created. You won't miss much by skipping this group.
is a group that now contains more about forcing locks and perceived infringements of civil rights in the U.S.A. than it does about computer security. You won't miss anything important by skipping this group.


These are tools that are helpful to security, and that we think everyone really should have installed. They can all be obtained from the JANET-CERT Web site at

is a set of programs to provide a secure, encrypted alternative to TELNET, rsh and rlogin. It also provides forwarding of X11 and arbitrary TCP connections. Everyone should use it. We produce a CD-ROM containing SSH clients for most platforms.
is a library and a program for inserting logging and access-control into network services, especially those run from inetd. Most free Unices come with tcp_wrappers installed by default. For those that don't, it's fairly easy to add it.
is a daemon that runs on your system and acts as a partner to somebody else's TCP wrapper. Their wrapper will not only tell them that a user (or possibly the enemy) has made a connection to their system from your machine, but also who that user was. This is useful for you, as it enables you to track down the offending user (or the compromised account). Most modern Unices come with an identd. For those that don't, pidentd is quite good.
John the Ripper
is a more recent password cracker that will probably be more efficient than crack at finding passwords and testing the security of passwords.
is an old program that will attempt to break the passwords your users (and root) have chosen by comparing them against a dictionary and applying some simple (and well-known) rewriting rules (E to 3, l to 1, o to 0 etc.). This has effectively been superceeded by John the Ripper
is a program that scans your entire operating system and makes a list of all files present, complete with cryptographic checksums. A copy of this is made on a floppy of other removable medium and then routine checks are made comparing the two and highlighting any changes. This involves some effort as the database needs to be recreated after any patching of the system.
The Coroner's toolkit
is a collection of programs for doing post-mortem analysis of a UNIX system that has been compromised. It is probably not worth having it installed since you won't be able to trust it after installation. It is useful to be aware of it if you wish to attempt to work out what happened on your system. If used carefully it can avoid some of the mistakes that will cause one to trample over the evidence, but it is not for beginners.

Routine checks

You should do routine checks of your system. This will account for the majority of your weekly allocation of time supporting the system.

  • It is worth having a checklist of things to do once a week so that you don't forget anything.
  • Compare the list of privileged files against a paper copy.
  • Check your log files. (Not just for security incidents; look for other system problems too.)
  • Look for any world-writable files.
  • Check your users' .rhosts files for dangerous contents. (You should tell them that you are going to do this when you give them the account.)


If you think your system has been compromised , please contact Cambridge CERT and Unix Support as soon as possible!

  • E-mail:,
  • Phone: 34728 on the University exchange.