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

Denyhosts

[mcelrath]

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

[Anonymous Coward]

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

[Noryungi]

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

Executive summary

[Anonymous Coward]

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

Re:Denyhosts

[module0000]

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.

Some more guidance on setting up SSH

[dweller_below]

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 server should not allow known usernames including root. The attacker must find a username.
• * The admin is trained to create good passwords for his usernames.
• * SSH users are taught to verify the identity of their systems when they first connect.
• * System admins must regularly review the activity of their SSH servers.
• * USU IT Security monitors all SSH connections, including ones on non-standard ports. We follow up on interesting connections.
• * USU has SSH Honeypots that help us respond to SSH attack.