What ports are least likely to be probed on the internet? [closed]

Question

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.

Brian

EDIT:

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.

Answer 1

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.

Answer 2

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.

EDIT:
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.

Answer 3

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.

Answer 4

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

Answer 5

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.