In follow up to my teammate Marc’s post last week around OPC UA and network traffic, this week I’m going to explore firewall ports in more detail. My goal is to help you understand where IT is coming from when they get concerned about any open inbound ports on firewalls. There is more to it than the obvious which is why they ask a lot of questions. This is especially true when one is talking about a connection that is coming from outside the plant firewall, but also even when it’s a port between a business and a production network.
Through understanding more, you’ll be able to have collaborative discussions with your IT team, where you can weigh the risks with IT as your partner, look for options that address the risks, and accomplish the movement of data required to run your business in ways that address your application-specific security concerns.
Know Your Risks
Every business is different, and I don’t profess to being capable of knowing all your risks. So, an important step in any security discussion is to be aware of the nature of your business, the risk profile, and what concerns the people running your business and, thus, IT. All businesses are targets but some are even bigger targets; you just need to be aware.
Inside vs Outside the Facility
In this post, I am mainly focusing on opening inbound ports to allow traffic to pass in from outside the plant. The topic of the “inside job” where an employee or contractor is physically in the building can be a whole separate topic of discussion and is the reason why IT may also be concerned about any open port between business and production networks.
The technical risks are the same for any open port, but when you are inside the facility firewall, the practical sources of attackers may change. In addition to physical access being a risk inside the plant, the well-known email link and malware attachment risks, just to name a couple of the many out there, create the risk of a user on either the production or business side “inviting an attacker in”. That’s why those attacks are so popular and, once on the network, that attacker may as well be physically present, depending on how your network is setup.
Closing or Opening Ports
When a port is closed on a firewall, security is in the hands of the firewall to not accept any requests to open a connection for TCP traffic, and reject UDP connectionless traffic to closed ports. To an attacker, a closed port doesn’t really exist, as they will receive no response. But let’s look more closely at what happens when you open that port.
In the simplest case, you have opened a door completely and told the firewall to let all traffic flow, bypassing any methods, algorithms, or technology in the firewall that is purpose-built as a security device. An open port is an attack surface. Even one port - it’s a place for someone to probe. Then who is in charge of security after that? It’s the software applications that the traffic flows to that you are now depending on for that security. But those applications are nearly always built to perform a specific function and are not specialized and hardened for network security like a firewall. Attackers probe for open ports, looking for weaknesses in the software such as a factory default password, an easily guessed password, an injection attack, or other vulnerability.
So let’s look at some common questions you may have.
I thought Advanced Firewall Filtering and Intrusion Prevention Services protect us?
Today’s enterprise class firewalls are capable of doing a variety of things to inspect traffic, identify suspicious or known attacks, and block them even on an open port. You can also setup rules that say “only allow traffic from these IP addresses, or even in some cases these MAC addresses” which can make the attack surface smaller but never totally eliminate it.
Keep in mind a human has to configure and maintain those filters. One mistake and the attack surface is enlarged, or critical data flow is cut off. Some firewalls can run a proxy on an open port and the proxy inspects the traffic using rules, algorithms, and detection mechanisms that are constantly updated by the firewall device vendor. When using those technologies realize you are trusting that device’s algorithms and any rules that were defined by humans managing the firewall and there is an attack surface there.
Encryption & Authentication Protects Us, Right?
Encryption keeps someone from reading your data if they can’t decode it. It does not prevent attacks. Encryption also means that any filtering proxies in your firewall can’t read the data so they cannot determine if an exploit is included in the data, so the firewall packet inspection is actually subverted by encryption.
There are famous break-ins that were performed by attacking the encryption mechanisms on devices, server operating systems, and software applications. If you’ve had to deal with IT shutting off the older TLS1.0 and TLS1.1 encryption support on your systems, that’s why as those encryption methods are well known attack surfaces.
Similarly authentication is just another thing for an attacker to try and exploit. Even if they don’t get in, they can overload your application with requests to the point the application is doing none of its main purpose and is spending all it’s time fighting off requests.
We Are Running a VPN, Isn’t that Safe?
This may seem safe, almost like bringing the client into the secure environment of the plant. But actually it’s the other way around. Using a VPN simply expands the security perimeter of the plant to include the remote VPN client. Now the plant is exposed to whatever risks the client is exposed to. This is how the NSA EternalBlue exploit propagated the well-known WannaCry virus, and still remains a serious threat today. In many cases where VPN clients and the connection were not restricted properly, when a VPN client connects it has access to your entire network.
In upcoming posts, I’m going to explore the risks around VPNs and other methods of mitigating open port risk further. Be sure and register to receive updates at the bottom of this post.
We Need to Move Data, So What Do You Do?
Ultimately decisions around opening ports must be made by you and your IT team in the context of your business and application needs. If you are going to open even one port, we are not in the business of rendering advice on how to do that within your security stance, but there are experts that can help, such as the US NIST who has published guidelines to consider.
If your business’s security position is that you are not going to open inbound port, there are solutions. A solution that we’ve been helping users with involves reversing the connection, which may sound impossible, but has been implemented in the Cogent DataHub tunneling solution.
Learn More in our Reversing the Connection Article
Ready to Keep Learning?
In the spirit of our recent DataHub Virtual Learning, as I said earlier, I’m going to be publishing additional articles on this topic and exploring solutions. To be notified as I publish more content, register below!
