Security policies

Introduction

If you don't take security seriously, you run a very real risk that someone will break into your system over the network, and wreak havoc with it. For examples of the sorts of things that can happen, see the Honeynet project.

The standard configuration has been designed with security in mind, but here are a few general principles. See also:

• CERT UNIX Configuration Guidelines
• Securing Debian
• Bastille Linux Walkthrough (Bastille doesn't work terribly well on Debian, but we can take some of their advice.)

Passwords

Choose good passwords. Here and here are articles explaining how to do this.

Physical access

There must always be at least one system administrator with physical access to each server. This means that if you're going away on holiday, you must arrange for another sysadmin to be able to get into the room where the server is located.

Firewall

Get a firewall if you can possibly afford it. See StandardNetwork for suggestions, and for a list of the ports you'll need to open for incoming traffic.

Services

Don't run more services than you need. In particular, don't run inherently unsafe services such as ftp or telnet, which send passwords over the wire in cleartext (the only way to log in remotely should be via ssh). These and other services can be disabled by commenting out lines in /etc/inetd.conf. See StandardConfigFiles.

Secure implementations

A Unix system is composed of a number of components, such as a DNS server, a mail transfer agent, etc. Some implementations of these components, such as the BIND DNS server and the Sendmail mail trasfer agent, have had a large number of security vulnerabilities in the past (see security notes on BIND and on Sendmail). Avoid these programs if possible; there are often more secure replacements. For example, there are several mail transfer agents that have been designed for security; we recommend Postfix.

In the case of BIND, the main alternative is djbdns; we'll probably get around to figuring it out sometime, but for now, we recommend running BIND in a chroot jail.

File permissions

Programs that are owned by root, and that have their SUID bit set, will run as root no matter who runs them. This is a security risk. One way to reduce this risk is to allow these programs to be run only by members of the staff group. The script /usr/local/bin/fix-perms.sh adjusts group ownership and permissions accordingly on some of these programs. We include the compiler, gcc, because crackers may try to use an ordinary account to compile exploits. (The ingenious Linux/Slapper worm did this.) Install this script, make it executable, then run it as root:

sudo chown root:staff /usr/local/bin/fix-perms.sh
sudo chmod 754 /usr/local/bin/fix-perms.sh
sudo fix-perms.sh

Security updates

Stay abreast of security alerts for the packages you use. The easiest way to do this is to subscribe to one or more security advisory mailing lists, such as:

• debian-security-announce mailing list
• CERT mailing list
• Bugtraq mailing list (high volume)

When a new version of a Debian package is released to fix a vulnerability, it will typically be on security.debian.org; you can get all the latest Debian security fixes by doing this:

sudo apt-get update
sudo apt-get upgrade

For programs you've compiled from source, you'll need to download the latest source code and recompile; see StandardSourceInstalls for details.

Checking your system

There are tools that can help you find vulnerabilities in your system. This is absolutely essential if you aren't using a firewall, and highly recommended in any case. We recommend Nessus; it will scan your system's network ports, looking for vulnerable services, and give you a report on possible problems and what you can do about them.

You can find SUID root programs by running this command:

sudo find / -perm +u+s -a -user root