Slowing Down SSH Authentication Attempts
I finally found a nice and simple way to slow down the thousands of SSH probes I get every day without changing the port number (though that's only because I'm too lazy to remember to set the port number to connect to). This article on Using iptables to rate-limit incoming connections pretty much gives a good copy / paste solution that I threw in and quickly tested, and it works as advertised. Hopefully now the numbers from logwatch will go down a bit. I got 11,000 thursday, followed closely by 20,000 on monday. They must really like me!
1 TrackBacks
Listed below are links to blogs that reference this entry: Slowing Down SSH Authentication Attempts.
TrackBack URL for this entry: http://arcterex.net/mt/mt-tb.cgi/3763
» DenyHosts Implemented on UFies from UFies.org
Hey there guys.... I've implemented DenyHosts on UFies. Basically this is a way to prevent the sometimes more than 20,000... Read More
I looked at keys as well, but I like to be able to login from internet cafes or whatever, and relying on my memory for a keyfob with my ssh keys on it seems like asking for trouble. I'll checkout denyhosts though, thanks!
I tried the iptable rule and found out that it's not a good idea if you also use bash completion_over_ssh feature, the third time I pressed tab to get a path completed the delay got me thinking ;-)
Anyway the real problem is that it does not make a distinction between successful and failed ssh login (and how could it at iptable level?).
DenyHosts looks like a nice solution, I will try it asap.
I use this:
http://denyhosts.sourceforge.net/
.. on one host anyway. On another, where I don't have computer illiterate people logging in, I switched to RSA keys and disabled passwords entirely. Solves the bruteforcing problem entirely.
I also like the idea of port knocking, but I haven't seen a usable implementation yet.