Comment

Comment on How to harden against SSH brute-forcing?

fail2ban is mandatory equipment for any ssh server accessible to the public especially on its default port. It’s highly configurable, but the default settings will do fine at making it statistically impossible for any user or password to be brute forced.

source

Sort:hotnew top

cron@feddit.org ⁨1⁩ ⁨week⁩ ago
I don’t really get the love for fail2ban. Sure, it helps keep your logs clean, but with a solid SSH setup (root disabled, SSH keys enforced), I’m not bothered by the login attempts.

source
- sugar_in_your_tea@sh.itjust.works ⁨1⁩ ⁨week⁩ ago
  You should be. Most of it’s noise, but if there’s a serious attack, you’ll appreciate clean logs.
  
  I think fail2ban is nice as like a third or fourth layer of defense. In order of my priorities:
  
  key-only login, root login completely disabled
  
  solid root password, and user privilege separation (have each service use its own user)
  
  geoip bans - if you never plan to support clients in a given region, block it at the firewall level (or better yet, whitelist the handful of regions you care about); I do this by port, so SSH gets a much more restricted set of allowed regions than HTTPS
  
  fail2ban - especially if you have a relatively large whitelist
  
  only access SSH over a Wireguard VPN - Wireguard doesn’t show up in port scans, and SSH can bind to the VPN host instead of 0.0.0.0, so the ability to login via SSH will be completely hidden
  
  If you’re not going to do 3-5, at least change the default SSH port to cut down on log noise.
  
  source