Make Money

With IT budgets getting tighter, managers need to trim costs. Service contracts are expensive for any technology; firewalls are no exception. Netfilter, the project that provides the packet filtering program iptables, is a free firewall alternative. While it lacks the service contract of commercial solutions and a pretty interfaces to make firewall modification easy, it has solid performance, performs effectively at firewalling, and allows for add-on functionality to enhance its reporting and response functions.


As a case study to demonstrate the feasibility of iptables as an enterprise firewall, consider the network I manage at University of Illinois at Urbana-Champaign. The network supports 2,000 devices and has a 1-gigabit uplink with two firewall zones (DMZ and secure). Daily bandwidth outbound averages around 100 gigabytes. The network is protected by two dedicated firewall machines running iptables, each with three network cards (two for the bridging firewall, one for management access), and each running 1.5GHz single-core processors with 1GB RAM. Processing power is not critical in this case; you could save money by using a machine with a lower-end CPU.

We experience no latency attributed to the firewalls, and they do as good a job as can be expected of blocking bad traffic. Once the firewalls were properly tuned, we saw no downtime due to software issues.

There are, however, a couple of "gotchas" to keep in mind. The connection table can get filled on firewalls that are routinely being scanned or are on high-traffic networks. To solve this problem, increase the net.ipv4.ip_conntrack_max kernel parameter (mine is currently at 131071) and decrease net.ipv4.tcp_keepalive_time (3600 is a good choice). As long as the firewalls have plenty of memory to spare, these settings should not pose a problem, and the firewalls will happily run without needing any hand-holding. The result is a firewall with no packet loss and unnoticeable latency that's highly available (assuming good hardware).


Effectiveness at filtering traffic according to policy

A firewall is only as good as its ruleset, no matter which firewall you are using. The rules for iptables are generally easy to understand. Here is an example rule:

iptables -A INPUT -m state -p tcp --dport 80 -s 192.168.5.0/24 --state NEW,ESTABLISHED,RELATED -j ACCEPT

This command adds (-A) an input rule (traffic going to the machine the firewall is on) that checks state (-m) for any new, established, or related traffic from the 192.168.5.0 subnet on port 80 (Web traffic). If you want to log dropped packets (and you should) you also have to create both a DROP rule and a REJECT rule just to handle the logging.

You can block malformed packets (i.e. packets which may be part of a SYN scan) easily with rules checking just the TCP header flags. Other tools such as fwsnort allow for more detailed packet inspection to block clearly malicious traffic. fwsnort converts Snort rules into iptables rules that embed some IPS capability into the iptables. However, iptables allows for easy addition of IP address blacklists to stop all traffic from known hostile netspaces. Once you're familiar with the conventions for writing iptables rules and you have a basic knowledge of IP headers, you'll find it easy to write new rules.


Add-on functionality for reporting and active response

Several add-on tools can help you get more out of iptables log data. Most standard system log scanners can be configured to pull out interesting information, but they certainly aren't designed for that purpose. psad can be configured to provide email alerting on apparent attacks above a certain threshold, and to actively block hostile IP addresses once a defined threshold has been met.

You can perform additional management of the connection tables with the conntrack-tools from Netfilter. This software allows command-line access to the connection tables and allows for grabbing statistics on that information. Lastly, you can set up firewalling up to layer 7 (the application layer) with l7-filter. For instance, an academic environment could use l7-filter to limit peer-to-peer traffic bandwidth as a way to cut back on those fun MPAA/RIAA cease-and-desist letters.

On the downside, because iptables doesn't do the heavy lifting of making rules for you like commercial firewall appliances, it requires users have a more in-depth understanding of firewalling. While tools such as Firewall Builder and KMyFirewall making configuring iptables more user-friendly, a security admin will have to learn about firewalling and the applications in general. This means lots of time and up-front testing.

There is also the problem that when things break there is no one to call to fix it. This requires that knowledge be cultivated in house. However, information on open source solutions tends to be in the public domain, so training costs tend to be a factor of time and perhaps buying some books at Amazon.

At the end of the day, organizations can gain tremendous cost savings by using iptables for firewalls. An added bonus is the additional flexibility that an open source solution provides.

Article written By John C. A. Bambenek, he is a handler at the Internet Storm Center and a security administrator at the University of Illinois at Urbana-Champaign. He has written numerous articles on security, contributed to several computer security courses, and recently contributed the chapter out "Botnets: Proactive System Defense" to the book Botnets: Countering the Largest Security Threat.

Labels: firewall, linux