How to harden your RHEL 5 servers
While most of the recommendations we're going to review today will apply to nearly any Linux system and many will apply to any Unix system, they were meant specifically for Red Hat Enterprise Linux 5 and are included in a reference card published by NSA that you can retrieve from this URL: http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf
This double-sided tri-fold sheet of tips (select flip on short edge for double-sided printing) was published in June of this year (2012) and covers a wide range of issues. From general principles to kernel parameters, it covers a lot of ground and is well worth the time required to consider each recommendation and why it's important for the security of your system.
Starting with the general principles, we are instructed to Encrypt all data transferred over the network. If you are still using protocols that don't encrypt their connections, user passwords and all commands and information sent over those connections are subject to compromise. It doesn't take a lot of genius for someone to download and use a tool such as Wireshark to capture sensitive information from your network -- unless, of course, it's encrypted.
Minimize the amount of software installed .... The more tools you install, the more vulnerabilities you will have. It's as simple as that. Your options are to restrict the software you install or maintain to what is clearly required or to actively look for vulnerabilities -- or both. The more critical a server, the less tolerance you should have for anything beyond the essential services. Traditional Unix hardening recommendations have long suggested not running any service you don't require. This applies to software applications as much as it does to native OS services.
Use security-enhancing software and tools whenever available (e.g., SELinux and iptables). Iptables is generally installed and running by default on RHEL servers. Don't disable it! The only time I have ever disabled iptables is when, in a pinch, I wanted to determine whether iptables or something else was responsible for a connection failure. Otherwise, iptables is running. It's easy enough to modify your iptables rules and to add new ones as needed. The syntax is fairly simple as is the logic (first matching rule ends the checking). SELinux is another story but, under most circumstances, makes your system safer without adding much if any overhead to your administrative responsibilities. The only time I've had to wrestle with SELinux was when I was trying to share some files via Samba and, oops, the files weren't visible on the Windows side. But just a few commands later, the content that I wanted to share was available on the Windows systems that I wanted to share it with.
Run each network service on a separate server whenever possible. As the tips card points out, this precaution helps to ensure that the compromise of one service doesn't lead to the compromise of others. If you can afford to dedicate a server to each service, this can also greatly simplify the administration of each of those servers.
Maintain user accounts. This principle urges you to both create and enforce a good password policy. The best way to do this is to take advantage of the password complexity settings available on your RHEL servers. Fortunately, that's not hard. You just edit your /etc/pam.d/system-auth file and make sure you've set up some minimum length and complexity requirements so that none of your users can assign themselves weak passwords. In the example below, we're setting up a minimum password length (actually a complexity score) and requiring at least three character replacements when a password is changed, along with requiring an uppercase, lowercase, digit and special character.
password requisite pam_cracklib.so try_first_pass retry=3 minlen=14 difok=3 ucredit=-1 dcredit=-1 ocredit=-1 lcredit=-1
See http://www.itworld.com/endpoint-security/275056/how-enforce-password-com... for more information on password complexity in Linux.
In addition, you should delete or at least disable unused accounts -- preferably as soon as someone leaves your organization or switches to a different project. I go with the disable option whenever it's unclear whether anything in a former user's account might be needed by someone else working on the same project. You can disable an account simply by replacing the hash field in the /etc/shadow file or inserting an additional character into it. This works well when there's some chance you might have to enable the account again for the same user since you then won't then have to issue a new password.
Remember that you have a choice when removing an account whether to also remove the associated home directory. I generally check with the user's manager before removing the user's files, but this decision often depends on how the account was used.
Review system and application logs on a routine basis. This is one of the hardest things to do because logs are so long (and generally horribly dull) and time is so short. Even so, you can review logs without having to read each and every line. You can use a tool like logwatch or build a log review tool using Perl that will highlight the messages that will tell you about the kinds of problems or issues you can't afford to ignore. Reviewing logs can help you to spot problems long before they're beyond manageable. If you only look at your logs when something is terribly broken, on the other hand, you are probably out of touch with how you servers are being used.
I would add to this that you should also review performance measures. As with system logs, performance data -- the kind of measurements that you can get by routinely collecting performance values with sar -- can be a vital part of managing the security of your systems. After all, security isn't just about confidentiality; it also involves availability.
The hardening tips also suggest that you move your log files to a dedicated log server. This would ensure that anyone who breaks into your server can't cover their tracks, especially if you send your log entries to a syslog server directly, rather than transferring the logs periodically. If you maintain a syslog server, you also don't have to give many people access to it and any tools that you use to analyze your log files can be used against a series of log files (presumably from a large group of servers) as easily as they can be run against one.
Never log in directly as root, unless absolutely necessary. This is a no-brainer. Even though those of us who have been traipsing around our systems as root for decades might not like it, accountability is important. If you don't force your sysadmins to switch user to root or, better yet, use sudo to run root-level commands, you just won't know who is using root's power for what and you might not even be sure whether everyone who is using root access is someone authorized to do so. Prefacing commands with "sudo" is a bit more trouble, but you won't have to enter your password for every command and the benefit of knowing who is making changes to your system makes it well worth the trouble.
All that and we're just through the General Principles section. Next week I'll cover some of the more in depth material and add some extra guidance on how you can keep your systems safe. In the meantime, please get your own copy of the "Hardening Tips for Default Installations of Red Hat Enterprise Linux 5" (URL shown on page 1). And, if you're not just a RHEL shop, you can download recommendations for other operating systems as well from links provided on this page:
This is good stuff! Thanks, NSA!