New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Fail2ban may provide a false sense of security
Just throwing this out there for discussion...
The old stalwart fail2ban may not be providing the security you think it is.
Specifically, a "low and slow" attack from a botnet will go unnoticed.
Fail2ban will detect and block multiple attempts from the same IP, but not repeated attempts from different IPs.
You may want to try:
grep -c Found /var/log/fail2ban.log
and
grep -c Ban /var/log/fail2ban.log
and ponder the numbers.
Comments
We use fail2ban to save a few disk space for the auth log, not for making it secure. Key pairs or certificates are the way to security.
For SSH yes, but fail2ban has much wider applicability -- e.g. for public services such as imap, smtp that aren't secured the same as SSH.
Well had that problem this helped.
http://blog.shanock.com/fail2ban-increased-ban-times-for-repeat-offenders/
You can always tweak the config to tighten the time limits before banning.
Decent password strength makes a world of difference. Usually the time to crack with a "low and slow" is incredibly futile.
Certainly interesting. Thanks.
Fail2ban should be used as a tool used for reducing clutter in logs caused by automated scanning, not as a defense mechanism in the first place.
The applications themselves often have rate limiting, use it if possible. To go with your mail server example, both Dovecot and Postfix have that.
How would you protect an imap or smtp server from a botnet low and slow authentication attack?
indeed lowering the threshold works too in conjunction with rate limiting and using native jail fail2ban-client status info can reveal same stats as the greps
my custom fail2ban status output statistics
you can also parse your fail2ban logs to get some stats as to patterns for banned and repeated ban (restored bans) IP addresses too i.e.
Why would you not use it as an early defense mechanism in a layered strategy?
It has it's place beyond just log clutter.
Rate-limiting for postfix and dovecot are usually scaled in connections/second, or per minute, and track connecting IPs, and do nothing for a low and slow attack.
Bots brute forcing mail servers usually don't go slow nor change IPs that often. What you can do with e.g. Dovecot is to insert delay after each unsuccessful attempt.
That means that if someone tries to log in with a wrong password, Dovecot will artificially insert a delay before the "auth failed" response - that way the bot will have to wait for let's say 5 seconds before trying again. I would call that enough.
Brute forcing at a rate 1 attempt per 5 seconds becomes "slightly" ineffective very quickly.
But again, these are tracked by IP, and aren't applied in a situation where different IPs attempt a login to the same mail account.
That's certainly true - and as far as I know, there is no solution to this issue. I would say set minimum password complexity policies and let the bots do their thing.
Block with iptable by range /24 or whatever you need.
Yes. That would do for most setups. In my case I manage couple mail servers for my clients. The thing that bothers and made me setup defense is how many in house attacks happen. how meticulous the attackers are in my case the assistant of the CFO tried for whole year are more brute forcing the CFO's email getting banned every single day. She gained access in the last. Unfortunate for them I joined them just last year. Checking the logs show me that there were same ratio of attacks from internet and intranet.
I'm surprised that this had happen this firm don't have anything to steal data wise. There is no industrial espionage even after there is one bad actor who had the patience for this kind of attack. She worked there 15+ years so yes these kind of protection is required in some cases.
I experienced a distributed attack on smtps recently, which fail2ban did not detect and which I noticed only by looking at log files. I changed the fail2ban smtps config to ban after 1 failure, and collected 500 IPs in an hour. Let it run for a few hours, then dumped them all into an ipset.
You probably need to lower the threshold for fail2ban and for postfix at least see smtpd_client_auth_rate_limit http://www.postfix.org/smtpd.8.html
Dovecot has it's own mechanisms I believe with auth_failure_delay i.e. https://wiki.dovecot.org/Authentication/Penalty
If the server only has you as one user, you could set fail2ban threshold to ban after 1 failure like you did. As if you ever enter the wrong details, you could unblock yourself via out of band console access anyway heh.
Depending on the environment, you might ban legitimate people with this
Actually might serve as a good tool to weed out repeat offenders - sitting them down and explaining the virtues of using a password manager hehe
Maybe but doubtful. There's a whitelist for local ISPs. But if one of my users is vacationing in Brazil it's possible
The "recidive" (Iirc they spell it like that) rule implements longer bans and it was added a few versions ago. The version of fail2ban in the debian 9 (but not earlier) repo has it.
Yea, I would call fail2ban a security tool, not to secure something. Used properly it's a great tool!
Yep the same thing I shared earlier with official tag on it.
But the fail2ban team just named it bad. So bad I still share a link than this name.
i used a 6-digit password and it havn't been bursted so far.
my auth.log has 20+MB big.
the more dangerous, the safer it is.
LOL
But have your installed fail2ban or any similar tool?
If nothing similar is installed, it does sound quite dangerous.
Nope, believe or not, my vps is naked for a few months.
Fail2ban will cause a cpu high load due to a large auth.log when startup.
However, weakly password is not recommended.
Still waiting to be bursted... LOL
strict pubkey auth + multi-day ban times + a couple of whitelisted IPs.
I think I'll stick with this for a while.
What I've done is create a ipset whitelist of Canada/US, that should cover all networks from which my users are authenticating to postfix & dovecot, and then...
Gathered all IPs ("Found") from the fail2ban log, sorted and removed dups.
Iterated through the IP list, removing any found in the ipset whitelist.
Added the remainder to a permanent ipset blacklist.
There's an hourly cron script that looks for new fail2ban log entries, tests then against the whitelist and adds then to the blacklist as required.
You might be interested to know that of the 1,200+ collected IPs, 94% were not found in the whitelist
Yup. Thanks to that I got a nice blacklist where at least a lot of those china dudes are in.