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."

5 of 99 comments (clear)

  1. Denyhosts by mcelrath · · Score: 5, Informative

    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.
    1. Re:Denyhosts by Anonymous Coward · · Score: 5, Informative

      Another useful software for auto-banning bad accesses is fail2ban which can also handle other services, like exim, vsftp, apache, etc.

  2. Low intensity ssh brute-forcing. by foobar+bazbot · · Score: 5, Insightful

    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.

    1. Re:Low intensity ssh brute-forcing. by foobar+bazbot · · Score: 5, Interesting

      low-intensity bruteforcing is not dangerous - therefore it does not matter that fail2ban doesn't help. Basically, all fail2ban does is turning a fast bruteforce attack into a low-intensity one anyway.

      Yes, of course -- what's dangerous is not the low intensity attack itself, but that they command enough bots to make low-intensity attacks have a reasonable chance of success against lousy passwords. And that's only dangerous in combination with the fact that you're permitting users to have lousy passwords.

      Tricky passwords is enough - they can't guess them in a lifetime with a low-intensity attack.

      Amen, brother. That's absolutely enough -- if you enforce it.

      The main reason I suggested key-based auth first is because some fools' idea of "make sure users use strong passwords" is to force users to change their passwords frequently, and tell them to use strong passwords (e.g. not derived from a single english word), and maybe enforce silly requirements such as "must have at least one letter and one numeral"; this inevitably results in "password1" the first month, "password2" the next month, and so on.

  3. Executive summary by Anonymous Coward · · Score: 5, Informative

    "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.