17.2.1. Shutting Down Unwanted Network Daemons

The first step in securing a Linux machine is to shut down or disable all network daemons and services that you don't need. Basically, any network port that the system is listening for connections on is a risk, since there might be a security exploit against the daemon using that port. The fast way to find out what ports are open is to use netstat -an, as shown next (we've truncated some of the lines, however):

# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:7120            0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:6000            0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN

Here we see that this system is listening for connections on ports 7120, 6000, and 22. Looking at /etc/services, or using the -p to netstat, can often reveal what daemons are associated with these ports. In this case it's the X font server, the X Window System server, and the ssh daemon.

If you see a lot of other open ports — for things like telnetd, sendmail, and so forth ask yourself whether you really need these daemons to be running. From time to time, security exploits are announced for various daemons, and unless you are very good at keeping track of these security updates, your system might be vulnerable to attack. Also, telnetd, ftpd, and rshd all involve sending clear-text passwords across the Internet for authentication; a much better solution is to use sshd, which encrypts data over connections and uses a stronger authentication mechanism. Even if you never use telnetd, it's not a good idea to leave it running on your system in case someone finds a way to break into it.

Shutting down services is usually a matter of editing the appropriate configuration files for your distribution and rebooting the system (to be sure they're good and dead). On Red Hat systems, for example, many daemons are started by scripts in the /etc/rc.d/init.d directory; renaming or removing these scripts can prevent the appropriate daemons from starting up. Other daemons are launched by inetd or xinetd in response to incoming network connections; modifying the configuration of these systems can limit the set of daemons running on your system.

If you absolutely need a service running on your machine (such as the X server!), find ways of preventing connections to that service from unwanted hosts. For example, it might be safest to allow ssh connections only from certain trusted hosts, such as from machines in your local network. In the case of the X server and X font server, which run on many desktop Linux machines, there is usually no reason to allow connections to those daemons from anything but the local host itself. Filtering connections to these daemons can be performed by TCP wrappers or IP filtering, which are described later in this chapter.

17.2.2. Top 10 Things You Should Never Do

We've made the claim that security is mostly common sense, so what is this common sense? In this section we summarize the most common security mistakes. (There aren't actually 10 items in this list, but there are enough to merit the use of the common "top 10" phrase.) Consistently avoiding them all is harder work than it might first seem.

Never use simple or easily guessed passwords

Never use a password that's the same as (or closely related to) your user ID, name, date of birth, the name of your company, or the name of your dog. If you're an amateur radio operator don't use your callsign; if you love cars don't use the make/model or registration number of your car — you get the idea. Always ensure that your passwords are not simple words that can be found in a dictionary. The best passwords are nonsense strings. One good practice is to use a password based on a simple rule and a phrase that you can remember. For example, you might choose a rule like: the last letter of each word in the phrase "Mary had a little lamb, its fleece was white as snow," hence the password would become ydaebsesesw, certainly not something that will be easily guessed, but a password that will be easily remembered. Another common technique is to use numbers and punctuation characters in the password; indeed some passwd programs insist upon this. A combination of the two techniques is even better.

Don't use the root account unless you have to

One of the reasons that many common desktop operating systems (such as Windows) are so vulnerable to attack through email "viruses" and the like is the lack of a comprehensive privilege system. In such systems, any user has permission to access any file, execute any program, or reconfigure the system in any way. Because of this it's easy to coerce a user to execute a program that can do real damage to the system. In contrast, the Linux security model limits a wide range of privileged tasks, such as installing new software or modifying configuration files, to the root user. Do not succumb to the temptation to use the root account for everything! In doing so you are throwing away one of the more powerful defenses against virus and "Trojan Horse" attacks (not to mention accidental rm -rf * commands!). Always use a normal user account, and use the su or sudo commands to temporarily obtain root access when you need to undertake privileged tasks. There is an additional benefit in this limited use of the root account: logging. The su and sudo commands write messages to the system log file when they're invoked, mentioning the ID of the user performing the su or sudo, as well as the date and time that the command was invoked. This is very helpful for keeping track of when root privileges are being used, and by whom.

Don't share your passwords

Don't tell anybody your passwords, ever. This also means you shouldn't write your passwords on little sticky notes attached to your monitor, or into the diary you keep in the top drawer. If you want to allow someone temporary access to your system, create an account for them to use. This allows you some convenience in monitoring what they do, and you can easily clean up afterward. If you really must trust someone with your root account, use the sudo command, which allows you to give users root access without revealing the root password.

Don't blindly trust binaries that have been given to you

While it is very convenient to retrieve and install binary copies of programs on your system, you should always question how much you trust the binary before running it. If you're installing software packages that you've retrieved directly from the official sites of your distribution, or a significant development site, you can be fairly confident the software is safe. If you're getting them from an unofficial mirror site, you need to consider how much you trust the administrators of the site. It is possible that someone is distributing a modified form of the software with back doors that would allow someone to gain access to your machine. While this is a rather paranoid approach, it is nevertheless one that many Linux distribution organizations are embracing. For example, the Debian organization is developing a means of validating a software package to confirm that it hasn't been modified. Other distributions are sure to adopt similar techniques to protect the integrity of their own packaged software.

If you do want to install and execute a program that has been given to you in binary form, there are some things you can do to help minimize risk. Unfortunately, none of these techniques is easy if you're new to the Linux environment. First, always run untrusted programs as a non-root user unless the program specifically requires root privileges to operate. This will contain any damage the program might do, affecting only files and directories owned by that user. If you want to get some idea of what the program might do before you execute it, you can run the strings over the binaries. This will show you all the hard-coded strings that appear in the code. You should look for any references to important files or directories, such as /etc/passwd, /bin/login, etc. If you see a reference to an important file, you should ask yourself whether that is in keeping with the purpose of the program in question. If not, beware. If you're more technically inclined, you might also consider first running the program and watching what it is doing using a program like strace or ltrace, which display the system and library calls that the program is making. Look for references to unusual file system or network activity in the traces.

Don't ignore your log files

Your system log files are your friend, and they can tell you a lot about what is happening on your system. You can find information about when network connections have been made to your system, who has been using the root account, and failed login attempts. You should check your log files periodically and get to know what is normal, and more usefully what is abnormal. If you see something unusual, investigate.

Don't let your system get too far out of date

It's important to keep the software on your system fairly current. That Linux kernel 1.2 system you have running in the corner that's been reliably serving your printers for years might be a great subject at cocktail parties, but it's probably a security incident waiting to happen. Keeping the software on your system up-to-date helps ensure that all bug and security fixes are applied. Most Linux distributions provide a set of packages that are security fixes only, so you don't have to worry about issues, such as configuration file and feature changes in order to keep your system secure. You should at least keep track of these updates.

Don't forget about physical security

Most security breaches are performed by people inside the organization running the target system. The most comprehensive software security configuration in the world means nothing if someone can walk up to your machine and boot a floppy containing exploit code. If your machine uses a BIOS or system PROM that allows the device boot order to be configured, set it so that the floppy and CD-ROM drives boot after the hard drive. If your BIOS provides support for password protection of its configuration, use it. If you can padlock the machine case closed, consider doing so. If you can keep the machine in a physically secure area such as a locked room, that's even better.