Hacker News Reader

Comment by cm2187 | Hacker News Reader

The problem is that you are also at the mercy of passwords selected by your users for smtp, imap, etc. So you still need some defence against brute force.

For administrative protocols (ssh, rdp, etc), I am a firm believer in IP whitelists, which give you the additional peace of mine of protecting you against future zero days, unless they affect the firewall.

View on HN

For SSH simply disallowing passwords entirely removes this problem. For me that's the one single thing that dramatically improves defense against any kind of brute force or untargeted attack.

I'm actually shocked that you're the first one to mention it. Only use public key logins and if you're not targeted and if it's practical in your workflow change the port (definitely not for security, only so that sshd won't eat as much CPU time from bruteforce attempts).

Just make sure you don't use a port any higher then 1024 or else a non root process can start up and take its place if the real one crashes.

Oh, good to know, I will ignore this advice and excitedly await for this to happen to me

That's an excellent point. I painted myself into a corner here because I am letting some of my friends use the server as well. Have to gently transition them to public key usage only now.

Give them a reasonable deadline, and just disable password login afterwards.

This isn't something they should have trouble understanding/accepting.

You can restrict password auth to particular users/groups, which also greatly reduces the attack vector.

Or require OTP for password authentication.

Nowadays, if you accept plain user-chosen passwords on SMTP or IMAP, you're already in trouble anyway. Often, the attacker doesn't even have to guess because your users likely re-used the same password across different services...

Reply on news.ycombinator.com