Does it improve security to use obscure port numbers?

Question

I recently started a job at a small company where the CTO prefers to host SSH services at obscure, high numbered ports on our servers rather than the well known port 22. His rationale is that "it prevents 99% of script kiddy attacks." I'm curious whether this is considered bad practice.

Intuitively this seems sensible. But we are both largely self taught, and I am uncomfortable with the idea of improvising our own security procedures rather than following well established convention. I know that in general cryptographic schemes and protocols are painstakingly designed by teams of experts, and that every detail is intended to protect against some kind of attack, no matter how insignificant it might seem. I worry about the unintended consequences of deviating from these recommendations.

But my colleague seems to have evidence on his side. He was able to demonstrate that we do get dozens of attacks every day that try port 22 and just move on. I know that generally we should avoid security through obscurity, but moving away from this common target really does seem to thwart most attacks.

Is this good practice or not? Should we use well known ports?

ADDENDUM

We do not rely only on the obscure port. We have many other security measures in place, including mandatory hardware keys. I will restate my question more clearly.

Is there any reason why port 22 in particular was chosen for SSH? Is there anything dangerous about using other ports?

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

Changing default port can save you from port scan and script kiddies but you may not be able to withstand against targeted attack where the attacker could identify the running services irrelevant to the ports.

If you wanted to just get away form script kiddies this may be helpful but you may not be able to secure your self from rest of the advance attacks.

My recommendation is to use default port (may reduce your administrative overhead) and deploy multi-faced security defenses to mitigate attacks.

For example with default port in use, deploy certificate based authentication with SSH is allowed to only certain trusted sources.

Answer 5

I would say yes, use non-normal port numbers as this will filter out a LOT of automatic bots. but don't rely on it, as a lot of bots i have noticed will scan a network/host for any open ports and try them.

The best thing is to implement some good security on your SSH port. disable root login, whitelist IPs if you can, don't use passwords for logins ( use keys ), also enable a notification for any logins. And setup a firewall, this is important.

Answer 6

Obscuring ports on high numbers like this only stops simple bots which will look for well known ports. Script kiddies and determined hackers can simply port scan the rest of the port range to find a service, so you are only stop some log noise.

It doesn't really matter about convention of not listening on the standard port for that service. The developers of that service give you the option to run it on any other port, and any program that may interact with it will have an option to specify what port your wanting to speak to.

I agree with other posts here that sensitive ports like SSH should be kept in privileged port space bellow 1024.

A better way to obscure SSH which actually works is to do a port knock. This involves closing off the port at iptables until a sequence of ports have been "knocked" that then will open the desired port.

EG you might send a packet to 8000 4545 28882 7878. Once you desired sequence is entered iptables will unlock your desired port. This really does stop the majority of script kiddies and hackers as no port is advertised. But this does not stop against replay attacks, but at the point you have bigger issues to worry about .

https://en.wikipedia.org/wiki/Port_knocking.

Really you should be using TCPWrappers and only letting known ips and network ranges access ports like SSH. Do you need to let IP's from china access SSH? Or will developers only need to access from the office LAN? If they work remote make them VPN into the LAN

Answer 7

As mentioned by others, migration to non-standard port is not a security solution because you filter out just naïve-level attacks.

Same time, the migration can be much more valuable if combined with other precautions. For instance, you place a honeypot on the standard port (an environment that is physically isolated from the rest of your system but looks like a legit piece for the attacker). Then, if you see someone broke in the honeypot it's quite likely be a hacker so you can auto-ban it or so.

And surely, you should not use outdated versions of software with known vulnerabilities, regardless the port number they're bind to listen.

Answer 8

No, it does not, or if I want to be more precise, it's the wrong protection against the threat.

Take a step backwards: what is threat we want to protect from? The threat we're trying to protect from is any person on the public internet who can bypass the normal authentication mechanism. That's what these "script kiddies" are trying to do: access the server using SSH even though they're not authorized. In particular, your superior wishes to prevent these attackers from even being able to start establishing an SSH connection.

What's the standard technology to prevent establishing network connections? A firewall. The standard answer to this problem is to just block port 22 entirely to outside traffic. The bigger problem here is that SSH is available to the public internet at all, and the firewall solves this completely, while the obscure port only hides it slightly and doesn't actually prevent the connections. If external access is required, the standard answer to allowing this authorized access is a VPN into the network. This would both block script kiddies and knowledge attackers who could figure out how to find the port you're actually using.

If you lose to 1% of attackers, you still lose. You need protections that work against 100% of attackers. If instead you are successfully blocking 100% of attackers (so far), then you must have more robust protections in place. These other protections make the obscure port irrelevant, and if that is (hopefully) the case, all using the other port does is confuse people who are less familiar with the actual security practices like yourself and, quite probably, waste the time of people trying to gain legitimate access when they try to connect (new system not configured and have to ask someone the correct port, admin forgot to tell person about the nonstandard port and person has to bother them again to diagnose the problem, etc.).

This is why we harp about "security through obscurity" and Kerckhoffs's principle. We should avoid distracting ourselves with practices that don't actually protect us. We should save our time and effort for protections that actually work and avoid the false sense of "security" that these obfuscation methods give us.

Answer 9

I want to add that in the end, security is a game about resources on both sides. Time is such a resource.

This measure is wasting an attackers time so it's not that bad. You can also learn about attackers resources when they still connect to your custom port. Maybe there's a higher interest to target you in particular.

However if it adds significant overhead to your administrative tasks you might want to invest your time somewhere else. If not then do it but don't rely on it.

Answer 10

Using non-standard ports for application services is not good practice in terms of security.

The SSH service is a frequently targeted service and port 22 is a frequently scanned port.

Obscuring the SSH port by changing it may help protect you against broad stroke Internet scans, but a targeted scan will identify an alternative port in use.