Distributed SSH Brute Force Attacks

Recently a couple of news reports have come in that suggest that someone has changed how they do SSH brute force attacks:

The change is this: instead of the hosts from the SSH botnet pounding away as fast as possible from the same IP over and over and over again, where you see it failing and failing and failing, these guys have moved to what they should have been doing, coordination. They’re only trying one or two logins from a single IP before moving on; another IP from the botnet tries a new login. The IP may re-appear but only after a while. This defeats some of the simple rate-based triggers for local protection. What’s more is they’re only trying very specific SSH servers. They seem to not be trying everything in the book.

The answer to this is to use a blacklist, working on the theory that someone else has seen this IP scanning and trying logins and failing. Here’s a list of blacklists you can use (import them with caution, use at your own risk, etc).

These lists MAY help you prevent the attempts from the botnet (and many others). I’ve worked with the person (let’s call him C) who both gathered this list and did more analysis of this distributed, patient scanning to look at an overlap between Arbor’s SSH scanner and bruter blacklist and his own blacklist and we came up with about 12% overlap. Not great, and I wonder how much overlap there will be in the future (ie if we go forward one day would the Arbor SSH blacklist have prevented a bruter from trying logins). I would suggest contributing to those blacklists to help everyone, there’s a lot of SSH-bots out there at this point!

Also, here’s a 2d snapshot of ATLAS’ SSH blacklist: http://atlas-public.ec2.arbor.net/public/ssh_attackers

What we’re lacking so far is a capture of the tools on the box, the bot code. I analyzed a case earlier this week where an SSH server was broken into via SSH scanning and it was just a typical IROFFER network. This looks far more substantial than that.

If you have tracks matching this AND you want to help analyze this, please be in contact.

Many thanks to C for his great analysis of the events so far. He, too, is looking for “what comes next”.

Reblog this post [with Zemanta]

14 Responses to “Distributed SSH Brute Force Attacks”

December 06, 2008 at 1:48 pm, arioch said:

Have a look at DenyHosts on Sourceforge for all your *nix boxes with open ssh to the Internet. Great tool to help secure your boxes and keep them a little more secure.

Also has any contacted the maintainer of DenyHosts to see if there is any correlation with the data he is receiving at http://stats.denyhosts.net/stats.html?

December 08, 2008 at 8:52 am, Jay Maynard said:

I’ve installed DenyHosts and enabled its distributed blacklist maintenance function. It’s stopped this attack cold at my system; I only get an attempt a day, maybe, from the botnet that it doesn’t stop.

December 08, 2008 at 5:18 am, esorge said:

Would be nice to setup an honeypot in order to do some stats on SSH client banner, OS fingerprinting, etc. This can help us tracking if the distribuited attack is starting to spread through specific vulnerable OSes, etc.

December 08, 2008 at 8:18 am, George said:

Hi,

I have several failed login attempts in my logs. What worried me most is that the user name for each was very nearly correct, I believe generated from parts of my googlemail email address. The IP addresses the attempts were made from are all well distributed.

Let me know if these logs will be of interest.

December 08, 2008 at 8:35 am, Koos van den Hout said:

I think this started around November 21 – 22 of 2008. I already saw a few distributed ssh attacks before but this was the first with exact timed coordination. I saw newsposts of people with the same username being tried within seconds from when it was in my logs. Comparing 2 hosts with adjacent IPs yielded the same IP trying the same names.

(I also mentioned the coordination at http://idefix.net/~koos/newsitem.cgi/1227707752 )

I did firewall all IPs trying invalid usernames after a while, this mostly shut up the attempts, making me think the size of the attacking network is not unlimited.

December 08, 2008 at 3:33 pm, Brute force SSH attack confounds defenders | H_acktivis_T said:

[…] have been applied to mitigate the attack, but these are only partially successful, Arbor Networks warned on […]

December 09, 2008 at 4:15 am, t said:

By changing the default SSH port to something different say 222 or 1022 one can add one step for attacker – port identification. I wonder if or how much that helps, is there anyone with the relevant setup/experience/data ?
(probably you can setup port rotating by month – january 1010, february 1011, etc 😉

December 09, 2008 at 5:37 am, mokum von Amsterdam said:

This is going on a long time already.

I picked this up in May 2008 and certainly was not the first.
http://mokumvonamsterdam.blogspot.com/2008/05/ssh-brute-force-botnet.html

Good you get the ‘news’ out in the open again, never too much attention for issues like these.

Denyhosts is doing a pretty decent job of keeping your /etc/hosts.deny up to date, give it a try.

December 09, 2008 at 7:52 pm, Matthew Walker said:

We’ve been seeing this on our production network for a while; and most recently they actually been successful against two of our exposed research boxes that I was silly enough to leave with weak username/password combinations on accounts with wheel. The funny thing that we’re still looking into at my lab is that although the two boxes were compromised at the same time; they do different things, one seemingly just acts as an IRC relay node, and the other was actually actively attacking servers in Brazil. Luckily the rest of our exposed boxes did not have such vulnerabilities.

December 15, 2008 at 5:37 pm, The Linux Mint Blog » Blog Archive » The Mint Newsletter - issue 69 said:

[…] SSH Brute Force Attacks confounds […]

December 19, 2008 at 3:11 pm, Nerd Gene » Blog Archive » Prevent port scans and SSH brute force said:

[…] the influx of reports about botnets doing SSH brute force attacks, I decided to check my own server logs. Sure enough, I […]

December 19, 2008 at 11:31 am, Chinese Sandwich Babies Take Over Duh Interwebs | We Break Things said:

[…] [3] http://edwardlucas.blogspot.com/2008/12/cyberwarfare.html [4] /blog/asert/2008/12/distributed-ssh-brute-force-attacks/ Share and Enjoy: These icons link to social bookmarking sites where readers can share and […]

May 03, 2009 at 7:15 am, HÃ¥kon Alstadheim said:

Hi, I used to have one of the entries in your blacklist-list at my website
(http://www.alstadheim.priv.no/cgi-bin/svarteliste). That link should be removed from the list.

It has been discontinued. There is no point in running such a thing in isolation any more, since most serious attacs nowadays are distributed slow attacks. To stop those we’d need a distributed approach, like taking port 22 hits from dshield.org.

I don’t have much time for IT-security work anymore, so the idea is hereby put into the public domain.

August 26, 2010 at 9:44 pm, Mitigating SSH Brute Force Attacks | InfoSecStuff said:

[…] or write a script to block them automatically based on log entries. There are also a number of blacklists available on the Internet that provide a good starting point of hosts/networks to block even if they […]

Comments are closed.