Some iptables modules you probably don’t know about
I admit it, at the beginning of Rusty’s presentation on iptables years ago, I think it was at the Linux Expo or Raleigh back in the ’90s, I thought: “Just what we need, another network filtering system.” This was shortly after we made the change from ipfwadm to ipchains with little benefit (in fact, some lack of functionality, IIRC) and a re-learning. Rusty won me over pretty quickly though…
One of the big features that made it easy to swallow iptables was that it included backwards compatibility with both ipfwadm and ipchains. It also included, as the name suggests, tables, where you can branch off and handle packets by groups. For example, I have a table for detecting bogons (addresses like 192.168.0.0/24 and 10.0.0.0/8), and just have one rule in my main tables that jumps to the bogon check. In other systems, like FreeBSD’s ipfw, you can use gotos, which work about as well as they do in programming.
Another nice thing about iptables is that it has a plugin architecture for adding functionality. This has been used to great effect for things like firewalling weird application-specific protocols like FTP, marking packets or handing them off for shaping, etc… For example, one I mentioned yesterday was “hashlimit” to help protect from SSH attacks.
Let’s look at a few other interesting modules for iptables. Some of them are built-in to the stock kernel, others have to be patched in (requiring a rebuild of iptables in some cases as well as the kernel).
condition (patch?)
With condition, you can easily enable or disable a rule from a script by writing to a file under “/proc/net/ipt_condition”. For example: “iptables -I INPUT -m condition –condition killnet -j DROP”. Then if you “echo 1 >/proc/net/ipt_condition/killnet” the input chain will start dropping packets. Then “echo 0” will re-enable input packets.
connrate (patch?)
This includes a “–connrate min:max” and matches when a connection (managed by the conntrack module) is within the range. An optional “!” can appear before the rate to invert the sense of the match. You could, for example, start dropping packets if a particular connection is above a certain rate, for example.
iprange (built-in)
The iprange module allows you to specify source and/or destination addresses as ranges. While the built-in “-s” and “-d” will take a netmask, this can work with an arbitrary range of addresses, for example: “iptables -I INPUT -m iprange -s 192.168.1.5-192.168.1.100 -j ACCEPT”, that isn’t an address range that can be specified by “192.168.1.0/25” sort of syntax.
length (built-in)
Match a rule based on the packet length as a range.
limit (built-in)
Limit a match based on a rate and burst rate. For example, logging can be handy but also offers the opportunity for a denial of service by hitting your logs hard. “iptables -A INPUT -m limit –limit 10/min –limit-burst 30 -j LOG –log-prefix « Dropping:” would add a log target to the end of the input chain. This will log up to 10 messages a minute, with initial bursts of up to 30 messages. You’d normally use this at the end of an INPUT chain which has a default REJECT or DROP policy.
mac (built-in)
A rule which matches based on the MAC address the packet came from. For example, you could allow packets which have your name server’s IP on them, but come from another MAC address (one way of spoofing packets).
