Red Hat Bugzilla – Bug 164076
iptables ipt_recent module does not work properly
Last modified: 2007-11-30 17:11:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4
Description of problem:
I use the ipt_recent module in a few iptables rules to stop SSH dictionary attacks. The following lines are the contents of my /etc/sysconfig/iptables file, a short version I used to try and track down the recent module issue:
# cat /etc/sysconfig/iptables
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:SSH-attack - [0:0]
:Main - [0:0]
-A INPUT -j Main
# SSH Scan Stopper
-A SSH-attack -m recent --set --name sshattack -j LOG --log-prefix "SSH attack: "
-A SSH-attack -j DROP
-A Main -p tcp --dport 22 --syn -m recent --rcheck --name sshattack --seconds 600 -j DROP
-A Main -p tcp --dport 22 --syn -m recent --rcheck --name sshconn --hitcount 5 --seconds 30 -j SSH-attack
-A Main -p tcp --dport 22 --syn -m recent --set --name sshconn -j ACCEPT
Unless I've made some stupid mistake (I don't have a whole lot of experience with iptables), the above rules are supposed to do the following:
1) All SYN packets to SSH port 22 get a ipt_recent name of "sshconn" added the first time the IP address is seen.
2) If more SYN packets come in from the same source address, and the source address is listed in the "sshconn" table, they go through the following:
2a) If more than 5 packets in 30 seconds, the packet gets sent to the SSH-attack chain where they are tagged to the "sshattack" table and dropped.
2b) If less than 5 packets, nothing happens (packets are accepted).
3) If a SYN packet comes in from an address that is in the "sshattack" table and the entry is younger than 10 minutes, the packet is dropped.
However, here's what really happens: The first SYN packet that comes in from a source address appears to be tagged and then accepted. The second packet that comes in is sent to the SSH-attack chain and then dropped (I've added LOG lines to the chain to test it). This should not happen because of the "--hitcount 5" on the line that causes a jump to SSH-attack (-j SSH-attack).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
This bug appears to have been fixed in kernels >= 2.6.15, according to: