Slashdot Mirror
The Hail Mary Cloud and the Lessons Learned
badger.foo writes "Against ridiculous odds and even after gaining some media focus, the botnet dubbed The Hail Mary Cloud apparently succeeded in staying under the radar and kept compromising Linux machines for several years. This article sums up the known facts about the botnet and suggests some practical measures to keep your servers safe."
The solution to low-frequency brute force attempts is Denyhosts. It just blocks any host with repeated failed login attempts. I've been using it for longer than I can remember, probably longer than this "Hail Mary" botnet has been in existence. I'm not sure why this author seems to have never heard of it.
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
This is about the low-intensity password brute-forcing via ssh that's been going on for years -- the only difference between this and any other password brute-forcing via ssh is that fail2ban and such scripts are ineffective, because the attempts are so low-frequency that it's practically impossible to distinguish them from users fumbling their passwords.
The simple solution is to disable password authentication for all users, and make them use keys -- this renders you 100% safe from this botnet. If that's infeasible, be damn sure you've disabled password authentication for root (i.e. "PermitRootLogin no" or "PermitRootLogin without-password" if you still want key-based root logins). If you do allow password logins for any or all users, enforce strong password requirements.
Actually, not permitting root logins via SSH was one of the points he repeated several times. He also said, explicitly, "There's no safety in high port numbers anymore.". Perhaps he's wrong, but he did consider your point.
Personally, I don't feel very exposed, so I'm not willing to do much more than that, plus picking a secure password. I may have set things up so that no SSH logins are possible in any way, but I'd need to check again to find out. (I'm not much of an administrator, and my system isn't internet facing, but as I never use SSH except in a browser, there's no reason to allow it.)
But did you notice that not all of the attacks were attempts to log into root? (I don't know why anyone would replace root with admin, but apparently enough people do that that was a secondary target. If I changed the root account's name it would be to something like "doofus" or "notHere". (I.e., easy to remember and short, but not easily predictable. So you'd need a "dictionary attack" on the account name as well as the password.) I don't feel threatened enough, however, to bother with that.
I think we've pushed this "anyone can grow up to be president" thing too far.
I think this article points to the fact the author is retarded.
Considering the retarded author in question is someone who is a respected author on OpenBSD ''pf'', firewalls and security in general, I think your answer prove you are the retarded one.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
"I've managed to get my name on slashdot a lot"
"Use key auth instead of passwords"
"My references are my own blog posts"
There's nothing interesting to see here. Don't allow password logins to your system, because you can't trust people to use good passwords. It's 2013, there's no cake for pointing this out.
Not to mention several routers use admin and support ssh connections.
Router software virtually never gets updated.
Sig Battery depleted. Reverting to safe mode.
He actually mentions port knocking, but I think he mis-understands it. He makes a mathematical argument, without addressing the fact that the sequence of ports can be as long as you want. He seems to think port knocking is used to grant access, when most of the users I know who use it do so only to start sshd so that they can then log in via secure means.
But having to log in from a multitude of places is pretty common. Less common these days than in the past is having to log in from some random machine. Everyone has a cell phone or tablet or laptop. With those, you can store your private keys, and then totally disallow password logins via ssh.
You can then decide whether to allow root login via ssh or not as a separate issue.
Sig Battery depleted. Reverting to safe mode.
Or you could just set up key based authentication only. If you need to access devices that do not support key based auth, set up a server that DOES do key based auth as the only location they are accessible via SSH from.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Centos6.3 and 6.4, AIX 5.3.
Battlemaster--Game with friends in medival realms
Pick a host from our pool, assign a user name and password (picked from a list, dictionary or pool)
Implies that each host will, from a predefined directive, try certain user names. I have seen ones better coordinated than that, where they are going through the list alphabetically across a large number of systems. To me this implies a tighter degree of central control on the attack.
...). Any sane admin has root disabled for ssh access, in particular, so the number of attempts they make on that is irrelevant; and the rest shouldn't be allowed much of anything, ever.
That said, the list of users that they try are almost always first names only, aside from the usual collection of system names (root, toor, admin, oracle, games
At any rate, my point remains: this is an old game they've been doing. Interesting that we now have assigned a name to the botnet but otherwise not really news. It would be interesting to know more about the systems that are part of it, but they mostly come from the usual collection of countries and hence your likelihood of getting useful information on them is pretty well zero.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
That won't help if tomorrow someone finds a vulnerability in the openssh server that enables to bypass that (maybe something like this one from 2011). And that someone instead of announcing it worldwide (i.e. the NSA) start to use it to deploy their own backdoors in your server. Not having access to the service in the first place will avoid potential future exploits on it. Of course, could be exploits for the portknocker daemon, but as is simpler than the sshd (or any other service you have published that is not meant for the world) should be easier to check/audit it (only 2 vulnerabilities were found so far that im aware of, and implies or already being logged in the system, or being successfully authenticated.)
And, btw, the Single Packet Authentication uses a certificate too to open the port for your IP. And then you can use your own ssh certificate or password to login.
Not quite. It's retarded admins that use password authentication on public facing SSH services. I have had a public facing SSH server for over 5 years now and it ONLY permits key-based authentication. I have NEVER had an unauthorized login. But them I'm an unpublished no-name IT guy who only follows those "best practices" that the so-called experts keep railing on about but don't seem to follow themselves.
I am certain you can also have a secure Windows server that has a public facing connection on the internet ... I've just never had the patience to try it.