October, 2003

Firewalls: Doing It Yourself

Can an open-source solution adequately replace a commercial product? We compare iptables to FireWall-1 to find out.


Enterprise-class firewalls, such as those made by Check Point Software Technologies, Cisco Systems and NetScreen Technologies, have long been marketplace commodities. Out of the box, they provide reliable, relatively easy-to-use security solutions. And the vendors also provide 24/7 support and ongoing maintenance. The problem with commercial firewalls is that they are expensive. Open-source firewalls, such as iptables, a freeware Linux tool developed by Netfilter, aren't nearly as easy to use, but they're quickly catching up in features and functionality. And price? Well, that's hard to beat. iptables boasts many features normally only found in commercial firewalls, including packet defragmentation, rate limiting, packet content inspection and protocol state tracking. Some security managers may ask, "Is iptables capable of replacing commercial firewalls?" To find out, we compared iptables to Check Point's FireWall-1 running on Nokia IPSO in six areas: packet filtering; policy management; integration of VPNs, NAT and routing protocols; performance and scalability; and maintenance and support. Here's how an iptables firewall stacks up.

Packet Filtering FireWall-1 set the standard for firewall functionality when it hit the market 10 years ago, giving users the ability to filter IP packets based on flexible, admin-defined security policies, and perform protocol state tracking. iptables meets this requirement, but not with the same ease as FW-1. iptables' rules can filter packets based on protocol, port number, specific network interfaces and IP addresses. It can also filter based on arbitrary combinations of TCP flags, protocol state, time to live (TTL) value, packet fragments and more. It's stateful and able to perform packet rate limiting. It can log sufficiently detailed information about packets traversing the firewall, which is useful for intrusion detection. FireWall-1 set the standard for firewall functionality when it hit the market 10 years ago. iptables meets this requirement, but not with the same ease as FW-1. iptables' packet filtering is generally as functional as FW-1. However, its rule language isn't as flexible as that used by FW-1. It has no notion of a network or service "object," which makes for longer rule sets. FW-1 also has the ability to specify encryption within policies and its application to traffic traversing the firewall. iptables has no built-in encryption support (although this can be added with FreeSWAN-more on this later) iptables generally logs more information than FW-1, via syslog to an ASCII file. This format makes logs easy to analyze by automated parsers. Unless reconfigured to log via syslog, FW-1 logs everything in a proprietary format.

Policy Management One of the things that made FW-1 an overnight success is its GUI, which made deployment, configuration and maintenance relatively simple. The GUI took tasks like setting security policies and access control lists (ACLs) away from engineers and placed them in the hands of ordinary admins. Like most Linux applications, iptables is configured and managed through a command-line interface. This makes iptables less accessible to non-Linux gurus. However, Firewall Builder, an open-source tool, implements an attractive GUI for iptables that allows drag-and-drop operations to edit policies constructed from a database of network objects in a manner similar to Check Point. Additionally, Firewall Builder can securely deploy a new iptables policy on a remote firewall over SSH via a simple shell install script. While Linux gurus will find iptables easy to use, and the add-on GUI makes management easier, FW-1's well-established GUI is more functional than either of the iptables interfaces.

VPNs, NAT and More Firewalls are frequently called upon to perform essential networking and security functions, such as secure remote connectivity, network address translation (NAT), failover and, in many cases, the ability to speak routing protocols. FW-1 has incorporated NAT and VPN as standard features, but doesn't provide routing or failover capabilities. (Note: FW-1 does provide a method for synchronizing the state table to avoid dropping sessions, even if the master firewall must be failed over to a backup. This isn't implemented in iptables). iptables has a built-in NAT implementation, but doesn't provide VPN, routing or failover. However, tools are available to give iptables enterprise- class functions.

IPSec-compliant VPN. FW-1 comes out of the box with VPN-1, giving it a clear advantage over iptables. iptables users can integrate an IPSec-compliant VPN with FreeSWAN, an open-source product of the FreeSWAN Project. FreeSWAN can terminate a VPN tunnel with 27 different IPSec clients--including FW-1. Configuring FreeSWAN is complex compared to FW-1, since it uses the notion of "left" and "right" RSA keys and subnets. This isn't a tool for uninitiated Linux users.

NAT. iptables has a complete NAT implementation that allows both source and destination NAT functionality. Masquerading a Class-B network behind a public IP is easy through a single iptables command. Functionally, it works as well as FW-1.

Routing. Both FW-1 and iptables lack routing capabilities. In our comparison, FW-1 uses ipsrd on the Nokia IPSO to route protocols, which is managed through a Web interface. iptables can use the Zebra routing daemon for protocol routing on an iptables gateway. Zebra supports OSPF, along with many other protocols, such as BGP, IGMP and RIP. The interface to manage Zebra on a Linux system is similar to Cisco IOS, complete with an "enable" mode and context-sensitive help.

Failover. Both FW-1 and iptables require additional software for failover. FW-1 relies on IPSO's VRRP support, whereas iptables uses Keepalived, an open-source implementation of VRRP. Keepalived's configuration is easy through the notion of a VRRP "sync group," in which all monitored interfaces are placed. All interfaces in the sync group on the master virtual router will fail to the backup state should a link status change on any particular interface. All state changes are logged, and Keep-alived can send an e-mail alert when a change occurs.

Performance and Scalability A firewall must be able to inspect all inbound and outbound packets without reducing traffic speeds, and scale with increased bandwidth utilizations. Here's where iptables has an advantage over FW-1. The Linux IP stack is built for performance and scalability. iptables provides packet- filtering capability on top of the Linux stack. With sufficient hardware, iptables will keep up with the volume of packets thrown at it. FW-1 on Nokia has excellent performance, but overall FW-1 performance varies depending on the host hardware platform and OS. Further, scalability is hampered by the cost of new equipment, software licensing and support. Versions of FW-1 can run on low-end x86 hardware, but these obviously won't have the same performance as the customized Nokia boxes. With the low cost of x86 hardware, purchasing a system to allow iptables to filter packets on a saturated 100 Mbps link is relatively cheap (under $1,000). The license costs alone for FW-1 on networks with more than 100 internal hosts are in the tens of thousands of dollars. Where iptables can't compete is in manageability. FW-1's GUI allows for easy creation and distribution of rules to multiple firewalls in distributed environments. iptables is strictly a one-to-one architecture, making it less scalable in large, distributed environments.

Ease of Maintenance Firewalls regularly require patches to mitigate security vulnerabilities and to deploy new features. Installing new software is harder on iptables than on FW-1, but not by much. iptables can be recompiled and upgraded at any time without affecting a running iptables firewall. The same is true for the Zebra routing daemon and Keepalived. However, upgrading the kernel portion of iptables is another matter. A new kernel can be compiled and installed without having to take a firewall out of service, but making the new kernel active requires some downtime to reboot. In any case, it's a good idea to have a backup firewall to cover while the primary is rebooting. Upgrading FW-1 on Nokia IPSO is done with the "newpkg" command, whereas upgrading iptables on Linux requires manual compilation and installation. The compilation process for iptables may not be as seamless as using newpkg, it's easily mastered by anyone who's familiar with the general compile/install process for Linux systems.

Support Cost considerations aside, most enterprises welcome software and maintenance support, especially for critical systems such as firewalls. Check Point and other vendors provide subscription-based support, which includes patches and technical assistance. Not so in the open-source world. The lack of 24/7 on-call support is often the biggest stumbling block to adopting iptables and other open-source solutions. While there are no Maytag repairmen waiting by the phone for iptables, there's a devoted user community that actively supports and improves the iptables code. Can the open-source community provide equal or better support than commercial vendors? Through grassroots collaboration and quality control, Linux supporters will often develop patches for security vulnerabilities within hours of a flaw being discovered. In contrast, commercial vendors sometimes take weeks to produce a fix. Additionally, several commercial vendors--including IBM, Oracle and Red Hat --are starting to offer support contracts for Linux, so it's not impossible to purchase support for open-source software. However, purchasing support specifically for iptables is difficult. In worst-case scenarios, enterprises can apply their own fix. The source code to iptables is readily available, so an enterprise can craft homegrown patches and workarounds until a fix is posted. While this requires a certain level of in-house coding sophistication, open-source code sometimes provides enterprises with more flexible security remediation options than commercial, closed-source solutions. Bottom line, a support contract obligates a vendor to be responsive, whereas no one in the open-source community is obligated to provide support.

Capable, But Not Ready for Prime Time Our comparison found that the commercial firewall still triumphs over the open-source alternative. With a few tweaks and additional freeware tools, iptables can provide nearly the same functionality and features as many commercial firewalls--at a substantial savings. Deploying an iptables firewall may make sense for companies that have competent Linux admins, but it's not for everyone. The initial installation, as well as the care and feeding, is more complex than that of a commercial product. Also, a decision must be made between paid support contracts and trusting that the open-source community will solve a problem. Still, for those looking to save money on licenses and support contracts, and are willing to dedicate themselves to making an open-source solution work, iptables provides the key functions found in commercial versions. As iptables and the open-source community mature, iptables may one day rival its commercial cousins as an enterprise firewall solution.

MICHAEL RASH is a senior security engineer at an ASP. He is a contributor to the Bastille Linux and manages his own iptables log analyzer project, psad.