SSH password authentication insight and analysis by DRG

Published: 2010-09-07
Last Updated: 2010-09-07 13:59:34 UTC
by Bojan Zdrnja (Version: 1)
5 comment(s)

We've been writing about SSH brute force attempts for numerous times already. A lot of security researchers are collecting various information about such brute force attacks and numerous other tools exist that can prevent or block them.

DRG (Dragon Research Group), which is a volunteer research organization dedicated to further understanding of online criminality and to provide actionable intelligence for the benefit of the entire Internet community, last month published a very nice paper about such SSH brute force attempts. Among the other things, the paper lists a whole bunch of tools that can be used in order to limit or block SSH brute force attempts, and configuration recommendations that will help you increase security of your SSH installations. Check the paper at

Additionally, DRG is also publishing a list of IP addresses of SSH attackers that were detected on various pods DRG uses, that are spread around the world. This list is available at

DRG also created a very cool tag cloud showing most common usernames and passwords that have been tried in latest SSH brute force attacks. The cloud is available at - check it make sure there aren’t any of your passwords there :). Both the list and the cloud are updated every hour.

More information about DRG is available at and I’m sure they could use more pod runners.


Keywords: brute force drg ssh
5 comment(s)


How can this leave out ipt_recent? It's like four lines of boilerplate iptables rules. It's a lot easier (though maybe less flexible) than the log-scraping utils.
How hard would it be to modify the ssh daemon so that after some number of attempts, it slows down? After 5 attempts, for example, it makes you wait 5 seconds before the next attempt. That would still allow you to login, but would stop any brute force attack.

From the 'man sshd_config':

Specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional
connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connec‐
tion. The default is 10.

Alternatively, random early drop can be enabled by specifying the three colon separated values
“start:rate:full” (e.g. "10:30:60"). sshd(8) will refuse connection attempts with a probability of
“rate/100” (30%) if there are currently “start” (10) unauthenticated connections. The probability
increases linearly and all connection attempts are refused if the number of unauthenticated connections
reaches “full” (60).
Some of the options in comments above (and others often cited to address these attacks) go by another name: Denial Of Service.

Anything other than a specific IP-blocking mechanism opens one up to DoS. This includes options that affect the operation of the ssh daemon and options that are specific to a username. Very simply, if an attacker knows (or guesses) a remote host is using an IPS method that somehow cripples the daemon or specifically blocks a username, all they have to do is continue to attack, even if they can't break in. This effectively denies/impacts access to legitimate users, the definition of DoS. Information Assurance covers many things other than unauthorized access. Protection against all of them is important.

The referenced article has some good options for IP-based blocking including sshblack and sshguard. Conceivably, there is a methodology for 'joe jobbing' or spoofing an IP address to get it blocked, but very unlikely with the ssh protocol.

Diary Archives