Summary

Network security devices like Suricata and Snort struggle to inspect and block threats within encrypted VPN and TLS traffic, which can impact the effectiveness of security rules and measures.

Abstract

The article discusses the limitations of network security devices, such as Suricata, in inspecting encrypted traffic, particularly when using VPNs or TLS encryption. It highlights that security rules designed to block malicious traffic may not function as intended when the traffic is encrypted before reaching the inspection point. The author points out that while encryption is crucial for privacy, it can prevent security devices from detecting and blocking threats. The post also touches on the concept of Man-In-The-Middle (MITM) attacks, where an attacker can decrypt and inspect traffic if they trick a user into accepting a rogue certificate. Furthermore, the article reflects on the trade-off between privacy and security, using the example of airport bag inspections, and emphasizes the need for multiple layers of security, known as defense in depth. The Capital One breach is mentioned to illustrate how Mutual TLS (MTLS) can inadvertently hinder a web application firewall's ability to detect malicious activities. The author, Teri Radichel, concludes by urging network designers to be aware of these encryption-related challenges and to consider privacy implications when implementing traffic inspection methods.

Opinions

Encryption of network traffic through VPNs and TLS is essential for privacy but poses significant challenges for network security devices.
Security devices may only inspect unencrypted parts of the traffic if the payload is encrypted, limiting their effectiveness.
MITM attacks exploit the trust model of SSL/TLS, allowing attackers to decrypt and inspect traffic, which is similar to how some firewalls operate.
There is a delicate balance between maintaining user privacy and ensuring network security; this balance requires careful consideration.
The use of Mutual TLS (MTLS) in the Capital One breach exemplifies how encryption can prevent security tools from detecting attacks.
Relying solely on host-based security can be risky, as malware can potentially disable or bypass such protections.
Network security should employ a multi-layered approach, including network-layer inspection, to protect against encrypted threats.
Network designers must be mindful of the implications of encryption on security analysis tools and the potential privacy breaches when using MITM techniques.

Network Security Devices Can’t Inspect Encrypted Payloads

Some Suricata or Snort rules won’t work with VPN and TLS encrypted traffic

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: Network Security | pfSense | Cybersecurity

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I was troubleshooting some issues with Suricata and ran across this Q & A post on the Netgate website. The person is talking about how Suricata rules don’t block people who are using a VPN when the traffic is applied to the WAN interface. However, when applied to other interfaces or when not using the VPN people are getting blocked.

This person’s traffic may not even be inspected by Suricata within the traffic payload.

“Block snort2c hosts” blocking http traffic for LAN clients

For the past year, I’ve had all traffic on the LAN go thru the VPN tunnel. Everything worked great. I recently created…

forum.netgate.com

When you use a VPN it encrypts your traffic as it gets sent over the network. If Suricata is inspecting that traffic and the traffic is encrypted on the client and decrypted somewhere past the firewall, Suricata only sees the encrypted payload and cannot detect anything in that payload that might trigger an alert. Suricata may be able to inspect things outside of the payload if only the payload is encrypted and not the rest of the traffic.

If the traffic is encrypted by pfSense as the VPN endpoint then whether or not the traffic can be inspected depends on whether the VPN encryption occurs before or after the point where Suricata inspects the traffic.

The other option is, some firewalls let you send traffic to the firewall directly and then the firewall decrypts it, and then the firewall encrypts it to send it to the final destination. The destination responds to the firewall which inspects the traffic. Then the firewall re-encrypts the traffic and sends it to the client.

This is the same concept that attackers use in a Man-In-The-Middle (or monkey in the middle or whatever you want to call it) attack to snoop on your traffic. They trick you into accepting an intermediary, fake certificate in your browser so it looks like your traffic is encrypted with SSL. Well it is, but it’s encrypted with a certificate attackers can use to decrypt the data, view it, and then send it along. To the end user, it looks as though everything is working fine. But the attacker that got you to allow the fake certificate can read everything you send along to whatever websites you are visiting.

If the attacker cannot trick you into accepting that rogue certificate, then they can’t see your data. The same is true of a firewall that is trying to inspect packets for malicious payloads. I didn’t dig into that post too closely to understand if that is what is happening or that particular person. I just wanted to let people know that you should be aware if your traffic is actually being inspected or not if you are using a VPN.

On the one hand, some people don’t want others to view their data. Some use VPNs so Internet service providers can’t view network traffic flowing over network devices. On the other hand, your security devices can’t protect you from attacks that they cannot see.

Security is often a tradeoff between privacy and protection. When we allow TSA to inspect our bags at the airport that’s an invasion of privacy. On the other hand, we don’t want to allow someone with a bomb on the plane. Where do you draw the line? The choices are not always easy.

By the way, inspecting SSL/TLS encrypted payloads on pfSense is not exactly simple so I’m not even going to get into that here.

If you are trying to defend networks you need to understand how encryption impact your security analysis tools. Part of the problem with the Capital One breach is that the team implemented Mutual TLS which encrypted traffic between the client and server. MTLS is great because it authenticates both the sender and the receiver. On the other hand, the web application firewall couldn’t see the payloads involved in the attack so it couldn’t block the malicious traffic.

Sometimes we can use different types of security in different places to get around weaknesses in a particular implementation. You might think that you can put security on the host where the traffic exists unencrypted and inspect that. However, too many times, malware on a host was able to turn off the firewall and security controls or bypass it in some way. Inspection at the network layer cannot be bypassed by malware on a host alone.

All these complications are why we need multiple layers of security and defense in depth. Sometimes we can glean from net flow that unwanted behavior is occurring and perhaps some Suricata rules only look at the traffic in those layers.

Just understand, if you are using rules that look at the data in the packet payloads, that the rules won’t help if those payloads are encrypted in such a way that the traffic inspection device cannot see the traffic. Also be cognizant of the potential breach of privacy if you do use a certificate to MITM the traffic. With great power comes great responsibility. If you are designing a network anywhere — including for cloud applications, these considerations apply.

Follow for updates.

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab