I think there is something wrong with fail2ban + firewalld running on Ubuntu servers. I leave a screenshot of the problem I am referring to. Even though fail2ban is detecting that a user should be blocked, apparently the communication with FirewallD is not working properly. You can see it in the log because the log is filled with many already banned messages.
The fix is pretty straighforward - just restart fail2ban. Sometimes restart fail2ban and firewalld. Sometimes just restart firewalld.
The problem is that it’s happening on every new server that I have installed over the last few years. I’m talking maybe 15 servers.
I read up about firewalld and I see it’s roots are with Redhat. That ufw is the default for Ubuntu. I understand the dillema for the Virtualmin developers, implementing a firewall can be a mission critical and mamoth task and supporting another firewall is too complicated. I also note there’s not real UFW plugin for Webmin.
But I need advice. The problem isn’t I’m afraird my servers will get hacked. That too, but the problem is some of these repeat logins are using huge resources spiking CPUs. So I have a security problem and I have a performance problem.
The best probable cause someone (Keith) gave me was that he thinks there is something wrong with log rotation. That both products work fine until log rotation happens, then one or the other fails.
Please check guys - you might be thinking your fail2ban is working like a bomb but do this first:
Having the same problem on my Debian 10 servers.
After they try to bruteforce the server, it will block the IP finally after more or less 5 minutes.
When I do a complete reboot during this time, it’s getting blocked instantly.
Nor sure why it’s the Casey but having a lot “already banned” in my logs as well
Not sure if they are maybe already made connections to the server…
This is important that fail2ban service is started afterfirewalld. I presume (if your services configured correctly at the first place) the solution for your problem would be as simple as:
Webmin 2.000 will handle those cases automatically, making sure that when firewalld stopped or restarted using UI, dependent services like fail2ban will be restarted as well, to make sure actual banning is functioning as expected.
this issue is very common and well discussed on the fail2ban git repo website. Open your firewalld log and pick out the first ban for that IP and check firewalld successfully bans and which ports. If the firewalld fails then fail2ban won’t know that. That’s #1. After that, check which ports are banned and which ports the IP intruder strikes when the second fail2ban triggers. Those two logs will show the issue and you can get set the log of firewalld to debug output to check.
Thanks for the input. My opinion is the FirewallD and Fail2Ban combination should just work on new installations. I have installed it on many new fresh default Ubunto 20.04 servers and although for a few days it appears to work it then breaks down.
For now I’ll wait for the new Virtualmin 7 installer to see if this resolves the situation reliably. Since this is happening on all my new fresh servers it would be impractical to troubleshoot the problem every time it happens. I’m talking about around 12 servers here which is just a fraction of the other 40+ servers that I manage. Also I don’t exactly know when it breaks down - I would have to constantly log in to look for already banned messages or write some kind of script to watch the problem. Sure one can write a script - but then one has to maintain a script, hand over the script to other staff. Lots of extra Sysops that I would greatly prefer to avoid.
You can wait for someone else to fix the issue that appears to be common or you can do some legwork and assist the community so everyone gets the fix. People spent time getting it 99% there and helping you find where it might be occurring. I’m not sure what you were searching for if not help to find the source of your problem. I don’t have the problem with 10+ domains.
I’m not sure you read the thread before you posted your reply. I’ve done a lot of due dillegence and research like I do with every single post. Go and have a look. Also I’m a pro (e.g. I pay) user.
The developers of Virtualmin made it clear earlier in the post there is something they will ammend on the future Virtualmin installation routine for Ubuntu / FirweallD / Fail2ban. I’m happy to wait for that.
The issue is you wasted resources. You could have simply checked your firewalld log for 3 minutes to see if it accurately banned the respective IP. If not, you have a data point to lend for future mods. Fail2ban has a large number of issues because changes are occurring and not all of them are captured by current packages. With some very simple mods Fail2ban works very well. If you were not going to make the corrections needed then it was a waste of hundreds of people who visited your topic not realizing you were not going to take corrective action. Resources are scarce. Now you have left the community not knowing if you have an issue solely for your installation or if the problem is contained somewhere else, maybe in VM and maybe not. For someone with that many servers I would fix the problem yesterday. I could be wrong.
I had a similar problem that was caused by this issue. The problem in in /etc/fail2ban/00-firewalld.conf where banaction_allports is not set. The issue only appears if you have a jail with banaction allports, like recidive enabled.
