Good evening,
unfortunately for several years, I have continued to use Webmin and Virtualmin, but over the years it seems to me that the problem relating to hacker attacks has never been resolved…
In particular, it would seem that Fail2ban works correctly, banning IPs after a certain number of attempts and for the set time…
Initially we find an error, the ban time is set to 10min, but it is enough to know about it to correct it, however, even after changing this parameter, the IPs will be banned, but they will continue to try to log in and Fail2ban in the log will record a simple “IP already banned”…
I hope you can provide me with a resolution, although I don’t hope so sincerely…
Your system must process the packet unless you somehow pass the information to a firewall ahead of the machine. There is no way around this. The ‘already banned’ machine is getting a ‘REJECT’ in response to the attempt. Your security IS working.
Your concern arises from not fully understanding what is happening under the hood. Relax. All is good.
If you want a more agressive setting you can search for settings in fail2ban that increments the time from 10 minutes up to 2 weeks for repeated failures. Your machine will still log the attempts however. This is not reason for concern.
This seems like FAQ material as it seems to come up rather frequently.
As I said above, if your firewall is on your server, it MUST accept the packet to decide what to do with it. If you want to prevent that, you need a firewall ahead of the box. No way around that.
OK. This is more serious. They are successfully logging in and sending mail even though the IP is banned? IF that is the case, your box is rooted and you basically need to reload from scratch.
Yes, 10 minutes or a similar (relatively short) ban time is sufficient to thwart a brute force attack, which is perhaps the primary intention of using fail2ban.
Yes, as mentioned above, they send mail from root@domainname.tld
About the firewall, it’s obvious that the connection should be refused if the IP is banned, I wonder it’s not like this by default, otherwise what’s the point of this protection if they can keep trying?
Sending from root@whatever is not the same as logging into the box with a banned IP.
If you want a proper firewall AHEAD of your box, that is another issue. I don’t know any off hand that will work off of the IP’s generated in fail2ban.
Again, if the firewall in on your box, it MUST process the packet to see what to do with it. If it is banned, the default action is to REJECT it. No other processing is done other than to determine what action to take on the packet. How can it do anything else? Seriously. Think this through.
No, that’s not right. OP understands correctly, you’re misunderstanding.
“Already banned” in the log means the firewall rule isn’t working. Something is wrong with fail2ban configuration in such a case. Fail2ban reads logs, and when it flags something it means it made it past the firewall. Fail2ban is not monitoring the firewall log (and it works even without a firewall log), it is monitoring application logs…if it hits the application log, it did not get filtered by the firewall.
A ‘trigger event’ Apr 30 05:08:35 main postfix/smtpd[1420510]: connect from unknown[185.225.74.20] Apr 30 05:08:37 main postfix/smtpd[1420510]: warning: unknown[185.225.74.20]: SASL LOGIN authentication failed: authentication failure Apr 30 05:08:40 main postfix/smtpd[1420510]: warning: unknown[185.225.74.20]: SASL LOGIN authentication failed: authentication failure Apr 30 05:08:42 main postfix/smtpd[1420510]: warning: unknown[185.225.74.20]: SASL LOGIN authentication failed: authentication failure Apr 30 05:08:44 main postfix/smtpd[1420510]: warning: unknown[185.225.74.20]: SASL LOGIN authentication failed: authentication failure Apr 30 05:08:47 main postfix/smtpd[1420510]: warning: unknown[185.225.74.20]: SASL LOGIN authentication failed: authentication failure Apr 30 05:08:48 main postfix/smtpd[1420510]: warning: unknown[185.225.74.20]: SASL LOGIN authentication failed: authentication failure
Subsequent events Apr 30 05:13:48 main postfix/smtpd[1420510]: timeout after AUTH from unknown[185.225.74.20] Apr 30 05:13:48 main postfix/smtpd[1420510]: disconnect from unknown[185.225.74.20] ehlo=1 auth=0/6 rset=6 commands=7/13 Apr 30 05:17:09 main postfix/anvil[1420512]: statistics: max connection rate 1/60s for (smtp:185.225.74.20) at Apr 30 05:08:35 Apr 30 05:17:09 main postfix/anvil[1420512]: statistics: max connection count 1 for (smtp:185.225.74.20) at Apr 30 05:08:35 Apr 30 05:17:09 main postfix/anvil[1420512]: statistics: max cache size 3 at Apr 30 05:11:07
Does it have to process requests to determine permit_sasl_authenticated
I have had this issue when fail2ban starts before firewalld is ready for whatever reason … this causes fail2ban not to be able to write to the ipset, meaning that certain ip address don’t get banned as the rule is never written to the ip set. A bad fix I did was to unban every IP in fail2ban’s database and let it repropagte. Not saying this is what is happening here but it may be
I remember when I first looked into fail2ban a ‘limitation’ was that it reads logs and can lag a little because of that. For as few as I have I wonder if mine are artifacts of getting more attempts in before the logs were read and the event triggered.
example:
12 failed attempts
logs read
line 11 and 12 output ‘already banned’
?
My Webmin firewalld window showed “all interfaces”. Firewald command line showed only docker as the interface. Changing to eth0 in the GUI and hitting apply still showed docker as the interface. I changed it via command line and restarted .
I wish I had seen this first. Sets denied logging in firewalld.
firewall-cmd --set-log-denied=all
To see what is denied:
journalctl -x -e
Latest fail2ban entry shows up. I’ll try and remember to do further checking later. Well, that and turn off the logging.
Turns out proftp isn’t registering with fail2ban though. But, that’s another thread.
In this case I don’t remember doing any restarts. Possible I guess but the last two time stamps were early morning (a day apart) before I was even up. I’m doing some packet logging and tailing log files today just to keep an eye on things.
I’m trying to get some working knowledge of firewalld today.
Since fail2ban updates the firewall maybe it would make more sense if it could periodically check that its’ rules are applied?
But, that’s another thread.