How to harden against SSH brute-forcing?

someacnt@sh.itjust.works · 7 days ago

How to harden against SSH brute-forcing?

sugar_in_your_tea@sh.itjust.works · 6 days ago

There’s more to it than that.

I recommend geoip blocking anything outside of your expected operating regions in addition to using key-based logins. iptables operates at a lower level in the network stack than SSH, so the vulnerability surface is a lot lower, and blocking before something actually looks at the packets cleans up the logs. This is huge because it makes it a lot more obvious when there’s a legitimate attack.

Cover yourself with layers:

block obviously bad packets at the firewall level
eliminate insecure modes of login (only allow key-based login)
something like fail2ban to ban the few who make it through 1 & 2
use a secure root password so if someone does get in, they’re less likely to get root access
have your services run as non-privileged users to limit issues if something gets compromised

If you only do one thing, it should be only allowing key-based logins. If you do two, run SSH on a non-standard port or set up geoip blocking (second is more work, but a lot more effective).

troed@fedia.io · 6 days ago

Still no. Here’s the reasoning: A well known SSHd is the most secure codebase you’ll find out there. With key-based login only, it’s not possible to brute force entry. Thus, changing port or running fail2ban doesn’t add anything to the security of your system, it just gets rid of bot login log entries and some - very minimal - resource usage.

If there’s a public SSHd exploit out, attackers will portscan and and find your SSHd anyway. If there’s a 0-day out it’s the same.

(your points 4 and 5 are outside the scope of the SSH discussion)

sugar_in_your_tea@sh.itjust.works · 6 days ago

It’s also one of the biggest targets for attack. Here’s a somewhat recent CVE and here is another. Staying on top of security patches is absolutely critical, and many don’t do that.

The best security practice is to layer your protections.

your points 4 and 5 are outside the scope of the SSH discussion

They’re not about SSH, sure, but they are relevant to securing a system to remote access. Always assume your security infra will be compromised and plan accordingly. Generally speaking, the more layers, the better.