2

I have a server I am using to host public internet services where I want to start and stop many instances, lets say up to 50 per physical server. The architecture of the software means each instance needs its own port (unlike say HTTP where I could have a single Apache/NGINX/etc. then proxy requests to the right place based on domain name etc.).

Is there any security risk of making say 50 unprivileged ports (assuming I extend the software default port, this would be say UDP and TCP ports 35000 to 35050) permanently open in the systems and network firewalls, even when there is currently no instance running on that port? OR should I go to the extra effort to dynamically open/close the ports?

Does it matter that the software appears to default into the dynamic port range, or an unprivileged port (at least for Linux servers where low port numbers need root) in general?

Fire Lancer
  • 128
  • 5

3 Answers3

2

This shouldn't be an issue unless a buffer overflow is found in the network stack. In that case, you are screwed if you have any ports open. However, the main purpose of a firewall is to prevent outsiders from connecting to services which should only be accessible to the local host (in the case of a host firewall) or to an internal network (in the case of a network firewall). Your particular case is that of a host firewall, and thusly there should be no effect on the machine of leaving the ports open other than that someone will believe that a program occasionally runs on those ports if they perform a scan (which is true, but trivial information in your case).

Therefore, no, you don't need to close the ports unless you are concerned about someone guessing that there is occasionally a service running on those ports and attempting to someone figure out when the service is running and on top of that develop an exploit for a piece of software they have no knowledge of.

DeepS1X
  • 321
  • 1
  • 5
  • Yeah the scan finding active ports and existance of the server are public information anyway, there is a webpage that could just tell them that info, and I have to except the risk in the software itself and trust the vendor. I was more interested in the risks of people exploiting some other OS or network thing I was not aware of (like being able "connect" to the port in some way to DOS it when the instance next boots other than brute force traffic flooding) – Fire Lancer Aug 04 '17 at 08:45
  • No need to worry about that. I was just enumerating some edge case scenarios in which things could go poorly if a determined attacker was after you, not things which are actually likely to occur. I should state however, that I agree with them in that leaving ports unused for other applications is good practice, but not necessary at all in your case. – DeepS1X Aug 04 '17 at 13:31
1

from architecture point of view. you need to visualize this type of security for udp or tcp into two categories

  1. End point ( your service instance) listener where if the instance of your service is not running, it is imposible to connect to, basically your end point does not exists. -

  2. in-transit ( your routing, firewall, etc) where if a connection is attempted from one side (public side in this case) and the service is not active at the end point, the packets are just dropped because there is no service to respond.

  3. Next is to secure your end point(1) ( there are multiple ways) such as mutual auth, SSL/TLS, authentication etc).

  4. Next secure your in-transit point , for example for DOS (denial of service) it is usually stopped at the gate not at the service instance. big part of intrusion prevention and detection is done in this layer.

If you service becomes very popular, you will be prepared.

To answer your question with a specific solution:

  1. Determine the maximum number of instances you service requires (apparently 50 from your question).
  2. Configure your host(s) ephemeral ports ( port pool), this is possible on both *NIX and windows.
  3. On your network firewall (if this applies) create a firewall rule that allows (any source --->to your host(s)IPs/ ephemeral ports.
  4. On you local firewall (FW runnin on the host), also configure a firewall rule that allows packets from external-Firewall IP--->your Host IP/port range.

by convention, ephemeral ports are between 49151 to the upper limit for IPV4-IPV6.

Hugo R
  • 177
  • 2
  • 1 is not applicable (its a publically usable service, with public IP, DNS records, links/information on other web pages etc.). 2 you are saying a port without a listening socket is just as secure as a closed port? 3/4 are not applicable for this (active port?), and since its not my software I have to trust the vendor that the software itself is secure. – Fire Lancer Aug 04 '17 at 08:39
  • yes, from end point perspective a port without a listener is as secure as a close port. there is nothing to be attacked. however in an enterprise setting, a FW rule may be something like "source to any" in this case any host running a listener (not nescessary your service) on that port would be vulnerable. – Hugo R Aug 07 '17 at 05:15
1

DeepS1X is right that it would require targeted effort for someone to abuse those open ports, but I think HRL has the right answer. It's not scalable to simply open ports for a service and let them hang out on your server, especially with the amount of other services constantly scrubbing the net for open ports / services.

To add onto points 1 & 2 from HRL's post - You haven't mentioned what flavour of Linux you're using, but you might consider leveraging something like Debian UFW App allowances to manage access into the wild for each of your apps. This would mean you could start and stop your apps as needed and they would have port access simply by virtue of being up.

You can see about setting up UFW on the ubuntu help site, and there is a detailed explanation on setting this up for your own applications in this post.

llorrac
  • 324
  • 1
  • 7
  • 1
    Welcome to SSE. :) So are you essentially saying "you agree with the approach mentioned in the question"? i.e., leave the ports open in firewall and keep bring up the services as needed? You (and DEEPS1X) seem to think that a targeted can attack leverage an unfiltered but "not open" port (the correct way to think of a port on which firewall allows traffic, but no program is listening on that port). Could you cite any ref / give an example? What about the other part of the question? i.e., a) any increased risk on account of using unprivileged ports? – Sas3 Aug 04 '17 at 06:14
  • Hey Sas3. Thanks for replying - and for being gracious on my first post :) I guess I didn't place a reference as I was thinking of network security best practices? I just had a quick google and came across these two links which outline what I was thinking: https://www.acunetix.com/blog/articles/danger-open-ports-trojan-trojan/ | https://security.stackexchange.com/questions/9461/are-open-ports-dangerous – llorrac Aug 04 '17 at 06:31
  • In general, you are right - when FW refers to a Network Firewall and when there *are* services listening on those ports. Especially if those don't need to be exposed to the outside world. In this case though, the question seems to imply a host firewall, without any service / program listening behind that open port - but will come up when necessary. :) – Sas3 Aug 04 '17 at 08:50
  • I should place a little citation for network stack exploitation here if simply because it is good practice. These types of exploits are uncommon, but not unheard of. These tend to be exceptionally rare in modern OSes, but here is probably the most relevant recent example. https://www.exploit-db.com/exploits/35302/ – DeepS1X Aug 04 '17 at 13:38
  • Another good one is this: http://www.zdnet.com/article/microsoft-fixes-gaping-hole-in-windows-tcpip-stack/ – DeepS1X Aug 04 '17 at 13:39
  • Anywhoodle, the point is that anything is exploitable given a determined enough attacker. Except OpenBSD. You know, they've only had two remotely exploitable vulnerabilities in nearly ten years? That is about the same as my SOHO router. Wait a minute...... ;) – DeepS1X Aug 04 '17 at 13:41