Protecting SSH From The Masses

SSH brute-force attacks are not uncommon against computer systems sitting on public IP addresses. Script kiddies and botnet-infected systems are scanning the Internet looking for low-hanging fruit (think: weak passwords) to leverage for additional attacks, website defacements, or attack-tool storage.Usually, the scans come from the same source trying user names like admin, root, test, and db. The passwords are typically the same as the user name plus common ones like I had mentioned in my blog about FireForce. The sad thing is that the scans are successful -- and that's why they continue.

In a way it's a little amusing, because I've seen it time and again where the user or admin who you were sure had extremely well-secured systems ended up being compromised because he was doing some testing, created a test account with an easy password, and forgot to delete it. The irony is that these particular systems probably have some of most complex passwords you've ever seen, but they fell because of a guessable one where the admin was being lazy.

During mid-June, we saw an uptick in the number of distributed SSH attacks where each account attacked was done by a different IP. There have been various combinations over the years, but it's always interesting to see these because you know that the machine connecting to you is infected and part of some botnet. ISC also noted the increase in its June 18 diary.

There are several good steps for securing SSH. The easiest is to change the port to something other than 22. While this seems silly, it is effective at eliminating the usual daily scanning. We all know that security through obscurity surely shouldn't be the only defensive measure, but in this case it cuts down the noise. If you start getting brute-force attempts on the new port, then you're obviously dealing with someone more determined at getting in because he had to perform a port scan to find the new SSH port.

The other effective measure is to disable password authentication and used only SSH keys. This means you'll always need your key with you when you're accessing the server remotely, but it prevents password attacks.

I also like fail2ban for automatically blocking IPs that are attempting repeated logins. It monitors your logs looking for repeated failures and can add a firewall rule using a host-based firewall like ipfw and iptables to block the attacker after a configurable number of failed logins over a user-configured amount of time.

Looking back through my fail2ban log for June, I can see the same trend that others saw, whereas the beginning of June was pretty quiet with a sudden jump from 330 blocked IPs on the 16th to nearly 2,500 on the 17th. Since then, it has been consistently 1,000 to 1,500 hosts blocked every day.

Securing SSH is not hard, but it does require a small amount of effort to make the configuration changes, create keys, and install a tool like fail2ban. But the time required is certainly less than what you'll spend rebuilding the system if it gets owned.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.