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? – Steffen Ullrich Jun 8 '20 at 16:13
  • Regular public facing site, with a need for good security. – Yogesch Jun 8 '20 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. – Yogesch Jun 9 '20 at 0:04

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.


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 '20 at 16:17
  • 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 '20 at 17:59

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.