Bug 169279

Created attachment 119261 [details]
Simple test script

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").

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 to either close or follow up on this bug report.

Created attachment 119376 [details]
iptables SSH brute force detection

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

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?

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) ?

This is a kernel netfilter problem. Assigning to kernel.

If there is any impact on the iptables part, please assign back after fixing.

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?

(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.

Sounds like the 'jiffies' problem: http://nvd.nist.gov/nvd.cfm?cvename=CAN-2005-2873

Updated to RHEL4U3 and the bug is still present.  Any idea when the fix from
2.6.15 will make it into RHEL4?

Will a fix make it into RHEL4 anytime soon?

The kernel 2.6.9-34.ELsmp still has the problem :-( What about U4?

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!

The bug has been well described here for a over a year, and jmorris 
said in an earlier comment that the fix would be soon seven months ago.  Can 
someone please get on this already?

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

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.  

Taking this ticket, because its bothering me personally..

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.  

Has anyone confirmed whether the bug is fixed in RHEL 5?

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.

Is it a duplication of bug #202412 ?

This bug should be closed as duplicate of bug #202412 and reopened if problem
persist. Thank you.

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."

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.