Today we have the answer to the question – Without SSL decryption how many threats/attempted vulnerability exploits/other bad stuff will I miss that are coming from the internet at my internally hosted (externally published) web sites and services?
To run some simple tests (which will be detected as malicious attacks) I’m going to be running the Nessus scanner against a website behind a Palo Alto Networks Next Generation Firewall, 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’.
In short the answer is you’ll miss a lot – without decryption of traffic coming at your own web servers it’s pretty much impossible to detect attacks (with some minor exceptions) that are hiding inside HTTPS, either way let’s see how it’s done…
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) and the latest firmware/security updates have been applied across the board. Continue reading
For some time there have been plenty of examples of backing up Palo Alto Firewalls with curl commands (extracting the files using the XML API) however that may not sit well with some Windows administrators who want to use PowerShell. As such I’ve put together the BackupPANNGFWConfig repo on GitHub which contains the scripts to get ahold of the API keys needed and then to perform the backups for a series of firewalls.
To get the scripts drop by the link below and for the configuration see the screenshot sequences in this post. You will need a basic understanding of Palo Alto Firewalls, PowerShell and Windows Server to work through these steps.
Super important note, this script is configured to use a TLS1.2 connection to the firewall as well as only allow connections to a firewall with a trusted security certificate – if you jump on the web management interface of the firewalls from the server that you are running the script from you should see the ‘secure’ padlock icon in the address bar.