Palo Alto Next Generation Firewall

S T O P P R E S S 6 Jun 2012

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. http://www.paloaltonetworks.com/literature/video/demo/demo-ui.html

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

Have you already heard about this firewall?

  • Yes
  • No
  • I think so.
See results without voting
February 2010
Updated: March 2011
 

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.

Heuristics

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 alongside 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 something 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 can not 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 line }


More by this Author


Comments 32 comments

Marta  6 years ago

Great!!


Manna in the wild profile image

Manna in the wild 6 years ago from Australia Author

Thank you Marta.


Bill 6 years ago

The PALO alto firewall can be configure to pas Ip multicast traffic?


adreaman 6 years ago

a wonderful document to learn about next generation firewall!


Frank N 5 years ago

Very good information. Thanks.


Owan 5 years ago

Could Palo Alto Firewall be as proxy server for http service?


Manna in the wild profile image

Manna in the wild 5 years ago from Australia Author

There are two kinds of http proxy - the security proxy which is superseded by the PAN firewall, and the caching proxy server.

The PAN firewall is not a caching HTTP(s) server and it does not try to implement the outdated traditional security proxy where the client-server model is deliberately broken. If you really think there is value in caching and web acceleration, then use an up or downstream caching web proxy dedicated for the task. Note that there is not as much static content on the web compared to when caching proxies were first marketed. So you need to evaluate your particular traffic.

The PAN firewall provides a lot more security than the dedicated HTTP security proxy ever could, and gets enhanced with new application signatures as they become necessary.


Smail 5 years ago

Hi,

does the 500 model support the same features (IPS, AD, DPI, reporting, URL filtering, High Availability)

like the other models (2000, 4000, 5000)?

The difference is only the throughput and number of interfaces?

Is there a link where I can compare the models on one site without going through all the data sheets?


Manna in the wild profile image

Manna in the wild 5 years ago from Australia Author

The 500 will not do VSYS (Virtual systems) or 802.3ad.

the 2000 series supports VSYS but not 802.3ad.

The rest is supported, and the GUI is the same.

As for the latter query, this looks promising:

http://www.paloaltonetworks.com/literature/index.p...


James 5 years ago

In our scenario , we have existing hundreds of firewall policy configured on it. It tooks around 20 minutes to take affect them when we tried to move some policies to different position and add additional some policies into it.


James 5 years ago

I just finished a POC for PA firewall and found something as above.


Manna in the wild profile image

Manna in the wild 5 years ago from Australia Author

James, to a large degree, the commit time is not dependent on the policy size. Therefore there must be an anomaly which can be resolved through tech support.


Mark Zetts 5 years ago

We have a Palo Alto SSL-VPN firewall but with the new Windows 7 laptops just issued running 64 bit OS, we have run into a problem with the 64 bit JRE needed to use NetConnect and the 32 bit older 1.5 JREs needed for the application we are connecting to. The older 32 bit laptops on XP do not have this issue. With the 64 bit laptops on Windows 7 the 32 bit IE browser will not connect, only the 64 bit IE will, but then we cannot use the 32 bit 1.5 JREs as the applications cannot find them.

Is there a way to force it to always use/expect a 32 bit browser and JRE connection so there is no issue?


Manna in the wild profile image

Manna in the wild 5 years ago from Australia Author

In the support knowledge base, there is a checklist that tells you how to work with 64-bit O/S.


sach2910 5 years ago

Great stuff..... keep up the good work!!!

As we say in India, Knowledge grows when its dispersed..


Lazhar 5 years ago

could Palo Alto be interconnected with a NMS equipement like InfoVista or HP open view to collect the logs and create a dashboard and reporting portail?

regards

Lazhar


Manna in the wild profile image

Manna in the wild 5 years ago from Australia Author

Lazhar, I know for certain that LogRhythm can natively read Palo Alto syslogs. The PAN will stream syslog, so any NMS that can read the format can be used. It will also integrate with Splunk and other SIEM products. PAN-OS supports well known traps (defined in RFC1907), and will also allow configurable traps. Each log message can be sent as a trap, and you can download MIBs for the O/S.


lazhar 5 years ago

very nice post and useful answer for my question, thanks

regards

lazhar


Nandagopal 4 years ago

From a security perspective, won't SSL decoders mentioned above be able to peer into banking traffic and capture Credit card information . You have mentioned that a policy can be made where the device(PA) will not look into the SSL traffic destined for banking sites but aren't we at the mercy of the firewall admin , who might one day decide to quit his job and live off the credit card numbers decrypted using SSL decoders. Or is there another way that the SSL Connects to banking/credit card gateways can never be decrypted even if you have all the SSL decoders in the world? Is it even ethical to do SSL decoding on banking traffic?

Also I believe SSL connections can go to 8080/443 etc but can PA decode random SSL ports for different webserver/applications? Do banking sites use a random high numbered port for SSL and is there a VPN + certificate layer above the SSL port layer?

Last question, how far different is a PA device from a Microsoft ISA server 2006/TMG which seems to have almost all the security capabilities mentioned above except for maybe HA and caching/acceleration. ISA also has firewall client mode which can use a diff policy for itself across any network boundaries?

By the way, this is a great blog with a lot of information!


Manna in the wild profile image

Manna in the wild 4 years ago from Australia Author

"won't SSL decoders mentioned above be able to peer into banking traffic and capture Credit card information"

It's all done in memory. You'd have to hack the O/S to vector off the credit card information.

"aren't we at the mercy of the firewall admin , who might one day decide to quit his job and live off the credit card numbers decrypted using SSL decoders."

It's too hard a task compared to the admin just looking at plain-text emails. There is a lot of information in emails that could assist a crook.

A crooked admin would do better (less risk and effort) to just buy validated credit card data on the black market!

Even a PCI auditor checking on credit-card leakage via the PA data-leakage-protection facility will not be able to write down an actual leaked credit card as the PA does not reveal the actual number. It blocks the leakage and offers a small packet-capture as evidence.

"Or is there another way that the SSL Connects to banking/credit card gateways can never be decrypted even if you have all the SSL decoders in the world?"

Not that I know of. on average, I'd wager that a machine given rights to "MITM attack" an SSL stream by a trustworthy organisation, subject to PCI audits will do a better job of checking certificate validity than the typical individual. It's ethical to increase security. But no matter how you explain this, some people can't accept it and that's the reason for the bypass capability.

"Is it even ethical to do SSL decoding on banking traffic?"

Yes of course if it increases security. I'd rather trust my organisation to SSL decrypt my banking connection in this way than risk a keylogger coming into my machine over an SSL link.

"Also I believe SSL connections can go to 8080/443 etc but can PA decode random SSL ports for different webserver/applications?"

Yes.

"Do banking sites use a random high numbered port for SSL"

No idea... and I can't see the advantage.

"and is there a VPN + certificate layer above the SSL port layer?"

Most definitely. It all sits in a PKI.

"Last question, how far different is a PA device from a Microsoft ISA server 2006/TMG which seems to have almost all the security capabilities mentioned above except for maybe HA and caching/acceleration."

Not knowing much about ISA server, means I can't answer this. Sorry.

"By the way, this is a great blog with a lot of information!"

Thank you, :-)


Henry 4 years ago

Can I use a suitably-sized PAN as a replacement for my Web application firewall and regular firewall set-up? Will it be like having both devices in just one?


Manna in the wild profile image

Manna in the wild 4 years ago from Australia Author

Hi Henry.

Yes. You might like to compare just how much you expect the PAN to do compared to the WAF. - X-site script protection etc. It would be a good idea to approach PAN with the question. Some WAFs are specialised and advanced.


John 4 years ago

Great work and make me understanding Palo Alto firewall much better then what their website told me. I am completely new to Palo Alto and my company is looking for to get some Palo Alto firewall in place to enhance application security. Actually, there are two questions come up to me after read your post:

1. how Palo Alto can achieve all security features turned on without comprise the performance. How one traffic stream can be simultaneously perform all security operations (such as AV, url filtering, ips, etc) by Palo Alto firewall? It get copied multiple times and then send to multiple security applications in different core?

2. Palo Alto firewall is streaming processing data packets. How Palo Alto firewall detect virus in a big compressed file without received all data? Just curious it.


Manna in the wild profile image

Manna in the wild 4 years ago from Australia Author

Hi John,

Threat analysis affects performance capacity according to the specifications; but apart from that the answer to your question is that the firewall data plane uses a deterministic algorithm for signature matching. This means there are no surprises when under load and the performance is predictable. So the rated performance claims are matched to the hardware properly. A non deterministic method might be faster, but unpredictable under load - possibly hitting a chaotic mode where latency blows out.

Streamed data will contain a signature after a few bytes - usually within the first hundred bytes, 64 are chosen as the application signature. Once the application is known, the list of applicable viruses is greatly reduced and from then on a small set of virus signatures is compared to the data streaming past.

In contrast, a traditional virus checker has no intelligent knowledge of the application, so it needs to test every virus signature and of course that is very expensive for cpu-time. To mitigate that, some virus checkers load the file into memory and work on it that way, but this is not needed in the PAN because it knows already much about the particular applicable vulnerabilities etc.


KurpLondon 4 years ago

Thanks for your document,

Having never heard for Palo I googled it hence why I'm here. Although it was written in 2010, I'm a bit sceptical whereas we can call it next generation firewall. Most advanced firewalls (Checkpoint, Juniper) provide user authentication and application identification (maybe at different level) but that's not why I'm posting.

Now the most interresting part, in my opinion, is the SSL "decryption". I would rather call it SSL proxy. It sounds to me it can only work in a controlled environment (i.e corporate users) and/or the fact many people would ignore a certificate warning. You can force user in your coporate network to trust a CA (in this case the firewall) but then what happen if dual authentication is required. For example, what happens if banks start issuing client certificates to their customers ? While the client's webbrowser will ignore the certificate warning because the Firewall's CA is among the trusted CA, it's unlikely the remote server ignores a forged certificate thus preventing the authentication. So to allow legitimate traffic, you'll start adding "trusted" websites (and applications) to go through by bypassing your security policy. And we all know what adding exception means.


Manna in the wild profile image

Manna in the wild 4 years ago from Australia Author

A new partly free, with optional enhanced feature pay service called "Wildfire" traps malware. Device - Setup - WildFire.


az88evn 4 years ago from Ha Noi

thank so much, it's so great


carpet 4 years ago

Can I use palo alto firewall in level 1,

How does it work?


Manna in the wild profile image

Manna in the wild 4 years ago from Australia Author

What do you mean level 1?


carpet 4 years ago

I mean level 1 like physical level.A firewall in the wire ,whitout level 3(IPs),whitout level 2(vlan) and whitout macs .It´d be like a wire with policies


Manna in the wild profile image

Manna in the wild 4 years ago from Australia Author

Yes - search this article for virtual wire


carpet 4 years ago

thank you so much from Spain

    Sign in or sign up and post using a HubPages Network account.

    0 of 8192 characters used
    Post Comment

    No HTML is allowed in comments, but URLs will be hyperlinked. Comments are not for promoting your articles or other sites.


    Click to Rate This Article
    working