similar to: EmergingThreats fwrules ipset updater

http://bugzilla.netfilter.org/show_bug.cgi?id=640 Summary: ipset-4.2 : ipset -T <some_setlist> <address> always negative Product: ipset Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: default AssignedTo:

I want to use the ipset-service to store ipsets persistently across boots. (For use by iptables rules. firewalld has direct support for persistent ipsets but I need the more general capability of raw iptables.) I'm using a kernel with ipsets compiled in, rather than loaded as a module. The support script that saves ipsets checks if the module is loaded before saving and finds nothing, so

http://bugzilla.netfilter.org/show_bug.cgi?id=773 Summary: iptables performance limits on # of rules using ipset Product: ipset Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: default AssignedTo: netfilter-buglog at lists.netfilter.org

I have been using shorewall for years with ipsets. I have encountered a problem after upgrading from 4.2.11 to 4.4.10. When I run ''shorewall-check'' or ''shorewall start'', it halts with the error: ---------------------------------------------------------------------- ERROR: ipset names in Shorewall configuration files require Ipset Match in your kernel and

https://bugzilla.netfilter.org/show_bug.cgi?id=1750 Bug ID: 1750 Summary: 'ipset save' does not save in format loadable by systemd (it saves in 'ipset list' format) Product: ipset Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: normal

https://bugzilla.netfilter.org/show_bug.cgi?id=1726 Bug ID: 1726 Summary: invalid json generated by ipset list -output json Product: ipset Version: unspecified Hardware: x86_64 OS: Debian GNU/Linux Status: NEW Severity: trivial Priority: P5 Component: default Assignee:

-------- Original Message -------- Subject: Re: [CentOS] ipset and blacklisting From: "Albert McCann" <mac358 at newsguy.com> Date: Wed, September 21, 2016 5:34 am To: "'CentOS mailing list'" <centos at centos.org> How are you saving and reloading the ipsets over a reboot? > -----Original Message----- > From: centos-bounces at centos.org

http://bugzilla.netfilter.org/show_bug.cgi?id=719 Summary: ipset restore fails randomly Product: ipset Version: unspecified Platform: All OS/Version: All Status: NEW Severity: critical Priority: P3 Component: default AssignedTo: netfilter-buglog at lists.netfilter.org ReportedBy:

Before firewalld I used to use ipsets to blacklist several countries. Firewalld added support for ipsets with version 0.4, a year ago. Centos 7.2 is still at 0.3.9. Anyone know of a newer Centos package? jon -- Jon H. LaBadie jon at jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)

On Fri, 14 Sep 2018, Kenneth Porter wrote: > I'm using a kernel with ipsets compiled in, rather than loaded as a module. The > support script that saves ipsets checks if the module is loaded before saving > and finds nothing, so aborts. Why does it need to make this check? Likely the check is there to avoid an abort when the commands are issued but w/o the feature present. So

This is what ipset can do for traffic on a home server that's not wanted on a slow 6MB DSL connection. http://palmettoshopper.com/httpd_traffic.jpg I only use my home server for zoneminder, testing my commercial website and streaming movies. Got tired of hackers looking for files that don't exist on my home server and non-complying robots. Check the drop in bandwidth. Setup up a

ipset on CentOS6 comes with /etc/rc.d/init.d/ipset so that "service ipset reload" can be used to (re)load the configuration. CentOS7 doesn't come with an equivalent for systemd: # systemctl reload ipset.service Failed to issue method call: Unit ipset.service failed to load: No such file or directory. # systemctl start ipset.service Failed to issue method call: Unit ipset.service

Hi all I have a CentOS6 box with shorewall-4.5.21. If I have IPSET= in shorewall.conf and I issue the command "shorewall add ppp:192.168.33.3 ptp", I get the error: /usr/share/shorewall/lib.cli: line 585: [: too many arguments ERROR: Zone ptp, interface ppp does not have a dynamic host list The error is corrected setting the actual path to ipset in shorewall.conf, or via the patch:

http://bugzilla.netfilter.org/show_bug.cgi?id=733 Summary: ipset restore won't restore from output of ipset save Product: ipset Version: unspecified Platform: All OS/Version: Debian GNU/Linux Status: NEW Severity: normal Priority: P5 Component: default AssignedTo: netfilter-buglog at

i created an ipset and added 8.8.8.8 to it and used the same iptables working all summer long but ?i can still ping 8.8.8.8 and do nslookup queries against it. ipset or iptables is broken. Anybody else rebooted since ipset-6.11-3.el6.i686 was installed and actually tested that IP addresses that are supposed to be blacklisted are actually blocked? ? Filed CentOS bug report 7977

http://shorewall.net/pub/shorewall/2.3/shorewall-2.3.0 ftp://shorewall.net/pub/shorewall/2.3/shorewall-2.3.0 WARNING: This is a development release and may be unstable New Features in version 2.3.0 1) Shorewall 2.3.0 supports the ''cmd-owner'' option of the owner match facility in Netfilter. Like all owner match options, ''cmd-owner'' may only be applied to

I've just started experimenting with ipset under CentOS 6, and have found what appears to be a bug (or poor design) in the init scripts for ipset, /etc/rc.d/init.d/ipset In stop(), save() and status(), it does lsmod to check for the existence of the ip_set module. If the module is not found, it exits without performing any action. This doesn't take account of a kernel where the ip_set

https://bugzilla.netfilter.org/show_bug.cgi?id=1719 Bug ID: 1719 Summary: ipset wrongly blocking undefined ranges and not blocking ranges that are defined Product: ipset Version: unspecified Hardware: All OS: RedHat Linux Status: NEW Severity: critical Priority: P5

https://bugzilla.netfilter.org/show_bug.cgi?id=880 Summary: ipset doesn't refresh the timeout for an existing entry when the table is FULL. Product: ipset Version: unspecified Platform: x86_64 OS/Version: Fedora Status: NEW Severity: normal Priority: P5 Component: default

I haven''t debugged this enough to understand what is happening, but I observe the following: someipset = bitmap:ip,mac 1) br0:+someipset 2) br0:+someipset[2] The first 1) doesn''t match anything in rules or tcrules, the second 2) matches fine. (Also using +someipset[1] doesn''t match anything) Is it possible/sensible/feasible to have shorewall figure out the