Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
26  
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: security.stackexchange.com/questions/2430/… –  Tony Meyer Sep 29 '11 at 3:16
    
well it maybe an obstacle for "scripting kids" –  lukas Sep 29 '11 at 10:14

11 Answers 11

up vote 57 down vote accepted

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.

share|improve this answer
3  
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. –  XHR Sep 28 '11 at 20:18
9  
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 1: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 7:25

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.

share|improve this answer
6  
wonderful distinction –  ZJR Sep 29 '11 at 2:00
2  
+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
1  
+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

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.

share|improve this answer
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
4  
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 0:17

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.

share|improve this answer
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 6:55

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?

share|improve this answer
13  
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
3  
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 1: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 2:44
    
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
1  
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 1 '11 at 4:36

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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