Palo Alto User-ID and WinRM

Background: In the past, when using the agentless method of User-ID with a Palo Alto firewall, WMI was used for the firewall to connect to a domain controller and parse Windows security logs to find user to IP mappings. However, on June 14, 2022, Microsoft released patch KB5004442 for Windows Server to address the vulnerability described in CVE-2021-26414. This patch essentially breaks the WMI connection from the firewall to the server. This is described well here: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000wkkfCAA

The new solution is to enable WinRM to be used in place of WMI. This process is very well documented so I won’t go into detail here, but I did want to mention that I had to add the service account used for this into the “Remote Management” group in Active Directory or else it wouldn’t work properly and would show “Access Denied” for the server. The below links are helpful in configuring this and only one of them has the Remote Management Group mentioned.

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/user-id/map-ip-addresses-to-users/create-a-dedicated-service-account-for-the-user-id-agent

        https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000001VUICA2&lang=en_US%E2%80%A9

        https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/user-id/map-ip-addresses-to-users/configure-server-monitoring-using-winrm

  

Sophos XG Virtual Firewall – VMware vSwitch Configuration

I recently setup the Sophos firewall as a VM in VMware ESXi 8. Sophos offers this for free for home users with limitations around how much memory and CPUs can be used.

When deploying this, or really any other virtual firewall in VMware, there are a few things to consider. First, just like a physical firewall appliance, you’ll want at least a minimum of two physical ethernet ports on the VMware host. This will allow you to use a traditional “inside” and “outside” interface. Next, if your VMware host has multiple ethernet ports, it is worth identifying what those ports are ahead of time before deploying the VM. This can be done by plugging in each cable on the physical host and checking what port lights up in the VMware console under the Network Management settings. Make a note of which ports they are.

Before deploying the VM, you can prepare the network settings in VMware for this. You’ll want to have two separate virtual switches, each associated with their own physical ethernet port. I created one vswitch for “inside” and another for “outside”. Next, I created two ports groups, also one for inside and outside and attached them to the appropriate virtual switch.

Here are the virtual switches:

Here are the Port Groups:

Now, when deploying the VM, add two network adapters and assign one to the inside port group and the other to the outside port group.

Use Palo Alto API and Script to Pull Automated Backup Config Files

Palo Alto has put out a helpful article on this topic, but I wanted to add a few additional details. This is necessary when you don’t have Panorama or some other 3rd party tool that doesn’t already have an integrated solution for pulling backup configs from the firewall.

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Cm7yCAC

As the article above mentions, the first step is to generate the API key using this format in a browser. Record and maintain this API key once generated.

https://<firewall-ip>/api/?type=keygen&user=<username>&password=<password>

Next, if you are using a Windows machine, download Curl here: https://curl.se/windows/

I extracted this then took the contents and put it in a folder named “Curl” in the C:\ directory. Next, I created a folder for the backup configs named “FirewallBackups” also in the C:\ directory.

Next, I created the following Batch script below. Replace 192.168.1.1 with the firewall management IP and the actual API key. Also, you can change the directory where the backups are stored as well as the filename.

cd c:\Curl\bin\
curl -kG "https://192.168.1.1/api/?type=export&category=configuration&key=API-KEY-HERE" > c:\FirewallBackups\PaloAltoFilename-01_Backup%DATE:~10,4%_%DATE:~4,2%_%DATE:~7,2%_%TIME:~0,2%_%TIME:~3,2%.xml

In this script, it is switching to the directory where the Curl executable is. You can also follow instructions to add Curl to the system path so it runs without having to switch to that specific directory. At the end of the filename, this script will automatically insert the timestamp to differentiate file names and prevent the file from being overwritten each time the backup runs. The formatting around this is necessary because the timestamp by default has the “:” symbol in it which isn’t supported in the Windows filename so it replaces that with “_” instead.

Finally, you can schedule this Batch script to run on a schedule basis using the Windows Scheduler or a third party tool.

Fortigate SNMP VPN Tunnel Listing and Monitoring

This article describes how to list all VPN tunnels using SNMP and monitor the status of individual tunnels.

This shows all VPN tunnel names and their corresponding OIDs to then be able to monitor:


snmpwalk -v2c -c string_here 198.18.254.1 1.3.6.1.4.1.12356.101.12.2.2.1.3

This will monitor one of the VPNs determined from the first output:

snmpwalk -v2c -c Hotlips1 198.18.254.1 1.3.6.1.4.1.12356.101.12.2.2.1.3.2.1

For Interface Monitoring, you’ll need to retrieve the SNMP index number matching the actual interface you want to monitor. Run these commands to see the index numbers and match with the interface:

“config system interface”

“show”

Then take the index number and use this base OID:

.1.3.6.1.2.1.2.2.1.8

That will show all of them, pick the interface with the index you want to monitor.

For example, to monitor interface with index 6 use:

.1.3.6.1.2.1.2.2.1.8.6

Display FortiGate Policy Name or Comments in FortiAnalyzer Logs

By default, the FortiGate does not send the Policy Name or Comments from the policies in logs to FortiAnalyzer or any remote logging server. This makes troubleshooting more difficult.

You must turn this setting on manually from the Fortigate CLI:

config log setting 
set log-policy-comment enable
set log-policy-name enable 
end

Temporarily Add Denied Sessions to Session Table to Reduce Resource Utilization and Log Generation

This is an interesting feature available through the Fortigate CLI that I came across.

Below are the commands to enable denied session to be added into the session table:


#config system settings #set ses-denied-traffic enable
#end

For optimum performance, adjust the global block-session-timer:

#config system global 
#set block-session-timer <1-300>  (default = <30>)#end

Here is a link to the Fortinet knowledge base with a good description of what this is:

https://kb.fortinet.com/kb/documentLink.do?externalID=FD46328

Aruba Clearpass and Juniper Switch Integration for 802.1X Authentication and Access List Mapping

This article from Juniper does a fantastic job of explaining Clearpass and Juniper Switch integration so I won’t recreate the wheel here, but I wanted to share one caveat that I experienced with this:

https://www.juniper.net/documentation/en_US/release-independent/nce/information-products/pathway-pages/nce/nce-157-aruba-dot1x-mac-configuring.pdf

Here is an example of the Juniper switch filters or Access Control Lists. Notice that the “IT-Admin” name is just the role that Clearpass sends over to the switch once Clearpass completes the role mapping process for a user authentication.

set firewall family ethernet-switching filter IT-Admin term Block_Internal_Server from destination-address 198.18.255.75/32
set firewall family ethernet-switching filter IT-Admin term Block_Internal_Server then discard
set firewall family ethernet-switching filter IT-Admin term Allow_All then accept
set firewall family ethernet-switching filter SonyLaptop term Block_Internal_Server from destination-address 8.8.4.4/32
set firewall family ethernet-switching filter SonyLaptop term Block_Internal_Server then discard
set firewall family ethernet-switching filter SonyLaptop term Allow_All then accept

The only issue I saw was when testing this was when I had created my service, role mappings, etc in Clearpass with a new role, but had not yet created this matching filter/ACL on the Juniper switch side. So, what would happen is Clearpass would show the user authentication and the correct role mapped, but the user wouldn’t have access. I wrongly assumed that the Juniper would assign a default role so that essentially no filter/ACL would match and the user would simply be allowed full access, but that was not the case. Without a specific filter/ACL for that role sent from Clearpass, the user will not have access.

Use Palo Alto Networks Remote Access VPN on Mobile Devices Without Global Protect License or App

It is possible to use the remote access VPN capabilities of a Palo Alto firewall without having a Global Protect license or Global Protect agent (app) on your mobile device. I do want to mention that you get additional capabilities by having the Global Protect license and app such as TAC support, detailed information about the endpoint connecting to the VPN, split tunneling, NAC-type functionality by profiling and enforcing compliance profiles, and more.

This is helpful if you have just a handful of mobile devices where you want the ability to have remote access VPN.

Here is what the configuration looks like to enable this. First you must enable IPSec along with X-Auth support under the Gateway Client Configuration. You set the Group Name and Password and configure the rest of GlobalProtect like you normally would.

On the iOS or Mobile VPN client settings, create a new VPN configuration and use the IPsec/Cisco tab to configure the necessary settings. IPsec and X-Auth must be enabled. The group password field in the Palo Alto is the equivalent of the “secret” field on the iOS VPN client configuration.

This will also work with the native VPN agent on macOS.

Initial Setup Script for FortiAnalyzer/FortiManager

The FortiAnalyzer and FortiManager Admin Guides provides great information, but one thing i’ve found it lacking is a concise, quick method of giving a VM a new management IP address through the console so you can manage it through the GUI.

Admin Guide: https://docs.fortinet.com/document/fortianalyzer/6.2.0/administration-guide/

Here is a quick script you can use for the initial setup after the VM is deployed to get a new management IP setup, default route set, and management protocols enabled:

config system interface
edit port1
set ip 10.10.10.10 255.255.255.0
set allowaccess https ssh
end
config system route
edit 1
set dst 0.0.0.0 0.0.0.0
set device port1
set gateway 10.10.10.1
end

Now you should be able to access FortiAnalyzer or Manager using the GUI with https://10.10.10.10

Use OpenSSL to Convert a PEM Certificate File and a Private Key to PKCS#12 (.pfx .p12) Format

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

* Note: In this case, the certificate file after “-in” is the actual server certificate and the cert file after “-certfile” is the bundled file that you would get from a CA.

* If this is a self-signed cert, leave out the “-certfile” section since there will not be an intermediary or root CA.