Since the pace of change with Linux is so fast, Linux has not typically been a platform of choice for firewall implementations; while quick progress is good in many respects, it also suggests a lack of stability. But the latest Linux kernel, version 2.4, offers a number of improvements over the 2.2 kernel that make Linux a viable alternative for corporate firewalls. Netfilter, Linux's in-kernel "packet mangling" infrastructure, and iptables, the administrative tool that manages it, represent a substantial improvement over ipchains, the previous option available under the 2.2 kernel. Netfilter offers a much more integrated and capable infrastructure than did ipchains, while iptables offers reasonable backwards compatibility with ipchains and ipfwadm rulesets while still offering administrators the possibility of improving firewall implementations under Linux.

Linux Firewalling
When deciding on a firewall implementation, most Unix-savvy administrators have usually chosen to use ipfilter on OpenBSD for their combination of capabilities and stability, as the capabilities of Linux's packet-filtering infrastructure did not match that of ipfilter. In particular, previous packet filters for Linux were not stateful (meaning that they couldn't relate requests for information and responses to those requests) and didn't offer an integrated interface for packet filtering, address translation, or other packet manipulation. This greatly complicated writing firewall rules and, for common cases, significantly reduced the desired level of security that the firewall could provide.

Ipfwadm, the packet filter for the 2.0 series of the Linux kernel, and ipchains, the packet filter for the Linux 2.2 kernel, were relatively simple tools that did not meet the needs of most corporate networks. They also suffered from a lack of integration; packet filtering, support for common protocols such as RealAudio, and masquerading--as network address translation (NAT) is called in the Linux world) were all handled separately. All of this changed with Netfilter and iptables.

State: What Is It Good For?
Stateless packet filters are simpler to implement, but more complicated to configure, and ultimately much less secure than packet filters that do keep state. From the perspective of stateless packet filters, every packet that arrives is a new packet (with no relationship to any packet that came before or after). Since most useful network conversations have two sides, stateless packet filters need two rules for each kind of network traffic they allow--one for the request and another for the reply.

All network conversations using TCP/IP have a source IP address, a source port, a destination IP address and a destination port. So, to permit client computers on the internal network to browse the Web, stateless packet filters must allow outbound traffic to all computers on port 80 (the common World Wide Web port) and allow inbound traffic from port 80 to all computers on the internal network. Web requests will come from a randomly chosen, high source port on internal machines; consequently, traffic must be permitted to enter the network on all high ports.

But this opens a glaring security hole because almost any process could be running on a high port on a networked machine, including sensitive processes like Network File Sharing (NFS), X Window System, and RPC (remote procedure calls). What's really needed is something that allows responses to the IP address and the port from which a request is made and from the IP address and port to which the request is sent. To do this, the packet filter must keep a state table about pending requests. This is simple to do with iptables.

Netfilter or iptables?
There may be some confusion about the difference between Netfilter and iptables. Netfilter is an infrastructure; it is the basic API that the Linux 2.4 kernel offers for applications that want to view and manipulate network packets. Iptables is an interface that uses Netfilter to classify and act on packets.

Although the Netfilter infrastructure is incredibly extensible, right now there are only four modules built on top of it: the ipchains and ipfwadm backward-compatibility modules (to allow older scripts to work with newer kernels, but without newer features), the iptables system, the connection tracking system, and the NAT system. As its name implies, iptables works on entries in tables (where each table represents a different kind of packet examination or manipulation).

The pre-defined tables for iptables are:

• filter: The default table used for stateful packet filtering
• nat: Used to control NAT (masquerading) to hide source addresses on a privately-addressed (RFC1918) network, and to expose services on that network
• mangle: Used for fancier stuff. Most sites currently won't use this.

A big move
Not every site needs Netfilter and iptables. For sites already using Linux for firewalling, the move to this new infrastructure can be difficult, as it requires administrators to learn the new interface. But it's well worth the effort; the vast improvement in security justifies the move to Netfilter and iptables, especially for sites still using ipchains. And for sites that were previously unwilling to consider Linux as a firewall platform, Netfilter/iptables may be just enough to make them reconsider. OpenBSD is still the reigning king of secure operating systems; the OpenBSD team has spent the last four years auditing the source code of the entire OS. But OpenBSD recently changed its default stateful packet filter due to licensing concerns about ipfilter. So now that the 2.4 Linux kernel offers stateful packet filtering, administrators should revisit the possibility of using Linux for corporate firewalls.

What's your experience with Netfilter and iptables? E-mail Todd or post your thoughts in our Talkback forum below.

Todd Underwood is chief technology officer at Oso Grande Technologies and a contributor to ZDNet Tech Update.