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.
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.
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.
|The True Internet of Things||Sep 02, 2015|
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
- The True Internet of Things
- Using tshark to Watch and Inspect Network Traffic
- September 2015 Issue of Linux Journal: HOW-TOs
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- Firefox Security Exploit Targets Linux Users and Web Developers
- Where's That Pesky Hidden Word?
- A Project to Guarantee Better Security for Open-Source Projects
- Build a “Virtual SuperComputer” with Process Virtualization
- My Network Go-Bag