100

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?

William Rosenbloom
  • 1,516
  • 2
  • 6
  • 12
  • 13
    There is no such thing as security by obscurity. There is only obscurity. This principle was established decades ago. – user207421 Jul 18 '18 at 00:40
  • 61
    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 01:28
  • 2
    If you'd like a decent security by obscurity ( :) ), you should use port knocking instead of simple non-standard ports. Port knocking can not be defeated by scanning. The only way to counter it is a decent traffic analysis, which is way, way harder. – goteguru Jul 18 '18 at 10:42
  • 29
    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
  • Why is port 22 available to the public internet? – jpmc26 Jul 19 '18 at 12:17
  • 1
    Possible duplicate of [The valid role of obscurity](https://security.stackexchange.com/questions/2430/the-valid-role-of-obscurity) – Rory McCune Jul 19 '18 at 19:00
  • 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
  • 1
    If you've installed a fresh SSH and just monitored logs within first hour, you'd count hundreds if not thousands of attempts! On a side note, this was what encouraged me to plot a honeypot just for that purpose of fun! – amrx Jul 21 '18 at 00:03
  • I don't know if you sign your question with your real name, but if you do, or if your identity can be established from your posts, then maybe you disclose too much. – akhmeteli Jul 22 '18 at 19:17
  • In this case, inconvenience to authorized users is likely to be fairly low, as they can generally configure their SSH software (even command-line SSH generally has something like `~/.ssh/config` to assign a short name to a complicated connection) to connect to some strange port the first time and then not have to remember the port in the future. – Chai T. Rex Jul 23 '18 at 00:28
  • The linked-to article is about Kerckhoff's Principle, which is not generally applicable. Kerckhoff's principle applies directly only to cryptography systems, not directly to systems in general. – hft Sep 29 '21 at 20:35

10 Answers10

144

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

Robbie JW
  • 105
  • 3
Steve Sether
  • 21,530
  • 8
  • 50
  • 76
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/80438/discussion-on-answer-by-steve-sether-does-it-improve-security-to-use-obscure-por). – 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 04:59
59

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.

Tom
  • 10,201
  • 19
  • 51
  • 33
    *"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
  • Your first sentence is wrong. It can only "improve" security if the correct protection (e.g., *a firewall blocking port 22 from internet traffic*, or multiple firewalls from different vendors if you want defense in depth, e.g. a firewall on the device that allows public internet access into the network and then a machine level firewall) is not in place. If it is not in place, then the defender will still lose to slightly more sophisticated attacks that bother to check other ports. Losing to 1% of attackers is still losing. – jpmc26 Jul 18 '18 at 18:47
  • 9
    @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 04:10
  • @Tom You may want to reread the comment because I answered that. Your answer suggests that a nonstandard port helps protect against zero day vulnerabilities. If you're worried about those in your firewall, then you can use multiple firewalls to achieve better defense in depth than a nonstandard port does in case one of them fails. With this set up, the nonstandard port buys you nothing, and this setup protects against *more* scenarios than a nonstandard port (like someone who bothers to scan all ports). Obscurity is subpar at best. Are you sure *I'm* the one who doesn't understand security? – jpmc26 Jul 19 '18 at 08:23
  • 5
    @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
  • @Tom Zero day on SSH doesn't matter if the attacker can't even connect to SSH. With a firewall, a vulnerability (such as zero day) on the firewall itself is required to even attack SSH. The only scenarios where these obscurity methods matter are ones where the proper security measures are not in place, and in these scenarios, a *slight* increase in the attacker's effort defeats them. Taking the chance that not a single attacker will spend it is stupid. Use security measures that make obscurity irrelevant if you actually want to defend against threats, or you're not secure at all. – jpmc26 Jul 19 '18 at 12:07
  • 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
  • @Tom They need to resist every attacker in the threat model(s) you're considering. Obviously, the threat model does not consist of only attackers who do not check other ports; this is demonstrated by the OP since they say only *99%* of attackers would be thwarted by this mechanism. Attackers are very clever. Assuming they won't discover information that's "hidden" in plain site is just stupid, as history shows us. – jpmc26 Jul 19 '18 at 20:43
  • 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
  • 1
    For sure script-kiddies run port scanners looking for the favourite port of their favourite in. Having a different port means 99.9% of script-kiddies and self-distributing 0-days find nothing and the 0.1% target attack is not staved off even a little. – Willtech Jul 23 '18 at 09:27
  • "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." This falsely assumes that we're comparing obscure ports to no protection at all. That isn't at all what I've suggested. What I've said is that the obscure port does nothing if you have the correct protections and there's no reason to avoid using them. If you get hacked once every 10 years, you're failing. – jpmc26 Jul 23 '18 at 21:07
  • @jpmc26 - we talk past each other. I've already addressed everything you said and keep saying. The point you make now I addressed in my original posting. I really have nothing to add. – Tom Jul 23 '18 at 21:18
31

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.

vidarlo
  • 14,890
  • 2
  • 43
  • 56
  • 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 05:40
  • 5
    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 05:41
  • 5
    @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 01: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
  • fail2ban can help but requires Python, a resource hog on some devices. Plus, although a balance must be struck, I don't feel it's good security practice to believe that there will always be zero risk from brute-force attacks and to simultaneously be inured to evidence of harmless attacks in your security logs. It creates an opportunity for a more dangerous attacker to operate under cover of noise & complacency. A high port (for now) maximizes the SNR; attacks on it indicate a more determined attacker and draw appropriate attention. – Mike Brown Jul 23 '18 at 04:10
  • Then get a better log viewer, that can filter out invalid username authentication attempts, root attempts and so forth, and your Signal-Noise-Ratio will be back to real attackers attempting valid user accounts. – vidarlo Jul 23 '18 at 04:48
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.

Sayan
  • 2,033
  • 1
  • 11
  • 21
  • 6
    We don't rely on the obscurity. We have many other security measures, including [hardware authentication keys](https://www.yubico.com/products/yubikey-hardware/). 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 02: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.

SSLTrust
  • 61
  • 3
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/80477/discussion-between-forest-and-patrick-mevzek). – forest Jul 21 '18 at 02:48
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

user6858980
  • 99
  • 2
  • 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
  • @Tom explain why you think its cute security? The port is fire walled off until you unlock it with this method, you then still have all your existing security measures in place. If your not advertising your port you will avoid the majority of net scans.. If the service behind the hidden port becomes vulnerable, it will also give you plenty of time to path before automated hacks start flooding in. Think how this could have stopped shellshock spreading so rapidly. Yes usability decreases, I now have to send 3 packets before I log in, such difficulty. – user6858980 Jul 17 '18 at 13:50
  • @user6858980 I called it "cutesy" because it's one of the things someone tells you at a conference and you go "now that's a neat idea", until you think through all the implications. And yes, sending 3 packets can be a hell of a task if you are, say, in an Internet cafe. I've restarted crashed servers using a Palm Pilot and a GSM (not 3G, not 2G, GSM) phone while riding the train. I've done troubleshooting on an iPad. Good luck getting your port knock done when you are in an emergency situation without your usual equipment. – Tom Jul 17 '18 at 13:58
  • so what are the implications that don't make it practical? Your saying there is a problem without giving any information. The notion you cant send three packets via GSM on a train is nonsical, if you have a stable enough net connection to maintain a ssh connection you have enough to do for x in $PORT1 $PORT2 $PORT3; do nmap -Pn --host_timeout 201 --max-retries 0 -p $SERVER_IP; done; ssh user@$SERVER_IP. Or three telnets and a ssh. Tell me how you would exploit a vulnerable service or brute force something that is firewalled and not advertised? – user6858980 Jul 17 '18 at 14:12
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.

Yury Schkatula
  • 181
  • 1
  • 2
  • 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
  • 3
    @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
  • @jpmc26 Good sysadmins use `.ssh/config` files ;-). But more seriously, good security rarely comes without effects on usability. Where to draw the line between usability and security, depends on the situation. Perhaps the first time, a banner might warn them before banning? Again, it just depends on the situation... – Luc Jul 19 '18 at 20:15
  • @Luc There are better alternatives, though, like using a white list of IPs in the first place (via firewall), and just blocking external traffic on port 22. – jpmc26 Jul 19 '18 at 20:39
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.

jpmc26
  • 823
  • 9
  • 17
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.

Noir
  • 2,553
  • 13
  • 23
-2

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.

Justin
  • 722
  • 5
  • 9