Distributed SSH Brute Force Attempts on the rise again 
Share | Published: 2010-06-18,
Last Updated: 2010-06-18 12:32:51 UTC
by Adrien de Beaupre (Version: 1) 
5 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.

Cheers,
Adrien de Beaupré
EWA-Canada.com










 

Keywords: distributed ssh brute force attempts 
5 comment(s)
previous

Comments
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?
posted by nate, Fri Jun 18 2010, 13:05 
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.
posted by Steven Chamberlain, Fri Jun 18 2010, 13:20 
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?
posted by Jonathan, Fri Jun 18 2010, 14:04 
Changing your listening ssh port to something non-standard almost eliminates
this.
posted by James, Fri Jun 18 2010, 14:08 
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.
posted by joeblow, Fri Jun 18 2010, 14:22