EDU-110 Study Palo Alto

Palo Alto EDU-110: Content-ID


Describe the seven different Security Policy Types

Define the two predefined Vulnerability Protection Profiles

Configure Security Profiles to rpevent virus and spyware infiltration

Configure File Blocking Profiles to identify and control the flow of file types through the firewall

Configure a DoS profile to help mitigate Layer 3 and Layer 4 protocol based attacks

Content ID Overview

Content I.D. is a real time threat prevention engine with administrator created policies to inspect and control content flowing through the firewall.

Content I.D. offers a method of detection based on complete analysis of all allowed traffic throught the firewall.

Multiple threat prevention and data loss capabilities are combined into a single unified engine

Applications are identified almost immediatly by the firewall, and allow allowed traffic is analysed for exploits, virures, spyware, malicious URLs and dangerous files or restricted content

Security Policies with Security Profiles

When a security policy rule permits traffic through the firewall, a security profile can be attached than deepens a scan into the traffic flowing through the firewall interface.

It can check for viruses, scan for spyware or exploits, is a malicious URL being accessed? Or is sensitive organisation data being leaked externally?

If a match is found, a predefined action can be taken against the offending session. Simply allow the traffic through, or block it. Ask the user permission if they wish to continue with the offending session, or simply log the threat for an administrator to review later.

Security Profile Types

Vulnerability Protection

Vulnerability protection attempts to scan for known exploiting of vulnerabilities in software taking place in a session

URL Filtering

URL filtering classifies web browsing into categories, and can control it based on it’s content


Anti spyware picks up and nullifys downloading of spyware downlods, carried out from installed spyware from inside the organisation


Antivirus picks up on infected files being transferred from within an application

File Blocking

File blocking tracks and blocks file uploads, and downloads based on the file type and application

Data Filtering

Data filtering identifies and blocks transfer of specific data patterns (credit card numbers) found in network traffic

WildFile Analysis

WildFire forwards unknown files to the WildFire service for malware analysis

Security Profile Group

A security profile group is a set of security profiles treated as a unit, to simply the task of adding seperate profiles to a policy rule.

Anti Spyware DNS Signatures

The cloud based DNS signature database allows instant access to anti-spyware DNS signatures without needing to download any update packets.

It includes built in domain protection logic too, that can detect potentially harmful domains

Each list added to the profile can be configured with their own action. These actions are allow, alert, block, and sinkhole

DNS signature exceptions can be manually added too, meant for the purpose of handling false positives.

To add an exception, enter the DNS signature threat I.D. number in the threat log, and click ‘ADD’.

Anti Spyware Sinkhole Operation

The DNS sinkhole allows infected hosts on the network to be quickly identified.

The default action for Palo Alto DNS signatures is to sinkhole, and the sinkhole IP is a Palo Alto networks server.

The firewall itself can be configured to use another IP address as the sinkhole address.

The sinkhole address does not need to be connected to a real host. The only recommendation would be that the sinkhole address be in a different zoen than the DNS client, so that the traffic violation is logged on the firewall.

File Blocking Overview

File blocking profile blocks prohibited, malicious or suspect files from being downloaded or uploaded to the network.

Three actions can be taken when the profile detects a violation

  • Alert – Allows the transfer, but creates an entry in the data filtering log
  • Continue – Log the activity but allows a file transfer only with the users permission
  • Block – Logs the activity and blocks the file transfer

The continue action gives the user a respone page, requiring a click of a continue button to continue their file download or upload.

The continue action only works when paired to the web-browsing application, and is a useful capability to prevent drive-by downloads.

File blocking can be done on a file type, or per application basis. For example, file attachments could be blocked in gmail but permitted to transfer via FTP.

Blocking Multi-Level Encoded Files

Files can be encoded by multiple layers of protocols and applications.

Encoding has legitimate uses, such as compression, but can also be used to insert malicious data and upload sensitive data.

The Palo Alto firewall can decode a maximum of four-levels of encoding in multi-level files. If a file exceeds this number of levels, it can be blocked by a File Blocking Profile.

Encoding methods that the firewall can decode, are base64, gzip, HTTP 1.1 chunked encoding, pkzip, qpencode, and uuencode.

The configuration can be tested by zipping the same file five times, and attempt to pass the file through the firewall.

Telemetry and Threat Intelligence

Telemetry is a community driven approach to threat prevention.

It allows your firewall to collect and share information about applications, threats, and device health with Palo Alto.

it also performs passive DNS monitoring for all traffic.

The benefits from telemetry is Palo Alto uses the intelligence gathered to delviery enhanced intrusion prevention systems, and spyware signatures to customers worldwide. It allows Palo Alto to test and evaluate experimental sgiantures with no impact to the administrators network.

Telemetry is an opt in feature, and which is shared can be cgosen through the telemetry and threat intelligence settings.

All information gathered from telemetry is saved to the wildfire global cloud, with anonymity preserved and not shared with third party organisations.

Denial of Service Protection

DoS protections use packet header information from layer 3 and layer 4 to detect threats rather than a signature, and are not linked to a security policy.

The zone based protection profile provides a wide comprehensive denial of service protection from the edge of the organisations network, preventing the enterprise engaging from a volumetric denial of service attack.

This DoS zone protection profile acts as a first line of defence for the network.

The DoS protection policy and profiles allow flexible rules and criteria to be matched that protects destination zones and even specific hosts suchg as web servers, dns serves, or any other server that could be prone to DoS attacks.

Zone Protection: Flood Protection

The flood protection profile protects against the most common SYN flood, UDP flood, and ICMP flood attacks

All the categories use random early drop for protection except for SYN, which gives a choice between random early drop and SYN cookies.

There are three thresholds for the zone protection profile,

  1. Alarm Rate – Trigger log events
  2. Activate – Active the mitigation response
  3. Maximum – All further packets above this rate are dropped

When using SYN cookies, the activate threshold should be set to 0 to ensure all TCP connection attempts are tracked

The zone protection profile is disabled by defaulty when the threat prevention licence is installed

EDU-110 Study Palo Alto

Palo Alto EDU-110: App-ID


Define application identification

Describe four major technologies to help identify applications

Configure application filters and application groups

Detect unidentifeid applications that traverse the firewall

Configure scheduling to Application ID

What is an application?

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

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

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

What is App-ID?

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

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

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

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

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

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

App-ID and UDP

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

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

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

App-ID and TCP

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

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

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

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

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

Identifying Applications

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

These are:

Application Signatures

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

Unknown Protocol Decoder

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

Known Protocol Decoder

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

Protocol Decryption

SSL and SSH decryption capabilities

Application ID Operation

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

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

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

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

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

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

Application Shifts

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

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

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

Dependant Applications

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

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

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

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

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

Implict Applications

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

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

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

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

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

Application Filters

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

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

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

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

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

Application Groups

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

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

Groups ultimately simply the administration of a rule base.

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

Nesting Application Groups and Filters

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

Application Block Page

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

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

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

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

A custom HTML page can be crafted and uploaded.

Unknown Network Traffic

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

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

Identifying Unknown Application Traffic

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

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

Controling Unknown Applications

Create a custom application with a custom signature

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

Create a custom application signature to match that bit pattern

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

Configure an application override policy

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

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

Application override also disables the security profiles

Block unknown-tcp or unknown-udp traffic

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

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

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

Updating APP-ID

App ID’s can be scheduled to:

  • Download Only
  • Download and Install

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

Updates to the App ID database are released nearly every week

EDU-110 Study Palo Alto

Palo Alto EDU 110: Security and NAT Policies


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

EDU-110 Study Palo Alto

EDU-110: Palo Alto Interface Configuration


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

EDU-110 Study Palo Alto

EDU-110: Initial Configuration of Palo Alto Firewall


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

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


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 subnet (anything between –

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

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

EDU-110 Study Palo Alto

EDU-110: Security Operating Platform and Architecture


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


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.

EDU-114 Study Palo Alto

Palo Alto EDU-114: Blocking Threats From Stolen Credentials


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


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

EDU-114 Study Palo Alto

Palo Alto EDU-114: Blocking Threats in Allowed Traffic


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.

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.

EDU-114 Study Palo Alto

Palo Alto EDU-114: Custom Threat Signatures


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.