Brute force SSH attack confounds defenders Security researchers are struggling to combat a sophisticated brute-force attack against SSH servers. Instead of using the same compromised machine to try multiple password combination, the newer attack relies on coordination among multiple botnet clients. Also, instead of throwing this resource at random Secure Shell (SSH) …
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.
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.
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.
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.
"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!
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
