| The principles of system hardening can be summarized with a single maxim: "Unless explicitly permitted, access is strictly forbidden." In other words, the access to any system service or resource should default to none, unless you specifically allow it. This way, you know what you are opening up and why. It is much more difficult to work the other way around because there is always the slight chance that someone important was missed and later turns out to be a costly oversight. So, the general idea is to install only those packages that the system actually needs and open only those firewall ports that are required by these services. That way, potential intruders can't exploit software that isn't present or running on the system. However, removing a package isn't always possible (due to dependencies) or practical. Therefore, at the very least, unneeded services should be disabled. The following general tasks are associated with securing the operating system and its services: Disable or remove all unneeded services. For services that are required, ensure you are running the latest version. Use the secure version of a service daemon wherever and whenever possible. For instance, use vsftpd for FTP services instead of one that doesn't support SSL. Disable or remove all unused user accounts. Keep up-to-date with software updates, for both the operating system and applications, at least in regard to security patches. For SLES servers, you can easily keep them updated using the YaST Online Update (YOU) feature. (Refer to Chapter 2, "Updating the Server," for more details.) Harden the Linux kernel using the grsecurity kernel patch (http://www.grsecurity.net) to prevent attacks that use buffer overflows and the like. A good starting reference is the "Linux Kernel Hardening" article from the SANS Institute (http://www.sans.org/rr/whitepapers/linux/1294.php). Specify logging and access control for all services, allowing only the minimum access necessary. Secure and review these logs regularly. (See "Using a Central syslog Server" later in this chapter for information on securing system logs.) Whenever possible, use chroot jail to run a service in a confined directory. If at all possible, create a special user to run server processes. For example, run named as user named. These accounts should not have shell access; for instance, they should be given /bin/false as the default shell. Restrict access to special system services like cron to system administrators. Restrict access to root. Administrative tasks should be performed using sudo whenever possible. Review and remove unnecessary SUID and SGID applications, such as CD burning programs. Review and ensure no weak file permissions are assigned to critical system files. Remove unnecessary filesystem permissions (such as world-write). Also check for missing sticky bits on world-writeable directories. TIP You can use the following find command to get a list of all world-writeable directories whose sticky bit is not set: find / -type d -perm +o=w not -perm +o=t -print
Remove all compilers (such as gcc and g++) from the servers. After an intruder breaks into a system, he or she will often copy over the source code of a rootkit so a version specific to your server can be built and installed. If you need compilers, such as for software development work purposes, confine their installation to your workstation. Limit the number of daemon processes using the instances directive in xinetd. Setting limits can help prevent some Denial of Service (DoS) attacks. Run a firewall on each server so there are no open ports and the only ports that are reachable are those you specifically allowed. The bastion host should have its own packet filtering and access controls in addition to (and not instead of) the firewall. Run a system hardening script or utility against your server to ensure all bases are covered. One such utility, Bastille, is discussed later in this chapter.
TIP After you have hardened a host to your satisfaction, ensure you document its configuration so that it may be used as a baseline for similar systems. Furthermore, a review of the documentation could point out weaknesses that you may have missed the first time around. In addition, should you need to rebuild the server after a system compromise or failure, this documentation can quickly get you back up and running.
You should periodically use security scanners such as those discussed in Chapter 12, "Intrusion Detection," to verify that your servers are secure, especially after any upgrades or patches have been applied; sometimes a patch may inadvertently open a previously closed security hole. System hardening is not limited to just securing the server operating system and its services. The "system" is composed of more than just the server hardware and the various software packages that run on it. The system also includes all associated networking hardware, such as switches and hubs, that provides access to the server. Therefore, you also need to harden your physical network infrastructure. NOTE In many situations, the weakest links are the users and their workstations. Therefore, proper user training and education are a must. Be aware that many of the system hardening concepts discussed in this chapter are also applicable to client workstations.
|
