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.

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.

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 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.)

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

``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.