----- Original Message ----- From: [email protected] To: [email protected] Sent: Wednesday, 6 October, 2021 20:54:58 Subject: [Fail2ban-users] Extending fail2ban for distributed attacks
I've noticed that I have a number of slow distributed attacks happening on my server which evade fail2ban by using a pool of IP addresses. I've been looking at the sqlite db and it looks like the data field in the bips table can have all the data I need to have a supplemental script which runs periodically and looks for a "threshold number" of failed logins over a time period against the same account and bans all IPs that tried. I've already instrumented my filters with the <f-user> tags so that the account name is available in the JSON data. Has anyone tried this? I only started looking at fail2ban a few days ago. Are there any holes in the approach I'm suggesting? Steve Sent with a Spark _______________________________________________ Fail2ban-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fail2ban-users Hi Steve, Hoping not to break any netiquette as I have not been posting for years. I have observed much and been working on improving my own filtering setup over the years and there are several things that you can do to limit the IP addresses that can target your server. Locally on my mailserver I have deployed nftables instead of ip tables as it is a much more configurable and modern firewall and it gives a cleaner overview of the setup. Not talking about its efficiency. It does require that you use one of most recent newest versions of fail2ban though. My preference is the newest stable. Personally I do not care much if the attacks are being slow or not. I just hit them hard at the first attempt or after they attack a couple of times depending on what they do. My setup involves: 1: Dynamic blocking old legacy IP ranges that are being abused by spammers/hackers. Check out: http://www.theunsupported.com/2012/07/block-malicious-ip-addresses/ http://www.cyberciti.biz/tips/block-spamming-scanning-with-iptables.html I made my own modification for the scripts to work with nftables. Look up IP-deny.com. It will enable you to implement a rule to preform geo-blocking. 2: Blocking of the HTTPS and IMAPS (POP3S if you use it) for countries that you deem to be a hazard if allowed the opportunity to access your mailserver. Also do not present any unencrypted traffic if possible. SMTP can be difficult to avoid. As always limit the exposed ports to a minimum. 3: Configure your fail2ban to ban on any failing user authentications happening on the java side (I use the Zimbra mailserver). They exploit JSON and the like and when usernames (typically e-mail adresses) have been collected then they gets blocked by the mailserver due to their failed logins. I have fail2ban monitoring the kern.log (nftables actions gets logged there and proper rule definitions for fail2ban can make the actions permanent), all failed access in logs, syslog, and more, just to insure that they do only get one attempt or at the most 2 attempts initially. This might pose a problem to the rightful owners of the mail accounts. When under siege you can eventually deploy a script to enable blocked user accounts. As they only get 1 attempt to guess a password per IP address used then that should be fairly safe. 4: Set up the recidive and f2b-loop (check on google) rules to give you the possibility of implementing bans to keep out the hard cases permanently. 5: Configure rules in nftables to limit how often an IP address is permitted to access a port and make a dynamic blocking based on that. In my setup I do that and further I reset the timeout if the same IP address keeps hammering the server before the timer expires. This will be picked up by your fail2ban rules. The IP addresses then gets banned for years to come :) 6: Insure that the data in the fail2ban database has a sufficient lifespan. I think I set mine to 3 years. 7: Whitelist your own networks and at the least the IP addresses used. You do not want to be blocked. If your users log on using a VPN connection then they should be safe from being blocked. 8: Implement rspamd and configure fail2ban to check its logfile. No rules for rspamd exists in fail2ban as I remember. I hope the above gives you some ideas. It is much like catching a fish using your bare hands or a piece of wet soap. The above setup does keep my server running pretty well and with nearly no spam. Zimbra is a whole story by itself. The recent attacks fairly quickly gets exhausted. Kind Regards, Jan Hauge _______________________________________________ Fail2ban-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fail2ban-users
