There are documented (albeit debated) advantages to using a non standard port for SSH.

I also read in various places about using a non-standard port for https (e.g. 8443). Is there a possible advantage to doing this? Of course, the firewall will need to account for it, and the webserver/reverse-proxy too. But having gone through the (relatively simple) hoops, is there a possible benefit for a public-facing webservice?

  • 2
    Is this for a website which should be accessible by the public or some private site which should not be consumed by the public? Jun 8, 2020 at 16:13
  • Regular public facing site, with a need for good security.
    – ahron
    Jun 8, 2020 at 16:20
  • 1
  • @schroeder I had seen 2 of those 3 questions you had marked as potential duplicates. Two of them are specifically about ssh. The 3rd is a bit general and indeed a potential duplicate but I hadn't found it because of the "unusual" (submitting an edit) phrasing. With the benefit of hindsight, the accepted answer here covers some points (public vs private sites, and corporate firewalls) not discussed in there either.
    – ahron
    Jun 9, 2020 at 0:04

4 Answers 4


Having a different port is security by obscurity. While this is bad to be used as the main protection it can be useful as an additional protection, like to avoid the usual vulnerability scanners in their default settings.

But how much additional protection is actually achieved is questionable: if the site is private one can keep the port kind of secret. But if the site should be publicly available like in your case then the alternative port cannot be kept secret. This means that there is no real obscurity in the case and thus also no security gained by obscurity.

While one might be able to avoid some dumb scanners this way the security benefit is small. On the other side one will have trouble with corporate firewalls which might block access to this alternative port, thus preventing customers from visiting the site.


Not really. This is security-through obscurity (https://en.wikipedia.org/wiki/Security_through_obscurity). It may prevent some automated scans from detecting it, but anything which connects to the port will grab the banner information & will be able to determine that a web server is running.

  • 1
    If you look at the instances of large scale worm propagation over the past 20 years, most of them used static ports. For example SQL Slammer would have propagated less successfully if many fewer servers had been running on port 1434. Furthermore, portscans like Nmap are usually detected quickly by IDS, whereas connecting to standard ports to attempt to discover which IPs host what services usually do not; changing to nonstandard ports therefore forces attacker to spend more effort to probe each IP and increase detection probability at the network level.
    – cowbert
    May 11, 2023 at 20:23

Don't let the "security-by-obscurity" stigma fool you. There ARE major significant benefits to changing as many default ports as possible.

For SSH it's a no-brainer. If you run your SSH on port 22 you will get hundreds maybe even thousands connect attempts a day. Changing the port immediately takes you out of the pool of attack victims. Furthermore, in the event there is ever a major vulnerability in the protocol, chances are good you will be unaffected long enough to implement a patch without being compromised.

With HTTPS it's a little different because that service is meant to be consumed by the public, but the benefits still hold true.

There are many many individuals who scan entire ranges of targets looking for low hanging fruit. If you change the port, you take yourself out of the pool of potential targets and limit exposure only to those who specifically know of your service.

Limiting your exposure is NOT security by obscurity and is definitely a good practice.

  • Take care not to take an idea too far. Yes, changing the port to a non-standard port removes you from automated scans looking for standard ports. But that's it. Your statements make it seem like a panacea for the port scanning problem. Changing ports helps to limit exposure to unfocused threats, but does nothing for someone focused on you, as the duplicated linked explain.
    – schroeder
    Jun 9, 2020 at 16:17
  • 2
    Changing standard ports may also protect against worms that exploit new or unknown vulnerabilities, since they'll most likely just be attacking standard ports for software, which might give you enough time to patch or update it. I don't know of any worm that tries random ports, they've all been targeting the port specific to the exploited software they're made for.
    – user
    Jun 9, 2020 at 17:59

When you use non-standard ports, I see potential drawbacks.

  • In larger networks, security audits are more complex.

  • Some protocols (e.g. Voice over IP) negotiates the port while setup. The firewall temporarily opens the port and when connection is finished then the port is closed again. Of course, the port is also closed after a certain time-out in case of failures. When you choose a random port, then you may hit such a special port. Some time ago we faced exactly this problem in our premises. Some connections to our Oracle database (using non-standard port) dropped when connection was established over VPN.

  • You create issues when a packet inspection firewall comes into place. Packet inspections are typically based on the port.

  • A low educated admin may start a second instance of the application using default settings, i.e. default port and security (e.g. TLS/SSL) disabled. Or a software update reverts your configuration. In this case, your computer runs the service two times, one runs on non-standard port and is secured, the other runs on standard port and is not secured. When you use standard ports all the time, then you can start the service only once. See this example: https://stackoverflow.com/questions/75829138/i-can-still-access-mongodb-server-with-no-authentication-credentials/75831018

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .