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

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.

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:

#!/bin/sh

PATH=/usr/sbin:/sbin:/bin:/usr/bin

#FLUSH PREVIOUS TABLE ENTRIES
iptables --flush

#CHANGE DEFAULT POLICIES FROM
#ACCEPT TO DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

#ALLOW LOCAL LOOPBACK TRAFFIC
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

#ALLOW ESTABLISHED CONNECTIONS
iptables -A INPUT -m state --state \
ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state \
ESTABLISHED,RELATED -j ACCEPT

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

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

#SSL - 443
iptables -A INPUT -d 192.168.1.2 -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

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.