TECHNICAL INSIGHTS: DECRYPTION – BOTH WAYS?

29 January

DECRYPTION WORKING BOTH WAYS, INBOUND INSPECTION (PROTECTING YOUR WEBSITES AND SERVICES FROM THE INTERNET)

When working on a traffic decryption project most administrators get so far as doing outbound decryption whereby a firewall or other device inspects the traffic between internal client PCs and the internet. A frequently forgotten puzzle piece is protecting your websites and services that are published to the internet with inbound decryption and inspection of traffic.

While some organisations may look to SaaS WAF providers to provide this additional layer of defence, many of these services offer rudimentary security features beyond DDoS protection. Without the ability to inspect this traffic bad actors have a potentially free run of trying out any kind of attack they want – at least until another detection mechanism picks up on it.

To illustrate the difference between “catch rate” of inspected and uninspected inbound traffic I’ve spun up a few test servers in our lab and using the Nessus vulnerability scanner have run a pair of tests to see just what a Palo Alto Networks Next Generation Firewall can detect during a scan with both inbound decryption on and off. While we won’t get the same results that might be seen from a ‘determined attacker’ we will get an idea of how things look from the standpoint of a ‘casual attacker’.

Kit list for this testing:

– An ‘internal’ web service, in this case the web console for PRTG Network Monitor (running on Windows Server)

– A Palo Alto Networks Next Generation Firewall – a PA-850 running PAN-OS 8.1 with a full suite of licences

– The Nessus vulnerability scanner

Both the firewall and the web service have been configured to run TLS1.2 with the private key for the certificate on both (which allows the firewall to decrypt the traffic without breaking connections); additionally the latest firmware/security updates have been applied across the board.

I ran the testing in two phases, first with decryption enabled and then without decryption enabled. Before each test I cleared the Threat, URL and Data logs on the firewall.

The Results

The results turned out as expected, with not a single one of the Nessus scans (run over HTTPS) being detected as a threat while decryption was off, turning decryption on immediately lit up all kinds of brute force attempts, remote code execution attempts and other such nasties. The NG Firewall simply has no visibility into the payload of the traffic without TLS inspection.

When running without decryption only threats on port 80 (over plain text) were detected – although this might allow for blocking by source IP it’s far from the best solution.

With decryption turned on it immediately lit up all the traffic inside HTTPS with 236 threats being detected, of which 169 were detected as medium/high/critical and in turn would have been blocked by a firewall configured to the best practice templates.

Number of threats detected with decryption: 448 (236 over HTTPS)
Number of threats detected without decryption: 226 (0 over HTTPS)

Additionally with decryption enabled the App-ID engine inside a NGFW has a much easier time of isolating the specific application (e.g. Exchange Active Sync/Confluence/Remote Access Tools/Airwatch) that is being accessed – in turn this allows administrators to further restrict access and reduce the attack surface by not just enabling a port and instead enabling the specific application.

As a final note, we also have the advantage of seeing file transfers within the TLS session once inbound inspection is enabled, so in much the same way as we may want to block users from downloading executables, and to ensure AV scanning and Sandbox Analysis is performed with outbound inspection, we can now apply the same controls for inbound inspection. Preventing malicious content being uploaded to or downloaded from public facing web apps.

The ultimate question – should I enable inbound decryption?

Yes; but, it’s important to remember that security always needs to be a layered approach – here we’ve proven beyond doubt that by enabling inbound decryption more threats can be detected and blocked. Things get more complicated with very specific attacks that might try and exploit specific features of a website/web service (like SQL injection, Cross Site Scripting and Path or Parameter manipulation) – here you have to look beyond the firewall and towards ‘web application firewalls’ which dials this kind of security up even further. For your more determined attackers you will have to look even further beyond these edge protections, here it’s worth a look the MITRE ATT&CK Matrix and other similar frameworks.

NEXT STEPS…

Please reach out to us or get in touch with your account manager if you require assistance in configuring these services or are looking to review your stance on traffic decryption.