Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Botnet Security IT Linux

The Hail Mary Cloud and the Lessons Learned 99

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

The Hail Mary Cloud and the Lessons Learned More

The Hail Mary Cloud and the Lessons Learned

Comments Filter:

  • Denyhosts (Score:5, Informative)

    by mcelrath ( 8027 ) on Saturday October 05, 2013 @01:35PM (#45045955) Homepage
    The solution to low-frequency brute force attempts is Denyhosts [sourceforge.net]. 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.

    • Re:Denyhosts (Score:5, Informative)

      by Anonymous Coward on Saturday October 05, 2013 @01:43PM (#45045997)

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

    • Re:Denyhosts (Score:4, Informative)

      by Noryungi ( 70322 ) on Saturday October 05, 2013 @01:56PM (#45046113) Homepage Journal

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

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

        You can do the same with iptables on Linux using the module "limit". See the manual page for "iptables-extensions" for the details. DenyHosts may have it's good points, but mostly it just complicates things. There is already a lot of functionality in the packet filte

    • Re:Denyhosts (Score:5, Informative)

      by module0000 ( 882745 ) on Saturday October 05, 2013 @03:03PM (#45046517)

      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.

    • If I remember correctly, denyhosts relies on the old /etc/hosts.deny tcpwrappers functionality, which I thought had been deprecated for years now. (Still works in ancient "enterprise" distributions of course, up to at least RHEL5.x though). I see a few other mentions of fail2ban, which in my mind is the successor to denyhosts - it uses iptables directly to accomplish the same thing.

  • Low intensity ssh brute-forcing. (Score:5, Insightful)

    by foobar bazbot ( 3352433 ) on Saturday October 05, 2013 @01:35PM (#45045957)

    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.

    • Re: (Score:1)

      by Anonymous Coward

      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.

      Tricky passwords is enough - they can't guess them in a lifetime with a low-intensity attack. Do not force people to change passwords (except if there ever is a security breach), that makes it much easier for them to put up with really long passwords. And if you live in a part of the world where your keyboard h

      • Re:Low intensity ssh brute-forcing. (Score:5, Interesting)

        by foobar bazbot ( 3352433 ) on Saturday October 05, 2013 @02:34PM (#45046355)

        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.

        • One thing that he seems to be assuming is that the botnet is a bunch of Linux boxes. I think that is a pretty poor assumption. Nothing stops a botnet of compromised Windows machines from trying to SSH into a Linux machine. Also, he runs BSD, so why did he not say "Linux, BSD, and Other OSes"? I'm sure it wasn't for sensationalism. Also why is he calling it a botnet? Isn't a botcloud ;-)

          • why did he not say "Linux, BSD, and Other OSes

            Maybe because the default setting in BSD [freebsd.org] is
                      PasswordAuthentication = no
            and
                      PermitRootLogin = no

            Could that be why he didn't mention the botnet logging into to lots of BSD boxes with password authentication?

            • "Could that be why he didn't mention the botnet logging into to lots of BSD boxes with password authentication?"

              No. No it could not. The first reason is because it is disingenuous to imply that the Hail Mary Cloud is succeeding in breaking into "lots" of Linux boxes. It is also the default on every decent Linux distribution out there that root logins via ssh are not allowed. Also, as you said, it is the default setting. Perhaps you were unaware of the word default and what it means, because the last ti

              • This is really one of those literal RTFM situations...

                Notice I was talking about password authentication?

                As noted above, PasswordAuthentication defaults to no on FreeBSD.

                How about some popular Linux flavors?
                Ubuntu? Debian? Fedora?
                Those are the top 3 in usage, right? So I checked those and guess what?
                PasswordAuthentication defaults to yes.

                So yeah, could that be why he didn't mention the botnet logging into to lots of BSD boxes with password authentication?

                Correct me if I'm wrong..

                Perhaps you could bother to read the whole comment yo

                • "This is really one of those literal RTFM situations..."

                  No. It's really more of a "You're a troll who is misrepresenting the facts" situations. I did read what you wrote, and as I said: No!.

                  "PasswordAuthentication defaults to yes."

                  Who cares what PasswordAuthentication defaults to, when PermitRootLogin is no? The chances that they will brute force a root account password with "PermitRootLogin no" is just as equal to zero. Furthermore, with PermitRootLogin yes the chances are also zero if a strong passwor

                  • You're totally off topic. If anyone is a troll, it's you. Sadly, it appears you're just an idiot who spouts off without even knowing the basics of what is being discussed.

                    The botnet being discussed tries to login with a series of usernames over time with each member of the botnet attempting to guess a different password for each username in the series.

                    So PermitRootLogin is irrelevant to defending against it, other than presumably it might eventually try root among all the other usernames it's attempting.

                    Hav

                    • It's no mistake. In both cases a system with proper security (i.e. strong passwords) has no chance of being compromised. Period. Your argument is: If the system admin is a moron then they have a very slim chance of getting in, but it is still a chance." You can say that for both BSD and Linux. There is no fundamental difference. Even if I have a user whom I allow to set a password that isn't strong only that user will be compromised. They can try their local priv exploit all day; it isn't going to wo

                    • Now that you've changed your tune, it's obvious you realize you were wrong all along. Of course, with your posting history on other things, that's not much of a shocker, is it? You have a lot of these "misunderstandings".

                      The botnet doesn't need a privileged user. It can generally use the machine's resources for whatever it desires, including making outgoing connections to compromise more hosts, with just a non-privileged user.

                    • I didn't change my tune you frigging troll. I never said it needs a privileged user. I said it will never compromise an actual system, Linux or BSD, unless it is insecure. Your ridiculous claim is that BSD is magically secure and Linux is by default insecure. Just admit that you are a troll and a moron and move on with your life. Plonk.

                    • Re: (Score:2)

                      by illtud ( 115152 )

                      I'm just posting to say I haven't seen:

                      >... Plonk.

                      For years. As in 15, at least. Wow.
                      Note that this is judgement-neutral, I'm just saying 'hi' to once-familiar term, this is judgement-neutral!

    • Or you could just use a strong password.

  • "I'm not really in a mind to offer help or advice to the people running those scripts, but it might be possible to scan the internet from 255.255.255.255 downwards next time."

    Yes, start with all the multicast addresses. That'll work for them! ;)

  • Executive summary (Score:5, Informative)

    by Anonymous Coward on Saturday October 05, 2013 @02:20PM (#45046257)

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

  • STOP USING PASSWORDS FOR AUTHENTICATION! why not only allow connections in authorized_keys??? if you feel so inclined, add a password on top of the authorized key.

    there is only so much programmers can do to make it user friendly and secure.

    • Re: (Score:2)

      by smash ( 1351 )
      The passwords in keys are for a different purpose - they are in case the key gets stolen. You should password protect your keys unless they are single purpose, limited privilege for remote access by non interactive scripts.

    • Ow please.. This is so old.. haven't allowed pasword logins in the last decade or so..
      Why on earth would anyone have allowed password logins for the last 10 years? Or: Ever?
      Someone that's savvy enough to get a shell account is savvy enough to use a key pair.
      It's 2013. I mean, seriously, PASSWORDS? for SSH?? You must be joking.

      -f

    • Re: (Score:2)

      by fa2k ( 881632 )

      Keys are good for security, but random passwords of 8 characters (and even less) are totally safe against online brute force attacks. Passwords are frequently needed when new systems are installed. After all, you can't go moving keys around on an USB stick every time a new host is set up.. Using passphrases on the SSH keys is fine, but if we neglect the security of the keys themselves, it turns an online attack into an offline attack: the keys are much easier to brute force, and it can be distributed

  • I've seen these on my own home system going back at least as far as 2008 [slashdot.org]. That said, i don't think he has their entire plan correct. The writer's statement

    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.

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

    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.

  • Here is the guide we provide to the SSH users at our University: https://it.wiki.usu.edu/ssh_description [usu.edu]

    Some of the major points:

    • We try to use multiple overlapping security layers to protect SSH:
    • * The firewall limits the vulnerable scope of SSH to a few trusted hosts.
    • * The firewall can also be used to prevent credential guessing by rate-limiting connections to the SSH port.
    • * The SSH Port is treated as a shared secret. Only interesting, targeted attacks find the SSH server.
    • * The SSH serve

Slashdot Top Deals

A committee takes root and grows, it flowers, wilts and dies, scattering the seed from which other committees will bloom. -- Parkinson

Close