[SOLVED] A few questions about configuring Fail2Ban
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hello,
I have a few questions about configuring Fail2Ban:
1- The following options exist in two sections of Fail2Ban. One under [DEFAULT] section and another under the service configuration section:
Code:
maxretry = 3
findtime = 1d
bantime = 4w
Why?
2- If I set the value of findtime to 1d, that means the number of times that the wrong password is entered must happen during a day? For example, 3 times in one day.
3- What is the best value of findtime to avoid brute-force attack?
Hello,
I have a few questions about configuring Fail2Ban:
1- The following options exist in two sections of Fail2Ban. One under [DEFAULT] section and another under the service configuration section:
Why?
So that different services can have different configurations but if one isn't specified then the default will be used.
Quote:
Originally Posted by Jason.nix
2- If I set the value of findtime to 1d, that means the number of times that the wrong password is entered must happen during a day? For example, 3 times in one day.
Pretty much. However 3 / 1d is crazy unless you've other mitigating factors to stop legitimate users getting locked out. Brute force attacks work by sending a lot of requests in rapid succession, so a smaller findtime is more appropriate.
Quote:
Originally Posted by Jason.nix
3- What is the best value of findtime to avoid brute-force attack?
So that different services can have different configurations but if one isn't specified then the default will be used.
Pretty much. However 3 / 1d is crazy unless you've other mitigating factors to stop legitimate users getting locked out. Brute force attacks work by sending a lot of requests in rapid succession, so a smaller findtime is more appropriate.
Hello,
Thank you so much for your reply.
If you define findtime = 10s and maxretry = 3, then the hacker enters the password twice under 10 seconds and enters the third time in 11 seconds, then will he\she be blocked?
If you define findtime = 10s and maxretry = 3, then the hacker enters the password twice under 10 seconds and enters the third time in 11 seconds, then will he\she be blocked?
Why would you want to have findtime set so crazy low? Remember there's "reaction time" involved here, which is the delay between sshd writing the failed attempt to the logs and Fail2Ban reading the logs. In general this will be low, but on a heavily loaded system there may be a reaction delay.
If you're looking to stop bad actors attempting to access / brute force your system, a bit of research, even reading your own log files would show that the typical attack vector is an attempt every few seconds. A typical pattern is also to try a single password and if that fails to "back off" for a few seconds then try again.
From experience I find the default values are sufficient to discourage automated attempts.
Why would you want to have findtime set so crazy low? Remember there's "reaction time" involved here, which is the delay between sshd writing the failed attempt to the logs and Fail2Ban reading the logs. In general this will be low, but on a heavily loaded system there may be a reaction delay.
If you're looking to stop bad actors attempting to access / brute force your system, a bit of research, even reading your own log files would show that the typical attack vector is an attempt every few seconds. A typical pattern is also to try a single password and if that fails to "back off" for a few seconds then try again.
From experience I find the default values are sufficient to discourage automated attempts.
Hello,
Thanks again.
I think to prevent brute-force attack, findtime value should be 1s, but as you said, the best option is to look at the SSH logs to determine the best value.
How can I tell Fail2Ban to block an IP address if it enters the wrong password 3 times regardless of the time interval?
I believe it is bantime = -1. If you actually uses password only, then short findtime will ban your users often simply because they think they type in the wrong password and they will ask but you to unban them all the time. I find setting it to a few minutes suffices. Remember, this is for brute force /well known account and passwords. It is better to just use public keys auth, or integrate one time passwords using gauth or security devices. That way, no one has a "real" password.
I think to prevent brute-force attack, findtime value should be 1s, but as you said, the best option is to look at the SSH logs to determine the best value.
So how do you know it's a brute-force attack if you're only looking at 1s? The signature of brute force is prolonged multiple password attempts. Many skript kiddy scripts will back off slight or attempt to randomize time between tries.
Quote:
Originally Posted by Jason.nix
How can I tell Fail2Ban to block an IP address if it enters the wrong password 3 times regardless of the time interval?
Depending on how your regular users interact with the system this isn't a particularly clever thing to do as it doesn't allow for things like regular user errors. Say I enter my password wrong because I used an old one, then enter the right one, then do the same thing a couple of times over the next few days, I'd get banned. Now maybe that's the behavior you want, but it will really annoy your regular users.
So how do you know it's a brute-force attack if you're only looking at 1s? The signature of brute force is prolonged multiple password attempts. Many skript kiddy scripts will back off slight or attempt to randomize time between tries.
Depending on how your regular users interact with the system this isn't a particularly clever thing to do as it doesn't allow for things like regular user errors. Say I enter my password wrong because I used an old one, then enter the right one, then do the same thing a couple of times over the next few days, I'd get banned. Now maybe that's the behavior you want, but it will really annoy your regular users.
Hello,
Thank you so much for your reply.
1- So what settings do you recommend to protect against brute-force attacks?
2- I want to be blocked for one day if a person enters wrong password three times during the day. Is it possible?
The person connecting gets 5 tries within 20 minutes. If they fail the 5 attempts, they start with a 20 minute ban. If they come back after the ban and fail again, the ban doubles, and will keep doubling after the failed attempts.
I also use a non-standard port so I'm not bombarded by bots.
I think in the years I've been running my server, only one person/bot was persistent enough to get a ban for several weeks before giving up.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.