System security is always a trade-off between convenience and features on the one hand and protectiveness and removing unnecessary risks on the other. As the cliché goes, security is inversely proportional to convenience: the easier a system is to use, the less secure it's likely to be. In contrast to many discussions in this column, this month we turn our attention to the "secure if inconvenient" end of the spectrum.
System security is always a trade-off between convenience and features on the one hand and protectiveness and removing unnecessary risks on the other. As the cliché goes, security is inversely proportional to convenience: the easier a system is to use, the less secure it’s likely to be. In contrast to many discussions in this column, this month we turn our attention to the “secure if inconvenient” end of the spectrum.
As installed in “normal” mode from most current distributions, Linux tends to be a feature-rich yet very insecure operating system. For example, some distributions install an active Web server by default. While this is very convenient — the system can start serving files almost immediately and Web-based administrative tools will work right away — it also exposes the system to many sorts of security threats. If a very secure system is your goal, then there’s still a lot of work to be done.
The process of modifying a system to make it highly secure is known as hardening. This month, we’ll begin considering how to harden Linux for an environment with high security requirements (for example, a system functioning as a firewall). Every step we discuss may not be necessary for every system (or site), but knowing about all of them will enable you to apply the ones that are relevant to you. Furthermore, we’ll perform the entire hardening process manually to gain the most insight.
Be aware that the order of activities in this discussion is not rigorous, and actual task ordering would need to considered carefully prior to making any changes to a system.
We will consider the hardening steps in groups of related activities: preliminary planning and preparation (what to do before you get started); securing the physical system (restricting physical access to the system and its components); installation (installing Linux and system software, including all security patches); securing services and daemons (configuring daemons to reduce security risks); securing local file systems (assigning appropriate permissions and removing insecure items); restricting root access (limiting root access to the system console and a small group of administrators); configuring user authentication, including remote access (specifying how users must authenticate themselves when they log in); setting up remote access (specifying user authentication from remote systems as well as other network-based access control); setting up ongoing system monitoring (these facilities allow you to detect any unauthorized changes to the system); and additional activities needed to complete the hardening process.
Before we begin, there are two important points to remember:
Hardening activities must be performed before the system is placed on the network. Why? Because any system attached to a network prior to hardening has a chance, however small, of already being modified. You must begin the hardening process from a known, good system state. You must reinstall the operating system before you harden an existing system.
Successful hardening is based on a least-privilege security model. The system should be open only as much as is needed to function properly. Similarly, users should be given the minimum amount of access that they need.
As with any major undertaking, it’s only common sense to plan what will be done before modifying the system. You may also find it helpful to rehearse your particular hardening process before applying it to production systems. Doing so will enable you to test your actions and verify that they have the results that you intend. Rehearsing may also allow you to identify and address any unexpected side effects of the actions you are taking.
Here are some of the decisions to make before you begin to modify your system:
Decide how you will partition the disks on the system, and where various file systems will be located. File systems provide natural security boundaries that you can take advantage of. On a secure system, isolate operating system files from all user files by placing them on separate file systems.
Decide what software will run on the system. This will, of course, be determined in large part by the system function (e.g., a DNS server will need to run named). You will also need to be aware of the relevant software dependencies (e.g., an NFS server must run the portmap daemon).
If appropriate, plan the system’s user account and group structure. Create groups when you need to grant access to a system resource to multiple users.
Another important preparatory task is to acquire and gather together all of the things that you’ll need to install and configure the system. These include any software packages you typically install at your site, the media for the Linux distribution, and all of the security patches released since the media was created (in most cases your Linux vendor will offer such patches from their web site). However, it’s also helpful to check an independent source of security vulnerabilities like CERT (http://www.cert.org/nav/index_red.html) for a list of recently discovered security problems.
Finally, it is important to take notes as you go, documenting the hardening process. Notes will be helpful for you in the future (you’ll know exactly what you did) and for refining the process for other systems.
Documentation can also allow other system administrators to understand the system’s configuration and apply the hardening process to other systems.
Secure the Physical System
When you’re ready to proceed with the hardening process, the first thing to decide is where the system will physically live. In general, important and sensitive systems should not be placed in publicly accessible places because any one with physical access to the system will be able to compromise it.
For example, access to the system’s CDROM (or even floppy) drive may allow someone to boot an operating system of his choosing and then freely examine the system’s hard disks (more on this in a minute). In addition, an accessible system can be stolen, a risk that may be unacceptable when there is sensitive or valuable data on the system. Finally, systems that are accessible are also vulnerable to vandalism, and damaged servers can’t fulfill their functions.
You may also need to consider these issues related to the system’s physical security:
Ideally, the system will be protected with a locked door. However, cheap locks are not much better than no locks when theft is a risk. In addition, locks are not sufficient when there are other ways of getting into the area (like windows). Don’t forget to secure network devices and cabling. Accessible network cables are vulnerable to tapping and eavesdropping.
Select a location where the risks of accidental damage to the system is minimal (e.g., no overhead sprinkler systems).
Install an uninterruptible power supply for the system, if appropriate.
Once the system is set up, the next thing to do is to assign a BIOS password to it. This will prevent unauthorized people from changing the computer’s BIOS settings. After the operating system is installed, you’ll need to remember to modify the set up to disallow booting from the CD-ROM and floppy drives.
Install the Operating System
The next steps involve installing the Linux operating system and the rest of the required software. It’s much easier to harden a system when you’ve installed the operating system yourself because you know exactly what it includes.
One recommended practice is to install a minimal operating system configuration, the minimum necessary to boot the system. Then, go on to install the additional packages you need from the installation media. This practice results in a final installation that has only the items that you really need. The logic behind this is that intruders can’t exploit security holes in software that’s not installed.
Next, you’ll need to apply all of the security patches that you’ve gathered together. In addition, upgrade any packages where newer versions close security holes. Once you have configured, updated, and built all the required packages, backup the source code, and then remove it from the system.
Once the software is installed, the next step is to build a custom kernel for the system. Your custom kernel should disable any feature that’s not needed (once again, intruders can’t take advantage of features that aren’t there). For example, for systems that are not operating as routers, you should remove IP forwarding capabilities.
Figure One shows some of the items you might want to consider disabling when you’re not using the corresponding device types or features (listed as they are described in the make xconfig utility):
Figure One: Kernel features that you might want to disable
Code maturity level options
Prompt for development and/or incomplete code/drivers = n
process accounting = y (needed for system monitoring)
support for a.out binaries = n
Binary emulations of other systems
all items that you are not using to n
port IDE device support = n
IP: multicasting, IP: advanced router and Wan router to n.
Set all unused protocols to n: IPX, Appletalk, Decnet, all experimental protocols
Network device support
PLIP, PPP, and SLIP to n
IrDA (infrared) support
the main item to n if you’re not using the IR port.
Set all unused file system types to n. Likely candidates include: ADFS, Amiga FFS, BFS, UMSDOC, EFS, JFFS, JFS, NTFS, OS/2, QNX2.
File systems — Network file systems
all unused types to n: Coda, NFS, SMB, NCP
If you’re using NFS, enable NFSv3 support, and enable server support only if the system will export file systems.
debugging = n
Once you’ve configured the new kernel, build and install it and all associated modules. Boot the new kernel and make sure that it has all the functionality you need. Backup the default installed kernel and modules (save /boot and /lib/modules), and then remove them.
Similarly, backup the kernel source code directory (conventionally /usr/src/linux) and then remove it.
The final steps in this group involve configuring the system boot process:
Configure the boot loader (LILO or Grub) for automatic booting, disallowing any boot time user intervention. The boot loader should also be configured to require a password. For LILO, this would mean removing the prompt keyword and using the password keyword within the lilo.conf configuration file (conventionally located in /etc). For Grub, you would use the hiddenmenu, default 0 and password keywords within the Grub configuration file (usually, /boot/grub/grub/conf).
Require the root password to be entered when entering single user mode by adding the following line to /etc/inittab: sp:S:respawn:/sbin/sulogin
You may also want to disable the ctrlaltdel inittab entry (just comment the line out with #)to prevent that key combination from ever triggering a reboot.
That’s all for this month. Next month, we’ll continue our look at system hardening by considering ways of securing the many daemons that are present on Linux systems.
Æleen Frisch is the author of Essential System Administration. She can be reached at firstname.lastname@example.org.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62