The Tao of Linux Security: the Five Phases of a Secure Deployment

Start on “the Path” to a more secure system.

SSH is the standard remote access protocol in use on Linux systems today. In its default configuration, it has some settings that you definitely need to lock down. Add the following lines to /etc/ssh/sshd.config:

PermitRootLogin no
X11DisplayForwarding no

The first line prevents root from logging in to the server via SSH, which never should be done. The second line disables X forwarding, which would allow users to launch an X session from your server. In the example case, X isn't installed, so this should not be a problem. You could lock down SSH further by chrooting it or using TCP Wrappers; however, due to space constraints, I have omitted those configuration steps.

iptables Firewall

Rather than go into a long discussion on the proper configuration of a a firewall, I have created the following script with comments to secure the Debian system. It restricts traffic (statefully) only to new SSH, HTTP and SSL connections. Change the IP address in this example to your server's address. For more details on the options available in iptables, consult the man page. When building your own firewalls, keep in mind the goal of shrinking the attack surface by opening only necessary ports in iptables:



iptables --flush

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -m state --state \
iptables -A OUTPUT -m state --state \

#SSH - 22
iptables -A INPUT -d -p tcp \
--dport 22 --sport 1024:65535 -m state \
--state NEW -j ACCEPT

iptables -A INPUT -d -p tcp \
--dport 80 --sport 1024:65535 -m state \
--state NEW -j ACCEPT

#SSL - 443
iptables -A INPUT -d -p tcp \
--dport 443 --sport 1024:65535 -m state \
--state NEW -j ACCEPT

Save this script locally, and copy or move it to the /etc/network/if-up.d directory so that it runs when the network comes up after boot. If you want to apply this configuration on a Red Hat-based system, you simply could run the above script and use the iptables-save command to keep the rule set across reboots.

Although you could take these steps and many more, there is a tool that makes this process much easier, Bastille (Figures 7 and 8). Bastille uses question/answer responses to script your preferred security settings and apply them to the actual system. There also are a multitude of manual security checklists available for most distributions and applications that can be found on the Internet. Some of the best checklists are the benchmarks put out by the Center for Internet Security. These benchmarks contain detailed settings and descriptions of “best practices” relating to specific operating systems and popular applications. They are excellent companions to Bastille.

Figure 7. Bastille in Debian

Figure 8. Bastille in an X Window System Fedora Environment

Phase 5: Monitoring/Auditing

The last phase of the tao is an ongoing process. Regular monitoring of your system will verify that your security goals are being met over time. The most useful tool for this is built right in to the system, syslog. From the /var/log/messages file, you can view a variety of security-related information for both the system and some applications. Many applications use their own log files. Be sure to look through those as well. If you have multiple systems, you should use a central syslog server to collect the logs. This easily can be configured in the syslog.conf file.

A newer alternative to syslog is called Splunk (Figure 9). Splunk has both free (limited to 500MB daily) and enterprise versions. The nice thing about Splunk is its super-easy install, and you can search through logs using Google-like commands through a streamlined Web-based interface.

Figure 9. Splunk is one of the best and most useful open-source projects available.

As useful as logs are, they do not provide a complete picture of how well your security is working. Only regular auditing can accomplish this. Doing so tells you if your security is still in place and functioning. I am not suggesting penetration testing for every system, but active testing of your settings is good insurance. Create checklists or scripts to test those settings that are important to maintaining your security goals. In lieu of a checklist, you could run Bastille using the --assess switch to get a security report of your current configuration. You also can use the CIS benchmarks (which rely on Bastille) as baseline checklists for an audit. If you can afford it, have an outside consultant come in and verify your security with his or her own tests to give you peace of mind, especially if you work in a heavily regulated industry.

Figure 10. The Bastille assessment report gives you a detailed overview of your current security configuration.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Thanks a lot

Geziler's picture

Thank a lot, i thing this is wonderfull