Data Circle

After some comments about security recently on the Bytemark IRC channel, I started to look through the logs for the various services which I run on my servers to see if there were any obvious security holes which needed plugging. Most services seemed secure, and I’d already cracked down on spam, but I did notice a lot of failed login attempts for ssh in the authentication log (/var/log/auth.log on Debian systems if you want to check your own). Every so often, there would be a burst of login attempts from a given IP address, which would either attempt to brute force the root password or try to login to common account names (e.g. guest). I only have a small number of accounts on my servers anyway, and the root passwords are all strong, so I wasn’t too worried that any of these attempts would succeed, but nevertheless I wanted to take some steps to reduce or eliminate them.

First, I considered reporting the offending IP addresses to their netblock abuse contacts. Unfortunately many of the connections came from Brazil or China, where I don’t expect to get a response. Even when I contacted European ISPs with logs of what machines on their netblock were doing, I didn’t receive any replies, though it’s possible they took action and couldn’t tell me about it.

Since trying to get the netblock admins to tackle the problem at its source didn’t do much good, I decided to deploy some technical measure instead, namely:

1. Disabling root logins over ssh.
2. Moving ssh to a different port.

Disabling root logins does what it says on the tin, i.e. you can prevent anyone from logging in as root over ssh, even if they provide the correct password. The response from the server is the same as if an incorrect password was entered, so they will not know that you have disabled this feature. The relevant setting can be found in the ssh config file (/etc/ssh/sshd_config on Debian):

PermitRootLogin no

If this is currently set to PermitRootLogin yes, simply change the yes to no and reload ssh (/etc/init.d/ssh reload). You’ve now effectively blocked anyone from brute forcing your root password over ssh, although the login attempt messages will still appear in your logs.

Moving ssh to another port is the second effective method of stopping people from trying to brute force their way into your machine. By default ssh runs on port 22, but there is no reason why it needs to, other than convention. You can easily change the port using the following directive in the ssh config file:

Port 22

You can change the value to anything you want, so long as another service is not running on the same port—e.g. don’t change to port 80 if you’re already running a web server. Most brute force login attempts will come from automated programs which assume that ssh is running on port 22, so if you move the service to another port they will simply receive a ‘Connection refused’ error message. Making this change has, as of the time of writing, completely eliminated all the failed login attempt messages in my authentication logs.

You could of course go one step further and only permit ssh logins from users with keys or from specific IP addresses, but that creates a degree of management overhead which you may not wish to bear. In my case, I access four different servers from various locations and machines, so it’s simply not practical to use such a tight restriction.

Other ssh security tips which you might want to try if you are really paranoid include:

1. Use fail2ban to scan your log files and automatically block any IP addresses which produce too many failed login attempts.
2. If you have multiple IP addresses, limit ssh so that it only runs on one of them, using ListenAddress.
3. Throttle ssh connections so that only one connection per IP address can be made in a given length of time – e.g. every minute. This will significantly slow down any brute force attempts.
4. If you don’t need ssh, simply disable it entirely (this is probably not an option for most administrators though).

Hopefully these tips will help you to lock down ssh, as it’s in all our interests for machines on the Internet to be as secure as possible.