Fundamentals Guide: Security Policies

PAN-OS 4.1, 5.0, 6.0

Table of Contents
Overview on page 1
Two kinds of security policies on page 1
Sessions on page 2
Topology on page 2
Service "application-default" on page 3
Shadowing of rules on page 5
Security policies base on users on page 6
Security policies with NATed IP addresses on page 6
URL categories in security policies on page 7
Application dependencies and application shifts on page 7
Application identification and decryption on page 9
Clean up rule on page 9
Security policy tips on page 9
Related knowledge base documents on page 10

Overview
This document describe the fundamentals of security policies on the Palo Alto Networks firewall.

All traffic traversing through the dataplane of the Palo Alto Networks firewall will be matched against a security
policy. Traffic originating from Management interface of the firewall will not be matched against the security
policies, as by default this traffic does not pass through the dataplane of the firewall. Security policies on the
firewall can be defined using various criteria like Zones, Applications, IP addresses, Ports, Users, and HIP
profiles. Firewall administrators can define security policies to allow or deny the traffic starting with the Zone as
a wide criteria and fine tuning the policies using other granular options (such as, Ports, Applications, and HIP
profiles).

Two kinds of security policies

The firewall has two kinds of security policies:
1. Explicit security policies: These policies are defined by the user and are visible in CLI and Web-UI
interface.
2. Implicit security policies: These are rules that are not visible to the user via CLI interface or Web-UI
interface. The following section discusses more about the implicit security policies on the Palo Alto
Networks firewalls.

Generated on 2015-03-22-07:00
1
Fundamentals Guide: Security Policies

Implicit security policies

The firewall by default implicitly allows the intra-zone (origination and destination in the same zone) traffic and
implicitly denies inter-zone (between the different zones) traffic. The traffic allowed or denied by these implicit
policies are not logged on the firewall by default, and thus no logs can be found for this traffic allowed. In order
for the firewall to log the traffic, the traffic has to match one of the explicitly configured security policies on the
firewall. However, for troubleshooting purposes the default behavior can be changed. Refer to DOC-6957: How
to See Traffic from Default Security Policies in Traffic Logs.

Sessions
Palo Alto Networks firewall is a stateful firewall. All traffic passing through the firewall is matched against a
session and each session is matched against a security policy.

A session consists of two flows. The Client to Server flow (c2s flow) and the Server to Client flow (s2c flow).
The end point which initiates the traffic is always referred as the Client, and the end point to which the traffic
is destined to is referred as the Server. While defining security policies, only 'c2s' flow direction needs to be
considered. Policies should be defined to allow/deny traffic from the originating zone to destination zone, that is
from 'c2s' direction. The return flow 's2c' doesn't require another new rule. The Security policy evaluation on the
firewall is done sequentially from top to bottom in the list. Traffic matching the first closest rule in the list will be
applied to the session.

Here is an example of how to identify the flows in a session from the CLI:
> show session id 107224

Session 107224

c2s flow:
source: 172.23.123.5 [Test]
dst: 172.23.123.1
proto: 50
sport: 37018 dport: 37413
state: ACTIVE type: TUNN
src user: unknown
dst user: unknown

s2c flow:
source: 172.23.123.1 [Test]
dst: 172.23.123.5
proto: 50
sport: 37750 dport: 50073
state: ACTIVE type: TUNN
src user: unknown
dst user: unknown

Generated on 2015-03-22-07:00
2
Fundamentals Guide: Security Policies

Topology
In this document, the following topology is referenced for discussing different use cases of security policies:

Service "application-default"
This section discusses the service, "application-default", and its use in security policies.

In the example below, security policies are defined to allow and deny the traffic matching the following criteria.
Rule A: All applications initiated from the Trust zone in the IP subnet 192.168.1.0/24 destined to
Untrust Zone must be allowed on any source and destination port.
Rule B: The applications DNS, Web-browsing, FTP traffic Initiated from the Trust zone from IP
192.168.1.3 destined to Untrust Zone must be allowed.
The applications should by restricted to use only the "application-default" ports. For example the DNS
application by default uses destination port 53. So DNS application should be allowed only on this
port and the usage of this application on the rest of the destination ports should be denied.
Rule C: All the other applications from 192.168.1.3 to Untrust Zone must be blocked.
Rule D: All the traffic initiated from Untrust zone to any zones should be blocked.

Generated on 2015-03-22-07:00
3
Fundamentals Guide: Security Policies

The Service column in the security policies is used to define the source and destination ports on which traffic
should be allowed. There are four options to select from for Service:
1. Application-default: To allow traffic on the default destination ports.
Refer to the following document to get more details about finding default destination ports used by
various applications
DOC-7276: How to view Application-default ports for an application.
2. Any: To allow traffic on any source and destination ports.
3. Predefined services: Services that are already defined on the firewall.
4. Custom services: Admins can define services according to their application port requirements.

The screenshot below shows the rules that are created to match the above criteria.

When committing the above configuration changes, the following shadow warnings are displayed:

Generated on 2015-03-22-07:00
4
Fundamentals Guide: Security Policies

In the next section, the impact of the shadow warnings is discussed, as well as how to avoid encountering
them.

Shadowing of rules
In the above example, the IP address 192.168.1.3 belongs to Trust Zone and falls in subnet 192.168.1.0/24.
Since the firewall does a security policy lookup from top to bottom, all traffic from the IP 192.168.1.3 will match
Rule A and thus the same will be applied to the session. While the traffic also satisfies the criteria of Rule B
and Rule C, these rules will not be applied to this traffic as Rule A is shadowing Rule B and Rule C.

In order to avoid this impact, the Rule B and Rule C should be on top of the Rule A as shown below. This will
make the traffic match against thebcorrect rules and will prevent the "shadow warnings" during the commit.

Generated on 2015-03-22-07:00
5
Fundamentals Guide: Security Policies

Security policies base on users

In the above example, policies are written based on the IP addresses. In the same way, LDAP users, LDAP
groups, and locally-defined users on the firewalls, can also be used in the security policies. Refer to the
documents below for more details on how to setup User-ID and add the users to the security policies:
DOC-1807: User Identification Tech Note - PAN-OS 4.0
DOC-4068: How to Add Groups to Security Policy

Security policies with NATed IP addresses

This section discusses how to write security policies when a translation of IP addresses is involved, and also
how to use URL categories in security policies to control various websites.

In the below example, security policies are defined to match the following criteria:
Public IP 192.0.2.1 in the Untrust zone is translated to private IP 10.1.1.2 of the Web-server in the DMZ zone.
1. Incoming traffic from the Untrust Zone to the Web-Server 10.1.1.2 in the DMZ Zone must be allowed on
port 25, 443, and 8080 only.
2. All the users in the Trust zone must be denied access to "Adult and Pornography" category websites in
the Untrust zone.
3. All other traffic from the Trust zone to Untrust zone must be allowed.

The rules below show the configuration to satisfy the above criteria.

All the traffic destined to the web server from Untrust zone will have a destination public IP of 192.0.2.1, this IP
belongs to Untrust zone. Since the traffic is originating from Untrust Zone and destined to an IP in the Untrust
Zone, this traffic is allowed by an implicit rule that allows same zone traffic. After security policy lookup, the
firewall does a NAT policy lookup and determines that the public IP of the web server should get translated into
private IP 10.1.1.2, located in DMZ zone. At this stage, the firewall has the final destination zone (DMZ), but the
actual translation of the IP from 192.0.2.1 to 10.1.1.2 does not happen, yet. After determining the information of

Generated on 2015-03-22-07:00
6
Fundamentals Guide: Security Policies

the final destination zone for the post NAT traffic, the firewall will do a second security policy lookup to find a
policy that allows traffic destined to the final destination zone, DMZ. Thus, Rule X above is configured to allow
post NAT traffic.Note that Rule X has DMZ (Post-NAT zone) as the destination zone and the 192.0.2.1 (Pre-
NAT IP) as the destination IP address. In the above example a service "Web-server_Ports" is configured to
allow destination port 25, 443, and 8080. For more information, refer to DOC-4527:How to Configure a Policy
to Use a Range of Ports.

URL categories in security policies

In the above example, Rule Y is configured to block adult category websites using the URL category option
present in the security policies. Web-browsing application must be explicitly mentioned in the policies when
using the URL category option in the security policies else other irrelevant traffic with match this rule. Another
way of controlling websites based on URL categories is to use URL filtering profiles.

Application dependencies and application shifts

This section discusses "application dependency" and describes what happens to the session when the
application-id changes in the middle of a session.

In the example below, security policies are defined to allow and deny the traffic matching following criteria.
1. Applications Gotomeeting, Youtube from Trust zone to Untrust Zone should be allowed.
2. Applications Facebook,Gmail-base from Guest Zone to Untrust Zone should be allowed.
3. The applications SSL and Web-Browsing should be blocked for the Guest Zone users.

The below example shows the rules that are created to match the above criteria.

While committing the above configuration changes, the following application dependency warnings are seen.

Generated on 2015-03-22-07:00
7
Fundamentals Guide: Security Policies

Applications like Gotomeeting and YouTube are initially identified as SSL, web-browsing and Citrix. As more
packets for these sessions pass through the firewall, more information to identify the application is available to
the firewall. The firewall then shifts the application to respective applications like Gotomeeting and Youtube.

Whenever an application shift happens, the firewall does a new security policy lookup to find the closest rule
that is matching the new application. So in the above case, SSL and web-browsing are called dependent
applications for Gotomeeting and YouTube and thus these applications should also be allowed in the security
policies. If the application of the traffic changes in the middle of the session then a second security policy
lookup is done to rematch the traffic against the security policies for finding the new closest matching policy.

Generated on 2015-03-22-07:00
8
Fundamentals Guide: Security Policies

In the above example a new security policy called "Dependency Apps rule" is created to allow the SSL and
Web-browsing. Youtube traffic initially matches this rule and once the application shift happens then a second
security policy lookup is done to matched agains Rule 10.

Since PAN-OS 5.0, applications for some protocols can be allowed without the need to explicitly allow their
dependencies (see DOC-6900: How to Check if an Application Needs to have Explicitly Allowed Dependency
Apps). In the above example, Facebook and gmail-base are such applications which depend on SSL and Web-
browsing and doesn't need their dependency apps explicitly allowed.

Application identification and decryption

Certain applications like Vimeo that use SSL and are encrypted can be identified by the firewall without SSL
decryption. However, applications like YouTube that make use of SSL need to be decrypted by the firewall for
their identification. Since SSL connections are encrypted, the firewall has no visibility into this traffic in order to
identify this traffic. The firewall makes use of the common name field present in the certificate for application
identification. This is exchanged in clear text during the SSL handshake process.

Websites like Vimeo use the URL name of the website as a common name and thus does not need SSL
decryption to be configured. Some websites like YouTube use a certificate with wildcard name as the common
name . In YouTube's case it is *.google.com. So using this information for application identification is not
possible and thus SSL decryption needs to be configured to get visibility into URL of the website. Refer to the
following document on How to Implement and Test SSL Decryption

Clean up rule
In some environments it is necessary to log all the denied and allowed traffic by the firewall. By default, only
traffic that is explicitly allowed by the firewall is logged. To log traffic that is allowed by the firewall's implicit
rules, refer to the following documents:
DOC-1412: Any/Any/Deny Security Rule Changes Default Behavior
DOC-6957: How to See Traffic from Default Security Policies in Traffic Logs

Security policy tips

The following criteria is checked by the firewall in the same order to match the traffic against a Security policy.
1. Source/Destination address
2. Source ports and destination ports
3. Applications
4. User-ID
5. Url category
6. Source and destination Zones.

Generated on 2015-03-22-07:00
9
Fundamentals Guide: Security Policies

In the above configuration example, when application "web-browsing" on TCP port 80 from Trust Zone to
Untrust zone passes through the firewall, a security lookup is done in the following way.
1. Source/Destination address - Since Rule A, B, and C have "ANY" source and destination addresses, the
traffic matches all these rules.
2. Source ports and destination ports- Since Rule A, B and C have "ANY" services, the traffic matches all
these rules.
3. Applications- Since Rule A and B has "web-browsing" applications, the traffic matches these rule.
4. User-ID- Not applicable here.
5. Url category-Not applicable here.
6. Source and destination Zones. Since the traffic is between Trust and Untrust, Rule A is chosen for this
traffic.

The optimal way of configuring security policies is to minimize the use of "any" and be specific with the values,
when possible. This reduces unnecessary security policy lookups performed by the Palo Alto Networks device.

Related knowledge base documents

Is there a Limit to the Number of Security Profiles and Policies per Device?
How to Identify Unused Policies on a Palo Alto Networks Device
How to Test Which Security Policy will Apply to a Traffic Flow.
Why are Rules Denying Applications Allowing Some Packets?
Why Does "Not-applicable" Appear in Traffic Logs?
How to Identify Unused Policies on a Palo Alto Networks Device
How Session Rematch Works
How to Restrict a Security Policy to Windows and MAC Machines Using GlobalProtect HIP Profiles
How Application-Default in the Rulebase Changes the Way Traffic is Matched
Incomplete, Insufficient data and Not-applicable in the application field
How to Schedule Policy Actions
Security Policy Management with Panorama
Session Log Best Practice

owner: sdurga

Generated on 2015-03-22-07:00
10