Open ports are not a security hole
2015-11-23 22:19 by Ian
What follows is an email I wrote for our sales department, which had to regularly field questions surrounding these issues when our VoIP product came up. The scary thing is that the misconception is most prevalent in the minds of people who should know better (engineers and sysadmins). So here is the most unpopular position you can possibly take in a group of network admins. Maybe it will help someone else dismantle some technical hear-say.
All,
I've had to assuage concerns about this issue often enough to warrant a detailed write-up describing the security concerns associated with opening port ranges on firewalls. I've tried to write this for the benefit of non-technical departments that have to deal with objections to port ranges but do not have the technical knowledge to field this specific question. Nothing in this email is proprietary information. This is all baseline networking knowledge. Please feel free to use this email as copy-pasta for customer consumption (with your manager's approval, of course).
A more detailed discussion about this issue can be found here:
https://www.grc.com/sn/sn-043.pdf
The basic objection:
"We don't want to open lots of ports because of security concerns."
The unstated logic:
"More open ports implies more security risk."
The underlying premise:
"Open ports ARE the security hole."
The flaw in the objection goes back to the premise, which is wrong. In order to have an open port, there must be a program running to listen for connections on that port. Attackers don't attack PORTS. They attack PROGRAMS. The port is only the means of getting to the program, and not itself the target of an attack.
You can tell when someone is operating under the bad premise when you hear things like...
"Change the port, so attackers won't be able to exploit such and such service."
"Closing the port fixes the vulnerability."
The corrected premise is:
"Programs listening on open ports are the security hole."
You can immediately confirm this for yourself by shutting down the listening program while leaving the port open. Any attempts to open a connection on the open port will fail, because there is no process on the other side of the wire to answer your request. So without the ability to make a connection, there is no security hole possible.
No program? No hole.
The unstated logic, corrected to account for the good premise:
"More exposed programs implies more security risk."
Or to state it more precisely...
"The security liability of the server is the sum of the security liabilities of the individual programs that are exposed to the internet."
Let's run a concrete example. For our purposes here, "security liability" is a number from 0 to 10 with larger numbers indicating more risk. Every program on a server has such a number, depending on its config. Let's say that our product's components have these liability values:
| Program | Port | Liability | Notes |
|---|---|---|---|
| Apache | 443 | 3 | |
| SSH | 22 | 6 | Not publicly exposed due to DDoS/login risk. |
| MySQL | 3306 | 4 | Not publicly exposed. |
| Asterisk SIP | 8412 | 2 | |
| Asterisk RTP | 10000 | 1 | |
| Asterisk Manager | 4687 | 9 | Not publicly exposed due to remote execution risk. |
| Cryptographic daemon | 43900 | 9 | Not publicly exposed due to key-leak and DoS risk. |
So a full-featured installation has a liability score of...
1 + 2 + 3 = 6
If we turn off asterisk completely, that score drops to 3, even if the ports for asterisk are still open. Dead programs don't talk. So the fact that there is a means of talking to an absent program doesn't help an attacker in any direct way.
It also doesn't help an attacker to have many possible routes to talk to the same program (besides possibly ease-of-discovery). If there is a vulnerability in the program (Heartbleed, the finger port hack, etc), a single open port is sufficient to exploit the vulnerability.
An objection to open ports makes sense only if ALL of the following conditions are met:
1) The open port is accessible from the internet.
2) There is a running program listening to the open port.
3) There is not otherwise a way to access the program from the internet.
If we open the DNS port (53) on one of our servers that is not running the DNS program, condition (2) is not met. So it doesn't matter in the least (besides being sloppy admin work).
If we then install and start the DNS program, we have increased our security liability because conditions (1, 2 and 3) are all met.
Now, for someone to object to opening port 1094 for DNS as well as 53 on the grounds that the extra open port is a security risk, the attacker just needs to attack port 53. Which he could do regardless of port 1094 being closed or open. In fact, we could open ALL the ports on the server and tell DNS to listen to all of them. This would be a very strange configuration, but it is no less secure than the standard config of having a single port open.
Condition (3) is not met for asterisk RTP. If it is exposed at all, it has already contributed as much as it can to damaging the server's security posture. It doesn't make sense to say that a given program is "more exposed" for the same reason that it doesn't make sense to say "more pregnant" or "very unique". The first word is meaningless for a binary condition.
Unique, or not?
Pregnant, or not?
Program exposed to the internet, or not?
Port scans will often detect open ports. But being the target of a port scan is not itself a security risk. Moreover, the kinds of ports asterisk uses are very easy to conceal from a port scan (because they are UDP, and therefore are not required to SYNACK back to a connecting client).
I don't envy the position of our customer-facing departments that have to explain this to some IT rep or engineer that believes they know better by virtue of their title. But these are the facts of the matter.
Here are some recommendations you can give to customers that can't be bothered with facts (in order of increasing impact on our product's operation):
- Restrict the RTP port ranges to twice the number of concurrent calls you expect the server to handle. IE, if the server needs to support 50 calls at once, they need to open at least 100 RTP ports.
- Configure their firewall to not reply to ICMP requests. This is a well-understood practice, and the customer's IT people should know exactly what is meant by this recommendation.
- Don't configure the voice server to use TCP for SIP traffic. This will make the SIP port more difficult to discover with a port scan, and will also improve their resistance to SYNACK flood attacks (a type of DoS attack).
Previous: Excursion to the bare-metal: ARM Cortex vs MIPS
Next: How will quantum computers impact cryptography?