Immutable Security

Peter Handsteen, a.k.a “That Grumpy BSD Guy” recently observed a round of low and slow SSH password guessing attacks against his server. For those not familiar with the term “low and slow” this is an attack meant to be slow enough that IDS systems aren’t tripped but fast enough where the attacker has a decent chance of getting access. The interesting thing about this attack is that it is coming from several different sources and is likely a botnet design just for this purpose. There is about one attempt per minute against the root account. While this doesn’t sound like much, it’s enough for an attacker to cycle through 1440 common passwords in a single day. And since each few attempts come from a different source, it would be difficult to block at the network level. Admins who use passwords like root, test, admin and password are likely to fall victim.

OSSEC detects the invalid logins, but a cursory look at the length of time between each failed attempt reveals that it is not likely to trip the “SSHD brute force” rule (ID 5712). This means that while OSSEC will detect this, the threshold is low enough where you may not get an e-mail alert. This makes sense, since most people would not want an alert for just a couple of failed logins every minute or two.

So what can we do to defend against these types of attacks?

• Well, for starters, the basics of choosing good passwords apply. There is no vulnerability being exploited here other than poor password practices. This is in effect a people problem. Choose stong passwords and audit them regularly.
• It’s also a poor practice to login as root directly, especially thorugh SSH. Adding ‘PermitRootLogin no’ to sshd_config will prevent exploitation through SSH even with a poorly chosen password.
• Invalidate the password for root by locking the account, or just placing something like ‘*’ in the password field of the shadow file. Then give your non-privileged account access through sudoers. To attain root, simply type ‘sudo su -’ and the password of your non-privileged account.
• “Tune down,” then “tune up.” Tune your IDS to the point at which the alerts you’re getting are meaningful and need to be seen in near real-time. After you have done that (which could take several months in a large environment), use the GUI interface of the tool to see what it thinks isn’t important enough to alert you on. The tool’s idea of importance may be different than your own.

Exploitation from attacks like this are entirely preventable. Using layers of security mean that even if one defense fails, another steps in to hopefully take its place. The key is to implement the layers before the system is placed into production, then manage it well throughout its life.