Implementing Security on Linux

Patrick Lambert

Security is never a luxury. It can save money, time, and frustration. The Linux operating system, a UNIX clone created in 1991, has several built-in security mechanisms, which are unfortunately rarely used. This article explores the basic aspects of securing a Linux server.

Start with a fresh install. Any security expert will tell you that there is no use securing a system when you don't know whether break-ins and backdoors already have been created. Any Linux distribution will work fine, because they all contain the required security tools. You should install and configure the Linux system before connecting it to the Internet. Linux installation is relatively simple regardless of the distribution you pick -- the security configuration happens after the installation.

Basic security on a Linux system is very similar to other UNIX systems. Areas to configure include user security, network security, and kernel parameters. This article reviews all of these areas, including more advanced ways to add security to Linux and some sites that contain more information.

Initial Security

After initial system setup, you can see how to make it cracker-proof. First, secure the root account. For example, edit the file /etc/securetty, which contains a list of pseudo-terminals from which root can logon. Disable telnet (ttyp0-ttyp9), so the root user can only be used on the console or over a secure link such as ssh. Also, configure the ftp daemon to refuse root logins. The file /etc/ftpusers lists the users that cannot use ftp and the root user should be part of that list.

Securing normal user accounts depends on which actions you want to allow them to do. For example, with a mail account the shell should be set to /dev/null when you create the user account. A last thing to do from the shell is disable suid programs. Programs that are set uid root (suid) can be executed by any user, and the program will run with root permissions. This is very dangerous, and only necessary programs should be left suid. Type the following command to find out which binaries are suid on your system:

find / -perm -4000 -print

You will get several pages of programs. Disable those that are not necessary. I recommend disabling at least traceroute, ping, rcp, rlogin, and uu*.

Networking

When connected to the Internet, your server acts as a playground for crackers who wish to crack in to destroy data or steal property, especially if your site is high profile. You must know which Internet services are running, and disable all those that aren't necessary. Services are started from two places: The Internet daemon, configured in the file /etc/inetd.conf, and the startup files, in the directory /etc/rc.d. Go over each of them and see if you need these services. Although services like finger, echo, or daytime have their uses, you probably don't need them and if you leave them running, they create possible security holes in your system. A good way to see what is currently running from the startup files is by issuing this command:

ps -ax

Note that services started by the inet daemon are not listed in ps because they are only started once someone connects to them. Let's go over some of them and see whether they are needed. Services running as daemon:

• kerneld -- This process is unrelated to networking and may cause you to wonder what this is, especially since older versions of Linux did not have it. The kerneld process is a way for the kernel to perform action in user space. It is, for example, used for loading kernel modules.

• inetd -- This is the super-server, the Internet process that controls other services such as ftp, telnet, and finger. It is needed most of the time and should be left alone. You can configure inetd from the /etc/inetd.conf file, where each specific running service is listed.

• lpd -- This is the line printer daemon. It controls the spooling system and the printing. Using a daemon allows your system to receive print jobs over the network from authorized systems. You can firewall it if you do not expect printing requests to come from other hosts. We will talk about firewalling later.

• portmap -- The portmap process converts TCP/IP calls into RPC numbers and is needed to run RPC processes. You need it, for example, to share directories between hosts, using the NFS protocol.

• rpc.mountd, rpc.nfsd -- These are the necessary processes for allowing other hosts to mount shared directories on your system, using the NFS protocol.

Here are the most popular services run from inetd, which you need to configure in the /etc/inetd.conf file:

• telnet -- telnet is an unsecure protocol. It transmits data over an uncrypted connection. It should not be used for administration purposes and should be disabled on servers with sensitive data.

• ftp -- The File Transfer Protocol is a widely used service to transmit files over the Internet. There are two ways to use ftp -- for user login, and for public purposes. If you allow the special user “anonymous” to log in on your ftp server, this may have serious implications. Avoid it, if possible, because we often see security announcements regarding possible buffer overflows in ftp servers allowing unauthorized users to gain root access.

• smtp -- The SMTP server is the Internet mail server. It could be Sendmail, Qmail, or an other program. Keep your email server up to date, because most systems need an email server to participate in the widely used email system.

Once you are familiar with every service that is running, make sure that you have the latest stable versions, and that they contain no known bug. You can run Sendmail, the email server, as well as Apache for Web serving, and ftpd for anonymous ftp, but first understand each of these services and how they handle clients so you can configure them properly. Sendmail, for example, runs as root and does everything with superuser privileges. This means if any bug is found in any part of Sendmail, then root is vulnerable. This was a big problem in past versions, but now it is much more secure. Another solution to try is Qmail, which is also an email server, but runs multiple processes, and only a minimal part runs as root. If a bug is discovered in another part of the program, root will not be vulnerable.

Also consider the ftp daemon. The most popular ftp daemon on Linux, and the one that comes by default, is wu.ftpd. Bugs are sometimes found and not fixed right away in the main wu.ftpd distribution. Look for the VR series -- the wu.ftpd(VR) distribution is a package that does everything the normal ftp daemon does, plus various bug fixes and enhancements. Always run the latest VR version, since the ftp daemon must run as root in order to assign users their proper permissions. Note that allowing anonymous users on your server is another possible security hole. Read the man page for precise information on how to set up the anonymous account to be secure.

Apache was designed in a completely different way. As soon as you start httpd, the Apache binary, it sets itself as another user. It does everything as a normal user, with no special privileges. This is why Apache can't allow someone to break into a system. Note that this only applies to the server itself, not the CGI scripts you may allow users to run.

Also consider the way people log on. By default, telnet and ftp are not encrypted, and passwords are sent as clear text. Never log in as root over telnet. Install sshd, which allows you to log in using an encrypted connection. With ssh you can log in, and with scp you can copy files to and from the server. Another option is to disable ftp and telnet completely and let your users use only ssh and scp.

Firewalling and Kernel Parameters

The Linux kernel comes with advanced packet filtering and accounting. This is the next area to work on. Configure your kernel with IP Firewalling and IP Accounting on. To configure your firewall, use the ipfwadm utility for kernels 2.0.x and ipchains for kernels 2.2.x. Basic firewalling rules to add are blocks for address spoofing. For example, if your server is a gateway for a local LAN (with the eth0 network interface connected to the Internet and the eth1 interface linked to a local network with IPs in the 192.168.1.x class), it makes no sense for packets from an IP in the 192.168.1.x class to come in from eth0. This would certainly be a spoofing attempt.

These rules, entered by the ipfwadm or ipchains commands, are then set up in the kernel's firewalling rules. For example, here are rules commands to block packets from an address spoofer trying to appear as an internal system, assuming the external IP of your system is 254.23.45.5.

For kernels 2.0.x:

ipfwadm -I -i deny -P all -W eth0 -S 192.168.1.0/24 -D 254.23.45.5/32

For kernels 2.2.x and up:

ipchains -I input -p all -i eth0 -s 192.168.1.0/24 -d 254.23.45.5/32  -j
DENY

It would also be impossible for a packet coming from 127.0.0.1 to arrive on eth0.

You can also use the TCP wrappers package, which does the same thing as IP firewalling, but on a per service basis. Configure /etc/hosts.deny to deny everyone except your local domain from accessing ftpd. For example:

in.ftpd: ALL EXCEPT 192.168.1., 127.0.0.1

The last thing to secure is the shell that your users will use. Linux's default shell, BASH, comes with a built-in command called ulimit, which interacts with the kernel to set various limits. This command allows you to set limits on what user-run processes are allowed to do. To get a full list of current limits, type:

ulimit -a

For example, to set the maximum core file size to 50 blocks, type:

ulimit -c 50

This sets soft limits. The file /usr/src/linux/include/linux/limits.h contains various defines that you can change to set hard limits on users before compiling the kernel.

Advanced Topics

An interesting concept that is becoming more popular is encryption. There are two ways to encrypt files -- a program that can encrypt a file with a key, and a kernel module that can encrypt a file system. The default Linux file system is ext2, and it is a bare bones file system, with no ACL or encryption capabilities. To encrypt files on a file system, install a file system that is capable of handling encryption. One such file system is TCFS. It is a transparent file system that installs itself as a kernel module and provides files to clients in a way similar to NFS. The client requests files, and the server handles the requests, and provides decrypted files to the client. To encrypt only a few files, use a program like PGP or IDEA. PGP uses a public/private key scheme, while IDEA only uses one key on the command line.

Final Thoughts

I have only scratched the surface of security issues for Linux systems. In reality, security is a complex, continuous task. At a minimum, you must do two things on a regular basis to ensure security on your server. First, check your logs often. Several tools are available to help you monitor logs. (I created my own small program that would parse the log, put in bold and issue a beep on important lines like password failure or su login.) Second, read CERT notices, the BUGTRAQ mailing list, and the sites of the authors of the various programs you are running (like Sendmail and Apache) for updated versions.

Resources

http://metalab.unc.edu/LDP -- The Linux Documentation Project provides various documents for administrators on various Linux issues.

http://www.seifried.org/lasg -- This is the Linux Administration and Security Guide, which provides much more in-depth coverage of various security tools and lists the common services and ways to secure them.

http://www.cert.org -- The CERT Coordination Center is the central place for security issues in all kinds of UNIX programs. They publish advisories on new-found security holes.

http://www.geek-girl.com/bugtraq -- BUGTRAQ mailing list archives.

http://metalab.unc.edu/LDP/HOWTO/IPCHAINS-HOWTO.html -- ipchains how-to.

http://tipoftheweek.darkelf.net -- The Tip Of The Week Web site lists Linux tips on various issues that can arise while configuring a Linux system.

http://tcfs.dia.unisa.it -- The TCFS encrypted file system home page.

http://www.pgpi.com -- PGP international Web site.

ftp://idea.sec.dsi.unimi.it/pub/crypt/code -- Contains IDEA and other encryption programs.

About the Author

Patrick Lambert is a computer consultant and has been involved in the Linux and UNIX worlds since 1994. He currently creates software and offers computer support to users and companies worldwide. A list of the software he has created is available at http://devplanet.fastethernet.net. He can be reached at: drow@post.com.