Having your SSH server on an alternate port provides no extra security today

July 6, 2018

Every so often I either hear someone say that having your SSH server on a non-standard TCP port provides extra security or get asked whether it does. On today's Internet, the simple answer is no, it doesn't provide any extra security, or at least that it shouldn't. To explain that and convince you, let's talk about the two risks that your SSH server opens you up to. Let us call these the the scattershot risk and the targeted risk.

The scattershot risk is mass SSH password guessing. Pretty much any system on the Internet with an open SSH port will see a legion of compromised zombie machines show up to repeatedly try to guess username/password combinations, because why not; if you have a compromised machine and nothing better to use it for, you might as well turn it loose to see if you can get lucky. Of course SSH is not the only service that people will try mass password guessing against; attackers are also constantly probing against at least authenticated SMTP servers and IMAP servers. Probably they're trying anything that exposes password authentication to the Internet.

However, you should never be vulnerable to the broad risk because you shouldn't have accounts with weak passwords that can be guessed. Especially you shouldn't have such accounts exposed to SSH, because there are a number of ways to insure this. First, obviously you want to enforce password quality rules (whether just on yourself, for a personal machine, or on everyone). If you're worried about random accounts getting created by software that may mis-manage them and their passwords, you can lock down the SSH configuration so that only a few accounts can log in via SSH (you probably don't need that postgres system account to be able to SSH in, for example). Finally, you can always go all the way to turning off password authentication entirely and only accepting public keys; this will shut down all password guessing attacks completely, even if attackers know (or guess) a username that's allowed to log in remotely.

(SSH is actually a quite easy daemon to lock down this way, because it has good authentication options and it's relatively easy to configure restrictions on who can use it. Things like IMAP or authenticated SMTP are generally rather more troublesome because they have much weaker support for easily deployed access restrictions and they don't have public key authentication built in in the same way.)

The targeted risk is that someone will find a vulnerability in the (Open)SSH server software that you're running and then use it to attack you (and lots of other people who are also running that version). This could be the disaster scenario of full remote code execution, or an authentication bypass, or merely that they can work out your server's private key just by connecting to it (see also). This is an actual risk (even if it's probably relatively unlikely in practice), but on today's Internet, moving SSH to an alternate port doesn't mitigate it due to modern mass scanning and things like shodan and zmap. If your SSH is answering on some port, modern mass scanning will find it and in fact it's probably already in someone's database, complete with its connection banner and any other interesting details such as its host keys. In other words, all of the things that someone unleashing an exploit needs to know in order to target you.

You could get lucky, of course; the people developing a mass exploit could be lazy and just check against and target port 22, on the grounds that this will sweep up more than enough machines and they don't need to get absolutely everyone. But don't count on it, especially if the attackers are sophisticated and intend to be stealthy. And it's also possible that the Shodan-like search engine or the Internet scanning software that the attackers are using makes it easier for them to just ask for 'all SSH servers with this banner (regardless of port)' than to specifically limit things to port 22.

PS: The one thing that moving your SSH server off port 22 is good for is reducing log noise from all of the zombie machines trying scattershot password guessing attacks against you. My personal view is that there are better alternatives, including not paying attention to your logs about that kind of thing, but opinions differ here.

Comments on this page:

With regards to password guessing, it's not too difficult to install something like fail2ban. Helps reduce noise in the authentication log for stuff like "ftpsuser", "maint", "admin", and other low-hanging fruit that probably doesn't exist on your system. We also tend to get a lot of scans on some of our SMTP servers.

Distro packages also tend have pre-canned recipes for the most common needs: SSH, SMTP, IMAP, etc. I also find it handy that you can whitelist IP (ranges) so that folks from internal networks don't get locked out if they fat finger the password a few times.

Having run fail2ban in the past, it's easy to install, but difficult to make useful. 90% of attackers blindly deploy countermeasures already, and I don't want to set limits so low that they may lock out legitimate users after a humanly reasonable number of failures.

Between that and the lack of IPv6 support at the time, I ended up uninstalling it. It wasn't paying its way.

Written on 06 July 2018.
« I'm seeing occasional mysterious POST requests without Content-Types
We've decided to write our future Python tools in Python 3 »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jul 6 23:00:02 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.