Guess what? SSH again!

Published: 2009-04-17
Last Updated: 2009-04-17 13:57:24 UTC
by Daniel Wesemann (Version: 2)
8 comment(s)

Our DShield data shows that password guessing attacks against SSH keep going strong. As if this alone were not indication enough that somebody somewhere is collecting bots and making money, we also keep receiving reports and logs from ISC readers who got hit and missed, or even hit and sunk.

While I'm aware that ISC readers probably don't have to be told, let's nevertheless try again to get the word out: If you are running any SSH server open to the Internet, and your usernames and passwords aren't at least 8 characters or so, your box is either owned by now, or about to be. It doesn't matter one bit what sort of device it is - those who run these scans have proven to be equally apt at taking over a Cisco router as they are at subverting an iMac.

Countermeasures shown to help include:

- Filter (by IP) who can get to your SSH. Firewalls rule! Who can't get to your SSH can't brute-force your SSH.
- Reconfigure your SSH to only use password protected SSH keys and not permit plain passwords anymore
- Use hard to guess usernames. Yes, usernames.
- Move your SSH off port 22 to some obscure corner of the port space
- Scan your own network to find out where you have SSH running before others do. You might be surprised ...
- Use "fail2ban", though this doesn't help a lot anymore against the distributed scans we see lately
- Educate your users to use good passwords. Yes, even those users who have proven to be immune to enlightment.
- Watch your logs. It's a great way to learn. And knowing what the "daily noise" looks like is imperative to spot "oddities"

Best is a combination of several of the above. One university I know allows password-based SSH from a couple of known networks only, and insists on certificate-based SSH from all others. A reader, whose systems at a community college had kept getting hammered, had the following anecdote to share: "No matter how hard we try, users keep picking bad passwords. So we decided to give them difficult to guess usernames. If a user's ID is @455%userid, it doesn't matter much anymore how dumb his password is!"

Before you purists now rush to the contact button at the top of our page -- yes we know that picking complicated usernames and moving SSH off port 22 are "security by obscurity" and not real security. But fact is that they both help to thwart the rampant brute force attacks. Bulletproof is nice, but if it can't be had, good camouflage sure beats being a plum target!

Let us repeat: SSH password guessing break-ins happen daily. If you haven't taken this seriously so far, DO SO NOW.

Update: http://wiki.centos.org/HowTos/Network/SecuringSSH contains a decent list of tips on how to secure sshd.

Keywords: bruteforce ssh
8 comment(s)

Comments

telnet ns1.dshield.org 22
Trying 70.91.145.9...
Connected to ns1.dshield.org.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3
If someone could tell me how to enforce password protected keys, I would be eternally grateful. As far as I can see, its not possible.
Let's aim toward using cryptographic keys on a PIN-protected (eg. OpenPGP) smartcards, or similar. That hopefully protects against having your password keylogged (and/or your SSH identity key stolen) on a compromised/untrusted machine, too.
@Steven: After configuring login via authorised keys, set "PasswordAuthentication no" in your sshd_config. That doesn't enforce that the keys are password-protected, but it prevents plain passwords from being used (or brute-forced).
@ nyt: that only tests connectivity. It's not like you're actually logged into that machine. That's typical of any SSH service when you test it with telnet. When you can do something more than telnet, let us know (or maybe not, since that would constitute malicious activity).
Most important tip of all: If you don't need or use SSH, don't enable it/do disable it. None of the servers to which I have physical access have SSH enabled, although they do do some rather nasty things to folks connecting to port 22.
@Steven Chamberlain: Smartcards would be great, but they won't be practical until the vast majority of computers support them. I've never seen one that did, so I'm guessing that's a long way off.
If you don't like script-based tools like fail2ban, try sshguard (http://sshguard.sourceforge.net/). It's written in C, supports whitelists and IPv6, and does intelligent hostname/IP deciphering. It's faster, better and sexier IMO.

Diary Archives