Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 164076 - iptables ipt_recent module does not work properly
Summary: iptables ipt_recent module does not work properly
Alias: None
Product: Fedora
Classification: Fedora
Component: iptables
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-24 07:39 UTC by Wesley Haines
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-12-05 09:28:39 UTC
Type: ---

Attachments (Terms of Use)

Description Wesley Haines 2005-07-24 07:39:12 UTC
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
: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):

How reproducible:

Steps to Reproduce:
See above.

Additional info:

Comment 1 Wesley Haines 2005-12-05 09:28:39 UTC
This bug appears to have been fixed in kernels >= 2.6.15, according to:


Closing bug.

Note You need to log in before you can comment on or make changes to this bug.