Route Protocol

Objectives:

Describe the differences between active/active and active/passive high availability

Define the prerequisites for creating a high availability pair

Describe the metrics used to detect a firewall failure

Configure the firewall interfaces used for heartbeats and hellos

Configure a high availability pair

Firewall High Availability Overview

High availability is remains a concern for mission critical networks. Palo Alto firewalls can be used as a high availability pair. When firewalls are set up in this pair, they provide redundancy and help business continuity.

If one firewalls fails for any reason, the other firewall can take over with minimal loss of service.

Palo Alto firewalls support both active/passive and active/active high availability configurations.

Both firwalls will synchronise their network, object, and policy configurations plus session information.

Note that only changes that have been comitted are shared between the firewalls.

Some information is not shared that is firewall sepcific, this is management interface IP address, high availability specific configuration, log data, and the application command center.

To get a consoliated view of applications and logs across a high availability pair, Panorama must be used.

Active/Passive High Availability

One firewall manages traffic whilst the other synchronised and ready to move to an active state if a failure occurs.

In this mode, the firewalls will both share the same configuration settings, and one will actively manage traffic until a failure occurs.

If an active firewall fails, the passive firewall will transition to an active state and takes over seamlessy enforcing the same policies to maintain network security.

In an active/passive setup, session capacity or network throughput is not increased.

Active/Passive high availability is supported in virtual wire, layer 2, and layer 3 deployments.

Active passive high availability has the simplicity of design, meaning any troubleshooting is easier.

Active/Active High Availability

In an active/active high availability deployment, both firewalls in the pair are active and processing traffic.

Both firewalls maintain their own session and routing tables, plus synchronise to each other.

The active/active configuration is designed to support environments that require asymmetric routing.

Active/active high avilability does not increase the session capacity or network throughput. Active/active high availability is supported in virtual wire and layer 3 deployments.

Active/active mode requires advanced design concepts, and can result in more complicated networks.

Depending on how the active/active high availability is implemented, it might require additonal configuration such as dynamic routing protocols on both firewalls, replication of NAT pools, and deployment of floating IP addresses to provide seamless failover.

Both firewalls in the active/active configuration process traffic, so firewalls will use the additional concepts of session owner and session setup to perform layer 7 content inspection.

Active/active mode is recommended if each firewall needsi tso wen routing instances, and if full real time redundancy is required out of both firewalls at all times.

Active/active will have faster failover and can handle peak traffic flows better than active/passive mode since both firewalls are processing traffic.

Note the PA-200 series firewall supports only high availability lite without synchronisation capability and can not be configured for active/active high availability.

The VM-Series firewall in Amazon Web Services only supports active/passive high availability

High Availability Prerequisities

Before high availability can be enabled on the Palo Alto firewall pair, both firewalls need to be the same hardware model.

The PAN-OS version must be the same, except when there is a temporary version mismatch during a software upgrade.

The Palo Alto firewall pair must also have up to date application, url, and threat databases.

A high availability interface type must be configured, and the firewall correctly licenced.

The firewall must also have a matching slot configuration (applies to multi-slot firewalls)

Specific requirements on VM-Series firewalls is that the firewall must use the same hypervisor, and the number of CPU cores requires to be the same.

Active/Passive High Availability Links

The high availability control link is used to exchange hellos, heartbeats and high availability state information.

The control link is also used to synchronise routing and User-ID information between mangement planes.

The active firewall also uses this link to synchronise configuration changes with it’s peer firewall.

The firewalls exchange hello messages messages and heartbeats at configurable interviews to verify the peer firewall is responsive and operational.

Hello messages are sent from one peer to the other to verify the state of the firewall.

The heartbeat is an ICMP ping sent to the high availability peer. A response from the peer indicated that the firewall is connected and responsive.

The control link is a layer 3 that requires an IP address.

The data link layer is a layer 2 link but can be configured as a layer 3 link that requires an IP address. The layer 3 link is only required if the data links are not on the same subnet. In layer 2 mode, the data link type uses ethertype 0x7261

The data link is used to synchronise sessions, forwarding tables, IPSec security associations and ARP tables between firewalls in the high availability pair. Data flow on the data link is unidirectional and flows from the active firewall to the passive firewall.

Dedicated and Non-Dedicated High Availabilty Ports

Some of the Palo Alto firewall range have high availability ports, and others require the management or in-band ports to be used as high availbility links.

The control link provides synchronisation for functions that are part of the management plane.

Using the dedicated HA1 port or the management port as the control link is more efficient than using the data planes in-band ports as the synchronisation packets need to pass from the data from the data plane to the management plane is not required.

The dedicated HA1 port requires an IP address that is different from the managment interface address. With devices with the dedicated ports, an ethernet cable can directly connect the dedicated HA1 ports and the dedicated HA2 ports to the device pair.

For firewalls without a dedicated high availability port, the best practice is to use the management port for the control link to allow a direct connection to be formed between management planes on the firewall.

Any in-band port can be used for the data link. Any in-band port that is used for a Control or Data link must be configured as the interface type HA.

Firewalls with dedicated HA ports are:

• PA-800
• PA-3000
• PA-3200
• PA-5000
• PA-7000

Firewalls without a dedicated high availability port:

• PA-200 and PA-500 Series
• VM Series

High Availability Backup Links

Backup links provide redundancy for control and the data links.a

The purpose of configuring a bkacup control link is to avoid a split brain scenario.

Split brain operation occurs when a non redundant control link goes down, which causes the managment plane to miss heartbearts, although both firewalls are still functioning.

In this situation, the passive firewall concludes that the active firewall is down and attempts to start services that are already running on the active firewall, causing a split brain operation.

Dedicated and redundant management plane control links connections can help prevent split brain.

In band ports are used as backup links for dedicated HA1 and HA2 ports. The following needs to be considered when configuring these ports:

• The IP address of the primary and backup HA links must not overlap
• HA backup links must be on a different subnet from the primary HA links
• HA1 backup ports and HA2 backup ports must be configured on physically seperate ports

PA-7000 Series HA Links

High availabiltiy on the PA-7000 series mandates the use of specific ports on the switch management card.

The HA1-A port is the control link. This port connects directly to the HA1-A port on the second firewall in the pair, or connected together through a switch or router.

The control link cannot be configured on NPC data ports or the MGT port.

The HA1-B port is the backup control link. This port connects directly to the HA1-B port on the second firewall in the pair, or through a switch/router. The backup control link also can not be configured on NCP data ports or the MGMT port

The high speed chassis interconnect, or HCSI, is used as the HA Data link and backup data link. Each HCSI port is a quad port SFP+ interface. Each HCSI port has four 10GB links internally for a combined speed of 40GB.

The HSCI ports are not routable and must be connected directly to each other. The HCSI-A on the first chassis connects directly to the HSCI-A on the second chassis, and so on.

Once fully connected, the connectivity will provide full 80Gbps transfers rate. In software the four HSCI-A ports are treated as a single HA inteface, this goes the same for the four HSCI-B ports.

If in the rare isntance the distance between the high availability pairs exceeds the maximum distance of the HSCI interface, in band ports can instead be used for data link connections.

Designating an Active Firewall

The firewall in a high availability pair will be a ssigned a device priority to indicate a preference for which firewall should assume the active role.

If a designated firewall in a HA pair needs to be made the active firewall, the pre-emptive behavior on both devices and a priority should be assigned.

The fireewall with the lower priority value is designated as the active firewall. The other firewall is designated as the passive firewall.

By default, pre-emption is disabled. When enabled the firewall with lower priority can resume as the active firewall when it recovers from whatever event stopped it working.

If pre-emption is disabled, this can give an administrator a chance to check why a firewall failed before bringing it back into service.

Failure Detection

The firewall can use several monitored metrics to detect a failure.

The firewall uses hello messages and heartbeats to verify that the peer firewall is responsive and operating.

Hello messages are sent from one peer to the other at the configured hello interval to verify the state of the other f irewall.

The heartbeat is an ICMP ping to the high availability peer over the Control link, and the peer responds to the ping to establish that the firewalls are connected and responsive.

Firewalls can be configured to monitor the link states of the physical interfaces. A firewall can be configured to trigger a failure if any or all the monitored interfaces in the group fail. The default behavior for monitored groups of ports is to failover if any port in the group fails.

The firewall can be configured to monitor mission critical IP addresse via ICMP pings to test reachability. Again a group can be defined to list the IP addresses that require to be monitored.

An IP address is deemed unreachable if ten pings fail by default, the failover settings can be set to fail the firewall if any or all the IP addresses become unreachable. Similar to interfaces, the default behavior is failover if any of the IP addresses fail.

The PA-3000, PA-5000, and PA-7000 series firewalls can also force a failvoer if an internal system health check fails. The health check is not configurable and is enabled to monitor critical components such as the field programmable gate arrays and CPUs.

General health checks can also cause a failover on any platform.

The failover will also occur if the firewall is suspended, or if pre-emption occurs.

HA Timer Profiles

High Availability timer profiles define the parameters associated with detecting failures and triggering failover.

Complexity can be reduced with configuring seven different high availability timers by selecting different profiles. The Advanced profile gives access and control to each of the seven different timers

The recommended profile is used for typical failover times, whilst the aggressive profile is used for faster failover time settings.

Note these preset values can change in different PAN-OS releases

Heartbeat Backup on the Management Port

Enablement of heartbeat backup on the management port can help prevent split brain operations, as redundant heartbeats and hello messages are transmitted over the management port on the management plane.

As heartbeat is an ICMP ping, the management port if configured for heartbeat backup must have pings enabled on the management interface.

Active/Passive High Availability Startup

The firewall remaisn in the INITIAL state after boot-up until it discovers a peer and negotiation begins. After a 60 second time out, the firewall becomes ACTIVE if HA negotiation has not started.

The ACTIVE state is the normal traffic-handling state of the active firewall in an active/passive configuration.

The PASSIVE state is the normal state of the passive firewall in an active/passive configuration. The passive firewall is synchronising flow state, run-time objects, and configuration.

If passive link state is configured, the passive firewall is running, the passive firewall is running routing protocols, monitoring link and path state. The passive firewall pre-negotitates LACP and LLDP if LACP and LLDP pre-negotiation are configured. The firewall does not process any other types of traffic.

A firewall in the SUSPENDED state cannot participate in the election process and become either active or passive. To suspend a firewall, click Device -> High Availability -> Operational Comamnds and click the Suspend local device link.

To re-active the firewall, click Make local device functional link.

The NON-FUNCTIONAL state is an error state due to a data-plane failure or configuration mismatch.

Firewall State	Description
INITIAL	Transient state of a firewall until it joins the HA pair. The firewall will remain in this state after boot-up until it discovers a peer and negotiations begin.
ACTIVE	Normal traffic handling state
PASSIVE	Normal traffic is discarded, might process LLDP and LACP traffic
SUSPENDED	Administratively disabled
NON-FUNCTIONAL	Error state

Monitor Firewall States

The state of the individual firewalls in a high availability pair can be monitored from the Dashboard tab of the web interface. There is colour coded display about the major components of high availability, these states are green for good, yellow for passive, and red for critical.

Synchronisation of the firewalls must be initiated manually the first time a firewall pair is connected.

This is required to prevent administrators accidently setting the wrong firewall as active and overwriting the configuration they wish to push to the peer.

Even though Sync to Peer is available on the passive device, it should only be ran from the active device or the current configuration on the active device may overwritten with an earlier out of date configuration.

Objectives:

Create an interactive, graphical summary of the applications with the ACC

Export policy rules, objects, and IPS signatures using the configuration table export

Create a predefined report to view traffic statistics for the previous day

Describe how log files are forwarded to an external source

Configure a Server Profile to forward logs to a syslog server

Filters

Local Filters

Applying a local filter allows interaction with a graph and customises the display so details can be seen and information can be accessed on a specific widget.

The local filter is persistent across reboots

Global Filters

A global filter allows the display to be limited and details the administrator wishes to see, removing unrelated information from the display.

An example is all events can be displayed related to a specfic user and application. The users IP address or username and application can be applied as global filter, and display only information regaridng the user and the application through all tabs and widgets on the ACC. Global filters are not persistent.

Global Filters can be applied in three ways:

• Set a global filter from the table. Select an attribute from the table in any widget and apply the attribute as a global filter
• Promote a local filter to a global filter. Allows you to take a local filter, which can be attribute in a single graph or table in a widget and apply that attribute globally. When the local filter is replicated to a global filter, the display is updated across all tabs on the ACC.
• Define a global filter using th Global Filters pane on the ACC.

Session Browser

Selecting Monitor -> Session Browser alls the administrator to browse and filter sessions that are currently on the firewall

Configuration Table Export

Starting with Pan-OS 8.1, policy rules, objects, and IPS signatures from Panorama and firewalls can be exported to demonstrate regulatory compliance to external auditors, or conduct periodic reviews of firewall configuration and generate reports about firewalls policies.

Auditors no longer need direct access to firewalls to take screenshots, or use the XMI API to generate configuration reports.

Form the web interface, configuration data for policies, objects, network, and devices, plus panorama configurations, the exceptions in antivirus, antispyware, and vulnerability protection can be exported.

Configure table export works like a printout, and generated files can not be exported back into the firewall.

The data that is viewed on the web interface is exported into a CSV or PDF format.

Filters can be applied and matched with the report criteria, plus searching within PDF reports allows data to be found quicly.

Every time configuration data is exported, a system log is generated to record the event.

Types of Reports

Predefined Reports

Over 40 reports including Applications, Traffic, Threat and URL Filtering

Botnet Reports

Behavior-based mechanisms to identify potential infected hosts

Custom Reports

With the query builder

PDF Summary Reports

Aggregated reports

User or group-activity reports

Includes URL categories and browse-time calculations

Report groups

Compile reports into a single emailed PDF

User or Group Activity Reports

1. Serlect Monitor -> PDF -> Reports -> User Activity Report
2. Click Add and then enter a name for the report
3. Create the report:
   1. For a User Activity report: Select User and enter the Username or IP address (IPv4 or IPv6) of the user who will be the subject of the report
   2. For a Group Activity report: Select Group and select the Group Name from which to retrieve user group information in the report
   3. For a Custom User or Group Activity report: Select Filter Builder and select the appropriate Connector, Atrribute, Operator, and Value for the report
4. Select the time period for the report from the drop down list.
   1. It should be noted that the number of logs that are analysed in a user activity report is determined by the number of rows defined on the Max Rows in User Activity Report on the Logging and Reporting Settings section in Device -> Setup -> Management
5. Select Include Detailed Browsing to include detailed URL logs in the report.
   1. The detailed browsing information can include a large volume of logs (thousands of logs) for the selected user or user group and can make the report very large
6. To run the report on demand, click Run Now
7. To save the report, click OK
   1. User/Group Activity reports cannot be saved on the firewall

PDF Summary Reports

PDF summary reports contain information compiled from existing reports based on the data for the top five in each category.

PDF summary reports also provide trend charts that are not available in other reports

Report Groups

Report groups enable a set of reports to be created that the firewall can compile and send as a single aggregate PDF report with an optional title page and all constituent reports included.

Exporting Current Listing to CSV

To export the current log listing to CSV, select the Export to CSV icon.

EXporting of the log listing to CSV format generates a CSV of up to 65,535 logs.

To change this number of limits, use the Max Row in CSV Export field on the Log Export and Reporting subtab. Select Device -> Setup -> Management -> Logging and Reporting Settings

Scheduled Log Export

A daily export of logs can besent to a FTP or SCP server in a CSV format.

Traffic, Threat, URL, Data Filtering, HIP Match, and WildFire logs can be exported.

After the first export, only logs collected since the last export will be sent in the next export.

The log file also includes logs of the last calendar day.

Forwarding Logs to External Sources

The firewall provides logs that record configuration changes, system events, security threats and traffic flows.

Logs can be forwarded to a Panorama management appliance, which can generate SNMP traps or syslog messages and send e-mail notifications.

The firewall can also forward logs using HTTP/HTTPS. This capability allows the firewall to integrate with external systems that provide a HTTP-based API and trigger automated actions when a specific event occurs on the firewall.

Logs most commonly are sent to Panorama or to an external syslog server for long-term storage and analysis.

Panorama provides the ability to manage a distributed network of Palo Alto Networks firewalls from a centalised location where the administrator can:

• View of all the firewall traffic
• Manage all aspects of device configuration
• Push global policies
• Generate reports about traffic patterns or security incidents

Panorama is available as a dedicated management appliance known as the M-100 or M-500, or as a virtual appliance.

If the M-100 is used as a log collector, it’s maximum storage is 7 terabytes.

The M-500 supports up to 24 terabytes

Cortex Data Lake

Cortex Data Lake provides cloud-based, centralised log storage and aggregation for on-premises, virtual, private cloud, and public cloud firewalls, plus Global Protect Cloud Service.

Panorama provides the interface for all logs stored in Cortex Data Lake.

From Panorama, an aggregated view of all logs can be observed, and reports, log analysis, and forensics can be generated from this logged data.

Cortex Data lake also provides isolation of data from other customers, avoiding cross-contamination of logged data.

Data redundancy is maintained through storage of multiple copies of the log datacase to ensure access when needed.

Current Cortex Data Lake facilities are in two regions, North America and Europe.

The location can be configured to where log data is forwarded.

Syslog Overview

Syslog is a standard log transport mechanism that enable aggregation of log data from different network devices such as routers, firewalls, and printers from different vendors into a central repository for archive, analysis, and reporting.

Syslog log forwarding can be used to forward logs to a system information and event manager.

Many SIEM vendors and models are compatible with PAN-OS software.

Syslog can be transported over UDP, TCP, or SSL with authentication.

SNMP Monitoring Overview

If the SNMP manager is on a non management, allow SNMP on the interface management profile for that interface and create a service route for SNMP to use that interface.

Creating an SNMP Traps Server Profile

SNMPv2:

Trap Repository Adress

Community String

SNMPv3:

Username

EngineID: (Get with the OID 1.3.6.1.6.3.10.2.1.1.0)

Passwords:

Auth uses SHA

Privlege uses AES

Objectives:

• Describe the three basic requirements for creating a VPN
• Configure the interface, IP addresses, and PSK for the IKE Gateway
• Configure the DH group, encryption methods, and authentication methods for an IKE Cryptographic profile
• Configure a static route in the route table for the tunnel
• Troubleshoot IPSec VPN issues from the responder side of the VPN tunnel

Site to Site Overview

IPsec VPNs are implemented between Palo Alto firewalls as routed based tunnels, rather than policy based designs.

In a route based VPN, the determining factor of which traffic will be tunneled is the final destination of that traffic.

Route based VPNs are easy to deploy and can scale easily due to the advantage of being supported by dynamic routing protocols.

The Palo Alto firewall can also interoperate with third party policy based VPN devices.

When recieved traffic is destined for a remote private network, it looks up the next hop in the routing table.

If it is a remote network, the routing table points to a logical tunnel interface.

This interface is not a real interface, but has the information required to create an IPSec tunnel.

Once the traffic is sent to this logical tunnel interface, the VPN is created and traffic is sent through it.

Palo Altos support IKE version 1 and 2. Version 1 is more commonly used but version 2 supports the requirements of the Network Device Protection Profile, or NDPP.

The option of ‘IKEv2 preferred mode’ provides the ability for the Palo Alto to fall back to IKEv1 after 5 failed retries, that takes around 30 seconds.

IKE Phase 1

IKE Phase 1 identifies the end points of the VPN.

Phase 1 uses peer IDs to identify the devices at each end of the VPN. This is often just the public IP address of the device.

In situations where the public IP is not static, it can be replaced with a domain name or other text value

Three settings are available on Palo Alto firewalls: Aggressive, Main, and Auto

Five snippits of information are transmitted during Phase 1:

1. Authentication Method
2. Diffie-Hellman key exchange
3. Symmetric Key Algorithm / Bulk Data Encryption
4. Hashing Algorithm
5. Lifetime

IKE Phase 2

Phase 2 creates the tunnel that will encapsulate data traffic.

Whilst IKE Phase 1 deals with the authentication, Phase 2 focuses on the data that is transmitted across the tunnel.

Each side of the tunnel has proxy IDs to identify the traffic it is sending and what it expects to receive. These IDs can be a specific network range or a generic network of 0.0.0.0/0

Both sides need to know what the other side will be sending in order for the VPN tunnel to work.

Five snippits of information are transmitted during Phase 2, these are:

1. IPSec type and mode
2. Diffie-Hellman / PFS
3. Symmetric Key Algorithm / Bulk Data Encryption
4. Hashing Algorithm
5. Lifetime before rekeying

Route Based Site to Site VPN

A single VPN may be sufficient for connecting between a singel central site and a remote site.

Connections between a central site and multiple remote sites require VPN tunnels for each central remote site pair.

Each tunnel is bound to a tunnel inteface.

VPN traffic is moved across the tunnel interface to the same virtual router as the incoming plaintext traffic.

If a packet comes to the firewall, the route lookup function can determine the most approriate tunnel to use.

The tunnel interface appears to the Palo Alto operating system as a normal interface, and existing routing protocols and infrastructure can be applied.

Each tunnel interface can have a maximum of 10 IPSec tunnels, that allow creation of IPSec tunnels for individual networks that are associated on the same tunnel interface as the firewall.

VPN Tunnel Component Interaction

Three basic requirements for creating a VPN in Pan-OS:

1. Create the tunnel interface or Phase 1 Objects
   1. See Network -> Intefaces -> Tunnel
   2. The new logical interface must be added to a Layer 3 zone and to a virtual router just as any other logical Layer 3 interface would
2. Configure the IPSec tunnel or Phase 2 Objects:
   1. A basic interface can be used when creating a tunnel between PAN-OS devices with known IP addresses
   2. The only values needed are the tunnel interface to use, local peer ID, remote peer ID, and pre-shared key
   3. If configuration is with another Palo Alto firewall, make use of the default crypto profiles
   4. If the configuration is with another vendors firewall, configure the advanced settings in Crypto Profiles to match both sides
3. Add a static route to the virtual router or enable a routing protocol such as BGP, OSPF, or RIP
   1. Add a route table entry fo the remote network that points to the tunnel interface in Steps 1 and 2
   2. Create a route for the remote network using the tunnel interface
   3. No next-hop IP address is required when tunnel interfaces are used
   4. Ensure to create a security rule to allow tunneled traffic

Troubleshooting IPSec Tunnels

Begin by looking at the IPSec Tunnel page, each tunnel provides useful troubleshooting information.

Go to Network -> IPSec tunnels

Tunnel Status, green indicates a Phase 2 SA tunnel has established. Red indicates SA is not available or has expired.

IKE Gateway Status: Green indicates a valid IKE Phase 1 SA or IKEv2 IKE SA. Red indicates that IKE Phase 1 SA is not available or has expired

Tunnel Interface Status:

Green indicates that the tunnel interface is up, because tunnel monitor is disabled or the tunnel monitor status is up and the monitoring IP is reachable. Red indicates that the tunnel interface is down because the tunnel monitor is enabled and the remote IP address is unreachable.

Tunnels are established only when traffic is attempting to cross. The test vpn command in the CLI can be used to initiate a tunnel manually.

Common VPN error messages

Always troubleshoot error messages from the responder!

Issue	Initiator Error	Responder Error
Wrong IP/no Connection	P1 – Timeout	P1 – Timeout
No matching P1 proposal	P1 – Timeout	No suitable proposal (P1)
Mismatched peer ID	P1 – Timeout	Peer identifier does not match
No matching P2 proposal	No proposal chosen	No suitable proposal (P2)
PFS Group Mismatch	P2 – Timeout	PFS group mismatch
Mismatched proxy ID	P2 – Timeout	Cannot find matching Phase 2 tunnel

Describe the three major components of GlobalProtect

Configure the client and server certificates to authenticate the agent and the portal

Define the three methods supported for GlobalProtect client connections

Configure the tunnel parameters for an external gateway connection

Extending the security platform with GlobalProtect

GlobalProtect builds on the technology of and offers several features over traditional VPNs:

• Extends Next Generation Firewall capabilities to endpoints
• Delivers full traffic visibility
• Simplifies management
• Unifies policies
• Stops advanced threats

Expanding the boundries of the organisation network the clients endpoint anywhere in the world, GlobalProtect can work on remote laptops and mobiles devices.

GlobalProtect can determine the closest available gateway to the roaming device and establish a secure connection using strong authentication.

Laptops and mobiles devices can stay conencted to the organisations network at all times, and behave as if they have never left the corporate network.

GlobalProtect can ensure that the same secure application enablement policies that protect users at the organisation are enforced for all users where ever they are in the world.

Components of GlobalProtect

GlobalProtect comes in three components:

• GlobalProtect Portal
  • Provides the management functions for the GlobalProtect infrastrucutre. Every client that connects to the GlobalProtect netweork receives configuration information from this portal.
• GlobalProtect Gateways
  • Provides security encofrmcenet for traffic and GlobalProtect agents and apps. External gateways provide security enforcement and VPN access for remeote users. Internal gateways apply security policy for access to internal resources
• GlobalProtect Client Software
  • Runs on end users systems and enables access to network resources via the deploy GlobalProtect portals and gateways

GlobalProtect Install Agents

The installer is in an .msi for Windows, or .pkg for Mac.

GlobalProtect has installation agents for Android, Chroembook, iOS, and Universal Windows Platform.

The iOS and Android versions are available through their respective app stores.

The GlobalProtect app for Linux extends User-ID and Security Policy enforcement to users on Linux endpoints.

The app is available in .deb, .rpm, or .tar packages, and compatibilty with operating systems such as CentOS 7.0, Red Hat Enterprise 7.0, or Ubuntu 14.04 and later

It provides a command line interface and functions as an SSL or IPSec VPN client.

The Linux App supports common GlobalProtect features and authentication methods such as client certificate authentication, server certificate validation, authentication cookies, and two factor authentication.

Connection Sequence for GlobalProtect

1. The GlobalProtect client on the local system connects to the GlobalProtect Portal for authentication.
2. After authorization is confirmed, the portal sends the client configurations and a list of GlobalProtect Gateways.
3. The client connects to the bets gateway (based on SSL response time and local priority) to respond to the connection request.

It is the client that communicates directly with portals and gateways, there is direct communication among gateways or between gateways and portals.

Once the client is installed and enabled, it contacts the portal when setting up a connection. Any time the client contacts to the portal, the portal authenticates the connection.

A GlobalProtect Topology

The GlobalProtect implementation requires at least one portal and one gateway.

The portal and gateway can be configured on the same firewall.

In the most simple configuration, a single firewall is configured to serve gateway and p otal services from the same IP addres. This provides the end users with VPN access to the organisations networks with a minimum of configuration.

If the gateway and portal share a single IP address, only one certificate is needed for the firewall.

An Advanced GlobalProtect Topology

Larger environments GlobalProtect can be configured with multiple gatewaysd.

Additional gateways can be used to provide access to multiple protected networks, and can provide redundancy and performance improvements for end users.

GlobalProtect clients can connect directly to a gateway, from a list provided by the portal, and by default, the chosen gateway is the one that responds the fastest to the connection request.

To ensure consistent access, multiple gateways often require the networks to be connected to each other by VPN so the end user has access to the same data regardless of which gateway they connect too.

Although there will always be one portal, the portal is not a single point of failure. If the firewall that hosts the portal is unreachable the client can use their cached configuration to contact other gateways.

The only limitation is an offline portal, which a new client can not be serviced or configuration changes will not be downloaded by existing clients.

This issue can be resolved by fixing the offline portal, or redirecting clients via DNS to another portal.

GlobalProtect in the cloud

With major cloud providers having worldwide locations, with VM series firewalls and globalprotect mobile security, this allows an organisation to extend their security policy to remote users and devices regardless of their location in the world.

GlobalProtect establishes a secure connection to protect the user from internet threats and can enforce application based access control where ever they are in the world.

Prisma Access

In marketing terms:

Prisma access is:

• security delivered from the cloud
• scalable, mangeable architecture
• consistent security for both remote locations and mobile users
• managed centrally by panorama

Prisma access allows the administrator to scale their networks based on growth of the headquarters, remote networks, and mobile users.

Subscriptions are Threat Prevention, URL F iltering, WildFire are all included with Prisma Access.

Panorama is used to onboard sites, manage policies and query logs for monitoring and reporting capabilities.

Determining Internal or External Gateways

The portal can provide an IP address and DNS hostname as part of the information passed to the client to determine if the host is inside or outside the corporate network

The DNS hostname and IP address must correspond to a device whose name can only be resolved by an internal web server

The agent performs a reverse lookup on the IP address. If it recieves a hostname as the response, the agent assumes it is an internal network and connects to the gateways in the internal list.

If no response is recieved by the lookup, the client connects to the gateways in the external list.

If an internal host detect hostname and address pair is not provided, the client connection attempts to connect to the internal gateways first, then the external gateways.

Clientless VPN

Clientless VPN allows the user to have secure access to an organisations network from a SSL-enabled web browser without needing to install client software

Users can log into the GlobalProtect portal using a web browser and launch the web applications that have been published for that user

A user can access applications that have been made available to them. The user who logs in will be able to see a list of applications that they can launch

Security policies will need to be configured to allow traffic from GlobalProtect clients to the security zone associated with the GlobalProtet portal that hosts the landing apge.

Security policies will need to be configured to allow user-based traffic from the GlobalProtect portal zone to the security zone where the published application servers are hosted.

GlobalProtect for Internal User Based Access

An internal gateway that is used in conjunction with User-ID technology can be used to provide a secure, accurate, method of identifying and controlling traffic by user

Internal gateways are useful in sensitive environments where authenticated access to critical resources is required

HIP Profiles can be configured on the gateway to ensure compliance with internal maintenance requirements, such as the latest security patches and anti-virus definitions are installed, whether disk encryption is enabled, and if any other software is required to bne installed.

GlobalProtect Certficates

Connectivity between all components of GlobalProtect is authenticated using SSL certificates.

The portal can act as a CA for the system, using a self signed or imported subordinate issuing a CA certificate, or an administrator can generate their own certificates using their own CA.

The portal, gateways, and agents msut use certificates all signed by the same certificate authority.

Before any information is tranferred, the client verifies the gateway is using a server certificate signed by a trusted CA.

The gateway also verifies that the client has a client certificate signed by the correct CA.

If they are third parties who may not trust a self signed CA, a third paty CA who is trusted by all parties should be used for the portal.

The portal includes public certificate of the CA, and the needed client certificate and key as part of a configuration bundle sent to the client.

GlobalProtect gateways use the same client certificate to authenticate and identify the client,

Support is provided from the Palo Alto for the portal to export the server certificate and key for the gateways. If an external CA is used, the CA certificate, along with a server certificate and key can imported along with a server certificate and key for the portals and gatewats, and a client certificate and key for the clients.

Portals and gateways do not communicate directly, so the gateway certificates need to be manually imported onto firewalls.

Authentication Server Profiles and GlobalProtect

GlobalProtect uses the same system of server profiles and authentication profiles that administration or user-id use.

Agent Software

The GlobalProtect client apge lists available GlobalProtect releases.

When the agent connects to the portal, the firewall will check the version and installs the currently activated version if it is different from the version currently on the system.

Only the portal provides the software, so if seperate from the gateway it will need to be maintained.

GlobalProtect Portal

As most configuration for GlobalProtect to work happens on the portal, the portal is responsbile for co-ordinating communications between all other components for GlobalProtect to work.

GlobalProtect administrators can set the level of control that end users have over their own coinnections, from a fully locked down configuration to one that permits to choose what gateway they want to connect too.

GlobalProtect App Connection Methods

on-demand: Allows users to establish a connection on demand. This user must explictly initiate the connection

user-logon: Automatically establishes a GlobalProtect client connection after the user logs into their computer. If the use of single sign on is enabled, the agent uses the Windows credentials of the user to authenticate to the portal in a process that is completely seamless to the user. The authentication profile must use the same verification process as the logon service.

pre-logon: Preserves pre-login and post-login services provided by organisation infrastructure regardless of where a machine might be located. GlobalProtect establishes a connection, even if a user is not logged into the computer. This means the company can create a logicial network that maintains the security and management features normally achieved by a physical network. Tunnel selection and establishment occurs based on machine certificates deployed outside of GlobalProtect

When User-ID technology isi n use, pre-login conditiuons are marked with a user identifier of ‘pre-login’ rather than an explict user. Once a user has logged in ‘pre-login’ changes to the username of the client device.

Internal gateways only support always-on methods, user-login or pre-login.

The connection method is selected by navigating to Network -> GlobalProtect -> Portals -> Agent

GlobalProtect Gateway

The GlobalProtect gateway provides the endpoint for the agents connection

If tunnel mode is enabled, the client sends all traffic through the conencted gateway.

Note that external gateways always require a tunel, internal gateways do not but can be configured to use one.

Split tunnels are supported, but this feature is not recommended for extending the firewall policy with application control and visibility to all mobile users.

Gateways enforce the policy based on the HIP profiles that are received.

GlobalProtect and User-ID

The GlobalProtect client provides a way of mapping user information to the firewall directly.

Every user that has the GlobalProtect agent or app running requires the user to enter their login details to access orgainisation rsources.

This login information can be mapped to the User-ID user mapping table on the firewall for visiblity and user-based securtity policy enforcement.

Since users must authenticate to gain access to the network, their user to IP address is explictly known.

GlobalProtect Agent

The GlobalProtect client software runs on end users systems and enables access to the organisations network via GlobalProtect Portals and Gateways that have been deployed.

Objectives

Describe the four main components of User-ID

Describe the differences between the integrated agent and the Windows-based agent

Define the methods to map IP addresses to users

Configure the PAN-OS integrated agent to ocnnect to monitored servers

Configure the Windows-based agent to probe IP addresses for username information

User-ID’s Purpose

The purpose of User-ID is to identify the user on the network and the IP addresses of the computers the user is logged in too.

User-ID can retrieve information from a connected LDAP directory server.

The goal of User-ID is to give the ability to write policies, display logs, and display reports using usernames rather than just numercial IP addresses and port numbers.

Usernames and group names can be used as matching criteria in Authentication policies, Decryption policies, DoS protection policies, Policy Based Forwarding policies, QoS policies, Security Policies, and Tunnel Inspection Policies.

User-ID Main Functions

Before user and group based policy rules can be created, the firewall requires a list of all users and their group mappings.

The firewall uses group mapping and user mapping to collect the information required.

Group Mapping is learned from group names and member users from a LDAP directory server.

User Mapping includes several different methods to collect IP address-to-username information.

The user mapping can be chosen by the administrator to suit different needs and environments. Different methods can be used at different sites.

User-ID Components

Palo Alto Networks Fireewall

• Maps IP addresses to usernames
• Maps usernames to group names

PAN-OS Integrated User-ID Agent

• Runs on the firewall
• Collects IP address to username information

Windows-based User-ID Agent

• Runs on a domain member
• Collects IP address-to-username information
• Sends information to the firewall

Palo Alto Networks Terminal Services Agent

• Runs on Micorsoft and Citrix terminal servers
• Collects IP and port nubmer to username information
• Sends information to the firewall

Forms of User-ID Agent

Capability	PAN-OS Integrated Agent	Windows-Based agent
Included with PAN-OS software	Yes	No
Available for download from Palo Alto Networks and can be installed on one or more Windows Systems	No	Yes
A firewall can communicate with both agent types at the same time	Yes	Yes
Can monitor up to 100 domain controllers or Exchange servers	Yes	Yes
Can monitor users and domain controllers only from a single Active Directory, or AD, domain	Yes	Yes
Designed for small and midsize deployments	Yes	No
Can handle larger environments or multiforest domains	No	Yes

Integrated Agent verues Windows Based Agent

The Windows based agent and the PAN-OS integrated perform the same basic tasks, but use different underlying communication protocols.

The Windows based agent uses MS-RPC, which requires full Windows Security logs to be sent to the agent, where they are filtererd for relevant User-ID information. This agent is best for reading local logs.

The Pan-OS integrated agent users either the Windows Management Instrumentation (WMI) or the Windows Remote Management Protocol (WinRM), which allows the agent to retrieve only the relevant User-ID information from the security logs. This agent is best for reading remote logs.

In summary, use an integrated agent for remote sites, or install a Windows-based agent at the local site.

User Mapping Methods

User Authentication

• GlobalProtect – Login Events
• Captive Portal – Web Forms

XML API

• Aruba/ClearPass
• User/Group Mapping
• Devices that can format and send XML over HTTP

Syslog Listening

• Third Party WLAN controller
• Third Party Proxy
• Third Party VPN
• Network access control systems
• 802.1x devices

Port Mapping

• Terminal Services Agent
• Microsoft Remote Desktop Services
• Citrix Presentation Server
• Citrix XenApp

XFF Headers

• Third Party Proxy

Server Monitoring

• eDirectory – Login or logout events in authentication logs
• Microsoft Exchange – Login or logout events in authentication logs
• Microsoft Active Directory – Login or logout events in authentication logs

Session tables are also read to confirm known IP address to username mappings based on current Windosws file and printer shares

Client Probing

• Windows Clients

User Mapping Using Global Protect

Every GlobalProtect user is required to enter their login credentials to access to the VPN

GlobalProtect can directly add the username to the firewalls User-ID mapping table

GlobalProtect is listed as the best solution for high security enviroments

User-ID information can be provided by clients that are conneted to an internal network via an internal Global Protect gateway without establishing a VPN tunnel to the firewall.

User-ID Syslog Monitoring

Syslog monitoring may be a good fit where existing network services exist that authenticate users. These services could include 802.1x devices, Wireless controllers, Apple Open Directory serves, proxy servers and other related services.

These services can be configured to send syslog messages that contain information about login and logout events, and configure the User-ID agent to parse those messages.

The integrated and Windows based agents can retrieve these syslog messages. Syslog Parse Profiles are used to parse syslog messages. With environments with different services with varying messages, custom Syslog Parse Profiles can be set up to pick up on login and logout events. If the Pan-OS integrated User-ID agent is used, Palo Alto provide predefined Syslog Parse Profiles through Application content updates.

The User-ID agent can parse for login events to map IP addresses to usernames and parse for logout events so the firewall deletes outdated mappings. Deletion of outdated mappings is useful were IP address assignments are changed often.

User-ID Operation Overview: Domain Controllers

Before User-ID can operate, it must be enabled on the relevant security zone.

If User-ID is enabled, the firewall consults the administrator-defined User-ID configuiration to determine which agents the firewall has available to gather IP address and username information.

Once User-ID has retrived the IP address and username information from an agent, it can use the firewalls LDAP configuration to retrieve user to group mapping information from a LDAP server.

With the information requirements satisified, the security policy can be checked for a match.

In terms of Domain Controllers User-ID, When a user logs into their laptop, which is an Active Directory member, the AD domain controller logs a logon event with the username and IP address of the station.

User-ID Domain Controller Monitoring

Palo Alto recomended passive server monitoring (due to low overheads) allows a User-ID agent to monitor the security logs for user logon or logout events for a Microsoft domain controller.

The AD domain must be configured to log succesful logon events into the security logs.

Users are able to authenticate to any domain controller in a domain, and security logs are not replicated between seperate domain controller servers. Server monitoring needs to be turned on for all controllers to capture all user login events. User-ID agents can monitor multiple domain controllers, but only a single domain.

Step 1 – Parse and record

On startup, the User-ID agent parses the security event logs for user logon events

Step 2 – Check Logs

The User-ID agent checks Security logs on a regular basis for only new logon or logout events

Step 3 – Mappings cached

User mappings are cached for the first time equal to the timeout value set in the User ID agent

User-ID Windows Session Monitoring

Clients thats have a connected shared file/folder or print resource will have their session information stored on a Domain Controller.

This is an additional Windows-based method to resolve IP addresses to users. Consult the shared resource session table recorded on the Domain Controller.

User-ID Mapping Recommendations

Use	If you have…
GlobalProtect	GlobalProtect VPN Clients
Captive Portal	Web clients that do not use the domain server
Syslog Listener	Non-windows systems, NAC mechanisms such as wireless controllers, 802.1x devices, or proxy servers
User-ID agent: Session monitoring	Exchange servers, domain controllers, or eDirectory servers
User-ID agent: Session monitoring	Windows file and print shares
Terminal Services agent	Multi-user systems such as Microsoft Desktop Services or Citrix Metaframe Presentation Server (XenApp)
User-ID agent: Client probing	Windows clients that often change IP addresses
XML API	Devices and applications not integrated with User-ID

Steps for configuring User-ID

1. Enable User-ID by zone
2. Configure user mapping methods
3. Configure group mapping (Optional)
4. Modify firewall policy rules to use usernames or group names

To enable user-ID by zone, tick the ‘Enable User Identification’ box on the zone settings on the firewall.

By default User-ID tries to map all user from all networks found within a User-ID enabled zone.

The include list can be used to limit the networks that the firewall tries to map IP addresses too.

The exclude list can be used to exclude a subnet of network included in an Include list.

If WMI probing is enabled, by default only private IP address ranges are probed. To probe public addressing ranges, those ranges need to be included in the Include List.

Configuring the PAN-OS Integrated User-ID Agent

1. On the domain controller, create a service account with the required permissions to run the agent
2. On the firewall define the address of the servers to be monitored
3. Add the service account to monitor the servers
4. Configure session monitoring (optional step)
5. Configure WMI probing (optional step)
6. Commit the configuration and verify agent status

Configure the Windows-Based User-ID Agent

1. On the domain controller, create a service account with the require permissions to run the agent
2. Select a Windows domain member
3. Download and install User-ID agent software
4. Run the User-ID agent installer
5. Configure the User-ID agent
6. Configure the firewall to connect to the User-ID agent
7. Verify connection status

Selecting the Installation Location

The Windows-based agent can be installed on 32 or 64 bit machines running Windows XP SP3 or later

The agent is to be installed on the same network site as the monitored server to optimise bandwidth use

Two agents can be installed on two member servers in case one agent or a single domain controller fails.

The agent can be installed on a domain controller, though this is not recommended best practice.

Selecting Users and Groups for a Security Policy

any – matches any value for user

pre-login – Used with certain GlobalProtect implementations

known-user – Matches any user or group identified by User-ID

unknown – Matches traffic where the user could not be identified by User-ID methods

select – Matches a specific user or group identified by User-ID

For larger enterprise, it is best to set policy rules by groups rather than users.

Objectives:

• Describe how a firewall works with WildFire Threat Intelligence Cloud
• Describe how WildFire analysis is used to update URL categories listed in the PAN-DB URL Filtering data
• Configure Session Information Settings to specify which type of session information will be sent to Wildfire
• Define a WildFire Analysis Profile
• Configure both the types of information submitted to WildFire and the amouht of information is returned to the firewall in the report

Evolution of Malware

In modern times malware has evolved.

Instead of being a simple replication of a virus, it has adapted to be highly evasive and adaptable to avoid deteciton. Highly targeted and sophisticated when launching attacks

This new breed of malware that is often the core of the most sophisticated attacks on organisations networks today

Often this new malware is customised for a particular attack, making it more difficult for traditional signature-based anti-malware solutions to detect it

WildFire Threat Intelligence Cloud`

Palo Alto firewalls arouind the world automatically forward unknown files and URL links found in emails to the WildFire Threat Intelligence Cloud Cloud, or one of the three regional clouds for analysis.

The three regional clouds are in Europe, Japan, or Singapore.

Each cloud analyses samples and generates malware signatures and verdicts independently of other WildFire clouds.

The sample could be detected as Benign, Grayware, Malware or Phishing. If Phishing the PAN-DB URL Database will get updated.

WildFire signatures and verdicts are shared globaly which allow WildFire users to benefit from the anti-malware coverage no matter where they are in the world.

WildFire users can also use the WildFire XML API or WildFire Dashboard to manually upload files to WildFire for analysis.

Recap of Wildfire

WildFire is a cloud based virtual sandbox used to evaluate unknown files and URL links found in e-mails.

The evaluation occurs for Android, Linux, MAC OSX, Windows XP, Windows 7 and Windows 10

If malware or phishing is founmd, WildFire creates a new antivirus signature or adds the URL to the PAN-DB Phishing URL category.

These updates are available in minutes for firewalls around the world to download.

Overview of Wildfires Operation

For the daily threat updates, the new signature is normally delivered within 24 to 48 hours

WildFire Verdict Descriptions

Benign

Safe and does not exhibit malicious behavior

Grayware

No security threat but may display obtrusive behavior

Malware

Malicious in nature and intend and can pose a security threat

Phishing

Based on properties and behaviors the website displays

WildFire Protects E-mail

The Palo Alto firewall has the capability to send email attachements or URL links to WildFire for analysis.

The firewall nor Wildfire store or enable viewing of the email contents.

If WildFire detects a malicious file, it immediatly creates a new anti-virus signature that can be downloaded by Palo Alto firewalls around the world.

This new antivirus signature can help prevent further compromise of other machines in the network and around the world.

If the firewall has a WildFire and PAN-DB licence, the firewall can gain access to the signatures in as little as 5 minutes.

If WildFire determines a file attachment or e-mail URL link is malicious, it includes the email header in WildFire Submissions logs that it returns to the firewall. If User-ID technology is eanbled, the log can be used to quickly find and remediate the threats received by the user.

Content Packages and Wildfire Updates

WildFIre analysis is used to create new antivirus signaturtes.

It also is used to update the URLs and URL categories listed in the PAN-DB URL Filtering database.

Antivirus signatures are made available within 24 to 48 hours as content updates to the Antivirus content database.

Daily downloads of the antivirus content database can be scheduled. Firewall access to the AntiVirus content database is permitted with a Threat Prevention Licence.

Antivirus signatures are also available as little as 5 minutes as content from the WildFire Signatures database. A firewall can scheduled as little as every minute to check for updates. Access to this database is permitted with a WildFire licence.

URL updates are available within 5 minutes as content updates to the PAN-DB URL Filtering database.

Updates of the firewall with new content updates of the PAN-DB URL Filtering do not need to be scheduled, as new URL information is downloaded dynamically as needed.

Firewall access to the PAB-DB URL filtering database is enabled using a URL Filtering Licence.

Standard and Licensed Functionality

Standard Subscription

• Windows XP and 7 analysis
• Windows PE file analysis
  • EXE, DLL, SCR, FON, and others
• Antivirus signatures delivered by daily dynamic content updates (requires Threat Prevention licence)
• Automatic file submission

WildFire licensed service

• Standard subscription features
• Additional file type analysis:
  • Microsoft Office extensions, PDF, JAR, CLASS, SWF, SWC, APK, Mach-O, DMG, RAR, 7-Zip, Linux ELF, PKG
• WildFire signature updates every 5 minutes
• API file submission
• WildFire private cloud appliance
  • WF-500

WildFire Licenses

Signatures

There are two different content package formats for WildFire content updates, content packages for 7.1 and later, and content packages for 7.0 and earlier.

The content packages contain the same set of signatures

XML API

A licence allows users to submit files for analysis to WildFire using the WildFire XML API

Private Cloud

A WildFire licence entitles a firewall to use the WF-500 appliance as a WildFire private cloud service.

WildFire Private Cloud

The WF-500 is a WildFire private cloud solution. It supports Windows XP and Windows 7 virtual environments and requires a Windows 7 64-bit image to be installed on the appliance.

The WF-500 locally analyses unknown files, plus files and URLs found in email.

The advantage being that these files will never leave your network.

The WF-500 does not support scanning of APK files.

The WF-500 locally generates antivirus signatures and categorises URLs.

The administrator can choose whether to automatically forward malware files to the public cloud for signature generation.

The WF-500 appliances supports the WildFire XML API.

Content updates to the WF-500 are provided daily, helping to imrpove analysis accuracy. Trusted code-signing certificates, malware domain lists, new signatures are examples of content packages provided to the WF-500 via updates.

The WF-500 can be configured to provide automatic download and installation of WF-500 content packages, or can be manually accomplished by an administrator.

Hybrid Cloud

The Hybrid Cloud combines the public and private cloud solutions.

If a WF-500 applioance is used, a WildFire hybrid cloud can be enabled that lets the WF-500 analyse sensitive file types locally, whie less sensitive file types are sent to the WildFire public cloud.

Files that are not supported on the WF-500, such as APK, can be set to be forwarded to the public cloud.

If public and private cloud solutions have configuration overlap, the private cloud analysis will prevail.

WildFire Appliance Cluster

Up to 20 WildFire appliances (WF-500) can form a WildFire appliance cluster on a single network.

Clusters are useful where the WildFire public cloud can not be used.

The larger clusters have better support for a larger firewall deployment on a single network over the capability a single WildFire appliance provides.

Wildfire clusters also provide fault tolerance, and a single signature package is provided to all firewalls connected to that cluster.

Encryption can be enabled on appliance clusters too, beginning with PAN-OS 8.1.

Encryption can be switched on to maintain confidentiality of transmitted content.

Clusters can be operated in a FIPS/CC environment where they are configured using FIPS/CC compliant certificates.

WildFire Analysis Profiles

WildFire analysis profiles are objects that are added to security profile rules that are configured with an action of “allow”.

WildFire analysis profiles are not required for security profile rules with the deny action, because no further processing is needed of traffic that will be dropped.

WildFire Analysis are applied to all packets during the life of a session.

WildFire anaylsis profiles represent additional security checks on files in allowed network traffic.

WildFire analysis profiles allow more granular control over allowed traffic.

An example is that the firewall can be configured to submit files to Wildfire only when a specific file type is matched, and they are transferred in a specific direction by a specific application.

Files submitted by WildFire are logged to Monitor -> Logs -> WildFire -> Submissions

The firewall contains a pre-defined, read only default WildFire Analysis Profile.

It can be customised by creating a new WildFire profile, or cloning the default profile and editing that clone.

The default profile rule sends all unknown files from any applications allowed by the rul,e to the WildFire public cloud for analysis.

WildFire Reporting Overview

Each time that the WildFire technology analyses a file or URL link, it will report it’s finding to the firewall.

The administrator can configure the information submitted to WildFire and the amount of information that is returned to the firewall in the report.

Information reported back to the firewall is recorded by the firewall in the WildFire submissions log.

Objectives:

Describe the benefits of decrypting traffic

Define the three decryption types that can be configured at the firewall

Describe how a certificate chain of trust is used to authenticate a device, service, or person

Configure an SSL Forward Proxy

Review Traffic logs to determine whether SSL sessions are being decrypted

Why decrypt network traffic?

More traffic is being encrypted. Palo Alto firewalls offer the capability to decrypt and inspect network traffic for visiblity, control, and granular security. Decryption on a Palo Alto networks firewall includes the capability to enforce security policies on the decrypted traffic, where otherwise the encrypted traffic would not of been blocked since it could not be inspected. Decryption on a firewall can also prevent malicious content from entering the organisations network or preventing sensitive information from leaving the ogranisation as encrypted traffic.

The Palo Alto fireweall can decrypt both SSHv2 and SSL/TLS inbound and outbound traffic.

SSL/TLS Overview

The SSL/TLS protocol encrypts an HTTPS connection between a client and a server where no pre-existing secure channel was previously present.

The client requests an SSL connection to the server, the server responds with it’s certificate that ther client P.C. then verifies. The client uses that public certificate to send an encrypted session key, and the server begins encrypted server communications with the client.

The communication between the two devices may periodically need to re-establish the connection and rekey the communcation.

Perfect Forwarding Secrecy, PFS, prevents former sessions from being decrypted if the private key is discovered.

Support for the Palo Alto firewalls to inspect PFS traffic on SSL Forward Proxy was introduced on version 7.1 of PAN-OS, and SSL Inbound Inspection was added in PAN-OS 8.0

Firewall Decryption Types

SSL Forward Proxy (Outbound)

The SSL Forward Proxy on the firewall decrypts SSL traffic between an internal host and the external web server.

The firewall acts as an SSL proxy essentially.

A connection is formed between the internal client and the firewall, and a seperate SSL connection is formed between the firewall and the exteral web server.

SSL Inbound Inspection

SSL Inbound inspection decrypts SSL traffic coming from external users to internal servers

The administrator must have access to the servers private key and certificate

The firewall decrypts and inspects only the traffic flowing through it

SSH Inspection

SSH Decryption decrypts outbound and inbound SSH traffic.

if an SSH tunnel, port forwarding, is discovered the SSH conenction is blocked to ensure it is not being used to tunnel disallowed applications and content

A decryption policy can be attached to security policy rules to control normal, non-port forwarded SSH traffic.

Public Key Infrastructure

The PKI solves the problem of verifying the identity of a public key owner.

PKI is the set of hardware, software, policies, and standards used to create, manage, distribute, and revoke public keys and digital certificates. A PKI digital certificate is a method of packing and distributing publuc keys in a way that proves identity of their owners. Palo Alto supports X.509-format certificates

A PKA certificate authority provides serviers that can authenticate people, devices, and services by issuing the certificates that can confirm their identity and public key.

Certificate Authoritys are arranged in a heirarchical order, similar to a file system. The root CA’s form the top level of the hierarchy and the intermediate CAs form the second and lower levels.

An intermediate CA is certified by a root CA to issue certificates or certify additional lower level intermediate CAs. Each CA has a database of certificates that stores certificates, revokes certificates, stores certificate requests and issues certificates.

Devices use their own certificate store to keep their private keys and certificates they have been issued. They can also maintain a list of trusted certificate authorities here. This list of trusted authorities can be updated by a user of it a device recieves new trusted certificate authorities via a software update.

If the certificate of the issuing certificate authority is not trusted by a client device, the client will recieve a warning message when it sees a certificate verified by that untrusted certificate authority.

Certificate Train of Trust

• Root CA
  • Intermediate CA
    • Device Certificate

The Root CA certificate is always signed by the root certificate authority itself.

The device can verify the owner of a public key if the devices list of trusted certificate authoritys includes a root certificate authority in the chain of trust

Certificate Facts

An issuing CA computes a hash value of the critical information in a certificate and that includes the hash value in the certificate.

The receiving entity can recompute and compare the hash value to ensure the certificate has not been tampered with by a malicious third party

The prevent tampering of the hash value and other critical information, the issuing CA encrypts the information with its own private key. The receiving device uses the issuing CAs public key to decrypt this information to recompute and calculate the hash value. Because only the issuing CA themselves only know their private key, the encryption of the digital certificate information is the act of digitally signing the certificate.

Palo Alto Features using certificates

• SSL/TLS decryption
• Management interface user authentication
• Global Protect
  • Portal Authentication
  • Gateway Authentication
  • Mobile Security Manager authentication
• Captive Portal user authentication
• IPSec VPN IKE authentication
• High availability authentication
• Secure syslog authentication

Certificate and Revocation Checking

All certificates in a chain of trust must be checked before an SSL/TLS connection can be considered to be secure

1. Determine the certificate chain of trust
2. Validate each certificate
   1. Signature valid?
   2. Date range valid?
   3. Not malformed or corrupt?
3. Check the revocation status

If the signatures are valid, check the revocation status of each certificate in the chain using CRLs and OCSP.

The certificate may be revoked before it’s intended expiration date because the certificate owners private key might have been compromised, hostname or username of the certificate owner may of also changed. The host could of been retired, a user left the company, or a counterfeit or leaked key may need to be invalidated.

Certificate Signing Request Process

1. Applicant creates public and private key pair
2. Applicant signs (encrypts) identity information using the private key
3. Applicant sends signed information and public key
4. CA returns the signed certificate

Advantages of this setup is the private key never leaves the device, and the device is part of a chain of trust.

The disadvantages to this setup is the device needs to be capable of generating a CSR, plus there is some administration overheads.

Certificate Management in the Web Interface

The web interface gives several options for certificate management:

• Generate certificates
• View certificates
• Modify certificate use
• Import and export certificates
• Delete certificates
• Revoke certificates

Firewall CA Certificate Deployment Choices

Each certificate can be authorised for different uses. A signing certificate must be a CA certificate. The firewall requires a signing certificate to support features such as SSL Forward Proxy or GlobalProtect.

Option 1.

You can obtain the firewall certificate from a third party CA.

Advantage:

The third party CA certificate is more than likely already signed by a trusted root CA, that will work with clients without error

Disadvantage:

Most third party CAs do not issue signing certificates, and signing certificates are required for SSL operation

Option 2.

If you already have deployed an internal CA, you can issue a signing certificate to the firewall.

The advantage here is the end devices in the enterprise likely already trust the CA certificate since it’ll be added to their stores

Option 3.

If a self-signed CA certificate is generated, the firewall can generate any other required certificates.

The disadvantage here is the self signed CA cetificate will not be trustedf by any of the end clietns until the CA certificate is added to their trust stores.

There are automated methods that exist to distribute CA certificates to multiple clients

Generate a CA certificate using CSR

If an internal CA is present, it can be used to help sign a firewalls certificate.

To creat the public and private key, plus CSR using the web interface, ensure the External Authority (CSR) is selected in the Signed By field.

If the certificate will be a certificate capable of signing over certificates, then select the Certificate Authority check box.

The common name must be the FQDN or IP address of the firewall.

An OSCP responder can also be set for the certificate, and a variety of certificate attributes can be set to further identify the owner of the certificate.

Once all the fields have been filled out as required, click the generate button. A new but unsigned certificate will appear in the certificate management window.

Export the certificate in it’s csr file form, and import to your CA.

The CA will sign the file and return it in a .pem format, import this into the Palo Alto firewall with the same name as the existing .csr file to replace it

Import a CA certificate

A firewall CA certificate and public/private key pair can be created on an internal CA and imported into the firewall.

Use the import button the certificates page to import a CA.

A PKCS12 file contains both the certificate and private key in the same file.

A PEM file containing the certificate will not contain the private key, and may need to be uploaded from a seperate file.

Certificate Hierarchy

PAN-OS organises the certificate lists as a hierarchical list, to help simply administration

Forward Proxy Decryption

SSL Forward Proxy decryption decrpyts and inspects SSL/TLS traffic from internal users to external web servers

It prevents malware concealed as SSL encrypted traffic from being introduced to an organisations network

The firewall dynamically chooses a key size to use to establish an SSL foreward based session for a client. A static key size can be configured for SSL Forward Key sessions between the firewall and the clients regardless of the key size used on the destination server.

Be aware of the validity date on the firewall certificate is taken from the validity date on the server certificate. The firewall acts a proxy for the SSL connection, but not the underlying traffic.

Packet capture functionality executes before decryption, which means the packet capture file will contain encrypted data.

Forward Trust and Forward Untrust Certificates

If a server certificate is trusted, the firewall signs a copy of the server certificate with a forward trust certificate.

If the server certificate is untrusted, the firewall signs a copy of the server certificate with a forward untrust certificate.

This is the workaround to if a user visits a site with an invalid SSL certificate

Configuring Forwarding Certificates

The first step to configure SSL forward proxy is to configure a forward trust certificate on the firewall.

The forward trust cetificate needs to be signed by an internal CA or a firewall CA.

The firewall can also create a self signed forward trust certificate, but every client will need to have a copy of the self signed CA cert in their trusted store.

Configuring a Forward Untrust Certificate

A forward untrust certificate is recommended, and should not be trusted by SSL clients.

It shouldn’t be issued by a trusted CA, nor copied to a SSL clients certificate store.

A quick way to get a cetificate matching these requriements is generate a new self signed certificate on the firewall.

Configuring SSL Forward Proxy Policy

The rules are parsed from top to bottom, in the section Policies -> Decryption

When traffic matches a particular rule, the actions defined in that rule are taken and the processing through the list of rules is stopped.

Not all traffic should be decrypted, some legally should not be decrypted, depending on local laws and regulations concerning health records, financial records and other privacy concerns.

Forward Proxy Decryption Profiles

The firewall prcoesses and inspects HTTP/2 traffic by default.

The application layer protocol negotiation, or ALPN, is used secure HTTP/2 connections.

If no value is specified for the ALPN TLS extension, the firewall downgrades the HTTP/2 traffic to HTTP/1.1 or classifies the traffic as unknown

HTTP/2 inspection can be disabled by slecting the Strip ALPN check box

The decryption profile enables checks to be performed on the decrypted traffic and specify traffic that is to be excluded from decryption.

The decryption profile allows the administrator to block sessions using unsupported protocols, cipher suites, or sessions that require SSL authentication.

The sesions can be blocked based on certificate status, for example the certificate has expired or signed by a non trusted CA.

Sessions can also be blocked if resources are not available or if the hardware security module is not available to sign certificates

Creating security policy rules

Create two rules, one that allows web-browsing and the other that permits ssl.

Once allowed through and decrypted, the firewall may identify the ssl application as some other application, such as web-browsing.

The web-browsing rule should be specified to allow access over both ports 80 and 443. The application default port for web browsing is just ports 80 and 8080.

SSL Inbound Inspection Overview

The Palo Alto firewall can inspect inbound SSL traffic for potentional threats from external hosts to internal SSL enabled servers

The session can be controlled with security policy rules and security profiles

The administrator just needs to import the same certificate and private key as the server into the firewall.

The firewall can listen in to the secure session since it has the same private key and certificate as the internal server.

Unsupported Applications

Some applications may not work with SSL Forward Proxy

Such as:

• applications that use client-side certificates
• Non-RFC compliant appliactions
• servers that use unsupported cryptographic settings

The applications that detected as unsupported, fail into an excluded cache so decryption is not attempted again until 12 hours after the first occurance.

You can display items in this cache, by using the CLI command:

show system setting ssl-decrypt exclude-cache

The command output will give a reason too on why the decryption had failed

Decryption Port Mirroring

This feature will export decrypted flows out of a dedicated interface on the firewall.

The uses include network forensics and data loss prevention. Tools such as NetWitness or Solera.

Decryption port mirror is only available on the PA-3000 Series, PA-5000 Series, and PA-7000 series and requires a free PAN-PA-DECRYPT licence to be installed for it to be enabled.

Decryption Broker

The firewall can also provide a central point for decrypting all of the network traffic.

The decryption broker allows the firewall to forward plain, cleartext traffic to a security chain for additional enforcement.

Providing a clear visiblity into network traffic.

The securitry chain is a set of inline, 3rd party appliances dedicated to perform specific security functions such as IPS. A single firewall can distribute decryption sesions of up to a maximum of 64 security chains. The firewall can monitor these to ensure they are processing traffic.

The security chain can return the allowed traffic back to the firewall.

The decryption broker is only supported on PA-7000 Series, PA-5200 series, or the VM-Series devices.

Hardware Security Modules

Hardware Security Modules are devices designed to safeguard security keys.

It generates, stores, and manages digital keys, providing logical and physical protection of the firewalls private keys from nonauthorised use.

Dedicated hardware security modules can be used to manage certificate signing functions for SSL Forward Proxy, SSL Inbound Inspection, and master key storage

HSM support is generally required when FIPS 140-2 level 3 protection for CA keys is required

Palo Alto firewalls can be used with SafeNet Luna SA 5.2.1 or Thales nShield Connect

Hardware Security Module use is supported on the PA-3000, PA-5000, PA-700 Series firewalls. This includes the VM series firewalls too.

It’s supported on the Panorama VM, and Panorama M-100 and M-500 devices too.

Objectives:

Describe how the firewall uses PAN-DB database to filter user access to websites

Configure a custom URL filtering profile to mimimise the number of blocked websites between trusted zones

Configure safe search and logging options

Configure access to only enterprise versions of SaaS applications

The URL Filtering Feature

Palo Alto networks maintns a PAN-DB URL filtering database that groups websites into categories.

If a Palo Alto networks firewall has a valid licence it can use this PAN-DB database to filter user access to websites.

PAN-DB groups similar URLs into categories, for example a group of urls may come under a category of ‘internet-portal’ which would block the likes of Yahoo if the administrator chooses to deny access to it.

An administrator can also create their own URL categories with a match criteria in firewall policies, even if the firewall does not have a URL filtering licence.

URL filtering can be used in Authentication, Decryption, QoS and Security Policies

The initial cache database of URLs is created from a seed database file from a PAN-DB cloud server.

The cache size is dependant on the firewall model, but can range from a few hundred thousand to a few million unique URLs

This cache is backed up to disk every eight hours, and after the firewall is rebooted by the administrator.

Cached entries expire based on timeouts included in the database for each URL, these are not configurable by the administrator.

If the URL is not found from within the cache, the firewall will contact the PAN-DB cloud servers for the loopup. The firewall will cache these URLs to speed up future lookup attempts.

Nightly updates of URL filtering are not required due to this on demand nature of URL filtering.

URL filtering can be applied to SSL encrypted traffic even if traffic is not decrypted. The URL category can be matched to a scurity policy rule as the URL information will be seen in clear text.

App-ID will classify this data stream as SSL too.

URL Category: Policy compared to Profile

If a URL Category is configured as part of a policy:

• Used as a match condition
• URLs are matched to a predefined or custom URL
• Actions are determined in the policy rule
• URL category name is logged in the URL filtering log

If a URL category is configured as part of a Security Profile:

• Applied to traffic allowed by security policy
• URLs are matched to block or allow lists, predefined or custom URL categories
• Action more granulary configured for individual or URL categories
• URL details are logged in the URL filtering log

URL Filtering Log

Access of a URL that matches a URL or URL category configured with alert, block, continue, or override actions will result in an entry in the URL filtering log,

The actions that require user interaction, the continue or override options, the firewall logs the initial blocking action and the succesful user action.

If the user clicks continue on a prompted page, the firewall will add block-continue and continue log entries

URL Filtering Security Profile

The Palo Alto firewall contains a pre-defined read only default URL filtering profile.

The default profile can not be modified or deleted.

To modify or adjust options, the default profile can be cloned or a new URL filtering profile can be created altogether.

URL filtering profile allows the administrator to control and monitor how users access the web over HTTP or HTTPS

The default profile is configured to block websites such as known malware sites, phishing sites, and adult content sites.

Between trust zones, the number of blocked websites could be less than what is between untrusted zones.

Remember, in a zero trust setup, no zone is completly trusted!

Multi-category and risk based url filtering

PAN-DB can assign multiple categories to websites, categories are based on how risky the website is, it’s content and purpose.

The security related categories are:

• high-risk
• medium-risk
• low-risk
• new-registered domain

Websites in the newly registered doamin category are domains which were created in the last 32 days.

The three levels of high, medium, and low risk indicate the level of suspicious activity detected on the website, but has not yet been confirmed as a malware or phishing site.

When a security policy is created based on a security related category, the firewall enforces the risky sties regardless of the website content or function.

For multicategory and risk based URL filtering, the firewall needs to connect to the beta PAN-DB server

URL Filtering Response Pages

HTML block pages have a size limit of 16 kilobytes.

They are displayed in a users browser when they attempt to access a URL or URL category with a configured action of ‘block’, ‘continue’, or ‘override’.

Each page will include the users IP address, the URL they are trying to access, and the URL category.

The users IP address is replaced with their username if User-ID technology is enabled.

If a user succesfully uses the continue or override response page, they have access to that overriden category for 15 minutes, and is not presented the response page again.

The override duration can be adjusted at Device -> Setup -> Content-ID -> URL Filtering

The override password is set at Device -> Setup -> Content ID -> URL Admin Override

URL filtering reponse pages in a layer 3 enviroment require the configuration of a layer 3 interface on the firewall, with an interface management profile configured to allow response pages.

Response pages can also work in a virtual wire configuration.

Safe Search and Logging Options

Safe search is a best-effort setting in web browsers that is used to prevent sexually explict content from appearing within search results.

It is the search provider and not Palo Alto that determines what is explict. The capability of the firewall ensuring that safe search is selected is provided with weekly application and threats content updates.

Safe Search enforcement if enabled prevents users who use google, yahoo, bing, yandex or youtube from viewing search results unless their browser is configured with the strict safe search option.

Users will see a URL filtering block page in their browsers if this feature is enabled.

If SSL is in use, decryption must be activated to enforce safe seraching.

If the log container page option is enabled, only the URL of the main container page is logged, and not the URLs of subsequent pages that might be included within the container page. URL filtering generates many log entries, so this option is recommended to be aenabled.

A HTTP request header might include the attribute-value pairs user-agent, referer, or x-forwarded-for. These attribute value pairs can be logged by enabling their corresponding options in the URL filtering tab. Enabling these supports the analysis of indications of compromise.

Configure Credential Phishing Prevention Method

Palo Alto firewalls can identify and prevent in progressing phishing attacks by controlling websites where users submit corporate credentials based on the sites URL category.

This allows access to be controlled to phishing websites blocking users from submitting their credentials to untrusted websites, but allowing users to submit their credentials to corporate and authorised websites.

Before configuring, the administrator should devide what method they want to use for the firewall checking the credentials submitted to webpages are valid. Each method requires the configuration of User-ID technology.

Use IP User Mapping / Use Group Mapping

These two technologies check for submission of a valid username only. The firewall blocks or allows, based on the settings, the submission of the username with any password submitted. Essentially it checks for the username only but does not regard the password.

Use Domain Credential Filter

This method checks for valid passwords submitted to a webpage.

IP User Mapping – The firewall uses IP address to user mapping that the PAN-OS integrated User-ID collects to check if a username submitted to a webpage matches the username of a logged-in user

Group Mapping: The firewall agent collects group mapping information from a directory server and retrieves a list of groups and group members. It compares usernames from these groups to usernames submitted to a webpage.

Domain Credential Filter

The Windows Based User-ID agent is installed on a read only domain controller, or RODC. The user ID agent collects password hashes that correspond to users for which credential detection is to be enabled for. The firewall checks if the source IP address matches to a username and password submitted to a webpage belongs to that username. In this mode the firewall can block or alert on the submission only when the password entered matches a user password.

HTTP Header Insertion and Modification

Software as a service, or SaaS are prone to data exfiltration through consumer version so the application. Firewalls can now perform HTTP herader insertion as a way to enable access to the enterprise version whilst blocking access to a consumer version of software. HTTP header insertion occurs when an identified header is missing from a request. If the header exists, it is overwrriten with the value that the administrator has defined.

HTTP header insertion can be based on several pre-defined types. These are: Dropbox, Google, Office 365 and YouTube. If the administrator wishes to perform HTTP header insertion for an application that is not predefined, the administrator can create a custom HTTP header type. It can also be created to modify standard HTTP headers.

Handling Unknown URLs

A URL matched to the unknown category means it has not yet been catagorised, so does not yet exist in the filtering database on the firewall or in the URL cloud database. Although the action may initially be set to alert for unknown websites, good practice would be considering to block access to unknown websites, and only allow access to permitted categories of websites

Handling Not-Resolved URLs

A URL matched to a not resolve category was not found in the URL filtering database, and the firewall was unable to connect to the cloud to check the category. Configuration of the block action for not-resolved may be disruptive to end users. You could configure it to be alert, so that users are not blocked by the policy but log entries are generated to alert an administrator that URLs are not being resolved to URL categories.

To verify Pan-DB cloud status, the following CLI command can be entered, it should show connected:

show url-cloud status

A symptom of the problem is due to a lack of CPU resources, the system resources widget on the dashboard could confirm this.

Objectives:

Define application identification

Describe four major technologies to help identify applications

Configure application filters and application groups

Detect unidentifeid applications that traverse the firewall

Configure scheduling to Application ID

What is an application?

An application is a specific program or feature whose commuinications can be labeled, monitored and controlled

Applications will include business tools and services, which may need to be permitted. Blocked applications might include personal services

Applications can be delivered to the client via a web browser, a client to server model, or a peer to peer design.

What is App-ID?

App-ID is a technology that uses multiple identification mechanisms to determine the exact identify of applications that flow through the firewall

App-ID is a relied upon technology, since accurate traffic classification should be a primary function of any firewall.

The security rules within a Palo Alto firewall can specify whether to block or allow applications.

This is more advanced in comparison to a traditional firewall, which may block by port or protocol.

A traditional firewall can easily be bypassed with todays technologies and methods. Such as using SSL and SSH traffic encryption, sneaking other protocols and applications across port 80 or using non standard port numbers.

With the use application filter security policy rules, and enforcing applications to use only their default ports. The Palo Alto can enforce only DNS traffic to go across DNS known ports, rather than say bit torrent or a command and control server.

App-ID and UDP

A Palo Alto firewall that examines UDP packets can only identify a single packet in order to identify the application.

In most case, the first packet transmitted has all the information needed for a Palo Alto firewall to identify the applications.

UDP-Lite is very similar to to UDP, but can servce applications in error prone network enviroments that prefer to havbe damaged payloads delivered rather than discarded

App-ID and TCP

When it comes to TCP, the Palo Alto often needs to examine multiple packet transfers to identify the application. The first packet sent is a TCP SYN packet, and whilst containing the source and destination address and ports, it contains no application data.

The next two packets that follow on, SYN-ACK, and ACK, do not contain any application data ethier. It is all part of the three way handshake TCP uses to establish a data connection.

The application data likely follows on after the ACK, for example in a HTTP GET request or the reply from the server.

The firewall may have to wait a few more packets to be able to sufficently identify an application, or detect the data as encrypted.

If the data is encrypted, the network administrator may need to use a decryption policy to decrypt the HTTPs session and identify the application.

Identifying Applications

The Palo Alto APP-ID technology uses four internal component technologies to help identify technologies.

These are:

Application Signatures

A database of signatures of applications updated when the firewall grabs its content updates

Unknown Protocol Decoder

A heuristics engines that examines the patterns of communication. It attempts to identify the application based on it’s network behaviour. This type of detection is used for applications that encrypt from end to end ssuch as Skype or BitTorrent

Known Protocol Decoder

A set of application decoders that understand the syntax and terminlogy of common applications

Protocol Decryption

SSL and SSH decryption capabilities

Application ID Operation

Network traffic is initially classified based on the it’s IP address and port.

The firewall then consults the security policy to determine whether to allow or block the traffic based on the IP address and port. During this initial check, the application is set to any.

If traffic is allowed, a session is created and App-ID begins looking for an application signature. The firewall uses it’s known and unknown protocol decoders to attempt to identify the application.

If the App-ID engine determines that SSL or SSH encryption is in use, and a decryption policy has been configured, the traffic flow could be decrypted and the unknown and known protocol decoders can be put to work on the decrypted traffic.

If the application signature at this point still can’t be identified, the application will be unknown-tcp or unknown-udp based on the transport protocol.

Once the application has been identified, the firewall checks the security policy rule to determine whether to block, allow, or allow and scan for threats on the traffic.

Application Shifts

Network traffic can change from one application to another during a session

When a web browsing session starts, it may be identified as web-browsing, then to SSL.

Once application I.D. gets a further idea on the patterns and volumes of data being transmitted, it may then further clasify the application to such as facebook-base or facebook-chat

Dependant Applications

Some applications can depend on other applications during network shift during the lifetime of a session.

It is important that if these applications are to be permitted, that they are included in your security policy rules

In an example, in Rule 1 web-browsing may be permitted.

If the application type changes to Microsoft Office on demand, a rule will need to be created that permits Office365 on demand.

If this is not included, the user may have a negative web application expeirence.

Implict Applications

For many of the dependant applications, the app-id database implictly allows the required parent application without the need of the network administrator to add the parent application to the security policy.G

Going back to the Facebook rule, adding the facebook-base application would implictly turn on the require web-browsing rule to the security policy.

App-ID defines implict dependants because the addition, of say the web-browsing rule, could allow more traffic through the firewall than intended.

Implict permissions are only processed if a explict security policy rule for the parent application has not been added.

The implict support applies to custom applications too, based on HTTP, SSL, MS-RPC or RTSP.

Application Filters

An application filter groups applications based on attributes that the administrator selects from the App-ID database.

The attributes that can be selected are Category, Subcategory, Technology, Risk, and Characteristic.

Application filters can be useful when access to applications needs to be defined by say risk, or technology rather than matching specific applications.

New applications are classified by Palo Alto, and added to the App-ID database with values for Category, Subcategory, Technology, Risk, and Characteristic.

New applications that are added will automatically match with the application filter defined.

Application Groups

An application group is a static, created by the administrator, defined set of applications. Groups allows the logical grouping of applications that can be used in Security, QoS, and PBF rules.

A group can be used when the network administrator wishes to treat a set of applications in a similar way in a policy.

Groups ultimately simply the administration of a rule base.

When planning application groups, network administrators should consider how they want the groups to be enforced for access, and create seperate groups accordingly for seperate actions.

Nesting Application Groups and Filters

An application group can be manually configured to contain, applications, and application filters plus other application groups

Application Block Page

For applications that are web based and blocked, the Palo Alto can displayaa response page in the users browser.

The default response page includes the prohibited application name, and the users name if the user id feature has been enabled.

If the user id feature has not been enabled, an IP address is displayed instead.

Application block response pages need to be enabled via an interface management profile.

A custom HTML page can be crafted and uploaded.

Unknown Network Traffic

If APP-ID cannot identify an application, it will display in the Monitor -> Logs -> Traffic section as unknown-tcp or unknown-udp.

The only exception to this rule is HTTP, which if unidentified will be displayed as web-browsing

Identifying Unknown Application Traffic

Create rules to allow or block applications known to be flowing through the firewall

Create a temporary rule to detect new unidentified applications flowing through the firewall

Controling Unknown Applications

Create a custom application with a custom signature

Use network packet capture to identify unique bit a patterns in the application

Create a custom application signature to match that bit pattern

Use the custom application in a Security, QoS or PBF policy rule

Configure an application override policy

An application override policy rule can be used to identify custom application traffic based on it’s source zone and IP address, it’s destination zone and IP address, and it’s port and protocol.

This prevents the firewall using App-ID to process the Layer 3 data.

Application override also disables the security profiles

Block unknown-tcp or unknown-udp traffic

The unknown-tcp or unknown-udp traffic seen inside an organisation is normally benign. It could be a custom developed back up script or maintenance task

Unknown-tcp or unknown-udp that appears in sessions going out or coming in to the network should be suspect.

The traffic should be attempted to be verified using the traffic log and packet captures

Updating APP-ID

App ID’s can be scheduled to:

• Download Only
• Download and Install

Alternativelly, they can manually downloaded and installed at any time to suit the administrator.

Updates to the App ID database are released nearly every week