The various SSH daemons have had their fair share of vulnerabilities. We're now seeing worms that just connect to random IP addresses and try a bunch of different account names and passwords, looking for someone who used a week password. Over the last month, we've gotten inquiries about what to do about this from all different directions. Consulting and hosting clients have been concerned, as well as several inquiries to various community forums we're on.

One good place to start is to make sure that you are using good passwords. "apg" is a good tool for generating fairly good passwords. Another tool, "gpw", which has gotten fairly hard to build these days, generates random passwords based on common sets of English character patterns, to make them more pronounceable. "apg" tries to do this, but it's not as good as gpw, IMHO. Personally, I usually use a string of 32 random characters and numbers for my passwords, because I mostly use SSH public key authentication...

If you are using SSH public keys for authentication, you can completely disable the ability to use passwords for authentication. To disable password authentication, first make sure that you can log in to at least the root account using the SSH public key, then change "/etc/ssh/sshd_config" so that "PasswordAuthentication" is "no". Now re-start the SSH daemon and test that you can no longer log in using passwords.

One thing I've been doing since the <gasp> mid-90s, in anticipation of just such an attack, is to put the SSH daemon on a non-standard port. I'd recommend randomly selecting a port by doing (in bash):

echo $[RANDOM%1024]

This randomly selects a port in the privileged port range. Check that it's not used by running "fuser -n tcp <port number>" and find out what it's reserved for by looking for that port in "/etc/services". For example:

guin:jafo$ echo $[RANDOM%1024]
138
guin:jafo$ fuser -n tcp 138
guin:jafo$ grep 138 /etc/services
netbios-dgm     138/tcp                         # NETBIOS Datagram Service
netbios-dgm     138/udp
guin:jafo$ echo $[RANDOM%1024]
844
guin:jafo$ fuser -n tcp 844
guin:jafo$ grep 844 /etc/services
guin:jafo$ 

My first choice wasn't very good, since there are already a bunch of worms that try attacking port 138. However, my second choice wasn't reserved in "/etc/services" at all.

Next you need to modify "/etc/ssh/sshd_config" and change the "Port" line so that it's not commented out and lists the port you specified. Now you'll have to restart your SSH daemon ("service sshd restart" or "/etc/init.d/sshd restart" for Red Hat and Debian respectively). Of course, you'll probably also want to make sure that this new port is open in your firewall.

When using a non-standard port, you probably want to set up your ssh configuration so that you don't always have to specify the port. Let's say you've set up your machine "www1.example.com" to use port 844. On machines that you SSH to that machine, you might want to set up something like the following in your "~/.ssh/config" file:

Host www1.example.com www1
   Hostname www1.example.com
   Port 844

This sets up the host with an alias of "www1", and then says that the SSH daemon is on port 844. You will now be able to run "ssh user@www1" or "scp foo user@www1.example.com:/tmp", without having to specify the port number.

Another thing one could do is to firewall off your SSH port, and use something like port-knocking to open up the SSH port. In port knocking, you can send secret sequences of data to a number of ports, which may or may not be open, to cause an action to happen. It's like a secret knock that your system responds to. Or, if you have an open SSL web server, you could have a password protected page that runs a CGI which opens the SSH port. I haven't done any of those things, though.

Those are the things I recommend for protecting against the current crop of SSH worms out there.
(Post Reply)