Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 155608 - libipt_recent.so not built due to spec file problem
libipt_recent.so not built due to spec file problem
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc-kernheaders (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Woodhouse
Brian Brock
Depends On:
Blocks: 156320
  Show dependency treegraph
Reported: 2005-04-21 15:19 EDT by Mike Kimmick
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2005-597
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 13:31:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:597 qe-ready SHIPPED_LIVE glibc-kernheaders bug fix update 2005-09-28 00:00:00 EDT

  None (edit)
Description Mike Kimmick 2005-04-21 15:19:40 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050415 Firefox/1.0.2 Red Hat/1.0.2-1.4.1.TL1

Description of problem:
All packages fully updated as of 04-21-05.

Missing /lib/iptables/libipt_recent.so, and so cannot match on recent.

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

How reproducible:

Steps to Reproduce:
1. Try adding the following rule:
iptables -A INPUT -m recent --name badguy --rcheck --seconds 60 -j DROP

Actual Results:  The following error is printed:
iptables v1.2.8: Couldn't load match `recent':/lib/iptables/libipt_recent.so: cannot open shared object file: No such file or directory

Expected Results:  No error should occur and the recent extension should be available.

Additional info:

This is the exact same bug as found in the closed bug report 106002.

Essentially, the spec file for this version of iptables has an error where KERNEL_DIR is defined as /usr but should be defined as /usr/src/linux-2.4

1.Get iptables-1.2.8-12.3.src.rpm
2.Fix spec file by changing KERNEL_DIR defs
from /usr to /usr/src/linux-2.4 (5 lines)
3.Rebuild rpm.
Comment 1 Mike Kimmick 2005-04-21 17:02:15 EDT
Okay, now I have another issue.  After rebuilding the rpm and installing it, I
can add a line to match recent, and this works fine.
iptables -I INPUT -m recent --name badguy --rcheck --seconds 60 -j DROP

Saving the config and restarting iptables fails.  During iptables restart, I'm
getting the following error:

Flushing firewall rules:                                   [  OK  ]
Setting chains to policy ACCEPT: mangle nat filter         [  OK  ]
Unloading iptables modules:                                [  OK  ]
Applying iptables firewall rules: Bad argument `recent:'
Error occured at line: 25
Try `iptables-restore -h' or 'iptables-restore --help' for more information.

This can be quite damaging as the firewall never gets loaded, and the machine is
wide-open for attack.
Comment 2 Mike Kimmick 2005-04-21 17:21:19 EDT
iptables-save is not saving the config correctly.

RHEL 4 works fine, and here is the saved data
-A INPUT -m recent --rcheck --seconds 60 --name badguy --rsource -j DROP

And here is what is saved under RHEL 3
-A INPUT -m recent recent: --seconds 1701970164 --hitcount 1953391971 --name 
--rsource -j DROP
Comment 3 Mike Kimmick 2005-04-22 11:16:10 EDT
From RHEL 4, iptables-1.2.11-3.1.RHEL4.src.rpm has the same spec file problem. 
Fixing and rebuilding iptables-1.2.11-3.1.RHEL4.src.rpm on RHEL 3 seems to work.
Can now add firewall rule to match on recent, and the rules are saved and
restored successfully.
Comment 4 Eric Wood 2005-05-09 23:11:35 EDT
This approach has worked on my RHEL3 system also.  Thanks. The 'recent' module
is very important in order to throttle ssh brute force attacks:

RHEL3 and RHEL4 really needs an iptables update asap.
Comment 5 Thomas Woerner 2005-05-11 07:28:47 EDT
iptables may not use the kernel headers directly. It has to use the
glibc-kernheaders instead. Assigning to glibc-kernheaders.

If is it fixed in the glibc-kernheaders package, please reassign to get the save
problem in the iptables recent module fixed.
Comment 6 David Woodhouse 2005-07-14 08:17:00 EDT
Adding ipt_recent.h to glibc-kernheaders.

Actually, since iptables is probably the only user of these headers, it should
probably carry its own copy instead of putting them in /usr/include/linux.
Comment 8 Red Hat Bugzilla 2005-09-28 13:31:38 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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