Fail2ban - how to stop "slow brute force"

SYSTEM INFORMATION
OS type and version Ubuntu Linux 20.04.4
Webmin version 2.000
Usermin version 1.860
Virtualmin version 7.1-1
Theme version 20.00
Package updates Alle installierten Pakete sind auf dem aktuellesten Stand

I have some slow attacks from Russia.
They are pretty clever with their hacking attempts . They doing something like a slow brute-force… they only try for 3 logins per hour:

What would you suggest to stop them.
Here is what I do try, any maybe you can tell if that’s a good Idea or if there are better ones:

  1. I’ve opened the existing /etc/fail2ban/filter.d/proftpd.conf configfile and removed the first line of the failregex to put it in a seperated filter (to be able to set other ban-times.
  2. I’ve created a new filter named proftp_noSuchUser (/etc/fail2ban/filter.d/proftp_NoSuchUser.conf) and put in there the same as in proftpd.conf, but for failregex only the first line (which was removed from proftp)
  3. Then I’ve created a new jail which check for the last 3,5 hours, if there are more then 9 attempts with a wrong username from the same ip, and if, I ban it for a month.

Webmin - leak of information

Unfortunately it’s not clear, what kind of inputs are possible for the values. Must I write it in seconds (as fail2ban generally use it that way), can I use 10m for 10 Minutes, or 10d for days?

Would be an big enhancement if we have a short note what kind of values are possible in the input fields.
I’ve found that on many places in Webmin & Virtualmin those informations are missing.

Ok, seems to work, the Russian IP-Address are now blocked by fail2ban

And BTW, I’ve figured out, thet 10m, 10d or 10w are working well as input values in the fields of webmin.

Hope this little tutorial helps somebody out, which might recognize the same kind of attack at their servers.

At the rate of three attempts per hour it would take them a lifetime, quite literally, to brute force their way into your server. You should do nothing and let them.fly under fail2ban’s radar.

They can’t do you much harm that way.

1 Like

Yep, unless your password is 12345678 or password, I don’t think you should concern yourself overly with three attempts per hour.

If you were to make fail2ban that aggressive, you’re going to lock yourself out, I guarantee it. (Unless you always use key-based logins, which is recommended if you have that ability, and don’t need to allow password logins at all…in which case you could disable passwords.)

1 Like

Hi All,

I offer this in case anyone else arrives here with a similar question.

I agree that a slow attack like this is unlikely to yield any results for the attacker but I pay close attention to the logwatch reports that arrive daily and a number of slow attacks like this make it more difficult to see other information that might be important because of the “noise”. So for what it is worth, this is what I do. If nothing else it gives me some more peace of mind.

I make use of the recidive filter but because I don’t want to give genuine users more trouble I have set the criteria to figures that are unlikely to catch a real user like - matches 100 in 10 minutes before ban but the ban time to 2 months.

Then, when I find an offending IP number I run “fail2ban-client set recidive banip 111.222.333.444” (obviously IP number to ban). That works a treat and I have reduced the offenders to very few. Now my logwatch report is very clean.

Hope that helps someone.

PS. I have only ever found attackers using the full email address as a username, I use an alternative pattern which is available to be set using the Vmin interface.

1 Like

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.