I gave a presentation to the Orem, UT Kiwanis chapter on staying digitally safe. The presentation slides are available.
Page 3 of 4
Network encryption is a game changer for security teams as it makes it more difficult to identify malicious traffic. It may even paralyze some people and cause others to dismiss network security monitoring altogether.
But does it have to be this way? During a recent SANS webcast entitled Alternative Network Visibility Strategies for an Encrypted World hosting Zeek/ Bro experts, Matt Bromiley said, “(Encryption) just means I have to change my analysis techniques and change the way I approach these particular datasets as well.”
Continue readingWith the majority of web traffic now served over HTTPS, it is important to decrypt traffic to give visibility to network security monitoring (NSM) tools. The Palo Alto Networks next-generation firewall can decrypt inbound traffic quite effectively.
However, there is one gotcha when enabling this feature on production systems with live traffic. Beware of SSL session caching!
Identifying the SSL decryption transition issue
When I first tested SSL inbound inspection in my Palo Alto firewall, it was in a lab environment and it worked great! The URLs were showing up in the logs, I did not get any SSL errors (decrypt-error,
decrypt-unsupport-param, or decrypt-cert-validation) and it all seemed to work fine. I submitted a change request and was on my marry way.
Then I enabled the feature on a system with a fair amount of active traffic. The results were startling. There was a huge spike in “decrypt-error” logs I couldn’t explain. Enough users were complaining that I ended up reverting the change, puzzled at why what worked flawlessly in the lab didn’t work in production.
I had two leads to what the cause was. The first was Palo Alto’s 8.0 and 8.1 documentation on the “decrypt-error” session reason end saying:
“The session terminated because you configured the firewall to block SSL forward proxy decryption or SSL inbound inspection when firewall resources or the hardware security module (HSM) were unavailable. This session end reason is also displayed when you configured the firewall to block SSL traffic that has SSH errors or that produced any fatal error alert other than those listed for the decrypt-cert-validation and decrypt-unsupport-param end reasons. “
Palo Alto Networks Pan-OS® Administrator’s Guide 8.0 & 8.1
The second clue was the error that appeared in browser windows of some clients who had an active connection to the server at the time. For Google Chrome it was “ERR_SSL_VERSION_INTERFERENCE” and “ERR_SSL_PROTOCOL_ERROR” for Samung’s browser on Android. Firefox and Microsoft Edge gave similar messages.
This led me to believe that clients with cached SSL sessions were attempting to resume their SSL sessions. When that happened the firewall treated the connections as if they were a new connection but would produce a fatal error when it didn’t receive the expected payloads for a new session.
Resolution to resumed SSL sessions
To resolve this, I tried changing the decryption profile settings such as disabling “Unsupported Mode Checks,” but to no avail. On affected clients I tried clearing the SSL cache and even restarting the machines but that did not correct the issue.
Finally, I reduced the SSL session cache timeout setting on the server itself to 60 seconds. When that happened, the issue disappeared!
I wouldn’t recommend shutting SSL session caching entirely as there could be a huge performance impact to the server, but a 60 second timeout leading up to and immediately after enabling the policy should be adequate. If possible, keep it 60 seconds for as long as what the value was previously. I also found decreasing the timeout even after enabling SSL inbound inspection immediately worked.
You can find documentation for SSL session timeout settings for Nginx F5, Apache, and IIS. (At the time of writing I have not tested the parameters on each of these.)
Some forum posts suggest restarting the server(s) will also clear the server’s SSL session cache and force a new negotiation, although I did not test this. This isn’t always feasible if sessions are shared across multiple backend servers, there is a load balancer at play, or engineers are turning on decryption for a large number of servers.
When I contacted Palo Alto about this issue, they told me, “(T)here is feature request (FR ID: 5786) in addition to Jira PAN-80072,” that they did not have a work-around, and that “the only thing to be done now is to wait till further notice.” I am disappointed they do not publish the known issues surrounding decryption and did not have a work-around readily available as this would have saved me hours of troubleshooting, research, and some downtime.
If you found this write-up useful, I ask you let people on Twitter and LinkedIn know. If you liked this post, check out Is Network Security Monitoring Dead in the Age of Encryption?
Over the last several years we have seen encryption become more pervasive. Does it now make sense for security teams to invest in network security monitoring solutions?
With the strong push for encryption on everything from websites to hard drives, encryption is becoming a standard practice for most organizations. Reviewing the graph below from Google’s Transparency Report, we see that a majority of web traffic is now HTTPS.
Encryption is permeating other protocols. In September 2018, CloudFlare announced a new protocol that hides the server name during the SSL handshake. RFC 7858 (DNS-over-TLS) and RFC 8484 (DNS-over-HTTPS) both were proposed this decade and are already implemented by some organizations. (Note that DNSSEC doesn’t encrypt dns queries, but ensures they are authenticated.) SMB and SNMP in their third versions also include cryptographic capabilities. Microsoft’s Remote Desktop protocol now incorporates SSL, and SSH has always been encrypted.
It seems that just about all data transmitted over a network is encrypted or is moving in that direction. It is these reasons that some vendors push to move security monitoring to the endpoint where the machine decrypts the information anyways. Is network security monitoring dead in the coming age of encryption? Continue reading
Every organization with an Internet presence is battling for survival. State-sponsored hackers and organized crime groups continue to gather power and are more dangerous than ever before. We have approached the day when organizations must combine forces and reallocate resources to effectively defend against these formidable adversaries.
Continue reading
One common mistake IT administrators make is exposing the management interfaces of their services directly to the internet. Not only is this a poor practice, but these days it can almost be considered negligent. A defense in depth example will help you understand how to better protect your systems.
Imagine security analysts easily finding answers to questions about your organization’s network such as: What devices have port 445 enabled? What servers are running an old version of Apache? How many web cameras are on our network? Envision automatic notifications when outdated or vulnerable software is detected in your organization! That’s the value of the NIST asset inventory in the cybersecurity framework.
Someone recently contacted me concerned their Google account might be compromised. Although they live in California and have never traveled to Europe, Google will redirect them to European versions of Google, usually the Czech version. The individual informed me that after signing into a Google service from her home, Google notified her via email that a new sign-in was detected coming from Prague.
The last three articles I’ve published step you through how to setup the Bro intrusion detection system (IDS) on Red Hat 7. You’ve read through installing prerequisites, compiling and installing Bro, and configuring it for the first time. But despite anyone’s best efforts, there is likely to be some hiccups along the way. Your Bro workers might drop packets, hit a Bro bug, or perhaps a worker crashes. This post will examine some tools to help you diagnose common issues and unfold some potential causes and solutions with Bro.
The Bro IDS is great at analyzing network traffic, not to mention it’s very capable at detecting and logging issues that it finds in your network traffic. It’s amazing that an open-source project has progressed this far. This post covers configuring Bro and running it.
Let’s review what we have covered in part one and part two of this guide:
- Prerequisites for Bro IDS are installed, including:
- PF_RING
- Other needed packages
- OS settings are adjusted, including:
- Firewall/IPTables
- Memory/buffers settings are adjusted
- Bro is compiled
- Plugins are compiled and installed, including:
- PF_RING
- Setcap (which enables some permissions for non-root users)
This section will go into configuring various settings in Bro, then starting Bro. We’ll also explore how to check on the health of Bro.
