z: VPN and Advanced Protection

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:

  • Site-to-site VPN
  • The GlobalProtect client and satellite VPN
  • Custom applications and application override
  • Custom threat signatures
  • Zone protection and DoS protection

Technical requirements

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.

Setting up the VPN

There are several ways of connecting devices in a secure way. Palo Alto Networks firewalls currently support the following protocols:

  • Generic Routing Encapsulation (GRE) is a fairly old protocol that is not very secure but can be useful if legacy devices need to be connected to the firewall to provide rudimentary security to the encapsulated packets.
  • Internet Protocol Security (IPSec) is the de facto tunneling protocol between remote sites and can be used for very strong encryption.
  • Secure Socket Layer (SSL), which is really Transport Layer Security (TLS), is used to connect endpoints over a network-friendly protocol.

To set up GRE tunnels, you can set up a connection in Networks | GRE Tunnels. All you need to configure is the following:

  • Name
  • Source interface
  • Source IP
  • Destination IP
  • Tunnel interface
  • TTL (default 64)
  • Keepalive

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.

Configuring the IPSec site-to-site VPN

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:

Figure 10.1 – IKE crypto profiles

Figure 10.1 – IKE crypto profiles

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.

  1. Click on Add and name the profile so that you can easily identify it.
  2. Set DH group:

    --DH Group 1: 768-bit group

    --DH Group 2: 1024-bit group

    --DH Group 5: 1536-bit group

    --DH Group 142048-bit group

    --DH Group 19256-bit elliptic curve group

    --DH Group 20: 384-bit elliptic curve group

  3. Set Authentication:

    --md5

    --sha1

    --sha256

    --sha384

    --sha512

  4. Set Encryption:

    --des

    --3des

    --aes-128-cbc

    --aes-192-cbc

    --aes-256-cbc

  5. Set Key Lifetime in hours (8 is the industry default).
  6. IKEv2 Authentication Multiple lets you set the number of IKEv2 re-keys that are allowed before the gateway is forced to start a fresh authentication. This will hinder snooping efforts.
  7. Click OK.

    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:

Figure 10.2 – IPSec crypto profiles

Figure 10.2 – IPSec crypto profiles

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:

  1. Click on Add and name the profile so that you can easily identify it.
  2. Set the IPSec protocol to ESP or AH.
  3. Set Encryption:

    --des

    --3des

    --aes-128-cbc

    --aes-192-cbc

    --aes-256-cbc

    --aes-128-ccm

    --aes-128-gcm

    --aes-256-gcm

    --Null

  4. Set Authentication:

    --md5

    --sha1

    --sha256

    --sha384

    --sha512

    --none

  5. Set DH group:

    --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)

  6. Set Lifetime in hours (1 is the industry default).
  7. Optionally, enable Lifesize, which triggers a re-key if a certain amount of data has been transmitted.
  8. Click OK.

    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:

  1. Click on Add and set a descriptive name for the peer you will be connecting to.
  2. Set Version to IKEv2 only mode, or IKEv2 preferred mode if you're not sure whether the remote end supports IKEv2.

    If the remote end only supports IKEv1, leave the default of IKEv1 only mode, which will skip attempting to negotiate IKEv2.

  3. Choose whether you'll set up a tunnel between IPv4 or IPv6 nodes.
  4. Select the physical interface that will be maintaining the connection to the remote end (this could be a loopback interface as well).
  5. Set Local IP Address.
  6. Select whether the peer has a static IP or a resolvable FQDN, or whether it is a dynamic IP host.
  7. Set Peer Address by adding an IP or FQDN (if the peer is dynamic, this field disappears).
  8. Select Pre-Shared Key or Certificate for Authentication.
  9. Type in and confirm the Pre-Shared Key (PSK).
  10. Optionally, you can agree with the peer to use FQDN, the IP address, the key ID, or the user FQDN (an email address) as an additional form of identification during the handshake.

    The IKE Gateway should look similar to the following screenshot:

    Figure 10.3 – IKE Gateway

    Figure 10.3 – IKE Gateway

  11. Go to Advanced Options.

If you selected Certificate as the Authentication method, the last few steps are a little different:

  1. Select Local Certificate. If it hasn't been uploaded or generated yet, you can do so from the dropdown.
  2. You can optionally set HTTP Certificate Exchange to use the hash-and-URL exchange method to let the peer know where to fetch the certificate from.
  3. Select Distinguished Name, FQDN, IP, or User FQDN for Local and Peer Identification and set a matching value for the Local and remote peer.
  4. For Peer ID Check, set Exact if Peer Identification must exactly match the peer certificate and Wildcard if the identification is a subdomain or the certificate is a wildcard certificate.
  5. Optionally, if the data used in the identification does not match that of the certificate, select Permit peer identification and certificate payload identification mismatch.
  6. Add or create the certificate profile that supports the local certificate.
  7. Go to Advanced Options.

    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:

  1. Set Enable Passive Mode if the local device should only receive inbound connections and not attempt to connect to the remote peer. This can help preserve the bandwidth or prevent unsuccessful connection attempts if the remote peer goes offline regularly or has a dynamic IP that is prone to change.
  2. Set Enable NAT Traversal if either side is behind a NAT device that is not itself.
  3. Set IKE Crypto Profile.
  4. In the IKEv2 tab, set the following:

    --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.

  5. In IKEv1, if this tab is available, set the following:

    --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.

  6. Click OK.
  7. The Advanced Options settings should now look similar to the following screenshot:
Figure 10.4 –  The IKE Gateway advanced settings

Figure 10.4 – The IKE Gateway advanced settings

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:

Figure 10.5 – Tunnel interface

Figure 10.5 – Tunnel interface

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:

  • Connections from the client will be established between the trust zone and the VPN zone.
  • The IPSec tunnel will require a security rule that is established from the Untrust zone to the Untrust zone (from the external interface out to the internet):
Figure 10.6 – A VPN tunnel from the firewall's perspective

Figure 10.6 – A VPN tunnel from the firewall's perspective

To create the IPSec tunnel, go to Network | IPSec Tunnels and follow these steps:

  1. Click on Add and provide a descriptive name.
  2. Set the appropriate tunnel interface.
  3. For Type, you can have the firewall create the SPI automatically, set it manually, or set the tunnel for GlobalProtect Satellite.
  4. If you select Auto Key, set the following:

    --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:

    Figure 10.7 – IPSec tunnel configuration

    Figure 10.7 – IPSec tunnel configuration

    --In the Proxy IDs tab, add local to remote subnet pairs if the remote peer is policy-based.

  5. In Manual Key, you get to set all the phase 1 and phase 2 parameters for a single IPSec tunnel. This works well with a route-based peer but could become troublesome with a policy-based peer as multiple manual IPSec tunnels will need to be created.
  6. In GlobalProtect Satellite, set the following:

    --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.

  7. Click OK.

    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:

  1. Give it a descriptive name.
  2. Set the Destination subnet.
  3. Select the tunnel interface for Interface.
  4. Next Hop can either be None to simply route packets into the tunnel or the remote tunnel IP, which some systems may require.
  5. Change Admin Distance and Metric if needed.
  6. Click OK.
  7. Commit your changes.
  8. The route should look similar to the following screenshot:
Figure 10.8 – A static route into a tunnel

Figure 10.8 – A static route into a tunnel

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:

  • For phase 1, which encryption authentication, Diffie-Hellman group and key lifetime will be used.
  • For phase 2, whether you will set up ESP or AH. If you choose ESP, which encryption algorithm will be used, and if you choose if AH, which authentication will be used, which Diffie-Hellman group, and how long should the lifetime be?
  • Does the remote peer support IKEv2?
  • What is the remote peer IP or FQDN, or is the host on a dynamic IP?
  • Will you use a PSK or a certificate to establish phase 1 authentication?
  • Is either host behind a NAT device?
  • Does the remote end support replay protection?

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.

Configuring GlobalProtect

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:

  • Perform Host Information Profile (HIP) checks
  • Support GlobalProtect on mobile endpoints (such as Android, iOS, Chrome OS, and Windows UWP) and Linux
  • IPv6 support for external gateways
  • Split tunnel based on destination domains, the client process, or the streaming application
  • Clientless VPN

There are two main components that need to be configured when setting up GlobalProtect:

  • Portal, which provides clients with a download portal to get the client package, provides configuration to the agents once installed, and provides a Clientless VPN.
  • Gateway, which is the where the agent connects to establish a secure connection.

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.

Setting up the portal

To create a new Portal object, go to Network | GlobalProtect | Portals and follow these steps:

  1. Click on Add.
  2. In the General tab, set a name for the portal.
  3. Select the interface that the portal will be listening on:

    --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.

  4. Select IPv4, IPv6, or IPv4 and IPv6.
  5. In the appearance dropdowns, you can choose to use the default page, upload a custom page, or disable the landing page entirely (when disabled, the agent will be able to fetch the configuration, but no page is displayed if someone connects using a browser).
  6. In Log settings, keep Log Unsuccessful SSL Handshake enabled.

Move on to the Authentication tab:

  1. You need to provide an SSL/TLS service profile that serves the certificate that will be used for the portal. Ensure the certificate matches the FQDN that is used for the portal (for example, portal.example.com) and has been imported in Device | Certificate Management | Certificates, then create a new service profile. Set Min. version to TLSv1.2
  2. Create a new client authentication:

    --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.

  3. If you want clients to use a client certificate when connecting, create a certificate profile:

    --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:

  1. Set the certificate profile that will be used to match the machine certificate used by the GlobalProtect agent.
  2. Add the registry/Plist keys that need to be registered.
  3. In the Agent tab, you can control the configuration sent to the Agent so that it can establish a connection.

    -- 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:

  1. Click on Add to create a new config.
  2. In the Authentication tab, set a descriptive name:

    --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).

  3. In the Config Selection Criteria tab, you configure which user/user group or type of endpoint device this configuration will apply to:

    --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.

  4. In the Internal tab, we can set Internal Host Detection for IPv4 and IPv6 and Internal Gateways for HIP checking:

    --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.

  5. In the External tab, external gateways can be added, as well as a third-party VPN.

    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:

  • Enable a welcome page that pops up every time a user connects.
  • If users are normally not allowed to disable GlobalProtect but an exceptional event could require some users to disable their agent, a password can be set here to share with users.
  • A password can also be set for users to be able to uninstall GlobalProtect.
  • A Mobile Device Manager (MDM) can be set to enroll mobile devices connecting through GlobalProtect.

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:

  1. Connect Mode is set to user-logon (always on) by default and can be changed to On-demand, which lets the user decide when to connect, or Pre-logon, which establishes a connection using the machine certificate before the user logs on to their desktop environment
  2. Allow User to Disable GlobalProtect is set to Allow. Change this to Allow with Comment, Allow with Passcode, or Allow with Ticket (or Disallow altogether). Allow with Ticket requires users to call in and get a challenge response by an admin that can run Generate Ticket in Network | GlobalProtect | Portals.
  3. Windows users can be prevented from uninstalling GlobalProtect or required to enter a password before being able to uninstall.
  4. Allow User to Upgrade GlobalProtect App will prompt the user by default. This can be set to Disallow, Allow Manually, Allow Transparently, or Internal. Both Allow Transparently and Internal will update the agent automatically, but Internal will only perform the upgrade when the user is on the corporate network.
  5. Set Allow users to Sign Out from GlobalProtect to No if users are not permitted to disable GlobalProtect.
  6. Enforce GlobalProtect Connection for Network Access disables all network access if GlobalProtect is not connected to an internal or external gateway (no exceptions need to be set for the gateway IPs or FQDNs):

    --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.

  7. Enable Advanced View can be set to No if users should have a simplified experience.
  8. Allow user to change Portal Address can be set to No if the user is not allowed the option to change the portal address, which could be used to enter portal information to a different organization. The drawback is that the portal address will need to be pushed (via Global Policy Objects (GPO), for example) to the clients:

    HKEY_LOCAL_MACHINESOFTWAREPaloAlto NetworksGlobalProtectPanSetup with the Portal key.

    /Library/Preferences/com.paloaltonetworks.GlobalProtect.pansetup.plist with the Portal key

  9. Set Allow User to Continue with Invalid Portal Server Certificate to No.
  10. You can keep the tunnel connected for a specified amount of time by setting a timeout in Preserver Tunnel on User Logoff.
  11. Connect with SSL Only forces the use of SSL for this agent configuration profile, even if IPSec is enabled on the gateway (leave this as No).

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:

  1. In General, enable Clientless VPN:

    --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.

  2. In the Applications tab, you can select the clientless applications that are available to users. You can either create these individually in Network | GlobalProtect | Clientless Apps and then create Clientless Apps groups in Network | GlobalProtect | Clientless App Groups or you can create apps directly with the following steps:

    --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.

  3. In the Crypto Settings tab, you can control the security of the outbound connections from the firewall to the applications:

    --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.

  4. In the Proxy tab, additional proxy servers can be configured if the outbound connections need to pass through a proxy server. Proxy rules can be configured for specific domains and processed from top to bottom, so put the most specific ones at the top:

    --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.

  5. In the Advanced Settings, you can add exclusions for any applications that have a sub-page that should not be accessed through the portal. Paths are not supported, however.

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:

Figure 10.9 – Clientless VPN-enabled GlobalProtect portal

Figure 10.9 – Clientless VPN-enabled GlobalProtect portal

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:

  1. Click on Add to add a new 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.

  2. Click Ok to complete the portal configuration.

Now that the portal is configured, you can start adding the internal and external gateways.

Setting up the gateway

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:

  1. Click on Add and provide a descriptive name.
  2. Select the appropriate interface and select IPv4, IPv6, or IPv4 and IPv6 and set the IP. Just like the portal part, it is good practice to set the gateway on a loopback interface.
  3. In the Authentication tab, set the following:

    --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:

  1. In the Tunnel Settings tab, set the following:

    --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.

  2. In the Client settings tab, you can control how the gateway interacts with a subset of users, the host OS, or the region. Skip this step if split tunneling is not required:

    --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.

  3. The Client IP Pool tab holds the global IP pool for all users connecting to the gateway. Multiple pools can be added, both IPv4 and IPv6. IP addresses are assigned from the top pool first; once this is depleted, the next pool will be used, and so on. The IP pools will automatically be added to the virtual router that the tunnel interface belongs to.
  4. In the Network Services tab, you can control which DNS and WINS servers the agent receives when a connection is established, and the DNS suffixes relevant to your organization. If a dynamic or DHCP client interface exists, this can be set as an inheritable source for DNS and WINS information to be passed along to GlobalProtect agents.
  5. In the Connection Settings tab, set the following:

    --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).

  6. In the Video Traffic tab, you can force video applications to use the local internet breakout instead of the tunnel to conserve bandwidth. Any video streaming service that is not allowed should not be excluded and is instead blocked on the firewall by the security policy. This feature requires a license.
  7. In the HIP Notifications tab, you can create profiles containing HIP objects or HIP profiles and their User Notification settings:

    --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.

  8. In the Satellite tab, you can configure the tunnel settings for Satellite firewalls.

    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.

  9. Click OK.

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 objects and profiles

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:

  1. Click on Add and set a descriptive name.
  2. In the General tab, provide all relevant host information, such as the OS version, the GlobalProtect client version, the domain, and for mobile devices, which WIFI network or carrier they are connected to.
  3. In the Mobile Device tab, you can enable this profile for mobile devices and set parameters for the types and models of the device, the phone number, and the IMEI number. You can have HIP verify whether the passcode is enabled, the mobile device is jailbroken, disk encryption is enabled, and whether certain applications are installed.
  4. In the Patch Management tab, you can set detection for missing patches by severity level and different vendors. These patch signatures are included in the Dynamic Updates package.
  5. In the Firewall tab, you can enable detection if the firewall software is installed and enabled.
  6. In the Anti-Malware tab, you can enable detection for installed antivirus or anti-malware software and see whether real-time scanning is enabled, check the minimum virus definitions and the product version, and see when the last scan took place.
  7. In the Disk Backup tab, you can enable detection for backup software and see when the last backup was run.
  8. In the Disk Encryption tab, you can enable detection for encryption software and see whether certain locations have been encrypted.
  9. In the Data Loss Prevention tab, you can enable detection for data loss software and see whether it is enabled.
  10. In the Certificate tab, you can verify whether the certificates used by GlobalProtect have specific attributes set.
  11. In the Custom Checks tab, you can add checks for running processes and registry or Plist keys.

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:

  1. Create a new security rule and set a descriptive name.
  2. In the Source tab, set the GlobalProtect security zone and create and set a user IP pool object.
  3. In the User tab, set the user group and the HIP profiles to apply this rule to. Only devices matching the HIP objects in the profile will match this rule.

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:

  1. In the Destination tab, set an appropriate destination, such as to the DMZ servers or other internal resources.
  2. Add appropriate applications in the Application tab.
  3. Set services or the destination URL categories in the Service/URL Category tab.
  4. Set the action, threat profiles, and logging settings in the Actions tab.
  5. Click OK.

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:

Figure 10.10 – Automated quarantine

Figure 10.10 – Automated quarantine

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:

Figure 10.11 – HIP-enabled security rules

Figure 10.11 – HIP-enabled security rules

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.

Custom applications and threats

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:

Figure 10.12 – An unknown-tcp application in the traffic log

Figure 10.12 – An unknown-tcp application in the traffic log

There are two ways to address this issue:

  • Implement an application override that forcibly sets all these sessions to a specific application.
  • Create a custom application using signatures to positively identify these sessions, and still perform security scans on the sessions.

Let's take a look at the easiest solution first.

Application override

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:

  1. Click on Add and set a descriptive name for the new application. In this case, we will call the application Solar.
  2. In the Configuration tab, set the Properties and Characteristics settings. For my solar converter, we'll set the following:

    --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.

  3. In the Advanced tab, you can select to use TCP and UDP ports by checking the Port radio button, or select an IP Protocol, ICMP Type, ICMPv6 Type, or None. In the Port settings you can add tcp/ or udp/ followed by a port number (such as tcp/88), port range (such as udp/50-100) or dynamic (such as tcp/dynamic) for dynamically assigned ports . We will set the following:

    --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.

  4. We do not need the Signatures tab right now, so we can click OK.

The application now looks as in the following screenshot:

Figure 10.13 – A custom application

Figure 10.13 – A custom application

To create the override, go to Policies | Application Override and create a new override policy:

  1. Click on Add and set a descriptive name.
  2. In the Source tab, we'll set the source zone to LAN and the source IP to 192.168.27.113 for my solar converter.
  3. In the Destination tab, we can set the destination zone to outside and the IP addresses associated with my converter's cloud interface.
  4. In the Protocol/Application tab, set the destination ports to tcp 22221-22222 and the solar custom application that we created earlier.
  5. Click OK and Commit.

The override rule will look as in the following screenshot:

Figure 10.14 – Application override rule

Figure 10.14 – Application override rule

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:

Figure 10.15 – The session identified as a custom application

Figure 10.15 – The session identified as a custom application

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.

Signature-based custom applications

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:

  1. Click on Add and set the filter ID to 1.
  2. Select Source and set the IP of my solar converter, 192.168.27.113.
  3. Set the destination port to 22221.
  4. Click on Add and set the filter ID to 2.
  5. Select Source and set the IP of my solar converter, 192.168.27.113.
  6. Set the destination port to 22222.
  7. Click OK.
  8. Enable filtering by setting the Filtering toggle to ON.
  9. Then, configure capturing by doing the following:
  10. Click on Add.
  11. Set a capture stage:

    --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.

  12. Click OK.

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:

Figure 10.16 – Packet capture in Wireshark

Figure 10.16 – Packet capture in Wireshark

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:

  1. Set a descriptive signature name.
  2. Set the scope. Transaction is used to match a signature in a single packet and Session is used to match signatures across multiple packets.

    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.

  3. Ordered Condition Match requires multiple conditions to be matched in order from top to bottom. With this option unchecked, they can be matched in any order. We'll keep it unchecked as there is only one signature.
  4. Add an OR condition:

    --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).

  5. Click OK twice.

The custom application will now look as in the following screenshot:

Figure 10.17 – Custom application with a signature

Figure 10.17 – Custom application with a signature

Once you commit this, you should start seeing the sessions being picked up as the custom application.

A few notes on creating signatures:

  • A signature pattern must contain at least a 7-byte string with fixed values.
  • Enclose hexadecimal strings in x.
  • Be mindful of upper- and lowercase letters in ASCII. You may need to include a signature for both if there could be instances where one is used versus the other (for example, GOOGLE.COM versus google.com).
  • Outside of the 7-byte string, you can add Regular Expressions (RegEx) to match more complex patterns.

The following characters can be used as wildcards in a RegEx string:

Figure 10.18 – RegEx wildcard characters

Figure 10.18 – RegEx wildcard characters

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!

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:

  1. Click Add.
  2. In the Configuration tab, you need to set a threat ID and a descriptive name. All threats are identified by their ID, and a window from 41000 to 45000 is reserved for custom threats (1500018000 for custom spyware).

    Let's set an ID of 41000 and give it the name BlockBrowser.

  3. Set the severity. If your vulnerability profile has a specific action other than default for the severity, that action will be applied unless you create an exception in the profile. Let's set high.
  4. For Direction, you can set whether this vulnerability should only match if the packet is traveling in a specific direction – from client to server or from server to client – or if it can be detected in both directions. We will set client2server.
  5. Define a default action. Set Reset Client.
  6. Affected System is the only unique setting to vulnerabilities that is not also found in spyware; it indicates who is involved with a certain signature. As we're going to capture outgoing browsing sessions, we'll set this to client.
  7. If there's any CVE, vendor bug ID, or Bugtraq information you'd like to add for completeness, there are fields available to add this information.

The Configuration tab should look as in the following screenshot:

Figure 10.19 – Custom Vulnerability Signature

Figure 10.19 – Custom Vulnerability Signature

In the Signatures tab, we can add the patterns as we did before with custom applications, but there are two signature types:

  • Standard is the same type of pattern match as the custom application.
  • Combination adds a timing attribute that lets you define a number of hits over a specified amount of time, and the aggregation criteria (hits from the source, destination, or the source to the destination are counted). This can help identify brute-force conditions where one or two signature matches in a timeframe could be normal, but five is suspicious. Combination can only be applied to predefined vulnerability IDs.

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:

Figure 10.20 – A packet capture web session from Firefox

Figure 10.20 – A packet capture web session from Firefox

Add the details learned from the packet capture to the custom threat:

  1. In the BlockBrowser custom threat's Signature tab, click on Add and set a name, Firefox.
  2. Set Scope to Transaction.
  3. Add an OR condition:

    --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.

  4. Click OK.

If you want to add multiple User-Agents, you can add more OR conditions, each matching a different browser type:

  1. Add an OR condition:

    --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.

  2. Click OK twice.

The Signature tab should look as follows:

Figure 10.21 – Custom Vulnerability Signature

Figure 10.21 – Custom Vulnerability Signature

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:

  1. In the Exceptions tab, type the threat ID into the search field.
  2. Check the Show All Signatures box at the bottom.
  3. Check the Enable box to activate the override for this signature.
  4. Make sure the action is set to default:
Figure 10.22 – Adding a custom vulnerability to the exceptions

Figure 10.22 – Adding a custom vulnerability to the exceptions

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.

Zone protection and DoS protection

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:

  • System-wide settings that defend against maliciously crafted packets or attempts at evasion through manipulation
  • Zone protection to protect the whole network against an onslaught of packets intended to bring the network to its knees
  • DoS protection to more granularly protect resources from being overwhelmed

The system-wide settings are, unfortunately, not all neatly sorted in one place. I'll go over the most important ones.

System protection settings

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:

  • Activate is the level of buffer usage where the protection will start monitoring sessions that are heavily taxing the buffers and discard the session if needed.
  • Block Hold Time is the amount of time a session is granted to act abusively in case it is expected behavior of passing nature.
  • Block Duration is the amount of time the blocked IP will be blocked for if the behavior lasts longer than the block hold time.

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:

Figure 10.23 – The Session and TCP settings

Figure 10.23 – The Session and TCP settings

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.

Configuring zone protection

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:

  1. Click on Add and set a descriptive name.
  2. In the Flood Protection tab, we can enable protection for UDP, ICMP, ICMPv6, and Other IP. There are three settings per protocol:

    --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.

  3. SYN has one additional setting, called Action, where RED can be switched to SYN cookies instead. When SYN cookies are enabled, the firewall does not add SYN queue entries and it discards the SYN packet instead, but it does reply with an SYN/ACK containing a particular sequence number that allows it to reconstruct the original SYN if the client is able to reply with an appropriate ACK to the sequence number. This prevents the SYN queue from getting flooded (as no entries are added). When SYN cookies are used, it is fine to set activate at 0. When the maximum is reached, all excess SYN packets will still be dropped:
Figure 10.24 – Flood alert logs

Figure 10.24 – Flood alert logs

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:

Figure 10.25 – Flood protection

Figure 10.25 – Flood protection

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:

  • TCP Port Scan detects TCP connections on many different ports to a single destination from a single source.
  • UDP Port Scan detects UDP connections on many different ports to a single destination from a single source.
  • Host Sweep detects whether a single source is making many connections to many destinations.

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:

Figure 10.26 – Reconnaissance protection

Figure 10.26 – Reconnaissance protection

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:

  • Spoofed IP address will look up the routing table and will only accept packets that are ingressing on an interface that has a route associated with the source IP.
  • Strict IP Address Check checks that an IP is not the broadcast IP of a subnet and the source IP is routable over the source interface.
  • Fragmented Traffic lets you drop fragmented packets (handle this with care as some links may need fragmentation due to MTU (Maximum Transmission Units) restrictions).
  • Strict Source Routing and Loose Source Routing are the datagram header options that allow the sender to set the route a packet should take.
  • Timestamp prevents the sender from requesting timestamps from any machine processing the packet.
  • Record Route is an IP header that lets the sender collect the IP from every host processing the packet.
  • Security and Stream ID, with IP options 2 and 8, respectively, can also be blocked.
  • Unknown is the packets that have an unknown class or number.
  • Malformed is the packets with inconsistent combinations of their length, class, and number (based on RFCs 791, 1108, 1393, and 2113):
Figure 10.27 – IP drop packet-based attack protection

Figure 10.27 – IP drop packet-based attack protection

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:

  • Mismatched overlapping TCP segment blocks packets that are using an incorrect sequence number and could have been injected into a flow.
  • Split Handshake prevents TCP handshakes that have been fragmented or split over more than three packets.
  • TCP SYN with Data and TCP SYNACK with Data block SYN and SYNACK packets that contain data, since these packets should only be used to establish a handshake and not to transport data.
  • Reject Non-SYN TCP and Asymmetric Path are normally set globally but can be set differently per zone to accommodate some zones needing either of these TCP anomalies without compromising the other zones by changing the global setting.
  • The TCP Timestamp option should be stripped from the TCP header to prevent timestamp DoS attacks.
  • The TCP Fast Open option can be stripped. If this check is left disabled (the default), SYN or SYNACK data will be allowed for the purpose of TCP Fast Open, even if TCP SYN with Data and TCP SYNACK with Data are set to blocking.
  • Multipath TCP (MPTCP Options) can also be left as the global setting or controlled per zone to allow exceptions to the global setting as some zones may need to support multipath:
Figure 10.28 – TCP drop packet-based attack protection

Figure 10.28 – TCP drop packet-based attack protection

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:

Figure 10.29 – Default ICMP drop settings

Figure 10.29 – Default ICMP drop settings

As you can see in the following screenshot, by default, all routing headers, except type 3, 253, and 254, are dropped in IPv6 Drop:

Figure 10.30 – IPv6 drop options

Figure 10.30 – IPv6 drop options

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:

  • Exclude List will drop all the protocols listed. As the following screenshot shows, an ethertype of 0x890d would be blocked while all the other protocols would be allowed.
  • Include List allows only the protocols listed in addition to IPv4, IPv6, ARP, and VLAN-tagged frames. All other protocols will be dropped:
Figure 10.31 – Protocol Protection

Figure 10.31 – Protocol Protection

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.

Configuring DoS protection

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:

  • The Aggregate profiles count the total number of connections matching the rule and profile.
  • The Classified profiles count individual sessions based on the source, the destination, or the source and destination.

There are only two tabs:

  • Flood Protection contains all the same settings as the Flood Protection tab in the Zone Protection profile, but someone decided to break it up into smaller topical tabs. The only difference is the addition of Block Duration, which will be used in the DoS protection policy.
  • Resource Protection, which can be enabled to limit the maximum number of concurrent sessions to a resource:
Figure 10.32 – The Aggregate and Classified DoS protection profiles

Figure 10.32 – The Aggregate and Classified DoS protection profiles

To apply these profiles to a resource, create a new rule in Policies | DoS Protection:

  1. Click on Add and set a descriptive name.
  2. In the Source tab, set Type to Zone or Interface and select the appropriate zone or interface. Add a source IP/subnet if needed.
  3. In the Destination tab, set Type to Zone or Interface and add the destination zone or interface. Set the destination IP address(es) of the resource you are going to protect. Use the public IP address if the connection will come in from the internet and goes through the destination NAT.
  4. In the Option/Protection tab, do the following:

    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:

Figure 10.33 – A DoS protection rule

Figure 10.33 – A DoS protection rule

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.)

Summary

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
44.192.53.34