Needs Exclude List

[GWustenstein]

Looking at this and other solutions to handle waves of VPS hosting-instance based attacks. What this solution lacks is CIDR and/or IP whitelisting, which would prevent adjacent instance DOS attacks (seen these in the wild).

Also, this would benefit from a db-based implementation and being made callable as part of a F2B action when each IP is being discovered, rather than an async cronjob. In this case, envision it being provisioned with directives for # of unique IPs before signalling a ban, etc. and when that threshold is crossed, it logs it's own entry which can drive it's own F2B Jail. Personally don't think the script should be doing it's own ban, just drive the logging logic to indicate to a specific jail that the offending range is banable, and let F2B's jail engine do the thresholding/timing/whitelisting like normal.

[djdomi]

no, not this programm needs it imho - you can exclude and whitelist already inside fail2ban iirc

[jaccol]

I expect that if you have an ignoreip configured AND hosts around this IP are getting banned, that this tool will make an IP range to ban that includes the ignoreip. Effectively overruling the setting.

[pbiering]

Yes, it can happen that "fail2ban-block-ip-range" will block ranges which include preconfigurd ignoreip configuration, in case the "attackers" are in surrounding /22 (max).

In this case of such neighbours I would recommend using a different "firewalld" zone like "trusted" instead of using ignoreip.

[GWustenstein]

Let me make sure I understand this correctly: you're suggesting that I run firewalld to drive nftables, and place my VPS instance's IP range in a trusted zone, then let fail2ban handle the default traffic? My first thought was F2B would fire spurious triggers when logfails, etc. happen on my instance and fill the filter table with bogus (my ip) entries that are overridden by the trusted zone, but thinking again, the ignoreip directive should prevent that for my instance IPs. This seems complicated, but worth a try...I'll set aside some time and come up with a way to sandbox some test cases (maybe spool up a an attacking instance to try the mess out).

[pbiering]

At least here "fail2ban" fills the public chain:

nft list chain inet firewalld filter_IN_public_deny
table inet firewalld {
    chain filter_IN_public_deny {
        ip saddr 192.0.2.119 tcp dport 25 ct state { new, untracked } reject with icmp port-unreachable
...

as defined in

grep ^zone /etc/fail2ban/action.d/firewallcmd-common.conf
zone = public

while not touching the other zones. And e.g. the "trusted" zone with narrowed source IPs will have precedence.

[WKnak]

IMHO it is possible to add exceptions in the firewall to allow communication with trusted IPs / Networks, so this feature is not needed to be implemented.