Categories
EDU-110 Study Palo Alto

Palo Alto EDU 110: Security and NAT Policies

Objectives:

  • Display and manage security policy rules
  • Describe the difference between implicit and explicit rules
  • Create a security policy
  • Describe the difference between source and destination NAT
  • Configure source NAT
  • Configure destination NAT port forwarding
Flow logic of a next generation firewall

Controlling Network Traffic

All traffic flowing through the data plane of the Palo Alto firewall is checked against a security policy.

The traffic matching does not include any traffic originating from the management interface of the firewall as it does not pass through the data plane of the firewall.

Security rules can be defined on the firewall using various criteria such as zones, applications, IP addresses, ports, users, and host information profiles.

Sessions and Flows

The Palo Alto firewal is a stateful firewall. A stateful firewall matches all traffic passing through the firewall against a session with a I.D. number. Each session is then checked against a security policy rule.

Each session is idenitfied by a six tuple consisting of:

  • Source and destination IP address
  • Source and destination port numnber, For non-UDP/TCP traffic, different protocol fields are used
  • Protocol
  • Source security zone

The end point where the traffic was initiated will always be identified as the client. The endpoint where the traffic from the client is destined too is known as the server.

When security policy rules are defined, only the direction of the client to the server should be considered. Return traffic is automatically permitted by the Palo Alto firewall.

Security Policy Rule Types

Three different tyypes of rules can be defined within a security policy.

The rule type specifies whether a rule applies to traffic within a zone, between zones, or both.

Intrazone applies all traffic within a specific zone. A destination zone can not be applied for an intrazone rule

If multiple source zones were applied, the rule apply to traffic with a source and destination of the same specific zone

An interzone rule applies to all matching traffic between the specified source and destination zones, but not traffic within the same zone.

A universal rule applies to all matching interzone and intrazone traffic in the specified source and destination zones.

Implict and Explict Rules

The firewall implictly allows intrazone traffic and denies interzone traffic.

Explict rules must be created to control all other traffic, above the order of the two implict rules.

The interzone default rule saves the need for the network administrator to create a rule that blocks all traffic not defined by a security policy.

The intrazone and interzone rules do not log traffic, however the Palo Alto recommendation is to log all traffic. So it is recommended to turn on logging for the implict security rules

Note, a placement of an explict deny all rule at the end of the explict rules may negatively effect firewall performance. The reasoning behind this is a explict deny all rule would be above in order to the implict permit between intrazone rule.

Security Policy Match

Security Policy rules are evaluted for a match from top to bottom.

The policy rules themselves are unidirectional, from source zones to destination zones. So if traffic is intended to be initiated in both directions it is recommended to have two policy rules

It is recommended to reduce the use of ‘any’ when defining security rules

Policy Rule Hit Count

An administrator should regularly review, identify, and determine rules that are being used freqently and what rules are unused and are to be removed.

Hit counts can be reset to validate the usage of an existing rule over a given period of time.

Hit count data also incluides the number of traffic matches, timestamps, number of applications seen, and the number of days with no new applications seen.

Rule Shadowing

Rule shadowing is when an above rule casts a shadow over further rules in the evaluation order, ethier by casting too wide a net for further rules to ever be evaluted for traffic matching

Universally Unique Identifers (UUID)

UUIDs are created when a security policy rule is made. The UUID helps to provide a complete audit trial that keens a history of the entire operational history of a rule from the time of its creation.

UUIDs were created since previous to PAN-OS 9.0, if a rule was renamed it’s history was lost forever.

The UUID allows history regarding the firewall rule to be kept no matter how many changes are made to it.

Finding Unused Security Policy Rules

Administrators from time to to time should inspect their security policy rulebase, cleaning up unused rules.

This can be performed easily by checking the ‘Highlight Unused Rules’ checkbox in the Security Policies section of the fireewall.

This option can also be used when it comes to troubleshooting a firewalls security policy.

Tag-Based Rule Groups

In PAN-OS 9.0 the tag browser is replaced with the ability to assign rules to tag groups.

Once rules are assigned to a tag-group, the rulebase can be viewed as a tag group to visually group rules based on the tagging structure created.

When the rule base is viewed as groups, operational procedures such as adding, deleting, or movement of the rules can be carried out within the tag group for easier management of the rule base

Rule tag groups are displayed in the same order as rules in the rule base. A single tag group may appear multiple times throughout the rule base to preserve rule hierarchy.

Using Global Find

The candidate configuration and content databases can be searched for a particular string when using global find

This can include IP addresses, Object names, Policy rule names, Threat IDs, and Application names.

The global find does not search dynamic content such as logs, addresses ranges, or allocated DHCP addresess.

It also does not search individual username or group names that are identified by User-ID.

Rule Changes Archive

Clicking the Audit Comment Archieve link in the properties of a security policy rule, allows the administrator to view audit comment history and configuration log history between commits.

Configuration versions can be compared to allow the administrator to see what has been changed in the security policy.

Test Policy Functionality

Policy rules and managed device configurations can be tested to ensure that candidate configurations are correctly securing the network, and connectivity can be checked to ensure network resources can be reached.

The test security policy match allows a set of test criteria to be entered, and it is evaluated against the current security policy for a match or not.

NAT Types

Source NAT

Source NAT is used for private users to access the public internet, outbound traffic

Destination NAT often is used to provide hosts on the public internet access to private servers.

For source and destination NAT, the firewall maintains the mapping of pre-NAT to post-NAT IP addresses

Source NAT

Source NAT changes the source address of the packets that match the NAT policy as the packets go through the firewall.

Source NAT is used to allow host devices configured with private IP addressing to send and receive traffic on the publicaly address internet

Source NAT Types

Static IP

Static IPs are a 1 to 1 fixed translation.

It changes the source IP address, leaving the source port unchanged.

The static IP NAT type supports the implicit bidirectional rule feature

Dynamic IP

1 to 1 translations of a source IP address only, no port number.

Private source addresses are translated to the next available address in the public IP range.

Dynamic IP and Port

Allows multiple clients to use the same public IP addresses with different source port numbers.

The assigned address can set to an interface address or a translated address.

Dynamic IP and Port Oversubscription

The TCP protocl recognises around a maximum of around 64,512 available ports, subtracing 65,536 from 1024 well known ports.

Some PAN-OS platforms support DIPP NAT oversubscription, allowing the use of port numbers by using the destination IP address as an additional identifier for the NAT session.

The NAT oversubscription rate can be configured up the maximum rate supported by the hardware platform

Destination NAT

Destination NAT translates an original destination IP address to an alternative destination IP address.

Destination NAT attribututes

Static IP mapping with optional port forwarding

1 to 1 fixed translation, enabled by static source NAT with the bi-directional option set. This changes the destination IP address whilst leaving the destination port unchanged.

Dynamic IP address support for destination NAT

The translated address can be a FQDN, address object or group.

The translated original IP address can be set to a destination host with a DHCP assigned address.

Each FQDN can support up to 32 IPv4, or IPv6 addresses

Configuring Destination NAT

Destination NAT uses the original packet tab to define the source and destination zones of hte packets that the firewall will translate, and specifies the destination interface and type of service

NAT rules must be configured ot the use the zone associated with the pre-NAT ip addresses configured in the policy.

Traffic subjected to NAT must be permitted explicity by the security policy when that traffic traverses multiple zones.

Categories
EDU-110 Study Palo Alto

EDU-110: Palo Alto Interface Configuration

Objectives:

Describe flow logic of the next generation firewall

Create a security zone

Describe the differences between Tap, Virtual Wire, Layer 2 and Layer 3

Create and configure a virtual router

Define a static default route

Configure a VLAN interface

Configure a loopback interface

The flow logic of a next generation firewall

The diagram above shows the flow logic of a packet travelling through a Palo Alto Firewall.

If traffic is decrypted by a policy, it is re-encrypted when traffic is forwarded on from the firewall.

The policy check also checks any IP addresses before network address translation occurs

Flexible Deployment Options

Tap

Tap allows traffic to be mirrored to the firewall, allowing for application, user, and content visibility without any inline deployment.

Tap is suitable for an evaluation and audit of the existing network

The Tap interface can be connected to a core switches switch port analyser, otherwise known as SPAN, to recieve a mirror of packets traveling through the network for the Palo Alto to analyse

Virtual Wire

App-ID, Content-Id and SSL Decryption is can be used with Virtual Wire. It also includes network address translation capabilities.

VWire mode allows the firewall to be inserted into an existing topology without requiring any reallocation of network addresses or redesign on the network topology. All protection and decryption features of the firewall can be used

Layer 3

Layer 3 offers all the options that virtual wire has. In addition Layer 3 offers virtual routers, virtual private networks and routing protocols

The firewall can mix and match these interface types on a single device.

Security Zones and Security Policies

Palo Alto firewalls use the concept of security zones to secure and manage networks.

Different security policy rules are created to control traffic to and from each zone

The physical location of the zone does not matter, a single zone can be at different locations throughout an enterprise.

Descriptive zone names should be chosen that help designate specific types of business, functions, location or access privileges

By default the Palo Alto firewall allows intrazone traffic, and a denys interzone traffic

In-band network interfaces

There are three types of in-band network interfaces to allow traffic flow across and enterprise

They are labeled with the format ethernet n/n

The first type is on a single-slot firewall, where the interfaces are ethernet1/1, ethernet1/2 and so on. The second number represents the inband port.

On a multi-slot firewall, the first number represents the slot number, the second number represents the inband port

Logicial interfaces can be sub-interfaces on a physical interface, in a format of ethernet1/1.1 or ethernet1/1.2

A physical port or subinterface can only be assigned to a single zone. A zone can contain multiple physical or logical interfaces

Interface Zone Types

Tap Zone contains Tap interfaces

Layer 2 Zones contain Layer 2 intefaces

Tunnel zones do not contain any interfaces, they are used for a feature called tunnel content inspection and for a specific scenario that involves tunnel-in-tunnel encapsulation

Virtual Wire zone contains virtual wire interfaces

Layer 3 zones can contain layer 3 interfaces, VLAN interfaces, Loopback interfaces or Tunnel interfaces. All these interface types can be assigned IP addresses

HA intefaces are not used to control network traffic, and used for synchronisation of a pair of firewalls deployed in a high availability configuration. They cannot be placed in a security zone

The management interface also does not control network traffic, and is used for firewall management. It cannot be assigned to a zone

Tap Interfaces

Tap interfaces allow passive monitoring of switch traffic from the SPAN or mirror port.

The firewall cannot control or perform traffic shaping on ports where it is configured as a tap interface

If the port passes mirror traffic, the tap interface can only support SSL Inbound Decryption

Even though the firewall cannot block traffic, it can still identify the traffic

This is useful for the administrator when it comes to configuring sercurity rules on whether to permit or deny traffic

Virtual Wire Interfaces

A virtual wire interface binds two firewall interfaces together. It is typically used when no switching or routing is required by the firewall. It sits transparently between two network devices so no configuration changes are required. No MAC address or IP address is assigned to either virtual wire interface

Creating the virtual wire is completed in two steps:

  • Create the virtual wire object
  • Configure the virtual wire interfaces

It should be noted though that Palo Alto firewalls come factory preconfigured with Ethernet ports 1 and 2 preconfigured as virtual wire interfaces, allowing all untagged traffic through.

Since network traffic flows through the firewall, the firewall can examine, shape, and block traffic. The virtual wire configuration can take advantage of many Palo Alto features such as App-ID, Content-ID, NAT, QoS, SSL decryption and User-ID

A virtual wire is also known as a ‘bump in the wire’ deployment or ‘transparent in-line deployment’.

As the virtual wire is transparent between other devices, it does not support routing or firewall management traffic as no IP address is assigned to the virtual wire interface. A virtual wire configuration can also not service as a end point for a VPN tunnel

Virtual Wire Subinterfaces

A virtual wire sub-interace can read and process traffic based on several factors:

  • VLAN tags ( 1 – 4094)
  • IP classifers (untagged, traffic, source IP)
  • VLAN tags and IP classifers (source IP)

The IP classifer can be made up of a specific address, a range of addresses, ro a subnet address.

Each sub interface can be assigned to a seperate security zone, allowing granular policy controls to traffic flows arriving or leaving through the same port.

Layer 2 interfaces

A layer 2 interface provides switching between two or more interfaces through a VLAN object. This is normally used when no routing is required

To create a layer 2 interface:

  • Create a VLAN object
  • Configure the Layer 2 interfaces that the VLAN object connects too

Note that the firewall does not take part in any spanning tree protocol. The firewall does forward STP packets that arrive from external switches in the VLAN object to the other switches.

In Layer 2 mode the fireewall can support App-ID, Content-ID, User-ID, SSL decryption and QoS. A layer 2 interface does not support routing or firewall management as no IP addresses are assigned to a layer 2 interface

Layer 2 sub-interfaces

Like virtual wire, layer 2 can be divided up into sub interfaces. Sub interfaces can be assigned to different zones and security policies can be applied to them.

VLAN traffic is isolated by a sub-interface, this is caused by two factors:

  • Need routing between VLANs
  • Security policy blocks interzone traffic by default

This is a good configuration candidate for multi tenanted networks

Layer 3 interfaces

The layer 3 interface type allows routing of traffic between multiple layer 3 interfaces.

As a layer 3 interface can carry out routing, network traffic can flow through the firewall between different layer 3 interfaces. The firewall can examine, shape and block traffic as it traverses these interfaces

The routing between layer 3 interfaces is carried out by an internal virtual router inside the Palo Alto firewall

A layer 3 deployment typically takes more work as it usually requires network reconfiguration in the organisation.

A layer 3 firewall supports App-ID, Content-ID, User-ID, SSL decryption, NAT and QoS. Additionally, unlike the other interface types so far, the layer 3 interface can support management traffic and VPN traffic as it is assigned an IP address

A layer 3 interface supports IPv6 too, these can deployed seperately or as part of a dual stack configuration. The firewall needs to be enabled to use IPv6 though.

This can be turned on in Device -> Setup -> Session -> Session Settings -> [Gear Icon], click the option ‘Enable IPv6 Firewalling’

Layer 3 sub-interfaces

Similar to Layer 2 sub interfaces, traffic in each VLAN is isolated; requiring a virtual router to connect together, and security policy blocks interzone traffic flow by default.

To allow trafifc to flow between zones, appropiate security rules need to be configured.

If two seperate sub-interfaces have the same VLAN number, the firewall will use ethernet witching to pass traffic between the zone interfaces.

If two seperate sub-interfaces have different VLAN numbers, the traffic needs to pass through the virtual router on the IP layer.

Virtual Routers

The Palo Alto makes use of an internal virtual router to reach other subnets

The virtual router can be configured in several ways to reach other subnets. Using static routes, or with the use of a dynamic routing protocol.

The Palo Alto can support the BGPv4, OSPFv2, OSPFv3 and RIPv2 routing protocols. The Palo Alto can also route multicast with the PIM-SM (spare mode) v2 and PIM-SSM (source specific multicast) v2 multicast routing protocols.

Whilst on the topic of multicast, host facing interfaces have multicast support with IGMP v1, v2 and v3.

The Palo Alto firewall can be configured with multiple virtual routers, and have inter virtual router links between them.

Multiple Static Default Routes

Multiple static default routes can be configured on the Palo Alto firewall. When assigned different metrics, the route with the lowest metric is chosen for use by the Palo Alto firewall.

Path monitoring can be used to determine whether a default route is valid. If the router is no longer deemed to be valid the Palo Alto firewall will switch to the next higher metric route in it’s routing table

Path monitoring will continue to monitor all paths, even after a failure. If the path monitoring detects a lower metric default router is usable again, it will switch back to that default route with the lower metric.

VLAN Interfaces

Network interfaces that are attached to a layer 2 interface, and a vlan object can be attached to the virtual router through the configuration of a VLAN interface.

A VLAN interface can be assigned an IPv4 or IPv6 address and attached to a virtual router. This provides a path from the Layer 2 interfaces of the firewall to the Layer 3 interfaces of the firewall

Loopback Interfaces

The loopback interface is a logical non physical interface that be reached through a physical interface or sub inteface.

It behaves just like a host interface that can serve clients and is assigned an IP address.

Firewall services provided through the loopback interface could be a access point to the management web interface through HTTPs, a GlobalProtect Portal, a GlobalProtect Gateway, or an IPSec VPN tunnel endpoint.

Policy Based Forwarding

Policy based forwarding allows traffic to take an alternative path compared to the next hop specified in the routing table. They are typically used to specify an outgoing interface for security or performance reasons.

Policy based forwarding does not apply to traffic that originates locally from the firewall itself. Examples would be an IPSec VPN, GlobalProtect, or traffic originating from a virtual router

Policy Based Forwarding can be configured from Policies -> Policy Based Forwarding

These rules can be customised to specify matching criteria such as source zone or interface, source or destination IP address, application, or destination port. If the criteria is matched, the rule can be set to specify an outgoing interface

Policy based forwarding contains a feature that allows path monitoring to verify connectivity to the outgoing interface/next hop address. This allows the firewall to direct traffic through an alternative outgoing interface if the interface specified by the policy based forwarding becomes unavaiable for any reason.

An ICMP ping is used as heartbeats to verify the next hop IP address is indeed reachable.

The path monitoring / montioring profile can be configured to have a threshold number of heartbeats to determine whether the external next hop IP address is unreachable. If the monitoring profile picks up that the IP address is unreachable, the rule can be disabled or an alternative route specified. If the rule is disabled the virtual router will use it’s routing table to determine the next hop IP address to be used.

Once fail over or wait recover action is taken, the profile continues to check if the next hop IP address is reachable. If it becomes reachable the firewall will automatically revert to using the policy based forwarding rule

Categories
EDU-110 Study Palo Alto

EDU-110: Initial Configuration of Palo Alto Firewall

Objectives

Connect to the firewall and login as admin

Configure the network settings for the management interface port

Describe the difference between the running configuration and the candidate configuration

Configure dynamic firewall updates to update the applications and threats database

Create a local firewall administrative account

Access the firewall logs

Access to the firewall

The Palo Alto firewalls are built in with a dedicated out of band network management port.

This port only passes traffic for management functions of the firewall, it cannot be configured as a standard traffic interface. It can be used for direct connectivity to the management plane of the firewall.

The default IP address of the firewall is 192.168.1.1 for most physical models. The default address for virtual firewalls is set to recieve an address from a DHCP server.

Any initial configuration for a Palo Alto firewall must be performed from the dedicated mangement port, labeled MGT, or via a serial connection to the console port.

The baud rate and settings for the serial connection is 9600-8-N-1

The default username and password for the Palo Alto are:

Username: admin

Password: admin

The firewall will prompt you to change these credentials in the CLI and web interface away from the defaults.

The password for the administrator on the firewall is stored in the firewalls XML configuration file, but is encrypted using the firewalls master key.

Methods of administrative access to the firewall

There are four ways of accessing the firewalls administrative functions

Web Interface – The most common way to configure and monitor a Palo Alto firewall. The graphical web interface provides detailed administrative and reporting tools in a browser format.

SSH or Console (Command Line Interface) – The CLI allows access to the firewall to display status and configuration information. It allows modification too. The CLI can be accessed through SSH, Telnet, or the serial console.

Panorama – If multiple firewals are deployed, Panorama can be used to manage configurations, policies, software and dynamic content updates all in one place. Panorama aggregates data from all the firewalls and can display them all within the Panorama web application

REST XML API – The REST based interface allows access to operational status, reports and packet captures. Like the other methods, it allows access to configure the firewall too. The XML API can be configured to capture login events and send them to the firewall. The API is implemented using HTTP/HTTPS requests and responses. An API browser is also present on the firewall, by appending /api at the end of the firewalls URL, for example:

http://192.168.1.1/api

Reset to Factory Configuration

To reset the Palo Alto firewall back to factory configuration, if the password is known enter the CLI interface and enter the following command:

request system private-data-reset

This command will erase all logs, reset all settings, and saves a default configuration once the management IP address has changed.

If the password is not known to the firewall, reboot the firewall and whilst it is starting up, enter the command

maint

After some time, the firewall wil offer you the option to reset to factory defaults via the menu option Reset to Factory Default

Configuring the Management Interface

On the system you will access the Palo Alto, change it’s IP address to one in the 192.168.1.0/24 subnet (anything between 192.168.1.2 – 192.168.1.254)

Once the configuration has been applied, connect to the MGT port via an ethernet cable to your device

After some seconds have passed, open a web browser and navigiate to https://192.168.1.1

A Palo Alto login prompt page should appear, log in to the firewall using the default username and password of admin / admin

Once logged into the firewall, navigate to the Device -> Setup -> Interfaces section

Click Management

A window will open up, configure the network settings for the management interface as required

Commit the configuration, and reconnect to the web interface using the new network configuration

Configuring General Settings

Under Device -> Setup -> Management -> General Settings -> [Gear Icon]

From top to bottom of this pop-up window.

Hostname – An identifiable name for the firewall that can contain up to 31 characters. These characters can contain a mix of alphanumeric, hypen and underscore characters. The default hostname is the model of the firewall.

Domain Name – By default, this is empty. Can contain up to 31 alhanumeric, hypen, or underscore characters

DHCP Checkboxes:

  • Accept DHCP server provided Hostname
  • Accept DHCP server provided Domain

Login Banner, configures a pop-up message to present when logging into the Palo Alto firewall

SSL/TLS Service Profile: When SSL/TLS is in use, the firewall requires a digital certificate that wil be trusted by the clients

Long/Lang: Configure these settings to put the firewall on the map under the ACC tab

Configure DNS and NTP servers

Go to: Device -> Setup -> Services -> [Gear Icon]

DNS server configuration is required in order for the Palo Alto firewall to reach update servers

The NTP configuration is optional, but it’s recommended. It makes it easier for a human to read through the logs!

Note, if the management interface has been configured by DHCP. These values can be assigned to the firewall automatically via DHCP

The Services window also allows the domain name of the update server to be configured, to grab the latest sofrware and any updates to the threat database.

Clicking the checkbox to validate the update servers identity adds a level security between the firewall and the update server.

Service Routes

To access external services, the management port is used by default.

These external services would be:

  • Update services
  • DNS services
  • NTP services
  • Licence Retrieval
  • Panorama
  • Other external services

If the managment port is does not wish to be used for these services, an alternative port or logical interface can be configured to be used instead.

This will be configured under the panel in:

Device -> Setup -> Services -> Service Route Configuration

Configuration Types

The firewall has two types of main configuration, the running configuration and the candidate configuration.

The running configuration is the actual configuration running on the Palo Alto firewall. It’s maintained in a file on the firewall called running-config.xml

The running configuration is copied to the candidate configuration file during startup. Any edits made before a commit are made to the candidate configuration.

Once a commit has been made, the candidate configuration overwrites the running configuration.

The firewall saves the previous running configuration and labels these by a date and timestamp.

The web interface contains a set of operations that can be used to manage the running and candidate configurations.

Global Configuration Management

The Configuration Management section, in Device -> Setup -> Operations contains options for global configuration management (For all administrators changes, rather than one admin)

Revert, Save, and Load manage local configurations on the firewall

Export operations transfer configurations as XML formatted files to accessing host accessing the Palo Alto firewall through the web browser

Import operations import configurations from the host running the web browser to the Palo Alto

If a configuration is loaded or reverted from configuration management, only a full commit is possible. A full commit writes all changes made to the running configuration

Configuration Options

At boot time, the latest configuration on the hard disk is loaded to the candidate configuration in the control plane memory.

The control plane forces an automatic commit to copy this candidate configuration into the running configuration in the control plane memory.

The running configuration is then pushed to the running configuration in the data plane memory, where it used to inspect, control, and secure traffic traversing the firewall.

Any administrators that make changes to the candidate configuration and follows with a commit writes the changes in control plane and data plane memory. The firewall does automatically take timestamped backups when a commit is performed.

Saving a candidate configuration

A candidate configuration can be saved in several ways:

Navigate to Device -> Setup -> Operations

Click Save named configuration snapshot to save the current candidate configuraiton to a XML filename on the disk. Multiple named configurations can be saved this way

Click Save candidate configuration to save the configuration to memory. If edits are made and the save canddiate configuration is clicked again, the previous save is overwritten. Note that this saved configuration is stored in viotile memory and will be erased if the firewall is rebooted.

A named configuration snapshot can be loaded to replace the existing candidate configuration. The loaded file is in the format of an XML file.

Revert to last saved configuration aborts any changes to the configuration since the last save.

To delete any candidate configuration and start over, click Revert to running configuration. This copies the running configuration to a fresh candidate configuration.

Admin Level Commit

An admin level commit enables an administrator to only commit their changes to the running configuration, and not any other administrators active changes.

If Commit All Changes is selected, this commits all changes made by all administrators. This can only be selected if the administrator has the correct privileges.

A middle ground is also available, that a group of administrators changes can be commited, leaving other administrators changes alone.

Administrator Level Save and Revert

Per-admin changes can be saved without needing to commit, the icons are available on the ‘Config’ drop down on the top right section of the page.

The Save Changes icon allows an admit to save current changes and continue later without needing to commit a partially completed configuration change.

The saved changes made by any administrator are written to the same default XML file, but each change is tagged with information about the administrator that made that change.

The Revert Changes icon removes the most recent changes since the last saved candidate configuration.

There is a choice between reverting to the last saved configuration made by the administrator logged in, or the last saved configuration made by other administrators

Preview and Validate Changes

The preview changes button compares the candidate and running configurations.

Preview changes will open a window that displays a side by side comparison of the running and candidate configurations before a commit is made. Differences are coloured coded to indicate where configuration has been added, changed, or deleted.

The change summary lists the individual settings where changes are being commited

It will list object names, whether its shared, or for a specific virtual system, and whether it has been edited, created, or deleted.

The validate commit button will show any errors that may appear during a commit

The validation is performed with a syntactic and semantic validation of the firewall configuration before being commited.

The semantic validation determines whether the configuration is valid and complete. This would reduce the number of failures at a commit time.

The results will show any warnings or errors that would of been displayed on a full commit. Warnings don’t prevent a commit though.

The preview and validate commit buttons will display all changes by all administrators, or just changes made by select administrators.

Transaction Locks

Device -> Setup -> Management -> General Settings

A lock can be taken to block other administartors:

  • Commiting a candidate configuraton
  • Making changes to the candidate configuration

Locks can be removed by the administrator who created them, or by an administrator with superuser rights.

A lock can be configured to be automatically taken when an administrator logs in.

Commit and configuration locks are released automatically when an administrator commits their configuration.

Licencing and Software Updates

The process of activating the firewall is:

Register the firewall with Palo Alto Networks

  • Click Assets on the Customer Support Portal
  • Enter the serial number
  • Click Register Device
  • (For VM Firewalls) Register an e-mailed auth code to the Support account on the Customer Support Portal
    • Existing support accounts access the VM-Series Authentication Code link on the Support Portal
    • If no support account exists, use the capacity auth-code to register and create an account

Active a support licence

  • Before subscriptions can be added, the support licence must be activated. Click Device -> Support and Active Support using an authorisation code

Active the licences for each subscription that was purchased in Device -> Licences (Once support is activated)

The activation of the WildFire licence requires a commit

Before any licences can be retrieved, the firewall itself needs to go through an initial configuration of an IP address information, and a DNS server address to reach the internet.

Dynamic Updates

Updates include new anti-virus and anti-spyware definitions, new malicious domains and malicious URLs along with new application signatures. It is essential to download theses updates to the firewall to maintain the most current protection offered. A threat protection licence is required to download Applications and Threats updates

Updates can be downloaded directly from the Palo Alto update server via two paths.

One is downloading the updates to another system such as a user desktop or Panaorama mangement device, and then uploading to the firewall.

Two is navigating to the Device -> Dynamic Updates section of the firewall and clicking Install to Install the update.

The following release schedules are available for updates:

Antivirus is daily

Applications and Threats: weekly updates, with new applications coming monthly

WildFire: Around every 5 minutes

The firewall can be configured to check for updates as frequently as required. As often as every hour for anti-virus, applications and threats as often as every 30 minutes and wildfire updates can be checked once per minute

PAN-OS Updates

To maintain the most current protection, the firewall requires to be updated to the latest PAN-OS software.

When an upgrade is performed, it is important to download the next x.0 base release, before downloading to the next minor release. When installing the minor release the base release is automatically installed

Like dynamic updates, there are two methods of updating the firewall, via uploading a file or using the Check Now hyperlink

The MGMT port is used to fetch these updates, but can be configured to use a seperate in-band port

The firewall must be running the most recent version of Applications and Threats database. The software upgrade process fails if it does not have a current update.

Administrator Account and Role Respositories

The firewall can authenticate locally or remotely defined administartors: A local account and password, or a remote account and password.

PAN-OS software supports remote authentication using Active Directory, Kerberos, LDAP, RADIUS and TACACS+

Roles for each administrator can be defined locally, or remote too using Custom Roles or Dynamic Roles

Remote role assignments are supported via RADIUS or TACACS+ using VSAs, Vendor Specific Attributes

All administrators changes, whether local or remtoe, are logged in the firwalls Configuration and System logs. Time logged in is logged, and any configuration changes that are made

Firewall Authentication of non-local users

Before an external authentication service can be used, an authentication profile requires to be created on the firewall. The authentication profile contains information to authenticate an administrator account against an external authentication service once one of the services servers can be reached.

An authentication sequence is a method where a firewall can contact multiple services to authenticate an account. A specified list of authentication profiles can be created by adding them to the optional authentication sequence on a firewall.

If created, specify the sequence instead of the profile on the user account on the firewall

An authentication profile uses a server profile, which is used to locate the external authentication services servers. A server profile can be configured a list of external authentication servers

Step one:

Authenticate non-local password

Step two:

Read optional authentication sequence

Step three:

Go to first/next Authentication profile

Step Four:

Has a server profile been found?

If No:

Login has failed, check if they’re is another authentication profile and go to Step three

If Yes:

Was an account found?

If No:

If there is anoither authentication profile, go to step three

If Yes:

Check the password authentication

Server Profiles

Devices -> Server Profiles

Server profiles define connections that the firewall can make to external servers for the purposes of authentication.

These types of external servers could be Kerberos, LDAP, RADIUS, SAML, or TACACS+ servers

Server profiles are required to validate login information for accounts that were not locally created on the firewall

Authentication Profiles

Devices -> Authentication Profiles

The authentication profile specifies what server profile and settings are used to authenticate the administrator account. An authentication profile is specified when an administrator account is created where the name and password are maintained on an external service

Authentication Sequence

An optional configuration if multiple external services have been defined.

The list is created with a list of Authentication Profiles that are in order of most preferred to least preferred, that should be checked to authenticate an administrator account.

Each one in the list is checked until one profile succesfully authenticates the user.

If a local database is preseent in the list, the firewall checks that one first regardless of where in the order it comes

Authentication only fails once all profiles fail the query of the login information

Categories
EDU-110 Study Palo Alto

EDU-110: Security Operating Platform and Architecture

Objectives:

Describe the characteristics of the Security Operating Platform

Describe the differences between single-pass architecture and parallel processing

Describe the Zero Trust security model and how it relates to traffic moving through the network

Cyber Attack Lifecycle

  • Reconnaissance
    • Attackers carefully plan their attacks: They identify and select targets, research them. Using phishing tatics or data mining from a social media platform or company website. Company networks are scanned on this stage to look for vulnerabilities, services, and applications that can be exploited.
  • Weaponisation
    • Attackers determine the methods that will be used to deliver the malicious payloads to achieve their objective. The malicious payload could be present in an website, or specially crafted packages to attract the victim.
  • Delivery
    • The attackers may also choose to e-mail a PDF or word document.
  • Exploitation
    • The attacker now deploys the exploit against the vulnerabler application or system. Using the exploit kit or weaponised document. The deployment of this explot gives the attacker an initial entry point into the targeted network.
  • Installation
    • With initial access, attackers will try to establish a escalated privileges to gain control of the system. This will also allow the attacker to try gain a perisistent entry point into the network for future access.
  • Command and Control
    • The attackers establish a command channel back to a specific attacker control server, to allow communication back and forth between their own infrastricture and the infected devices
  • Act on the objective
    • The attacker has a persistent ongoing connection into the network. They can now act upon their motivations to try achieve their goal. Motivations could be data exfiltration, destruction of critical infrastructure or defacing web property.

Network Security Platform

The Palo Alto Networks Security Platform has three objectives:

Prevention-Focused Architecture – React only to the threats that are critically important

Highly Automated – Reduce or remove manual response

Safely enables all applications – Granular use of controls and prevention of known and unknown cyberthreats

Security Operating Platform

Cortex

Apps can be created and developed on a common application framework, known as Cortex, to rapidly build and deliver cloud-based security services with no additional infrastructure or on-premises hardware changes. Apps are delivered from the cloud to extend the capabilities of the platform, including the ability to effortlessly collaborate between apps, share threat context and intelligence, and drive automated resposne and enforcement

Contains Coretex Data Lake, and Cortex XDR

Network Security

Palo Alto Networks Security Operating Platform firewalls are designed to safely enable applications and prevent modern threats. The firewall can identify all network traffic based on applications, users, content, and devices, and lets you express your business policies in the form of easy-to-understand security rules.

Advanced Endpoint Protection

Traps Advanced Endpoint Protection providfes multi-method prevention, a proprietary combination of malware and exploit prevention methods that pre-emptively block both known and unknown threats directly on an endpoint

Cloud Security

The Palo Alto Networks VM-Series firewall is a virtualised form of the Palo Alto Networks Security Operating Platform firewall. The VM-Series firewalls are designed for use in a virtualised or cloud environment to identify all network traffic based on applications,u sers, content, and devices

Additional Palo Alto Products

Panorama – Allows consolidated policy creation and centralised management. Allows for the implementation and control of firewalls centrally with an efficient rulesbase, adds insight into network-wide traffics and threats across multiple firewalls

Prisma Software as a Service – Protects cloud based applicatinos such as Box, Salesforce, and Dropbox by managing permissinobs and scanning files for external exposure and sensitive information. Prisma SaaS is focused on data loss prevention for personally identifiable information, payment card industry information and other sensitive data.

GlobalProtect – Safeguards the mobile workforce by inspecting all traffic using the organisations next generation Palo Alto firewalls deployed as internet gateways. Devices with the GlobalProtect app establish a secure SSL/VPN connection to the firewall with the best performance for a given location. Proves the organisation with full visibility of all network traffic.

AutoFocus – Gives security operatiyons and analysis teams direct access to all the threat intelligence Palo Alto networks gathers from customers, open source feeds, and the Unit 42 threat research team.

This allows security teams to focus their effects on the most important attacks and understand the most critical elements of those attacks.

Next Generation Firewall Architecture

The firewall allows you specifiy security policies based on identifcation of applications seeking access to the network.

This is different to traditional firewalls that seek to identify applications via their protocol and port number.

The next generation firewall uses packet inspection and a library of application signatures to distinguish between applications that use the same protocol and port number. With this technology the next generation firewall can identify malware applications that may use common port numbers

The Single Pass Architecture


The Palo Alto firewall has a strength in it’s single pass parallell processing (SP3) engine. Each protection feature uses the same stream based signature format. This means the firewall can check for all risks that could be present in packets simultaneously.

An advantage of this simultaneous scanning is traffic can cross the Palo Alto firewall and be scanned with a minimal amount of packet buffering. This allows these advanced features to be enabled without slowing down the performance of the firewall.

The Firewall Architecture

The Palo Alto firewall has processors dedicated to specific security functions, that all work in parallel. These security functions can be be implemented in hardware offloading or software. The hardware offloading components types and capacities will vary on the specification of the firewall model.

Data Plane Processing:

  • Signature Matching Components (Single pass pattern matching), a stream based uniform signature matching technology that looks for exploits, virues, spyware, credit card numbers and social security numbers with.
  • Security Processing Components (Enforcing Security Policy), a multicore processor that can handle complicated tasks such as secure sockets layer (SSL decryption)
  • Network Processing Components, responsible for the routing and network address translation (NAT), plus all network layer communication such as:
    • Flow Control
    • MAC Lookup
    • Route Lookup
    • Quality of Service

On the higher end hardware models, the data plane has three seperate processors that are connected via 1Gbps busses.

Control Plane Management

Contains the management parts of the firewall, responsible for management user interface for configuration, logging, and routing updates.

The higher end models of Palo Alto firewalls have their own dual core processor, RAM, and hard drive/SSD.

The Zero Trust Model

North-South traffic: Traffic that enters and leaves the network

East-West traffic: Internal traffic that never leaves the gateway

Data flows in a open network are open to a few vulnerabilities, such as a lack of visibility. If the network administrators cannot view traffic the administrators have no control of the traffic. This leaves networks open to attacks from both inside the organisation and from the public internet.

Another few examples of vulnerabilities:

Remote employees are treated as internal traffic

Wireless users, partner connections, or guests create new entry possible vulnerable entry points into the network

Remote offices need to be considered as providers of untrusted traffic because of where they are located.

Internal employees may unintentionaly present as a security threat with USB keys, or file downloads

Data flows secured by Palo Altos

The security model that Palo Altos follow is to remove the presumption of trust, known as the zero trust model.

This is an alternative security model that aims to address the shortcomings of failing permieter centric strategies by removing the assumption of trust.

Trust boundries are created taht compartmentalise different segements of the network enviroment.

Security functionality is also moved closer to different pockets of resources that require the protection needed by a firewall.

Palo Alto firewalls offer a range of threat prevention technologies that give an integrated approach against threats.

DeliveryExploitationInstallationC2Act on the Objective
App-IDBlocked high risk applicationsBlock C2 communications on standard well known portsPrevent exfiltration and lateral movement
URL FilteringBlock known malware sitesBlock malware and fast flux domains
VulnerabilityBlock the exploitPrevent lateral movement
Anti-spywareBlock spyware and C2 traffic
Anti-VirusBlock malwarePrevent lateral movement
TrapsMonitor allowed processes and executablesPrevent the exploitPrevent malilcious .exe from running
File BlockingPrevent drive by downloadsPrevent exfiltration and lateral movement
DoS and/or ZonePrevent evasionsPrevent Denial of Service attacks
WildFireIdentify MalwareDetect unknown malwareDetect new C2 traffic

Physical Firewall Platforms

PA-220 or PA-220R series

PA-800 Series

PA-3200 Series

PA-5200 Series

The PA-5280 firewall is similar to the PA-5260 firewall, but the PA-5280 firewall has double the data-plane memory. This means that the session capacity on the 5280 is doubled over that of the 5260

PA-7000 series – PA-7050 and PA-7080 are chassis architecture

Panorama M-200 or M-500/WF-500/600 servers

Virtual Systems

Virtual systems (vsys) are seperate, logical firewall instances within a single physical Palo Alto firewall.

Rather than multiple firewalls, service providers and enterprises can use a single pair of firewalls and enable virtual systems.

A virtual system consists of a set of physical and logical interfaces and subinterfaces, virtual routers and security zones. A deployment mode of virtual wire, layer 2, or layer 3 can be chosen. When virtual systems is enabled the following can be segmented from the other virtual systems:

  • Administrator access
  • Management of all policies, including:
    • Security
    • NAT
    • Policy based forwarding
    • Decryption
    • Application Override
    • Authentication
    • Denial of Service Protection
  • All objects
    • Address objects
    • Application groups
    • Application filters
    • Dynamic Block Lists
    • Security Profiles
    • Decryption Profiles
    • Custom Objects
  • User-ID
  • Certificate Management
  • Server Profiles
  • Logging, reporting, visibility functions

The PA-3X00, PA-5X00, PA-7X00 firewalls all have support for virtual systems. The number of maximum virtual systems vary per platform.

On the PA-3×00 series firewall, a licence is required to create multiple virtual systems.

Categories
EDU-114 Study Palo Alto

Palo Alto EDU-114: Blocking Threats From Stolen Credentials

Objectives:

Describe authentication and authorization methods supported by the firewall

Configure user accounts for firewall administrators and end users

Define multi-factor authentication implementation methods

Configure the firewall to connect to an MFA server

Configure anti-phishing and user credential submission protections

Summarize the three methods used to break the credential threat attack life cycle

User Authentication

Users connecting to firewall services / connecting to the firewall

Users are required to be authenticated when:

  • HTTP/HTTPS access to the mangement interface
  • HTTP/HTTPS access to the XML API
  • SSH/Telnet to the Command Line Interface
  • Serial connection to the Console interface

Users can be required to authenticate when connecting through the firewall for applications such as:

  • Accessing a website
  • Accessing web mail
  • Accessing share point
  • Accessing Office 365

Supported Autentication Methods

The Palo Alto software can support three types of authentication services: local, external, and multi-factor authentication.

Local authentication without a database (XML configuration) can be used for stored accounts to authenticate logins to the firewall.

With no database however the firewall cannot authenticate traffic flowing through the firewall.

Local with a database can be used to authenticate logins to the firewall, and for user traffic flowing through the firewall.

The firewall can use all external services to authenticate logins to the firewall, and user traffic flowing through the firewall, these are:

  • Kerberos
  • LDAP
  • RADIUS
  • TACACS+
  • SAML

Palo Alto software also supports four multi factor authentication venders.

  • Duo V2
  • Okta Adaptive
  • PingID
  • RSA SecurID Access

The authentication services above all require an authentication profile. The authentication profile is used to link a set of users to a specific authentication service.

Only the authentication services that use an authentication profile can authenticate user traffic flowing through the firewall.

Configuring Authentication TO the firewall

Dependant on the configuration of the authentication profile for the user, will determine how users are authenticated to the firewall.

Each user can be configured with their own Authentication Profile that points to an authentication service.

Or alternatively all users can be configured to use the same authentication profile and authentication service.

To configure per-user authentication to the firewall, assign an authentication profile to a user account when they are added to the firewall.

To configure an authentication profile for all users on the firewall, assign an authentication profile to the authentication settings of the firewall under Device -> Setup -> Management -> Authentication Settings.

The all users authentication only supports RADIUS, TACACS+, and SAML

SAML can only authenticate users using web based services.

Configuring Authentication THROUGH The Firewall

The firewall can be configured to authenticate user credentials when users attempt to access network resources through the firewall.

Individual authentication profiles should not be assigned to the individual user or the firewalls authentication settings in this mode

Rather, an authentication profile to an authentication policy via an authentication enforcement object should be created.

An example is that a web form could be presented, that asks the user to fill out a username and password before they can gain access to a resource. The form can authenticate against an LDAP service to determine whether user should get access.

Admin Role Profiles

Admin role profiles control authorisation to manage the firewall.

Dynamic Admin Roles are a built in set of permissions, stating what a user can or cannot do on a firewall using the web interface, CLI, or XML API.

A role based admin roles are a custom set of permissions, that can control users activities on a firewall when the Web, CLI, or XML API permissions are in use.

User Authentication TO and THROUGH the Firewall

A source user I.D. can be set to authenticate users accessing network resources through the firewall on the security policy, if user authentication of traffic flowing through the network has been configured.

Adding a Local, Non-Database Firewall Administrator Account

Step 1 – Create a custom Admin Role if required

Browse to Device -> Admin Roles to create a custom Admin Role Profile.

Although they are predefined role based admin roles on the firewall already, they cannot be modified. Custom addtional roles can be created though to fit around the needs of the administrator

Predefined Roles:

  • Audit Administrator – Responsible for the regular review of the firewall audit data
  • Cryptographic Administrator – Responsble for the configuration and maintenance of the cryptographic elements related to the establishment of secure connections into the firewall
  • Security Administrator – Responsible for the administrator tasks that to not fit into the two other roles of the administrators

Step 2 – Create a local, non-database administrator account

Administrators can be created by browsing to Device -> Administrators

Adding a Local Database User as a Firewall Administrator

Step 1 – Create a user in the local user database

Go to Device, Local User Database, Users, and click Add

Step 2 – Create an authentication profile that links to the local user database

An authentication profile links a username in the authentication service that the firewall must use to authenticate login credentials of a user.

Go to Device, Authentication Profile, and click Add. Select the type ‘Local Database’

Note the selection of type ‘None’ could allowed undesired users to log into the firewall

In advanced settings, the Allow List can permit only certain users to be authenticate by a profile.

The account lockout option can be set from 0 – 10 attempts, to prevent brute force attacks. The default is 0

A lockout time can also be set to specify how long a user is locked out of the firewall for after the failed attempts value has been reached. The range is from 0 – 60. 0 means the account is not unlocked automatically and creates additional work for administrators

Step 3 – Create a custom Admin Role Profile if required

Step 4 – Create an administrator account from a user in the local user database

Go to Device, Administrators, enter the name of the username previously created and select the Authentication Profile as created in Step 2.

Adding an External User as a Firewall Administrator

Step 1 – Create a server profile for the external authentication service

To create a service profile, for example LDAP, go to Device -> Server Profiles -> LDAP -> Add

Step 2 – Create an authentication profile that links to the Server Profile

An authentication profile links the username to the authentication service that the firewall uses to authentication the users login credentials.

The firewall uses an authentication profile to verify user credentials when a user attempts to login to the firewall

The profile is also used when the firewall is attempting to verify user credentials when a user is trying to access a network resource through the firewall.

To add a profile, go to Device -> Authentication Profile -> Add

Step 3 – Create a custom Admin Role Profile if required

Go to Device -> Admin Roles -> Add

An externally authenticated user logging in must be given permissions via an assigned admin role

Externally authenticated users can be given a predefined Dynamic Admin Role Profile, or a custom Role Based Admin Role Profile

Step 4 – Create an Administrator account that links to the Authentication Profile and the Admin Role profile

Go to Device -> Administrators -> Add

The username must match that of what is on the external service.

Adding an administrator that is authenticated by a certificate

Step 1. Create the users certificate

Palo Alto Firewalls support interactive and non-interactive authentication

The certificate based authentication, non-interactive, is only available via web browser

If the certificate of the issuing CA is not added to the clients browser, a warning message is generated by the clients browser when attempting to connect

Note, configuration of certificate based authentication for any administrator automatically disables the username and password logins for all administrators on that firewall

Step 2. Create the firewalls certificate profile

Device -> Certificate Mangement -> Certificate Profile -> Add

Add a CA certificate here for the firewall to verify a users certificate.

CRL and OSCP can be used here to check for certificate revocation status

Step 3. Create a custom Admin role if needed

See previous notes

Step 4. Configure the firewall to peform certificate-based authentication

and

Step 5. Create a certificate authenticated administrator account

Under Device -> Setup Management -> Authentication , select the Certificate Profile created earlier

Enabling SSH Key-Based Command Line Firewall Access

Key based command line access provides cryptographic strength over passwords, with passwords not needing to be sent over the network and reducing the risk of brute force attacks. It also options the possibility for two factor authentcation.

Key based SSH logins permits automated scripts access to the CLI too.

This can be configured in Device -> Administrators, ticking the box for ‘Use Public Key Authentication (SSH)’

A public key an imported in the field below the checkbox

Preventing use of stolen credentials by using multi factor authentication

The Palo Alto can be used to detect credential leakage when the firewall is configured to use User-ID. If User-ID detects valid corporate credentials being entered, the Palo Alto can consult the URL filtering to see if the category of the website that is being entered with credentials is valid for having corporate credentials being entered into. If it is meant to be prevented from entering credentials, the firewall will block the attempt to enter corporate credentials.

Block is not the only option that can be configured here, the firewall can be permitted to allow credential submission or set to warns the user against submitting the credentials.

The pages can be customised further, in a way that a pop-up could appear to discourage users from reusing their corporate passwords on other legitimate websites

Steps for Configuring Phishing Protection

Step 1 – Configure User-ID on internal-zones

One Example: See Device -> Server -> Profiles -> LDAP

Device -> User Identification -> Group Mapping Setting

Used to determine user are members of which groups

Second Example: See Device -> User Identification -> User Mapping

User-ID agents monitor devices for login and logout events

Firewall-integrated and Windows-based User IDs agents are available

Firewall-integrated configuration is done in this example, in the username field a user that has permission to view event logs on the event viewer should be entered in the configuration

User-ID also needs to know what type of server it is monitoring, this can be set in Devices -> User Identification -> User Mapping -> Server Monitoring -> Add

Step 2 – Configure a URL filtering Profile to block access to known phishing sites

Objects -> Security Profiles -> URL Filtering

Custom anti-phishing response pages can be set by going to Device -> Response Pages and viewing the Anti Phishing Block Page or Anti Phishing Continue Page

Step 3 – Configure a URL filtering profile to control user credential submission

Objects -> Security Profiles -> URL Filtering -> ADD

Weakest matches to strongest matches:

Use Group Mapping:

Detects corporate usernames by comparing to usernames in LDAP User Group

Uses IP User Mapping

Detects corporate usernames by comparing to User-ID IP-to-Username mapping table

Use Domain Credential Filter

Detects corporate usernames and passwords using bloom filters to match credentials

Default Log Severity on a match is set to medium

Step 4 – Add a URL filtering Profile to Security Policy rules

Categories
EDU-114 Study Palo Alto

Palo Alto EDU-114: Blocking Threats in Allowed Traffic

Objectives:

Block known malware attacks by configuring Security Profiles according to best practices

Detect unknown malware attacks by configuring WildFire according to best practices

Overview of Inspecting Allowed Traffic

When network traffic passes between zones on the firewall, it matches against rules on the security policy.

Even if the security policy gets a match and permits traffic, the security profile attached to the rule can allow further inspection of packets passing through the firewall to occur

The security profile can check for threats like:

  • Viruses
  • Spyware
  • Expoits
  • Malicious URLs
  • Malicious files
  • Sensitive data
  • Zero-day malware

If a match is found in the security file, it can carry out various actions like allow, block, ask the user for permission to continue, or log the violation.

The security profile allows a network administrator have more granular control over allowed traffic

Security profiles can detect known and unknown threats

Known threats, updated with regular update downloads, can pick up on new and old malicious traffic. The security profiles designed for detecting known threats are:

  • Antivirus
    • Using signature matches
    • Updated daily
  • Antispyware
    • Using signature matches
    • Custom signatures can be created
  • Vulnerability Protectioin
    • Using signature matches
    • Custom signatures can be created
  • URL Filtering
    • Using pattern matches
  • Data Filtering
    • Using pattern matches
  • File Blocking
    • Using file type and transfer detection

The Palo Alto firewall also has a platform for picking up on unknown threats, WildFire Analysis

WildFire analyses files and URLs in a virtual sandbox enviroment. Wildfire creates new signatures for newly discovered threats, distrubuting them to firewalls worldwide

Day One Security Profile Methodology

The Day One Security Profile is best practice security profile configuration for blocking threat and minimising application downtime between outbound, inbound, and internal zones.

The security profile allows the administrator to build three sets of custom security profiles, one for inbound, one for outbound, and one between internal zones.

If an administrator is concerned that false positives will be blocked, the administrator can configure them to report security profile violations, but do not block them.

Blocking Signature Detected Threats

The Palo Alto firewall uses signatures to detect and block known viruses, spyware, and software exploits.

Updates to these signatures are distributed frequently to firewalls with Palo Alto content updates. Wildfire also frequently distributes updates.

If new spyware is encountered that Palo Alto does not have a signature for, the network administrator can craft their own custom signatures to block threats.

Viewing Information

To view blocked or alerted threat information, click on the Threat Log in the monitor tab.

The ID column in this log can be useful for creating exceptions in the profile rules, if a false positive occurs.

Overview of URL Access

The PAN-DB URL filtering database is maintained by Palo Alto Networks, which groups websites into categories.

A firewall with a valid URL filtering licence can control user access to websites

URL Filtering profiles should be attached to all security policy rules that allow traffic in a zero-trust configuration

Filtering information can be viewed in the URL filtering monitor tab. Note the continue is a prompt sent to the user confirming they wish to continue to visit a webapge, the override action is a result of the user confirming they want to still visit that webpage

Blocking Unauthorised File Transfers

The Palo Alto supports the blocking of unauthorised file transfers via with a link in a E-mail attachment, webpage, or instant mesage containing a FTP, Google Drive, Dropbox or similar URL.

The file blocking profile detects the file type using the filename extension and the content inside the file. Once determined the profile will block or allow the file transfer

Viewing Blocked Files

The data filtering log displays a list of files blocked by the File Blocking Profiles. The firewall records the filename and file type along with other information.

The firewall security policy rules and file blocking profiles should be adjusted accordingly with the information presented in these logs.

Detecting unknown threats

WildFire is the Palo Alto profile that is primarly in use for detecting new or unknown threats. WildFire requires a WildFire subscription to be used.

A cloud based sandbox enviroment, WildFire analyses unknown files and URLs within e-mail links that the Palo Alto discovers. The sandbox determines whether the samples are benign, grayware, phishing or malicious.

If the WildFire cloudbox discovers malware, it generates a signature from the sample file and distributes the signature to all firewalls within minutes (that have an active subscription). These quick updates allow firewalls to have an edge over malicious applications with quick detection and blocking, all potentionally discovered from one other single firewall!

Basic WildFire support is included with a Threat Prevention licence. To get the full features of WildFire a valid WildFire licence is required. If a WildFire licence is not present, Palo Alto firewalls without a licence will get the licence definitions on the next Antivirus Content Update.

If WildFire forwarding is eanbvled, the firewall forwards files that were blocked by antivirus signatures. Signatures can often match multiple variants of the same malware application, and can block new variants of the virus application that have not been seen before. The forwarded file can be used by the Palo Alto research team to further protect firewalls with new additions to IP address, URL and domain blocklists.

The WildFire Profile

The WildFire profile performs additional checks on allowed network traffic. As is the same with other security profile rules, WildFire Analysis applies to all packets over the life of a session.

The recommended practice is to forward all files and links to WildFire for analysis.

Configuring WildFire Forwarding

To configure wildfire forwarding, go to the Device Tab, then the WildFire tab underneath that.

Viewing WildFire Logs

WildFire logs can be viewed in the Monitor, WildFire submissions tab.

Blocking Sensitive Data Transfers

The data filtering profile can prevent sensitive information from leaving a protected network.

A data filtering profile attached to all security policy rules allow scans for data patterns to occur

Three types of data patterns can be scanned for, Predefined Patterns (Credit Card Numbers, Social Security Numbers), Regular Expressions (Regex), and File properties (Property=Value). They are 22 predefined patterns in PAN-OS 2.0

The property=value object type can be tied into a third party data loss prevention product

Data Filtering Log

The Data Filtering Log (under the Monitor tab) allows the administrator to determine if there has been any succesful or blocked transfers of data. Information can also be viewed if there was any hosts or systems involved in the transfer of data. Packet captures can also be viewed to see which sensitive data was transferred but a password needs to be set in order to protect this data.

Protecting Access to the Data Filter

A password must be set on the Data Filtering Log if packet captures are enabled. This is to prevent easy access to sensitive data.

HTTP ‘Accept-Ranges’ Option

The HTTP Accept-Ranges option allows a web client to resume a stopped data transfer, by requesting a resend of the missing data.

Palo Alto recommends that this is disabled, so that if a sensitive data transfer is stopped it can not be resumed

Security Policy Modifications

Rule Tags and Descriptions

Rules can be tagged and assigned on security policies to allow for easy identification, a description can also be entered on a security rule to help any other network administrators learn how a security policy is used

Rule Tags and descriptions can be forced on rules on the Policy Rulebase Settings, a tag, description, or audit comment can be forced to be present before a commit can be made to the firewall.

Configuring Security Profile Groups

The recommended configuration from Palo Alto is to use the same naming convention as the security profiles: outbound, internal, and inbound.

Security Profile Groups can be attached in the same way to a security rule as a Security Profile.

Optional Initial Configuration

If the administrator is concerned about false positives, they have an option to use a configuration that only sends alerts, but does not block malware.

The alerts can be used as a source of information when it comes to reconfiguring the firewall to better protect networks.

Best Practice Configuration Templates

Iron Skillet can be used with Palo Alto to try get a best practice configuration in place. Iron Skillet is a website repository of firewall and Panorama day one configuration templates according to best practice recommendations.

Day One configurations help keep a network safe by blocking malware, but minimises downtime as a result of too strict configuration. They are safe starting points for most deployments

Configuration settings can be added as more information about specific services and applications are learned in a network enviorment

The Iron Skillet template creates a set of inbound, outbound, internal security profile and security profile groups.

Iron Skillet creates custom reports too as well as log and log forwarding settings.

Additional configuration will be required to best suit your network, including but not limited too additional interface addresses, zones, and routing.

How good is your configuration?

A tool is present for Palo Alto to analyse firewall, and panorama configurations. These are compared against Palo Altos best configuation practices. The tool returns a set of recommendations on how to improve the network security

The best practice security tool can be accessed on the Customer Support Portal.

Categories
EDU-114 Study Palo Alto

Palo Alto EDU-114: Blocking threats in encrypted traffic

Module objectives:

Create and manage certificates using the web interface

Configure certification revocation checking on the firewall

Configure SSL/TLS decryption on the firewall

Describe the effects of key pinning on firewall Decryption policy

Configure SSH decryption on the firewall

Manage the master key

The importantance of SSL/TLS

Secure Socket Layer / Transport Layer Security secures network communications end to end across a shared network platform. It offers many advantages such as encryption for data privacy, hashes for data integrity, and certificates for authentication.

The Palo Alto next generation firewall offers SSL/TLS decryption to help prevent malware introduction through encrypted channels, and data exfiltration out of the company out encrypted channels.

A quick recap on SSL/TLS operation

An SSL session is established between a client and server as the following:

  1. Client requests an SSL connection to the server
  2. The SSL server sends the client it’s server certificate
  3. The client verifies this SSL certificate against it’s own trusted store of root certificates
  4. The client sends an encrypted session key to the SSL server
  5. The server uses it’s own private key to decrypt this session key
  6. The server and client then begin encrypted private communications between each other using the confidential session key

Palo Alto Certicate Management

The Palo Alto firewall supports two different types of SSL certificate, certificate authority signed certificates and self-signed certificates.

The preferred method for configuration is a CA-signed certificate, which simplifies SSL configuration.

The administrator has a number of options in obtaining a CA-signed certificate

  1. Buy a CA-signed certificate and public-private key pair from a public CA
    1. Disadvantage is cost
    2. Limitation in that public CA’s do not sell signing certificates, required for SSL Forward Proxy description
  2. Get a CA-signed certificate and public-private key pair from an internal CA
    1. Advantage is usually free
    2. Can be a signing certificate to be used with SSL Forward Proxy decryption
  3. Create the certificate and public-private key pair on the CA server
    1. Create a certificate and public-private keys
    2. Import certificate and public-private keys onto the firewall
    3. Disadvantage: A small risk that hte private key transferred over the network would be stolen

On the last point there with the risk of a key being stolen, there is a workaround:

  1. Generate a CSR and public-private keys, export the CSR file
  2. Sign and return the certificate in a file
  3. Import the CA signed certificate from the file

For self signed certificates, a couple of advantages is that they are free and can be obtained in minutes. The self signed certificate can also be used with SSL Forward Proxt decryption. The primary disadvantage is that this self signed certificate would not be trusted by other devices in the organisation.

The administrator could export and install the self signed certificate to the trusted root certificate store on other devices in order for the self signed certificate to be trusted as a work around.

Certificate Creation and Management

Under device, open Certificate Management -> Certificates
Click the generate icon to generate a new SSL certificate
Alternatively you can import an already signed certificate into the Palo Alto by using Import

Certificate Checking and Revocation

One: Determine chain of trust

Two: Validate each certificate in the chain

Steps to check:

  1. Is the certificate signature valid?
  2. Is the date range presented by the certificate valid?
  3. Is the certificate signature malformed or corrupt?

Three: Check revocation status of each certificate

Compare against the online certificate status protocol (OCSP) first, then the certificate revocation list (CRL)

These lists will return four different statuses:

  • Current: valid
  • Expired: Cannot trust identity
  • Unknown: Cannot establish validity
  • Unavailable: OSCP/CRL can’t be contacted

Why would a certificate get revoked?

  • The private key has been compromised
  • Hostname or username of owner changed
  • Host decommissioned, e.g. user left the organisation
  • Couterfeit key found

Configuring SSL Decryption Certificate Revocation Checking

The Palo Alto firewall can be configured to verify the revocation status of certificates used for decryption.

This can be set up in Device -> Setup -> Session -> Certificate Revocation Checking

SSL Forward Proxy Review


The firewall uses SSL Forward Proxy to decrypt and inspect SSL traffic when the Palo Alto fireewall does not have access to the SSL servers private key.

The firewall and the SSL server must share a common CA for the firewall to validate the servers identity.

At the other end of the communcation, the SSL client and the firewall must have access to a common certificate authority for the client to validate the firewalls identity.

The SSL session tries to establish a session with the server with a SSL handshake. The Palo Alto firewall intercepts this handset and issues its own handshake between the firewall and the server. The SSL Server responds with a common CA to allow the firewall to validate the servers identity

The firewall copies this servers certificate and signs it with its own forward trust certificate and public key.

A forward trust certificate indicates to the SSL client that hte firewall has verified and trusts the servers certificate. The firewall forwards the newly copied and signed server certificate to the client

The client uses the firewalls forward trust certificate to validate the firewalls identity, using a CA common to both the client and firewall.

The client has now established a secure connection, and the firewall acts a proxy between the client and the server. The firewall can decrypt traffic and inspect it flowing between the client and the server.

If for any reason the server can not verify the servers certificate, it signs the servers certificate with a forward untrust certificate that indicates to the client the SSLs server certificate could not be verified

Configuring a Forward Trust Certificate

Tick the box ‘Forward Trust Certificate’

Configuring SSL Forward Proxy

Under Objects:

Under Policy Rules:


Fill out other rules similar to a security policy permitting access to the internet, then note the different selectable options at the end

Configuring SSL Inbound Inspection

This traffic flows originate outside to inside

Note: You load the SSL certificate for the SSL server to the Palo Alto, and use that to decrypt/inspect traffic

So a private key and cert will need to be imported into the server

Identifiying Decrypted Network Sessions

Within monitor -> logs -> traffic, check the column header ‘Decrypted’ for yes or no

With the CLI command:

show session all filter ssl-decrypt yes

Check for the flag *

Decryption Exclusions

Websites with known decryption problems are pre-popualted on this Palo Alto created list.

The exclusion list is updated via content updates, and can also have websites added to it

No Decryption

Even if a website action is set to “no-decrypt”, the decryption profile can still be configured to block sessions with expired or untrusted certificates

Opting out of SSL Decryption

Device -> Response Pages


Click on the ‘Disabled’ hyperlink to enable the opt out page

SSL Decryption Policy Considerations

Key Pinning can affect SSL decryption configuration, it’s purpose is to prevent use of counterfeit man-in-the-middle certificates. There are two types of key pinning, static key pinning and Dynamic Key Pinning (HTTP Public Key Pinning, HPKP)

Static Server Certificate Pinning

The software devceloper writes the code for the SSL server and client. The developer also configures both ends of the client and server to recognise the servers certificate.

The SSL decryption fails here as the client is preconfigured to accept a certain certificate. The firewall re-writes the certificate so the client will fail to validate the certificate presented to it via the firewall.

The same can happen with a certificate authority, where the software developer notes what certificate authority signed the certificate. As the certificate authority will also be different this can cause the client validation to fail.

Dynamic Key Pinning

Dynamic key pinning relies on a HTTP protocol extension called HPKP. A list of acceptable CA certificates and public keys is sent from the SSL server to the client the first time that the client connects to that SSL server.

The acceptable CA certificate information is sent in a HTTP resposne header named Public-Key-Pins. The client must establish at least one HTTPS connection to the server to recieve this list of acceptable CA certificates and public keys

This type of SSL Forward Proxy decryption can fail as the firewall can not perform the decryption unless it modifies the CA signature on the server certificate. The modified signature may not match the list of acceptable server cetificates unless the client is also configured to accept the certifcate and public key of the firewall as an acceptable CA certificate.

Reasons not to configure SSL Decryption

  • Prohibited by law or a company policy
  • Server requires a client certificate (Forward Proxy)
  • New CA can not be added to a client
  • Client software requires specific server certificates
  • Non-standard SSL implementation in use

SSH Decryption

The Palo Alto firewall can decrypt and inspect SSHv2 traffic, to detect SSH-tunneled applications.

The decryption is unsupported with SSH key passwordless logins.

The Palo Alto firewall uses an automatically generated key to decrypt or encrypt traffic.

The traffic is identified as ethier ssh or ssh-tunnel on the firewall. The traffic can be controlled using Security Policy rules.

Firewall Master Key

The firewall master key is used to encrypt passwords and private keys.

It is good practice to periodically change the master key.

The master key must be the same in a HA pair

Managing the Master Key

All changes must be committed before changing the master key, the master key change does not require a commit after the key has been changed.

An expiration warning is good practice to set to avoid being locked out, an auto-renew can be set as a lockout safeguard to protect against accidental lock-out.

If the master key has expired, firewall access is only available through the console to perform a factory reset.

Categories
EDU-114 Study Palo Alto

Palo Alto EDU-114: Custom Threat Signatures

Objectives:

Create custom software vulnerability and spyware signatures

Create standard and combination threat signatures

Types of signatures:

  • Defined by Palo Alto:
    • Vulnerability Signatures
    • Anti-Spyware Signatures
  • Are updated frequently (each week) via Applications and Threats content updates
  • Custom defined:
    • Vulnerability Signatures
    • Anti-Spyware Signatures
  • Are updated by the administrator as required

Creating Custom Threat Signatures:

Browse to Objects -> Custom Objects, select Spyware to create custom spyware signatures or select Vulnerability to create custom vulnerability signatures.

The creation for both of these signatures is a similar process

Standard Verus Combination Threat Signatures

A standard signature looks for a single match condition out of one or more defined, once detected it will trigger the threat action.

A combination signature looks for one or more standard match conditions within a time element. This is only created when the administrator wishes the firewall to take action only when one or more threat signatures are detected within a certain time period

An example of a good combination signature is detecting brute force attacks, when a password is submitted to an application in quick succession.

Categories
EDU-114 Study Palo Alto

Palo Alto EDU-114: Blocking Threats Using Custom Applications

  • Use logs to discover unknown traffic
  • List methods to control unknown traffic
  • Perform a packet capture using the web interface
  • Create a custom application with a custom signature
  • Manage custom applications
  • Create a custom application without a custom signature
  • Configure an Application Override policy

Applications are not always identified

Some applications can not be uniquely identified. Such as commercial or internally developed software.

These fall under a generic classification, such as unknown-tcp, unknown-udp, unknown-p2p, web-browsing or ssl.

Custom applications offer more granular control and reporting abilities to work in the Palo Alto firewall.

Controlling application traffic

There are different types of control application traffic on the Palo Alto firewall:

Commercial application known to App-ID can be used in Security Policy to permit or deny.

A commercial applciation unknown to App-ID can be submitted to Palo Alto networks to have a new signature created for the application to be used in security policies.

Additionally, a custom application can be created with a signature on the Palo Alto device that can be used as an application in the security policy.

Finally, a custom application can be created without a signature, using the application in application override feature.

With an internal application, your choices are limited to creating a custom application with a signature, to be used in Security Policy, or creating a custom application without a signature to be used as an application in application override.

Creating a custom application

To create an application with a signature, application traffic needs to be captured and unique bit patterns identified. The custom application can be created with signature and then applied in the security policy rules.

Automatic Packet Captures

The Palo Alto firewall randomly captures traffic that has been identified as unknown by the App ID database.

These logs can be downloaded within the Monitor -> Logs -> Traffic section of the firewall, clicking the green arrow next to the maginifying glass with export the file that can be re-imported into a Network Analyser such as wireshark

To verify that unknown traffic is being captured, the CLI command below can be ran on the firewall to check:

show running application setting | match "Unknown capture"

If the setting is not toggled to on or off, it can be changed with the following command, followed with a commit

set deviceconfig setting application dump-unknown <yes/no>

Manual Packet Captures

The Palo Alto firewall can carry out manual packet captures on the data plane, although it must be noted that an active packet capture may impact firewall performance. The Palo Alto firewall has limited analysis abilities built into it’s web interface.

The Palo Alto firewall can also capture traffic on the control plane, though this is limited to troubleshooting operational issues rather than troubleshooting application identification.

A packet capture to a network analyser offers more benefits over a packet capture to the local Palo Alto. Firewall performance is not impacted and much greater analysing abilities are available to an application dedicated to the task.

Capturing packets on the data plane can be filtered to a number of differnet options, such as:

  • Ingress Interface
  • Source IP address
  • Destination IP address
  • Source Port number
  • Destination Port number
  • Protocol Number
  • Non-IP
  • IPv6

Packets can also be captured at different stages as they progress through the Palo Alto firewall.

  • recieve stage – Captures pre-session packets when they are received on the data plane. Packets will have a pre-NAT address
  • drop stage – Captures packets dropped by the data plane for whatever reason
  • firewall stage – Captures packets matched to a session and processed by the firewall
  • transmit stage – Captures packets matched to a session and trasmitted by the data plane. Captured packets here will have a post NAT address

To take a data plane capture, go to monitor and select the option ‘Packet Capture’

Custom Application Creation

Custom applications can be created under the Objects -> Applications section of the Palo Alto

Once added, the application can be added under the security policy of the firewall.

For applications without a signature, application override can be used.

Categories
EDU-114 Study Palo Alto

Palo Alto EDU-114 Notes: Blocking Threats Using APP-ID

Objects:

Interpret the application labels in logs and reports

Migrate from a port-based Security Policy to an application-based Security policy

Maintain an up-to-date App-ID implementation

App-ID identifies applications in traffic o bserved by the firewall.

Traffic enters the firewall, and is attempted to be identified it’s application signature. If the firewall has decryption of SSL enabled, it will try to decrypt it and attempt to identify the decrypted traffic again by it’s signature.

If the application can not be identified by it’s signature, a protocol decoder attempts to identify the application.

If the protocol decoder fails in it’s identification of the application, the traffics analysed using behavioral heuristics.

At this point, if the traffic can still not be identified. The application is listed as unknown traffic.

At any point the application is identified, it is compared against the Security/Decryption and what action is required to be taken. If the application is not identified the same process can occcur, just under the ‘unknown’ application tag.

The Palo Alto firewall can identy encrypted traffic under the SSL application by decrypting it. Once decrypted the Palo Alto firewall takes the same process as above of trying to identify the traffic using signatures, protocol decoders, and behavioral heuristrics.

Applications can also be identified in Encrypted SSL traffic. If a single website users a unique IP address, the CN in the certificate can be used to identify the website being accessed.

If multiple websites shared an IP address, the SNI field in TLS can be used to identify the website being accessed.

When creating security rules, application id’s should be implemented using a positive security model. This means to specify what to allow rather than what to block – similar to a whitelist.

Being a next generation firewall, the Palo Alto should be configured by block via application, rather than port numbers. Port numbers would be a more typical approach to security on a standard router or layer 3 switch.

Applications can be controlled on non-standard ports. Under the service tab of the security rule, selecting application-default only permits the applications to operate on their commonly known ports. This can be changed to ‘any’ which allows the application to operate on any port. An additional service can be created which allows the Palo Alto administrator to permit the application to be communicated with on ports that may be non standard.

Note that when an application is SSL encrypted, it may operate on a port that is different from the standard port that is commonly known when the application operates in plain text.

Following from Palo Alto OS 9.0, applications do contain two different fields that list applications with their Standard non-SSL ports, and another field that lists their secured ports.

Examples of these applications would be:

  • web-browsing
  • SMTP
  • FTP
  • LDAP
  • IMAP

Application IDs can be identified in the logs, under the column Application in Monitor > Logs > Traffic.

Labeling of TCP traffic in the logs:

  • not-applicable – Traffic dropped from policy before the traffic could be identified
  • incomplete – Three-way handshake dd not complete or was followed by no data
  • insufficent-data – Not enough payload of identification
  • unknown-tcp – Unidentifiable TCP traffic
  • unknown-p2p – Unidentifiable peer-to-peer traffic

Labeling of UDP traffic in the logs:

  • not-applicable – Traffic dropped per polciy before application could be identified
  • unknown-udp – Unidentifiable UDP traffic
  • unknown-p2p – Unidentifiable peer-to-peer traffic

If allowed network traffic is unidentifiable by App-ID, it is examined to see if https is present. If https is present the applcation I.D. is set to SSL. If http is detected, the application I.D. is set to web-browsing. If http is not detected, the application i.d. is set to: unknown-tcp, unknown-udp or unknown-p2p. The traffic log can be examined for further details

Unknown applications can be controlled by blocking the three categories unknown-tcp, unknown-udp and unknown-p2p in a security policy. The application can be manually identified by creating a custom application with a custom signature in Objects -> Applications -> Add. Alternatively an application override policy can be created under Policies -> Application Override

Moving to a Palo Alto firewall, or an application based firewall can be done in a couple of methods. Using the greenfield method or the migration method.

The greenfield method involves putting the firewall in a logging state sitting between the legacy third party firewall and the internet. This can be done in VWire, L3 or TAP mode. The information logged can be used to create a suitable security policy on the firewall based on identified applications in the logs.

The Migration method has three phases.

Phase 1 is to migrate the legacy port based policy to a Palo Alto Networks firewall. The goals being to ensure a succesful cutover, with minimised user issues. In this state the firewall can capture application traffic.

Phase 2 consists of adding application based rules above corresponding port-based rules, reducing the attack surface and removing unknown applications as soon as possible.

Phase 3 consists of removing the old legacy port-based rules, completing the policy migration from a port-based firewall to an application one.

The priortisation of rules to migrate can be found in the policy optimiser, that gives clues to the most common port based ruels in use during a migration. Attention should be paid to the rules that utlise the most traffic with services and no applications defined. The policy optimiser also displays the numbers of applications seen attached to a rule and the number of days since an additional application has been observed. A hit count is present in the Rule Usage section of the Policy Optimiser, so that attention can be paid to the Rules with the most hits.

Policy Optimiser also has a section for Unused Applications, that will identify applications permitted in a security rule that have not been seen in some number of days. This can be useful in optimising rules where previous applications are no longer present

Application and Threat conent updates are pulled to the firewalls from https://updates.paloaltonetworks.com

The content updates for application signatures, including Protocol decoders and Protocol context create App-ID that allows the firewall to identify applications. These updates do not require a licence.

Threat signatures, which contain Threat Signatures along with protocol decoders and protocol contexts create Context-ID. The addition of the Threat Signatures are a licenced feature that require a licence on the Palo Alto firewall.

These two signature types are what the Palo Alto firewall depend on to maintain maximum protection on the network and should be scheduled to update regularly. If an outdated application i.d. can not identify the traffic, then the content i.d. can not inspect traffic for threats.

Two content update workflows are available based on the administrators priority for updating the firewall. If application uptime is the priority:

  • Allow new App-IDs in Security Policy Rule
  • Schedule download and install
  • Review content release notes
  • View new and modified App-IDs
  • Review and update policies
  • Commit the configuration

If security first is the chosen workflow:

  • Schedule a download and install
  • Review content release notes
  • View new and modified App-IDs
  • Review and update policies
  • Commit the configuration

To not block new applications, create a security rule to permit new applications, adding a filter for the sub-category of the new application type you would like to permit. On the application filter ensure the checkbox: Apply to new App-IDs only is ticked.

To schedule the download and install of new applications, see the Dynamic Updates section under Device. Set the schedule to update as requested.

Release notes for the application I.D.’s can be selected on the same page under the Documentation column as well as new and modified applications since the last installed update.

Updates do not need to be scheduled, but can be manually downloaded and installed from the Dynamic Updates page.

The impact of the downloaded application ids can be checked once downloaded against the existing security policy.