News for hackers. Stuff that matters.

A comment on SSH Brute Force – The 10 Year Old Attack That Still Persists. Parent comment

Re:SSH Brute Force – The 10 Year Old Attack That Still Persists by voidlogic on Monday July 15, 2013 @12:52PM (#6046773)
I agree that changing the port is not a great security measure in theory and I think it should be last of a large number of things a person does to secure SSH.

BUT- I worked at a company a while back that had fail2ban notify us when by E-mail when it banned people. Changing the SSH ports dropped the bans per 6 month from 80-60 to 1-2. So while its certainly not the only thing you should do, there is something to be said for obscurity (in addition to existing real security of course).

[ Parent | on HN ]
Re:SSH Brute Force – The 10 Year Old Attack That Still Persists by bradleyland on Monday July 15, 2013 @01:38PM (#6047150)
Not to mention the hardware resources. Prior to changing our SSH port, the fail2ban process was #3-5 in terms of CPU time on many of our boxes. Changing the SSH port puts it out of contention for even the top 10.
[ Parent | on HN ]
Re:SSH Brute Force – The 10 Year Old Attack That Still Persists by swinglock on Monday July 15, 2013 @03:49PM (#6048123)
If you must then just limit connections per minute that can be opened per address to the sshd port in the host firewall instead. Sshd should be configured to close the connection after a number of failed logins. Now you get the same effect without a daemon parsing logfiles.
[ Parent | on HN ]
Re:SSH Brute Force – The 10 Year Old Attack That Still Persists by bradleyland on Tuesday July 16, 2013 @10:04AM (#6051903)
I recently added UFW configuration to my provisioning scripts, so we now use UFW's 'limit' rules to do that on the port we use for SSH. We could probably get away with moving it back to the default with this in place.
[ Parent | on HN ]