Bug 169279 - Kernel module ipt_recent overflow after ~20 days
Kernel module ipt_recent overflow after ~20 days
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.4
All Linux
medium Severity high
: ---
: ---
Assigned To: Norm Murray
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-26 10:04 EDT by Didier
Modified: 2012-06-20 09:32 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 09:32:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Simple test script (313 bytes, text/plain)
2005-09-26 10:04 EDT, Didier
no flags Details
ipt_recent log file (2.40 KB, text/plain)
2005-09-26 10:16 EDT, Didier
no flags Details
iptables SSH brute force detection (691 bytes, text/plain)
2005-09-28 11:42 EDT, Didier
no flags Details
/etc/sysconfig/iptables from both good and bad responding host (1.72 KB, text/plain)
2005-09-29 03:44 EDT, Didier
no flags Details

  None (edit)
Description Didier 2005-09-26 10:04:20 EDT
Description of problem:

The iptables 'ipt_recent' module does not honour parameters '--seconds' and/or
'--hitcount' and/or '--rttl', thus rendering it quite useless.


Version-Release number of selected component (if applicable):

iptables-1.2.11-3.1.RHEL4


How reproducible:

Always


Steps to Reproduce:

1. Execute minimal test script '' on target machine
2. start external SSH session to target machine
3. "cat /var/log/messages", "cat /proc/net/ipt_recent/DEFAULT", and "iptables -vnL"
  
Actual results:

Subsequent ssh sessions get tagged.

Expected results:

According to "-m recent" parameters, subsequent ssh sessions should not get tagged.


Additional info:

- The "ipt_recent" module is particularly useful in defending against e.g. ever
increasing SSH brute force attacks ; the "--seconds" and "--hitcount" parameters
are of paramount importance for the functionality of ipt_recent.

- Similar erroneous behaviour seems to be reported in bug #164076 for FC4.
According to my own tests, my attached test script functions correctly in FC4
iptables-1.3.0-2 (see /var/log/messages comparison).

- Version info :
RHEL4 : iptables v1.2.11 , ipt_recent v0.3.1
FC4   : iptables v1.3.0  , ipt_recent v0.3.1
Comment 1 Didier 2005-09-26 10:04:20 EDT
Created attachment 119261 [details]
Simple test script
Comment 2 Didier 2005-09-26 10:16:53 EDT
Created attachment 119262 [details]
ipt_recent log file

This file compares the log results between :
- the faulty RHEL4 behaviour ("SSH connect_set3" immediately followed by "SSH
connect_recent3"), and 
- the correct FC4 behaviour (6 "SSH connect_set3" messages due to '--hitcount
6',  then followed by "SSH connect_recent3").
Comment 3 Didier 2005-09-26 11:12:46 EDT
After successfully having tested my simple script on an identically configured
RHEL4 installation, I desperately rebooted (cannot recall the time or
circumstances I've done this before with RHEL) the server exhibiting the
erroneous behaviour.
Lo and behold, the test script now seems to function correctly.

Please note that during my tests, I took *every* measure to produce reproducible
results (flushing and deleting all chains, rmmod'ing iptables modules, etc.) ;
finally, only a full restart seemed to cure the problem.

As I am not quite sure whether this indicates a netfilter or kernel problem
(2.6.11 and 2.6.12 have ipt_recent patches), I leave it at the discretion of the
assignee twoerner@redhat.com to either close or follow up on this bug report.
Comment 4 Didier 2005-09-28 11:42:47 EDT
Created attachment 119376 [details]
iptables SSH brute force detection
Comment 5 Didier 2005-09-28 11:46:24 EDT
Update : I am experiencing the same erroneous behaviour (ipt_recent parameters
not honoured) on another fully patched RHEL4U1 server. As this is our main file
server, I am reluctant to reboot the server for testing purposes.

Unfortunately, due to the netfilter rules involved in the brute force detection
script (see attachment #119376 [details]), flaky ipt_recent support implies I'm exposed to
a very high risk of locking myself out of remote server SSH access after a
reboot with the iptables rules in place : -> escalating Severity to High.



/var/log/messages : iptables immediately drops ssh packets :

Sep 28 17:36:13 dmbrXXX kernel: IPT_DROP-BruteForce_SSH : IN=eth0 OUT=
MAC=00:02:55:67:74:cb:00:02:xx:c2:9b:75:08:00 SRC=xxx.xxx.xxx.xxx
DST=157.193.yyy.zzz LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=25339 DF PROTO=TCP
SPT=56636 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Comment 6 Thomas Woerner 2005-09-28 12:09:47 EDT
This is a problem in the kernel netfilter modules. iptables-save gets all
configured options back from the kernel modules. So the problem seems not to be
a iptables userland problem.

Is the output of iptables-save ok for you, too?
Comment 7 Didier 2005-09-29 03:44:03 EDT
Created attachment 119402 [details]
/etc/sysconfig/iptables from both good and bad responding host

There seems to be no discernible difference between the /etc/sysconfig/iptables
contents of the good and bad responding servers (both RHEL4U1).

Does this imply that a kernel patch/upgrade is needed to solve this bug (I'm
willing to run a custom patched kernel if this solves the problem) ?

More important for the immediate future :
can the circumstances which lead to the erroneous behaviour be predicted (e.g.
why does the filtering work after a reboot of one server, and why was the
reboot not necessary on another, identical, server (see comment #3) ?
Comment 8 Thomas Woerner 2005-09-29 04:54:02 EDT
This is a kernel netfilter problem. Assigning to kernel.

If there is any impact on the iptables part, please assign back after fixing.
Comment 9 Matti Hiljanen 2005-12-29 17:14:04 EST
This problem is still very much an issue on a fully patched RHEL4U2. Has there
been any progress on finding out and fixing the cause of it?
Comment 10 James Morris 2006-01-10 02:06:50 EST
(In reply to comment #9)
> This problem is still very much an issue on a fully patched RHEL4U2. Has there
> been any progress on finding out and fixing the cause of it?

This has been fixed upstream in 2.6.15 and the fix should be heading into RHEL4
soon.  A possible workaround until then may be to only use one of --seconds or
--hitcount arguments.
Comment 11 Dennixx 2006-03-16 10:54:53 EST
Sounds like the 'jiffies' problem: http://nvd.nist.gov/nvd.cfm?cvename=CAN-2005-2873
Comment 12 Need Real Name 2006-03-21 13:15:33 EST
Updated to RHEL4U3 and the bug is still present.  Any idea when the fix from
2.6.15 will make it into RHEL4?
Comment 13 Jeremiah Johnson 2006-04-20 09:33:39 EDT
Will a fix make it into RHEL4 anytime soon?
Comment 14 Milan Kerslager 2006-05-17 08:07:24 EDT
The kernel 2.6.9-34.ELsmp still has the problem :-( What about U4?
Comment 15 Jeremiah Johnson 2006-08-11 11:33:09 EDT
Great, so U4 is released and this bug is still present.  What info is needed to
resolve this thing?  All the information that should be needed has been posted here!
Comment 16 Robert Berlinger 2006-08-11 11:55:06 EDT
The bug has been well described here for a over a year, and jmorris@redhat.com 
said in an earlier comment that the fix would be soon seven months ago.  Can 
someone please get on this already?
Comment 17 Milan Kerslager 2006-08-28 14:54:48 EDT
There is one-line patch at comment #6 in netfilter bugzilla:
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=383#c6

Patch: https://bugzilla.netfilter.org/bugzilla/attachment.cgi?id=179
Comment 18 Jeremiah Johnson 2006-12-05 11:46:24 EST
Considering RHEL5 is right around the corner, will the happy users of RHEL4
*ever* see this bug fixed?

I don't see how this is marked as "needinfo" still as its very well documented
in various links in this bug.  
Comment 19 Wade Mealing 2007-03-21 01:31:00 EDT
Taking this ticket, because its bothering me personally..
Comment 20 Wade Mealing 2007-03-21 02:54:20 EDT
The one line fix does not apply, because there has been considerable changes to
ip_recent in between the 2.6.9 and 2.6.15 versions of the kernel.

This is a low priority bug (for me), (and if someone else has the fix, I'd be
glad to QA and push it in), so I'll get some time to work on it in my spare time.  

Comment 21 Robert Berlinger 2007-06-20 16:35:57 EDT
Has anyone confirmed whether the bug is fixed in RHEL 5?
Comment 22 Milan Kerslager 2007-07-07 18:25:26 EDT
Since the fix hit mainline at 2.6.15 (see comment #10) and RHEL5 has 2.6.18+
kernel, I believe that RHRL5 has not the problem.
Comment 23 Seiich IKARASHI 2007-09-19 09:44:02 EDT
Is it a duplication of bug #202412 ?
Comment 24 Milan Kerslager 2007-09-19 16:27:16 EDT
This bug should be closed as duplicate of bug #202412 and reopened if problem
persist. Thank you.
Comment 25 Didier 2007-09-20 03:06:52 EDT
WRT comment #24 :

Though I am the submitter of the bug, I'm unable to close :
" You tried to change the Status field from ASSIGNED to CLOSED, but only the
owner or submitter of the bug, or a autorized user, may change that field."
Comment 27 Jiri Pallich 2012-06-20 09:32:56 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

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