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.
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>.
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.
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.
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.
So that I can ssh into it from various places and do stuff on my home server from elsewhere
Or, if your service is open to the internet then why does not what I said above hold true?
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
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.
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.
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).
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.
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.)
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.