Risk of running services on ports >1024

Question

In a Reddit thread on securing SSH access to a Raspberry Pi, one commenter recommended running SSH on a non-standard port of 8123.

Another commenter had this to say on the matter:

Don't change your SSH listening port to anything >1024. An unprivileged rogue process can wait for the SSH daemon to terminate and establish a listening socket on that port. Ports <1024 are reserved to processes running as root.

I personally do not feel this is a significant risk with SSH as:

1. The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue.
2. If key based authentication is in use, little can be gained from intercepting communications.

However, not all protocols have this functionality. For example, web proxies running on port 8080 or 3128 generally have no authentication.

How significant is the risk of running on a port number > 1024?

Answer 1

Services running on ports < 1024 (at least on *nix servers) are generally considered to be more secure, because they require root (or a trusted user that has root privileges) to start them - whereas services running on ports >= 1024 could be run by an untrusted (possibly rogue) user on the server.

So, it is plausible that an attack like the one described in the reddit post that you copied could be pulled off by a malicious user on the server, without root privileges.

With regard to "1.The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue.": This is true - if a user had logged into the server previously, and his SSH client pinned the server's public key. In this case, the user's SSH client would (presumably) warn him that the server's public key has changed, and the user would (presumably) know that something's up. But, the user would only be warned if he had logged into the server previously and his client pinned the server's public key.

With regard to "2.If key based authentication is in use, little can be gained from intercepting communications.": I'm skeptical about this. The user's SSH client would send its public key, as usual during the start of an SSH session, then the rogue SSH server could simply authenticate the client (as is normally the case when the client's public key is present in the server's authorized_keys file) and proceed with the session using the public key that the client sent.

Answer 2

If there's a rogue process running on your Raspberry Pi then you have already been compromised, although the attacker or automated malicious process obviously hasn't managed to elevate to root yet.

The rogue process cannot access the host keys, so would present a different fingerprint to the user when connecting, alerting them to an issue.

That is true. However this depends on whether your users are likely to notice this or not. On an average system, many users will click through warnings, however with a Linux based system using SSH this bar is usually raised high enough that only semi-expert users will be connecting, increasing the possibility that they will realise something is wrong.

If key based authentication is in use, little can be gained from intercepting communications.

Agreed. Even though the public key could be retrieved from the SSH client, there would be no way of the rogue service intercepting the private key as this is never sent.

There may be a risk if password authentication was used instead, although as noted the user would have to had ignored any host key warning messages.

Therefore, in summary there is no extra risk introduced using a non-privileged port for SSH when public key authentication is in place. The only attack I could think of is where the rogue SSH daemon will let a user connect in the hope that the user immediately issues a sudo/su and then enters a password which is then captured. If this was not done immediately then because the rogue process will not have the same permissions as those of the real user, the user will likely notice that something is amiss.

Answer 3

Some SE threads are discussing the pros & cons of this from a security perspective. Does changing default port number actually increase security? and Should I change the SSH port to < 1024?.

However, there is also a risk involved, that the rogue process you mentioned actually locks you out of your server. The chances that this happens may be low, but what if? You will be lucky if you can reboot the server without SSH access. And hopefully at startup the SSH daemon is claiming the port before the rogue process.