Does it improve security to use obscure port numbers?
Does it improve security to use obscure port numbers?
If you're already using high entropy passwords or public key authentication, the answer is "not really". Mostly you're just getting rid of noise in logs.
I worry about the unintended consequences of deviating from these recommendations.
It depends on what port was picked. In Linux, by default all ports below 1024 require root access to listen on them. If you're using a port above 1024, any user account can listen on it if there's not already a process listening.
Why does this matter? Let's say you chose to set ssh to bind to port 20,000. If someone could stop the SSH process on a server (let's say they somehow found a way to crash the process), and had local access to that server, they could then run their own SSH server on port 20,000 before the service restarted. Anyone logging in would then be logging in to the bad guys SSH server.
This isn't as big a deal as it used to be, since these days it's only trusted IT staff that are given login access to servers. But still, it does have the potential for privilege escalation and other nastiness if an attacker gets a foothold on your server.
Other than being below 1024, there's nothing special about the number 22. Largely it was chosen because SSH was a replacement for telnet at port 23, and 21 was already taken by FTP. As long as you pick a port below 1024, the port doesn't really matter.
Is this good practice or not? Should we use well known ports?
I wouldn't say I recommend it. I also wouldn't advise against it. As I said, it avoids a lot of noise in log files, but the benefits are largely limited to that.
For anyone interested in the background story on SSH, you can find it at: https://www.ssh.com/ssh/port
Yes, it does. The real question is: By how much?
Why it does? You already have basic security, so the everyday bot attacks don't worry you. But there could be a 0-day tomorrow and the attackers know it won't be long until a patch is out, so they scramble to use it and won't bother with something complicated - they will just hit as many machines as possible on the standard port. Any kind of theoretical SSH worm would also use this strategy. You would be protected against that.
How much additional security does this gain you? It protects against this and maybe 2-3 other specific scenarios. It will add a few minutes at best to any targeted attack by anyone who is not a total idiot. It does nothing to the scenarios you are already adequately protected against.
Plugging those numbers into your favorite risk analysis method and you should come up with something relatively small. On the downside you have the added effort of setting a non-standard port number, documenting it, maybe missing it during a troubleshoot and wasting some time, etc.
My guess is that you would just about break even with an analysis. Or, in other words: Yes, it does improve security, but it's not worth the trouble because the improvement is very small.
No, it will not improve security. It may reduce log clutter, as automated attacks will only try default ports for e.g. ssh. But the port will still show up as SSH in a port scan, and shodan.io.
Those automated attacks typically aim for low hanging fruit, with standard usernames such as root, smith and so forth, and weak passwords. If they succeed, you have a problem in the first place.
If you configure ssh to only allow key authentication, disallow root logins, and use sensible passwords, use fail2ban or a similar mechanism to block offenders, they're not a real threat.
I use fail2ban configured to temporarily block for five minutes after three failed attempts, and for a week after 3*5 failed attempts. This reduces log clutter and blocks any real progress on a brute force attack.
For a targeted attacker it will make no difference which port stuff are listening at. It only matters for automated attacks that, in my opinion, are negligible risk.