Securing a Linux machine on the Eno network

Linux is convenient and powerful, but its widespread use by folks who don't really have much idea about computer security, and its availability to malicious people who want to find ways to break computers, mean it is a popular target for network-based attacks.

The best thing, of course, is to get educated about computer security in general. Failing that, here are four easy steps to take, in order of importance, that will make your Linux box an order of magnitude more secure while you figure out which services you really need and how they work.

N.B.: no warranty expressed or implied. Use at your own risk (see "the Ultimate Firewall").

This material is a work in progress, constructive feedback is much appreciated ... most of this advice is targeted towards Red Hat 5.2 and towards machines in the Ecology and Evolutionary Department at Princeton University, but it should be somewhat more widely applicable.

Last update: 16 June 1999 (RH 6.0 patch descriptions)

News

The only new security stuff floating around since the last time I did any serious updates (early May) are new releases of Netscape and wu-ftpd (perennial security problem, and so worth updating) and some denial-of-service attacks in the new (2.2.x) kernels. If you have RedHat 6.0 or are a bleeding-edge type and have upgraded your kernel, you should apply patches.

As of 14 June, kernel 2.0.37 is available. According to www.kernelnotes.org, "Probably the last 2.0.x release. It fixes a number of DoS (Denial of Service) vulnerabilities, so it's probably worth upgrading." However, Red Hat has not yet wrapped this in a bow and made it pretty, so you'll have to read the kernel upgrade notes and make your own way, probably patching and compiling the kernel source yourself (not for the faint of heart). [If you really want to do this, get the source RPMs from RedHat and the 2.0.37 patch from kernelnotes.org, read all documentation you can get your hands on, and don't say I didn't warn you. Otherwise, Red Hat will probably come out with some slightly more pre-packaged solution soon.]

  1. Enable TCP wrappers

    2. TCP wrappers are a layer of code that allow you to control and log access to network services. The goal here is to shut off access outside Princeton University. This doesn't guarantee your safety, but it drastically limits the number of jerks with access to your machine. By default TCP wrappers comes installed, but not enabled, on RH 5.2.

    As root, go to /etc and edit the files hosts.allow and hosts.deny.

    Add the following line to hosts.deny: 

    ALL:ALL

    Add the following line to hosts.allow: 

    ALL:LOCAL
    This will deny access to all machines outside of Princeton. There are other possibilities for the hosts.allow list, I really haven't researched what will work in any great detail. 
    ALL:.princeton.edu                   (allow access from Princeton machines)
ALL:128.112.113.0/255.255.252.0      (allow access from Eno/MGB subnet)
ALL:cituser@arizona.princeton.edu    (allow access for particular users)
    (If you are not an Eno/EEB user, you'll need to configure that middle line for your particular subnet.)

    Or use the following script: enable-tcpwrap (download, change mode (chmod +x enable-tcpwrap), execute).

  2. Shut off services in inetd.conf

    3. The inetd system daemon is a "clearing house" for a variety of network services; inetd.conf is its configuration file. Shut off all the services you don't need. New security holes are discovered all the time, but if you're not running a service it doesn't matter if it has a security-related bug in it.

    Edit /etc/inetd.conf. Comment out, by putting a # at the beginning of the line, all unnecessary services. As a start, I suggest leaving only telnet, identd, and time uncommented (you can add services such as ftp later, if you decide you want them. [Note: as I was writing this, there was a major new ftp security hole announced. If you don't need it, turn it off!] You can still use telnet and ftp from your Linux box to connect to other machines).

    After you've updated /etc/inetd.conf you have to tickle the inetd daemon so it sees the updates: 

    killall -HUP inetd
    Or you can copy this shell script (untested!) to edit your inetd.conf file and tickle inetd automatically ...

  3. Shut off other unnecessary services

    4. By default your Linux box runs several network services that you probably don't need, and if you do need them you should make sure they're configured safely (and all appropriate patches have been installed) before you use them.

    Suggested services to shut off:

    You can use an existing mechanism in RH 5.2 to disable automatic startup of services: these tools are /sbin/chkconfig (command-line) and /usr/sbin/ntsysv (text menu) or /usr/sbin/ntsysv (X11 menu). Or you can use my auto-config script (copy it to a file and run it, or just copy the commands straight to the command line in a bash shell) to automate the process.

    There is another option that you can use, a script I wrote (it should work generally on most SysV-based Unices): however, I recommend that if you can you should use the existing chkconfig mechanism under Linux.

  4. Install security patches

    5. Install security patches for your distribution. Red Hat 5.2 has (as of this writing) a relatively small number of security patches, which are listed on the Red Hat site: Most of these security fixes (there are about 13 in total as of Feb. 1999) are relatively minor, and primarily accessible by local users; this is in sharp contrast with RH 5.1. For this reason I strongly recommend installing RH 5.2 instead of 5.1, and reasonably up-to-date distributions in general (I don't know the current security status of Debian, Slackware, or other popular kernels). [Update, March 1999: serious holes have been announced in network security for Linux kernels < 2.0.36. Red Hat 5.2 is OK. If you do have a kernel < 2.0.36 (try uname -a for info), I would suggest upgrading immediately!] Nevertheless, you should look them over and decide which you need to install. My inexpert opinions about patches are available:

    If you have time, or are interested, there's always more you can do in the way of security ...

  5. Install other security packages

    6. Most of these I'm less familiar with myself, but they could all come in handy:

  6. Look at other Linux security links

    7. I haven't actually been able to find very much in the way of concrete, up-to-date examples for Linux, like the security checklists that are available for Solaris etc.. Here are a few reasonably good links.

  7. Follow security news

    8. Various security mailing lists or news sites:

    To do: