If you run an SSH server, and have left it on the default port, you’ll probably notice in time lots of login attempts. These login attempts will be from random IP addresses, and usually try lots of different username/password combinations, and hopefully failing.
This article will focus on OpenSSH – I’m not sure if all SSH daemons have similar options (such as AllowUsers).
Unfortunately, people realised that administrators often used usernames such as “test” with password “test” to, you guessed it, test certain functionality. They also realised that administrators would leave these accounts in place even after testing. This is obviously a big security risk – if anyone was to guess “test” and “test” (and lets face it, it’s not that difficult), they would have access to your server. This goes for any common username with a weak password combination.
Obviously it’d be very boring for someone to sit down and try lots of different IP addresses on the internet, check to see if ssh is open, and if it is, try lots of random username/password combinations. To get around this, bots/scripts were developed to carry out this task – start it up, and let it go – any successful attempts, tell the user and move on to the next potential victim.
So, what can you do to combat this at a very basic level? Well, as they’re usually bots, then a few basic steps can go a long way to preventing them from probing your server:
- Change the SSH daemon to run on a different port – by default, SSH runs on port 22/tcp. This is the port which SSH runs on “out of the box”. It’s possible to change this to something random (providing it’s not being used by something else) and that’s a good first step. Of course, if they did try a different port, and found your SSH service, it makes this step pretty useless, but they tend to just stick at the default for the initial probing.
The required option in sshd_config is the “Port” line; to change the port, it would be “Port 2202″ for example to put it on Port 2202 (tcp). Bear in mind though, it’s easy to lock yourself out if you’ve changed the port on the ssh daemon but forgotton to change any firewalling/routing – you have to allow the new port through your router, firewall, etc. - Only allow certain users SSH access – the AllowUsers setting in sshd_config is useful in that you can restrict SSH login to certain users – what this means is that any random attempt, where the username isn’t listed under the AllowUsers, will be blocked. Also, you should disallow root logins directly via SSH.
The required option in sshd_config is the “AllowUsers” line. Usernames are space seperated so, if you want two usernames to be able to SSH, the line would be: “AllowUsers username1 username2” and so on. - Use SSH Keys (with no password authentication) – You may be using password authentication, which is fine, but passwords can be guessed. By using SSH keys, unless the client connects and passes it’s private key information to the server, it won’t be allowed to authenticate. This means that any username/password attempt will not even attempt to authenticate, which is obviously a good way to prevent random password attacks!
Using SSH keys is a bit too indepth for this post, but check back soon where I will document this feature in more detail.
I’m not saying this will make your server invincible to these attacks; it won’t (well, SSH keys will probably stop password attacks if setup correctly!), but it’ll certainly help against the casual probe – if you allow a user access, who has a simple password, and a bot does probe a non-standard port and gets lucky, your machine will be compromised, but it certainly makes it a little bit more difficult for the automated, “lets get lucky” processes out there.
Look out for another article on droptips soon, where I will show how you can rate-limit attempts using iptables on Linux -this means, that if you do keep SSH on port 22, and you get, say, more than 5 new SSH connections in a minute from the same host, you can block the IP it’s coming from automatically, as it’s probably not up to much good!
Please let me know if you have similar tips with securing SSH access. What do you do? Find me on twitter @dazuk or by using comments below!