Nevermind. Having fixed the xt_tables database files, or more likely because of an intervening reboot? Shorewall show capabilities now shows GeoIP Yes and accepts the relevant syntax: in my case a whitelist rather than blacklist, DROP:$LOG Dirty:!^[CA,US] all+
For the record: most of the online instructions for setting up GeoIP with iptables are outdated; MaxMind changed their database format a few years ago. There is a conversion utility GeoLite2xtables referenced here: http://www.mailserverguru.com/iptables-geoip-blocking-ubuntu-16-04-18-04/ which is also outdated in the sense that MaxMind (due to privacy laws) as of this year no longer makes the CSV country file freely downloadable. It's necessary to sign up for a (free) account. Although their own ".mmdb" format can be downloaded automatically and periodically (with an individual key and their geoipupdate tool), it looks like the CSV files are only available if you log in and download explicitly. Once you have their zip file and extract it however, the instructions work from there. The one that can be easily downloaded automatically On Fri, Apr 17, 2020 at 12:00 PM Norman Henderson <norm.aud...@gmail.com> wrote: > Just to update: the reboot went badly but for a different reason. It > appears the match rule resulting from the ipset was applied before any > other rules including a specific rule to allow me to ssh to the machine - > so I locked myself out. It's a hosted VM and I have no console access so > had to get the friend that hosts it to bail me out. > > I'm trying a different approach: GeoIP. Following a few sets of > instructions I got xt-geoip installed, it shows up in lsmod and modinfo. > There are warnings in the logs but several posts suggest they aren't > significant: > xt_geoip: loading out-of-tree module taints kernel > xt_geoip: module verification failed: signature and/or required key > missing - tainting kernel > > The database is present in the directory specified (GEOIPDIR). > > However: shorewall still complains there is no GeoIP support in the kernel > (confirmed by shorewall show capabilities). I do not currently have any > /etc/shorewall/capabilities file. If I do the following: > iptables -t filter -I Dirty2Fwall 8 -m geoip --src-cc CN -j DROP > I get a different error, Could not open /usr/share/xt_geoip/LE/CN.iv4 > which is true, I have to sort out why the country files weren't unpacked > properly but at least iptables didn't object to the geoip match. > > Is shorewall just checking the base kernel capabilities without reference > to loaded modules? Could I fix that by creating and altering a capabilities > file? > > > On Tue, Apr 14, 2020 at 4:34 PM Tom Eastep <teas...@shorewall.net> wrote: > >> On 4/14/20 3:54 AM, Norman Henderson wrote: >> > Thank you Erich, that was the step I missed: dynamic zone. It's working >> > OK across shorewall stop/start, I will have to wait until tonight to try >> > a reboot. >> > >> > Tom, I have gone back to SAVE_IPSETS=Yes in shorewall.conf rather than >> > using the shorewall-init feature. Is there a reason to use one rather >> > than the other? >> >> If you use an ipset in /etc/shorewall[6]/stoppedrules, then you must use >> shorewall-init. Other than that, it is your choice. >> >> > >> > Also, is it OK to add entries using ipset add, which seems to be a lot >> > faster than shorewall add ? >> >> Absolutely. >> >> -Tom >> -- >> Tom Eastep \ Q: What do you get when you cross a mobster >> Shoreline, \ with an international standard? >> Washington, USA \ A: Someone who makes you an offer you >> http://shorewall.org \ can't understand >> \________________________________________ >> >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> >
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
