Hacker News Reader

Comment by lamontcg | Hacker News Reader

Yeah I suspect that up to date openssh with a config that passes ssh-audit's checks, with a fail2ban config, along with an ed25519 key unlocked by a yubikey will be entirely adequate security for SSH. Then time would be better spent securing VPNs and reducing internal trust.

Bit like having a front door that would withstand a C4 blast, but now all your windows are shattered.

View on HN

Fail2ban is also theater on properly configured SSH servers and has been since it was written.

I've often used fail2ban not as a security control, but a log hygiene solution. I don't need 10000s of failed login attempts in my logs, it's annoying. I have full faith it's not stopping a server compromise, but it absolutely keeps the noise level down.

I had inherited a server (Arch linux) which ran something like fail2ban (can't remember what it's called). It slowed down the machine tremendously, because the iptables lists became very big, and every packet started taking up too much CPU. I had to disable it (switching to whitelisting instead). Did you ever encounter something like this with fail2ban?

at a previous job i cleaned up after such mess. they used to have fail2ban adding thousands of rules without ever deleting them automatically. I replaced it with a pam module that maintained an ipset for addresses with failed login attempts.

ipset is very efficient.

While fail2ban might still be a good practice, I've found that simply using a non-standard SSH port is just as effective at keeping the logspam down.

I don't think anyone but the most uninformed would argue that fail2ban is an actual secure measure, it's more of a log file annoyance reducer. Obviously if you leave remote root enabled and the root password is one of a few dozen thousand common words that exist out there in public-domain password data sets, fail2ban isn't going to help much. As with the example of all the random botnet things out there that randomly try a popular list of dozens of common usernames (admin, root, webmaster, etc) with common passwords.

With things other than SSH it can also be effective in the most rudimentary first level filtering out of spam, various things that attempt to relay mail through my server get themselves first banned, and then banned for a longer time after they keep re-trying. Again with primarily the goal of having less cluttered postfix logs.

Fail2ban is also useful if you do leave something misconfigured. Mistakes happen so having a little redundancy is OK.

Apply your redundancy to whatever is generating and safeguarding your SSH configurations.

What does this even mean? I'm the one who generates the ssh configuration for my computer clubs server...

fail2ban is the same as having high number of rounds on password hashes to slow down attackers, and it takes about 30 seconds to install+configure. it makes a lot more sense than the title here, but is only useful as security-in-depth and can't replace other good practices. high rounds on a password hash is also equally useless if you use "password123" or something like that.

i've also seen significant reductions in idle cpu by using it and sending offenders to the timeout bin for 24h.

thanks for calling me "most uninformed" though.

I wasn't calling you most uninformed, your statement is totally correct, I was referring to any persons who might argue that fail2ban is purely useless as security theater. What I said was that fail2ban is useful as an annoyance/log clutter reducer, but not something that's an actual security measure which would be suitable to protect a poorly-configured sshd.

Reply on news.ycombinator.com