This month, we finish our three-part series on hardening Linux systems. As we've seen, hardening is the process of reconfiguring an "out of the box" Linux distribution to make it more secure.
This month, we finish our three-part series on hardening Linux systems. As we’ve seen, hardening is the process of reconfiguring an “out of the box” Linux distribution to make it more secure.
In the first column in this series, we considered physical system security and installation choices. In the second column, we discussed how to configure the kernel, how to alter the boot process, and how to modify or disable system services to thwart intruders. This month, we change our focus from what software and services are provided on the computer to how users actually use it. We’ll see how to secure local file systems, how to restrict insecure root access, and how to configure user authentication. Finally, we’ll discuss some things you can do to keep your system safe from harm.
Securing Local File Systems
A well-hardened system not only thwarts outside intruders, it also protects against abuse perpetrated (intentionally or accidentally) by any user (whether authorized or unauthorized).
One subsystem that deserves special consideration is the file system. Hardening the file system safeguards the contents and attributes (protection bits, owner, etc.) of every file in the local file system. To secure the local file system, you have to conduct an audit and modify a variety of settings to provide only the minimum access required. (Additional, complementary information about file permissions can be found in this month’s Power Tools column on pg. 40.)
For example, look for inappropriate file and directory permissions, and correct any problems that you find. The most important of these are group- and/or world-writable system executables and directories, and commands that are setuid or setgid. For world-accessible files, change the permissions to be as restrictive as possible. For commands that are setuid or setgid, make sure the command and those permissions are really necessary, and ensure that no unauthorized ones get added (discussed below).
Similarly, you should select mount options that leverage any security features provided by the operating system.
For example, the mount option nosuid disables the setuid bit on every file within the corresponding file system. Isolate non-system files into a separate file system and apply this option (setuid files should not exist except among system files).
Other mount options to consider are noexec (prevents binary programs in this file system from executing — usually this is overkill), nodev (prevent device access via special files on this file system — also useful for non-system partitions), and noauto (do not automatically mount the file system at boot time or with mount -a).
Finally, if you have very sensitive data and you don’t want others to see it, it’s best to encrypt it, taking care to select a long, strong pass phrase. The GnuPG (http://www.gnupg.org) package is a good choice for encrypting important files.
Restrict Local Root Access
Ensuring that only authorized people have access to the root account is another important step in hardening a system. There are several aspects to this task:
- If appropriate, prevent direct root logins from all locations except the system console. This is usually the default installed state.
- Choose and set a secure root password. Obviously, choose a strong pass phrase that is difficult to crack. In addition, devise a scheme for changing the password periodically.
- Restrict the group of people who know the root password to just a few key administrators. Furthermore, restrict the use of the su command to solely that group with the Pluggable Authentication Modules (PAM) system (http://www.kernel.org/pub/linux/libs/pam). There are several ways to accomplish this, but the easiest is to use the pam_ wheel module to designate an “su” group, and place the authorized users into that group.
- Use sudo (http://www.courtesan.com/sudo) or an equivalent package to grant ordinary users limited root privilege.
The sudo configuration file, /etc/sudoers, defines which commands each user is able to run. Figure One shows some sample entries that illustrate how to configure sudo.
Figure One: A sample /etc/sudoers
# Section One: Define named groups of hosts, users, and commands
Host_Alias CHEM = duncan, puck, brutus
User_Alias BACKUPOPS = chavez, vargas, smith
Cmnd_Alias MOUNT = /bin/mount, /bin/umount
Cmnd_Alias BACKUP = /usr/local/bin/star, /sbin/dump
# Section Two: Assign allowed access
# WHO WHERE = WHAT
%chem CHEM = SHUTDOWN, MOUNT
chavez CHEM = MOUNT : achilles = /sbin/swapon
BACKUPOPS ALL, !CHEM = BACKUP, /usr/local/sbin
The first four entries define various lists that are used elsewhere in the file. The second section contains entries that actually grant access via sudo.
In the second section, the first entry lets members of the chem group (as defined in /etc/groups) to use the shutdown, mount, and umount commands on hosts duncan, puck, and brutus. The second entry allows user chavez to use the mounting commands on the hosts in the CHEM list (as defined in the first Host_Alias line), and to use the swapon command on host achilles. The final entry applies to the user list BACKUPOPS (chavez, vargas, and smith), allowing them to use the commands in the BACKUP list on all hosts except those in the CHEM host list. Anyone in BACKUPOPS can also use any commands located in /usr/local/sbin.
Note that you don’t want to permit access to any command that is a shell (e.g., /bin/bash or /bin/tcsh) or that allows shell escapes (e.g., many editors), as this would make sudo equivalent to the ordinary su command.
Configure User Authentication and Account Defaults
Configuring user accounts and user authentication is a logical follow-on step to configuring root access. Decide on user account controls like password aging settings, account expiration, resource limits, host and/or terminal restrictions, and the like. It’s a good idea to set up defaults before adding any user accounts if possible. The various account controls are controlled in various ways, including shadow password file fields and the PAM configuration.
You will also need to set up default user initialization files in /etc/skel or elsewhere. Be sure to include an appropriate definition for the PATH environment variable. Similarly, you will also need to set up the system-wide login initialization files (/etc/profile and/or /etc/csh.*, as well as the files in /etc/profile.d under Red Hat Linux).
In addition, examine the password file for two types of accounts:
- Make sure that administrative and other accounts, where no one should ever log in, have a disabled password and /bin/false or another non-login shell.
- Remove all unneeded, predefined user accounts.
Finally, configure all other security facilities that may be in use for user accounts.
Table One: Where account controls are set
|Item||Configured via||Stored in|
Password lifetimes/aging settings
passwd, chage commands
Host, terminal and similar restrictions
Time of day
Set up Remote Authentication and File Access
Most system administrators recommend that you disable hosts.equiv and .rhosts-based password-less authentication. You may also want to consider disabling rlogin, rsh, telnet, ftp, rcp, and similar insecure remote access commands. Instead, insist that users use ssh for remote user access and the related facilities for file copying.
If you do decide to allow remote access, be sure to configure PAM appropriately for the relevant commands. In particular, make sure that remote root access is not allowed.
Install and Configure Ongoing Monitoring
One of the last steps in the hardening process recognizes that hardening is actually an ongoing task. Once you’ve hardened a system, you need to make sure that it stays that way over time. Thus, before we finish hardening, we must devise and establish a scheme for continually monitoring the system state. The scheme must include both the monitoring procedures and a method for examining the data that monitoring collects. Here are some tasks to consider:
- Install the Tripwire facility (http://www.tripwire.com). Record the baseline data for the hardened system. Afterwards, write the data to removable media, and then remove it from the system. Finally, configure Tripwire to run on a daily basis (or other periodic schedule).
- Install and enable process accounting (the Linux acct package). acct collects a variety of data that can be useful for security investigations. Use the lastcomm and ac commands to view the data.
- Configure the syslog facility by specifying the target location of each message facility and/or severity level. The best practice is to send or copy syslog messages to a central syslog server and to the local host (for redundancy).
You can also use Swatch (http://oit.ucsb.edu/~eta/swatch) to monitor log files and extract useful data from them.
There are a few final things to do to complete the initial hardening process.
- Perform a full system backup. Be conservative: verify the backup media after writing it, and consider making two copies of the backup.
- Consider removing any source code that you’ve placed on the system as you performed installations. Consider removing the compilers (gcc, et. al.)as well.
- Sign up for one or more security mailing lists. The best general purpose list is produced by the Computer Emergency Response Team (CERT). You can add yourself to the CERT mailing list by sending email to firstname.lastname@example.org with subscribe cert-advisory in the body of the message. Past advisories and other information are available from the CERT web site, http://www.cert.org.
- Get in the habit of checking the security pages for your Linux distribution on a regular basis. For example, the relevant Red Hat Linux page is http://www.redhat.com/apps/support/errata/index.html, and the SuSE Linux page in the USA is http://www.suse.com/us/support/security/index.html. The Linux Weekly News (http://www.lwn.net) also provides good security news; it’s published each Thursday.
This concludes our overview of the hardening process on Linux system. Hopefully, you’re systems are safer and you’re a little wiser.
For a checklist version of the information in this series, see http://www.linux-mag.com/2002-11/guru/harden_list.htm.
Æleen Frisch is the author of
Essential System Administration. She can be reached at email@example.com.