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
This randomly selects a port in the privileged port range. Check that it's not used by running “fuser -n tcp
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 email@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.comments powered by Disqus