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.'"
Put in denyhosts... (Score:3, Interesting)
Re:How to ID an Infected Computer (Score:5, Interesting)
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.
DenyHosts will not save you; disable passwords (Score:5, Interesting)
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.
Re:Put in denyhosts... (Score:4, Interesting)
Unfortunately, these phones do not have fixed IP addresses. IP-based authorization won't work when half the time your IP address is assigned by the local WiFi LAN as is the address of the other phone -- after all, you might be using SSH at home where IP addresses are assigned from the same range as at the hostspot where you get attacked. You need host-based or user-based authentication that does not depend on IP addresses. For example, SSH supports user-based cryptographic keys.
I also think that blocking hosts is the wrong way to go. Most people do not run open-to-the-public login servers, either on their home computers or on their phones. If you must do host-based blocking then the correct approach is that of hosts.allow — deny all requests by default except for those that you trust.
The cloud attack isn't new (Score:4, Interesting)
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...
Re:Denyhosts (Score:3, Interesting)
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).
Re:Put in denyhosts... (Score:3, Interesting)
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. "
RTFA. From the looks of the logs he posted, it's deliberately only trying a couple times from any given IP, specifically to prevent this sort of detection.
I used to do this sort of thing with scripts on my server, after running into an occasional spurt of several hours of an IP address trying every username in the book, apparently hoping for a blank password or same-as-login password. I had it set to autoban the IP at 5 of any sort of failed attempts in a row. I had to do it this way unlike your above example because the guesses kept changing the username, and most traditional "delayed authentication failure" responses nowadays are only effective after multiple attempts on the same username, and they were running a username dictionary, not a password dictionary.
But your method is 100% worthless against this attack.
Nowadays, my servers listen on a nonstandard port, and rsa key login is manditory. End of problem.