75

I have seen advice saying you should use different port numbers for private applications (e.g. intranet, private database, anything that no outsider will use).

I am not entirely convinced that can improve security because

  1. Port scanners exist
  2. If an application is vulnerable, it remains so regardless of its port number.

Did I miss something or have I answered my own question?

Lance Roberts
  • 401
  • 3
  • 12
  • 29
Sam
  • 965
  • 1
  • 7
  • 8
  • 31
    One thing I've done is use certain default ports (e.g., SSH port 22) as honey pots. Anyone attempting to connect to those ports is blocked entirely for `x` amount of time. It has proven to be effective against port scanning. Of course, this is just one tool in the security toolbox. – Belmin Fernandez Sep 28 '11 at 21:39
  • The general question about security through obscurity is asked here: http://security.stackexchange.com/questions/2430/the-valid-role-of-obscurity – Tony Meyer Sep 29 '11 at 03:16
  • well it maybe an obstacle for "scripting kids" – Lukasz Madon Sep 29 '11 at 10:14
  • 1
    @BelminFernandez, *"one tool in the security toolbox"*? No, this is for reducing server load (performance) and has **nothing to do with security** besides the mere illusion of it. Security-wise, it's totally unnecessary if the server is already strong, and if the server is vulnerable, it doesn't make it any more secure. – Pacerier Feb 08 '16 at 04:28
  • @Pacerier, Agreed that the effort and focus should be on implementing more solid security practices. However, there's no reason why you can't do both. – Belmin Fernandez Feb 08 '16 at 14:59
  • @BelminFernandez, The reason is because there are scenarios where doing extra work does not give extra security. See [http://serverfault.com/questions/316516/....](http://goo.gl/DFA2Tg). – Pacerier Feb 08 '16 at 17:46

12 Answers12

76

It doesn't provide any serious defense against a targetted attack. If your server is being targetted then, as you say, they will port scan you and find out where your doors are.

However, moving SSH off the default port of 22 will deter some of the non-targetted and amateur script kiddie type attacks. These are relatively unsophisticated users who are using scripts to port scan large blocks of IP addresses at a time specifically to see if port 22 is open and when they find one, they will launch some sort of attack on it (brute force, dictionary attack, etc). If your machine is in that block of IPs being scanned and it is not running SSH on port 22 then it will not respond and therefore will not show up in the list of machines for this script kiddie to attack. Ergo, there is some low-level security provided but only for this type of opportunistic attack.

By way of example, if you have the time - log dive on your server (assuming SSH is on port 22) and pull out all the unique failed SSH attempts that you can. Then move SSH off that port, wait some time, and go log diving again. You will undoubtedly find less attacks.

I used to run Fail2Ban on a public webserver and it was really, really obvious when I moved SSH off port 22. It cut the opportunistic attacks by orders of magnitude.

jdw
  • 3,855
  • 2
  • 17
  • 21
  • 4
    Agreed. I saw a very similar drop when experimenting with moving SSH to a non-standard port. Fortunately with password auth disabled, it's really a non-issue. – EEAA Sep 28 '11 at 20:10
  • 3
    Best answer here so far. It all comes down to who is attacking. I once helped admin a system that got hit with a zero-day attack from a scanning kiddie. Presumably in MS-RDP as we didn't have IIS exposed by the firewall. Our host wouldn't allow us to change the RDP port (managed hosting) so we basically had to sit there while they worked on a new pattern for their IDS/IPS filtering. Though it may not help as much for more established servers like SSH that seem to have less security issues than some MS products. – Matt Molnar Sep 28 '11 at 20:18
  • 10
    Definitely agree. Security is all about layers, and the more you have, the more secure you are. This may be a weak layer, but still a layer nonetheless. As long as it's not relied upon solely, it can only add to security. – Paul Kroon Sep 29 '11 at 01:11
  • 1
    Another point to moving SSH off port 22 is that large amount of SSH tries plus services as Fail2Ban may at times take up valueable CPU time. It may be negligible on top of the line hardware but some older servers may experience CPU spikes. Its CPU time, memory and bandwith you can use for other stuff. – artifex Sep 29 '11 at 17:54
  • I've done the same with RDP on Server 2003 - it substantially cut down on the amount of failed authentication entries in Event Viewer. – Moshe Jan 17 '13 at 07:25
  • @PaulKroon, Adding more layers in-and-of-itself does not automatically grant you greater security. Every layer you add has a security cost to it and if *that* security cost exceeds the security benefit, you're making yourself **less secure**. Be aware that security is managed by personnel with *human tendencies*, and thus any time a layer provides a greater-than-intended illusion of security, you are creating an opportunity for failure. See http://serverfault.com/questions/316516/does-changing-default-port-number-actually-increase-security#comment947873_316545 for more info. – Pacerier Feb 08 '16 at 05:30
46

It's very helpful to keep the logs clean.

If you see failed attempts with sshd running on port 33201 you can safely assume that the person is targeting you and you have the option of taking the appropriate action if you so desire.. Such as contacting the authorities, investigating who this person may be (by cross referencing with the IPs of your registered users or whatever), etc.

If you use the default port then it will be impossible to know if someone is attacking you or it's just random idiots doing random scans.

Andreas Bonini
  • 1,332
  • 1
  • 9
  • 16
  • 8
    wonderful distinction – ZJR Sep 29 '11 at 02:00
  • 3
    +1 This is the best argument for changing port numbers that I've ever heard and so far the only thing that would entice me to do so – squillman Sep 29 '11 at 23:29
  • 2
    +1 This is a great point. Targeted threats are a lot more dangerous than random probes (the script kiddies just move on to easier targets if you have any decent security). The targeted attacker may know a lot more about specific vulnerabilities or even password patterns. It's good to be able to recognize these attacks outside of the swarm of spam on port 22. – Steven T. Snyder Sep 30 '11 at 17:12
  • 1
    This is false. I've seen at least one server get compromised through a scan on a non-standard SSH port. There is no inherent reason why an attacker wouldn't be able to scan other ports as well. – Sven Slootweg Jul 02 '15 at 09:54
  • @SvenSlootweg, True, especially with computers getting faster and cheaper, a scan taking 65535 times longer is no longer *much longer* any more. – Pacerier Feb 08 '16 at 04:25
29

No, it doesn't. Not really. The term for this is Security by Obscurity and it's not a reliable practice. You are correct in both of your points.

Security by Obscurity at best will deter the casual attempts that just go around looking for default ports knowing that at some point they will find someone who left the front door open. However, if there is ever any serious threat that you face changing the deault port will at most slow the initial attack down, but only ever so marginally because of what you've already pointed out.

Do yourself a favor and leave your ports configured properly, but take the proper precautions of locking them down with a proper firewall, authorizations, ACL's, etc.

squillman
  • 37,883
  • 12
  • 92
  • 146
  • 1
    Eventually it all comes down to security by obscurity. A password is just an obscure string of characters. Same thing for a private key. Same thing for your two-factor authentication device's secret. Port scans can be trivially detected and blocked, or you can use port knocking to defeat it. – ceejayoz Sep 28 '11 at 19:23
  • 17
    The projection of (strong) passwords and encryption into the idea of security by obscurity is a bit of a stretch, in my own humble opinion... – squillman Sep 28 '11 at 19:26
  • 1
    There are 65535 ports. Choosing a random port will provide you with a 16 bit password. – Mark Wagner Sep 28 '11 at 19:37
  • Why? A strong password is just a more obscure string of characters than a weak password. It's not as if the non-standard port is the entire security apparatus. – ceejayoz Sep 28 '11 at 19:38
  • 5
    Using only 8 characters with the full range of alphabetic and numeric characters (and not even allowing special characters) the number of possible combinations is 62^8 (218,340,105,584,896). 65535 is not even in the same universe as that, even when employing port scan detectors. Note, I am discounting weak passwords. – squillman Sep 28 '11 at 19:52
  • 3
    **Again**, "it's not as if the non-standard port is the entire security apparatus". Every little bit helps. It's a 10 second tweak that, if nothing else, is going to stop your server from showing up to someone looking for SSH to start knocking at the doors. – ceejayoz Sep 28 '11 at 23:12
  • 8
    Meh. Keeping track of non-standard ports isn't worth it in my book. I'll agree to disagree with anyone... Adding further countermeasures beyond changing the port is certainly part of the equation and I'd much rather leave things up to those pieces of the puzzle. – squillman Sep 28 '11 at 23:42
  • 6
    From what I have seen the non-standard ports have become quite standard. 2222 for ssh, 1080, 8080, 81, 82, 8088 for HTTP. Otherwise, it becomes too obscure and you wonder what service is on port 7201 and why you can't connect to ssh on 7102. – BillThor Sep 29 '11 at 00:17
  • 2
    @ceejayoz, every little bit does not help if it means a lot more administrative effort (meaning keeping a database of what services are on what ports). IS it really worth keeping track of those nonstandard ports to add a few milliseconds to the attackers distributed portscanner? – Jim B Sep 29 '11 at 17:29
  • Virtually every other port should be firewalled off from outside access. One custom port for the whole organization's SSH and one tweak to .ssh/config and you don't have to worry about it. – ceejayoz Sep 29 '11 at 17:37
  • @ceejayoz, JimB is right that nothing is free. Every extra layer comes with an additional cost. Continuation of JimB's point at http://serverfault.com/questions/316516/does-changing-default-port-number-actually-increase-security/316648#comment947886_316659 – Pacerier Feb 08 '16 at 17:41
  • 1
    @Pacerier Nothing's free, but some things are damned close. I'm really not sure why you're reviving a five year old discussion to say what's already been discussed. – ceejayoz Feb 08 '16 at 17:55
  • @ceejayoz, This is a wiki, such "year old discussion" is simply a product of how the site is organized. Click through the link I had provided above to see what points are new; tldr: it's not about the cost being "damned close" to free. It's about the cost possibly being unwarrantedly high due to unaccounted for hidden factors. – Pacerier Feb 09 '16 at 15:01
  • @Pacerier Linking to your own comments as a "source" really isn't carrying much weight with me, nor are the points new. You say custom ports is indicative of a lax, "I don't need to do more" attitude. I say it's equally possible for it to indicate a "I've at least *thought* about security" attitude that's lacking in a lot of VPS owners. – ceejayoz Feb 09 '16 at 15:04
  • @ceejayoz, Linking to own comments is not a methodology for introducing "source", it's simply a way of [reducing repetition](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself#DRY_vs_WET_solutions). The points are new because they have not been mentioned above. The keyword is ***illusion***. I'm referring exactly to *that* attitude, the *"I've at least thought about security"* and *"I've got what a lot of other VPS owners lack"* attitude. – Pacerier Feb 09 '16 at 21:14
14

It's a slight level of obscurity, but not a significant speed-bump on the road to hackage. It's a harder config to support long-term since everything that talks to that particular service has to be told about the different port.

Once upon a time it was a good idea in order to avoid network worms, since those tended to scan just one port. However, the time of the rapidly multiplying worm is now past.

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
  • 2
    +1 for harder config & support issue. Makes you waste time that could be spent on securing the door (instead of having to search for where on your house you've put it). – Macke Sep 29 '11 at 06:55
13

As others have pointed out, changing the port number does not offer you much security.

I'd like to add that changing the port number may actually be detrimental to your security.

Imagine the following simplified scenario. A cracker scans 100 hosts. Ninety-nine of these hosts have services available on these standard ports:

Port    Service
22      SSH
80      HTTP
443     HTTPS

But then there is one host which stands out from the crowd, because they the system owner tried to obfuscate their services.

Port    Service
2222    SSH
10080   HTTP
10443   HTTPS

Now, this might be interesting to a cracker, because the scan suggests two things:

  1. The owner of the host is trying to hide the port numbers on their system. Perhaps the owner thinks there is something valuable on the system. This may not be a run-of-the-mill system.
  2. They chose the wrong method to secure their system. The administrator made a mistake by believing in port obfuscation, which indicates that they may be an inexperienced administrator. Perhaps they used port obfuscation in lieu of a proper firewall, or a proper IDS. They might have made other security mistakes as well, and might vulnerable to additional security attacks. Let's probe a little further now, shall we?

If you were a cracker, would you choose to take a look at one of the 99 hosts running standard services on standard ports, or this one host which is using port obfuscation?

Stefan Lasiewski
  • 23,667
  • 41
  • 132
  • 186
  • 17
    I'd look at the 99 hosts unless experience taught me otherwise. Someone who's moving ports around probably is more likely to patch and secure, if you ask me. – ceejayoz Sep 28 '11 at 23:14
  • 4
    I'd look at the 1 host that stood out, on the off chance that some PFY thought "If I change the port numbers, I AM INVINCIBLE!" but has the root password set to "password". – Andrew Sep 29 '11 at 01:53
  • 3
    @Ceejayoz, completely agree. I'm running SSH on 2222, no security value but cuts way down on script kiddies. I'd figure they're more likely to ignore me too, bothered to change the port, probably took other measures too. Obviously it's not all default configuration... – Chris S Sep 29 '11 at 02:44
  • 1
    I understand that not everyone agrees with my opinion. But in my experience, there were many system owners who would use port-obfuscation, but they would make mistakes like not updating OpenSSH after some critical security vulnerabilities were exposed, or would use unencrypted SSH keys from a shared university system, etc. Some of these systems were juicy targets. – Stefan Lasiewski Sep 30 '11 at 16:53
  • 3
    By extension: moving to a non-standard port, you are more likely to discourage the script kiddies, but also more likely to intrigue an experienced hacker. Which begs the question: which are you more afraid of being targeted by? – tardate Oct 01 '11 at 04:36
  • @ceejayoz, Quite the contrary... someone who's moving ports around is creating more work for himself and therefore with all things being equal, his increased workload results in greater delay in "patch and secure" when compared to the one using the default ports. That's not even the main issue, the **real problem** lies with the human tendency to be less vigilant when they get the illusion of safety. For example: – Pacerier Feb 08 '16 at 05:31
  • Whenever you hear stuff like "*oh it's 3am in the morning, we can patch this later since we are safer due to nonstandard ports*" or "*let's go for lunch first and patch this later since we are safer due to nonstandard ports*", you know your nonstandard ports are doing you a disservice. Reminds me of how removing vehicle barriers atop cliff trails actually **reduced the number of buses falling off the cliff** because drivers are *99x* more vigilant when the illusion of safety is not there. – Pacerier Feb 08 '16 at 05:36
  • Note: "human security" is all about security against humans. – Pacerier Nov 12 '17 at 00:12
9

I'm going to go against the general trend, at least partially.

On it's own, changing to a different port might gain you a couple of seconds while it's searched for, hence gaining you nothing in real terms. However, if you combine the use of non-standard ports together with anti-portscan measures it can give a really worthwhile increase in security.

Here's the situation as it applies to my systems: Non-public services are run on non-standard ports. Any connection attempt to more than two ports from a single source address, whther successful or not, within a specified amount of time results in all traffic from that source being dropped.

To beat this system would require either luck (hitting the right port before getting blocked) or a distributed scan, which triggers other measures, or a very long time, which would also be noticed and acted on.

John Gardeniers
  • 27,458
  • 12
  • 55
  • 109
  • Combine this with the point by Andreas Bonini about targetted attacks and it's a strong argument for using alternative ports. – JivanAmara Nov 06 '14 at 19:42
5

In my opinion moving the port that an application runs on does not increase security at all - simply for the reason that the same application is running (with the same strengths and weaknesses) just on a different port. If your application has a weakness moving the port that it listens on to a different port doesn't address the weakness. Worse it actively encourages you to NOT address the weakness because now it is not being hammered on constantly by automated scanning. It hides the real problem which is the problem that should actually be solved.

Some examples:

  • "It cleans up the logs" - Then you have a problem with how you are handling your logs.
  • "It reduces connection overhead" - The overhead is either insignificant (as most scanning is) or you need some kind of filtering/Denial-of-Service mitigation done upstream
  • "It reduces the application's exposure" - If your application can't stand up to automated scanning and exploitation then your application has serious security deficiencies that need to be addressed (i.e., keep it patched!).

The real issue is administrative: People expect SSH to be at 22, MSSQL to be at 1433 and so on. Moving these around is one more layer of complexity and required documentation. It's very annoying to sit down at a network and have to use nmap just to figure out where things have been moved. The additions to security are ephemeral at best and the downsides are not insignificant. Don't do it. Fix the real problem.

2

You are correct that it will not bring much security (as the TCP server port range has only 16 bits of entropy), but you may do it for two other reasons:

  • as others have already said: intruders trying many logins can clutter your log files (even if dictionary attacks from a single IP can be blocked with fail2ban);
  • SSH needs public key cryptography to exchange secret keys to create a secure tunnel (this is a costly operation that under normal conditions does not need to be done very often); repeated SSH connexions could waste CPU power.

Remark: I am not saying that you should change the server port. I am just describing reasonable reasons (IMO) to change the port number.

If you do that, I think that you need to make it clear to every other admin or user that this should not be considered a security feature, and that the port number used is not even a secret, and that describing this as a security feature that brings real security is not considered acceptable behaviour.

curiousguy
  • 246
  • 1
  • 5
  • Log files can easily be uncluttered with proper filters. If you are talking about server performance due to reduced logs, then we are no longer talking about security. Performance is a completely different topic altogether. – Pacerier Feb 08 '16 at 05:43
  • Not when the computer becomes unusable due to excess disk use. – curiousguy Feb 08 '16 at 09:07
  • Yes that's a performance issue. Performance is definitely important too, but this particular thread is specifically discussing about security only. (For purpose of this thread, just imagine you are Google-size, and Google does *actually* want those data for analysis and/or selling purposes.) – Pacerier Feb 08 '16 at 15:47
1

I can see one hypothetical situation where there would be a potential security benefit in running your sshd on alternate port. That would be in the scenario where a trivially exploited remote vulnerability is discovered in the sshd software you are running. In such a scenario running your sshd on an alternative port might give you just the extra time you need not to be a random drive-by target.

Myself I do run the sshd on an alternative port on my private machines, but that is mainly as a convenience to keep down the clutter in /var/log/auth.log. On a multi-user system I really don't consider the small hypothetical security benefit presented above to be enough reason for the extra hassle caused by the sshd not being found on the standard part.

EEAA
  • 109,363
  • 18
  • 175
  • 245
andol
  • 6,938
  • 29
  • 43
  • The scenario would only be valid if all the admin(s) absolutely not take any leeway with this "extra time" ever to [*go to lunch*](http://goo.gl/DFA2Tg) and etc. – Pacerier Feb 08 '16 at 05:49
1

It slightly increases security. In that the attacker having found the open port now has to work out whats running on the port. Not having access to your config files (yet :-) )he has no idea whether port 12345 is running http, sshd, or one of a thousand other common services so they need to do extra work to figure out whats running before they can seriously attack it.

Also as other poster pointed out whereas attempts to log into port 22, could be clueless script kiddies, zombie trojans or even genuine users who mistyped an IP address. An attempt to log into port 12345 is almost certain to be either a genuine user or a serious attacker.

Another strategy is to have a few "honey trap" ports. As no genuine user would know about these port numbers then any connection attempt must be considered malicious and you can block/report the offending IP address automatically.

There is a special case where using a different port number will definitely make your system more secure. If your network is running a public service such as a Web Server but also running an internal use only web server, you can absolutely block any external access by running on a different port number and blocking any external access from this port.

user23523
  • 121
  • 2
  • The ~0.1% security increase must be weighed against the [relevant security decrease](http://serverfault.com/questions/316516/does-changing-default-port-number-actually-increase-security#comment947873_316545), likely resulting in a total net loss in security depending on use case and context. – Pacerier Feb 08 '16 at 05:54
0

From experience, yes.

I'd say it's a good thing to do, it's a shield against automatic (usually Russian and Chinese) brute force attacks, which are extremely common and attack randomly. Once you change the ports, you don't have to worry about those bots again.

If you're concerned about a real threat, and you are their target, then it's definitely not enough.

Sasino
  • 1
  • from real worl no and never as i already been seeing port scanning on massive amounts of hosts – djdomi Nov 30 '21 at 18:42
0

Not by itself. However, not using the default port for a particular application (say, SQL Server) will basically force your attacker to scan your ports; this behavior can then be detected by your firewall or other monitoring metrics, and the attacker's IP blocked. Also, the average "script kiddie" will more likely be deterred when the simple tool or command script they're using doesn't find a SQL server instance on your machine (because the tool only checks the default port).

KeithS
  • 135
  • 1
  • 2
  • 12