James Stephens

Iptables is the firewall and packet filtering replacement for Ipchains in the Linux 2.4 kernel and beyond. It is part of the netfilter project. Iptables has many more features than ipchains and is also structured more sensibly. Points of note are as follows:

• Connection tracking capability, via the ability to do stateful packet inspection. This works for icmp and udp as well as tcp connections. For instance, stateful icmp filtering allows you to only allow an icmp echo-reply in if an echo-request went out. This is something you couldn’t do with ipchains ……. most people would block echo-requests but blindly accept echo-replies with the assumption that they would always be in response to their own pings. Not true. Unsolicited echo-replies can be a sign of a Smurf amplification attack, a Tribe Flood Network communication between master and daemon, or a Loki2 back-door.
• Simplified behaviour of packets negotiating the built-in chains (INPUT, OUTPUT and FORWARD). On multi-homed hosts, packets travelling between interfaces negotiate only the FORWARD chain rather than all three built-in chains as they did before (providing packet forwarding is enabled of course).
• A clean separation of packet filtering and network address translation (NAT). This is very nice; in Ipchains masquerading was done as part of the packet-filtering, but in Iptables masquerading is treated as a particular type of source NAT (SNAT) as it should be. Redirection, in turn, is treated as a particular type of destination NAT (DNAT). SNAT is done after routing and DNAT is done before routing, which makes it easy to define your rulebase and add NAT as an afterthought.
• Rate-limited connection and logging capability. Now you can limit both connection attempts, as in SYN-flooding attacks, and also prevent your logs being flooded, as happened in the Jolt2 fragment driven attack against Checkpoint’s Firewall-1. Another very nice feature.
• The ability to conduct packet filtering by tcp flags and tcp options, MAC addresses, and even by time of day.

How does it work?

The short answer is that user-defined tables for packet filtering, nat, packet mangling etc. hook into kernelspace chains (INPUT, OUTPUT, FORWARD, PREROUTING and POSTROUTING. Packets negotiating these kernelspace chains get filtered according to the rules in the tables. You might learn a litle more by clicking through the slides from an Iptables seminar I once gave at Princeton University.

Connection tracking is an area I have become quite interested in. See these posts for more detailed explanations of connection tracking in Iptables:

Connection Tracking - TCP
Connection Tracking - UDP
Connection Tracking - ICMP
Connection Tracking - FTP

Example Rulesets

Iptables example firewall rulesets are available “here”.

If you are keen to get hands on with configuring Iptables, “this post” looks at an affordable way to do it if you don’t already have access to a Linux box. In either case, be prepared to do some traffic analysis in order to debug any problems with the ruleset.

Recommended Reading