2

I have a home server running Ubuntu 16.04 Server Edition. I have a couple ports that my router forwards to my server and ufw on my server allows so that I can access the services outside the LAN - namely, SSH on a custom port (as the router blocks port 22 for forwarding) and ports 80 and 443 for HTTP and HTTPS for my web server. I want to open a port for development purposes - specifically, port 9991, which is not associated with any particular service/protocol. Most of the time, the development server listening on this port will not be running. However, the router will still forward requests on this port to the server, which will still be allowed by ufw. If there is no service listening on the port, yet it is open to incoming connections, is there a security threat?

marked as duplicate by Arminius, techraf, Anders, Rory Alsop Dec 28 '16 at 13:58

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4

In nmap terminology, an "open" port is usually the port where a service is bound on, and listening; otherwise the port is not open.

However, it seems like you are asking about having a port open on firewall. This is, allowing the remote hosts to connect to port 9991 on a server through firewall, even if there is nothing bound on this port and those connection attempts result in refusal. Yet this poses a few risks:

  • If your server is compromised, one can run an HTTP server on that port, and use it to spread illegal content (such as ransomware binaries, or host C&C server).

    More, in the enterprise setup, this compromised server could also be used to infect other machines inside the organization - including those which couldn't connect to Internet - via phishing attacks pointing to this server. This would have a higher chance of success as corporate users might trust internal servers more than external servers.

    Finally, making the compromised server easily accessible is much easier when one can simply launch sshd listening on this port.

  • If someone upgrades the OS on this server, a new version might introduce a service listening on this port. This service might not be secure in the default configuration - for example it might have known default credentials - and result in exploitable vulnerability.
  • It is pretty clear how the OP is defining 'open'. Your intro appears unnecessary. Also, I was with you until the "via phishing attacks" paragraph. People don't tend to trust links with IP addresses, even internal ones, which is what you would need to do in your scenario. I just don't think you've thought through the requirements for that paragraph to make sense. Otherwise, the points about a bare open port being used for other traffic and a new service unexpectedly using that port are interesting. – schroeder Dec 28 '16 at 7:32
  • Fixed. Regarding phishing, in my experience the servers in organization are almost always assigned internal names, so there is no need to use IP. – George Y. Dec 28 '16 at 9:49
  • Sure, but the naming convention suffers the same problem: why would someone trust an internally named server? – schroeder Dec 28 '16 at 16:52
  • Perhaps because an e-mail impersonating a company CISO states that the main server been compromised by ransomware, and an urgent patch is released on a backup server - install immediately? People are more likely to act when it is a binary stored on local serer than on some 03.warez.com/abc/9339.exe. And perhaps IE treats internal servers differently (security zone) than public Internet, for example in regard of ActiveX installation, etc? – George Y. Dec 28 '16 at 22:54
2

If there is no server behind a port, it is not technically opened. I assume that your question is more: is there a risk to have a port with no server not to be blocked by the firewall?

My answer will be in 2 parts. First, as there is no server listening on that port, there is no actual risk. But is does show that the firewall is poorly configured.

Best security practices recommend that a firewall blocks anything that is not required. It is a mere application of the separation of concern principle: the firewall admin should not know exactly how the servers are configured, he only should considere the required channel and block everything else.

So even if there is no immediate risk, not blocking the port at the firewall level is still a poor configuration.

1

no, if there is no service listening on that port there is absolutely no risk. Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP), specify a source and destination port number in their headers so if there is no service to respond there so no connection is established and the socket will be closed.

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