[CentOS] Ideas for stopping ssh brute force attacks

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

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 
blocking.