90

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?

  • 12
    There is no such thing as security by obscurity. There is only obscurity. This principle was established decades ago. – user207421 Jul 18 '18 at 0:40
  • 58
    Less garbage in log files is a security feature in my view, as it means you can concentrate more on real issues. – curiousguy Jul 18 '18 at 1:28
  • 26
    Security through obscurity isn't inherently bad, relying solely on it is. Obscurity can provide a negligible benefit which can't replace real security, but it can be used in addition. The downside of obscurity is that it normally adds inconvenience to authorized users (that have to remember the deviation from the norm), and security is generally about establishing a balance between restricting unauthorized users without impeding authorized users too much. – Centimane Jul 18 '18 at 13:59
  • 3
    It totally depends on the attack vector you are thinking about. If you want to evade people casually scanning the net for port 22, then sure, but if you want to defend against someone attacking your host, not a bit. – PlasmaHH Jul 18 '18 at 21:52
  • 6
    I am running an ssh server on raspberry pi and it is accessible from the internet. When I ran the ssh on the port 22, the 10MB ramdisk log partition was getting full in manner of hours - all due to login attempts logging. After moving the ssh to a high port, I haven't had a single attempt of unauthorized access in 6 months. For me, that's a benefit. – j_kubik Jul 20 '18 at 19:26

10 Answers 10

141

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

  • Comments are not for extended discussion; this conversation has been moved to chat. – Rory Alsop Jul 20 '18 at 10:32
  • 4
    Nope. Anyone attempting to log in to that evil server would be met with a big warning saying that the host key changed (granted the clients could take a step back, edit their known_hosts files to remove such entry, connect again, accept the unknown key and land into a different server owned by an attacker, where even the files they had on their home are missing). Also note, the redirection could be done via iptables, so sshd is actually listening on 22 (unreachable from the outside), and the real port 20,000 is shadowed by it). – Ángel Jul 21 '18 at 21:56
  • @Ángel While that is correct, it would still provide capabilities to someone with an arbitrary read vulnerability or a side-channel attack that allows accessing the host keys (which is not an insignificant risk). Furthermore, it makes social engineering attacks easier and makes it possible to exploit the client. You are right about using iptables to redirect ports though, which would be a good idea if you want to use a high port safely. – forest Jul 24 '18 at 4:59
57

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.

  • 31
    "there could be a 0-day tomorrow and [attackers] will just hit as many machines as possible on the standard port" Good point that I haven't seen mentioned in other answers! – Luc Jul 17 '18 at 15:54
  • 8
    @jpmc26 you don't understand security and believe it is a binary property. It isn't. I'm also curious why I need to block a closed port off with two firewalls and why that gives me additional security. – Tom Jul 19 '18 at 4:10
  • 4
    @jpmc26 how would a 0-day in the firewall matter in this question? I was clearly speaking about a 0-day in sshd and I described the scenario clearly. We both agree that using a non-standard port gives at best a small increase in security, but there are scenarios in which it does make a difference. – Tom Jul 19 '18 at 10:28
  • 8
    I know how a firewall works. I was assuming the questioner is not a complete idiot and has SSH open because he needs it to be accessible. Your 2nd part shows a typical security misconception - that your defenses need to resist every attacker. That is wrong. If I need to explain why, please open a new question, that goes beyond the character limit of comments. – Tom Jul 19 '18 at 12:48
  • 13
    If you thwart 99% of attackers, it means you get hacked once every 10 years instead of 10 times every year. If you think that is not a difference, we have nothing to discuss. – Tom Jul 19 '18 at 20:56
30

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.

  • 10
    Is it not considered an improvement to security to be attacked less frequently? Because I agree, random trolls will usually be stopped by even rudimentary precautions. But doesn't every attack come with a tiny risk of breach? Even if the risk is as improbable as guessing an RSA key correctly? – William Rosenbloom Jul 17 '18 at 5:40
  • 4
    There's no real risk in brute force against RSA in my opinion. And I have yet to observe any automatic attacks trying this; they try password authentication. Against a real, targeted attack, which will do leg work to find valid usernames and so forth, changing port will not help. – vidarlo Jul 17 '18 at 5:41
  • 4
    @WilliamRosenbloom, most automated attacks come with zero risk of breach. Consider the guy who's been trying to brute-force root access my server for the past year: even if he had the password, the private key, and the assistance of the world's best hackers, there's zero risk of him getting in. My server is configured to reject all login request from root. – Mark Jul 17 '18 at 23:26
  • @WilliamRosenbloom Except it won't permantly reduce attacks. Some botnets may never find out, but there are smart ones out there that will find out either because of port scanning or traffic inspection. Once that happens, you're back where you started. Also, it does literally nothing against any serious targeted attack, any skilled attacker will quickly figure out what port it's on. – Austin Hemmelgarn Jul 18 '18 at 1:54
  • 2
    Agreed. If your ssh authentication is robust, then the most dangerous attack against you is some kind of advanced persistent threat (APT). APT cybercriminals won't be fooled by the security-through-obscurity of ssh listeners on other ports. If you are forced into incident response under pressure, you'll be happy you had standard stuff. – O. Jones Jul 20 '18 at 18:21
6

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.

  • 6
    We don't rely on the obscurity. We have many other security measures, including hardware authentication keys. The obscure ports are just an extra layer on top of conventional security. Knowing that, would you still recommend to use the default port 22? Is there any reason other than administrative overhead? – William Rosenbloom Jul 17 '18 at 2:08
  • 1
    @WilliamRosenbloom Given all that, you clearly already defend against basic attacks. Anyone who is capable of getting past your hardware auth keys would also be able to find that alternative port... so I think Sayan's post still stands: "use the default port and deploy [multiple layers of] security" as you have done. – Luc Jul 17 '18 at 15:52
  • If you are using hardware keys, using non standard ports is just a security theater. An attacker who has any chance to break a hardware key would identify your real ssh port in no time anyway. Actually, a much much lower level attacker could do this easily. – goteguru Jul 17 '18 at 18:14
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.

4

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

  • 2
    port knocking is a cutesy security idea, but it has absolutely terrible usability. – Tom Jul 17 '18 at 12:22
  • @Tom unless you write a script to handle that for you... Usability for a remote admin is not really a huge concern. – schroeder Jul 17 '18 at 12:25
  • 1
    @schroeder you assume that you always do your admin stuff from the same machine where you have your nifty script handy. In that case, you don't need port knocking, key-based authentication will also make brute-force attacks pointless. – Tom Jul 17 '18 at 13:17
  • @tom yes, I am assuming that. If your admins are logging in from unknown or uncontrolled machines, then you have another problem. Your comment about key-based is also confusing: key-based authentication is terrible for usability. I think you might need to expand what you mean in your original comment and what assumptions you are making as a basis. – schroeder Jul 17 '18 at 13:19
  • @schroeder - you are right that key-based authentication is not much better in usability, but at least it is a standard procedure. My experience shows that your assumption will be correct 99% of the time, and wrong the one time when you really need to log on, but you're somewhere without your notebook. I've locked myself out of machines often enough to know that you always need to have at least one way in that requires no specific software or setup. – Tom Jul 17 '18 at 13:25
4

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.

  • 6
    Don't run a honeypot on a production server – AndrolGenhald Jul 17 '18 at 16:11
  • 3
    @AndrolGenhald I like the idea though. An attacker will try 22 before any alternative ports, so if you see so much as a TCP SYN there, you can ban the IP address from accessing any port (so the host will appear dead to the attacker). Or you could proxy traffic on port 22 to a honeypot server elsewhere. I agree that a high-interaction honeypot on prod is definitely not a good idea. – Luc Jul 17 '18 at 16:31
  • 2
    @AndrolGenhald, don't expose naked production server to the outer world. Then having a honeypot accessible on the same IP as the production server could be just a routing config. – Yury Schkatula Jul 17 '18 at 16:32
  • 1
    @Luc Yeah, having something listening and logging on port 22 could be useful, or routing it elsewhere, but the answer doesn't explain any of that. YurySchkatula Maybe you should add that to your answer? – AndrolGenhald Jul 17 '18 at 16:42
  • 2
    @Luc Sounds like a good way to ban your system admins when they get a new computer and forget to change the port the first time they try to connect. – jpmc26 Jul 19 '18 at 12:14
3

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.

1

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.

-3

Using non-standard ports for highly vulnerable applications is VERY GOOD practice. SSH has a lot of vulnerabilities and 22 is a common default port to brute force.

That being said, it probably depends. It's very common, especially in an enterprise environment, to see brute force attacks on DMZ servers against port 22. Many companies, in finance for instance, use a different default port for SSH/SFTP traffic for valid data transfer between organizations.

The idea in that case is more about filtering out some of the noise (Port 22 Brute Forcing) so the other traffic on an alternate port is easier to monitor. Anyone good enough can find any open port on an internet facing server.

This is considered a form of risk mitigation or risk reduction.

Edit: I should add: When I say good practice, I'm referring to good practice on your internet facing devices. Anything behind your firewalls is generally safe.

  • 2
    I wouldn't say openssh has a lot of vulnerabilities. A lot of the reported issues may allow a authenticated user to gain privileges, but that's different from a remote attacker gaining access... – vidarlo Jul 17 '18 at 4:35
  • 8
    Hiding your front door key under the mat is not very good practice. Yes, it is better than leaving the key in the lock, but not much better. The better idea is to mitigate the vulnerabilities, not to hide them. – schroeder Jul 17 '18 at 12:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.