The "Hail Mary Cloud" Is Growing 102
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.'"
Re:Put in denyhosts... (Score:5, Informative)
Denyhosts will *not* protect you from Hail Mary. Read the article...this particular botnet may send you only a single login from a single IP, but the cloud as a whole will send you hundreds of attempts.
The correct solution is to disable password login, and use pubkey auth instead.
Re:Put in denyhosts... (Score:1, Informative)
I change the default port that SSH listens on and use Key login, just to be safe.
I assume theres not much more i can do to secure it.
I would imagine 90% of the people out there don't need to have ssh running on a standard port.
Re:Why Is This The Linux Section?!! (Score:3, Informative)
Re:Put in denyhosts... (Score:5, Informative)
or fix your filesystem clients.
Re:Put in denyhosts... (Score:5, Informative)
Very true, but it'll only keep out an absolute moron. Anyone with half a brain will use a distributed mechanism, which means DenyHosts will only see failed password attempts from a given host a few times.
There's plenty more to do:
- Don't allow root logins via SSH, or limit them to key-based logins (trivially easy in /etc/ssh/sshd.conf)
- Disable shell accounts unless they're really needed. rssh is useful here - limit what a user with SSH login authority can do.
- Lock down other services. What good does DenyHosts do you if SSH and a separate app which can't be locked with DenyHosts both use the same password mechanism?
- Lock accounts which have more than N failed logins. (Though if you've centralised logins such as in the above example, it'd probably be better to do this from whatever system deals with the authentication, eg. LDAP).
Re:What has to happen? (Score:1, Informative)
The link the author provides in the story is about the Hail Mary pass [wikipedia.org]. Sure, the Hail Mary pass itself goes back to the prayer, but you're skipping a layer of analogy (and an interesting bit of trivia).
Re:How to ID an Infected Computer (Score:3, Informative)
Sure. Whenever I'm at home the phone connects via wifi through an Airport. When at work it connects via wifi through the university's secure wifi network.
Re:Put in denyhosts... (Score:5, Informative)
The nice thing about denyhosts is you can participate in the global shared DB, so one failed login on your machine, one on mine, etc, we all report the same IP, it gets flagged in the global DB, so we all block it. Machines that IP hasn't hit now won't allow login attempts from it.
Re:Denyhosts (Score:3, Informative)
Over the last week my SSH server has gotten about one password guessing attempt every ten seconds. Presumably they're not all from different hosts, but a quick visual scan didn't show up any duplicates and the ones that are close in time are certainly all from different IP addresses.
Re:DenyHosts will not save you; disable passwords (Score:2, Informative)
Re:Put in denyhosts... (Score:3, Informative)
Actually, no it isn't. It is a tool to limit the number of attempts at password guessing. Knowing it's there won't help the attacker at all (they still can't just blast away from a dictionary).
Re:Put in denyhosts... (Score:4, Informative)
Denyhosts isn't security through obscurity in any way.
It just monitors /var/log/messages (or wherever your sshd is configured to log to) and blocks ip addresses with multiple failed logins.
I think you're thinking of port knocking, which is security though obscurity, though it's still damned useful.
Re:Denyhosts (Score:3, Informative)
try this
cat logfile | cut -d " " -f [fill in the field with the IP ] | sort | uniq -c | sort -n
(and if need be, add ' | tail -20')
This will show you whether there are repeat IP addresses in the log.
Webgoddess
user names, too (Score:3, Informative)
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.)