Bug 164076

Summary: iptables ipt_recent module does not work properly
Product: [Fedora] Fedora Reporter: Wesley Haines <wes>
Component: iptablesAssignee: Thomas Woerner <twoerner>
Status: CLOSED UPSTREAM QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-12-05 09:28:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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
*filter
: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

COMMIT

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):
iptables-1.3.0-2

How reproducible:
Always

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:

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=383

Closing bug.