[CentOS] Ideas for stopping ssh brute force attacks

mouss mouss at netoyen.net
Wed Jul 23 08:32:04 UTC 2008

Ned Slider wrote:
> [snip]
> I don't think anyone is suggesting running SSH on a non-standard port as 
> a sole means of defence, but rather as part of a layered approach where 
> it is very effective in what it is designed to do - namely to vastly 
> reduce the number of random brute-forcing attempts and concomitant noise 
> in log files not to mention reducing the overall load on other 
> mechanisms of defence such as firewall scripts etc.
> Moreover, rate limiting is not as effective as it used to be as there is 
> now evidence that attackers are using distributed methods of attack 
> utilizing multiple random IP addresses that circumnavigate defences that 
> rely on attacks originating from a single IP address. Studies suggest 
> attackers will try a handful of common account names/passwords and then 
> move on as that's what yields the highest returns for them.
> We should also remember that public/private key authentication is only 
> secure as the host the private key is stored on when keys without 
> passphrases are employed (all too common where users don't want to trade 
> using a password for a passphrase). If a user account gets hacked then 
> the keys to the kingdom are there for the taking and the hacker has 
> instant access to any SSH servers which employ public/private key 
> authentication (without passphrases).

Indeed. and with keyloggers or social eng, passphrases get stolen too. 
(and trojans can also connect from the same client if an agent is 
running). so don't trust users too much...

>> A useful additional layer of defence, if you want it, is a daemon that 
>> will
>> watch for port scans on the simple services ports and immediately 
>> insert a
>> firewall rule to block that source - such as the old PortSentry, if 
>> you can
>> find it, or some more modern equivalent. Of course, this won't do much to
>> defend against some types of stealthy scans, such as idle time scans.

one problem here is that you may block innocent clients in the case of 
IP spoofing. better have a daemon that establishes tcp sessions before 

More information about the CentOS mailing list