enable ssh brute force protection not working

[RMerlin]

This also matches the logs of all the servers that I manage. lastb returns virtually nothing for servers where I moved SSH to a non-standard ports, but tons of attempts for those which I haven't - once that port responds, malwares try to log in using a list of pre-defined usernames: root, tom, tomcat, etc... Some of these servers were nearly DoS'ed by these login attempts in the past (as eventually OpenSSH would say "that's enough" and stop answering connections, which triggered my Nagios monitoring on these servers were SSH stopped responding).

All issues that are resolved by moving SSH to a non-standard port.

Check "lastb"'s output sometime to see what I mean.

 

[sfx2000]

I used netfilter to monitor the incoming packets and log the ones that matched the specified port to a file. I also cross referenced the netfilter packet counts with the contents of the file to make sure I wasn't missing anything.

tcpdump is your friend here... look at the wire, things happen there before netfilter or the app can log it.

 

[sfx2000]

Some of these servers were nearly DoS'ed by these login attempts in the past (as eventually OpenSSH would say "that's enough" and stop answering connections, which triggered my Nagios monitoring on these servers were SSH stopped responding).

All issues that are resolved by moving SSH to a non-standard port.

Anyways - certs generally work - just be sure that the passphrase is not empty...

I keep port 22 up, with openssh, I have a specific user, and a sufficiently strong password (pwgen is your friend here) along with strong ciphers, turning off the deprecated ones...

Lots of folks knock on the door - but guess what, they're going to anyways, even if you move the ssh daemon port - all the port move does is limit the logging in syslog, and that's something similar to putting one's head into the sand and pretending it doesn't happen.

So security thru obscurity - it's nonsense - the 'bots are still going to hit it - I'd rather know than not.

Configure sshd right, and that won't happen... and then use iptables to limit (or the ufw wrapper) connections to that port

PermitRootLogin no
MaxStartups 2:30:10
MaxAuthTries 3
LoginGraceTime 30​

 

[john9527]

Sorry, but I stand by my recommendation to move the port. The end goal for me is to minimize your chances of getting hacked. To me, it's obvious that moving the port helps to accomplish that goal (along with all other standard recommendations, use a cert, etc). That you continue to argue otherwise, is somewhat bewildering to me.

That being said, everyone is free to adopt what they believe is 'best practice'....the arguments have been made and anybody reading this thread can decide what they want to do.

 

[RMerlin]

Lots of folks knock on the door - but guess what, they're going to anyways,

Re-read what I wrote about DoS effects of leaving a potential door on the default port. I have first-hand experience managing over 120 Linux servers that shows that moving the port DOES help prevent them. It's not about hiding in the sand, it's about having a malware issue just one SYN packet and move on to another IP versus having it repeatedly attempt multiple connections within a few seconds because that first attempt showed something was answering on that port.

 

[sfx2000]

That being said, everyone is free to adopt what they believe is 'best practice'....the arguments have been made and anybody reading this thread can decide what they want to do.

agreed - and the brute force limit rule is a good thing to have in any event

Happy Holidays guys!

 

[sfx2000]

Merry Xmas - ports open, and then service discovery...