If you have only public key authentication enabled with SSH I honestly don't understand why people bother with things like fail2ban. It just adds more moving parts with very little security gain.
The real risk is a zero-day in OpenSSH and fail2ban probably isn't going to protect you from that. In that case you are better served by putting another layer of defense in front of SSH like a VPN.
fail2ban is the kind of pseudo-security applied just because someone's cousin mentioned that in his blog.
It provides zero security. If your endpoint uses default usernames you will be shot anyway because of IP spread. If your security is good you add something that will block your legitimate connection when you are in the middle of nowhere and, shit, cannot access your <some service>.
"security" is a term that has to be defined in relation to a threat model. If your threat model is an attacker with a static IP hammering your server, fail2ban does provide some security against that sort of attacker.
No it does not. If the packet is at your door it is too late already. Then either it does not matter in which case you do nothing, or it matters (DoS) and then you have other problems.
You are right that security works in the context of a threat model. There are however useless tools that give a false sense of "security" that do not fit in any reasonable model.
I have cases where I block whole ranges of IPs for "legal" reasons - it does not make sense but there you are, the ones who write the rules are not the ones who actually know the stuff.
> No it does not. If the packet is at your door it is too late already.
Too late for what? Again, it only makes sense to talk about "security" in the context of a threat model. You can debate the reasonableness of that threat model, but that's another discussion.
My threat model(for the sake of argument :^)) is an attacker with a static public IP address trying to bruteforce access to my service via repeated login attempts.
I'll maintain(for now) that fail2ban can be an effective tool that does provide some security against an attacker of this kind.
You wrote that someone is hammering your IP. This was for me the definition of a DoS. Nothing on your side will mitigate that.
But it does not really matter anyway. Your threat model is a single IP attacking you. What are you concerned about? That they will find services that are exposed and attack them? You should be securing these.
You will never be attacked by one IP. The exact same attack will be done from many, many IPs and you do not want to defend against IPs attacking you, but against them exploiting a vulnerability on your side.
Of course there is the "why not an extra layer of protection". This is great when you want to obscure something (moving a port for instance) because this does not have an effect on your system. Just imagine what happens when fail2ban goes south and blocks all addresses, or half of them, or yours because you tried too many times. This is a moving part that is actually dangerous.
If your server is on the internet with a public ssh server then it is probably providing some sort of internet service. That internet service is almost always easier to DoS than your openSSH server. If you are not providing a internet service then why is your SSH open to the internet?
What is the networking difference between a service for yourself that you want to access from "various places" and a public service with auth checks for your key?
Sure, but are L7 attacks easier than L4 against those servers? Adding more layers/software has a cost in configuration, maintenance, attack-surface, etc.
You're not wrong, but I'd say fail2ban still has value for junior operators seeking to reduce load and increase stability. If you don't know how to harden SSH, fail2ban is offers a much friendlier way to reduce the volume of logspam, CPU burn, and network traffic. It's just a pity that it's understood/documented/pitched as something that substantially increases security.
then you do not open it to Internet. Otherwise you patch aggressively, you use ssh keys and not passwords and you move it to some random port to hide it a bit (it actually helps)
> logspam
you can filter this out in your log management tool
> CPU burn
if this is your concern, then you have a hep of issues you need to address. I have never seen a CPU perf hit because of such behaviour (there are cases where it happens, butthis is due to a vulnerability of the service)
> network traffic
the packet is here already, there is nothing to reduce
Moving ssh off of port 22 makes it a pain in the ass to work with. Ports are standardized for a reason.
Authentication attempts are a useful security signal; I don't want to filter them out. I want hosts running dictionary attacks to not be able to connect to my services in the first place. If you are running an SSH bot, then I don't want you on my website or anything else.
> Moving ssh off of port 22 makes it a pain in the ass to work with. Ports are standardized for a reason.
yes, they were standardized in the ol' good times :) If you have a limited amount of people/services connecting then it is manageable. But of course YMMV.
> Authentication attempts are a useful security signal; I don't want to filter them out. I want hosts running dictionary attacks to not be able to connect to my services in the first place. If you are running an SSH bot, then I don't want you on my website or anything else.
enumeration and brute force on SSH fail by design when using keys.
As for other services I do not see how this helps - you will block random IPs hoping that a vulnerable site is not taken over if they happen to get back. It is not common (at least in my monitoring of several honeypots in various locations) to have the same IP being particularly visible. Sure they are back sometimes but this is quite exceptional.
Anyway - it is not worth the hassle, better have proper hardening.
> yes, they were standardized in the ol' good times :) If you have a limited amount of people/services connecting then it is manageable. But of course YMMV.
Agreed. I've never found it difficult to manage this. I already tend to configure SSH hosts in my ~/.ssh/config file anyway so that I don't have to remember every IP and port combination for every host I have access to when I want to use SSH (or something that relies on the SSH protocol like rsync or scp).
fail2ban increases your server performance. It cuts down on enormous amounts of logging from failed attempts, and reduces the CPU used to deal with the failures.
Some sites get a mind boggling amount of attempts. For example I sysadmin some Jewish sites, and they get exponentially more hacking attempts than the sites not mainly used by Jews. (This was before the current war mind you, I'm sure it's worse now.)
> People don't believe it's possible for software to be secure
Rightfully so. You'd statistically be almost always right considering a software unsecure given enough time (for the vulnerabilities to be introduced then found).
> need a secondary defense to "protect them"
Nothing wrong with that. It's called Defense in Depth and is rather advised. Once you understand that security measures are not bulletproof, stacking them proves to be an easy way to increase protection.
The case of fail2ban is not trivial: reducing log noise is a great perk, and can indirectly help with monitoring (you'd more easily notice suspicious behaviour if it's the only thing on your logs), but it comes at the small cost of setting it up, and accepting the risk of having a shared IP unwillingly blocked.
Fully agree. Limiting the networks which can access your server will help, e.g. limit access to just your local provider or your workplace and you'll see no attempts from Brazil, China, ... unless you are located there, of course ;-)
That's manageable with a bit of preparation: when I'm travelling, I allow access from other networks, e.g. those from phone providers. Or add a web form where I activate the IP address with a cryptographically signed "token" which the server can verify and then add the IP address to the set of allowed ones.
Used one or the other every now and then in the last 10+ years and still have my attackable footprint small the rest of the time.
The real risk is a zero-day in OpenSSH and fail2ban probably isn't going to protect you from that. In that case you are better served by putting another layer of defense in front of SSH like a VPN.