Palo Alto Next Generation Firewall

JUN 2012
The PA200 has been announced as a welcome addition to cover small branch offices - maintained by Panorama and well
featured just like the bigger rack mounted models.
Feb 2012
A new partly free, with optional enhanced feature pay service called "Wildfire" traps malware. Device -> Setup -> WildFire.
A new model for branch offices is available called PA-200. You can manage it via panorama.
***
Latest version resolves issues with routed (Jan 2012)
***
Version 4.1 will support multicast and IPv6
***
Palo Alto Firewall new version is in Beta now. This addresses IPv6. ​Read more about IPv6 in my article here.
The latest 3.x version is 3.1.9
3.1.6 has an issue.
3.1.5 is stable in the field.
Version 4.0.3 Is now available.
> 4.0.2 is invulnerable to TCP Split handshake attack
18 Mar 2011: You can see some new GUI features by going here.
If you want two factor authentication, see here:
http://www.nordicedge.se/palo-alto
http://www.youtube.com/watch?v=NKYv0kSdU1E
14 April 2011: A few upgrade quirks from 3.x line to 4.0.1 so consider waiting for 4.0.2 before upgrade. And upgrade because
you need the features not just because it is 'there'.
Palo Alto 4050

Pin It
Something new has recently happened in the firewall-market. This is the ​Next Generation Firewall.
Version 4.x now includes "Global Protect". This puts a perimeter around not only your physical infrastructure, but also your
mobile devices. A small application on your mobile device finds the nearest firewall to obtain policy. Finally, your mobile devices
are AS IF THEY WERE INSIDE HQ.
For years we have had individual units to provide Intrusion prevention (IPS) anti-virus (AV), anti-spam, Uniform Resource
Locator (URL) blocking and general networking policy control. Following this has been a list of successful Universal Threat
Management machines. The UTM seeks to combine all the internet security tools into a single unit. But these UTM devices
often suffer from performance issues when all features are turned on.
Over the last few years, a new problem has sneakily crept up. This is the problem of application independence from any
particular port. The Next generation firewall solves both the performance issue, and addresses the application independence
problem.
What is a port?
A port is nothing more than a number which is used to identify a connection in a server. There are thousands of ports, but the
first port numbers 0 through 1023 are so called 'well known' ports. A famous one is port 80.
Over port 80, flows most internet world-wide-web traffic. Nothing but convention entices any particular application to use a
particular port. Therein lies the problem.
Today, hundreds of applications can use port 80 - or other ports of choice. Since most firewalls let port 80 through, many
applications have a clear path through the firewall.
A typical example could be a bit-torrent application or a chat application. Although these might be nominally assigned a
dedicated port, both applications could break the rules a little and tunnel through port 80.
So what can be done about this?
The Palo Alto firewall is not a UTM. ​Gartner calls a device of this design a 'Next Generation Firewall'. Although it operates as a
single-unit IPS, Anti-Spam, URL filtering multi-function device, it has two main differences.
The first is that all these features can be turned on at the same time time without affecting performance. It achieves this by
using enough processing power and multi-threaded, multi-core CPUs to simultaneously perform all operations on the data
stream as it passes through the firewall. Traditional UTM machines perform, say, a URL check, then pass it to an AV engine and
so on. Traditional UTM machines suffer performance losses when the features are progressively turned on.
But the second and most significant difference is that the Palo Alto firewall primarily filters traffic based on an application
signature rather than a port number. To this end, port 80 as HTTP web traffic is irrelevant. The Palo Alto can be asked to look
inside web traffic that could be running on any port and find chat clients or file transfers or bit-torrent, or voice applications.
The port numbers are not required.
Now it should be clear that this is a massive advantage today because traditional firewalls cannot separate, say Farmville from a
web page which gives information about the stock market. Farmville is an application which is often spawned from Facebook,
and Facebook is an application that is port - 80 web based.
Finally, your policy can generally allow web-browsing, allow parts of Facebook, and disallow Farmville - for certain users in
various ways.
Details of the Palo Alto Firewall.
In the following sections, you will find finer details on how the Palo Alto firewall works. This is not a training manual, nor an
operations manual. It is not a benchmark or a product review. The intention is to expose the features and unique characteristics
of the unit.
NOTE: This review is based on PAN OS version 3.x
PAN OS 3.8 has recently been announced and has more features.
Policy-based Routing is defined by source zone and interface, source and destination addresses, source user and/group, service,
and application. Each of the rules can be associated with a health-check and disabled if the route fails.
Architecture.
The Palo Alto firewall contains two separate computers. One computer is for management, and the other deals with network
data. The two computers communicate using an internal bus.
This architecture is maintained across all of the product range. The advantage of this is how the machine can accept
management commands and run reports independently of the network load.
The computer which deals with network data is a single CPU (but multi-core) for the low-end PA-500. The CPU is fast enough
for the stated machine throughput in this case.
Higher-throughput machines have three separate specialist CPU types.
The first is a hardware accelerated network processor. This is linked to multiple multi-core CPU(s) that performs hardware
accelerated Secure Socket Layer (SSL) and Internet Protocol Security (IPSec ).
The third is a flash-matching engine.
Flash matching engine.
The flash matching engine is a hardware-implementation of a specialized regular expression parser - purpose-built for finding
signatures in the data stream. This engine contains an algorithm which has a deterministic known-run-time for each query.
While not the fastest engine ever possible, it has the massive advantage of being predictable. This latter point means that there
are no chaotic processing events where run-time could randomly blow out to unreasonable times.
The search-time for data is cut down by careful categorization. For example, if it is given the task to find a virus which is known
only to affect ICQ chat, then that search task is excluded for all other types of traffic. Only ICQ-chat vulnerabilities are explored
for ICQ application traffic.
This context-aware pattern matching makes the flash engine efficient.
Stream processing
When designing a filtering device, you have the option to pull in the whole data conversation, then scan it and send it on its
way, or scan and forward as a stream of data. The Palo Alto firewall is a stream processor. This choice means that the each
piece of data arrives and leaves as quickly as possible, and it also means there is no limit for the incoming data-size. In contrast,
the former method demands that the entire data stream is collected, held in memory, processed, then sent on its way. The
former method typically has file-size limits and cannot scan very large files.
It is important to note that the stream approach might appear to be slow: If you were to monitor a particular data stream
coming from the unit, it will leave slightly delayed but mostly at the same rate as the data as it was offered to the firewall.
Comparing this to a unit which pulls in the entire file as quickly as possible, scans, then sends it out again as quickly as possible,
the single-stream throughput seems faster.
But in the real world, multiple streams arrive for processing, and the Palo Alto copes much better in this case. Pretend you have
one hundred 500MB files all arriving mixed up at one interface. The stream processor separates this task into one hundred
independent threads and processes them in parallel. The non-streaming firewall has to somehow allocate finite memory
resources for all these files.
Security Zones and interfaces.
Why would people who - for some reason - have a business-need for Facebook be all on the same subnet? Of course the
answer is "no particular reason". So it makes no sense to restrict security levels to particular ranges of Internet Protocol (IP)
addresses.
The Palo Alto uses 'security zones'.
The security zone is a logical construct. There is no requirement for it to live only attached to one particular interface.
● Multiple logical interfaces can be in the same security zone.
● A single physical interface has only one zone.
● A physical interface can be a 'layer 3' interface which allows IP forwarding.
● A zone can be a L3 zone , and if so only contains L3 interfaces.
● Two physical interfaces can be linked as a 'virtual wire' and inserted into the network without IP addresses and 'look' at
data passing by without routing it. These virtual wires can be part of a virtual-wire zone.
 ● You cannot mix virtual-wire zones or interfaces with L3 zones or interfaces.
● A third kind of interface is the 'tap'. A tap just watches data and collects information. Unlike virtual-wire or L3 interfaces,
a tap cannot control the traffic.
● You can do NAT and routing providing you use L3 interfaces.
● All L3 interfaces in a virtual router share a routing table.
● Every L3 interface has an IP address.
● An interface which forwards traffic NEEDS an IP address, a ZONE, and a virtual router.
● A virtual router is an instance which is populated by data from Static or Dynamic routing information.
● Dynamic routing comes from Routing Information Protocol (RIP) or Open Shortest Path First (OSPF).
● A Dynamic Host Control Protocol (DHCP) server or relay can be assigned to an interface.
● You can create static Address Resolution Protocol (ARP) entries.
● Any L3 interface can participate as a management interface.
● All traffic that flows between zones require a policy rule.
How is the policy evaluated?
As with many firewalls - the policy is evaluated top-down and when a match is found, then the search terminates. A match
considers:
● source,
● destination,
● zones,
● other criteria (even actual ports if absolutely required),
Compared to typical firewalls, there is an important difference in how the Palo Alto evaluates policy. You are likely to have, say,
a web browsing rule where any of the streams of data ​within the HTTP protocol ​could spawn a new application. Let's assume
that user logs on to Google, then in a new tab, browses to Facebook, and starts Farmville.
The rule-base would be searched top-down to find that HTTP is allowed, and the Google page is loaded. Then the user browses
to Facebook, and an application signature for Facebook gets triggered. The policy is searched again to see if Facebook is
allowed. Note, that if web browsing is not allowed, then Facebook will not be allowed since it starts from a web-browsing
session.
Now that Facebook is displayed, the user clicks on Farmville, and the policy is searched once again. We can assume for this
example that Farmville is denied. A log entry will record this deny-status for Farmville.
When Facebook was started, a byte-counter also started. When the user closes Facebook, a log entry is made which records
how much data was used by the Facebook activity. Then the user closes the browser, and the logs record how much data was
used by the Google page.
All of the above is independent of the ports used for the associated applications but you do have the option to specify ports for
well-behaved applications. Typically specific ports are used for in-house and legacy applications.
Policy objects.
The firewall operates on abstract objects so that an end-point can be an object defined as:
● A host with a 32 bit subnet mask
● A network
● A named object
● A member of a group
● A user
● A service or group of services
● Applications
Rules can be very general, and very specific. More specific rules precede general rules.
Network Address Translation (NAT)
A separate policy list deals with NAT. This is independent of the traffic policy. The traffic policy always refers to the actual IP
addresses of the devices.
NAT types available include:
● Destination address translation - to allow external users to use servers inside that use a private IP address.
● Source address translation - typically used to allow users with a private IP address to access the public internet.
The NAT policy looks similar to a security policy so that the following columns are available as rule-matching criteria.
● Source zone
● Destination zone
● Source address
● Destination address
● Service
Based on these criteria, you can then translate:
 ● Destination address.
● Source address.
When traffic is logged, it may have been subject to a NAT rule. The log files contain a single line for each session that is a
summary. More information about the traffic can be found by clicking on a 'details' icon (a magnifying glass). More information
like NAT can be found in the 'details' log view.
Applications and the ACC
Google search, Gmail, Gtalk, Google Calendar, Lotus Notes, Yahoo Messenger and so on are all applications. Some may use port
80, some might not, and some might hunt for an available port.
The Application Control Center (ACC) displays data for the last hour about applications, threats, URL and data filtering events.
The ACC is a portal into the firewall logs.
The ACC reports total traffic for each type of application - where Facebook is seen as a distinct application even though it might
be spawned from a web browsing session. The web browsing statistic will not contain the Facebook count, but it does contain
all access to web pages that are not identified as a specific application.
How are applications identified?
There are four technologies involved:
1. Protocol decoder
2. Protocol decryption
3. Application signature
4. Heuristics
Protocol decoder
HTTP 'looks like' HTTP because of the particular commands used in the HTTP protocol. For example, there is a command which
is literally 'GET'. However, it's possible to have a protocol inside a protocol. The protocol decoders assist in identifying these
tunneled protocols.
Protocol decryption
You don't want viruses to slip by in an encrypted Secure Socket Layer (SSL) stream, so the Palo Alto firewall allows a
man-in-the-middle interception for SSL traffic. In this case, the administrator allows the firewall to legitimately act like a client
to allow it to decrypt the stream and scan the contents.
Application signature
When a particular pattern is recognized as unique to a particular application, this is an application signature.
This is [partly a community-driven database and as such, a customer can make requests about a possibly ​new signature or
application​.
Heuristic​s
Sometimes there is no specific signature for a certain kind of data stream, and in this case, a heuristic is a best-guess based on
non-specific patterns and/or behavior. For example, a stream of data which looks like it contains the type of stuff that
resembles an executable application, then it may be identified as say, a Windows .EXE file.
The mode shift.
A mode shift happens when the user clicks on something that changes the nature of the session in play. An example is a
mode-shift from a static web page to a video stream or a live chat.
How does traffic get processed through the firewall?
Lets assume a packet arrives at the firewall. It is checked to see if it is part of an existing session. Let's assume that it is a new
session. This is the flow and processing of the packet:
● Check source, destination routing and associated zones. Using this information, check the NAT policy table.
● Based on a traditional port-based policy decision, the ingress packet is checked to see if it ​could match any of the allowed
services. If so, then an application session is created. It's possible for the administrator to set up an application override.
If that is the case, then the particular application is excluded from further checking and it bypasses the detailed
application ID process.
● Otherwise, the next few live packets of this session are checked for application signatures (or heuristic information).
● Early on, if SSL is recognized, then the stream might have to be decrypted.
● At any time in the stream, a new signature or heuristic pattern could be recognized.
● Once an application is positively identified, then the policy is implemented. When a match is found the stream of data is
handled by the single-pass parallel processing engine.
● On egress, the stream could be re-encrypted and where applicable, NAT is applied.
● The packet is forwarded according to the routing table.
How is UDP processed?
The User Datagram Protocol (UDP) contains simpler and typically smaller packets. Application detection is often achieved from
examination of a single packet.
How is TCP processed?
The Transmission Control Protocol (TCP) uses more packets to establish and define the parameters required for transmission.
While UDP often contains application data in a single packet together with address information, the application data for TCP is
likely to arrive in several packets after the initial session control. This is why the Palo Alto needs to pull in a few packets before
making a positive identification of an application.
How do I manage so many applications?
The Palo Alto firewall has a Graphical User Interface available through a standard web browser. One of the GUI screens
provides the following search-able organizational categories:
● Category - (like business, networking...)
● Sub category - (like email, gaming...)
● Technology - (like browser or peer-to-peer)
● Characteristic - (like 'evasive' or 'tunnels other applications')
● Risk level.
The risk level is a finger-in-the air enumeration which loosely categorizes how risky is the application. These risk levels are
customizable, but there is little point in trying to do so since a new set of application signatures could upset your particular
impression of risk, and trying to single-handedly manage all the risk levels raises some serious administrative overhead.
You can search applications by name, select by groups, manage the content of groups, and create a filter which dynamically
generates a group.
Specific applications, statically defined groups, and dynamically generated groups can each be used in the policy.
The huge advantage of this approach is how it reduces the firewall administrator's overhead in maintaining policy. If your
corporate security policy says, 'Deny Instant Messaging (IM)', then it's easy to create a dynamic rule called 'Instant messaging'
and use that in a single deny rule. If a new IM technology is invented, then it will be included in the next application signature
release, and the security policy requires no changes.
How does the security policy look?
Compared to the traditional security policy which can easily run into hundreds or thousands of rules, the Palo Alto policy can be
quite short and simple. Since you have the ability to make abstract rules about ​kinds of applications, then a good rule set can be
short and easy to read.
It is a mistake to try and literally translate an old-style policy into a Palo Alto firewall. You really need to start again.
It's not as hard as it might seem.
As long as you can identify a few known good applications, and a few known bad ones, then in a few lines you can generate a
policy which gives much more control than the original technique.
The original rules are likely to have a rule like this:
Allow ANY-SOURCE to EXTERNAL on port 80.
Your Palo Alto firewall might look like this:
Allow {DNS,Web-browsing,FTP,SSL,Flash} from zone USERS to zone INTERNET
Deny {Games, IM, VOIP, Video-streaming} from zone ANY to zone ANY
Allow ANY from ANY to ANY
This might seem a little strange, but with a little thought to the list of known-bad applications, the policy becomes quite
complete with only these three rules. The final allow-rule from any to any will catch internal applications, legacy applications
and those little things that you would otherwise miss when migrating a rule-set. You could equally decide to make that a DENY
rule and deal with the complaints that follow. It all depends on your security stance.
By inspection of the logs, the administrator can refine the deny and allow groups.
You could generate an entire policy with these three rules, or more likely have a set of three rules like this for each
zone-to-zone. In that case, then be sure to specify the zones in each case because if you say deny from ANY zone, then that's
what would happen. Only do that if you mean it!
What happens if my application is special!
Sometimes, you have a well-controlled in-house or well trusted application that has no signature, or behaves badly through the
scanning engines. If you need to bypass policy for such an application, then this is easy.
An unrecognized application will appear in the logs as 'unknown'.
You can use a 'place holder' to define a pretend application signature based on traditional port and address criteria. However,
you can also dress it up to include a risk-level, a categorization, and other useful reporting properties.
Having done this, the logs and reports will show the application as expected.
Note: The application override prevents a matching session from going through the Application Identification engine, but you
still need to write a policy for it.
Sometimes, you might find an application that should have a signature but one does not exist. It might be a new application. In
this case, you can define an application ID, write your policy, report the application to Palo Alto and wait for a new signature
update. When it arrives, you can leave the policy in place, and remove the application override.
What about special parameters like timeouts?
The definition of any given application includes things like Standards ports, Risk level and so on, but it also includes:
● Session timeout.
● TCP timeout
● UDP timeout
You can change these for a specific application.
Some of the following appear in the 4.0 user manual.
● Jumbo frames have a maximum Transmission Unit (MTU) of 9192 and are available on some platforms.
● Dynamic URL Cache Timeout in units of hours. (+ other related URL timeouts)
● x-forwarded-for - to pass original IP address via HTTP header. (Or this may be stripped)
● ICMPv6 Token Bucket Size (for rate limiting)
● ICMPv6 Error Packet Rate (average error packets allowed globally per second
I want to write my own application signature.
It's easier to get Palo Alto to do it. Other people benefit from that as well. However, you might need to cut a new signature for
HTTP, and this is allowed.
The GUI editor allows you to generate a regular expression as an HTTP signature based on things like the contents of the URL or
a particular string in the application data. A combination of criteria as boolean operators - AND, OR, NOT with various
parameters etc ​complete the signature.
Security profiles
A security profile is an object that can be attached to any of the security policies. Here is a list of the security profiles available:
● Antivirus
● Anti-Spyware
● Vulnerability Protection
● URL Filtering
● File Blocking
● Log Forwarding
● Data Filtering.
When traffic is allowed by a given policy and if that policy has attached, a security profile, then the extra checks are performed.
For example, you can allow outbound HTTP, but block a particular stream if it contains a credit card number. This is achieved by
attaching a "Data Filtering" profile to the policy that allows HTTP.
Note that active directory groups in a typical enterprise will categorize staff by job function. You may find a group for
warehouse, a group for students or a group for guests and so on. Since the firewall can take these groups as a pass/block
parameter in its policy, a different security profile can be applied to each group. You might want to restrict adult-sites from the
students, but allow that access for the security staff. This would be done through AD groups and security profiles.
Antivirus profiles (AV)
If you attach an AV profile to a policy, then certain actions need to be defined in the event that a virus is detected. To prevent
repeated transmission attempts as a Mail Transfer Agent (MTA) would do, for these protocols:
● Post Office Protocol (POP)
● Internet Message Access Protocol (IMAP) and
● Simple Mail Transfer Protocol
the default action is populate the threat logs with ALERTs. Optionally a packet capture can be stored with the alert.
For other protocols, the default action is to BLOCK the virus.
Vulnerability Protection.
This provides IPS. It's important to understand that an alert indicates an attack was attempted for a particular exploit and it
does not mean that there is a vulnerable target or that the target was attacked. A packet capture can also optionally be stored
with the alert-data.
Exemptions
Spyware, Antivirus and Vulnerability protection are implemented with signatures that have a corresponding Threat Identifier
(Threat ID). This threat ID can be added to an exemption list and stop the alerts.
URL Filtering.
The Palo Alto firewall licenses a database from ​Bright Cloud​. This database is USA-centric but there is a feature which, over time
creates a local database - particularly useful in other countries. Each URL is assigned into a category and this ultimately lets you
allow, deny or restrict access based on 'kinds' of sites. On top of this you can maintain a list of KNOWN good or known bad sites
by specific URL or by incorporating a wild-card - as in the example "*.witchcraft.*"
When someone attempts to access a blocked site, that person sees a customizable block-notification.
The available actions are:
● Allow
● Block
● Continue
● Alert
● Override
Notification-pages presented to the user are customizable.
Block and allow lists are evaluated in this order:
1) Block list
2) Allow list
3) Category settings
A file blocking profile can control ingress and egress paths :
● It will detect file attachments
● It will identify a file independently from file extension - by MIME type.
Data filtering
Data can be filtered independently using weighted criteria, independently inbound and outbound, per session. You configure
this using sets of regular expressions. Credit card and US social security numbers have predefined patterns. Each filter has an
Alert/Block threshold. This feature is very useful for Payment Card Industry (PCI) compliance.
Only the minimum packet-capture length is held for analysis - just enough to comply with regulations, and the PCI auditor gets
a unique password to view the data. If the auditor loses the password, then the data is purged when a new password is
generated. This rather strange behavior is to comply with PCI requirements as it prevents the system administrator from finding
card details.
The Data Leakage Prevention (DLP) features are particularly useful when the rest of the organization has systems which will
automatically tag documents with a label like 'Company Confidential' or 'Top secret umbra".
Identifying users
A longstanding omission from firewall technology is how to create reports (and policy) with user names instead of or as well as
their IP addresses. It's possible to use static IP addresses and somehow bind a person's identity to a specific IP address but this
is so restrictive today that it is almost never done. Instead, Dynamic Host Control Protocol (DHCP) and Hot-seating allows a user
to roam between machines and IP addresses. It's difficult to post-process firewall logs to translate IP addresses to user names
because any particular user could change IP address several times through the log-history. So the username/IP mapping needs
to be recorded inside the logs with the appropriate time-stamp.
In practice, performing this mapping is a problem because of non homogeneous operating systems and authentication
schemes.
The Palo Alto solves a good deal of the issue by employing several clever techniques.
The Palo Alto Networks User Identification Agent
The PAN User ID agent may be installed on one (or more) of a company's Active Directory (AD) servers or on a Windows server
that has access to an AD server. It is non-intrusive and connects to the AD using Microsoft Remote Procedure Call (MS RPC)
supporting:
2008, 2030 and 2000 domain controllers.
The user agent(s) gather(s) user and group information directly from the AD server(s), then the Palo Alto firewall consults the
user agent(s) using Secure Socket Layer (SSL) for mapping IP addresses. You need a PAN agent for each AD domain. Since a
username in one domain could be identical to a different user in a different domain, the firewall stores each username qualified
with its respective domain.
The agent retrieves group information from the AD servers, and obviously some groups are not relevant and these can be
filtered out.
Reading the AD security log.
AD writes useful IP-user mapping information to its security log. Unfortunately, in a cluster of ADs, the logs are not replicated,
but this is still useful information. If the user agent has read-access to a particular AD log and all users and groups, then it can
mine mappings from the logs and periodically poll the log files for new information.
Open Server sessions
When an AD user connects to a printer or file share, a username-IP address pair is logged in the server session table. The user
agent can read this information if it has rights to read the current open sessions on the Domain Controller (DC).
Terminal Server Agent
Terminal Servers and Citrix servers cater for many users on the same machine. This means that they all appear to have the
same IP address. However, the source ports that they are allocated are mappable to unique users. The Palo Alto Terminal
Server Agent can run passively as a service on Citrix or MS Terminal server machines where it controls the source port
allocation and feeds the firewall with a mapping between <username> and <IP address , source port>.
An active method - NetBIOS query.
The User Agent can also switch into an active method to find IP addresses. It can send a query via the Network Basic
Input/Output System (NetBIOS) to a workstation. This is useful in particular for laptop users because they can roam between
wireless access points (APs) and wired networks without logging out and back into the domain. As they do this, the IP address
changes but the user remains logged in.
For this to work:
● The client must enable 'file and print services' for Microsoft Networks.
● The client must enable NetBIOS
● The client's software firewall must allow the query.
● Any intervening firewalls and access control devices must allow the query.
NTLM Auth.
The NT LAN Manager (NTLM) is a Microsoft authentication protocol. Some browsers in a Microsoft environment can
transparently respond to an authentication challenge. If this is the case, then the firewall can intercept a session with an
unknown user over an HTTP or SSL session. It will:
1. Issue HTTP 302 response which points to a Layer 3 device that issues HTTP 401.
2. The HTTP "unauthorized" 401 response contains a tag which triggers NTLM authorization.
3. The firewall asks a user agent to to forward the information to a domain controller to discover if the user's browser
successfully authenticated.
Captive portal
Where all other methods of discovering the IP-address to user-name mapping fails, the firewall can fall back to 'captive portal'.
This is last-resort because it interrupts the user to ask for authentication. People tend to get annoyed with multiple
authentication requests which is why this is last-resort. However, it does work for non Microsoft clients.
1. Firewall sees an unauthenticated session that is not transparently resolvable.
2. Firewall sends HTTP 302 redirect to a captive portal page.
3. This web-form is presented to the end-user and gathers username/password.
4. The username/password is authenticated with a RADIUS server.
5. If successfully authenticated, the Palo Alto User agent adds the mapping to the database.
The firewall rule bases includes a section for captive portal policies. Here are the parameters:
Name | Source Zone | Destination Zone | Source Address | Destination Address | Method
In the method you have the choice of:
● No-Captive-Portal: the session remains unknown.
● Captive-Portal: Use Web Form based user detection.
● NTLM-AUTH: attempt NTLM authentication and If it fails, attempt a web-form based mapping
After such effort to obtain user names and IP addresses...
What can we do with the information?
Obviously, log files and reports benefit greatly from exposing the user name along side application usage. You can see who is
using Facebook or bit-torrent, and how much data and time is consumed and spent doing so.
The Palo Alto can also use this data in its firewall policy!
The 'user' column in the policy is "ANY" by default, but you can set it to match a specific user, a group of users or any KNOWN
user. Thus it is possible to set policy for all that are known to be properly authenticated and exclude others, or grant different
levels of access based on credentials.
Furthermore, the conventional policy has a source parameter based on IP address or network, and this is combined with the
user parameter using logical AND.
SSL decryption.
To avoid going off on a tangent, I will have to assume that you know enough about symmetric and asymmetric encryption and
PKI infrastructure to understand this next section. Secure Socket Layer is a per-session encryption which is most commonly
used for secure sites like banking and server-updates or travel-booking sites and so on. When the https:// prefix is used, it can
choose Transport Layer Security (TLS) or SSL.
Normally, a firewall cannot peer inside a secured session, but the Palo Alto can be authorized to decrypt, scan and encrypt
again. This is possible in both upload and download directions. The client and server are issued digital certificates by a
highly-trusted third party. These tokens of trustworthiness are passed around to allow client and server to check on the
credentials of the parties involved. Inside a digital cert, you find a flag which states its purpose. This may be for authorization,
for encryption, for a client or server... whatever its use, an issuing authority called a Certification Authority (CA) digitally signs
the certificate as valid.
If someone or some ​thing tries to circumvent this authority by substitution of a different certificate, then the client can find out
from the CA that the certificate is invalid. A strong assumption is that we expect the end-user to actually read and heed an
invalid certificate-warning.
The Palo Alto can act as a client to the server, and as a server to the client in what is, in effect a "Man in the middle" attack. The
difference between this and a real attack is that you, the firewall administrator authorizes the process.
On the client side, it is the browser (or similar application) that knows by default, a list of trusted certificate authorities.
Therefore, if the browser gets a certificate that is signed by a CA not in that list, it will issue a warning. You can tech the browser
to accept certificates created by the Palo Alto firewall. In this way, all users are protected from viruses and malware that would
normally pass on an encrypted path directly from source to desktop.
The typical process (without the firewall in the way) for SSL is as follows:
1. Client connects to SSL-protected site and requests a connection.
2. SSL-protected site sends a certificate.
3. Client verifies the certificate.
4. Client sends an encrypted session key
5. SSL-protected site sends encrypted data.
The certificate is checked for:
 ● certificate matches server
● dates must be valid
● certificate type is SSL
● signature is valid
● the CA is trusted
SSL - Palo Alto as a forward proxy
When the Palo Alto firewall is in the path from client to server for an SSL session, it acts as a forward proxy. Here are the steps:
1. Client requests SSL connection
2. Server sends certificate (as before)
3. This time, the Firewall gets the certificate but creates a new one for the client.
4. The client verifies the certificate from the firewall.
5. Client sends a session key to the firewall.
6. Firewall sends a (different) session key to the SSL server.
Although the clients sees, and can verify that the certificate it receives is generated by the firewall, the firewall tries to include
as much relevant data from the SSL server as possible:
● SSL certificate's dates are re-written onto the Firewall-generated certificate.
● If the Firewall finds that the SSL certificate is not trusted, then it deliberately creates an invalid certificate for the client.
SSL - Palo Alto as an inbound proxy
When the SSL session is initiated from outside, and headed for a protected server on the inside of the firewall, the Palo Alto
firewall acts as an inbound proxy for SSL.
1. External client requests SSL session with a server behind the firewall.
2. The internal server sends a certificate back.
3. The firewall has been primed with a COPY of the SSL server's certificate AND key.
4. The firewall issues this copy to the original external client.
5. The external client sends a session key.
6. The SSL server sends encrypted data.
7. The firewall decrypts, scans and encrypts the data as it goes back to the external client.
Point 3. above will possibly be awkward to achieve in some environments - especially if the owners of the SSL server and the
security team are independent. It takes a bit of education and internal selling to convince the web-wizards to release a copy of
the certificate and key to the firewall. But the benefits outweigh those concerns because the firewall can protect the server
from otherwise encrypted malicious activity, and it can protect the corporation from data-leakage.
Management of certificates.
On the firewall, you can:
● create a self-signed certificate,
● load existing certificates,
● load existing keys,
● export self signed certificates.
Exported certificates can be added to users' browsers to make the browser understand that those particular certificates are
trusted.
Use of existing internal certificate authorities.
Some environments already have integrated a certificate authority. Typically, Active Directory or Novell eDirectory. In this case,
the firewall can use what is called a 'Subordinate certificate". AD will generate one in a format called Personal Information
Exchange (PFX). You will need to ​convert​ this to a format called Privacy Enhanced Mail (PEM) for import into the firewall.
How do you create SSL decryption policy?
The GUI has an 'SSL Decryption' policy tab. In there, you can define policy based on:
Source Zone, Destination Zone, Source Address, Sour User, Destination Address, Category, Certificate, Action
The column 'Certificate' is for choosing between forward proxy or intercept. 'Action' lets you choose whether particular traffic
needs to be decrypted. Typically, for peace of mind, users' like access to banking sites to pass by without encryption.
VPN
A Virtual Private Network (VPN) means an encrypted tunnel. It often implies Internet Protocol Security (IPsec), but a VPN can
also use SSL, or Secure Shell (SSH) or other methods.
The Palo Alto firewall offers an SSL-based VPN solution which will first attempt to use IPSec over SSL because it is available on
almost all browsers and allowed through firewalls. It will fall-back to standard SSL if required.
For SSL VPN, the client authenticates to the firewall, and the firewall installs the SSL client VPN software via an SSL session. The
SSL VPN client creates an internal IP address and a virtual network adapter which operates using IPSec for the fundamental
encryption technology.
There are several ways to implement VPN tunnels. The Palo Alto engineers (at the time of writing) chose to implement
route-based IPSec VPNs because they are easy to use and scale well. In practice, this means that the destination address
triggers a tunnel. A typical routing decision looks at the destination and netmask, compares this to a table and looks up the
interface and/or gateway for how to forward the data. The virtual VPN interface appears as a route-able object and data sent to
such a virtual interface gets encrypted.
VPN Internet Key Exchange (IKE)
To set up a VPN tunnel, both ends must agree on several parameters, like which encryption to use, how many bytes to transfer
before a re-key, and other information. This IKE is performed in two phases.
The first phase sets up some stable parameters, and the second stage is repeated throughout the life of the tunnel to refresh
keys. This is done to prevent someone from collecting a large pool of same-key cipher-text that could be used as part of a
cryptographic attack.
Phase 1
Identify the end points.
Each end is identified by a 'Peer Identifier (ID)' or an IP address, or a domain name or some static text. Both ends will need to be
configured and agree on the method before IKE will work.
Each end is authenticated to each other and then a secure channel is set up.
Phase 2
Determine which traffic can use the tunnel.
This is where the proxy ID that was authenticated in phase 1 is used.
VPN IPSec parameters
Phase 1
● Diffie Hellman (DH) Groups 5, 1, 2, and 14
● Encryption: Advanced Encryption Standard (AES) 128, 192 or 256 bits, and Triple Defense Encryption Standard (3DES).
● Hashing: Secure Hashing Algorithm (SHA1), Message Digest (md5.
Phase 2
● Authentication Header: SHA1, md5.
● Encapsulated Security Payload (ESP) Authentication: SHA1, md5, none.
● Encapsulated Security Payload Encryption: AES256, AES192, AES128, 3DES, none.
● DH groups: 5, 1, 2, and 14
Note how IPSec allows you to choose to authenticate but not encrypt traffic, and conversely encrypt but not authenticate, or do
both. What you choose depends on the application in hand.
DH group 5 is considered most secure.
Perfect Forward Secrecy (PFS)
PFS has a confusing title. It sounds grand but all it really means is that fresh keying material is used on every Phase2
negotiation. Without PFS, then established keys are manipulated into new keys. Obviously, to use fresh keying information each
time results in better security, but there is a performance hit, and sometimes problems with compatibility. This is why PFS is
optional.
Network Layer - Dynamic Routing
Many firewall administrators prefer to use static routes because these are controlled entirely by the configuration of the
firewall. They perceive a security risk to let some other machine tell the firewall how to forward data. This concern is justified,
but at the same time, a large dynamic network could be far too difficult to maintain with static routes. In fact, the security risk
from configuration error could be greater than using a dynamic routing protocol.
The Palo Alto firewall supports two dynamic routing protocols:
● Routing Information Protocol (RIP)
● Open Shortest Path First (OSPF)
Of these, RIP is a simple vector-based routing protocol suitable only for small networks as it does not scale well.
OSPF is potentially difficult to set up because it has several parameters, some of which are timers. If your set up does not match
the corporate implementation, then it can be troublesome. Cisco have established a de facto-standard configuration and it is a
good idea to follow those parameters when possible. OSPF scales well and it converges quickly.
Note: These dynamic routing protocols can be run across an IPSec tunnel.
You enable dynamic routing by editing a 'Virtual Router'.
OSPF parameters:
● Name of interface (or sup interface or tunnel)
● Passive (Tick or not)
● Enable (Tick or not)
● Link Type (Broadcast, Point-to-Point or Point-to-Multi-Point.)
● Metric (0-65535)
● Priority (0-255)
● Timing - Hello interval (0-3600)
● Timing - Dead counts (1-20)
● Timing - Retransmit interval (1-3600)
● Timing - Transmit delay (0-3600)
 ● Authorization profile
● A List of Neighbors.
Link type choice:
For Tunnel interfaces - you must use ​point to point​. Layer 3 Ethernet interfaces and sub interfaces should be set to ​broadcast.​
OSPF routes are tagged with Oi in the routing table to indicate an internal OSPF route.
Network Layer - Quality Of Service (QoS)
Normally, all types of internet traffic have an equal chance to get routed. Some applications should be elevated to a higher
priority. Typically, these are latency-sensitive applications like Voice over Internet Protocol (VOIP) or video streaming, or a
stock-market application. They are not necessarily high bandwidth applications, but they suffer if any packets get delayed.
QoS is a method to select certain packets for priority routing.
QoS also allows you to control the bandwidth used by various applications.
To do this, the Palo Alto Firewall permits the following controls:
There are eight ​classes.​
For each class, you can set:
● Guaranteed Egress in Mbps
● Maximum Egress in Mbps
● Priority { low, medium, high, real time }
Once these classes are defined, then you assign the class in a QoS policy:
Name, Source Zone, Destination Zone, Source Address, Source User, Destination Address, Application, Service, Class.
Note: Class 4 is the default class, used when none of the rules match.
Network Layer - High Availability (HA)
You can create a two-unit Active/passive cluster to provide a primary and secondary data path where state and configuration is
copied across both units. The higher-end 4000 series machines use an HA layer 2 interface for the data plane to do state
synchronization, and a layer 3 interface for the management plane to synchronize configuration. The lower end units also have
a data plane and a management plane but only one HA interface.
All configuration is synchronized except:
● HA configuration
● Management information
● Administrator accounts
Configuration is quite easy. Here are the advanced options:
● Device Priority​ - from startup, a lower value becomes the active firewall.
● Enable Preemptive -​ makes the particular firewall a preferred primary unit.
● Passive Hold Time​ - X milliseconds of fail-over delay.
● Hello Interval​ - heartbeat interval in millisecond.
What is considered a fail-over condition?
1. If any specified links go down, this is a LINK failure.
2. If a pre-configured test over a network fails, this is a PATH failure.
Fail over can be set to trigger combination of 1 and 2 above including and PATH failures over Virtual Local Area Networks
(VLANS) and virtual wires.
Layer 2 interfaces
Each interface can be assigned as a tap, a layer 3 or a layer 2 interface. Any two layer 2 interfaces permit a virtual wire between
them.
Also, any layer 2 interface can be associated with a VLAN and a ​security zone​. Multiple layer 2 interfaces that are given a
security zone may then be used to segment and apply policy to a flat network. Without zones, the unit behaves as an ordinary
switch.
Note: A flat network is a network where all hosts are in the same
broadcast domain and therefore in the same layer 3 addressing scheme.
Sub interfaces.
Each PHYSICAL interface can be made to look like a set of independent interfaces by using 802.1q VLAN tagging. A VLAN tag
appears to the operating system as an independent port.
You can assign layer 3 and layer 2 VLAN sub interfaces.
A layer 2 sub interface behaves like a normal switch port. A layer 3 sub interface gets an IP address.
Virtual wires.
Important (and obvious): When you insert the Palo Alto firewall into a wire using two ports set up as a virtual wire, you do not
get the ability to do NAT.
However, you ​can do SSL decryption and other policy based control including user identification (Use ID) and reporting. The
huge advantage of this mode is that the firewall can be transparently introduced into the network without any non-firewall
configuration. It will pass multicast traffic either transparently (default) or through policy such that 224.0.0.0 is included in the
definition of the destination 'ANY' in the policy.
Taps
You can use a single interface of the firewall to connect to a 'span' or 'monitor' port of the corporate switch and inspect (but
not control) the traffic it sees. It's possible to have multiple taps, and multiple virtual wires, and multiple layer-3 interfaces and
VLANs simultaneously.
Tap mode is passive therefore it cannot decrypt SSL but this is a very simple method of introducing the rich reporting and
visibility that the firewall can provide. The tap mode is non intrusive and does not introduce a single point of failure.
The 'security' policy format is used to control what traffic gets logged and reported. It does this by referencing the tap
interface's zone in the policy.
Management of the firewall. - Virtual security configuration.
Administrators are authenticated from a locally stored user database or from RADIUS. Actions are logged. There are two kinds
of administrators:
1. Device level - can manage the entire device.
2. Virtual SYStem (VSYS) account - can manage a particular virtual system.
Role-based administration includes:
● Super User
● Device admin (see above)
● Device admin - read only
● VSYS
● VSYS - read only
Using a selection of 'enable' read-only' or deny for each Web interface function, you can create user defined special roles:
● User defined - based on job function
● User defined -VSYS admin
● User defined -device admin
A VSYS admin gets a user identifier (ID). This ID can be a tag for objects on the firewall, and a particular VSYS admin can only
change those objects which have the particular VSYS's ID as a tag.
Summary:
● Role based access is applied to the account to allow access to certain web user interfaces.
● VSYS access control is applied to each object. - Virtual Wire, Virtual Router, Zone, Interface, Virtual LAN...
BOTH these access controls may be combined to permit very fine control.
The DEVICE administrator must create (and tag) virtual routers, virtual wires and VLAN objects.
Control of configuration images.
The Palo Alto implements a two-phase commit much like Cisco routers. At any time, there could be the actual running
configuration, a saved but not committed configuration, and a candidate configuration. It's a two-phase commit because first
you save the candidate configuration, then it gets committed.
A configuration can be saved locally as an XML file, and this can be imported into a production or test firewall for viewing and
later discarded without affecting the running configuration. Such flexibility is very useful for support staff.
Upon reboot, an unsaved configuration is purged.
At any time, you can take a ​snapshot.​ This gets saved to your administrating PC to a name of your choice.
NOTE:
● do NOT use the keyword 'config' anywhere in the file name as it is a reserved name and will cause the configuration to be
rejected upon restore. (Changing the name on file will fix this.)
There is also a 'rollback' facility to make it easy to backout a change, and this over writes the candidate configuration.
Any two configurations - files or running config can be compared in a color-coded GUI-based side-by-side comparison tool.
Details about the management interface.
By default, a dedicated and labeled management interface is set to 192.168.1.1/24. But this of course can be changed, and a
different physical interface may also be used.
The management traffic can run over http, https, SSH and different physical ports may be chosen based on the chosen protocol
or destination of management traffic, where the latter overrides the former.
How to manage the software versions.
Under the Device tab -> Software, a GUI allows you to refresh the available operating system version list via a properly
configured internet connection. As long as the management interface and IP addressing can get to the internet, then this works
perfectly. Otherwise, you can import a new version from your administrating PC.
Several versions can be loaded ready to be installed. This allows you to quickly choose any stored version at will. The
appropriate release notes are available from the same GUI.
Dynamic Updates.
The Uniform Resource Locator (URL) database is used for filtering web content. This is upgraded frequently so the firewall
allows you to:
1. Manually Install the most up to date version.
2. Subsequently allow periodic updates.
Again, the release notes are available in the GUI. It is important in a production environment to check the release notes in case
enhancements are made which could affect the local setup.
Panorama
Panorama is a VMWare virtual image which provides centralized centralized management and reporting for the Palo Alto
firewalls.
From Panorama, it uses the same look and feel of the individual firewall interface and gives the administrator the ability to
manage several firewalls from one configuration interface.
Of course, although the look and feel of an individual firewall is exactly replicated with panorama, it needs extra features:
● It maintains a ​device list​ and you add to the list via device serial number.
● The device ​name​ is included where appropriate in each GUI screen.
● The firewall and Panorama know each other's IP address.
● Global rules may be set for all policy (except for NAT).
● Panorama rules and local rules can coexist.
● The combined policy is visible for any device.
● Global Pre and Post rules are color coded.
● A configuration may be committed to all or a selection of devices.
● It can combine firewall reports from multiple devices.
● It automatically saves all of the configuration files that are committed on each managed firewall. The configuration may
be changed locally or through Panorama.
Log files.
All gateways produce log file. The Palo Alto is no exception. There are several kinds of log files:
● Configuration
● System
● Threat
● Traffic
● URL
● Data Filtering
Configuration logs.
Each configuration change is logged and referenced by a 'configuration path' with a time stamp, the username of the
administrator and an action. This satisfies requirements for a change-control log.
System logs.
A system log is stored when an administrator logs in, something significant happens with a VPN, some kind of user ID event,
and a routing update.
Threat logs.
The threat logs are for events related to:
● Spyware
● Vulnerability - malicious content
● Anti-virus
● Spyware
● Alerting or blocking URL categories
Traffic logs.
By default, when a session begins related to a recognized (or "unknown") application, a byte counter and timer begins. The log
entry is written when the session terminates. The session starts when a new signature is triggered, and when that happens, the
policy is re-read from top-down.
URL logs.
The following events on URL related filtering will trigger an entry in the URL log:
● Alert
● Black
● Continue
● Override
Data Filtering Logs
This log contains file locking and data filtering events, including a small packet-capture.
Log details.
There is too much information for each log entry to fit on one line. Log ​details​ shows the extra information and includes:
● NAT information
● SSL decryption status
● Interface from which the traffic arrived
 ● Interface out of which the traffic left
● Captive portal status
Filters
It's clear that a great deal of data is collected about traffic controlled by the firewall. To manage this, the administrator can use
filters and save them for repeated use.
These filters may be dynamic or custom built.
Dynamic
When you click on an item in the logs, that item is automatically added to a dynamically constructed search filter.
Custom
If you know the search criteria, then it may be manually entered into the filter editor.
In both cases, terms can be joined with familiar Boolean operators:
● AND
● OR
● NOT
Each query, once constructed and tested can be saved and retrieved by name for future use.
Reports.
You can export reports in the format: Portable Document Format (.pdf) or Comma Separated Values (.csv)
Automatic reports.
Four automatically generated report categories provide 33 built in reports that operate over a 24 hour period to produce a daily
notification. These summarize from the following logs:
● Threats
● Applications
● URL filtering
● Traffic
Custom reports.
Custom reports can be constructed from the following databases:
1. Application summary
2. Traffic log
3. Traffic log summary
4. Threat log
5. Threat log summary
NOTE: 'summary' data includes totals of sessions and byte counts.
You extract selected information by using a filter, and pick the appropriate columns for your report.
Summary reports
When you have multiple custom and built-in reports, these may be collected into a single or several automatically-generated
daily summary reports. The content and layout of the charts and tables is under your control.
Here are some examples of topics:
● top-destinations
● top-rules
● top-users
● top-vulnerabilities
● etc
Report delivery.
Up to twelve user activity reports can be emailed on a daily basis to a group of people. Different reports may be sent to
different recipients, and reports can be generated on a weekly cycle.
Factory reset
You will need a serial console access once reset is complete in both cases
Factory default using CLI
Log in to the CLI via SSH or Telnet
Enter CLI command 'request system factory-reset
Factory default using serial console connection
9600 - 8 - none - 1 - no flow control
Log in : Factory-reset
Password: serial number (case sensitive) *
*located on the rear of the unit.
DO NOT power off until the factory reset has finished.
Default settings for the management port:
IP address: 192.168.1.1/24
Username: admin
Password: admin
Then you can log in via a web browser using
https://192.168.1.1
Command Line Interface tips.
Here are some useful CLI expressions:
● show routing protocol rip database ​{ Shows learned routes from RIP }
● show routing route ​{ Shows the current routing table }
● request high-availability sync-to-remote​ { forces synchronization in HA }
● request high-availability state suspend ​{ This machine cannot now be master }
● request high-availability state functional ​{ reverses the above }
● show high-availability state ​{ give a lot of information about HA state }
● debug software restart device-server ​{ restart the device server }
● commit force { ​force a commit regardless - can only do from command