Palo Alto Firewall Notes

PAN--EDU
PAN-EDU-201
EDU--20
201
1
Firewall Installation, Configuration, and
Management: Essentials 1
Student Guide
PAN-OS 6.0
Revision A
Firewall Installation, Configuration, and
Management:
Essentials I
Student Guide
PAN-OS
OS 6.0
6.0
PAN-EDU-201
PAN-
PAN-EDU
EDU-20
201 Rev A
PAN-EDU-201
Palo Alto Networks, Inc.

www.paloaltonetworks.com
© 2007-2014
2014 Palo Alto Networks. All rights reserved.
201
Palo Alto Networks, PAN-OS,
PAN

and Panorama are trademarks of Palo Alto Networks, Inc. All other trademarks are
the property of their respective owners.
Student Guide
Student Guide PAN-OS 6.0 – Rev A Page 2
PAN-EDU-201
Typographical Conventions
This guide uses the following typographical
phical conventions for special terms and instructions.
Convention Meaning Example
Boldface Names of commands, keywords, and Click Security to open the Security
selectable items in the web interface Rule Page
Italics Name of parameters, files, directories, or The address of the Palo Alto Networks
Uniform Resource Locators (URLs) home page is
http://www.paloaltonetworks.com
courier font Coding examples and text that you enter Enter the following command:
at a command prompt a:\setup
Click Click the left mouse button Click Administrators under the
Device tab.
Right-click
click Click the right mouse button Right-click on the number of a rule
you want to copy, and select Clone
Rule.
Student Guide
PAN-EDU-201
Student Guide
PAN EDU 201 Palo Alto Networks. Confidential and Proprietary. Mod 0 page1
PAN EDU 201 Palo Alto Networks. Confidential and Proprietary. Mod page2
This course is designed for students who are new to Palo Alto Networks next generation firewalls.
Previous experience with other network security devices helpful but not required.
To prepare for CNSE Certification we recommend taking the 201 & 205 courses, downloading and
studying the CNSE STUDY GUIDE & CNSE TECH DOCUMENTS and take the ACE EXAM in preparation.
Additional information and a listing of topics included within the CNSE Exam: The CNSE exam tests
much more than just book knowledge of the Palo Alto Networks technologies. The best way to
prepare for the exam is to take the Palo Alto Networks technical training courses and/or to install and
use Palo Alto Networks technologies in many different real world environments. To achieve a
respectable passing score, Palo Alto Networks recommends at least a solid month of working with
the product.
The exam questions are concentrated in the following categories:
Administration & Management

Network Architecture
Security Architecture
Troubleshooting
User Identification
Content Identification
Application Identification
Panorama
GlobalProtect
The Accredited Configuration Engineer (ACE) exam is an accreditation exam. A passing score indicates
that an engineer understands the core features and functionality of the Palo Alto Networks firewall
technologies. The ACE exam is based on the .0 release of a PAN OS version (e.g., 4.0 or 5.0). It is
taken over the internet using a common web browser. The ACE exam serves several purposes:
It can be used as a bar of entry exam, to indicate base product understanding
It can be employed as a study aid for taking the CNSE exam
It is a requirement for those requiring access to the migration tool
The Certified Network Security Engineer (CNSE) is a formal certification. Achievement of this
certification proves that a candidate possess an in depth engineering level knowledge of how to
install, configure, and implement Palo Alto Networks products. The CNSE exam is based on the .1
release of a PAN OS version (e.g., 4.1 or 5.1). It should be taken by anyone who wishes to
demonstrate a deep understanding of the Palo Alto Networks technologies. This
includes customers who use Palo Alto Networks products, value added resellers, pre sales
system engineers, system integrators, and varied tiers of support staff.
The Support Portal provides administrators a way to get assistance managing Palo Alto Networks
firewalls. The site has links which allow users to:
• Download software and updates for their firewalls
• Open and manage support cases
• Access product documentation and white papers
• Share custom content such as custom App IDs, custom threats, CLI scripts and other tools
The KnowledgePoint communities provides users a way to connect with peers to ask questions,
exchange ideas, share experiences and knowledge. These communities are user driven, built by users
asking and answering each others questions.
The Palo Alto Networks Education website is the primary source of information regarding training on
Palo Alto Networks firewalls. Users can access course catalog and scheduling information for any of
the courses offered by Palo Alto Networks. For those seeking certification, information regarding the
ACE and CSNE programs can be found here as well.
At the end of each module students will be required to perform a number of lab exercises designed
to reinforce what was covered within that module. The labs build upon each other and so it is
important that each lab be performed at the end of each module.
Palo Alto Networks has built a next generation firewall with several innovative technologies
enabling organizations to fix the firewall. These technologies bring business relevant elements
(applications, users, and content) under policy control on a high performance firewall
architecture.
Delivered as a purpose built appliance, every Palo Alto Networks next generation firewall
utilizes dedicated, function specific processing that is tightly integrated with a single pass
software engine. This unique combination of hardware and software maximizes network
throughput while minimizing latency. Each of the hardware platforms supports the same rich
set of next generation firewall features ensuring consistent operation across the entire line.
architecture.
The Palo Alto Networks® PA 7050 is designed to protect datacenters and high speed networks
with firewall throughput of up to 120 Gbps and full threat prevention at speeds of up to 100
Gbps. The PA 7050 is a modular chassis, allowing you to scale performance and capacity by
adding up to six network processing cards as your requirements change; yet it is a single
system, making it as easy to manage as all of our other appliances.
enabling organizations to empower, enhance and fix some of the shortcomings within
traditional firewalls. These innovative technologies bring business relevant elements
(applications, users, and content) under policy control via a high performance firewall
architecture.
Delivered as a purpose built appliance every Palo Alto Networks next generation firewall
set of next generation firewall functions and features, including it Operation System, the PAN
OS, ensuring consistent operation across the entire line.
The WF 500 is specifically for organizations that prefer not to use public cloud applications
due to regulatory and privacy concerns and so when using the WF 500 they can deploy
WildFire as a private cloud.
Note: The WF 500 is fundamentally an X86 dual processor server, not a PA series firewall. It
uses a different architecture as opposed to the PA Series firewalls which do have and use the
Single Pass Processing SP3 Architecture.
enabling organizations to empower, enhance and fix some of the shortcomings within
traditional firewalls. These innovative technologies bring business relevant elements
(applications, users, and content) under policy control via a high performance firewall
architecture.
Delivered as a purpose built appliance every Palo Alto Networks next generation firewall
set of next generation firewall functions and features, including it Operation System, the PAN
OS, ensuring consistent operation across the entire line.
Here we will learn of the Panorama M 100 Virtual Appliance, its purpose and
recommended use.
architecture.
Here we will learn of the Panorama M 100 Virtual Appliance, its purpose and
recommended use.
Use the same language from the original SP3 slide,
Purpose built use a racing vehicle analogy any racing vehicle; a car, a motorcycle,
whatever. They go fast because of the sum or their parts = engine, suspension, tires, body,
driver.
We did the same thing built SW that was as efficient as possible, using a single pass to
perform the heavy lifting (L7 classification and inspection) Operations once per packet Traffic
classification (app identification), Content scanning threats, URLs, confidential data = One
policy.
then we married it to a HW platform that scales upwards and downwards using dedicated
processors for NW, Security (cavium multi core), threat and management. Separate
data/control planes for built in resiliency.
PAN EDU 201 Palo Alto Networks. Confidential and Proprietary. 10

The Palo Alto Networks firewall allows you to specify security policies based on a more
accurate identification of each application seeking access to your network. Unlike traditional
firewalls that identify applications only by protocol and port number, the firewall uses packet
inspection and a library of application signatures to distinguish between applications that
have the same protocol and port, and to identify potentially malicious applications that use
non standard ports.
The strength of the Palo Alto Networks firewall is its Single Pass Parallel Processing (SP3)
engine. Each of the current protection features in the device (Anti Virus, Spyware, Data
Filtering and vulnerability protection) utilize the same stream based signature format. As a
result, the SP3 engine can search for all of these risks simultaneously.
The advantage of providing a stream based engine is that the traffic is scanned as it crosses
the box with a minimal amount of buffering.
For further explanation, refer to the document

Single_Pass_Parallel_Processing_Architecture.pdf on the Palo Alto Networks website.
While a seemingly trivial and obvious approach, security software that looks at traffic in a
single pass is unique to the Palo Alto Networks next generation firewall. This approach to
processing traffic ensures that each particular task is performed only once on a set of traffic.
Key processing tasks are:
• Networking and management functionality: at the foundation of all traffic processing

is a common networking foundation with a common management structure.
• App ID (Application identification): a combination of application signatures, protocol
detection and decryption, protocol decoding, and heuristics to identify applications.
This application identification is carried through to the Content ID functionality to scan
and inspect applications appropriate to their use as well as to the policy engine.
• Content ID: a single hardware accelerated signature matching engine that uses a
uniform signature format to scan traffic for data (credit card numbers, social security
numbers, and custom patterns) and threats (vulnerability exploits IPS, viruses, and
spyware) plus a URL categorization engine to perform URL filtering.
• User ID: maps IP addresses to active directory users and users to groups (roles) to
enable visibility and policy enforcement by user and group.
• Policy engine: based on the networking, management, User ID, App ID, and Content ID
information, the policy engine is able to use a enforce a single security policy to traffic.
With Palo Alto Networks single pass parallel processing architecture, hardware acceleration is
provided for each of the major functionality blocks:
• Networking tasks (per packet routing, flow lookup, stats counting, NAT, and similar
functions) are performed on a dedicated network processor.
• User ID, App ID, and policy engine all occur on a multicore (up to 16 cores) security
processor with hardware acceleration for encryption, decryption, and
decompression.
• Content ID performs the signature lookup via a dedicated FPGA with dedicated
memory.
• Management functionality is provided via a dedicated control plane processor that
drives the configuration management, logging, and reporting without touching data
processing hardware.
This diagram is a simplified version of the flow logic of a packet traveling through a Palo Alto
Networks firewall. The course will reference this diagram to address where specific concepts
fit into the packet processing sequence.
Refer to the document Packet Flow in PAN OS on the KnowledgePoint site for a more
complete understanding of the session flow through the Palo Alto next generation firewall.
Palo Alto Network firewalls are built with a dedicated out of band management interface
labeled MGT. This interface only passes management traffic for the device and cannot be
configured as a standard traffic interface. Administrators use this interface for direct
connectivity to the management plane of the firewall. By default, this interface has an IP
address of 192.168.1.1.
Initial configuration of the firewall can be accomplished by connecting to the MGT interface
address or through a console session on the firewall. The console interface is an RJ 45
connection for all devices except for the PA 4000 series which uses a serial interface instead.
The default username of admin has a default password of admin

admin. A warning message will
appear in both the GUI and the CLI until the default password is changed. The admin account
cannot be deleted or disabled.
The system defaults can be restored by performing a factory reset of the device from
Maintenance Mode. Refer to the support website for instructions for this procedure.
This example shows the steps to configure the networking of the MGT interface of a PA 500
firewall for use in the training lab.
The MGT interface is for the management of the firewall only. If desired, the device can be
configured to allow firewall management over the traffic interfaces. However, the MGT
interface cannot be set up to pass regular traffic.
The device requires updates to software and to the databases to maintain the most current
protection levels. The MGT interface or a traffic interface must be configured to allow these
updates to be downloaded. The firewall requires DNS name resolution to connect to the
update servers.
The MGT interface can also be set up with the GUI. Palo Alto Networks firewalls are
configured with an IP address of 192.168.1.1 on the MGT interface by default.
Assign the Ethernet interface on your computer a 192.168.1.0/24 address and connect to the
MGT interface with an Ethernet cable. Launch a web browser connection to
https://192.168.1.1 and log in using the default user name and password. Click Device >
Setup > Management then click the button on the Management Interface Settings panel.
From this location, you can set the networking information for the MGT interface of your
firewall.
The GUI is supported on Internet Explorer 7+, Firefox 3.6+, Safari 5+, and Chrome 11+.
By default, HTTP and telnet are disabled on the MGT interface but HTTPS, SSH, Ping, and
SNMP are allowed. These settings can be configured as appropriate for your environment. For
additional security, the Permitted IP Addresses field restricts administrative access to specific
IP addresses.
If you experience intermittent GUI connectivity issues, changing the Speed attribute from
auto negotiate to match the settings of your network may alleviate the problem.
Administrators have multiple options when configuring a Palo Alto Networks firewall.
The most common way of managing the device is through the web interface (GUI).
Administrators can configure and monitor the firewall over HTTP/HTTPS from a web browser.
This graphical interface provides detailed administrative and reporting tools in an intuitive
web format.
The PAN OS CLI allows you to access the firewall, view status and configuration information,
and modify the configuration. Access to the PAN OS CLI is provided through SSH, Telnet, or
direct console access.
Palo Alto Networks also provides a Representational State Transfer (REST) based interface to
access device configuration, operational status, reports, and packet captures from the
firewall. There is an API browser available on the firewall at https://<firewall>/api, where
<firewall> is the host name or IP address of the firewall. This link provides help on the
parameters required for each type of API call.
The PAN OS WebUI is consistent across all Palo Alto Networks firewall hardware types.
Administrators will see the same interface when they connect to a PA 200 as when they
connect to a PA 5050.
The management tools are grouped according to functional categories. These categories are
listed as tabs at the top of the interface to allow for ease of switching between administrative
tasks. Blue text indicates a link which can be clicked for additional information or to configure
that feature.
The Tasks button at the bottom right of the screen provides a list of running and completed
tasks for this firewall. This button is especially useful when verifying that configuration
changes have been committed.
The Help button opens a HTML formatted version of the PAN OS Administrator Guide. This
searchable manual provides information about the options shown on screen when it is
clicked.
The web interface defaults to US English but can be set to other languages if desired.
Currently supported languages are:
• Chinese Traditional
• Chinese Simplified
• English
• French
• Japanese
• Spanish
Inform the Students Language selection is dynamic and does not require a commit operation
or a reboot of the interface.
The GUI provides guidance as you configure the firewall. Red underlines indicate tabs which
must be completed for a given interface. Yellow highlights specify required fields. The OK
button will be unavailable if the interface is missing required information.
When analyzing network traffic, a good starting point is the Application Command Center
(ACC) tab, which provides a high level overview of network traffic based on application and
threat visibility. The ACC displays the overall risk level for your network traffic, the risk levels
and number of threats detected for the most active and highest risk applications on your
network, and the number of threats detected from the busiest application categories and
from all applications at each risk level. The ACC can be viewed for the past hour, day, week,
month, or any custom defined time frame.
Risk levels range from 1 (low) to 5 (high) and indicate the applications relative security risk
based on criteria such as whether the application can share files, is prone to misuse, or tries
to evade firewalls.
The Monitor tab contains the displays the logs for the Palo Alto Networks firewall. Log entries
are added to the traffic database at end of session by default. All other logs are updated when
a policy match occurs while processing network traffic.
The log in the Monitor tab show a summary of the event in the GUI. For a more detailed
description of the event, click the magnifying glass icon on the left side of the entry.
When you first log in, the PAN OS CLI opens in Operational mode. Operational mode
commands involve actions that are executed immediately. They do not involve changes to the
configuration, and do not need to be saved or committed.
When you enter Configuration mode and enter commands to configure the firewall, you are
modifying the candidate configuration. The modified candidate configuration is stored in
firewall memory and maintained while the firewall is running. Each configuration command
involves an action, and may also include keywords, options, and values. Entering a command
makes changes to the candidate configuration.
The most common CLI response is invalid syntax due to incomplete command keywords
entered.
The built in help function of the CLI allows the administrator to look up commands and
options without leaving the interface.
For example, if an administrator was attempting to configure security rules and forgot the
available options, this might be the output:
username@hostname# set rulebase security rules rule1 profiles ?
+ virus Help string for virus
+ spyware Help string for spyware
+ vulnerability Help string for vulnerability
+ group Help string for group
<Enter> Finish input
[edit]
Notice when searching for the keyword fpga there are a total of 6 different commands
containing the keyword fpga.
Quotation marks are an optional way to search for a specific character string. Also use
quotations to search for multiple words in a specified sequence. Example To search for a
string of words such as tcp asymmetric path above you must use quotations or you will
receive an invalid syntax response.

To conduct a search on all available commands you can use the find command option for a
complete listing of commands.

PAN OS provides a RESTful XML API to manage both the Firewall and Panorama devices. The
API allows access to several types of data on the device so they can be easily integrated with
and used in other systems. The API is provided as a web service that is implemented using
HTTP requests and responses.
The API connection is treated as general administrator web access with the same source
address restriction and timeout settings. For security, the connection requires a key generated
with admin ID and password info or a current authenticated administrative session.
An XML API usage guide is available on the DevCenter online community at

http://live.paloaltonetworks.com.
There is an API browser available on the firewall at https://<firewall>/api, where
<firewall> is the host name or IP address of the firewall.
You need to be logged in to the devices web interface to be able to view the API browser.
Once you have logged onto the firewall, change the URL to https://hostname/api.
You can use API browser to navigate different API requests that are available for use. For
configuration commands, you can navigate to any path and view the corresponding xpath and
API URL on the browser. For Operational commands and Commit commands, you can navigate
to a specific command to see the xml body to use for the command parameter. For reports,
you can view the report names for all the supported dynamic and predefined reports.
PAN EDU 201 Palo Alto Networks. Confidential and Proprietary. Mod 2 page 1
By default, only the pre defined admin account has access to the firewall. Additional
administrator accounts can be added to the firewall for delegation and auditing purposes.
The firewall supports both locally defined users and server based authentication configurations,
such as RADIUS and LDAP. User accounts can be tailored to individual user needs, granting or
restricting permissions as appropriate.
A virtual system specifies a collection of physical and logical firewall interfaces (including VLANs
and virtual wires) and security zones. Virtual systems represent management boundaries,
restricting administrators to only the portion of the firewall assigned to them by a device
administrator. Multiple virtual system configurations are supported on the PA 2000, PA 3000, PA
4000, and PA 5000 series firewalls. There is no support for multiple virtual systems on PA 200,
PA 500, or VM series firewalls, although you will see vsys1 and Location on some screens.
Virtual system configurations are covered in more detail in the PAN EDU 205 course.
Server profiles define connections that the firewall can make to servers of specific types. For
authentication purposes, you can specify RADIUS, LDAP, or Kerberos servers. Authentication profiles
require server profiles in order to validate login information for users not created on the firewall.
For accounts not stored on the local database, an Authentication Profile must be created. An
Authentication Profile represents a link between an authentication source and the users from that
source that will be authenticated. The default is to allow all users allowed by the server profile.
If users might be authenticating from multiple sources, an authentication sequence can be used
instead. Authentication sequences specify multiple authentication profiles in an ordered list. As users
attempt to log in, they are checked against the list on a first match basis. In the example, users will
be checked against the PAN AD authentication profile first. If they cannot be validated with that
profile, the firewall will then attempt to authenticate against the RADIUS server.
The Admin Roles page defines role profiles that determine the access and responsibilities available
to administrative user accounts on the firewall. Administrators can be given rights by assigning
privileges to an admin role and then assigning that role to a specific user.
There are three parts to an admin role, the Web UI (GUI) permissions, the XML API permissions, and
the CLI permissions.
For the Web UI, levels of Enable, Read Only, and Deny can be applied to the sections defined by
nodes on the navigation tree. For the XML API, only Enable and Deny are available. All options are
set to Enable by default.
Multi virtual system capable firewalls can also create roles for virtual system level administrators.
The roles created are generic and are only assigned to a specific virtual system when attached to a
user account.
User rights while using the CLI are defined using the built in roles. No customization of these roles is
allowed. The built in roles are:
• None No access granted to the CLI
• superuser All access to all options of the device and all virtual systems
• superreader Read only access to all options of the device and all virtual systems
• deviceadmin Same as superuser except for creation of administrative accounts and virtual
systems
• devicereader Same as superreader except for administrative account and virtual system
creation information
• vsysadmin Full access to a virtual system
• vsysreader Read only access to a virtual system
The limits of the administrator account is determined by the Role assigned to the account.
• Dynamic: User rights are defined using the built in roles. These permissions affect both the GUI
and the CLI.
• Superuser All access to all options of all virtual systems
• Superuser (read only) Read only access to all options of all virtual systems
• Device administrator Full access to the device except for creation of virtual systems and
administrative accounts
• Device administrator (read only) Read only access to the device except for creation of
virtual systems and administrative accounts
• Virtual system administrator Full access to a specific virtual system
• Virtual system administrator (read only) Read only access to a specific virtual system
• Role Based: Permissions are based on a user defined role created on the firewall.
When you change a configuration setting and click OK, the current or candidate configuration
is updated, not the active or running configuration. Clicking Commit at the top of the page
applies the candidate configuration to the running configuration, which activates all
configuration changes since the last commit.
PAN OS allows for granular commits. You can choose to commit just Device and Network
configurations or Policy and Object configurations. If you need to check on the current status of
a commit, the Tasks button at the bottom of the screen will provide detailed information about
running and recently completed tasks. Only one commit operation can be run on the firewall at
any time.
If the firewall is multi virtual system capable, the Commit window allows device level
administrators to choose whether to commit the configuration to the device or to specific virtual
systems only. However, a running virtual system commit operation will prevent other virtual
systems on the same firewall from committing their configurations at the same time.
The Preview Changes displays a side by side comparison of the running and candidate
configurations before you commit. Differences in the configurations are color coded to indicate
which information has been added, deleted, or modified. This is similar to the Config Audit
feature, which is discussed later in the module.
The web interface provides support for multiple administrators by allowing an administrator to
perform a either a config lock or a commit lock, thereby preventing configuration changes or
commit operations by another administrator until the lock is removed. The following types of
locks are supported:
• Config lockBlocks other administrators from making changes to the configuration.

This type of lock can be set globally or for a virtual system. It can be removed only by
the administrator who set it or by a superuser on the system.
• Commit LockBlocks other administrators from committing changes until all of the
locks have been released. This type of lock prevents collisions that can occur when two
administrators are making changes at the same time and the first administrator
finishes and commits changes before the second administrator has finished. The lock is
released when the current changes are committed, or it can be released manually.
Any administrator can open the lock window to view the current locks, along with a timestamp
for each.
You can save and roll back (restore) the candidate configuration as often as needed and also
load, validate, import, and export configurations. Pressing Save creates a copy of the current
candidate configuration, whereas choosing Commit updates the running (active) configuration
with the contents of the candidate configuration. A save operation is not required before a
commit.
A complete set of configuration management actions can be found on the Device > Setup >
Operations screen. From this location, you can select a configuration from a list of save configs
or even export a configuration for use on another firewall of the same hardware type. This page
allows you to revert the candidate configuration to the running configuration to back out of
unwanted changes made to the candidate configuration.
Note: An exported configuration will include all settings of the firewall, including MGT interface
settings. Be sure to edit the MGT settings (e.g., IP address, subnet mask) before importing and
committing the configuration on another firewall.
You can view and compare configuration files by using the Config Audit page. From the drop
down lists, select the configurations to compare. Select the number of lines that you want to
include for context, and click Go. The system presents the configurations and highlights the
differences.
The color coding indicates the type of change in the comparison: red indicates a deletion, yellow
shows a change, green highlights an addition.
It is a good idea to perform a config audit on the running and candidate configurations prior to a
commit to visually verify the changes that will be made to the firewall.
The Palo Alto Networks firewall features are licensed individually. You can activate just the
functionality that you need for your implementation. Only features that are currently licensed
are displayed in the Device > Licenses section of the GUI. In the example above, the firewall is
licensed for URL Filtering, Threat Prevention, and GlobalProtect but not the WildFire subscription
service. Licensing will be discussed in more detail when the individual features are covered in
this course.
In addition to the feature licenses, the firewall must also have a valid support license. The
support license entitles you to access the Support website and submit trouble tickets to the
Technical Assistance Center (TAC). Additionally, the support license enables you to receive
product and security alerts from Palo Alto Networks based on the serial number of your firewall.
Palo Alto Networks posts updates with new or revised application definitions, information on new
security threats, such as antivirus signatures, URL filtering criteria, and updates to GlobalProtect
data. You can view the latest updates, read the release notes for each update, and then select the
update you want to download and install. Application and Threat updates require a threat
prevention license to download.
Updates are issued on the following schedule:

• Antivirus: daily
• Applications and Threats: weekly
• URL Filtering: daily
On the Dynamic Updates page, you may see two entries listed in the Application and Threats,
Antivirus, or URL Filtering area, one for the currently installed version and one for the latest version
available on the update server. If the latest version is already installed, there is only a single entry.
Additional information can be found in the whitepaper entitled Best Practices for Managing Content
Updates on KnowledgePoint.
To upgrade to a new release of the PAN OS software, you can view the latest versions of the PAN OS
software available from Palo Alto Networks, read the release notes for each version, and then select
the release you want to download and install. A support license is required for the download.
Software Updates require a firewall reboot. Use the Check Now button to see the most current list
of available updates.
If you are upgrading to a maintenance release directly from a previous major version (e.g., 4.1.9 to
5.0.1), you must download the .0 release prior to installing the maintenance release. For example, to
upgrade from 4.1.9 to 5.0.1, you would download both 5.0.0 and 5.0.1. However, the base release
(5.0.0) only needs to be downloaded. It does not have to be installed prior to clicking Install for the
5.0.1 software.
Software can be downloaded directly from the Palo Alto Network update server or the software can
be downloaded to another system, such as a user desktop or a Panorama server, and uploaded to
the firewall. The management interface of the firewall must be configured with DNS servers to
resolve the name of the Palo Alto Network update server (updates.paloaltonetworks.com) for the
direct download method to succeed.
When upgrading, the firewall must be running the most recent version of the Application and
Threats updates. If not, the installation process will fail and prompt you to update the Application
and Threats file.
The firewall can be gracefully shutdown or rebooted from the GUI. The candidate configuration in
memory will be lost upon either action so be sure to save or commit if you wish to preserve your
changes.
If you prefer to manage the firewall from the CLI, the equivalent commands are:
admin@PA-500> request restart system
admin@PA-500> request shutdown system
admin@PA-500> request restart dataplane
If the firewall is shutdown by these commands, it must be powered up manually by unplugging and
reconnecting the power cords on the firewall. The 2000 Series firewalls can be powered up by
toggling the power switch.
As features of the Palo Alto Networks firewalls are discussed in this course, knowing where they fit into
the packet flow through the firewall is critical. The above diagram will be referenced in the modules to
provide context for the topics presented.
For a more detailed discussion of the packet handling sequence inside of a PAN OS device, refer to the
Packet Flow in PAN OS document available on the support website.
The Palo Alto Networks firewall can replace your existing firewall when installed between an Internet
facing device and a switch or router that connects to your internal network. The firewall supports a
wide range of deployment options and interface types that can be used simultaneously on different
physical interfaces.
This module addresses the interface types most commonly implemented in new firewall deployments.
The other interface types will be addressed as appropriate in later modules.
Note: The New Decrypt Mirror Port will be explained within the subsequent slides within this
section.
Interface types are slightly different for the PA 7000 series.
There are numerous methods to integrate Palo Alto Networks firewalls into your environment. Many
implementations evolve over time, transitioning between some or all of the possible configurations listed
below.
Lets review some of the few Ethernet Interfaces that can be utilized and employed based upon your
deployment method.
• Tap Mode: By utilizing tap mode interfaces, the firewall can be connected to a core switchs span
port to identify applications running on the network. This option requires no changes to the
existing network design. In this mode the firewall cannot block any traffic.
• Virtual Wire Mode: Using virtual wire interfaces the firewall can be inserted into an existing
topology without requiring any reallocation of network addresses or redesign on the network
topology. In this mode, all of the protection and decryption features of the device can be used.
NAT functionality is provided in this mode.
• Layer 2 Mode: In this mode, all of the protection and decryption features of the firewall can be
used for Trunk (VLAN) interfaces. Layer 3 support, for VLAN switching, can be employed with
VLAN interfaces.
• Layer 3 Mode: Using Layer 3 interfaces the firewall can take the place of any current enterprise
firewall deployment.
A unique advantage of the firewall is the ability to mix and match these interface types on a single device.
The same firewall could be deployed in tap mode for one portion of the network while being in virtual wire
mode for another.
The Ethernet Interface types tap, virtual wire, HA, Layer 2, Layer 3 all use a common configuration
interface. You click Network > Interfaces > Ethernet and then click the name of the interface to be
configured to access this screen. The Config tab will change based on the configuration options
available for the interface type that you select.
By utilizing tap mode interfaces, the device can be connected to a core switchs SPAN or mirror port to
identify applications running on the network. This option requires no changes to the existing network
design. In this mode the device cannot block traffic or filter based on URL.
If the SPAN port passes encrypted traffic, the tap interfaces only support SSL inbound decryption. An
internal server certificate must be installed on the firewall and a decryption policy defined for the
traffic to be decrypted. Decryption will be discussed in detail later in this course.
Even though tap interfaces do not pass traffic like the other interfaces do, a zone assignment is still
required. Policies are required for logging and policies require zones to work. To allow logging, policies
will be configured with both the source and destination zones set to the zone containing the tap
interface.
When using virtual wire interfaces, the device can be inserted into an existing topology without
requiring any reallocation of network addresses or redesign on the network topology. In this mode, all
of the protection and decryption features of the device can be used. If necessary, a virtual wire can
block or allow traffic based on the virtual LAN (VLAN) tag values. NAT functionality is provided in this
mode.
A virtual wire is defined in two steps creating the virtual wire object and configuring the virtual wire
interfaces that the object connects. These steps can be done in any order.
If the virtual wire interfaces have not yet been configured, the interface fields can be left blank.
A virtual wire can block or allow traffic based on 802.1Q VLAN tag values. Specific tag numbers (0 to
4094) or a range of tag numbers (tag1 tag2) can be specified to limit the
traffic allowed on the virtual wire. A tag value of zero, which indicates untagged traffic, is the default.
Multiple tags or ranges must be separated by commas. Traffic that has an excluded tag value is
dropped. Tag values are not changed on incoming or outgoing packets. To allow all traffic, both tagged
and untagged, set Tag Allowed to 0 4094.
Select the check box entitled Multicast Firewalling if you want to be able to apply security rules to
multicast traffic. If this setting is not enabled, multicast traffic is forwarded across the virtual wire.
If the virtual wire object has not been configured, the Virtual Wire field can be left blank. The interface
names can be specified when the virtual wire object is created.
Since traffic will flow between virtual wire interfaces, a zone is required. Only zones that match the
Interface type will be presented by the pull down in the interface.
The firewall can generate and export Netflow Version 9 records with unidirectional IP traffic flow
information to an outside collector. Netflow export can be enabled on any ingress interface in the
system. This feature is available on all platforms except the 4000 Series models.
In a Layer 2 deployment, the firewall provides switching between two or more networks. Each group of
interfaces must be assigned to a VLAN object and additional Layer 2 subinterfaces can be defined as
needed. The Layer 2 interface provides standards based support for 802.1Q VLANs, but does not
support Spanning Tree Protocol (STP).
In a Layer 3 deployment, the firewall routes traffic between multiple interfaces. An IP address must be
assigned to each interface and a virtual router must be defined to route the traffic. Layer 3 interfaces
are required if routing is to be implemented.
The minimum required properties to configure a Layer 3 interface are the IP address, zone, and virtual
router. When the Palo Alto Networks firewall is operating in Layer 3 mode, it can provide routing and
Network Address Translation functions. All Layer 3 interfaces in a specific virtual router will share the
same routing table. Layer 3 interfaces can be configured as a DHCP client for situations where the
firewall is required to have a dynamically assigned IP address.
Layer 3 interfaces can also be configured to provide access to the management interfaces by assigning
them a Management Profile, discussed in the next module.
In some environments, there is no need for the firewall to provide multiple switch ports on a given
VLAN. Existing switching infrastructure may be sufficient. In these cases the firewall can be configured
to accept a 802.1q tagged trunk. Trunk ports carry traffic from multiple VLANs, each distinguished with
a unique header.
Using subinterfaces, a Layer 2 interface can have a virtual interface on each of the VLANs on the trunk.
Any untagged traffic will be processed by the base Layer 2 physical interface.
Layer 3 subinterfaces are most common when the firewall will be responsible for routing between the
tagged VLANs. The configuration is much the same as Layer 2 interfaces with the addition of virtual
router and IP address requirements.
Virtual wire subinterfaces are designed to allow classification of traffic into different zones and virtual
systems without requiring additional physical interfaces. This feature will be used primarily in multi
tenant environments in which the firewall must be transparent to neighboring networking devices.
You can configure one or more Ethernet interfaces as Layer 2 interfaces for untagged VLAN traffic. For
each main Layer 2 interface, you can define multiple Layer 2 subinterfaces for traffic with specific VLAN
tags.
Each Layer 2 interface that is defined on the firewall must be associated with a VLAN object if Layer2
switching is required to be performed by the firewall. A VLAN object is a Layer 2 switch object that
allows multiple Layer 2 physical interfaces and subinterfaces to be associated into a single switching
domain. Multiple Layer 2 interfaces can be assigned to a single VLAN object, but each Layer 2 interface
or subinterface can belong to only one VLAN object. VLAN objects can switch tagged and untagged
traffic
All of the steps required to configure Layer 3 interfaces apply to Layer 3 subinterfaces.
Untagged layer 3 subinterfaces may also be used when the Untagged Subinterface option is enabled
on the parent Layer 3 interface. Untagged subinterfaces are used in multi tenant environments where
traffic from each tenant must leave the firewall without VLAN tags. In this case, all traffic must be
configured for source NAT using the IP address of the untagged subinterface.
Note that you do not specify the virtual wire object during the creation of the subinterface. Since the
subinterface is built on an existing virtual wire interface, the virtual wire object is inherited from the
parent interface. However, the subinterface and parent interface can be configured on different zones.
Virtual wire sub interfaces provide flexibility in enforcing distinct policies when you need to manage
traffic from multiple customer networks. The sub interfaces allow you to separate and classify traffic
into different zones by either VLAN tags or VLAN tags in conjunction with IP classifiers (address, range,
or subnet). You can also use IP classifiers for managing untagged traffic. To do so, create a sub interface
with the VLAN tag 0, then define the sub interfaces IP classifiers to manage the untagged traffic.
For additional information, refer to the Virtual Wire Deployments section of the Palo Alto Networks
Administrators Guide.
Loopback interfaces can be used to provide Layer 3 services such as in band management,
GlobalProtect portal or gateway functionality, and IPSec. Each loopback interface behaves as a host
interface and is assigned an IP address. A /32 netmask is required for loopback interface addresses.
As with other Layer 3 interfaces, the routing table for a loopback interface is inherited from the virtual
router to which it is assigned.
A tunnel interface is a logical Layer 3 interface which represents a specific VPN configuration. Any
traffic that is routed to this interface will be tunneled according to the configuration of the IPSec VPN
object associated with the tunnel interface.
Tunnel interfaces will be discussed in the VPN module of this course.
Aggregate interfaces provide two key benefits to Palo Alto Networks firewalls: increased throughput
and link redundancy. Aggregate interfaces are supported on PA 500 and larger firewalls. Each firewall
can support up to eight aggregate interfaces.
Aggregate interface groups allow you to generate more than 1 Gbps aggregate throughput by using
802.3ad link aggregation of multiple 1 Gbps links. Aggregation of 10Gbps XFP and SFP+ is also
supported. Aggregated interfaces must be all of the same type (i.e. all copper or all fiber). The
aggregate interface that you create becomes a logical interface. Interface management, zone profiles,
VPN interfaces, and VLAN subinterfaces are all properties of the logical aggregate interface, not of the
underlying physical interfaces.
Each aggregate group can contain up to eight physical interfaces of the type Aggregate Ethernet. After
the group is created, you perform operations such as configuring Layer 2 or Layer 3 parameters on the
Aggregate Group object rather than on the Aggregate Ethernet interfaces themselves.
Note: Though aggregate virtual wire interfaces are possible, the recommended practice is to create
parallel virtual wires with common source and destination zones. This configuration allows traffic to
traverse any virtual wire at any time, rather than be restricted by the aggregate interface rules.
Requires a free Decryption Port Mirror license which can be downloaded from the Support Site.
When configuring use the drop down arrow to Select Decrypt Mirror for Interface Type.
This interface type will only appear if the license for Decryption Port Mirror is installed. If the
license has not been installed this option will not be displayed.
Requirements:
• Requires SuperUser privilege
• Support SSL Inbound, SSL Forward Proxy, SSH Decryption
• Target use cases are large scale packet capture and Data Leak Prevention (DLP)
Tested with NetWitness and Solera for large PCAP
Tested with Symantec DLP Network Monitor
• Provides a new mirror flag on sessions
• Management traffic terminating on the firewall is not monitored
• NAT scenario
Ingress (c2s flow used)
s2c flow is generated as reverted c2s
• L3/L4 headers and checksums are regenerated on the mirror port
• TCP 3 way handshake and FIN/RST synthetized
Is possible for the packet size to not be the same as we are decrypting the full SSL record (16kB) before
sending to the mirror port.
Please note, though the license is free it does require administrators to do the following:
• Go to the Support Site to request the license.

• Agree to the legal disclaimer
• Activate by rebooting the firewall.
PASeries Platforms Supported:

PA 3000
PA 5000
PA 7000
Performance
Decryption rate 5% (inbound inspection)
Panorama
Supports creation of Mirror interfaces
Forwarded logs have Mirror flag
Palo Alto Network firewalls use the concept of security zones. Zones are a logical grouping based on a
particular type of traffic on your network. The physical location of the traffic is irrelevant. Zone names
have no predefined meaning or policy associations.
Systems with similar security needs are grouped into zones. For example, the traffic going out of a DMZ
server is very different then the traffic on a server in the corporate datacenter. We would expect to see
traffic initiated from the internet making connections into the DMZ, but we would never want to see
that same kind of traffic into the datacenter.
When you define a security policy rule, you must specify the source and destination security zones of
the traffic. Separate zones must be created for each type of interface (Layer 2, Layer 3, virtual wire, tap)
and each interface must be assigned to a zone before it can process traffic. Security policies can be
defined only between zones of the same type.
Security policies are evaluated in the order they are listedted in the firewall. Traffic is compared
against each rule in the list. If the traffic matches the rule, no further
rther rules are evaluated. If the
rule does not match, the next rule is checked.
A Palo Alto Networks firewall enforces two implicitit rules if traffic has not matched any user
defined security policies:
• Traffic within a single zone is allowed.
• Traffic between two zones is denied.
These two rules are processed after all user defined rules, either from the local device or
Panorama. Implicit rules do not generate traffic log entries.
Caution: An explicit “deny-all” rule at the end of the user-defined policies will be processed
before the implicit rules, denying intra-zone traffic.
Security zones are defined by type. The available types are:
• Tap
• Virtual Wire
• Layer 2
• Layer 3
• External*
*The External zone type is a special zone. It allows traffic to pass between virtual systems when
multiple virtual systems are configured on the same firewall. The External zone type will only be visible
in the pull down menu if it is supported by the firewall model and the multi vsys feature has been
enabled.
A logical interface, including VLAN tagged subinterfaces, must be a member of a single zone. A zone
may have multiple interfaces, but an interface can only be in a single zone. The zone is a required
attribute for any interface to process traffic.
With the exception of intra zone traffic, any traffic not explicitly allowed by a security policy is denied.
The only way to allow traffic between zones is to create an allow policy specifying the source and
destination zones. The interfaces used for the traffic are not considered by the policies, just the zones.
In this example there are two Security Policy defined with source traffic from Trust L3 and the
destination zone of Untrust L3. Set the Action for any address and any service to allow all
members with in the zones.
When the Palo Alto Networks firewall is operating in Layer 3 mode, it can provide routing and Network
Address Translation functions. The Layer 3 information is processed when the packet is initially
received by the firewall, before the deep inspection of the packet and its payload begins.
When the Palo Alto Networks firewall is operating in Layer 3 mode, it can provide routing and Network
Address Translation functions. All Layer 3 interfaces in a specific virtual router share the same routing
table.
1st set the type of Interface.

2nd set the security zone.
Mention that devices on the same virtual Router use the same Routing table.
By default, any management traffic sent to or from the firewall goes through the out of band
management interface (MGT). Alternatively, a Layer 3 interface can be used to source this traffic and
also receive inbound management traffic.
Management features enabled by the profile can be restricted to specific IP address with the Permitted
IP Addresses panel. If configured, only the IP addresses listed can use the services selected when
defining the profile. If the field is left blank, the profile allows any IP address to used the configured
services.
A standard traffic interface can be configured to handle management traffic normally sent to the MGT
interface. The MGT interface uses a separate Layer 3 forwarding table than the virtual routers used by
the traffic interfaces.
A traffic forwarding Layer 3 interface can be used to source the management traffic. This interface can
be selected based on the management protocol or on the destination of the management traffic. In
most cases, the interface will also need to be assigned an appropriate Interface Management Profile in
order to accept the management traffic.
The firewall can be configured to be a DHCP server, as well as a DHCP relay.
The DHCP Server setting configures a Layer 3 interface to assign IP addresses from a user-
defined pool to DHCP clients. If an interface on the firewall is a client of an external DHCP server,
information from that configuration can be provided as part of the DHCP information provided to your
local users. DHCP Server currently supports IPv4.
The DHCP Server has three modes: Enabled, Disabled, and auto. Auto mode will disable the feature if
another DHCP Server is detected on the network.
The DHCP Relay setting forwards DHCP requests to up to four external DHCP servers. Client
requests can be forwarded to all servers,
rvers, with the first server response sent back to the client.
DHCP Relay supports IPv4 and IPv6.
The DHCP assignment also works across an IPse

IPsec VPN, allowing clients to receive an IP
address assignment from a DHCP server on the remote end of an IPsec tunnel.
Virtual routers to enable the firewall to route packets at Layer 3 by making packet forwarding
decisions according to the destination IP address (IPv4 or IPv6). Each Layer 3 interface,
loopback interface, and VLAN interface defined on the firewall should be associated with a
virtual router. Each interface can belong to only one virtual router.
By default, the firewall comes pre configured with a virtual router named default which includes all the
interfaces.
You assign your Ethernet Interfaces to your virtual Router.
The Ethernet interfaces and VLAN interfaces defined on the firewall receive and forward the
Layer 3 traffic. The destination zone is derived from the outgoing interface based on the
forwarding criteria, and policy rules are consulted to identify
dentify the security policies to be applied.
In addition to routing to other network devices, virtual routers can route to other virtual routers
within the same firewall if a next hop is specified to point to another
her virtual router.
Virtual routers provide support for static routing and dynamic routing using the Routing
Information Protocol (RIP), Open Shortest Path First (OSPF) protocol, and Border Gateway
Protocol (BGP).
Route-based VPN solution: You can configure route-based VPNs to connect Palo Alto
Networks firewalls at central and remote sites or to connect Palo Alto Networks firewalls with
third party security devices at other locations. With route-based ed VPNs, the firewall makes a
routing decision based on the destinationion IP address. If traffic is routed to a specific destination
through a VPN tunnel, then it is encrypted as VPN traffic.
affic. It is not necessary to define special
rules or to make explicit reference to a VPN tunnel; routing and encryption decisions are
determined only by the destination IP address.
The multicast routing feature allows

llows the firewall to route multicast streams using Protocol
Independent Multicast Sparse Mode ode (PIM-SM) and PIM Source Specific Multicast (PIM-SSM)
for applications such as media broadcasting (radio and video) with PIMv2. The firewall
performs Internet Group Management Protocol (IGMP) queries fo for hosts that are on the same
network as the interface on which IGMP is configured. PIM-SM and IGMP can be enabled on
Layer 3 interfaces. IGMP v1, v2, and v3 arare supported. PIM and IGMP must be enabled on
host-facing interfaces.
Standards based support for OSPF: With PAN-

PAN-OS 6.0 both OSPF v2 and OSPF v3 are
supported.
Normally, when traffic enters the firewall, the ingress interface virtual router dictates the route
that determines the outgoing interface and destination security zone based on destination IP
address. With policy-based forwarding (PBF), you can specify other information to determine
the outgoing interface, including source and destination IP addresses, source zone, source
user, destination application, and destination service.
The initial session on a given destination IP address and port that is associated with an
application will not match an application-specific
ation-specific rule and will be forwarded according to
subsequent PBF rules that do not specify an application ion or the forwarding table of the virtual
router. All subsequent sessions on that destination
tination IP address and port for the same
application will match an application-specific
specific rule. To ensure forw
forwarding through PBF rules,
application-specific rules are not recommended.
You can use Network Address Translation (NAT) policies to specify whether source or
destination IP addresses and ports are converted between public and private addresses and
ports.
When configuring NAT on the firewall, it is important to note that a security policy must also be
configured to allow the NAT traffic. Security policy will be matched
hed based on the post-NAT zone
and the pre-NAT IP address.
The firewall supports the following types of source address translation:
• Dynamic IP/Port—Multiple clients can use the same public IP address with different
source port numbers. Dynamic IP/Port NAT rules allow translation to a single IP
address, a range of IP addresses, a subnet, or a combination of these. In cases
where an egress interface has a dynamically assigned IP address, it can be helpful to
specify the interface itself as the translated address. By specifying
pecifying the interface in the
dynamic IP/port rule, NAT policy will update e automatically to use any address
acquired by the interface for subsequent translations.
• Dynamic IP—Private source addresses translate to the next available address in the
specified address range. Dynamic IP NAT policies allow you to specify a single IP
address, a range of IP addresses, a subnet, or a combination of these as the translation
address pool. By default, if the source address pool is larger tthan the translated
address pool, new IP addresses seeking translation will be blocked while the
translated address pool is fully utilized. This behavior can be changed by clicking the
Advanced (Dynamic IP/Port Failback) button to specify Dynamic IP/Port
configurations to be used if the pool is exhausted.
• Static IP—You
—You can use static IP to change the ssource IP address while leaving the
source port unchanged. A typical use case fo for this NAT type is an internal server
which must be available to the internet.
The firewall supports Static IP for destination address translation. Static IP allows you to
change the destination IP address and, optionally, the port. When used to map a single public
IP address to multiple private servers and services,
es, destination ports can stay the same or be
directed to different destination ports.
Port forwarding is a technique used to manage traffic through NAT policies based on
destination port numbers. For example, assume a company exists which has three separate
servers for email, web hosting, and an application server which
ich exist in a zone named Server-
Trust. All systems in Server-Trust are configured with a NAT policy to appear as if they have
the same IP address. When traffic is received at the shared address, the port forwarding
feature of the inbound NAT policy can send the traffic to the appr
appropriate server based on the
destination port associated with the session.
The key to understanding how to configure NAT rules is learning the flow logic of how NAT Is processed
in the firewall. Knowing when the NAT rules are evaluated versus applied makes the configuration more
logical.
NAT rules must be configured to use the zones associated with pre NAT IP addresses configured in the
policy. For example, if you are translating traffic that is incoming to an internal server (which is reached
via a public IP by Internet users), it is necessary to configure the NAT policy using the zone in which the
public IP address resides. In this case, the source and destination zones would be the same. As another
example, when translating outgoing host traffic to a public IP address, it is necessary to configure NAT
policy with a source zone corresponding to the private IP addresses of those hosts. The pre NAT zone is
required because this match occurs before the packet has been modified by NAT.
Security policy differs from NAT policy in that post NAT zones must be used to control traffic. NAT may
influence the source or destination IP addresses and can potentially modify the outgoing interface and
zone. When creating security policies with specific IP addresses, it is important to note that pre NAT IP
addresses will be used in the policy match. Traffic subject to NAT must be explicitly permitted by the
security policy when that traffic goes from one zone to another.
As with any other policy in the firewall, NAT policies are based on the source and destination zones of
the traffic being processed. Additionally, NAT policies can be configured to apply only for specific
services or IP addresses for more fine grained control.
Two NAT types are supported on Palo Alto Networks firewalls: IPv4 and NAT64. IPv4 NAT allows an IPv4
address to be translated to another IPv4 address. NAT64 is used to translate source and
destination IP headers between IPv6 and IPv4 addresses. s. It allows IPv6 clients to access IPv4
servers and allows IPv4 clients to access IPv6 servers. NAT64 is not supported on virtual wire
interfaces.
NAT policies allow the administrator to translate the source address, destination address, or both
depending on the needs of the implementation. We will discuss these configurations in the following
slides.
Source addresses can be translated to either an IP address or address range in either a
dynamic or static address pool. The size of the address range is limited by the type of address
pool:
• Dynamic IP And Port—The next available address in the address range is used,
and the source port number is changed. Up to 64K concurrent sessions are
translated to the same public IP address, each with a different
ent port number (1025-
65535). Up to 254 consecutive IP addresses
sses are supported. Port numbers are
managed internally.
• Dynamic IP—The next available address in the configuredigured pool is used, but the port
number is unchanged. Up to 32K IP addresses are supported in the pool.
• Static IP—The
—The same address is always used, and the port is unchanged. For
example, if the source range
ange is 192.168.0.1-192.168.0.10 and the tr translation range is
10.0.0.1-10.0.0.10, addressss 192.168.0.2 is always translated to 10.0.0.2. The
address range is virtually unlimited.
If Translation Type is set to None, no translation is done. This option, sometimes referred to
as a “No-NAT” policy, is reserved for cases wher
where an exception is required. For example, this
might be used if NAT translation will be used to obscure the source IP address except when a
specific address within a protected address range is detected.
In our example, a host with the IP address 192.168.15.47 exists on an private network. The
user at this address wants to connect to a server on the internet. To prevent the exposure of
the private IP address, the firewall administrator has configured
onfigured a NAT policy so that all traffic
from the private network appears to come the address on the ethernet1/4 interface.
Enter an IP address or range of IP addresses and a translated port number (1 to 65535) that
the destination address and port number are translated to. If the Translated Port field is blank,
the destination port is not changed. Destination translation is typically
cally used to allow an internal
server, such as an email server, to be accessed from the public network.
The Translated Address field can be completed with eitherher an IP address or an Address
object. Address objects are named objects configured on the firewall
wall to make it easier for
administrators to complete configurations with a pre-defined
e-defined address. Address objects can be
configured through the GUI at Objects > Addresses.
In this scenario, a user at an external system with the IP address 65.124.57.5 queries the DNS
server at 4.2.2.2 for the IP address of the webserver, www.xyz.com. The DNS server returns
an address of 172.16.15.1 – the external address of the firewall interface in the Untrust-L3
zone. In order to reach the webserver, the destination IP address
ss will have to be to the private
IP 192.168.15.47.
Remember: To cross zones you will need a Security Policy. Also remember that the Security
Policy is performed after the NAT policy.
NAT rules must be configured to use the zones associated with pre NAT IP addresses configured in the
policy. For example, if you are translating traffic that is incoming to an internal server (which is reached
via a public IP by Internet users), it is necessary to configure the NAT policy using the zone in which the
public IP address resides. In this case, the source and destination zones would be the same. As another
example, when translating outgoing host traffic to a public IP address, it is necessary to configure NAT
policy with a source zone corresponding to the private IP addresses of those hosts. The pre NAT zone is
required because this match occurs before the packet has been modified by NAT.
Security policy differs from NAT policy in that post NAT zones must be used to control traffic. NAT may
influence the source or destination IP addresses and can potentially modify the outgoing interface and
zone. When creating security policies with specific IP addresses, it is important to note that pre NAT IP
addresses will be used in the policy match. Traffic subject to NAT must be explicitly permitted by the
security policy when that traffic traverses multiple zones.
Organizations who are beginning to investigate or migrate to an IPv6 infrastructure can deploy Palo
Alto Networks next generation firewalls in virtual wire, layer 2, or layer 3 mode and then apply many of
the same firewall features to that traffic that can be applied to IPv4 traffic. IPv6 based applications and
content can be classified, controlled, inspected, monitored and logged with full visibility.
SLAAC Stateless Address Auto Configuration

LDAP Lightweight Directory Access Protocol
RADIUS Remote Authentication Dial in User Service
PAN OS supports IPv6 for some, but not all of the firewall functionality. The table above describes the
current IPv6 compatibility.
IPv6 neighbor discovery can be dynamically configured by Duplicate Address Detection (DAD) or
statically assigned in the Advanced tab.
Layer 3 interfaces, including the MGT interface, can be configured as dual stack with both IPv4 and IPv6
addresses. IPv6 can be used for all Management Interface services. However, connections to the Palo
Alto Networks update server and the BrightCloud server require IPv4 connections.
Regarding Dual Stack support Although the movement to IPv6 is primarily in the public address
space, many of our customers are moving toward a dual stack approach on their internal networks as
well. The move to dual stack means that OSPFv2 and OSPFv3 need to be run simultaneously to provide
full networking connectivity to both "stacks." Complex and dynamic networks require dynamic routing
protocols to simplify management of the network infrastructure. With PAN OS 6.0 we now support
OSPFv3 offering Dual Stack capabilities. This added function extends our OSPF support to include
dynamic routing for internal networks using OSPFv3.
The Business Case for OSPFv3:
The increasing prevalence of IPv6 and the exhaustion of the IPv4 address space.
Many customers are already moving toward a dual stack approach on their internal networks as
well. The move to dual stack means that OSPFv2 and OSPFv3 need to be run simultaneously to provide
full networking connectivity to both "stacks.
Limitations
OSPFv3 will not be supported on Dynamic Interfaces like DHCP and PPPOE.
ECMP is not supported
No "clear command
Currently cannot clear ospf or clear neighbors as operational command.
Only one instance ID can be configured per OSPFv3 interface
Though on the link there can be multiple instance IDs
OSPFv3 will not support fast hellos.
The hello interval is between 1 and 3600 seconds.
OSPFv3 Addressing Both Link LSA and Intra Area Prefix LSA were introduced to carry such
addressing information.
Protocol Processing per link not per subnet Additional Information

• OSPF for IPv6 runs per link instead of the IPv4 behavior of per IP subnet.
• An OSPF interface now connects to a link instead of an IP subnet.
• This changes the receiving of OSPF protocol packets, the contents of Hello packets, and the
contents of network LSAs
NOTE: Possibly Add the Decrypt Port Mirroring License installation and device reboot to the beginning
of this lab so that users will be able to see Decrypt Port Mirror
as an available option from within their Configuration UI of their firewall.
PAN EDU 201 Palo Alto Networks. Confidential and Proprietary. Mod5 page 1
Once the initial packet processing is complete, the Palo Alto Networks firewall examines the traffic to
accurately apply the security policies. Though the device can classify traffic by port like a traditional
firewall, the next generation firewall is designed to examine the application associated with traffic to
provide more granular control over data on your network.
Accurate traffic classification is the heart of any firewall, with the result becoming the basis of the
security policy. Traditional firewalls classify traffic by port and protocol, which, at one point, was a
satisfactory mechanism for securing the perimeter. Today, applications can easily bypass a port based
firewall by hopping ports, using SSL and SSH, sneaking across port 80, or using non standard ports. App
ID is the Palo Alto Networks traffic classification mechanism that addresses the traffic classification
limitations that plague traditional firewalls.
App ID uses multiple identification mechanisms to determine the exact identity of applications
traversing the network. We will discuss these methods in the following slides.
The term application does not have an industry accepted definition in the way that session or
packet do. Applications can be delivered through a web browser, a client server model, or a
decentralized peer to peer design. In Palo Alto Network terms, an application is a specific program or
feature that can be detected, monitored and blocked if necessary.
Applications will include business tools and services, which will need to be allowed, as well as
entertainment or personal services, which may need to be blocked.
App ID uses multiple identification mechanisms to determine the exact identity of applications
traversing the network. The identification mechanisms are applied in the following manner:
1. Traffic is first classified based on the IP address and port.
2. Signatures are then applied to the allowed traffic to identify the application based on unique
application properties and related transaction characteristics.
3. If App ID determines that encryption (SSL or SSH) is in use and a decryption policy is in
place, the application is decrypted and application signatures are applied again on the
decrypted flow.
4. Decoders for known protocols are then used to apply additional context based signatures to
detect other applications that may be tunneling inside of the protocol (e.g., Yahoo! Instant
Messenger used across HTTP). For applications that are particularly evasive and cannot be
identified through advanced signature and protocol analysis, heuristics or behavioral
analysis may be used to determine the identity of the application.
Once the application is identified, the policy check determines how to treat the application: block, allow
and scan for threats/file transfers/data patters, or rate limit them using QoS
One category of applications that are difficult to track and control are those applications that change
port as needed. These applications are known as evasive applications. In a traditional firewall, Yahoo
Messenger is defined as any TCP traffic destined for port 5050. In reality, Yahoo Messenger can
automatically try other common ports, including port 80, if port 5050 is blocked.
Other applications can be configured by the user to be evasive by using a non standard port. The
BitTorrent client traditionally uses a port of 6681 or greater. It is a simple procedure to force BitTorrent
to use a common port like 80 instead.
There are a number of application proxies out there that will take well behaved, fixed port applications
and tunnel them through any port the user wants. The net result is that the destination port of any
given connection has no bearing on the service or application that is generating the traffic.
Traditional firewalls use port blocking to control traffic. To allow a service such as DNS, the firewall is
configured to allow port 53 traffic.
On a Palo Alto Networks firewall, a rule is created to allow the DNS service rather than a specific port.
In this example, the end result is the same: DNS traffic is allowed. However, this will not protect the
network from other services using the same port.
An application intrusion protection system (IPS) can be added to a traditional firewall environment to
provide a second layer of traffic filtering. Once the traffic is processed by the firewall, it is passed to the
application IPS for further analysis. In our example, BitTorrent traffic sent on port 53 will traverse the
firewall because it is using an allowed port, but will be blocked by the application IPS.
The Palo Alto Networks solution is still to allow only DNS. Any traffic not specifically allowed will be
denied. The end result is the same as if we were to block the BitTorrent application explicitly. The port
number does not matter since we are checking for the application directly.
As in the previous example, the end result is the same for both solutions: BitTorrent traffic is blocked.
In the previous two examples, we were dealing with a well behaved, known threat. The situation
changes if the threat is unknown, like a zero day virus.
In the application blade example, the zero day virus using port 53 is allowed through the firewall
because it is using an allowed port. However, since the application blade does not know about this new
threat, the malware is not blocked and is passed onto the network. This is an inherent problem with
application block policies you cannot block what you do not know. Not only does the 0 day malware
get through, but there are no logs generated that identify this problem.
The Palo Alto Networks firewall is configured to allow only DNS traffic. Even if the zero day malware is
unknown to PAN OS, it is not allowed to pass since it does not match the allowed DNS service.
Additionally, traffic that fails due to policy is logged for later analysis.
In some discussions, App ID is compared to URL filtering. Although both can be implemented in PAN
OS, the two features are used to achieve different goals.
App ID exists to identify applications traversing the network. The App ID engine reads the application
signature to uniquely identify the application, regardless of the port or address information associated
with the traffic. This type of precision could be used to allow a network user to access the general
functionality of the Facebook web site (facebook base) but deny the ability to chat with other Facebook
users (facebook chat). App ID can be applied to all types of network traffic handled by a Palo Alto
Networks firewall.
URL Filtering is a feature of the Content ID engine. URL filtering processes traffic solely based on the
URL associated with the traffic. Nothing else in the packet is evaluated during this check. URL filtering
will simply deny access to the specified website through HTTP and HTTPS.
App ID and Content ID are separate engines in the Single Pass Architecture. URL filtering will be
discussed in more detail later in the course.
The Palo Alto Networks solution utilizes four major technologies to identify applications: protocol
decoders, application signatures, protocol decryption, and heuristics. We will discuss each of these
topics in the following slides.
These software constructs understand the application at the protocol level and provide contexts for the
application. For example, the HTTP decoder understands that there will be a Method and a Version for
each HTTP request. The decoders are what assist in detecting when a second protocol is tunneled
within an existing session. This is called Protocol in Protocol.
Palo Alto Networks maintains a database of known application signatures for use in the App ID engine.
Updates to the database are issued weekly.
You can view the application signatures in three ways:

• In the GUI under Objects > Applications
• On the web at http://apps.paloaltonetworks.com/applipedia/
• On an Apple iOS device with the Applipedia app
Each signature covers multiple versions of an application.
The firewall can be configured to decrypt Secure Socket Layer (SSL) and Secure Shell (SSH) traffic going to
external sites. With the SSH option, you can selectively decrypt outbound and inbound SSH traffic to assure
that secure protocols are not being used to tunnel disallowed applications and content. You can also apply
decryption profiles to your policies to block and control various aspects of SSL traffic.
Assume a scenario where a user will be connecting via an encrypted connection to Facebook. The company
policy is to allow employees to read Facebook, but prevent facebook chat and facebook posting. This can
easily be accomplished with the Palo Alto Networks firewall if SSL decryption is enabled for the facebook
application. If SSL decryption is not enabled, then the firewall cannot tell what application is inside the SSL
connection, let alone that application shifts are occurring within the connection.
Decryption will be discussed in more detail later in this course.
When traffic is unable to be identified by the application decoders and signatures, the Heuristics engine
is used. This engine looks at patterns of communication and attempts to identify the application based
on its network behavior.
This type of detection is required for applications that use proprietary end to end encryption, such as
Skype and encrypted BitTorrent.
When the PAN firewall examines UDP packets, it often only has to examine a single UDP packet to
determine what the application is. In most cases, all the information the firewall needs is contained in a
single packet. The above example shows a single packet DNS query for www.google.com. This packet
contains all source and destination addressing information. It also includes the application data that will
be used to identify the traffic so it can be processed by security policy.
Applications that use TCP will usually not have all the required information in any single packet. The
above example is of a HTTP connection to www.meebo.com. The first packet is a TCP SYN packet. While
it does contain all the source and destination addresses, it contains no application data. In fact, the
following two packets will also not contain any application data. They will just complete the three way
handshake. The actual application data will be either in the HTTP Get request or in the server reply.
When a session is initiated, the source and destination zones and addresses are determined and the
policy rule base is checked. A rule base exists for each zone pair. Rules can be created with multiple
zones as source and destination. This is commonly used to define access to a DMZ resource that is used
in a similar fashion by clients in both internal and external zones.
If there is a rule that matches the addresses and could match the application, the session is allowed and
the system begins to examine the traffic to determine the application in use. For this reason, it can be
beneficial to configure specific or default ports for the applications being allowed. If the service is
defined as any, all sessions must be allowed to proceed until the point where application layer data is
exchanged, and then the firewall can determine what application is inside the session. If the service is
anything but any, then many unwanted connections can be dropped immediately. If the traffic and
resulting application does not match any rule, the session will be dropped.
The policies are one way, meaning that they only allow traffic initiated in the direction the policy
specifies. The replies to the client are always allowed as part of the policy. However, if traffic is intended
to be initiated in both directions then two policies will be required. For example, a policy from the Trust
zone to the Untrust zone for web browsing would allow user web requests to go out and the http
replies to return, but it would not allow an internet host to browse web pages on a users computer.
Security policy consists of objects that describe the endpoints of the communication and the traffic to
be matched. Rules can be as specific as required. They are built using objects that hold values of
addresses, applications, users and services.
The configured action, deny or allow, is only taken if a session matches all defined fields of the security
policy. If a match is not made, the session will be compared against the next policy in the list. Once a
match is found, no further policies will be checked.
Address objects are named objects configured on the firewall to make it easier for administrators to
complete configurations with a pre defined address. The Address object can be configured through the
GUI at Objects > Addresses. Multiple address objects can be specified within a policy.
Note: Within PAN OS 6.0 Dynamic Address was replaced by Dynamic Address Groups and so the
selection of Dynamic is no long an available Type option. Youll alto notice the addition of the
Tags field and options via the drop down menu. This will be discussed in further detail later within
the Dynamic Address Groups section.
The FQDN address object is used to handle situations where an IP address might change or there are
multiple IP address for a FQDN. This address object will auto refresh based on the DNS TTL intervals. If
the DNS served IP address changes, the security policy will use the new address without any
administrator changes to the firewall.
Dynamic address group membership is determined through the use of tags. Logical and /or operators
are used to define filtering criteria. Tags can be registered dynamically to the firewall through the XML
API or VM Monitoring Agent on the firewall, or defined statically through PAN OS. Any entity that
matches the defined tags becomes a member of a given dynamic address group.
Dynamic address groups are a way to dynamically populate address groups with IP addresses through
the XML API for use in security policies and other types of policies. Admins are able to specify IP
addresses inside policies dynamically via tags and tag based filters. They are part of the Palo Alto
Networks virtualization solution and are intended for use with VMware ESXi integration. They replace
dynamic address objects in PAN OS 6.0. (Dynamic Address Objects upgraded from PAN OS 5.0.x to
6.0.x will be automatically migrated into a dynamic address group with the configured identifier being
translated into a tag.)
The VM environment is monitored via the vSphere API. The rate of change in a virtual environment
does not match traditional security policy change cycles. A zone based architecture may be sufficient to
keep a consistent policy. However, dynamic address groups that track IP addresses allow policy to
follow VM changes in cases where zones are insufficient. Changes are published to PAN OS via the
RESTful XML API, adjusting policies accordingly. At least 60 seconds will pass between an API call and
an IP address being registered by the firewall. Address Object Refresh (i.e. AddrObjRefresh) jobs run
every 60 seconds on the firewall. This job will wait until the following minute has passed if an Address
Object Refresh job has just occurred and PAN OS receives a new XML API update. These changes do
not require a manual commit job and are persistent when the firewall is rebooted.
These capacities are accurate for PAN OS 6.0. Each platform supports a certain number of dynamically
registered IP addresses.
Navigate to Objects > Address Groups > Add. Set the Type to Dynamic. Add Match Criteria from the
list of available tags. They can be combined with the logical operators and and or to create different
combinations of tag match criteria that must be met in order for an entity to be associated with the
dynamic address group.
Add the dynamic address group as match criteria in a policy. A commit job must be performed to push
the candidate configuration into memory as the running configuration. Dynamic address group
members can be changed dynamically at this point. Entities can be associated with IP addresses, and IP
addresses can be associated with tags through the XML API or the VM Monitoring Agent. It is not
necessary to perform successive commit jobs for such changes because they become part of the
running configuration.
An admin can view the IP addresses that have been registered dynamically to the address group by
clicking the name of the group, moving the cursor over Inspect, and then clicking the More link.
An admin can also view registered IP addresses under Objects > Address Groups.
In addition to the Address objects, Dynamic Block Lists can be used to dynamically maintain address
based policies using block lists from companies or agencies which maintain such lists. For example,
several groups on the internet maintain blacklists of known spam sites for email filtering.
The list is updated on a administrator defined schedule. The updated information is immediately
available for use in the policy, without a commit.
The URL Category match criteria is used in three different policy types: Security, QoS, and Captive
Portal. This field will match URLs against predefined categories provided by the dynamic updates. In
addition to the categories provided by Palo Alto Networks, you can create custom URL Categories. This
feature requires the URL filtering license except for custom categories. If the license expires, only
custom categories will be used by the policy.
Policy lookup occurs each time the URL Category for the session changes. Traffic logs will show entries
for each URL category transition. Lookups are cached for faster retrieval. The engine will check the data
plane cache, then the management plane cache before querying the external URL lookup servers. If the
category is not resolved before the webserver responds, the security policy will look for a match on a
not resolved category.
URL Category matching uses the same Block page as the URL Filtering profile and does not have either
the Continue or Override option.
If more granular URL filtering is required, a URL Filtering profile should be used instead. The URL
Filtering profile can match specific URLs (e.g., www.facebook.com), while the URL Category only
matches broad categories (e.g., social networking
networking). We will discuss URL Filtering profiles in more detail
in the Content ID module.
Many applications rely on other applications to be running before they can be used. In a Palo Alto
Networks firewall environment, you must make sure that an applications parent applications are
allowed in order for your target application to function correctly.
For example, a user wants use Google Translate. Applications accessed through a web browser will first
be recognized as an HTTP session. The administrator will have to enable the web browsing application
in addition to allowing the google translate base application.
Application dependencies can be found by accessing App ID in the GUI. Click Objects > Applications to
see application information. The App ID listings are also available through Applipedia.
There are multiple methods to re number your rules. Each method will automatically re order your
rules for you. Each method will be covered over the next consecutive slides.
Because youre filtering certain rules the Rule Number Order Column will only display the rules and
their respective rule numbers that apply in order. Notice Rule numbers 1, 3, 5 & 6 as they have all
been filtered out.
Also notice we are looking at 2 of 6 Rules as reflected in the upper right corner 2/6.
Question What happens when we have a Panorama injected policy? The Rule Number column will
include the Panorama rules.
Can Drag & Drop your rule in the order of your preference. Please note the number are the order
number and are not used as an identifier as rule ID number. The purpose is to show the order of the
policies.
When a rule is moved or deleted the re number of the rules will occur automatically.
Notice that the Administrator moved the TEST Rule #4 up one and so now it becomes Rule #3.
Alternative way to move your rules is via the Move option > Select the new rule number rule for
ordering purposes.
Requiring that dependencies be allowed in order to enable an application can often allow more traffic
than intended. For example, enabling access to web browsing just to allow facebook base allows users
to browse other sites, requiring the administrator to configure other policies to regulate this access.
PAN OS addresses this concern by implicitly allowing dependencies for a set of commonly used
applications to streamline the security policy process. Implicit permissions of a parent application are
only handled if there is no match with an explicit rule.
The complete list of implicitly allowed applications can be found in Appendix B of this manual.
Security policies on a PAN OS firewall will match source, destination, application and service. The
application and service columns specify what applications can be identified on a defined set of ports, or
on all available ports. The service column allows administrator to select one of the following:
• Application default: The service application default option will set the security policy to
allow the application on the standard ports associated with the application.
• service http or service https: The pre defined services use TCP ports 80 and 8080 for HTTP,
and TCP port 443 for HTTPS. Use this security policy setting if you want to restrict web
browsing and HTTPS to these ports.
• Any: The predefined service Any matches any TCP/UDP port. This service is typically used to
deny applications.
• Custom service: Administrators can create their own definition of TCP/UDP port numbers to
restrict applications usage to specific ports.
Using the service application default is the recommended practice for configuring a security policy to
allow the applications.
For more information, refer to the Security Policy Guidelines document on the support website.
In order to limit services to their published default port values, policies can be configured with the
application default setting. With this setting configured, the policy will only match if the port number
associated with the session matches the port listed in the matched applications entry in the App ID
database. This feature is intended to limit port hopping and port spoofing.
In our example, user Joe wants to access the website http://translate.google.com across the firewall.
Joes computer is in the Trust L3 zone and the firewall interface connected to the public internet is in
the Untrust L3 zone.
When Joe opens a browser connection to the website, a session is started. The firewall scans the traffic
and finds the application signature for the http get process, which matches the web browsing
application in App ID. Based on the source and destination addresses, the firewall determines that the
traffic is flowing from Trust L3 (source) to Untrust L3 (destination) zones. These are the only parameter
needed to match the General Internet policy so the traffic is allowed. The GoogleTranslate rule is not
checked at this time since a match has already been found.
However, connecting to the website and actually using Google Translate are two different events. We
will evaluate that action in the next slide.
Security policies are constantly be examined, for every packet that traverses the firewall, for the life of
the session. The firewall can detect application shifts, or changes, within an established session.
After Joe connects to the website, he tries to access Google Translate, initiating an application shift in
the current session. The App ID engine detects the shift and finds the application signature for google
translate base. The session still exists between Trust L3 and Untrust L3.
Using these three conditions (Application, Source Zone, Destination Zone), the first rule is checked.
There is no match since google translate base does not match the applications listed in the rule so the
firewall moves on to the next rule. The second rule matches on all conditions and google translate base
is allowed to run.
Does the order of the two rules matter in this example?
In this example, the order is not relevant. Traffic which matches one rule cannot match the other rule so
neither rule prevents the other from being evaluated.
Each security policy can include specification of one or more security profiles, which provide additional
protection and control. The profile associated with a security policy is only evaluated on a policy match
where the configured action is allow.
In additional to individual profiles, you can create profile groups to combine profiles that are often
applied together.
The following profile types are available for security policies:
• Antivirus: Protects against worms and viruses , blocks spyware downloads
• Anti spyware: Blocks attempts by spyware to access the network.
• Vulnerability: Stops attempts to exploit system flaws or gain unauthorized access to systems
• URL filtering: Restrict access to specific web sites and web site categories
• File blocking: Blocks selected file types
• Data filtering: Prevents sensitive information such as credit card or social security numbers
from leaving the area protected by the firewall
Security Profiles will be discussed in more detail in the Content ID module.
The PAN OS GUI displays a large amount of information about the policies configured on the firewall. To
limit the amount of information displayed, you can customize the columns shown. Hover the cursor
over any column name to expose the pull down.
Individual policies can be managed using the toolbar at the bottom of the Policy pages. Locally defined
policies can be created, deleted, cloned, enabled, and disabled. Policies pushed to the firewall by
Panorama must be edited from the Panorama server.
The Highlight Unused Rules option allows you to see which rules have not matched any traffic since the
last reboot of the firewall. This is most often use to troubleshoot misconfigured policies.
Controls also exist to reorder the policies. Incorrect order can prevent policies behaving as designed. In
the example, an administrator wanted to allow web browsing for all systems except the server at IP
address 192.168.15.199. However, with the deny rule appearing after the more general allow rule, the
server would still be able to browse the web. Selecting the AllowWebBrowsing policy and clicking
Move Down will arrange the rules so that they will be evaluated in the correct order to deny the server.
Policies can also reordered by dragging the entry to a new position with the mouse.
You can now tag objects and add color to the tag in order to visually distinguish tagged objects.
Tags can be added to the following objects: Address Objects, Address Groups, Zones, Service
Groups, and Policy Rules.
While the firewall supports both static tags and dynamic tags, dynamic tags are added using
the XML API and scripts or by configuring the Support for the VM Series on the Citrix SDX
Server on the firewall.
Dynamic tags are not displayed along with the static tags, and they are not part of the device
configuration. The tags discussed in this section are statically added and are part of the device
configuration.
One or more tags can be applied to objects and to policy rules; a maximum of 64 tags can be
applied to an object. Panorama supports a maximum of 10,000 tags that can be apportioned
across Pan rama (shared and device groups) and the managed devices (including devices with
multiple virtual systems).
It is also visibly challenging to determine what objects are related to one another or were created by
one admin vs another. The solution is to tag rules and identify them using color coded tags
Best practice recommends grouping rules by using Tags. For legacy rule groups use one tag per rule and
use color coding by administrator or business unit.
Colors can be configured for tag settings.
Example: set tag test1 color color4
Panorama can push tag color configs. If conflicting with existing tag on firewall, then device config
should take priority
Likewise if conflict between shared and vsys specific object then vsys takes precedence
Objects which can be tagged include:
Addresses
Address Groups
Services
Service Group
Administrators can also apply color coding to Zones.
Notice you can select and choose your tags with color coding being applied. Tag name length limited
to 127 characters with 16 colors. Colors can be repeated with names. Items can have multiple tags can
use same color. With multiple tags with different colors, then first tag color will be displayed, so order
matters.
Your zones are color coded. Notice the background slide that lists each of your zones with its
corresponding color.
Security policies are based primarily on App ID. Since the App ID database is ever growing, PAN OS
allows for the dynamic grouping of App ID signatures through Application Filters. As new applications
are added to the App ID database and categorized, policies based on these filters automatically will
check for these new entries without any manual reconfiguration.
Application Groups are static, user defined sets of applications, application filters, and other application
groups. They allow the firewall administrator to create logical grouping of applications that can be
applied to policies. Application groups are not updated with App ID database changes.
Applications are automatically added to matching application filters when added to the App ID
database.
Application groups can be manually configured to include applications, application filters, and other
applications groups.
Firewall policies can be configured to match discovered application signatures against applications,
application filters, or application groups.
As applications are added to the App ID database during the weekly updates, they are classified by
category, subcategory, technology, risk, and characteristic.
To create an application filter, click Objects > Application Filters > Add. Name the filter and select the
filter criteria. The filter will create a list of all applications which meet your parameters, based on the
current App ID database. As new App IDs are added with predefined properties which match your filter
settings, they are automatically added to the matching filter and will be checked the next time the filter
is used by the security policy.
Filters do not need to be complex to work. Many times, the subcategory will be enough. Selections such
as gaming or proxy applications will be immediately useful in security policy.
If you need to group specific applications, application groups allow administrators to create custom lists
of applications for policies to check. Application groups can combine applications, application filters,
and application groups into a single entry which can be added to security policies. Application groups
are not automatically updated when new applications are added to App ID unless the group contains a
filter which contains the new signature.
In this example, the sets applications that the administrator wants to allow and deny do not fit into a
application filter search. This administrator finds it more convenient to manually list the applications.
However, any new applications added to App ID will not automatically populate these groups.
The administrator in this example was given a list of applications to allow and deny on the network.
However, the company acknowledges that they do not know all of the applications that users are using.
The administrator is to set up allow and deny policies and determine what other applications are in use
so they can be added to the allow or deny lists.
The first rule created allows the list of allowed applications to pass through the firewall. The second rule
denies the applications disallowed by company policy.
The last rule will match any traffic not caught by the first two rules. Whether it is set to allow or deny
the traffic, any traffic matched by this rule will be logged by the firewall. The administrator can then use
the logs to identify application in use on the network and add them to the appropriate application
group.
In previous versions of PAN OS, there was no easy way to understand which applications were included
in the groups, filters, or containers associated with a policy. You would have to the Objects tab to view
information about application groups, filters, or individual applications.
PAN OS now allows you to view the contents of these objects from the policy page. Clicking on the
name of the object allows you to see information about the object and the contained components.
Address objects, such as Internal Users in this example, can also be expanded in the policy window for
additional information.
By default, if a policy denies a web based application, the user will simply get generic browser based
error pages. In many cases, this results in additional support calls because users assume network
problems rather than a policy violation. Custom response pages can be created to notify users when
their action is blocked by firewall policy.
The default response page will include the prohibited application name, as well as the username (if
User ID is enabled).
Application block response pages do not require an interface management profile to be set.
All traffic crossing a Palo Alto Networks firewall will need to be allowed by security policy. The default
settings for a security policy is to create a traffic log entry at the end of a session. This allows the log to
include the total time of the session and the amount of data transferred. If there are any explicit deny
policies in the security rule set they will be logged here as well.
The log viewer can be set to refresh at a specified interval or it can be refreshed manually. The number
of entries displayed can also be adjusted.
The filter bar allows administrators to display only the lines in the log which match specified criteria.
Values can be entered by clicking portions of the log entries or manually through the Add Log Filter
interface. Frequently used filters can be saved and reused.
Traffic logs are generated when a security policy matches and allows or denies a session to connect. By
default, the policy logs these actions at the end of a session. This setting can be changed either in the
Actions tab when creating a new policy or by clicking the entry in the Options column of the policy
entry.
The advantage to the Log at Session Start option is that state transitions are only logged at the
beginning of the session. The disadvantage of the option is that it will fill up the logs faster. Best practice
is to only enable logging at session start when troubleshooting sessions.
Group Activity Reports Overview
Activity Reports are no longer limited to a single user. Reporting capabilities allow admins to build
group activity summary reports . Use "run now" similar to create the user activity report. Detailed
browsing report will show activity of a specific user individually.
Disable Pre Defined reports are not in use by your organization. Allowing administrator to specify
which reports they wish to run.
PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 1
In order to provide the most robust network security model possible, the Palo Alto Networks firewall
allows granular control over network traffic. Beyond simply allowing or denying traffic based on
source, destination, and port information, the device can examine allowed traffic for specific threats.
including viruses and spyware. Additionally, traffic can be scanned for prohibited action, such as the
distribution of sensitive data.

Content ID combines a real time threat prevention engine with a comprehensive URL database and
elements of application identification to limit unauthorized data and file transfers, detect and block a
wide range of threats and control non work related web surfing.
Advantages of Content ID include:

• A stream based, not file based, architecture for real time performance
• The ability to block transfer of sensitive data and file transfers by type
• URL filtering capability enabled via a fully integrated URL Database
• The ability to detect zero day attacks with Wildfire
Note: The first arrow on the left side in the diagram refers to traffic that has been matched a security
policy with an action of allow that has one or more security profiles attached to it.
For additional reading about threat prevention in PAN OS, refer to the Threat Prevention Deployment
Tech Note available on the support website.

Security profiles are objects that are added to security policies with the allow action. Profiles are not
necessary for security policies with the deny action, since no further processing is needed if the packet
is to be dropped. As with policies, profiles are applied to all packets over the life of a session.
The profiles represent additional security checks to be performed on the allowed traffic. They look for
improper or malicious use of applications that are allowed in the environment. For example, web
browsing may be allowed, but you still worry that users could download a virus from a website. The
security policy would allow web browsing and an anti virus profile would be added in order to detect
and react to viruses.
Types of security profiles include:

• Antivirus: Detects infected files being transferred with the application.
• Anti Spyware: Detects spyware downloads and traffic from already installed spyware.
• Vulnerability Protection: Detects attempts to exploit known software vulnerabilities.
• URL Filtering: Classifies and controls web browsing based on content.
• File Blocking: Tracks and blocks file uploads and downloads based upon file type and
application.
• Data Filtering: Looks for specific patterns of data in the traffic.

The Anti Virus profile defines actions to be taken if an infected files is detected as part of an
application exchange. The listed applications represent the wide variety of vectors that modern
viruses can take in infecting a system. For each application type an action can be defined. The default
action is to block any detected virus unless the protocol is POP3, IMAP or SMTP, then the default
action is to alert. These three protocols are store and forward protocols: if an intermediate device
drops the packets, SNMP/POP3/IMAP are designed to continually resend until the data is ultimately
delivered. For these kinds of applications the infected file needs to be removed at either the server or
the client, not on the wire. When an antivirus profile is set to a block action for these decoders, an
SMTP 541 error message will be sent as part of the block action when a virus is detected. This will tell
the mail server not to retry sending the message, allowing the firewall to drop the mail without the
mail server trying to resend it.
The Actions column configures the action taken if the infected file is identified by the firewall anti
virus definitions file. The WildFire Action column defines the action taken if the infected file is
matched against the threat list maintained by the WildFire subscription feature, which is discussed
later in this module.
If you configure the action to alert, no traffic will be blocked. The only action taken will be to generate
an entry in the threat log. By selecting the Packet Capture check box, any alert will also be
accompanied by a packet capture of the portion of the file that triggered the virus signature. This can
be use to verify the presence of the virus and rule out false positives.

The administrator can configure anti virus profiles reduce false positive results or to ignore log
messages irrelevant to the particular network.
To create an exception, search the threat log for the threat ID that you wish to exclude. Add the threat
ID to the Virus Exception tab. In the example above, this profile will not alert or block the Eicar test
virus file.

A security policy can include specification of an anti spyware profile for phone home detection
(detection of traffic from installed spyware). The firewall includes two pre defined anti spyware
security profiles:
• Default: The profile applies the default action to all client and server critical, high, and
medium severity spyware events. This profile is typically used for proof of concept (POC) or
first phase deployments.
• Strict: The profile applies the block response to all client and server critical, high and
medium severity spyware events and uses the default action for low and informational
spyware events. Strict profiles are used for out of the box protection with recommended
block of critical, high, and medium threats.
The pre defined profiles cannot be modified or deleted.
Customized profiles can be used to minimize anti spyware inspection for traffic between trusted
security zones, and to maximize the inspection of traffic received from untrusted zones, such as the
Internet, as well as the traffic sent to highly sensitive destinations, such as server farms.

Each Anti Spyware security profile can contain multiple rules to handle different types of threats.
Each rule is configured with an action, a specific category of spyware to target, and severity levels.
Rules with different actions can be combined in the same profile.

The Exceptions tab allows you to change the response to a specific signature. For example, the profile
can be set to block all packets matching anti spyware signatures, but alert for user selected ones.
Exceptions are made for individual signatures and can be restricted to specific IP addresses. IP
addresses must be entered as unicast addresses. The IP Address Exception column only lists the
number of address entered. Click the number in the column to see the actual IP addresses. Addresses
specified will be checked against both the source and destination addresses.
Packet captures, if desired, must be requested on a per signature basis. The packet captures can be
set for both active and exempted signatures.

Detecting DNS queries for known malware domains is a very effective tool for detecting compromised
hosts. The DNS Signatures settings provides an additional method of identifying infected hosts on a
network. These signatures detect specific DNS lookups for host names that have been associated with
malware. The DNS signatures can be configured to alert (default), allow, block, or sinkhole when
these queries are observed, just as with regular antivirus signatures. Additionally, hosts that perform
DNS queries for malware domains will appear in the botnet report. DNS signatures are downloaded
as part of the antivirus updates. DNS based botnet signatures are included with the daily antivirus
updates, as part of the Threat Prevention subscription.
Note: DNS based botnet signature scanning only works if the DNS requests are visible to the firewall.

DNS Sinkhole allows administrators to quickly identify infected hosts on the network using DNS
traffic. Sinkhole DNS queries involve forging responses to select DNS queries so that clients on the
network connect to a specified host rather than the malicious system pointed to by DNS. The feature
takes effect for all DNS Signatures and adds an option to the anti spyware profile, allowing an
administrator to enable DNS sinkhole for DNS based spyware signatures. The admin selects the
sinkhole action and specifies the sinkhole IPv4 and IPv6 addresses. When the action is taken, the
firewall will forge a response and drop the query packet.
The infected hosts is easily identified in the traffic logs or using reports. Any hosts attempting to
connect to the sinkhole host is infected with malware. Use a Sinkhole IP address that to identify the
host (example: 6.6.6.0) . By default, Sinkhole address is set to the local loopback address. This
effectively prevent the infected host from communicating with the malicious system. Though the
loopback addresses prevents this communication at the host and the traffic will not reach the
firewall. Using a IP address will allow the traffic to be logged or available in reports.
The sinkhole action, just like the block action for DNS signatures, should be processed before DNS
proxy is processed. Thus, the query never goes through the proxy and sinkhole records are not
cached if DNS proxy caching is enabled.

Passive DNS (pDNS) data collection provides insight into issues like malware propagation, non
reputable IP space, and malicious domains. This data will improve existing threat prevention
capabilities in substantial ways when used in concert with WildFire data and other sources. For
example, newly discovered malware URLs can be added to the PAN DB malware category, to the DNS
based signatures, and to WildFire to assist in malware detection.
The pDNS collector in PAN OS allows customers to opt in and collect inter DNS server cache sync data
with the firewall, bundle the data, and sent it to Palo Alto Networks. The Data Plane forwards DNS
data to the Management Plane when the feature is enabled. The Management Plane reduces and
bundles DNS cache sync data locally until it reaches 1 MB or 10 minutes passes, whichever happens
first. The data is then sent to Palo Alto Networks.
PAN OS will only forward the DNS response when following requirements are met:
1. DNS response bit is set
2. DNS truncated bit is not set
3. DNS recursive bit is not set
4. DNS response code is 0 (NOERROR) or 3 (NX)
5. DNS question count bigger than 0
6. DNS answer resource records count is bigger than 0, or if it is 0 the flags need to be 3 (NX)
7. DNS query record type are A, NS, CNAME, AAAA, and MX

A security policy can include specification of a vulnerability protection profile that determines the
level of protection against buffer overflows, illegal code execution, and other attempts to exploit
system vulnerabilities. The firewall includes two pre defined vulnerability protection security profiles:
• Default: The profile applies the default action to all client and server critical, high, and
medium severity vulnerability protection events. This profile is typically used for proof of
concept (POC) or first phase deployments.
• Strict: The profile applies the block response to all client and server critical, high and
medium severity vulnerability protection events and uses the default action for low and
informational vulnerability protection events. Strict profiles are used for out of the box
protection with recommended block of critical, high, and medium threats.
The pre defined profiles cannot be modified or deleted.

Customized profiles can be used to focus vulnerability checking for specific threats and types of
traffic. Available actions for traffic which match a vulnerability protection profile are:
• Allow: Threats are allowed to pass with no further actions.
• Alert: Threats are allowed to pass and are logged in the threat log.
• Block: Threats are blocked by the firewall and logged in the treat log.
Note: CVE stands for Common Vulnerabilities and Exposure, a system maintained by the MITRE
corporation, which catalogs publicly known information security threats.

The Exceptions tab allows you to change the response to a specific signature. For example, the profile
can be set to block all packets matching vulnerability signatures, but alert for user selected ones.
Exceptions are made for individual signatures and can be restricted to specific IP addresses. IP
addresses must be entered as unicast addresses. The IP Address Exception column only lists the
number of address entered. Click the number in the column to see the actual IP addresses. Addresses
specified will be checked against both the source and destination addresses.
Packet captures, if desired, must be requested on a per signature basis for exceptions.

The threat log records each security alarm generated by the firewall. Each entry includes the date and
time, the threat type, such as a virus or spyware/vulnerability filtering violation, the source and
destination zones, addresses, and ports, the application name, and the action and severity.
Threat log entries can be logged remotely by severity level by defining log forwarding profiles, and
then assigning the profiles to security rules. Threats are logged remotely only for the traffic that
matches the security rules where the logging profile is assigned.
Threat logs are used in generating reports and in the Application Command Center.

Often, the need for exceptions to the vulnerability and anti spyware profiles are not known until a
user complains that they have lost functionality. The situation is further complicated by the fact that
multiple profiles may need to have the same exception defined.
Check the box next to the profiles that should have an exemption for this threat and, optionally,
specify the IP address exemptions in the adjacent panel.
Note: The Threat Details interface is exclusively for adding functionality. The values shown do not
reflect the current state of the listed profile exemption lists. You must check the individual profiles to
verify whether or not an exemption already exists.

A security policy can include specification of a URL filtering profile that blocks access to specific web
sites and web site categories, or generates an alert when the specified web sites are accessed (a URL
filtering license is required). You can also define a block list of web sites that are always blocked (or
generate alerts) and an allow list of web sites that are always allowed.
Pre defined sets of web categories can be downloaded from Palo Alto Networks. PAN OS supports
two different URL filtering databases: PAN DB (default) and BrightCloud. These URL filtering
technologies will be discussed later in the module.
Administrators can also define custom URL categories to customize the behavior of the URL filtering
profiles.

The URL Filtering feature can be used by placing categories directly in policies or attaching a URL
Filtering profile to a security rule. URL filtering only affects HTTP and HTTPS traffic.
The URL Category field can be used as a match condition for security, QoS, decryption, and Captive
Portal policies. Both pre defined and custom categories can be matched when using the URL category
field. The URL category itself does not have an associated action traffic behavior is controlled by the
policy.
The URL Filtering security profile provides granular control for traffic allowed by a security policy. As
with other profiles, the URL filtering profile is only applied if the associated policy allows traffic. The
profile can match URL categories, as well as individual URLs. Each category can be assigned a different
action for more focused management. For example, a security policy could be created to allow all
web browsing but have a policy which blocks all access to file sharing websites and logs all access to
social networks.

Each URL Filtering profile can be configured with an explicit Block List and Allow List, which take
precedence over URL categories. You must omit the http[s]:// portion of the URLs when populating
these lists. Entries in the Block List and Allow List are case insensitive and must match exactly. For
example, www.ebay.com is different from ebay.com.
The Block List, Allow List, and custom categories support wildcard patterns. A token is a string of
characters that begins or ends with a valid separator character (. / ? & = ; +). For example, the
following patterns are valid:
*.yahoo.com (Tokens are: "*", "yahoo" and "com")
www.*.com (Tokens are: "www", "*" and "com")
www.yahoo.com/search=* (Tokens are: "www", "yahoo", "com", "search", "*")
It is recommended to enter the firewall administrators domain in the Allow List to avoid possible
miscategorization.
For additional reading on this topic, refer to the document URL Categorization Components and
Process on the support web site.

The custom URL category feature allows you to create your own lists of URLs that can be selected in
any URL filtering profile. Each custom category can be controlled independently and will have an
action associated with it in each URL filtering profile (allow, block, continue, override, or alert).
URL entries can be added individually, or you can import a list of URLs. To do so, create a text file that
contains the URLs to include, with one URL per line. Each URL can be in the format www.example.com
and can contain an asterisk (e.g. *) as a wildcard, such as *.example.com. You can also create this text
file using the Export option, and then import the list to other firewalls.

Actions can be set for both the Block list and the URL categories. The available actions are:
• Allow Allow the user to access the website, no log or user message is generated
• Block Traffic is blocked, a Block log entry is generated, and a Response page is sent to the
users browser
• Alert Allow the user to access the web site but add an alert to the URL log
• Continue Send a response page requiring the user to click Continue to proceed, log the
action
• Override Send a response page and allow the user to access the blocked page after
entering a password, log the action
If a user successfully Continues or Overrides, they will have access to the Category associated with
the URL that generated the event for 15 minutes without having to Continue or Override again. This
timeout time is configurable.
The override password is set in Device > Setup >Content ID > URL Admin Override. There can only be
one URL Admin Override password per firewall.

Block pages are displayed when a user attempts to access a URL or URL category with a configured
action of block, continue, or override. Block pages are HTML pages, limited to 16KB in size. The HTML
code for the default response pages shown on this slide can be found in the appendix of
Administrators Guide. Each page can include references to the users IP address, the URL for which
access is attempted, and the URL category. The User field is populated with source user only if User
ID is enabled on the firewall.
URL Filtering response pages require the configuration of a Layer 3 interface on the firewall with an
interface management profile which allows the interface to handle response pages.
Refer to the Customizing Block Pages whitepaper on the Palo Alto Networks support website for
detailed instructions on creating customized block pages.

If you have any actions set to Override, you must specify the settings that are used when a page is
blocked by the URL filtering profile and the Override action is specified. The override action requires
the user enter a password, rather than simply clicking a button like the continue action does. There
can be only one URL Admin Override password per firewall.
The Mode setting determines whether the block page is delivered transparently (it appears to
originate from the blocked website) or by a redirect from the specified server. If you choose Redirect,
enter the IP address for redirection. The IP address must correspond to a Layer 3 interface on the
firewall with an interface management profile assigned with the Response Pages option enabled.
You can customize the behavior of the URL Admin password. The URL Admin Override Timeout sets
the lifetime of the override before the user must re enter the admin override password for URLs in
the same category. The URL Admin Lockout Timeout sets the waiting period that a user must wait
three unsuccessful override attempts.

The URL Filtering feature performed its lookup based strictly via the hostname/FQDN of a website in
previous versions of PAN OS. Sites accessed through translation services such as Google Translate
and Bing Translator would fall under the Translation category as the URL would be masked/embedded
within the translation URL. As a result, users found that strict filtering profiles could be bypassed
using these translation services, resulting in a potential security hole to access restricted content.
This feature introduces a secondary lookup for translated sites, which is recursive and only initiated if
it is determined that a secondary lookup is necessary. URL filtering logs will now be populated twice,
once for each lookup: translated site and embedded URL.
Filtering translated websites is built in to the URL Filtering engine for both PAN DB and BrightCloud. It
does not require any additional configuration to enable it. However, this feature is dependent on the
URL Filtering content update that is installed. Older versions will continue to function as it did prior to
an upgrade to PAN OS 6.0, allowing users to bypass restricted content by using a translation service.
Since each translation engine may change its parameters, or new, unsupported translation sites may
arise, enhancements will be periodically introduced via dynamic content updates.

Performing a search via Yahoo or Google for the restricted site, and then opening the site contained
within the search result via the cached option was another way users would access restricted
websites. This enhanced filtering functionality has been extended to caching sites such as
archive.org, archive it.org, and Google cache in an attempt to cover all bases. We have added a
feature in PAN OS 6.0 that will now automatically look up the category of the original website, even
when it is embedded or appended to the URL of the caching site being used. Block, Continue, and
Override response pages will now be displayed as initially intended, regardless of how the site is
accessed when URL Filtering profiles are applied to a security policy. This applies to both PAN DAB
and BrightCloud.
As was the case with Translation filtering, Cache filtering is enabled by default; no additional license is
required. Updates will be provided through URL Filtering dynamic content updates. Cache filtering
uses a secondary, recursive lookup, with each individual look up following the same URL
categorization flow. As such, multiple entries are also populated within the URL Filtering logs.

This features requires that the strict safe search options be enabled in the Google, Yahoo, and Bing
search engines. Safe search is a best effort setting in these web browsers that is used to prevent
sexually explicit content from being listed in search results. Each search provider determines what is
considered explicit, not Palo Alto Networks. The setting is disabled by default. A URL Filtering license
is not required to use this feature. Users will see a URL Filtering Block Page if this is enabled in PAN
OS but safe search is not enabled in their web browsers. This ability is updated through the
Applications and Threats signature updates from Palo Alto Networks. Updates will be provided if the
search providers make changes to their safe search feature. A best practice is to enable this feature
and add a security policy that prevents users from using another search provider other than Google,
Yahoo, or Bing.
There is a specific response page for use with this feature. The URL Filtering Safe Search Block Page
is found at Device > Response Pages.

To reduce the amount of information logged, the profile can be configured with the Log container
page only option. Container pages specify the types of URLs that the firewall will track or log based
on content type, such as text/html, text/xml, text/plain, application (pdf), and image (jpeg).
Adding a new container page overrides the default list of content types. The system provided default
container page is read only and cannot be edited. Only one custom container page can exist at a time.

The URL Filtering Log contains log entries for URLs that have action alert, continue, override, and
block. The action taken by the URL Filtering profiles will be listed in the Action column. Actions
requiring user interaction will log both the initial blocking action and the successful user interaction.
For example, if a user is presented with a Continue response page and then clicks the Continue
button, both block continue and continue entries will be recorded.

Beginning with PAN OS 5.0, Palo Alto Networks firewalls support two URL filtering services: PAN DB
(default as of PAN OS 6.0) and BrightCloud. BrightCloud lookups are available on previous versions of
PAN OS.
The two lookup services are licensed separately and only one can be active on a firewall at a time.
Mixed environments are not supported by HA pairs.

Firewalls using PAN DB cache URL lookups to expedite future lookups.
The management plane cache is initially created from a seed DB file downloaded from the cloud
server. The size of this cache depends on the firewall model and ranges from ~300K 3.5M URLs. The
cache is backed up on disk every eight hours and when a reboot is requested by the administrator.
Entries expire based on timeouts included for each URL in the database. These timeouts are not
configurable.
Like the management plane cache, the data plane cache expires entries based on values set in the
database for each URL. The size of the data plane ranges from 100K 250K URLs, based on the firewall
model.
If a URL is not found in the caches, the firewall will contact the cloud servers for the lookup. PAN DB
does not require a nightly download of a URL filtering file all updates are downloaded dynamically
from the cloud as needed.

When a URL lookup is performed on a BrightCloud enabled firewall, the URL is cached to expedite
future lookups. The URL caches are checked before the database file and the external servers (if
configured). During lookups, the data plane cache is checked first, then the management plane cache.
The data plane cache, being shorter, will have a faster lookup.
The management plane cache stores the last one million URL queries to the cloud in memory. This
cache is persistent and written to disk every 20 minutes to prevent data loss from a power failure. By
default, cached entries expire after 24 hours.
The data plane cache is also a memory resident structure. This subset of the management plane
cache does not age out its entries, but maintains the most recent cloud entries. The number of
entries kept by this cache varies by firewall model but ranges from 5,000 to 100,000 entries.
If the entry is not found in either cache, the local URL filtering file is checked. This file is updated daily
and can be scheduled for download and install from the Device > Dynamic Updates screen.

Dynamic URL Filtering is enabled by default and is not configurable if the firewall is using PAN DB.
For firewalls using BrightCloud, if Dynamic URL filtering is enabled and a URL is detected that is not
categorized by the local URL database, the firewall can request the category from a hosted 180
million URL database on the BrightCloud servers.
URL filtering is a licensed service. Firewalls using BrightCloud can be configured with these actions if
the URL Filtering license expires:
Block: Block access to all web sites in the Block List or in categories with the block action
Allow: Allow access to all web sites
No updates or dynamic filtering actions will occur with an expired license. License expiration does not
affect the user defined custom URL categories.
If the URL filtering license expires on a firewall using PAN DB, the URL filtering policies continue to
function, but lookups will be limited to the local caches. Connection to the cloud is revoked, so no
further lookups or updates will occur until a valid license is applied.

If using BrightCloud, if a URL is detected that is not categorized by the local URL database, the firewall
can request the category from a hosted 180 million URL database. The URL is then cached locally in a
separate 1 million URL capacity database. The Dynamic URL Cache Timeout value refers to the
number of hours a URL will be held in the Management Plane cache. This setting only applies to
BrightCloud server lookups. Cloud based lookup timeouts for PAN DB are defined as part of the URL
entry in the database and are not configurable.
The URL Continue Timeout setting determines how long a user can browse to a URL associated with
a continue action. For example, if user browses to a URL that in associated with a category where the
Action is configured as Continue, the user can browse to URLs in that same category for 15 minutes
before being presented with another Continue page.
When the x forwarded for option is selected, the firewall examines the HTTP headers for the X
Forwarded For header, which a proxy can use to store the original user's source IP address. The
system takes the value and places Src: x.x.x.x into the Source User field of the URL logs, where x.x.x.x
is the IP address that is read from the header. If the Strip x forwarded for option is selected, the
firewall zeros out the header value before forwarding the request and the forwarded packets do not
contain internal source IP information.

Palo Alto Networks provides daily updates of the top 20 million URLs according to BrightCloud. A valid
URL Filtering license is required to download these files to your firewall. If the license expires, the
existing database will function as described on the previous page, but the device will not be able to
download any further updates.
PAN DB does not require a nightly download of a URL filtering file. All PAN DB updates are
downloaded dynamically from the cloud as needed.

Sometimes URLs are miscategorized by the database providers, causing users to be unable to access
sites that should be allowed. Requests for recategorization can be submitted through the Request
Categorization Change link in the details window of a log entry. The link redirects your browser to a
change request form which is submitted to the database vendor.

File Blocking profiles control the flow of a wide range of file types by looking deep within the payload
to identify the file type (as opposed to looking only at the file extension) to determine if the transfer
of the file is allowed by policy. File blocking by type can be implemented on a per application basis.
For example, an organization can use file blocking to enable the use of specific webmail application
like Gmail and allow attachments, but block the transfer of specific file types.
The available actions for File Blocking profiles are:

• Block Traffic is blocked, a Block log entry is generated, and a Response page is sent to the
users browser if the traffic is web based
• Alert Allow the user to access the file but add an alert to the URL log
• Continue Send a response page requiring the user to click Continue to proceed, log the
action
• Forward Send the file to the WildFire cloud for analysis, log the action
• Continue and Forward Send a response page requiring the user to click Continue to
proceed and log the action. If the user continues, forward the file to the WildFire cloud and
log the action.

Drive by downloads have become the preferred method for hackers to deliver malware to
unsuspecting users. Instead of a user clicking on an attachment in an email, users can become infected
via a drive by download simply by visiting a webpage with an infected image. Often the user and even
the owner of the website may be unaware that the site has been compromised. The File Blocking
Profile looks within the application session, sees that a download is taking place, and verifies with the
user if the file is an approved download.

Modern malware has evolved from being simple replicating viruses to highly evasive and adaptable
network applications that allow hackers to launch increasingly sophisticated and targeted attacks.
This new breed of malware is at the heart of many of todays most sophisticated intrusions. As
malware has become more powerful, it has also become more targeted and customized for a
particular network, thus helping it to avoid traditional signature based anti malware solutions. This
shift means that the malware that represents the greatest risk to the enterprise is also the most
difficult to detect.
WildFire provides the ability to identify malicious behaviors in executable files by running them in a
virtual environment and observing their behaviors. This enables Palo Alto Networks to identify
malware quickly and accurately, even if the particular sample of malware has never been seen in the
wild before.
WildFire makes use of a your on premises firewalls in conjunction with Palo Alto Networks cloud
based analysis engine to deliver an ideal blend of protection and performance. The inline firewall
captures unknown files and performs inline enforcement while maintaining high network throughput
and low latency. The analysis of unknown files is offloaded to a secure cloud based engine to identify
unknown malware and subsequently deliver protections to all locations.

When the Palo Alto Networks firewall encounters a file, the file can be submitted to the hosted
WildFire virtualized sandbox. Supported file types include: Win32 Portable Executable (PE) files (.exe,
.dll, .scr), Microsoft Office files (.doc, .xls, .ppt, .rtf), Portable Document Format (PDF), Java Applet
(.jar, class), and Android Application Package (.apk). When choosing file types in the objects profile,
you can choose PE to cover all Win32 PE file types. Support for file types other than PE require a
WildFire license.
Submissions can be made manually or automatically based on policy. The sandbox provides virtual
targets for the suspected malware where Palo Alto Networks can directly observe more than 100
malicious behaviors that can reveal the presence of malware. If a sample is identified as malware,
the sample is then passed on to the signature generator, which automatically writes a signature for
the sample and tests it for accuracy. Signatures are then delivered to all Palo Alto Networks
customers as part of the daily malware signature updates.
In addition to providing protection from modern malware, users can see a wealth of information
about the detected malware in reports available on the WildFire Portal. The detailed reports provide
the ability to see all behaviors of the malware, the user that was targeted, the application that
delivered the malware, and all URLs involved in delivery or phone home of the malware.
The WF 500 appliance is available to customer who want the benefits of WildFire but do not want to
upload files to the cloud. It must be purchased separately. It provides the same malware analysis
functions, but it does not support analysis of Android Application Package (.apk) files in PAN OS 6.0.

The WildFire subscription service extends the feature set to accelerate administration. Newly
discovered malware signatures are available hourly. Subscriber firewalls can download the files
manually (default) or on an automated schedule. WildFire subscription updates are maintained
separately from the standard anti virus definitions and so have a separate match condition in the
antivirus profile configuration. Non subscribers still benefit from the signatures discovered by
WildFire since the discovered signatures are included in the daily antivirus updates.
Another benefit of the subscription service concerns logging. Standard WildFire users must log into
the WildFire server directly to view information about the files submitted by their firewall to the
WildFire server. Subscribers receive log information directly from WildFire in a log on their local
firewall.
A WildFire subscription also provides you with access to the WildFire API. This tool allows you to
create custom scripts to automatically submit suspicious files to the WildFire cloud for analysis. Using
the API, users can upload up to 100 samples per day and query for reports by file hash 1000 times per
day.

On the firewall, configure WildFire settings on the Device > Setup page.
By default the WildFire Server setting is configured with the value wildfire public cloud to allow the
firewall to automatically find the closest WildFire server. The cloud based service is hosted in the
North America, Europe, and Asia for redundancy and performance.
The maximum file size can be set in the range 1 10 MB (default is 2 MB). Files larger than the
specified size will not be sent to the WildFire server.
The Session Information Settings specify which information will be sent to the WildFire server. All are
selected by default.

Results of the detailed analysis of the submitted files are available through the WildFire portal. To
access the WildFire portal, go to https://wildfire.paloaltonetworks.com and log in using your Palo Alto
Networks support credentials or your WildFire account. You can use the WildFire portal to see which
users were targeted, the applications that were used, and the malicious behavior that was observed.
You can also configure the WildFire portal to send email notifications when results are available for
review.
The portal opens to display the dashboard, which lists summary report information for all of the
firewalls associated with the specific WildFire account or support account (as well as any files that
have been uploaded manually). The display includes the number of analyzed files and indicates how
many are infected with malware, are benign, or are pending analysis.

Click the Reports button at the top of the WildFire portal to view the list of available reports. Search
options are available at the top of the page, and pagination controls are included. To view an
individual report, click the icon to the left of the report name. To print a detailed report, use the print
option on your browser.

The detailed reports provide administrators with a extensive list of behavior exhibited by the files
submitted to the WildFire server. Information about registry changes, processes and files added to
the sandbox, and a summary of the behavior of the file are provided to allow administrators to take
appropriate action.
Additional information about known malware can be found by clicking the VirusTotal Information link
which connects the user to www.virustotal.com, a Palo Alto Networks partner.

WildFire report information is also available within the WildFire Submission Log in PAN OS. The
admin can view this information in the firewall in addition to the WildFire Portal. It provides the same
data as well as the

WildFire reports indicate whether a file was benign or malware. An admin can re submit a file if this
determination is believed to be incorrect. There is a link at the bottom of the report in the portal and
the WildFire Analysis Report in PAN OS.

In addition to the automatic file forwarding performed by the firewall, administrators can submit
suspicious files directly to the WildFire servers for analysis. To upload a file manually, click Upload File
in the upper right corner of the WildFire page. You can either directly upload the file to the WildFire
server or specify a URL for the file.

Though not as detailed as the WildFire logs, the data filtering log allows administrators to monitor
firewall interactions with WildFire. The log maintains records of communications with the WildFire
servers in order to show patterns of use. Administrators can see the file names and types which are
generating the file blocking events.
WildFire specific actions visible in the log are:

• wildfire upload success: the file was actually sent to the cloud; this means the file is not
signed by a trusted file signer and it has not yet been seen by WildFire.
• wildfire upload skip: the file was not uploaded because it was seen by WildFire before, and
it was determined to be malware. This will generate a WildFire report.

WildFire log forwarding settings are separate from Threat Log settings in PAN OS 6.0. An admin can
determine if log data about benign or malicious files will be forwarded to Panorama, sent as a SNMP
trap, provided as an email, or sent to a syslog server.

Security profiles are enabled on individual security policies. A security policy can be assigned profiles
appropriate for the type of traffic expected in that policy. Profiles are only used when traffic matches
a policy with the action of Allow.
Profiles can be assigned individually or as a security profile group. Groups are recommended for sets
of profiles which are commonly assigned together.

The firewall supports the ability to create security profile groups, which specify sets of security
profiles that can be treated as a unit and then added to security policies. For example, you can create
a security profile group that includes profiles for antivirus, anti spyware, and vulnerability and then
create a security policy that includes the custom profile.
Antivirus, anti spyware, vulnerability protection, URL filtering, and file blocking profiles that are often
assigned together can be combined into profile groups to simplify the creation of security policies.

Assume a situation where a client (sending the TCP SYN) initiates a session with a server (sending the
TCP SYN ACK). The Disable Server Response Inspection (DSRI) option disables packet inspection from
the server to the client. This option may be useful under heavy server load conditions.
For example, DSRI can be used in situations where an external system is accessing an internal
(trusted) server. Since the internal server is trusted, an administrator can opt not to inspect packets
sent from the server to the client to reduce processing load on the firewall.
DSRI is not recommended for communications with external or untrusted servers whose content is
unknown. Additionally, DSRI could result in traffic from an compromised internal server (e.g., a
system infected by a botnet) not being detected.

PAN OS includes additional protection features that are not linked to policy. Zone protection profiles
are set on specific zones and address issues with Layer 3 and Layer 4 protocol based attacks. Multiple
zone protection profiles can be created on the PAN device, but a zone can only have a single profile
applied to it. All traffic received on any interface in that zone will be examined based on the
protection profile when the zone is the session destination zone.
All flood protections are configured to protect SYN flood, UDP flood and ICMP flood. The value set in
the alert, activate and maximum fields is the packets per second from one or many hosts to one or
many destinations in the zone. Packets to destination zone are sampled at an interval of one second,
to determine if the rate matches the threshold.
Refer to the Understanding Zone Protection Profile whitepaper on the Palo Alto Networks support site
for more detailed information.

Reconnaissance protection is used to prevent/alert administrators on reconnaissance attempts like
ports scans, ICMP sweep. Unlike the flood settings, threshold settings are applicable to hosts in the
zone where reconnaissance protection is configured.
Packet based attacks use malformed traffic to adversely affect target systems. PAN OS provides the
ability to block these anomalous traffic types when detected.

Zone Protection profiles are enabled on a per zone basis. Each zone can have exactly one Zone
Protection Profile assigned to it. Zone Protection only applies when the zone is used as the
destination zone of a session.


Palo Alto Firewall Notes

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Palo Alto Firewall Notes

Transféré par

Droits d'auteur :

Formats disponibles

PAN--EDU

Palo Alto Networks, Inc.

Convention Meaning Example

The exam questions are concentrated in the following categories:

Administration & Management

PAN EDU 201 Palo Alto Networks. Confidential and Proprietary. 10

For further explanation, refer to the document

• Networking and management functionality: at the foundation of all traffic processing

The default username of admin has a default password of admin

PAN EDU 201 Palo Alto Networks. Confidential and Proprietary. 28

PAN EDU 201 Palo Alto Networks. Confidential and Proprietary. 29

An XML API usage guide is available on the DevCenter online community at

• Config lockBlocks other administrators from making changes to the configuration.

Updates are issued on the following schedule:

Interface types are slightly different for the PA 7000 series.

Tunnel interfaces will be discussed in the VPN module of this course.

• Go to the Support Site to request the license.

PASeries Platforms Supported:

1st set the type of Interface.

The DHCP assignment also works across an IPse

You assign your Ethernet Interfaces to your virtual Router.

The multicast routing feature allows

Standards based support for OSPF: With PAN-

SLAAC  Stateless Address Auto Configuration

Protocol Processing per link not per subnet  Additional Information

You can view the application signatures in three ways:

Each signature covers multiple versions of an application.

Decryption will be discussed in more detail later in this course.

Does the order of the two rules matter in this example?

Security Profiles will be discussed in more detail in the Content ID module.

Administrators can also apply color coding to Zones.

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 3

Advantages of Content ID include:

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 4

Types of security profiles include:

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 5

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 6

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 7

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 8

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 9

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 10

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 11

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 12

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 13

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 14

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 15

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 16

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 17

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 18

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 19

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 20

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 21

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 22

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 23

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 24

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 25

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 26

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 27

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 28

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 29

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 30

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 31

PAN-EDU-201 Palo Alto Networks. Confidential and Proprietary. Mod 6-page 32

• Config lockBlocks other administrators from making changes to the configuration.

PASeries Platforms Supported:

SLAAC Stateless Address Auto Configuration

Protocol Processing per link not per subnet Additional Information