Distributed SSH Brute Force Attempts on the rise again

Published: 2010-06-18
Last Updated: 2011-01-25 00:03:41 UTC
by Adrien de Beaupre (Version: 1)
13 comment(s)

SSH brute force attempts seem to be on the rise again, at the SANS Internet Storm Center we have received a number of reports that a number of networks are seeing them. The source IP addresses vary with each new attempted username in the wordlist, which would indicate that the attempts are distributed through botnet(s). It only takes a single user with a weak password for a breach to occur, then with that foothold escalation and further attacks are likely next. This is certainly not a new phenomenon, however I think it is a good time to raise awareness about it once again.

Reader xemaps wrote in with this log snippet:

"Whole day my server has been targeted by a botnet, attacker also changed ip each new dictionary user."

Jun 17 23:02:03 pro sshd[17444]: Invalid user mailer from 217.37.x.x
Jun 17 23:03:24 pro sshd[17460]: Invalid user mailer from 87.66.x.x
Jun 17 23:05:27 pro sshd[17617]: Invalid user mailman from 89.97.x.x
Jun 17 23:09:30 pro sshd[17639]: Invalid user mailtest from 62.2.x.x
Jun 17 23:15:44 pro sshd[17894]: Invalid user maker from 83.236.x.x
Jun 17 23:16:47 pro sshd[17925]: Invalid user mama from 84.73.x.x

Reader Ingvar wrote in with a similar pattern:

"On my home system I have seen these login attempts that start with user "aaa" and goes on alphabetically from over 1000 different hosts around the world (judging from the DenyHosts reports). Normally I only see single-digit attempts per day."

Jun 17 02:14:56 MyHost sshd[808]: error: PAM: authentication error for illegal user aaa from 151.100.x.x
Jun 17 02:23:11 MyHost sshd[870]: error: PAM: authentication error for illegal user aabakken from 150.254.x.x
Jun 17 02:24:57 MyHost sshd[875]: error: PAM: authentication error for illegal user aapo from 173.33.x.x
Jun 17 02:35:23 MyHost sshd[885]: error: PAM: authentication error for illegal user abakus from 121.160.x.x
Jun 17 02:37:32 MyHost sshd[895]: error: PAM: authentication error for illegal user abas from 190.200.x.x
Jun 17 02:38:18 MyHost sshd[900]: error: PAM: authentication error for illegal user abc from 193.251.x.x

Last year ISC Handler Rick wrote up a diary for Cyber Security Awareness Month - Day 17 - Port 22/SSH about SSH brute force attempts and some safeguards that can be implemented. Here is a brief summary:

  • Deploy the SSH server on a port other than 22/TCP
  • Deploy one of the SSH brute force prevention tools
  • Disallow remote root logins
  • Set PasswordAuthentication to "no" and use keys
  • If you must use passwords, ensure that they are all complex
  • Use AllowGroups to limit access to a specific group of users
  • Use as a chroot jail for SSH if possible
  • Limit the IP ranges that can connect to SSH

If you have any comments, additional examples of safeguards, or additional information please let us know here.

Adrien de Beaupré
Intru-shun.ca Inc.


13 comment(s)


I think its best to launch automated countermeasures triggered by monitoring SYN packets on port 22. Set a threshold at let's say 120 packets in 60 seconds (or whatever you think is the lower end of unreasonable). That way it doesn't matter if its an SSH scan, or an SSH bruteforce attack. There might be many sources and a single destination, or a single source and many destinations. It doesn't matter. You want to stop both the recon (scanning) and the attack (bruteforcing) right?
nate: if you mean closing your SSH port to anyone (perhaps including yourself) in the face of aggressive scanning/bruteforcing, that is not going to be appropriate in many situations. If you're really that fortunate, then you may as well shut down the service completely, or disable plaintext authentication and require client keys instead.

The nice thing about this attack though, is that it should be easy to compile a comprehensive list of infected hosts and go about getting people to fix them.
That's what I was thinking. Is there a place we can submit the hundreds of ip addresses we have? Or would just need to contact all of them ourselves?
Changing your listening ssh port to something non-standard almost eliminates this.
using a non-offical port for ssh (or any other registered service), is just a hack. security by obscurity, etc.

the real solution is to get people to fix their broken security, which led to the attempts in the first place.
joeblow: When you consider defense in depth, your goal is to implement multiple measures that, working together, protect your system/environment.

While changing your port should not be the only step taken to protect your systems, it does reduce your surface area by eliminating the potential of most of the automated scripts. Why would you not want to reduce your surface area if it's as trivial as using a different port (depending on your situation)?

I would also be surprised that the writers of PCI would recommend such a "hack" if it was indeed so.

Also, the "real solution" that you propose is generally outside of your control, while the configuration of your systems is well within your control. What you're proposing is akin to saying "We should not have a police force because the real solution is to get everyone to just follow the law."
so sending off a few thousand abuse@ emails is unacceptable? really? regardless of who has the control, the more respectable ISP's will disconnect botnetted hosts.
Seeing a lot of this against our SFTP server. Are the bots just looking for shells or are they smart enough to see a Windows SFTP server when they actually achieve a login? Implementing keys for logins will be the next step and is as close to a solution as is reasonably achievable in a business environment.
If you're running SSH on a non-standard port, and being attacked, then it is a much more serious threat. It means you're obviously being targeted because someone took the time to do some reconnaissance.
Thus running SSH on a non-standard port is much more than just "security through obscurity," it's one more layer that can give you the edge on an attacker.
To jtanium's point, I have some preliminary data that supports that: http://danielmiessler.com/blog/security-and-obscurity-does-changing-your-ssh-port-lower-your-risk

Diary Archives