The only thing sophisticated about this attack is that there is a tighter link between the compromised hosts (which do the attack) and the command/control centre, which does the co-ordination. Other than that, right now the only thing that this attack appears to be doing is running a dictionary attack on each selected SSH host to check out for valid usernames. Maybe at some stage in the future, they will try brute forcing passwords. But right now, "sophisticated" is definitely the wrong term; "clumsy" or "likely to gain lots of peoples' attention", more like it.

Just another reason to be using certificate based authentication, IP restriction or at the very least disable root login!

Most, in fact nearly all of the brute force ssh attacks against my honeypots use known Linux service names as passwords and often as user names too.

So if your ssh server uses such service names for passwords or user names change them now. It should be basic security practice to use non-dictionary words, strong passwords or pass phrases to access ssh. If possible, and it should be to some extent, restrict access based on IP address too. If one has difficulty in remembering complex passwords or phrases, one can always write them on a post-it note and stick it on the monitor.

That's what key pairs are for, shirley?

They can hammer away at port 22 on our servers until hell freezes over. We don't care.

I'm no server admin but wouldn't it be some defence to have a text based capcha before the user/pass prompt? Something like:

Fill in the missing word:

I r teh ******

1) luser

2) n00bage

3) r0xx0r

4) h4xx0r

I realise that would bugger automated logins, but there's other ways to sort them out, e.g. a challenge/response table unique to each registered host.

Port knocking, rsa/dsa key's, listen on another port, allow only certain machines, or only allow internal network. allow only certain users -- tcpwrappers and or iptables rules will help, etc., etc., etc.

Oh so easy to avoid issues.

Ditto, the failed login attempts on my box dropped to zero when I switched ports.

I suppose they would find it if they did a proper scan though, the handshake should give it away.

>one can always write them on a post-it note and stick it on the monitor.

Uh-oh.

Using NMap, scanning for SSH on all ports as opposed to just port22 would take perhaps 20 seconds extra - no big deal, so using another port isn't much protection.

Using non-standard ports is an easy and very effective measure. Combine it with something to catch port scans (portsentry is good) and you'll stop most attempts. Add in some of the other suggestions people have made and it becomes a very effective protection.

script on port 22 pretending to be ssh. With no real access possible.

ssh on a different port.

A scan for ssh that is not on port 22 is noisy. IDS systems will notice this.

This is a bot that is attempting to compromise ssh accounts, it is unlikely that it scans all ports identifies ssh and then attacks that port. Chances are this bot is hard coded to attack port 22, so changing the ssh port may well defeat a bot attack. Obviously if a human is attempting to access ssh then moving the ssh port is no help at all.

Putting login credentials on the pre-login banner will also help those who cannot remember complex passwords. Also helps if the post-it note falls of the monitor and the office cleaner throws it away.

The point is that they don't do it, not that they can't.

It's amazing how quiet the logs become.

Apply scissors to the ethernet cable to your box. Place cable ends 1 inch apart.

I still have to see the first bot leaping over that firewall ...

"If one has difficulty in remembering complex passwords or phrases, one can always write them on a post-it note and stick it on the monitor."

It's also a good idea to make sure said monitor is in full view of a network webcam with 100x optical zoom. Having a sticker on the computer with its IP address printed on it helps, too.

(Yeah, I've seen all of these things - though not all at once, unfortunately. Not that I'd do anything if I did. Of course not.)

To access my controlled servers requires a nice long password and originating from a 'trusted' network.

I sometimes need access from on the road... so I have a VPN set up - if someone were to crack the VPN details and the SSH details and guess the correct IP addresses to use, I must confess that I probably wouldn't notice because I'd be far too busy researching the best tin foil to use in hat making... because at that point in time hell would be chilly, there would be headless horsemen riding past and the end would be nigh!

Ya know..... I think that makes a lot of sense, at least for connections that are supposed to be to have a human in the link and not ment to be automated in anyway.....

Mind you for most users the question should probably be

"What color is Yellow"

1- Yellow

2- Triangle

Almost the perfect solution, but you broke Rule Number One of computer security:

1. Don't buy a computer.

This approach has other advantages, such as reduced technical support calls.

If you install denyhosts it can lock out an attacker after the number of guesses you choose to configure. If you then run denyhosts in network mode it can share your blacklist with other denyhosts users, which means when more than however many similar servers have been attacked by a host that you choose to configure, you won't get a single attempt on your own server from that host. Not as secure as restricting logins to allowed addresses only, but it means you can still fix your server if you go away on holiday and get an SMS monitor telling you that something is down and you need to login to it from the nearest Internet cafe. If you need to be more secure than this you'll have to carry the right crypto SSH key everywhere you go and disable non-key based logins.

``To access my controlled servers requires a nice long password and originating from a 'trusted' network.''

Surely to God people aren't running ssh listeners with password authentication exposed to the Internet? Under what circumstances couldn't you use a keypair and massively reduce the risk? The quality of the passphrase is a slight issue, especially if there are offline attacks, but that all presumes that someone has a copy of your private key. That massively reduces the risk compared to using a password for straight username/password authentication.

You can liken this to the old idea that even a the most basic form of bike lock will deter theives. The larger your sample, the more likely you'll find a totally unlocked one.

Given even a small amount of protection, the evil-doers will simply move onto the next target, as it's better to test 1000 machines quickly, than it is to test 1 thoroughly. Also the fact that you obviously understand the risks, shows them you'll probably choose a sensible password.

These guys have an almost unlimited pool of IPs to test for logins, they'll perhaps get a 0.0001% penetration rate, which is easily enough to justify the whole exercise. This is why they'll only test the most common passwords and then move onto the next host, because you'll get better results by increasing your sample size than you will be hammering a few servers with massive wordlists.

Simply put, it is not a good use of their time to have their scripts check for non standard ports or any of that other gubbins, when there're ~ machines who could have NO protection waiting to be tested.

Interestingly, this a bit like why you should NEVER use sequential IDs instead of usernames (like rapidshare), because I'll just use the password "password" and test a vast number of logins until I get what I want.

Be sensible, forget passwords and setup Certificate based authentication and then wonder how you did without it.