Category: Security

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.

Fortigate VIP Configured and Deny Policy Not Functioning

In a situation where you have a VIP configured to perform Destination NAT for traffic incoming from the Internet to an internal server, and you have a policy “above” the allow policy to the VIP in precedence, you will notice that by default the “above” policy isn’t functioning as expected when traffic is destined to the VIP.

This is extremely frustrating and isn’t how any other firewall i’ve worked on functions, but what happens is that the VIP translation is hit earlier on in the packet processing on the Fortigate so the policy that references the VIP gets used even if it is farther down in precedence than say a geo-filtering policy blocking all incoming traffic (allegedly to all hosts) from China.

That means that even though you think you have policies denying traffic above your VIP rules that it won’t matter. This is very concerning and probably needs to be addressed by Fortinet. Unless you really investigate logs to confirm that the deny rule above your VIP rule is getting used, this may go missed for a while.

The below link from Fortinet describes the problem in more detail and discusses possible solutions.

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

The key is that you can add the “set match-vip enable” line to the “above” policy config to make sure that even if a VIP is a destination, that this deny rule gets used instead of the permit rules that the VIP is associated with. Alternatively, you can use the VIP in the “above” deny rule explicitly as the destination. 

 config firewall policy 
 edit 36 
 set match-vip enable