This post is going to focus on building and applying a Host Firewall using the IPTables functionality that is built into Linux. (If you are already lost, try googling “securing linux with IPTables”, and check out the resources section below.)
Please note: This Secure Your Linux Host series is very hands-on. The tools and tips that will enable you to use a Host Firewall are coming, but let’s lay the foundation for using them first…
What is a Host Firewall?
When the concept of Firewall is mentioned, the most common meaning that comes to mind is a network services control between networks. Over 90% of the information that you can find on Firewalls is targeted at people who want to protect systems on one network (such as their corporate or home LAN) from systems on another network (generally the internet), while permitting a list of known services to be accessed by one network from the other. There are in fact several effective strategies for using Network Firewalls as boundaries between networks, or network segments. For a detailed introduction (or tune up) on this subject, please refer to the NIST document in the resources section below, or click here for a great SANS introduction.
A Host Firewall is different in that it exists to protect and control access to a single system from all others. Common scenarios a Host Firewall is well suited to address:
- Host is in direct contact with the Internet (or other hostile network)
- Host is located in a DMZ
- Host cannot trust systems on its network segment
- Host has high control expectations due to legal, regulatory, audit, or risk requirements
If you have servers that are hosted in a data center or directly connected to a broadband/DSL connection and, as a result, are in direct contact with the internet, then I highly recommend configuring a Host Firewall. Systems that are in this situation will be attacked from other systems all over the globe all of the time. There are so many attackers who are running probing scans across the entire network space of the Internet that you will get scanned. The recent log information that I supplied on http scans and ssh password attempts is an example of how any host (no matter how insignificant) will be regularly attacked.
OK – so what if the host is behind a firewall in a DMZ with other hosts (such as the www and SMTP, hosts in this illustration)? Most DMZ networks do not provide protection against attacks from other “peer” hosts in the DMZ. The problem that this presents is that, in the event that one host in the DMZ becomes exploited, then it can be used to probe and attack all of the hosts in the DMZ. Even worse, if a single host in the DMZ falls prey to a Worm or other self-propagating threat, then all similar hosts in the DMZ can be rapidly infected.
The “Host cannot trust systems on its network segment” argument for a Host Firewall is almost identical to the DMZ argument. Why provide access to services on the box to systems that do not need them?
The last point is about high-risk or highly-regulated systems. The rules on a Host Firewall are much simpler to review and understand (but perhaps not manage) than the rule set on a network boundary Firewall. This can have two major advantages. First, it can make it much easier to provide complete and frequent reviews of the Firewall rule set. Second, it can remove confusion, limit scope, and simplify formal audits of the network access that the given Host has.
Isn’t Linux Secure by Default?
Many Linux distributions and commercial operating systems advertise that they ship in a “fail safe” or at least “start safe” mode; let’s assume that to be the case. When you install any operating system, the first thing you do is start installing software and applications. With each application that you install, you may be exposing services to the network.
With a Host Firewall, you will know precisely what services you are and are not exposing. As you know from Part 1, I run a Mail Transfer Agent so that email to root, events, etc. is in fact delivered to an email account I actually use. Running a Host Firewall dramatically raises my confidence that I am not a SPAM relay – sure, I think I configured the MTA properly… But with the Host Firewall I know that only services on my host (via 127.0.0.1) can send email. Running a LAMP server provides a very similar situation. With the Host Firewall in place, I know that MySQL isn’t accessible on its native ports to the world.
So, What is the Downside?
The reason that more systems are not running a Host Firewall is a lack of management tools. If you have a small number of hosts that you are administrating, then adding and managing a Host Firewall is not much work at all. But, if you have a hundred servers with a mix of operating systems, split into several data centers, suddenly managing Host Firewalls is not only a nightmare but may be causing more operational risk than is acceptable.
Every modern operating system (Linux, Unix-*, Windows, System/Z, openBSD, etc.) comes with a built in Host Firewall capability. What is needed is tooling that enables both centralized management and harmonization with network boundary Firewalls. (Unfortunately, I won’t be able to provide that in this series!) The vendors with the best management of the network boundary Firewalls tend to be the manufacturers of those Firewalls, and they would be the most logical group to expand their existing management capabilities into the Host Firewall space. But, I do not think that anyone has developed a revenue model to justify that as worth the investment. (Hope springs eternal!)
In the next installment, I am going to walk through the actual artofinfosec.com Firewall. (No B.S. “Security Through Obscurity” here!) And then in the following segment, I am going to discuss tools for monitoring and adding countermeasures to the Host Firewall.
This is a great introduction to building a Host Firewall. (The html site version seems like a paraphrase of the Sun Blueprint document pdf.) It is a resource that I return to time and again. The firewall example provided here includes full egress control, and the article walks the reader through the firewall step-by-step. The description is for a very controlled Host Firewall, so controlled that I in fact found myself moving to a simpler implementation.
- NIST: Guidelines on Firewalls and Firewall Policy (pdf)
The NIST documentation (as usual) provides a great 360-degree medium-depth introduction to the topic. If you currently, or are about to, manage firewalls as part of your network security function, then read this guide!
Pingback: Interesting Information Security Bits for 02/25/2009 | Infosec Ramblings