IPTables/Netfilter Recent Module

Wrote myself a module which I called 'recent' to track seen IP addresses and be able to match against them using some criteria. What this lets me do is basically build up a temporary 'bad-guy' list for when people attempt to port scan me and whatnot and then I use the match to drop everything coming from them for a given amount of time. There is also an ipt_recent and access to the code.

Example #1:

# iptables -A FORWARD -m recent --rcheck --seconds 60 -j DROP
# iptables -A FORWARD -i eth0 -d 127.0.0.0/8 -m recent --set -j DROP

Here we are making a 'bad guy' out of anyone who tries to send data to 127.0.0.0/8 on our eth0 interface (which should never legitimately happen). The first packet will make it past the first rule and then be caught by the second rule and that address will be put into the recent list and the packet dropped.

Any subsequent packets for the next 60 seconds that show up from that address will be dropped, regardless of destination address, destiation port, etc.

Example #2:

# iptables -A FORWARD -m recent --update --seconds 60 -j DROP
# iptables -A FORWARD -i eth0 -d 127.0.0.0/8 -m recent --set -j DROP

(The author's favorite method)

This is identical to example #1 except that for every subsequent packet received from this source address the 'last seen' status will be updated in the table. Therefore there must be a 'quiet time' of 60 seconds before another packet from this address will even be considered.

It is the author's intent that all 'DROP' rules be replaced by:

'-m recent --set -j DROP'

and that a:

'-m recent --update --seconds 60 -j DROP'

rule be added very early on in the rule set, though following any:

'--match state --state ! NEW,INVALID -j ACCEPT'

rules. If the '--update' rule is before this check for ! NEW,INVALID packets then ESTABLISHED connection or those in the process of becoming ESTABLISHED could be disrupted by a malicious person who can modify his/her source address.

Example #3:

# iptables -A FORWARD -d 192.168.1.1/32 -p tcp --dport 25 -m recent --set --rsource --name SMTP_RELAY_IN -j ACCEPT
# iptables -A FORWARD -d 192.168.1.1/32 -p tcp --dport 113 -m recent --rcheck --rsource --seconds 15 --name SMTP_RELAY_OUT -j ACCEPT
# iptables -A FORWARD -s 192.168.1.1/32 -p tcp --dport 25 -m recent --set --rdest --name SMTP_RELAY_OUT -j ACCEPT
# iptables -A FORWARD -s 192.168.1.1/32 -p tcp --dport 113 -m recent --rcheck --rdest --seconds 15 --name SMTP_RELAY_IN -j ACCEPT

This set of rules can be used to allow auth requests to/from your mail server to go through when there is an associated SMTP connection. It's possible someone could write a conntrack module for this too but that seems kind of excessive, especially when there are a number of other places where this kind of a setup could be desirable (ie: for IRC). Unfortunately this won't work all the time because there are some incorrectly configured systems out there where the auth request will actually come from a different IP address than the SMTP connection was made to, not much that can be done there. This example also shows how you can set it up so that people have to, say, send a 'special' packet of some kind to be allowed to connect to some internal machine. Very neat idea.