Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Hail Mary Cloud and the Lessons Learned

Posted by timothy on from the not-so-full-of-grace dept.

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

9 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. Re:Denyhosts by Noryungi · · Score: 3, Informative

      I second that: DenyHosts is now mandatory on all the Linux servers I manage, and allows one to protect servers against that type of attacks with minimal effort.

      Please note that the author did not mention Denyhosts since his servers run OpenBSD, which incorporates DenyHosts functionality through ''pf'', its packet filter/firewall software (see the brute-force configuration of pf for more details).

      --
      The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
    3. Re:Denyhosts by module0000 · · Score: 4, Informative

      If you like DenyHosts - look at fail2ban. It has all the functionality of the older DenyHosts project and more. You can ban based on more than failed ssh logins - but any type of logfile imaginable. With customized responses to X login failures per Y time units for Z service. You'll find it in the repo's for all debian/rhel based distributions.

      --
      Trackball users will be first against the wall.
  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. Re:Nothing you can do? by Noryungi · · Score: 4, Insightful

    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)
  4. 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.

  5. Re:Nothing you can do? by icebike · · Score: 3, Interesting

    Not to mention several routers use admin and support ssh connections.

    Router software virtually never gets updated.

    --
    Sig Battery depleted. Reverting to safe mode.