Palo Alto Networks
In recently deploying the Captive Portal feature of a Palo Alto Networks Next Generation Firewall (NGFW) in testing we were finding Apple Macs take 120+ seconds to load the sign-in page. First thoughts jumped to the Apple Captive Network Assistance (CNA) feature not functioning correctly however this appeared to be a dead end. Some time and a few packet captures later showed that the Mac wasn’t even trying to reach out to the Captive Portal in a timely manner, after much head scratching the customer I was working with suggested that their Sophos Endpoint agent (Intercept X) might be the cause of this problem.
Disabling the agent didn’t seem to resolve the issue however uninstalling it did – the Captive Portal page appeared nearly instantly. In reviewing the packet captures again it was clear the Sophos agent was trying to reach out to a reputation service which was being blocked by the authentication profile on the firewall, it just took a really long time for the agent to stop trying and allow access to the Captive Portal.
To work around this issue the domains listed in the link below were added to an authentication bypass policy on the NGFW, with this in place the Captive Portal loaded promptly. If anything it makes sense to allow unauthenticated access to such services (including Windows Update and the likes) to ensure a client has the ability to update itself regardless of authentication status.
After a few years on hold it’s great to be back at CITC this time in the British Motor Museum. The video presentation covers a short (if speedy) introduction to Node-RED and it’s ability to integrate systems through their APIs.
Demo 2 is of note and shows how a user visiting a malicious website can have their internet access revoked until a helpdesk agent has a chance to clean-up their machine and then grant access again without even having to login to the firewall controlling that access.
A little treat that I hope will help someone at some point, for those with Palo Alto Networks Next Generation Firewalls (NGFW) and Aruba Instant Wi-Fi you can forward syslog messages from the controller to the NGFW and parse them with the profile below to map users to IP addresses.
There is plenty of information on syslog to User-ID at this link for those just getting started: https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/monitoring/use-syslog-for-monitoring/configure-syslog-monitoring.html.
The text strings you will need are:
- User authenticated
- username-([a-zA-Z0-9\_\.\@]+)
- IP-([A-F0-9a-f:.]+)
When setting up a GlobalProtect Portal/Gateway with AzureAD you may find you receive the error message:
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.
XML: The returned XML does not match the expected schema. (code: PE233) — JSON: The returned JSON does not match the expected structure (Invalid JSON.). (code: PE231)The cause is the default encoding from PowerShell is UCS-2 LE BOM as shown in Notepad++ below.
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.
If you are looking to build out Zone Protection Profiles on your Palo Alto Networks Next Generation Firewall then it can be handy to know just what your connections per second metrics look over time for each zone. Quite lucky Palo Alto Networks have a little (although not entirely descript) guide on where you can get this data – https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/zone-protection-and-dos-protection/zone-defense/take-baseline-cps-measurements-for-setting-flood-thresholds/how-to-measure-cps.html.
With that information in hand it was just a matter of time before working out how to collect this data through PRTG so do follow on with the screenshot guide to find out how!
Handy strings:
1.3.6.1.4.1.25461.2.1.2.3.10
[rowidentifier] Connections Per Second
TCP
UDP
Other IP
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.
https://github.com/jamesfed/BackupPANNGFWConfig
Has this page helped you? Was it worth the cost of a Coffee? If so click here to donate £4.00 to the myworldofit.net coffee fund via PayPal.