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.'"
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
Hail Mary's... Deamons... Rick Astley.. The final battle is closer than we ever imagined.
The article noted that this is a vulnerability to cracked smartphones with ssh installed for which the user will likely not even know opens up such a vulnerability to their cell.
I think that this is more serious for wi-fi and bluetooth enabled devices as the data charge is circumvented making it even harder to detect?
I'd hate to start streaming my smartphone's logs back to my IDS, but brute force is not a new reality but the environment is very precarious as the smartphone does a lot now but may not "do" enough to protect its own resources from attack.
It's difficult to say whether or not a given system is infected, even if you inspect a complete packet log. Your checksum plan is one of the few ways to guarantee a lack of infection. Actually even that isn't always a guarantee, depending on where the hack is hiding. It could be in the MBR or even burned into the BIOS.
Luckily, in most cases the hackers aren't clever enough to hide their steps that well. There'll be oddly-named files in /var/www, ps and top will disagree about running processes, or you'll suddenly find yourself locked out of some system management tool.
Just another "DOJ fascist authoritarian totalitarian bootlicker" -- Zeio
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.
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.
Yes indeed. You can always make a network-facing daemon that has been heavily audited more secure by putting a Python script between it and the public Internet.
What I will say here applies to password logins. For SSHD that is configured to accept only cryptographic/public-key authentication, the attacks that Denyhosts would block are only a nuisance (they fill up logfiles).
That heavily-audited network-facing daemon does not concern itself with password security. You can allow remote root logins and set your root password to "password" and that daemon will faithfully do what you told it to do. The heavy audits are designed to make sure that a person who does not have a valid login cannot get a shell without first guessing valid login credentials. The Python script makes it infeasible for a single host to brute-force those login credentials assuming a reasonably strong password. Thus, it addresses a security issue that is actually beyond the scope of SSHD.
Personally I prefer SSHGuard because it will use iptables to drop packets from offending hosts. In my opinion that's a better approach than adding the hosts to a hosts.deny file. A host listed in hosts.deny can still try to connect to your daemon; it will just be immediately disconnected. By contrast, anything firewalled by iptables and set to DROP won't even get so much as a momentary TCP connection. Not a big difference, but I say let them wonder if you're even online anymore. There's also no dependency on the robustness of tcpwrappers (well-tested though they may be).
It is a miracle that curiosity survives formal education. - Einstein
Because it's trying to guess SSH passwords?
all of whom should have a more sensible password policy.
Why does a cellphone OS need a user authentication system in the first place? Maybe at the application level.. no, I can't see that either. Anyway, this phone has one, and it's not meant to be used this way. These things are not meant to have SSH running on them, and whomever released the SSH package for them is irresponsible for not taking that into account.
It doesn't even need to authenticate using system methods, it could generate a random password at install - display on screen, and do it's own authentication. Maybe even offer to pop up an accept dialog before allowing access? Just a thought..
Sorry, I just can't understand how the phone and users continue to be blamed because in free software land developers are void of any and all quality concerns. At some point.. not the developers involved, but "free software" is going to get rap it deserves. It is what everyone makes it. Look after your own, if you see a free turd, call it a turd.
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.
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.
This is pretty much what I fear will happen eventually. Right after we'll all be equipped with "trusted" computers that will only run what we want if we jailbreak them, which will not only void their warranty but also open us up to trains of thought such as: If you didn't jailbreak and thus could only run software approved by The Powers That Are, you would not be susceptible to malware (or if, TPTA would have to take responsibility) and are thus fully liable.
Sounds far fetched? Think about it. Outlawing jailbreaking will probably not really work out, even if it was outlawed, who cares (how do you want to prosecute it)? But locked down devices that, in theory, cannot be harmful being spam chuckers will essentially mean you broke the lock. And then your lawmaker may choose, either he'll slap you for breaking the lock or, if he can't do that for some odd reason like a device that you own belonging to you, will catch you with the angle that you're causing damage with it and that can incur a hefty bill.
Don't tell me it ain't possible. If you haven't been asleep the last 10 years and when you look at the way things turned, it's anything but unlikely to become the next angle to ensure we only run what we're supposed to run.
And if at all possible, I'd like to avoid giving anyone a reason to follow that train of thought.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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
Dude, I totally agree with you. We are being channeled into systems that will not be under our full control, and doing anything about going down that path (other then willingly) is to be deemed unlawful. But I am not sure if freedom-loving individuals have any choice at this point...talking about it on /. is not going to change anything, other then providing a record of the dissent. So as they say here, "Ke Garne" or what to do?
I think therefore I can't be ~TTNH
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.