I wrote about using fail2ban with postfix[0] almost 15 years ago for blocking IPs that were sending to unknown email addresses on my server. It was a godsend for blocking tons of spam back then.
fail2ban is a real pet peeve of mine because anyone security conscious enough to deploy this will have likely already mitigated any actual security risks this could help with either by using a strong password or public key authentication.
That leaves noise in the logs - which sure, it's nice to reduce, but using an alternative port can help here.
I may sound like a spoilsport - but the fact that there have been a number of security vulnerabilities (https://www.cvedetails.com/vulnerability-list/vendor_id-5567...) in this project, make it worse than security theatre, it actually increases risk whilst not at all reducing it.
Yes. At this point, fail2ban has become almost a shibboleth for people following security checklists as opposed to reasoning about a coherent threat model. This is a perennial topic on HN, and almost always devolves to some appeal to grooming logs, because of all the authentication errors fail2ban is presumably preventing.
Don't use fail2ban. (Don't use passwords, either!)
I am one of the people to whom you refer. I read about fail2ban in a "Linux Server Bible" e-book around 2010 and have used it on all of my servers since, even though I am careful with my keys and use password-less login.
While I agree fail2ban is a wrong tool to prevent password brute force - better authentication mechanisms should be used instead - it has its uses. For example, it can be used to automatically ban (or alert about) dumb http scanners like gobuster. I am not saying, a determined attacker cannot bypass it, but if it saves me some hassle and raises the bar for them, why should not I do it?
More general, some attacker actions, especially during recon, rely on making many attempts to connect, fetch an URL, resolve FQDN, etc., these could be detected and automatically responded to, making attacker’s job harder and providing extra visibility to defenders.
> That leaves noise in the logs - which sure, it's nice to reduce, but using an alternative port can help here.
No, it cannot. As a sysadmin I do not want to get into user training about telling people about alternative ports and tweaking their CLI habits and any scripts that they have.
If you want to further cut down on the log noise get an IPv6 address (and drop IPv4)—good luck to anyone trying to scan a /64 for open ports.
I can cofirm this, I swapped one of my cloud VMs to ipv6 only ssh and after 11 months I never seen a single ip besides mine attempt to login. This was using the default port 22.
> That leaves noise in the logs - which sure, it's nice to reduce, but using an alternative port can help here.
Shifting services to alternate port numbers will stop very stupid scanners but it does not stop the worst offenders IME. Basically it just means you'll only get the really obnoxious sources that try everything ignoring responses.
> I may sound like a spoilsport - but the fact that there have been a number of security vulnerabilities (https://www.cvedetails.com/vulnerability-list/vendor_id-5567...) in this project, make it worse than security theatre, it actually increases risk whilst not at all reducing it.
Given the age of the project and that there's been a whopping NINE vulnerabilities found in its lifetime, this is a great take. By this same logic you better disable OpenSSH everywhere. In the same timeframe as Fail2Ban has has reported vulnerabilities, OpenSSH has had at least 60: https://www.cvedetails.com/vulnerability-list/vendor_id-97/p...
"Worse than security theatre" is quite the statement given they reported and fixed those issues in timely fashions.
If you apply the principles of defense in depth, using the network layer to deny access to misbehaving remote hosts is an obvious win on a lot of fronts and hardly qualifies as security theatre anymore than using a network firewall is security theatre.
It's not 9 vs 60, it's 9 vs 0 if you don't use it, with no loss in functionality. And GPs point is that it's not defense in depth, the vulnerabilities in Fail2Ban can compromise the security of other layers.
If we limit the use case to a single service, fail2ban is just a log cleaner. What it's detecting is merely the service that you're protecting doing its job properly. Now if you analyze the collected data and do something smarter with it, that's another story.
"Don't use fail2ban because you don't need it if you do XYZ"
I'm not so sure that's a good reason to be honest. And if you're worried about CVE's, well, you'll be using handwritten, hand delivered notes before long. Keep your systems patched, keep them tidy, none of this is likely to affect you, fail2ban or not.
Yup. I see many resources for self-hosting recommend fail2ban for e.g. SSH. But I always disable password-based SSH logins on all of my computers. The one niche use case I can see for fail2ban is possibly reducing the amount of hits to /wp-login.php and /cgi-bin in your web server (or reverse proxy's) access logs.
If someone is performing a denial of service attack from one I.P. address then this will help.
To tptacek's point, you've got to ask yourself is a denial of service attack in your threat model?
The reality is most folk set up fail2ban after seeing auth failures in their logs, not service degradation.
If you're considering a denial of service attack in your threat model, then I'd probably also consider a DDoS attack and there are likely more effective solutions here (a firewall or CDN).
And don't forget you're using some of those precious CPU cycles to parse the auth logs, with python no less :-)
Absolutely agree. Fail2ban, sooner or later, bans you from your services becasue something in the configuration went wrong.
It does not protect against anything serious: you must have proper credentials/MFA or certificates and therefore bots can check as much as they want.
There is no protection against DoS either.
And I agree about moving the port - I only see a tiny activity in my logs coming from bots when my ssh port moved away. Obviously 443 is there to stay (this is a public service) so I will get whatever comes.
One nice thing I'll say about fail2ban is that it can fire off reports with decent logs to the networks responsible alerting them to compromised systems and bad actors.
I agree that almost all use cases of fail2ban are little more than feel-good exercises.
Failed login attempts (the noise) are not where bad things happen. What we should be concerned with is if the attempt succeeds but is not from a legitimate user. fail2ban is no help there.
Having said that it might be a decent way to collect IPs. At one point I was distributing the collected IPs from VMs and blocking them for the whole network. fail2ban does provide mechanisms to do this.
At a former employer I hooked up a random Debian box to the corp network. Of course I ran fail2ban, in addition to a host of other lockdown measures. Without fail every morning at the same time some random corp scanner would start hammering on the ports, and fail2ban would kick in and block the scanner. After the default expiration time the rules blocking the scanner would expire, and it would happen again the next morning. This probably continued going on for several weeks or perhaps even months after I left the company.
You would get seriously yelled at by my team if you did this in my company.
The corporate scanner are not there for fun or because security loves to do scans. They are there exactly because they are random wannabe sysadmins who will plug in a box that ends up compromised.
A scanner may help to locate it and possibly warn about the issue. And only maybe.
Do not make life difficult for people who already have they hands full of constant vulnerabilities, fighting corporate crap and being the bad guys because they audit stuff.
I was first exposed to fail2ban by some PBX server suite I was setting up. Totally cannot remember the name of it, but it checked to see if the fail2ban service was running. If it was not the PBX service would not start and throw a are you insane error message. Saved a lot of new kids like me at the time who were just fooling around I bet.
In security circles RDP is called “ransomware deployment protocol” - basically one should never expose it to the internet.
Make yourself a vpn box or some Linux with ssh and do port forwarding and allow RDP from that Linux host. OpenVpn or ssh are much better to be exposed to the internet.
I made ts_block. It solved a particular problem I had at a particular time. Nobody should be doing RDP across the Internet w/o a VPN but, apparently, people still do it.
Also be careful that you've used CSRF and other origin protections. Otherwise competition can DoS your legit users by rapidly cross posting via js from their own site. Not likely in enterprise world but could happen in less than ethical industries.
Readit News
[0]: https://www.dp.cx/blog/postfix---fail2ban---win.html
That leaves noise in the logs - which sure, it's nice to reduce, but using an alternative port can help here.
I may sound like a spoilsport - but the fact that there have been a number of security vulnerabilities (https://www.cvedetails.com/vulnerability-list/vendor_id-5567...) in this project, make it worse than security theatre, it actually increases risk whilst not at all reducing it.
Don't use fail2ban. (Don't use passwords, either!)
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
More general, some attacker actions, especially during recon, rely on making many attempts to connect, fetch an URL, resolve FQDN, etc., these could be detected and automatically responded to, making attacker’s job harder and providing extra visibility to defenders.
Anyone who manages servers professionally does not read logs anymore and does not care about obvious things like people brute-forcing.
Reading ssh logs on your single VPS is security LARPING. Discussing faill2ban as well :)
No, it cannot. As a sysadmin I do not want to get into user training about telling people about alternative ports and tweaking their CLI habits and any scripts that they have.
If you want to further cut down on the log noise get an IPv6 address (and drop IPv4)—good luck to anyone trying to scan a /64 for open ports.
Shifting services to alternate port numbers will stop very stupid scanners but it does not stop the worst offenders IME. Basically it just means you'll only get the really obnoxious sources that try everything ignoring responses.
> I may sound like a spoilsport - but the fact that there have been a number of security vulnerabilities (https://www.cvedetails.com/vulnerability-list/vendor_id-5567...) in this project, make it worse than security theatre, it actually increases risk whilst not at all reducing it.
Given the age of the project and that there's been a whopping NINE vulnerabilities found in its lifetime, this is a great take. By this same logic you better disable OpenSSH everywhere. In the same timeframe as Fail2Ban has has reported vulnerabilities, OpenSSH has had at least 60: https://www.cvedetails.com/vulnerability-list/vendor_id-97/p...
"Worse than security theatre" is quite the statement given they reported and fixed those issues in timely fashions.
If you apply the principles of defense in depth, using the network layer to deny access to misbehaving remote hosts is an obvious win on a lot of fronts and hardly qualifies as security theatre anymore than using a network firewall is security theatre.
I'm not so sure that's a good reason to be honest. And if you're worried about CVE's, well, you'll be using handwritten, hand delivered notes before long. Keep your systems patched, keep them tidy, none of this is likely to affect you, fail2ban or not.
To tptacek's point, you've got to ask yourself is a denial of service attack in your threat model?
The reality is most folk set up fail2ban after seeing auth failures in their logs, not service degradation.
If you're considering a denial of service attack in your threat model, then I'd probably also consider a DDoS attack and there are likely more effective solutions here (a firewall or CDN).
And don't forget you're using some of those precious CPU cycles to parse the auth logs, with python no less :-)
It does not protect against anything serious: you must have proper credentials/MFA or certificates and therefore bots can check as much as they want.
There is no protection against DoS either.
And I agree about moving the port - I only see a tiny activity in my logs coming from bots when my ssh port moved away. Obviously 443 is there to stay (this is a public service) so I will get whatever comes.
Failed login attempts (the noise) are not where bad things happen. What we should be concerned with is if the attempt succeeds but is not from a legitimate user. fail2ban is no help there.
Having said that it might be a decent way to collect IPs. At one point I was distributing the collected IPs from VMs and blocking them for the whole network. fail2ban does provide mechanisms to do this.
Deleted Comment
Deleted Comment
Dead Comment
Brute.Fail: Watch brute force attacks fail in real time - https://news.ycombinator.com/item?id=36169954 - June 2023 (259 comments)
Ask HN: How to protect against endless SSH login attempts to my server? - https://news.ycombinator.com/item?id=34077205 - Dec 2022 (27 comments)
The corporate scanner are not there for fun or because security loves to do scans. They are there exactly because they are random wannabe sysadmins who will plug in a box that ends up compromised.
A scanner may help to locate it and possibly warn about the issue. And only maybe.
Do not make life difficult for people who already have they hands full of constant vulnerabilities, fighting corporate crap and being the bad guys because they audit stuff.
We have a life too.
Found this alternative:
https://github.com/DigitalRuby/IPBan
Make yourself a vpn box or some Linux with ssh and do port forwarding and allow RDP from that Linux host. OpenVpn or ssh are much better to be exposed to the internet.
https://github.com/EvanAnderson/ts_block
https://github.com/Zeziroth/Cancer2Ban
Shockingly it still works fine on Server 2022.
On another host I tried port 443, hoping to disguise it to appear like SSL. No any difference.
Also, there are services, which already publishing all my (and yours) open ports. Here is the report for my IP:
https://search.censys.io/hosts/104.63.172.143 (It's public anyway)
If for some reason you still needed password auth enabled I'd be inclined to still use f2b.
You can white list specific IPs though