Slashdot Mirror
The "Hail Mary Cloud" Is Growing
badger.foo writes "The Australian rickrolling of jailbroken iPhones only goes to prove that bad passwords are bad for you, Peter Hansteen points out, as he reports on the further exploits of the password-guessing Hail Mary Cloud (which we've discussed in the past). The article contains log data that could indicate that the cloud of distributed, password-guessing hosts is growing. 'With 1767 hosts in the current sample it is likely that we have a cloud of at least several thousand, and most likely no single guessing host in the cloud ever gets around to contacting every host in the target list. The busier your SSH deamon is with normal traffic, the harder it will be to detect the footprint of Hail Mary activity, and likely a lot of this goes undetected.'"
Just was has to happen to make people realize (or make lawmakers force them to) that securing your boxes is a necessity?
What? Tell me, please, what has to happen? How much damage is needed? We'll see it happen, no matter how much damage is required. The question is only whether it's too late or whether we can repair it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Denyhosts is available for most linux distros. You can tune its behavior and it will basically filter out requests coming from misbehaving hosts. From Wikipedia: "DenyHosts is a Python based security tool for SSH servers. It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the authentication log and blocking the originating IP addresses. "
Suppose you were an idiot. And suppose you were a member of congress. But then I repeat myself. -- Mark Twain
So is there any way other than looking at the packets on your router to know if a system is compromised? This is a question thats been asked many times before but Ive yet to see a straight answer.
The first, last, and only tech news site on the net
Hail Mary's... Deamons... Rick Astley.. The final battle is closer than we ever imagined.
I would think that anyone running an ssh server should also be running something like the Denyhosts daemon. After a set number of failed logon attempts, it will automatically add the connecting ip address to hosts.deny and their hack attempt is over.
-- Give me ambiguity or give me something else!
...because if the password is pre-set, default, and known to everyone accessing the software, then, yeah, exactly, you dumb s**t of an article author.
This is a distributed effort, and any one host will not hit your machine more than once. You could configure it to block entire country's subnets, but that's still only marginal protection.
What you want to do is disable username/password authentication on your ssh hosts. This is one of the first things I do. Set up your machine's public and private key, copy your public key to all your other machine's authorized_keys file, and edit your sshd config and add the line "PasswordAuthentication no". Now, broken crypto libraries aside, you will be safe from this sort of attack.
Although in spite of all the advice people offer to ward off the attacks, there are a couple of really simple things to do that will keep it at bay with excellent effectiveness:
If you keep to at least those precautions you just need to grep your messages log for the allowed user names periodically to make sure that there weren't any attempts on valid names. Then as a bonus your system will keep generating more log entries for you to post to slashdot journal entries as your observations of the attack attempts...
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
The summary starts by talking about jailbroken iphones getting rickrolled. It then goes on to discuss the growing hail mary cloud of compromised systems that are trying endlessly to find unsecured *nix boxes to log in to.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
s/cloud/network/
There. Done it for ya. Was that so hard?
We should make a Greasemonkey script out of it. :)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Because it's trying to guess SSH passwords?
Plaintext passwords over ssh have always bothered me. I always had a little program called 'sshlockout' which checks for failed password attempts via auth.log and lockout the IP, but that clearly won't work against something like this.
The only real solution is to disallow tunneled plaintext password logins entirely... simple enough, just set 'PasswordAuthentication no' in /etc/ssh/sshd_config (or wherever it lives). Problem solved.
Nobody should be using that sort of authentication any more anyway.
-Matt
It bans or denies connection to IPs that have repeatedly failed to login. That is real security, not obscurity. That being said, it is totally useless against today's threats.
I've try a number of things, ssh-anti-brute.pl worked well at least initially (when receiving multiple failed logins from the same destination address) but my drop chain was starting to get kinda lengthy.
I've recently moved sshd off port 22 and it seems to be doing the trick.
Am I the only one who misread the title as "The 'Hairy Mail Cloud' is Growing"?
Somebody posted a list of user names being tried above. Take a look at it for a little education on what not to use as a user name. No simple first names, no matter how romantic or aesthetic it feels. No names of servers (mysql, etc), especially not unadorned. "admin", of course, but also "manager" are out.
So, make the user names harder to guess. Root, of course, do not allow root to log in, period. Definitely not over the net, anyway. If you must log in as root, change the root user name, or add a synonym -- rename the root something obscure. Maybe the name of your favorite vegetable with some leetspeak thrown in, or turned backwards, or scrambled, or, think of you own way to make it obscure.
Use initials instead of single names. Or, better, use initials in combination with simple names, or job titles in combination with something like the first name and an initial. Or multiple names.
(If you might have someone specifically targeting your servers for something valuable, don't use names or initials or job titles at all, of course. Sometimes, you might even want to generate the usernames randomly, or at least partially randomly.)
In fact, if you disable, or just don't have root or admin or pguser or web, etc., you can be really, really sure that an attempt to log in with such names indicates someone who really shouldn't be allowed to even try to log in.
The point is, it's much harder to brute-force a system when the attacker doesn't even know what user names to start with, whether hail mary or machine-gun.
And then you make the password reasonably long and obscure, and you're pretty safe.
(User names, at least, usually won't need to be changed every six months.)
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Get off the default ports, too.
tarpit port 22, just for fun.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Because today's phone is tomorrow's remote terminal.
You'd better believe I sometimes wish I could log into my personal server remotely from my phone to check the logs or something.
Now, I may not now need to log into my phone via sshd, but, actually, yes I do. Simple stuff. The phone company's mail software and user input stink. But that's trying to fix a different problem, really.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
SSH is Linux specific? That is "Score:4, Informative"?
No, but it's present on most linux server installations, and therefore relevant to linux. I don't see how it's irrelevant. If it bothers you, maybe we should have a "unix" super-section that covers OS X, Linux, BSD, etc. that stuff that affects everyone can go under.
Using an RSA or DSA Pubkey will effectively stop these..
Add on top of that a firewall rule blocking high volume of requests to your server (I have it set at 4 per minute :)) works well for this.
I *NEVER* setup an SSH server using password auth..
Oh, and of course TURNING OFF SSH on your iphone when not needed is ALWAYS a good idea.
In my small amount of experience observing these types of ssh attacks, and even letting them into high-interaction honeypots to see what they do, there are four simple things that can be done to really cut down on the danger. Applying the first item, and any subset of the last three should be pretty good.
One, turn off root log in. Then they have to guess both a user name and a password. This would stop every single attack I have ever seen in my logs, since none of them have guessed a correct user account, let alone a correct password. It tries names like root, admin, apache, samba, so if you have these make sure they can't log in with ssh.
Two, use a decent password. A lot of people will tell you to take the inconvenient route of disabling password logins, saying they are dangerous. However, guessing over ssh is extremely slow, compared to a brute force attempt on a local machine. This means they really only get a chance to guess the most obvious passwords. If you trust all the passwords on the system to have decent strength, which is the case if, say, you are the only person logging into the machine, then you don't need to disable password logins.
Three, in case they did somehow figure out the name of an account that can log in, run DenyHosts. This will stop non-distributed attacks in their tracks, as they only get a few guesses.
Four, move the ssh port to something other than the default 22. I moved mine to 443 (https), since it's accessible from highly firewalled networks behind which I may be trapped, and people are already used to seeing encrypted traffic on that port. Ever since I did this, I haven't seen a single login attempt on my server other than myself. This means my server also wastes less time rejecting remote logins.
The ssh brute force bots I've seen are very stupid. I'm not really sure what the bot operators are doing. In my ssh honeypot where I have the root password set to "password", most bots won't ever guess it after thousands of attempts. Of the ones that do eventually guess the right password, most log out right away, then go right back to guessing root passwords again! Maybe trying to detect if it's a honeypot? Then there are ones that do log in and stop guessing, but they immediately log out and don't ever return (that is, no one has ever shown up and logged in without making guesses). Security researchers? Maybe marked my honeypot down for some future abuse? Maybe detected that it was a honeypot? I'm not sure what's going on with that.
Um, what about this? Or would you say that cygwin counts as "unix?"
But it seems to me that key based authentication mediates this risk. Am I the only one that does this? What the heck does everyone think ssh is for? I use password authentication the very first time I access a server. I put my pub key there, then disable password authentication. My private key never leaves the thumb drive I wear around my neck. Being a CHL holder, it is very unlikely you'll get to that without leaving your DNA and most probably grey matter all over the place. Plus, my cat sets my passwords.
This sig. intentionally left blank.