Possible to temporary remove "ACCEPT ctstate RELATED,ESTABLISHED" rule ?

[QuaxEros]

Since i'm fighting intruders i'd like to get rid of rule
ACCEPT ctstate RELATED,ESTABLISHED /* geoip-shell_aux_rel-est_4 */
can i just remove (-D) the rule from command-line (it will come back when i rerun the script, right ?)

What does geoip-shell_aux_rel_est_4 refer to ?

My IP is whitelisted to prevent lockout.
If this can be done , i feel no need for a config option.

[friendly-bits]

Hi again

can i just remove (-D) the rule from command-line

Yep, you can.

it will come back when i rerun the script, right ?

Generally geoip-shell code verifies firewall rules coherence when you call either the geoip-shell-manage script (including when using the geoip-shell shortcut), or geoip-shell-run.sh script. Rules coherence is verified when launched by the cron tasks as well. However, your question made me realize that currently only the rules which affect ipsets are checked. Some auxiliary rules are not checked for, and that includes the 'related-established' rule. I view this as an oversight and may add verification for those rules in the future. But for now, if you delete the rule, geoip-shell will not notice.

That said, geoip-shell recreates its firewall rules structure every time any change to the firewall rules is requested, for example if you add another country code or change which ports are geoblocked, or during automatic ip lists update, or when geoip-shell is loaded after a reboot. So this is when this rule will come back. Technically, you could disable automatic updates of the ip lists and avoid using the geoip-shell configure command with any options affecting the firewall rules - this will prevent geoip-shell from recreating the firewall rules structure. This would mean that gradually the ip lists will become outdated but may be reasonable as a temporary solution.

What does geoip-shell_aux_rel_est_4 refer to ?

geoip-shell adds comments to the firewall rules it creates. These comments are internally used by geoip-shell to 1. distinguish its own rules from other rules which may exist in that table, 2. serve as an identifier for each rule, 3. categorize the rules somewhat

The aux suffix (in the geoip-shell lexicon) means "auxiliary rule" - a rule which is required not for geoblocking but rather (mostly) to avoid blocking essential traffic. rel_est means "related/established" - in the case of inbound geoblocking, this allows inbound connections which conntrack identifies as either previously established, or related to other connections which were allowed. I don't know enough about how conntrack works, so I can not really elaborate more on this point. Generally this should allow you to connect to blocked countries and receive a response, without allowing them to connect to you on their initiative. The 4 stands for 'ipv4'. Note that for iptables, geoip-shell creates separate rules for ipv4 and ipv6, as explained in NOTES.md (2nd paragraph). So unless you restricted geoblocking to ipv4, you should have both geoip-shell_aux_rel_est_4 and geoip-shell_aux_rel_est_6 rules (NOTES.md also explains how to manually check the ipv6 firewall rules structure).

[friendly-bits]

To save you some time, you can use these commands to remove the 'related/established' rules for both ipv4 and ipv6:

iptables -t mangle -D GEOIP-SHELL_IN -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment geoip-shell_aux_rel-est_4 -j ACCEPT
ip6tables -t mangle -D GEOIP-SHELL_IN -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment geoip-shell_aux_rel-est_6 -j ACCEPT

If you enabled outbound geoblocking then you may want to remove the outbound related/established rules as well using same commands, except replace _IN with _OUT.

But anyway, I think making the related/established rule optional may be useful in some cases, so you are welcome to make a feature request in a new issue.

[QuaxEros]

Hi again,
Back from my daily chores (which i can do again since geoip-shell REALLY calmed down the attack rate). Man, i'm so happy i found this project!! LACNIC queries have been postponed BTW, i think they are overloaded or stopped their service...

• Found the commands by trial & error (have quite some experience but mainly self-taught after 5 years UNIX/BSD sysadmin long ago, way before XP) Good to have them written out though on this page..

[friendly-bits]

LACNIC queries

What do you mean by "LACNIC queries?" Attacks originating in LACNIC ip ranges?

[QuaxEros]

LACNIC stopped responding to whois queries. Tried querying from different regions with vpn. Says: quota exceeded & no whois reply, but from anywhere in the world. My latest attacks came from Brazil, Uruguay etc. I might not be the only one...

[friendly-bits]

This sounds like you are having less to deal with - good!

[QuaxEros]

You can't imagine the difference it makes. I was sure they were going to break my services at the rate they were going at it, even with decent defenses. My services are important to a whole host of community projects, now i'm confident they will survive. Thanx.. REALLY!! Most of the geoblocking projects i found are not easy to integrate independently, yours can be plugged in without a hitch.

[friendly-bits]

BTW which source are you using? RIPE/ipdeny/MaxMind? This may affect the effectiveness of geoblocking.

[QuaxEros]

Had all 3 systems on different source to look at differences in performance and result. Found out it is not so easy to compare if you're not resource limited. My systems run in data-centers on decent hardware.
Had some time-outs on RIPE. Changed all 3 to Maxmind for which i already had an account.

• Do the ipsets only exist in memory ? How are they handled on reboot, recreated from config ?

[friendly-bits]

• Do the ipsets only exist in memory

Yes, although there are some ways to set up the system to automatically save and and restore firewall rules (and presumably ipsets) after a reboot. I don't have experience with these. Probably this will work fine. Generally, I have never had any issue with the @reboot cron job, except with Busybox cron which may or may not support the @reboot keyword (which is why geoip-shell handles systems with Busybox-based cron differently, and why for OpenWrt persistence is implemented differently). So this should work fine.

• How are they handled on reboot, recreated from config ?

By default (except on OpenWrt) geoip-shell creates a compressed backup of all current ipsets and creates a cron job for persistence. You can verify that the job exists by using the command [sudo] crontab -l -u root or by running geoip-shell status which will also verify and report it.

That job runs the command /usr/bin/geoip-shell-run.sh restore -a. The -a switch tells the -run script to run in daemon mode, which means that if needs to re-fetch the ip lists, it will make multiple retries. Provided that the backup exists, the -run script will then call the -backup script to extract the ip lists from backup, and the -apply script to load them into ipsets and recreate rules based on config. If restore from backup fails for any reason, the -run script will instead call the -fetch script to re-fetch the ip lists. By default, the -run script will sleep for 30 seconds when called with the -a option, in order to give some time for the system services to settle down. This value is not changeable via the command line, but you can directly edit the file /etc/geoip-shell/geoiop-shell.conf and change the value of reboot_sleep to any other unsigned integer.

[QuaxEros]

Thanks for the explanation. Yes, packages exist iptables-persistent & ipset-persistent, they need netfilter-persistent for reloading them. As i said, your script is neat and nifty..

[QuaxEros]

Hi @friendly-bits,
Too busy to get back to you. Little update: Geoip-shell working well. It starts to be a little calmer on some services but too early to start celebrating, Fail2Ban is also doing it's job well with very stringent settings (massive lists by now), and closed all sensitive ports and functions (ftp, sql, client ssh, phpmyadmin etc.) It is crippling my systems a bit but i'm relatively happy now. At the moment my smtp is hammered by whitelisted CC's but RBL's and Spam-detection in place (~65% of incoming mail refused, was under 10% before). ESTABLISHED/RELATED rule still in place because i'm not sure if it can do without.. Thanx for all your hard work!! C U Later!