AADSTS700016: Application with identifier <Entity ID> was not found in the directory ‘<Directory ID>’.
The fix here is easy – the GlobalProtect client injects a :443 at the end of the domain name which isn’t mentioned in the guide from Microsoft (https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/palo-alto-networks-globalprotect-tutorial) but is in the guide from Palo Alto Networks (https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008U48CAE).
Interestingly the Reply URL doesn’t specifically require it (although mentioned in the Palo Alto guide) but either way easy to fix.
You may find that when doing decryption on a Palo Alto Networks Next Generation Firewall that images in Slack channels are not displayed or are only shown in a very low resolution – in addition images cannot be uploaded. When inspecting the HTTP error messages in your browser a 503 response may also be seen.
To top off the issue you may also see that User-ID isn’t mapping traffic from the Slack desktop application against the traffic which negates any User-ID based decryption exception you might have.
While helpful the Slack connection test tool at https://my.slack.com/help/test also doesn’t appear to throw any errors.
To fix this issue you need a decryption exception custom URL rule for the files.slack.com domain (which fixes viewing images) along with the base domain for your Slack tenancy (fixes uploads). This domain can be found by clicking the drop down in the top left corner of the Slack client.
If you have multiple Slack tenancies then you will need an exception for each one.
As always when making exceptions for your decryption policy please consider how it might degrade your ability to detect malicious usage of the network – in this case the sharing of files with unknown payloads.
For more information about Slack network usage visit: https://slack.com/intl/en-gb/help/articles/360001603387-Manage-Slack-connection-issues.
It’s a bit of an odd situation but sometimes you might want to take information from a cloud service in this case Cortex XDR from Palo Alto Networks and drag it into an on premise logging service. This guide will have a look at how to get this log data in as well as parse it such that you can break out the individual fields in the log entry.
In looking at the documentation it appears that the logs are in the Comment Event Format (CEF) but are then wrapped up in syslog for transmission. Although Graylog can absorb CEF directly this additional layer of syslog means we have to take in the syslog and then send the event messages through a processing pipeline in Graylog to extract the CEF data.
So onto the guide – which assume you are familiar with the operation of the Cortex XDR management console and Graylog (shown version is 3.3), for simplicity the code snippet you’ll need is also shown below from GitHub.
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.