In this chapter, we will learn about advanced configuration features, such as site-to-site VPN and the challenges it poses when connecting to different vendors. We will learn how to set up a GlobalProtect VPN and verify whether hosts connecting remotely are in a permissible state to enter the network or need to be quarantined. We will create custom applications and custom threats and apply them to a policy, and we will review how zone protection and Denial of Service (DoS) protection can defend the network and individual resources from attackers.
In this chapter, we're going to cover the following main topics:
In this chapter, we will be covering remote connections and protection from inbound connections. If you have a lab environment where you can simulate setting up VPN connections to other devices or produce incoming connections from a client, this will help greatly in visualizing what is being explained.
There are several ways of connecting devices in a secure way. Palo Alto Networks firewalls currently support the following protocols:
To set up GRE tunnels, you can set up a connection in Networks | GRE Tunnels. All you need to configure is the following:
Set up the same configurations on the remote end to get it going. Routing and security are handled in security policies and the virtual router.
In the next section, we will set up IPSec connections and learn about the different ways to implement the configuration.
Before you can set up a VPN tunnel between two peers, you first need to agree on the cryptography settings that will need to be applied on both sides so that the tunnel can be negotiated. If the remote end is not under your control, you will need to reach out to your peer to agree on which configuration to use.
In the first phase (phase 1) of the negotiation, both peers authenticate one another through the Internet Key Exchange (IKE) process. Once the authentication has been established, an IPSec Security Association (SA) is created on both sides that contains all the parameters needed to set up the phase 2 IPSec VPN tunnel.
The phase 1 crypto profile can be created in Network | Network Profiles | IKE Crypto. As you can see in the following screenshot, there are three default profiles already present with the following settings:
The default profile represents the most common cryptographic scheme and should not be used unless the remote peer does not know which cryptographic profile is configured, or if the remote end is a legacy appliance with limited cryptographic capabilities.
The Suite-B profiles (already superseded by the CNSA suite) are NSA-recommended cryptographic settings. The latest recommendations can be found at https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm.
The Suite-B profiles contain good options and are recommended for most situations, but use your judgement and confer with the remote peer about which cryptographic options are best suited for phase 1.
If possible, use Suite-B-GCM-128 for small remote devices and Suite-B-GCM-256 for larger peers.
To add a new phase 1 profile, review the options in the following steps:
Important note
Ideally, review which settings are supported on both devices and pick a set that meets the highest possible security standards.
--DH Group 1: 768-bit group
--DH Group 2: 1024-bit group
--DH Group 5: 1536-bit group
--DH Group 14: 2048-bit group
--DH Group 19: 256-bit elliptic curve group
--DH Group 20: 384-bit elliptic curve group
--md5
--sha1
--sha256
--sha384
--sha512
--des
--3des
--aes-128-cbc
--aes-192-cbc
--aes-256-cbc
Important note
Do not use md5, sha1, des, or 3des unless you are required to connect to a legacy device that does not support more modern algorithms, as all of these options are easily defeated by modern cracking and decryption tools.
The phase 2 cryptographic profiles can be found in Network | Network Profiles | IPSec Crypto. As you can see, there are three pre-configured profiles that you can opt to use if they suit your needs:
The Encapsulating Security Payload (ESP) protocol provides full encryption of the payload, while Authentication Header (AH) just adds headers and guarantees the integrity of the payload, but does not encrypt or otherwise obfuscate the payload by itself.
To add a new phase 1 ESP profile, pick the strongest options available on both peers. If possible, use Suite-B-GCM-128 for small remote devices and Suite-B-GCM-256 for larger peers, or create a new profile with the following steps:
--des
--3des
--aes-128-cbc
--aes-192-cbc
--aes-256-cbc
--aes-128-ccm
--aes-128-gcm
--aes-256-gcm
--Null
--md5
--sha1
--sha256
--sha384
--sha512
--none
--DH Group 1: 768-bit group
--DH Group 2: 1024-bit group
--DH Group 5: 1536-bit group
--DH Group 14: 2048-bit group
--DH Group 19: 256-bit elliptic curve group
--DH Group 20: 384-bit elliptic curve group
--No pfs (Perfect Forward Secrecy)
Important note
Do not use des, 3des, md5, or sha1 unless you need to connect to a legacy system that does not support stronger algorithms.
The next thing we need to set up is the IKE Gateway, which can be found in Network | Network Profiles | IKE Gateways. The IKE Gateway represents the settings needed during phase 1. IKE phase 1 is the authentication phase where the peers verify each other's authenticity before moving on to creating a secure tunnel in phase 2. Follow these steps to create the IKE Gateway:
If the remote end only supports IKEv1, leave the default of IKEv1 only mode, which will skip attempting to negotiate IKEv2.
The IKE Gateway should look similar to the following screenshot:
If you selected Certificate as the Authentication method, the last few steps are a little different:
Important note
The Local and Peer identification can be filled out with any information the remote admin and you agree on whether a PSK is used, but in the case of certificates, this data is matched against the certificates and could cause issues if there are mismatches.
In the Advanced Options tab, follow these steps:
--Optionally, you can force the use of cookies by the initiator in IKE_SA_INIT by setting Strict Cookie Validation.
--Liveness Check will send an empty informational packet if no IKEv2 packet has been received (idle) for the amount of time specified and will function as a keepalive. After 10 liveness packets have been sent with no reply, the tunnel is broken down and needs to be reinitiated.
--Select the main mode if both sides use a static IP or aggressive if at least one side has a dynamic IP.
--If fragmentation is expected, put a checkmark in the Enable Fragmentation box.
--Review the parameters for Dead Peer Detection.
Before we set up the actual tunnel, make sure you have a tunnel interface available in Network | Interfaces | Tunnel. If needed, create a new one and make sure to set it to a unique zone, such as VPN, and add it to your virtual router. If you need to set up tunnel monitoring, or if the remote end requires numbered tunnel interfaces, you can add an IP address, but this is not required if the tunnel is set up between two Palo Alto Networks devices. If you are going to use tunnel monitoring, also enable a management profile that allows ping, as follows:
As shown in the following diagram, phase 1 is established between the physical (or loopback) interfaces of both peers and serves to carry IPSec phase 2. IPSec is established between the tunnel interfaces on both ends. Tunnel interfaces are virtual interfaces and should be treated as if there is a physical interface with a network connected to it, as well as be configured with its own zone.
In the security policy, note the following points:
To create the IPSec tunnel, go to Network | IPSec Tunnels and follow these steps:
--Set IPv4 or IPv6 for Address Type.
--Select the appropriate IKE Gateway.
--Select the IPSec crypto profile.
--Select Show Advanced Options.
--Select Enable Replay Protection.
--Type of Service (ToS) headers can be carried from the inner IP header to the outer IP header by enabling Copy ToS Header. You can transport a GRE tunnel inside the IPSec tunnel by selecting Add GRE Encapsulation, which will add a GRE header after the IPSec header.
--Enable Tunnel Monitor and set the remote tunnel interface IP for Destination IP. Add a monitoring profile to set an action if the tunnel fails – wait-recover will keep the tunnel interface up and will keep routing packets to it until the tunnel is restored. fail-over will bring the interface down and have routing take care of packets via an alternative route. Use fail-over if you set up a second tunnel; otherwise, use wait-recover.
Your tunnel configuration will look as in the following screenshot:
--In the Proxy IDs tab, add local to remote subnet pairs if the remote peer is policy-based.
--Set (IP) Portal Address.
--Select the external interface.
--Set the local IPv4 or IPv6 address.
--Open the Advanced Options tab.
--Either select Publish all static and connected routes to Gateway to share the entire routing table to the GlobalProtect gateway or manually configure the subnets to publish to the gateway.
--If you have an external device certificate for the firewall, select External Certificate Authority and set the certificate and matching certificate profile to authenticate against the gateway.
Important note
A policy-based firewall will create an IPSec tunnel based on subnet pairs as defined in a policy (subnet-A-local gets access to subnet-X-remote), whereas a routing-based firewall will simply create a tunnel and then route packets into it. The Palo Alto Networks firewall is route-based, so it will default to using a single tunnel for all communications. Proxy IDs force splitting the single configuration into multiple IPSec tunnels. Pro-tip: while having a single tunnel simplifies configuration, it may suffer from performance degradation due to how sessions are handled on the data plane and a single tunnel will be processed by a single CPU. Creating multiple tunnels through proxy IDs will spread the load over more cores.
The last step is to add routes that forward any packets destined for the remote subnet into the tunnel. In Network | Virtual Routers, open the virtual router that holds the tunnel interface. In Static Routes, add a new route:
To test connectivity and manually initiate the connection, you can use following commands to initiate phase 1 and phase 2, respectively:
> test vpn ike-sa gateway <IKEgateway>
> test vpn ipsec-sa tunnel <tunnel name>
The IKE SA first needs to succeed before the IPSec SA can be tested. You can follow the connection attempts through the system log while using the (subtype eq vpn) filter.
You can follow the actual process logs via the CLI to see how the tunnel is being negotiated and set up any errors or interesting information if the tunnel doesn't come up:
> tail follow yes mp-log ikemgr.log
> tail follow yes mp-log cryptod.log
Here is a checklist of the things you need to agree on with the remote peer:
Now that you have a firm understanding of how to set up a site-to-site VPN, we will move on to configuring GlobalProtect for a client VPN.
Using a site-to-site VPN is a very robust and secure method of connecting two systems, which is less appropriate and much harder to configure for endpoints such as laptops or mobile phones. To accommodate many different OSes and easier configuration options, GlobalProtect is available to provide connectivity to employees, contractors, and guests.
GlobalProtect is an SSL VPN client that also supports IPSec, which means that the VPN connection can tunnel over HTTPS, so the client will likely be able to connect from most locations where traditional IPSec may be blocked by a firewall or other filtering device. IPSec can be enabled and set as the preferred connection method with a fallback to SSL if IPSec is blocked.
Most of the GlobalProtect functionality does not require an additional license, but there are a few features that do the following:
There are two main components that need to be configured when setting up GlobalProtect:
You can have one portal per GlobalProtect deployment and as many gateways as needed. Gateways can be spread over strategic locations, so users always have an optimal connection to the corporate "backbone." Gateways can be deployed on physical or virtual appliances on-premises or in the cloud (such as with Azure, AWS, GCS, and so on) or as part of Prisma Access. An internal gateway can also be set up to function as a User-ID and HIP enforcement point for internal users to be able to access sensitive resources on the network.
To create a new Portal object, go to Network | GlobalProtect | Portals and follow these steps:
--If you have an IP to spare, I would recommend creating a loopback interface in the external/untrust zone.
--Use the Untrust interface to make the portal available on the internet.
--Use an internal interface to only provide portal services to internal or connected hosts (the latter means you will not be able to change critical information easily as users need to be logged in first before being able to get config updates when they are connected remotely).
Important note
Setting the portal on a loopback interface makes any packets carrying an exploit targeting the portal IP go through full threat prevention before actually hitting the interface. This should be considered best practice.
Move on to the Authentication tab:
--Set a descriptive name.
--You can select which client OS this authentication method will apply to. Set Any for everyone or set a specific OS if different OSes should log in using different profiles.
--Choose the authentication profile that will be used to authenticate users. You can create a new one from the dropdown.
--By default, users need to provide a username and password. If these are enabled (see the next step), provide a client certificate. You can set Allow Authentication with User Credentials OR Client Certificate to Yes so that users can log in with either their username/password or a client certificate.
--Click OK.
--Set a profile name.
--Set the Username field to Subject (common name) or Subject Alt (and select Email or Principal Name). Leave this as None if a generic (machine) certificate will be used, rather than a personalized one.
--Set NetBIOS Domain in Domain.
--Add the CA certificate that will sign the user certificates and add appropriate OCSP (Online Certificate Status Protocol) URLs.
--Click OK.
In the Portal Data Collection tab, you can have GlobalProtect collect the Windows registry key or MAC Plist entries. These values can be used to select which configuration is sent to the client. Collection can be configured as follows:
-- In the Trusted Root CA box, you can add CA and intermediary certificates if the portal and Gateway certificates are self-signed so that the client trusts the certificates. An SSL Decryption certificate can also be installed in the client's trusted root certificates by checking Install in Local Root Certificate Store
-- Agent User Override Key is the master key used in the ticketing process to allow users to disable an always-on GlobalProtect agent on their system. If left unchanged, the system will use the system's default key. You can choose to change this key for security reasons (the key used to sign tickets – administrators will not need to know the key).
Multiple agent configurations can be created for different users' types or client machines. The agent configs are processed top to bottom when a user connects, so make sure the more specific configs are placed at the top. Create a new profile as follows:
--The client certificate can be used to push a certificate and its private key to the client. This certificate can be used to authenticate against the gateways.
--The user credentials are saved by default in the GlobalProtect agent. Set this so that only the username can be saved, or so that the credentials can be saved if the user uses biometric authentication.
--Select Generate cookie for authentication override so that a (unique) cookie is generated and sent to the client by the portal after the user first logs in to the portal.
--Select Accept cookie for authentication override if the cookie will be used to authenticate, rather than the user credentials. Set an amount of time for which the cookie will be valid (maximum 365 days). Once the cookie expires, the user needs to provide credentials when logging into the portal and will receive a new cookie.
--If cookies are used, set the certificate that will be used to encrypt them.
--You can select which components (Portal, internal-gateway, the external gateways manual, or Autodiscover) will require Multi-Factor Authentication (MFA).
--In the User/User Group tab, a user or LDAP group and a client OS can be selected.
--In the Device Checks tab, you can set an action to check whether a machine account with a device serial exists or a machine certificate has been installed.
--In the Custom Checks tab, you can look for the registry key or Plist entries we set in the Portal Data Collection tab.
--Set the IPv4 and FQDN hostname of an internal resource to prevent internal hosts from setting up a VPN tunnel to the external gateways while inside the network (this can be any internal server or host or an internal gateway configured on the firewall).
--Set IPv6 and IPv6 enabled FQDN if IPv6 is used in the network.
--Add internal gateways by their IP or FQDN (this value will need to match the certificate used on the internal gateway). Source addresses can be added to control which subnets will connect to a specific internal gateway.
When multiple gateways exist, the GlobalProtect agent will poll (through a TLS handshake) all of them to see which ones provide the optimal connection speed. The cut-off time is the time allowed for a gateway to reply:
--Add a gateway and give it a descriptive name. This name will be visible to the user, so it should help them understand where their connection is being made to.
--Add the FQDN or IP the connection that will be made to. This should match the certificate that will be used on the Gateway object.
--Add a source region. This can be Any or any country, subnet, or global region.
--Set a priority: from lowest to highest or manual user selection only. The priority has an inferior value compared to the result of the responsiveness poll – the highest, high, and medium priority items will be polled and if none in that priority are available, the agent will move to the lower priority items.
--Check the Manual box if the user is permitted to select this gateway as a preferred connection.
--Click OK.
In the App tab, we can configure how the GlobalProtect agent will behave. On the right-hand side, you can do the following:
On the left-hand side, you can configure how the agent behaves. I'll highlight the options that may need to be changed from the default or that are of interest:
--If this option is set, also set Captive Portal Exception Timeout to allow users to authenticate to a captive portal if they are at a hotel or airport before network access is blocked.
--Edit Traffic Blocking Notification Message so that users are made aware when traffic is being blocked due to GlobalProtect not being connected.
HKEY_LOCAL_MACHINESOFTWAREPaloAlto NetworksGlobalProtectPanSetup with the Portal key.
/Library/Preferences/com.paloaltonetworks.GlobalProtect.pansetup.plist with the Portal key
In the HIP Data Collection tab, you can select whether to collect HIP data or not. If a GlobalProtect license has been purchased, each GlobalProtect agent on Windows or macOS will send a HIP report about running processes, patch levels, and so on to the gateway when they connect, and periodically afterward. You can exclude several categories and vendor products from being collected, or add custom checks to Windows and macOS hosts for specific registry entries to be present or processes to be running.
Set the certificate profile to verify the machine certificate sent by the GlobalProtect agent.
Once you've reviewed HIP checks, click OK to complete the agent configuration.
In the Clientless VPN tab, you can create a portal interface that allows users to connect to a web page and have access to internal applications without needing to set up a full tunnel. It works by populating the Portal page with tiles that lead to application interfaces:
--Set the FQDN or IP of the portal.
--Set the security zone. This will be the source zone for outgoing proxied connections from the firewall to the application.
--Select a DNS Proxy object. Create one if you don't have one yet; it does not need to be attached to an interface for it to work with Clientless VPN.
--Change Login Lifetime and Inactivity Timeout if the defaults (3 hours and 30 minutes, respectively) are not suitable.
--In Max Users, select the maximum number of concurrent users. The default is 10.
--Click on Add to create a new application-to-user mapping and give it a friendly name.
--Display application URL address bar lets a user to input custom URLs, which the Clientless VPN will proxy for them. Disable this option unless your users are allowed to browse the internet via Clientless VPN.
--If an application should only be visible to a specific user or user group, click on Add and select the users(s) or group(s) you want it to be visible to.
--In Applications, click on Add and select an application, or create a new clientless app:
a) When creating a new clientless app, set a name so that the user will be able to identify the application.
b) Set an appropriate URL for the application.
c) Add a description with additional details.
d) Optionally, upload an icon for the Clientless App tile.
e) Click OK.
--Create additional applications as needed.
--Set Min Version to TLSv1.2.
--Disable SHA1 as this is no longer considered a secure algorithm. It should only be used if there is no alternative available to communicate with the remote peer.
--Enable all the server certificate verifications unless some internal certificates are known to be problematic.
--Click on Add and set a descriptive name.
--Add the domains that need/don't need to be proxied, one per line.
--Check or uncheck the Use Proxy box.
--Fill out the proxy IP or FQDN, port, and credentials details.
--Click OK and add additional proxy server settings as needed.
In the following screenshot, you can see what the GlobalProtect portal looks like with some clientless applications and the application URL enabled. The GlobalProtect agent can be downloaded from here as well:
In the Satellite tab, you can configure firewall appliances that will use a simplified VPN to connect to the organization. This is an ideal solution if, for example, several smaller firewalls are being used to set up pop-up locations or operate a booth at conventions to quickly set up, and break down shortly after the VPN tunnels, so the remote team has access through an actual firewall for additional security over the GlobalProtect agent. Larger or static sites will benefit most from a traditional VPN connection. Follow these steps to create a satellite group:
--In General, set a descriptive name and review Config Refresh Interval. This sets the cadence for how frequently satellites check whether there is a new connection configuration available.
--In the Devices tab, add devices by their serial number and set a descriptive name for each device.
--In the Enrollment User/User Group tab, you can add users or groups of users that are allowed to manually enroll devices. If a new device is set up in the field and the serial number has not been communicated for it to auto-enroll, the admin will be prompted to manually enroll, at which time their username or group membership must match the one you set here.
--In the Gateways tab, configure which gateways the satellite will connect to and what their routing priority will be. As opposed to GlobalProtect agents, which connect to the fastest or highest priority gateway, satellites connect to all the gateways you configure and use routing priority to direct traffic.
--Click OK.
Now that the portal is configured, you can start adding the internal and external gateways.
Gateways are where the connections that the agents connect to are. Each firewall can have multiple gateways, but they can't share an IP address, so if multiple gateways are needed, they will each require a unique IP. A portal and a gateway can share the same IP.
Important note
Gateways cannot coexist with an HTTPS-enabled management profile (never set a management profile that hosts services on an external or untrusted interface). In these cases, you should enable the management profile on a loopback interface and use port address translation; so, for example, port 4443 is translated to 443 on the loopback interface.
To create a new gateway, go to Network | GlobalProtect | Gateways and follow these steps:
--Use the same SSL/TLS service profile as the portal if you reuse the same FQDN or have the certificate set to an IP. If you want to use a different FQDN, import or generate the appropriate certificate and create a new SSL/TLS service profile.
--To use client certificates, set Certificate Profile.
--Create a new client authentication profile, set a descriptive name, and select the appropriate authentication profile. You can use the same profile as the portal or create a new one that leverages MFA for added security. Review whether you need credentials and a client certificate, or credentials or client certificate.
In the Agent tab, several considerations can be made that will alter the user experience:
--Tunnel mode must be enabled for external gateways. On an internal gateway, you can leave Tunnel mode disabled if you intend to use the gateway for HIP and authentication only. If Tunnel mode is enabled, the agent will set up a tunnel even when inside the network for added security.
--Select a tunnel interface. This interface can be created in Network | Interfaces | Tunnel and does not require an IP address, but it does need to be set in the appropriate virtual router and in a different security zone than the local network. Check the box next to Enable User-ID in the zone configuration.
--Leave Max Users empty to allow the maximum number that your platform supports.
--Unchecking Enable IPSec will force the use of SSL/TLS. If IPSec is checked but is unavailable from the agent's location, the fallback protocol is SSL/TLS.
--Create a new GlobalProtect IPSec Crypto profile from the dropdown that uses a GCM cipher (the default uses aes-128-cbc).
--The Enable X-Auth support option enables third-party VPN clients that support X-Auth to connect to a gateway. Enable this if you want to connect OpenVPN, for example. Set Group Name and Group Password. You can force the user to need to re-authenticate when the IPSec key expires by unchecking Skip Auth on IKE Rekey.
--Click on Add and set a descriptive name.
--Select the source user, host OS, region, or source addresses that should apply to the intended users. Otherwise, leave this all as Any if all users should fall into this profile.
--In the Authentication Override tab, select whether an override cookie should be generated, whether it should be accepted, and the amount of time the cookie should be valid for, and then select the encrypt/decrypt certificate for the cookie. It should be signed by the trusted root certificate associated with the portal and gateway certificates.
--In the IP Pools tab, you can set regular IP pools, which will be assigned from top to bottom; or, you can enable Retrieve Framed-IP-Address attribute from authentication server if your authentication server supports the Framed-IP-Address attribute so that clients are assigned a static IP address when they log in. Authentication Server IP Pool needs to be large enough to support all users as these are static assignments that are not cleared after a user logs off.
--In the Split Tunnels tab, you can configure which route sessions should take. If left blank, all sessions will be sent over the tunnel. Direct access to the user's home network (or hotel, airport, coffee shop, and so on) can be disabled by checking No direct access to local network:
a) Subnets added to the Include field will cause the GlobalProtect agent to only route sessions destined for these subnets over the VPN tunnel.
b) Subnets added to the Exclude field will not be sent over the tunnel.
c) Include and Exclude domains and their associated ports can be used to control which FQDNs are or are not sent over the tunnel. This feature requires a license.
d) Include and exclude Client Application Process Name lets you control which running processes will be forced to send all their traffic over the tunnel or are disallowed from using the tunnel. This feature also requires a license.
In the Network Services tab, you can add DNS servers and DNS suffixes assigned to the clients.
--Login Lifetime sets the maximum amount of time a user is allowed to be connected continuously.
--Inactivity Logout disconnects the user after no HIP report is received for the set amount of time. If no HIP checks are enabled, this timer is ignored.
--Disconnect On Idle interrupts the connection when no packets have been received over the VPN tunnel for the set amount of time.
The Disable Automatic Restoration of SSL VPN option will prevent automatic reconnection after the connection is interrupted for any reason, requiring the user to manually reconnect. This option will prevent always-on mode from working.
Restrict Authentication Cookies lets you set limitations to the authentication override by restricting the cookie to only work on the original source IP or the subnet that the cookie was created for (if the user shifts to a different IP or subnet, the cookie will no longer work for authentication override and the user will need to reauthenticate).
--Click on Add and select the HIP profile or the HIP profile to match (see the following bullet points).
--If a match needs to be reported to the user, set Enable Match Message and set a system tray balloon or pop-up message and type the text that needs to be displayed to the user.
--If a required check was not detected (not-match) and this event needs to be reported to the user, set Enable Not Match Message and set a system tray balloon or pop-up message and type the text that needs to be displayed to the user.
In the Tunnel Settings tab, set Enable Tunnel Configuration and set a tunnel interface. Since these will be branch offices, you should use a different tunnel interface, with an IP assigned, and a different security zone than the one that the regular gateway is using. The tunnel monitoring settings are the IP addresses that the remote gateways will use to monitor connectivity and fail over to a different gateway if monitoring fails. Set this to the tunnel IP.
In the Network settings tab, DNS settings and DNS suffixes can be set, or an inheritance source can be set. The IP pool will be used to assign an IP to the remote tunnel interface. Access routes let the remote peer set routes into the tunnel to reach the main site's network. Leave this blank to send everything into the tunnel.
In the Route Filter tab, you can enable Accept published routes to install routes advertised by the satellites into the virtual router. To prevent overlaps with local subnets, you can add subnets that will be accepted this way into the Permitted Subnets field.
You now have a fully functional gateway that your users can start connecting to. If you want to perform HIP checks, here's how to set those up.
HIP checks verify whether the agent's host OS lives up to the standards set forth by your organization. Remember that a license is required to perform these checks on your hosts.
Before we begin, verify that the GlobalProtect fata file is being downloaded periodically in Device | Dynamic Updates. This will ensure that the firewall has current information on vendor patch levels and software versions.
You can create HIP objects in Objects | GlobalProtect | HIP Objects.
A HIP object would typically cover one type of device for manageability, as there may be managed Windows and macOS laptops, company-owned mobile devices, and BYOD devices. All of these will have different characteristics. Follow these steps to build a basic HIP object:
In HIP Profiles, you can combine HIP objects through AND, OR, and NOT conditions, which allows you to build a set of conditions that apply to many devices. Once you add these conditions to GlobalProtect or the security policy security controls can be applied to users meeting, or failing, said checks.
A HIP profile could, for example, be set as follows:
("corp-laptop" or "corp-mobile") and not "byod"
This can be done to include all the corporate devices, but not the private ones.
To create security rules that leverage HIP profiles, do the following:
You can set the HIP dropdown to no-hip if this rule does not require HIP information to be available from the client, which allows third-party VPN clients to access resources, while any will allow any device. Create the rule as follows:
You can also set a HIP match for Quarantine, which will include any devices that the administrator has manually added to quarantine by adding the device through Device | Device Quarantine or by manually selecting it in a traffic or threat log, or any devices that were added to quarantine automatically by matching a security rule with a log forwarding profile that has a quarantine action set, as shown in the following screenshot:
A rule base for HIP-enabled clients could look something as in the following screenshot. Each rule is for the same zone, user, and IP pool, but the HIP matches are different for each rule, so they will apply to different source devices:
Important note
By default, agents send a HIP update every hour. This interval can only be changed from the CLI with the following commands:
> debug global-protect portal interval <60-86400>
> configure
# commit
# exit
> debug global-protect portal show
You are now able to set up a complex GlobalProtect environment. In the next section, we'll learn how to create custom applications.
Every once in a while, an application may not be known. This could be due to it being a new application that has not been used much in the wild or could be something a developer created in-house for which it is not reasonable to expect there to be signatures to identify the session. In these cases, it is possible to create custom applications that use custom signatures and can trigger an App-ID to positively identify the previously unknown application.
The need for a custom application usually starts with the discovery of an abnormality in the traffic log. In the following screenshot, I have discovered my solar power converter, and an IoT device is communicating with its home server over an unknown-tcp connection:
There are two ways to address this issue:
Let's take a look at the easiest solution first.
Implementing an app override is "quick and dirty;" it forcibly replaces the application identification process with a custom application. The advantage is that you simply set a few simple parameters and you are done. The drawback is that there is no granularity, there is room for mistakes, and most importantly, if you set a custom application, the security profiles will no longer apply to the sessions (packets will no longer be scanned for threats and malware).
Important note
Setting a predefined application could help "fix" an otherwise broken App-ID process if the data flow is somehow different than what would normally be expected from the application, causing the regular App-ID to fail. This will only work if the application flow exactly matches the application being set in the override, with the rare condition of some key packets being out of order. I wouldn't recommend this as a fix-all, but keep it in your pocket for a rainy day.
The first step is to create a custom app that will be used to identify the session. Create a new application in Objects | Applications as follows:
--Category: business-system
--Subcategory: management
--Technology: client-server
We'll leave all the characteristics blank as this is a friendly app, calling home to report on my solar gains.
--Set Port to TCP/22221-22222.
--I'll leave all the Timeouts settings blank to indicate that I wish to use the system default timeouts for TCP.
--There's an option for scanning File Types, Viruses, and Data Patterns, but this will only work if there is no override in place, so I will leave these blank for now as well.
The application now looks as in the following screenshot:
To create the override, go to Policies | Application Override and create a new override policy:
The override rule will look as in the following screenshot:
Once the changes are committed, you should start seeing the sessions show up as a different application in your session table and traffic log, as you can see in the following screenshot:
While this is a great solution for simple applications, especially internal ones where you have control over the endpoints and can leverage host-based security to make up for the lack of scanning capabilities on the TCP flow, it is better to use signature-based identification and let the App-ID and Content-ID fully scan the flow.
Don't forget to disable the application override policy before moving on to the next section.
Identifying applications based on a signature or signatures provides far more accuracy when identifying custom sessions. Any sessions that do not match the signatures you set to identify the traffic will still be identified as unknown, which should either be blocked or raise an alarm if you have accounted for all possible signatures.
We first need to do some research into the application we want to identify before we can create custom signatures. Packet captures provide the best information for this.
To set up a basic packet capture, go to Monitor | Packet Capture and click on Manage Filters.
In the Packet Capture Filters , you can add up to four lines that tell your system what you want to capture, based on Ingress Interface, Source IP or Port, Destination IP, or Port and Protocol Number. You can also opt to include, exclude or exclusively capture non-IP protocols, which is helpful if you're trying to capture DHCP. So, for example, in my case, we'd do the following:
--Receive captures packets on the incoming interface.
--Transmit captures packets on the outgoing interface.
--Drop captures packets that are being discarded.
--Firewall captures packets while they are being processed.
For this exercise, we will use the firewall stage and call the file solar.pcap.
Enable capturing by switching the Packet Capture toggle to ON.
Once packets have been captured, the file will appear in Captured Files, where you can click on the file to download it. Wait a sufficient amount of time, and then if possible, restart the session. Once enough data is collected, click on the file and open it with Wireshark to start looking for signatures.
In my case, I discovered that my solar converter will always sign in using the same fingerprint, as you can see in the Data field of the fourth packet in the following screenshot:
We can now add this to the custom application we created earlier. Go to Objects | Applications and open the custom application (solar). In the Signatures tab, click on Add:
I'll set my scope to Transaction, since the fingerprint identification happens in the fourth packet and we don't need the signature engine to keep analyzing after it identifies the fingerprint.
--Set Operator to Pattern Match.
--The context for this signature is unknown-req-tcp-payload as there is no decoder that claimed this session (unknown-tcp). Many different contexts are available depending on the decoder that picks up on a session. If the custom app is a sub-application to web-browsing, for example, the context could be http-req-host-header.
--Set the pattern. To match ASCII, just add the ASCII text in the field, and to match the hexadecimal value, you must enclose the hex between two x tokens, which lets the signature engine know that this is a hexadecimal value.
--We'll use x123456792200ddx to match the fingerprint, which meets the 7-byte minimum for a custom signature.
--Some contexts can have qualifiers that filter where a string can be matched (for example, for http-req-host-header, you could add the http-method qualifier with the GET value).
The custom application will now look as in the following screenshot:
Once you commit this, you should start seeing the sessions being picked up as the custom application.
A few notes on creating signatures:
The following characters can be used as wildcards in a RegEx string:
An outdated but still usable list of all contexts and qualifiers can be found at this Palo Alto Networks Knowledgebase document:
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClOFCA0
You can now analyze packets to find identifiable patterns and apply them to signatures of custom applications. You can apply this same knowledge to custom threats!
If you need to take a more complex approach to a certain data pattern than allowing or blocking through a simple App-ID-driven security rule, you can also create custom threats that can block or reset a client or server or both, or block the IP of an attacker if a specific pattern is detected in a session.
You can create either a custom vulnerability or custom spyware. Both profiles have the same options but fall into different security profiles and reporting categories.
We will build a custom vulnerability, but the process for creating custom spyware is identical.
In Objects | Custom Objects | Vulnerability, create a custom vulnerability by following these steps:
Let's set an ID of 41000 and give it the name BlockBrowser.
The Configuration tab should look as in the following screenshot:
In the Signatures tab, we can add the patterns as we did before with custom applications, but there are two signature types:
We've already covered how to identify the payload, so let's create a standard signature and block Firefox as a browser.
As shown in the following screenshot, if you packet capture a web-browsing session from a regular browser, it will advertise its User-Agent, which is the software used to retrieve the web page. We can use this information in a signature to prevent certain browsers from accessing web pages:
Add the details learned from the packet capture to the custom threat:
--Set Operator to Pattern Match.
--Set Context to http-req-headers.
--Set Pattern to Firefox/.
--Add a qualifier and set it to http-method with a value of POST.
If you want to add multiple User-Agents, you can add more OR conditions, each matching a different browser type:
--Set Operator to Pattern Match.
--Set Context to http-req-headers.
--Set Pattern to Chrome/.
--Add a qualifier and set it to http-method with a value of POST.
The Signature tab should look as follows:
Once this new vulnerability is committed, you will start to see it show up in the threat logs once someone uses a Firefox browser.
Important note
SSL decryption needs to be enabled for patterns to be matched in encrypted payloads or headers.
Pay close attention to the action, as it may differ from the one we set in the custom vulnerability itself. This is because for high- and critical-severity threats, we usually set an action that replaces all the default actions. If the custom threat action differs from the Security Profile settings, add an exception, as shown in the following screenshot.
To add an exception, open the profile where the action needs to be changed:
You can now use the information you find in a packet capture to create custom applications or custom threats depending on your needs. In the next section, we're going to protect our network from floods and other low-level attacks.
While layer 7 threats generally revolve around stealing data, blackmailing users through sophisticated phishing, or infecting hosts with complex and expensive zero-day vulnerabilities, protecting the network layer against DoS and other attacks is equally important. Protecting the system and the network is achieved in three different ways:
The system-wide settings are, unfortunately, not all neatly sorted in one place. I'll go over the most important ones.
A good deal of the global session-related settings can be accessed through the Device | Setup | Session tab. In the Session settings, you can control several nice features such as Jumbo Frames, IPv6, and accelerated aging. An important setting here that should be enabled is Packet Buffer Protection. The firewall has buffers to process traffic while it is coming in and may need to rely on these buffers when CPU usage is high or a session requires extra attention. Attack methods exist that try to exploit such buffers and could cause DoS conditions if they manage to flood the buffer. Packet Buffer Protection will keep track of these sessions and discard them if their abuse threatens legitimate sessions:
Enable Packet Buffer Protection in each security zone individually.
From the CLI, you can check whether Packet Buffer Protection has been engaged:
> show session packet-buffer-protection
You can also check which zones have been enabled:
> show session packet-buffer-protection zones
In TCP Settings, all protections are enabled by default, but some may need to be disabled (temporarily) to fix an issue. Most commonly, Asymmetric Path, which refers to TCP packets arriving out of the window or containing out-of-sync ACK, is useful for troubleshooting. Packets dropped by this protection would show up as follows:
> show counter global filter category tcp | match out_of
tcp_out_of_syncz 0 0 warn tcp pktproc can't continue tcp reassembly because it is out of sync
tcp_drop_out_of_wnd 0 0 warn tcp resource out-of-window packets dropped
The TCP settings can be verified by running the following command in the CLI:
> show running tcp state
In the following screenshot, you can see the default values, which in most cases should be sufficient:
The Session Setup configuration can only be checked and changed from the CLI:
> show session info
------------------------------------------------------
Session setup
TCP - reject non-SYN first packet: True
Hardware session offloading: True
Hardware UDP session offloading: True
IPv6 firewalling: True
Strict TCP/IP checksum: True
Strict TCP RST sequence: True
Reject TCP small initial window: False
Reject TCP SYN with different seq/options: True
ICMP Unreachable Packet Rate: 200 pps
------------------------------------------------------
TCP – reject non-SYN prevents ACK packets from getting through without first having received an SYN packet to initiate a session.
There's an operational command and a configuration command to change this setting:
> set session tcp-reject-non-syn yes|no
# set deviceconfig setting session tcp-reject-non-syn yes|no
Strict TCP/IP checksum requires the checksum header to be accurate and unaltered; otherwise, a corrupted checksum will be discarded.
This setting can only be controlled through an operational command:
> set session strict-checksum yes|no
Strict TCP RST sequence will only accept an RST packet if it has a sequence number that matches the session's flow. RST packets with a mismatching sequence number will be discarded (this could be used to inject reset packets in an attempt to provoke a DoS). This protection can only be controlled through an operational command:
> set session tcp-strict-rst yes|no
Reject TCP small initial window is disabled by default, but lets you set a discard option for SYN packets where the Window size value in the TCP header is lower than the value you set:
> set session tcp-reject-small-initial-window-enable yes|no
> set session tcp-reject-small-initial-window-threshold <0-1024>
Reject TCP SYN with different seq/options blocks duplicate SYN packets with different sequence numbers or options:
> set session tcp-reject-diff-syn yes|no
Now that we've covered the system settings, let's move on to protecting zones.
Zone protection does exactly what its name states: protects a zone. This means that each zone needs to be enabled individually and different settings may apply to different zones. It is important that you have a good understanding of what traffic volumes are to be expected and where the limits of your infrastructure lie for you to be able to set certain flood protections so that they function efficiently. You may want to perform an audit before enabling zone protection. You can create new zone protection profiles by going to Network | Network Profiles | Zone Protection and following these steps:
--Alarm rate is when a log entry is created, alerting the admin that a threshold has been reached. This will be a critical log entry in the threat log, as we can see in the screenshot at the end of this list.
--Activate is the rate at which Random Early Drop (RED) will start randomly discarding packets. This should ideally start happening at a higher rate than what is normal for your network in the appointed zone.
--Maximum is the upper limit of the connections/seconds the system will accept. Anything over this limit will be discarded. The maximum is also used to calculate the progressive rate at which RED discards packets; the closer the connections/seconds get to the limit, the more packets get discarded.
The Flood Protection tab should look as in the following screenshot. Make sure to baseline your network before applying aggressive protection. If no tools or services are available, try setting Alarm Rate fairly low and monitor your threat log. Gradually increase the alarm rate until you stop receiving alarms, which should be your peak. At this point, you can set your activate rate for RED and make an educated estimate of where the maximum should be:
In the Reconnaissance Protection tab, we can set protection against discovery scans directed at hosts to find out what services are running, or the entire network to map the environment. In the following screenshot, you can see the three types of scans that can be intercepted:
A source address exclusion can be set in case a known server, such as a PRTG or Nmap server, needs to be able to perform scans for legitimate reasons.
For all scans, the threshold and interval indicate the number of events detected in a certain amount of time, before the action is applied to the source. Actions include allow, which disables the scan protection, alert, which simply logs detected scans, block, which drops new packets that match the type of scan after the threshold was reached, and block-ip, which adds the IP to a block list and, depending on whether Track By is set to source or source-and-destination, will block packets from the source or all packets from the source to the destination, regardless of whether the packets are directly associated with the detected scan:
In the Packet Based Attack Protection tab, we find several sub-tabs with a couple of important protection mechanisms. As the following screenshot shows, in the IP Drop tab, we will find the following options:
As you can see in the following screenshot, in the TCP Drop tab, we can protect against TCP-based malformations or irregularities that could be abused to gain access or exploit systems:
As you can see in the following screenshot, all the ICMP and ICMPv6 options are disabled by default. Because ICMP is commonly used for troubleshooting, most options may be desirable from a support perspective. ICMP settings can only be set to discard packets, while any options checked in ICMPv6 can be overruled by adding explicit security rules that allow the options:
As you can see in the following screenshot, by default, all routing headers, except type 3, 253, and 254, are dropped in IPv6 Drop:
In the Protocol Protection tab, you can add other protocols outside of IPv4, IPv6, ARP, and VLAN-tagged frames by their hex ethertype value. You can find a list of protocols and their hex ethertype at http://standards-oui.ieee.org/ethertype/eth.txt.
As you can see in the following screenshot, this section is fairly straightforward; we can add several different protocols, but we need to choose whether we set this to be an include or exclude list:
In Ethernet SGT Protection, you can add Cisco TrustSec Security Group Tags (SGTs). If an incoming packet has an 802.1Q header that contains an SGT that matches one of the tags in the list, the packet will be dropped.
To enable zone protection, go to Network | Zones and add a zone protection profile to all the zones by selecting the appropriate one from the dropdown. Make sure to also enable Packet Buffer Protection.
Now that we've set up protection for our zones, we can add protection for specific resources by setting up DoS profiles and creating a DoS protection policy.
A DoS protection profile is similar to zone protection, but it applies resource limitations at a smaller scale. A server may have limited resources and could be easily flooded by a focused attack leveraging a volume of traffic much lower than what the zone protection profile permits. New profiles can be created in Objects | Security Profiles | DoS Protection.
As you can see from the following screenshot, the DoS profiles are simpler than zone protection. There are two types:
There are only two tabs:
To apply these profiles to a resource, create a new rule in Policies | DoS Protection:
Add the service ports that need to be protected.
Select the action:
--Deny will block all sessions matching the rule.
--Allow will allow and not protect all sessions matching the rule.
--Protect will apply DoS profiles to all sessions matching the rule.
--Deny and Allow can be used to create exceptions above a more generic Protect rule.
--Set a schedule if the rule should only be active at certain moments.
--Set the appropriate Log Forwarding profile if alarm settings need to translate into an email being sent or a syslog sent out to a SIEM. If you created a default log forwarding profile, it will be added automatically.
--Select the appropriate Aggregate profile.
--If more granular protection is needed, check Classified and select the classified profile.
Set the Address classification as source-ip-only, destination-ip-only, or src-dest-ip-both.
Important note
Address classification takes up resources to keep track of sessions. You should be careful or defer using source-ip-only or destination-ip-only for internet facing protection rules.
Your rule should look similar to the following screenshot:
With this information, you are now able to protect your network and individual servers from getting flooded. (Disclaimer: there's only so much a firewall can do. If the ISP uplink is physically flooded, only alternative paths can make resources available to the outside. The firewall's job is to contain the attack to one zone while all other zones can continue working.)
In this chapter, you learned how to set up site-to-site VPN tunnels and a client-to-site VPN with GlobalProtect. You can now not only provide connectivity but also scan the client machine for compliancy and know how to control the user experience. We've also learned how to create custom applications and custom threats that will allow you to identify packets unique to your environment and take affirmative action, and we've learned how to set up zone and DoS protection to defend against all kinds of packet-based attacks.
In the next chapter, we will be getting our hands on some basic troubleshooting. We will learn about session details and how to interpret what is happening to a session.
44.192.53.34