Suppose you've got a server that runs insecure software and you have to make it publicly accessible, what ports are "safest" for providing that service on the internet. By "safest" I mean least likely to be port-scanned and probed for vulnerabilities.

My initial thoughts are to use ports that are below 1024 and not used for any known services (e.g. 471/timbuktu) because they will never in regular usage be accessed and probing them reveals potentially malicious intent (as against the interest of the prober).

Note that the internet-side service port will be selected by the firewall - the port of the service on the server will be different (and, notably, the service will not run as root).

Thanks for reading - appreciate your thoughts.



  1. Of course this is security through obscurity. That would be why this question has the obscurity tag! ;) That it is security through obscurity is not relevant to what I'm looking to find out. While it may be helpful for passers-by who know little about security to have the obvious pointed out, it doesn't answer the question or further the discussion. I expect the emphasis on the concern about security through obscurity is because I've phrased my question poorly.

  2. None of the answers that have been given really help me. Why would ports above 10000 be preferable? I would expect the opposite. Those are ports that are used by TCP connections going out from consumer machines, therefore the signal to noise ratio of anomalous connections to those ports is much lower on higher ports. Hence, the expectation of assailants to be detected while scanning lower ports is higher and the incentive for assailants to use said high ports or scan them is higher (notwithstanding popular service ports vis-à-vis e.g. NMAP's top ports). However, there are many more high ports, so the question is whether the probability of a scan hitting an obscure high port is lower than the probability of hitting a low port for an unused service. This is an emperical data question, I think.

  3. The internet-side connection port can be below 1024 with NAT. That's the port of relevance. The internal port is irrelevant, hence the application would not run as root (admin privileges, etc.). Even if it did run as root, it could be chroot'd/jailed.

  4. Port knocking is a great idea. Albeit a creative way to steganographically hide the service (and hence decrease the probability of service discovery), unfortunately it's doesn't answer the question. Thanks for suggesting it though.

  5. What would really help (and this is the sin qua non of the question) would be some emperical data on what ports are being probed with SYN/connect, and what payloads are being sent to honeypots, etc. That's much broader, but it's really more what would help.

EDIT 6: It would be valuable to know if those unused ports (i.e. <1024 and not assigned to a service, e.g. ports 4, 6, 8, 10, 12, 14 ,15, 16, etc) are ever scanned. If you look in your firewall logs, do you see things probing unassigned service ports?

Thanks, again.

EDIT Just for clarity, “safest” in this context is essentially a measure of the intervals of scans on a port. The vulnerability implied in the question is an exploit of a service for which no patch has yet been deployed. A port is “safer” if it has an interval substantially greater than the time to deploying patches that fix exploits, if you take my meaning. Thus port 60001 is safer than port 22 for SSH if there is a remote exploit in the ssh daemon because port 22, as the default ssh port, will be scanned more often for secure shell daemon (and corresponding exploits), therefore there is less time to deploy a patch between potential remote exploit attempts. This was the original thrust of this inquiry, and I hope this comment is helpful.

closed as primarily opinion-based by MadHatter, Massimo, womble, HBruijn, kasperd Sep 4 '15 at 10:10

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    If I were going down this road, I'd probably use PSAD : cyberciti.biz/faq/linux-detect-port-scan-attacks this will detect port scans and drop the offending IPs into your firewall. – Tim Howland Sep 15 '09 at 18:21
  • 3
    For all of the people complaining about "security through obscurity": If obscurity is so bad, why is running SSH on an alternate port so highly recommended? Why do militaries use camouflage? Obscurity by itself doesn't offer anything meaningful. It's really useful when layered on other defenses, however. – Gerald Combs Sep 15 '09 at 18:27
  • 2
    @Gerald: Because stupid people are allowed to post things on the Internet, too. – womble Sep 16 '09 at 7:22

A random high port (somewhere north of about 10000) is probably the least likely to get scanned, but given that it only takes one scan to find and exploit a vulnerable service, I strongly suggest you rethink your strategy.

  • @Womble: I'd quite like to know the basis for your thinking that the 10000+ range is safer. Thanks! – Brian M. Hunt Sep 15 '09 at 17:00
  • 2
    It takes time to port scan a host, so most people are just scanning < 1024 (or known exploitable ports). If you have a decent firewall in front, it can generally block port scans after a few dozen packets anyway. – Doug Luxem Sep 15 '09 at 17:31
  • 1
    @Brian: Less services live up there, so the ranges are less likely to get scanned. Not much less likely, though. – womble Sep 16 '09 at 7:21

Well, unless I'm mistaken (I'm not a *nix god) and assuming you're using *nix (by your mention of root I assume you are) you still have to be root to bind to a port lower than 1024 so that's out.

Beyond that, security by obscurity is not your friend and not a practice you should enter into. Port scanners can automatically enumerate all of your ports so if someone wants to find it they will. Choosing a different port number might just make it take a little longer for them to do so.

It won't matter if the firewall accepts incoming traffic on a different port than your app server is listening on. If it allows incoming connections and gets one it'll happily forward that onto your server on that different port, especially if it's simply a packet filtering firewall. You'll be slightly better off if there is a proxy on the firewall that will let you do application level protocol analysis and filter out various actions at that level.

Happy to clarify. In response to your comments,

From your original post: "and, notably, the service will not run as root". If you do not run your service as root you will not be able to listen on port < 1024. Thus the dismissal. Sorry, it wasn't clear to me at first that you were going to forward from < 1024 on the firewall to > 1024 on the app server, but I understand what you were implying now.

I didn't say port scanners DO scan all ports, I said they CAN scan all ports. Is this likely? No, not as likely as well-known ports. Will an intelligent firewall detect this? Yes.

My final paragraph is just a statement that once an attacker finds an open port it'll just blindly forward the traffic on through, unless you have an app-level filter in place to do more granular filtering in which case the blindfold is more transparent. I'm not necessarily encouraging app-level filters with that statement. I'm saying that port forwarding isn't going to save you anything once an attacker has a connection.

So, bottom line, you asked for thoughts (often interpreted here as "suggestions") and my thought is that it doesn't really matter what port you choose. You're susceptible on any port. Sorry if that didn't fit in your expectations, and I hope that helps to clarify the intent of my post.

  • @Squillman: -1 This does not answer the question at all, and your statements on port forwarding and running as root are actually incorrect (any non-retarded firewall can forward external port X<1024 to any port on any IP behind it). Unless you're opening the server to a DMZ, it doesn't matter what port the application binds to. – Brian M. Hunt Sep 15 '09 at 19:25
  • @Brian M. Hunt: My statement about port 1024 was not at all about port forwarding, it was about service binding on the application server. You have to be root to bind to a port < 1024. In other words, XYZ app can't listen on port < 1024 unless it's running as root. In fact, the 3rd paragraph speaks directly to port forwarding. "Accepting traffic on a different port than what the app is listening on" is port forwarding. As long as the incoming connection is allowed by the firewall it'll happily "port forward" the connection to the server. Please reread. – squillman Sep 15 '09 at 19:38
  • @Squillman: Thanks for following up. I find your post hard to understand. Perhaps you could clarify. You open by dismissing outright binding to ports under 1024 as the introductory statement of your answer. You then state that port scanners scan all ports of targets (which I think is rather unlikely except for targets like Google; I would enjoy evidence either way). Your final paragraph states what port forwarding is (knowledge of which belies your first paragraph), and encourages app-level filters. How are these statements relevant to the odds of a TCP being probed? – Brian M. Hunt Sep 15 '09 at 20:53
  • @Squillman - +1 That's clearer and helpful, thank you. – Brian M. Hunt Sep 16 '09 at 12:28

Suppose you've got a server that runs insecure software and you have to make it publicly accessible, what ports are "safest" for providing that service on the internet. By "safest" I mean least likely to be port-scanned and probed for vulnerabilities.

Your question smells of security through obscurity. That just isn't a good way to operate. I strongly suggest you consider other options.

You say you have to make it publicly accessible. This probably means that you are giving access to somebody to the system. Your users will be able to exploit the vulnerabilities.

If you must run something that is vulnerable you should at least run it behind a proxy or an application gateway that can protect it.

If possible you should also consider requiring VPN, port knocking or something so only trusted users can access the system.


Totally depends on what you're doing and what your situation is.

If you mean something has to be publicly accessible by the public then hiding the port makes it an open secret.

If you mean accessible to only a select number of people, then you can probably use some other method to "lock" out the port...depending on the service you could use something like port knocking.

If you're trying to allow people only from specific IP's or IP ranges, you can just tell the firewall or service to only allow access from particular IP's.

Can you put this server into a subnet of it's own, into a walled garden of sorts so that it isn't going to put internal systems at risk?

What service are you running? Some things like SSH have security features added in or extra support for features that are written up in howtos like the port knocking, whereas I'm not sure things like SMTP would handle this well.

The question is a little vague in terms of what tools you have available in your toolbox to stop attacks. Port scanning is going to happen on all major ports like www, smtp, telnet, ssh, etc., and any port well known for Windows services. If you're targeted for an attack, then no port is safe. Sometimes doing something like hiding a service that you have available to others using security through obscurity may be like swatting a bees nest with a stick. You're encouraging someone to attack you for fun.

You should really reconsider the strategy, and try doing something to wall off that server as well as send logs to another system, install an intrusion detection system, and make sure it's routinely monitored for suspicious activity. You might want to consider an edit to elaborate a little on your goals and what exactly you're doing. Unless you want advice through obscurity too :-)


This is real simple. Insecure software exposed to the Internet is just waiting to get clobbered, no matter how you try to hide it. The high ports are the "safest" but you will need a decent reactive firewall to hide behind to be safe. By reactive I mean one which will drop all packets from a given source if any one of a range of attempted attacks is detected. That still doesn't mean your idea makes any kind of sense but it will make it a lot harder for someone to locate your insecure port through a port scan.... unless of course they hit the correct port on the first few tries.

  • @John: Why do you think high ports are the "safest"? I've hypothesized that low ports on unused services would be "safer", with reasons above. I'd like to know why you think high ports are safer. Unfortunately, I don't know if it's possible to get a sound answer without diligent review of firewall logs, but I'd like to know your thoughts. – Brian M. Hunt Sep 15 '09 at 17:14
  • I believe the high ports are safer simply because the low ports are most frequently scanned and because they comprise a very small part of the overall range. The likelihood of hitting the correct port in the low range is therefore proportionately greater. – John Gardeniers Sep 15 '09 at 22:07

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