jccb
October 2, 2020, 9:50am
1
I recently experienced problems when trying to ban brutte force attacks on the ssh server.
after much research I found out that there are still some improvements that can be implemented, especially to improve the integration with firewalld.
See a discussion here:
opened 06:13AM - 01 Jul 16 UTC
enhancement
Apologies for not adhering to the bug report format but I'm not creating this is… sue for a bug.
This is half a question, half a suggestion.
All the supplied fail2ban action files for use with firewalld use 'direct' rule configuration to essentially ban IPs in the same way that iptables would.
However, from their own man page ( https://fedoraproject.org/wiki/FirewallD ) the authors of FirewallD state that `Direct options should be used only as a last resort when it's not possible to use for example --add-service=service or --add-rich-rule='rule'.`
Considering this, the more appropriate (and significantly simpler) manner in which to ban an IP address in FirewallD is by adding the IP (referred to as the "source") to an appropriate zone, such as "drop" or "block".
The command to do this would be `firewall-cmd --permanent --zone=drop --add-source=<ip>`. The benefit of this (apart from the simplicity) would be that firewalld would then also be able to display the banned IPs associated with the drop (or block) zone by using the command `firewall-cmd --info-zone=drop` or even `firewall-cmd --list-all-zones`.
No setup or teardown actions would be necessary. Essentially this approach delegates the nitty-gritty details of rule writing to firewalld. Instead of telling firewalld HOW you want to ban an IP, you instead tell firewalld THAT you want to ban an IP and let firewalld deal with the HOW.
If the 'block' zone were to be used, the response to banned IPs would be an icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited for IPv6. If the 'drop' zone were used, the packets would be dropped with no response.
I personally am in favor of using the drop behavior, but it's easy enough that both action's could be and should be supplied as options.
Am I missing something as to why this approach is not preferable? Is there a reason that `--direct` rules are necessary and my suggestion is unsuitable? Or is the current behavior simply a result of how iptables rules were ported over to firewalld for compatibility at first release? In which case I strongly suggest this at the very least as an option that should be included with the fail2ban package-provided action files.
here is the configuration that finally worked for me, the configuration out-of-the box did not work.:
the problem is that webmin sets firewalld as the banning method and this is apparently incompatible with iptables. This is the configuration that finally worked:
[image]
with this as default:
[image]
By the way, apparently there is a better solution for using firewalld, see the discussion here:
maybe the webmin developers want to consider this?
ramin
October 2, 2020, 3:40pm
2
jccb:
after much research
Interesting. I’m relatively new to both Firewalld and Fail2ban (after years of being spoiled by APF & BFD). Although I’ve never had a lick of trouble using them on CentOS, your trouble shooting ought to be helpful for others using Debian. Nice work and glad you got it working.
system
Closed
November 1, 2020, 3:40pm
3
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.