Bug 1136257
| Summary: | provide an init script that loads the ipsets | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Radka Brychtova <rskvaril> | |
| Component: | ipset | Assignee: | Thomas Woerner <twoerner> | |
| Status: | CLOSED ERRATA | QA Contact: | Tomas Dolezal <todoleza> | |
| Severity: | urgent | Docs Contact: | ||
| Priority: | urgent | |||
| Version: | 7.2 | CC: | blharris, bugzilla.blk, calestyo, cstpierr, cww, drjohnson1, janfrode, jbainbri, jscotka, kdube, mfuruta, mharris, mpoole, nigel, philrosedba, psklenar, ptalbert, quentin, rob.townley, rskvaril, sebastian.pesman, Speeddymon, tlavigne, todoleza, twoerner, vanhoof, ville.torhonen, wnefal+redhatbugzilla | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | All | |||
| Whiteboard: | ||||
| Fixed In Version: | ipset-6.19-6.el7 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | 888571 | |||
| : | 1377621 (view as bug list) | Environment: | ||
| Last Closed: | 2016-11-04 07:42:22 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 888571, 1130570 | |||
| Bug Blocks: | 1203710, 1295396, 1296594, 1313485, 1377621 | |||
|
Comment 4
d. johnson
2015-03-11 02:30:00 UTC
Would like to see these in Centos 7 aswell, in combination with Fail2ban it would make life a lot easier with regards to banning IP's. If IPtables uses rules which refere to an IPset list and that list is not present the firewall wont start. This could lead into unwanted behaviour with lot's of risks. Even when the iplist-service starts before the IPtables, then there is still no guaranty that the firewall will start, misconfiguration can always happen but in this case it would be a valid configuration but only missing the IPset list at that moment. I will +1 this. Reference bug 888571 which fixed the issue for RHEL 6. Since, unknown to me, iptables didn't come up, my server was completely open to anyone who wanted to have a go at it. [sudo] password for xxxxx: Last login: Sun Oct 18 22:18:18 CDT 2015 on pts/2 Last failed login: Mon Oct 26 01:38:51 CDT 2015 from 113.195.145.12 on ssh:notty There were 6249 failed login attempts since the last successful login. Thankfully all my user accounts have strong passwords and root isn't permitted. ipset is pretty useless without an initscript to start it, and if one uses it at all and includes rules in iptables/ip6tables configs that reference ipsets and the system is rebooted then the iptables initscripts will fail to load the ruleset because they reference ipsets and the ipsets did not get loaded because Red Hat does not provide an initscript. This is a rather unfortunate regression of a major important security feature considering it works in RHEL6 via errata. The only way for anyone to reliably use ipset as supplied by Red Hat is to completely write their own initscript from scratch or to extract the one supplied in RHEL6. It would really be nice to see Red Hat take the security of this seriously and issue an update to this broken feature. I extracted the systemd files from the Fedora rawhide ipset package and installed them by hand and ipset seems to work properly and load before iptables now in EL7, so the solution here would be to just simply include those files in an ipset package update for EL7. (In reply to Mike A. Harris from comment #11) > I extracted the systemd files from the Fedora rawhide ipset package and > installed them by hand and ipset seems to work properly and load before > iptables now in EL7, so the solution here would be to just simply include > those files in an ipset package update for EL7. i do not currently run Fedora, would you mind attaching those files (i assume very small) to this bug report? We shouldn't need to have "the files attached". The files should be made available in RHEL7 for everyone to use. Again, I rebooted my server and fail2ban failed to protect my server because iptables doesn't come up because ipset doesn't come up. This is a severe defect that needs an immediate fix. The Fedora ipset-service rpm can be downloaded from http://koji.fedoraproject.org/koji/packageinfo?packageID=12561 then select one of the builds and download the ipset-service rpm. If you don't want to install the Fedora package, then do the following to extract the files from the rpm: rpm2cpio ipset-service-*.noarch.rpm | cpio -icvdumB (In reply to Robert Townley from comment #12) > (In reply to Mike A. Harris from comment #11) > > I extracted the systemd files from the Fedora rawhide ipset package and > > installed them by hand and ipset seems to work properly and load before > > iptables now in EL7, so the solution here would be to just simply include > > those files in an ipset package update for EL7. > > i do not currently run Fedora, would you mind attaching those files (i > assume very small) to this bug report? I don't run Fedora either, just go to Fedora rawhide or the latest release, download the ipset src.rpm and you can go inside of it using GNU Midnight Commander (mc) or using rpm2cpio and extract the 2 files though. Even easier: http://pkgs.fedoraproject.org/cgit/ipset.git/tree/ipset.service http://pkgs.fedoraproject.org/cgit/ipset.git/tree/ipset.start-stop You do not need to run Fedora to have copies of these files. Last login: Sun Nov 22 21:19:24 CST 2015 on pts/3 Last failed login: Wed Nov 25 17:02:44 CST 2015 from u18750743.onlinehome-server.com on ssh:notty There were 21211 failed login attempts since the last successful login. [root@wibble ~]# uptime 23:09:18 up 3 days, 7:01, 6 users, load average: 0.10, 0.11, 0.10 This is what happens when you have ipset and forgot to start everything up manually. Over 21,000 login attempts in 3 days. This is a major security issue. Why haven't these startup files been pushed down to CentOS 7 yet? Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2505.html *** Bug 1397262 has been marked as a duplicate of this bug. *** |