Lance Spitzner

Organizations throughout the world are adopting Linux as their production platform.   By connecting to vide critical services, they also become targets of opportunity.  To help protect these Linux systems, this article covers the basics of securing a Linux box.  The examples provided here are based on Red Hat 5.x, but should apply to most Linux distributions.

Installation
The best place to start in armoring your system is at the beginning, OS installation. Since this is a production system, you cannot trust any previous installations. You want to start with a clean installation, where you can guarantee the system integrity. Place your system in an isolated network. At no time do you want to connect this box to an active network nor the Internet, exposing the system to a possible compromise. I personally witnessed a system hacked by a script kiddie within 15 minutes of connecting to the Internet.  To get critical files and patches later, you will need a second box that acts as a go between. This second box will download files from the Internet, then connect to your isolated, configuration "network" to transfer critical files.

Once you have placed your future Linux box in an isolated network, you are ready to begin. The first step is selecting what OS package to load. The idea is to load the minimum installation, while maintaining maximum efficiency.  Chose the installation that suits your needs, but deselect package you will not be using.  The less software that resides on the box, the fewer potential security exploits or holes.  This means if you do not need the News or Real Audio Server, don't install it.  The nice thing about Linux is it is easy to add packages later.  Regardless of which installation you choose, I would add the manual pages and HOWTO docs.  I find the on-line man pages and docs to be a critical resource that add little risk to your system.

During the installation process, you will be asked to partition your system.  I always like to make root as big as possible and just throw everything in there, then you do not run out of room in the future.  However, we do need several partitions to protect the root drive.  If we were to fill the root partition with data, such as logging or email, we would cause a denial of service, potentially crashing the system.

Therefore, I always recommend a separate partition for /var, this is where all the system logging and email goes.  By isolating the /var partition, you protect your root partition from overfilling.   I've found 400 MB to be more then enough for /var.  You may also consider making a separate partition for specific application purposes, especially applications that store extensive logging.  With such a setup, your partitions would look as follows:

/        - everything else
/var     - 200 MB
swap     - (max 127 MB of RAM)
 

Once the system has rebooted after the installation, be sure to install the recommend security patches. For Red Hat, you can find these security patches at http://www.redhat.com/support.  An excellent example of this is the security update for wu-ftpd  Without these patches, your system can be easily compromised.  Be sure to use your go between box to get the patches, the Linux box should always remain on an isolated network. Patches are critical to armoring a system and should always be updated.  BUGTRAQ@netspace.org is an excellent source for following bugs and system patches. For Red Hat, once you download the rpm, you can easily update your system using the following syntax.

rpm -Uvh wu-ftpd-2.4.2b18-2.1.i386.rpm

For systems that are already on-line, you can ftp the rpm and install it at the same time, using the following syntax.

rpm -Uvh ftp://updates.redhat.com/5.2/i386/wu-ftpd-2.4.2b18-2.1.i386.rpm

Eliminating Services
Once you have loaded the installation package, patches, and rebooted, we are now ready to armor the operating system. Armoring consists mainly of turning off services, adding logging, tweaking several files, and configuring TCP Wrappers. First we will begin with turning off services.

By default, Linux is a powerful operating system that executes many useful services. However, most of these services are unneeded and pose a potential security risk. The first place to start is /etc/inetd.conf. This file specifies which services the /usr/sbin/inetd daemon will listen for. By default, /etc/inetd.conf is configured for a variety of services, you most likely only need two, ftp and telnet. You eliminate the remaining unnecessary services by commenting them out (example A).  This is critical, as many of the services run by inetd pose serious security threats, such as popd, imapd, and rsh.  Confirm what you have commented out with the following command (this will show you all the services that were left uncommented)

 grep -v "^#" /etc/inetd.conf

The next place to start are the .rc scripts, these scripts determine what services are started by the init process. For Red Hat, you will find these scripts in /etc/rc.d/rc3.d.  To stop a script from starting, replace the capital S with a small s. That way you can easily start the script again just by replacing the small s with a capital S. Or, if you prefer, Red Hat comes with a great utility for turning off these services.  Just type "/usr/sbin/setup" at the command prompt, and select "System Services", from there you can select what scripts are started during the boot up process.  Another option is chkconfig, which you will find on most distributions.  The following startup scripts may be installed by default but are not critical to system functioning.  If you don't need them, turn these scripts off.  The numbers in the names determine the sequence of initialization, they may vary based on your distribution and version.

S05apmd (You only need this script for laptops)
S10xntpd (Network time protocol)
S15sound
S20bootparamd (Used for diskless clients, you probably don't need this vulnerable service)
S20nfs (Use for NFS server, do not run unless you absolutely have to).
S20rusersd (Try to avoid running any r services, they provide too much information to remote users).
S20rwalld
S20rwhod
S25innd (News server)
S25squid (Proxy server)
S30sendmail (You can still send email if you turn this script off, you just will not be able to receive or relay).
S30ypbind  (Required if you are a NIS client)
S34yppasswdd (Required if you are a NIS server, this is an extremely vulnerable service)
S35dhcpd
S35ypserv (Required if you are a NIS server, this is an extremely vulnerable service)
S40portmap (This startup script is required if you have any rpc services, such as NIS or NFS)
S40snmpd (SNMP daemon, can give remote users detailed information about your system)
S55routed (RIP, don't run this unless you REALLY need it)
S55named (DNS server.  If you are setting up DNS, upgrade to Bind 8.2,  http://www.isc.org/bind.html)
S60atd (Used for the at service, similar to cron, by not required by the system)
S60lpd (Printing services)
S72amd (AutoMount daemon, used to mount remote file systems)
S75gated (used to run other routing protocols, such as OSPF)
s85httpd (Apache webserver, I recommend you remove the installed version and upgrade to the latest version, http://www.apache.org)
S95nfsfs (This is the nfs client, used for mounting filesystems from a nfs server)
S95pcmcia (You only need this script for laptops)

To see how many services are running before you change the startup scripts, type

ps aux | wc - l

Once you are done with the installation and have turned off the startup scripts, type the command again and compare how the number of services have decreased. The fewer services running, the better.

Logging and Tweaking
Once you have eliminated as many services as possible, we want to enable logging. All system logging occurs in /var/log.   By default, Linux has excellent logging, except for ftp.  You have two options for logging for ftp, configure /etc/ftpaccess file or edit /etc/inetd.conf.  I prefer to edit /etc/inetd.conf, as it is simpler (i.e. harder to mess up :).  Edit /etc/inetd.conf as follows to ensure full logging of all FTP sessions.

ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -l -L -i -o

--- From the man pages ---

If the -l option is specified, each ftp session is logged in the syslog
If the -L flag is used, command logging will be on by default as soon as the ftp server is invoked.  This will cause  the  server  to log all USER commands, which if a user accidentally enters a password for that command instead of the username, will cause passwords to be logged via syslog.
If the -i option is specified, files received by the ftpd(8) server will be logged to the xferlog(5).
If the -o option is specified, files transmitted by the ftpd(8) server will be logged to the xferlog(5).

--- snip snip ---
 

Next comes tweaking. This involves various file administration. The first thing we want to do is create the file /etc/issue. This file is an ASCII text banner that appears for all telnet logins (example B). This legal warning will appear whenever someone attempts to login to your system. If you want to continue using the same /etc/issue file, you will have to modify /etc/rc.d/rc3.d/S99local.  By default, Linux creates a new /etc/issue file on every reboot.

We want to do two things to secure our /etc/passwd file (this is the database file that holds your user accounts and passwords).  First, we want to convert our system to use /etc/shadow, this securely stores everyone's password in a file only root can access.  This protects your passwords from being easily accessed and cracked (one of the first exploits a hacker looks for).  All you have to do is type the following command as root.  This automatically  converts your encrypted passwords to the /etc/shadow file. Of all the actions you can take to secure your system, I consider this to be one of the most important.

pwconv

The second step is to remove most of the default system accounts in /etc/passwd.  Linux provides these accounts for various system activities which you may not need.  If you do not need the accounts, remove them.  The more accounts you have, the easier it is to access your system.  An example is the "news" account.  If you are not running nntp, a news group server, you do not need the account (be sure to update /etc/cron.hourly, as this looks for the user "news"). Also, make sure you remove the "ftp" account, as this is the account used for anonymous ftp.  From the man pages.

man ftpd:

Ftpd authenticates users according to four rules.

4)If  the  user name is ``anonymous'' or ``ftp'', an anonymous ftp account must be pre-sent in the password file (user ``ftp'').  In this case the user is allowed to log in by specifying any password (by convention this is given as the client host's name).

For an example of my /etc/passwd file, check out example C.
 

We also want to modify the file /etc/ftpusers (example D). Any account listed in this file cannot ftp to the system. This restricts common system accounts, such as root or bin, from attempting ftp sessions. Linux has the file by default.  Ensure that root stays in this file, you never want root to be able to ftp to this system.  Ensure that any accounts that need to ftp to the box are NOT in the file /etc/ftpusers.

Also, ensure that root cannot telnet to the system. This forces users to login to the system as themselves and then su to root. The file /etc/securetty lists what ttys root can connect to.  List only tty1, tty2, etc in this file, this restricts root logins to local access only.  ttyp1, ttyp2, are pyseudo terminals, they allow root to telnet to the system remotely (example E).
 

TCP Wrappers
TCP Wrappers are a must, no armored system should be without it. Created by Wietse Venema, TCP Wrappers are a binary that wraps itself around inetd services, such as telnet or ftp. With TCP Wrappers, the system launches the wrapper for inetd connections, which logs all attempts and verifies the attempt against a access control list. If the connection is permitted, TCP Wrappers hands the connection to the proper binary, such as telnet. If the connection is rejected by the access control list, then the connection is dropped.  Fortunately for us Linux users, TCP Wrappers is already installed, the only thing left for us to do is edit the /etc/hosts.allow and /etc/hosts.deny file.  These files determine who can and cannot access our systems.  Also, TCP Wrappers allows us to do fancy things, such as banners or spawn additional programs, such as safe_finger.  The syntax is relatively simple.  Put the IP address or networks in /etc/hosts.allow that you want to permit connections from.  Put IP addresses or networks in /etc/hosts.deny that you do not want to permit access.  By default, Linux allows connections from everyone, so you will need to modify these files.  2 recommendations when working with TCP Wrappers.

1. Use IP addresses and networks instead of domain names.
2. Set up /etc/hosts.deny to deny everything (ALL), then permit only specific sites with /etc/hosts.allow.

For the Truly Paranoid
I consider the measures discussed above absolutely essential.  By following these steps, you have greatly improved your system's security, congratulations!  Unfortunately, your system is not 100% secure, nor will it ever be.  So, for the truly paranoid, I have added some additional steps you can take.

First we will create the wheel group.  The wheel group is a group of select individuals that can execute powerful commands, such as /bin/su. By limiting the people that can access these commands, you enhance the system security.  To create the group, vi the file /etc/group, create the group wheel, and add the system admins to the group.  Then identify critical system binaries, such as /bin/su.  Change the group ownership to wheel, and the permissions to owner and group executable only (be sure to maintain the suid or guid bit for specific binaries).  For /bin/su, the commands would be:

/bin/chgrp wheel /bin/su
/bin/chmod 4750 /bin/su

Second, we will lock down the files .rhosts, .netrc, and /etc/hosts.equiv.  The r commands use these files to access systems.  To lock them down, touch the files, then change the permissions to zero, locking them down. This way no one can create or alter the files. For example,

/bin/touch /.rhosts /.netrc /etc/hosts.equiv
/bin/chmod 0 /.rhosts /.netrc /etc/hosts.equiv

Third, we make some modifications to PAM.  PAM (Pluggable Authentication Modules) is a suite of shared libraries that enable you to choose how applications authenticate users.  To learn more about PAM, check out ftp://ftp.us.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html.  There are a variety of tweaks that you can make to your system.  Here is an example of how to convert your encrypted passwords to use MD5, making your /etc/shadow file far more difficult to crack.

Go to /etc/pam.d directory, where you will find all the configuration files for different binaries that require authentication.  Most of the configuration files will have the following entry.
password   required     /lib/security/pam_pwdb.so nullok use_authtok

All you need to do is find all the configuration files that have this entry, and add "md5" to the end, so it looks like this.
password   required     /lib/security/pam_pwdb.so nullok use_authtok md5

For my RedHat 5.1 system, I had to edit this line in the following configuration files in /etc/pam.d
chfn
chsh
login
passwd
rlogin
su
xdm

Last thing we can do is protect our system from physical access.  This mainly consists of setting up a password for our BIOS.  Also, you can password protect your system during boot-up by configuring /etc/lilo.conf with a password (password=xxx)  where xxx is your password.  However, keep in mind, once someone has physical access to your system, this is no guaranteed way to protect it.
 

Conclusion
We have covered some of the more basic steps involved in armoring a Linux box (Red Hat distribution). The key to a secure system is having the minimal software installed, with protection in layers, such as TCP Wrappers. There are many additional steps that can be taken, such as ipchains (firewall software), ssh (encrypted rlogin, rcp, and telnet), tripwire (monitor changes in system binaries), and swatch (automated log monitoring and alerts). Remember, no system is truly 100% secure. However, with the steps outlined above, you greatly reduce the security risks.