**Problem statement:
**Fail2ban with Firewalld on openSUSE Leap 15.0 allow the brute force attack to continue for unlimited time.
What needs to happen (ok in openSUSE Leap 42.x):
Fail2ban detects 5 invalid Apache login attempts, bans the IP, connection to Apache server drops off and the server becomes unavailable.
What happens (openSUSE Leap 15.0):
Fail2ban detects 5 invalid Apache login attempts, bans the IP, connection to Apache server continues undisturbed. Only the new connections from the same IP find the server unavailable.
Q1: Why(how) did it work in Leap 42.x? Q2: How to implement the same function in Leap 15?
Comments:
The reason for Q1 as stated is that I did some research and found out it probably wasn’t supposed to work like that at all, at least not OOB. Fail2ban sends the IP ban info to the FW but there is no actual “reset” of the active connections from the respective IP. So, the current connections will continue, just the new connections are being dropped.
I did nothing special for it to work on 42.x, installed and configured Apache, installed Fail2ban and configured jails, everything from official repos, worked as expected for years.
Now, after many unrelated issues with upgrading, I went for Leap 15 clean install, on the same exact HW, basically used the same configuration files for both Apache and Fail2ban, respectively, only to run into this behavior. The obvious difference is Firewalld but I can’t say it is to blame.
Clearly, the answer to Q2 is more important - I am currently studying ModSecurity with Apache but it might take a while. I feel like I’m missing something since it worked as needed OOB on 42.x and it should not be as complicated.
I suspect the different behaviour is nothing to do with either Fail2ban or with Apache, but with the iptables configuration for connection tracking.
Connection tracking distinguishes between new packets (the first packet of a connection) and established packets (packets that are part of an existing connection), and enables them to be handled them differently. Commonly, a rule such as
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
is placed at the top of the INPUT chain to avoid the overhead of checking each packet of an existing connection. With the above rule, an existing connection will be maintained even though an attempt to create a new one will be prevented by the new Fail2ban rule.
Without the conntrack rule above, every packet of an existing connection will be checked and the connection dropped when the new fail2ban rule is encountered.
So possibly the conntrack rule is present in your Leap 15.0 firewall configuration (I would regard this as ‘normal’), but not in the Leap 42.x one.
AFAIK they shouldn’t be related, any timing would be coincidental.
AFAIK conntrack has been around since… maybe when the ip kernel module was introduced? Although maybe in some cases a conntrack rule might be missing, as long as I’ve been aware of that capability it’s always been used. It’s why iptables today is supposed to support “stateful inspection” (although to me there is no common definition so then in my eyes becomes marketing).
That makes perfect sense, definitely explains the different behavior (my Q1), and the root cause (see my next post below) had to do with iptables indeed. Thank you very much
Correct! The only thing is, it is all on me getting ahead of myself, not the fault of openSUSE changes.
When I was doing my homework before migration 42.3 to 15.0 I read about the change from SuSEFirewall2 to firewalld. I then started looking into how to manage firewalld and how it works with fail2ban (and the other way around). I found a bunch of posts on “changes needed”; sounded reasonable to me, so I went ahead and basically changed the fail2ban actions from iptables to firewallcmd, without even checking if using iptables still works as needed.
Now, I keep forgetting many Linux “experts” are just trolls, posting “solutions” they found googling, just to increase their posts total count, and without reading the actual problem details.
So, with a fresh reminder of that, I decided to simply revert all the above-mentioned “changes needed” by the switching to firewalld - sure enough, everything works as expected, after 5 failed login attempts the server refuses to answer and disconnects the active connections for the respective IP.
In summary, the Solution: No special configuration changes are required to compensate for the change from SuSEFirewall2 to firewalld. Fail2ban should continue to work as designed.
Bottom line seems to just rely on what the Maintainers did to migrate,
I don’t know if the “suggested changes” you found were entirely the fault of those posters, could be that they were in a “pre-LEAP 15.0” situation exploring possibilities before solutions were finalized and published.
Also,
I’d caution against using firewallcmd without fully migrating to firewalld and even so… when using different tools to manage something common, you have to be absolutely certain you don’t create direct conflicts or result in unintentional conflicts, eg IIRC a major advantage in firewalld architecture is a better concept of layers and inheritance.