Security policy fundamentals

by sdurga on ‎06-13-2014 04:54 PM - edited on ‎09-14-2016 12:03 PM by (106,531 Views)

Security policy fundamentals

 

Table of contents

 

Overview

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

 

All traffic traversing the dataplane of the Palo Alto Networks firewall is matched against a security policy. This doesn't include traffic originating from the management interface of the firewall, because, by default, this traffic does not pass through the dataplane of the firewall. Security policies on the firewall can be defined using various criteria such as zones, applications, IP addresses, ports, users, and HIP profiles. Firewall administrators can define security policies to allow or deny traffic, starting with the zone as a wide criterion, then fine-tuning policies with more 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 are defined by the user and visible in CLI and Web-UI interface.
  2. Implicit security policies are rules that are not visible to the user via CLI interface or Web-UI interface. The following section discusses implicit security policies on Palo Alto Networks firewalls.

 

Implicit security policies

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

 

Sessions

The Palo Alto Networks firewall is a stateful firewall, meaning all traffic passing through the firewall is matched against a session and each session is then 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 endpoint where traffic initiates is always the Client, and the endpoint where traffic is destined is the Server. For defining security policies, only the c2s flow direction needs to be considered. Define policies that allow or deny traffic from the originating zone to the destination zone, that is, in the c2s direction. The return flow, s2c, doesn't require a new rule. The security policy evaluation on the firewall occurs sequentially from top to bottom in the list, so traffic matching the first closest rule in the list applies to the session.

 

Here's an example of how to identify 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

 

Topology

In this document, the following topology applies to use cases of security policies:

Screen+Shot+2014-06-26+at+8.25.25+AM.png

 

Service "application-default"

 

In the example below, security policies allow and deny traffic matching the following criteria.

  • Rule A: All applications initiated from the Trust zone in IP subnet 192.168.1.0/24 destined to the 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 the Untrust zone must be allowed.
  • The applications should be restricted to use only at the "application-default" ports. For example, the DNS application, by default, uses destination port 53. So the DNS application should be allowed only on this port. Using this application on the remaining destination ports should be denied.
  • Rule C: All other applications from 192.168.1.3 to the Untrust zone must be blocked.
  • Rule D: All traffic initiated from the Untrust zone to any zones should be blocked.

 

The Service column in the security policies defines the source and destination ports where traffic should be allowed. The four options are:

  1. Application-default: To allow traffic on the default destination ports.
    Refer to the following document for more details about finding default destination ports used by various applications:
    please see: 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 example shows rules that are created to match the above criteria.

shinji.png

 

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

Screen Shot 2014-06-26 at 9.36.41 AM.png

The impact of shadow warnings and tips for avoiding them are discussed next.

 

Shadowing of rules

In the above example, the IP address 192.168.1.3 belongs to the 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 IP 192.168.1.3 matches Rule A and will be applied to the session. Although the traffic also satisfies the criteria of Rule B and Rule C, these rules will not be applied to this traffic because Rule A is shadowing Rule B and Rule C.

 

To avoid the impact of shadowing, Rule B and Rule C should precede Rule A, as shown below. Now the traffic matches against the correct rules and prevents "shadow warnings" during the commit.

Screen Shot 2014-07-18 at 1.56.08 PM.png

 

Security policies based on users

In the above example, policies are written based on 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 following documents for more details on how to configure User-ID and add the users to the security policies:

Getting Started: User-ID

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 following 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 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 the Untrust zone must be allowed.

 

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

Screen Shot 2014-08-04 at 6.00.18 PM.png

 

All traffic destined to the Web Server from the Untrust zone will have a destination public IP of 192.0.2.1, which belongs to the Untrust zone. Since the traffic is originating from the 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 doesn't happen yet. After determining the information of the final destination zone for the post NAT traffic, the firewall does 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: 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. Otherwise, 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 following example, security policies are defined to allow and deny traffic matching the following criteria.

  1. Applications Gotomeeting, Youtube from the Trust zone to Untrust zone should be allowed.
  2. Applications Facebook,Gmail-base from the Guest zone to the Untrust zone should be allowed.
  3. Applications SSL and Web-Browsing should be blocked for the Guest zone users.

 

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

Screen Shot 2014-07-18 at 2.27.17 PM.png

 

While committing the configuration changes, the following application dependency warnings may be viewed.

Screen Shot 2014-06-26 at 11.07.41 AM.png

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 matching the new application. So in the above case, SSL and web-browsing are called dependent applications for Gotomeeting and YouTube, 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 rematches the traffic against the security policies to find the new closest matching policy.

Screen Shot 2014-07-18 at 3.00.38 PM.png

In the above example, a new security policy, "Dependency Apps rule," is created to allow the SSL and web-browsing. Youtube traffic initially matches this rule and once the application shift happens, a second security policy lookup is matches against Rule 10.

 

Since PAN-OS 5.0, applications for some protocols can be allowed without the need to explicitly allow their dependencies (see: How to Check if an Application Needs to have Explicitly Allowed Dependency Apps). In the above example, Facebook and gmail-base are such applications that depend on SSL and web-browsing and don'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 it. The firewall makes uses 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 SSL decryption must be configured to get visibility into the URL of the website. Refer to the following document on How to Implement and Test SSL Decryption

 

Clean-up rule

Some environments require logging all traffic denied and allowed 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:

Any/Any/Deny Security Rule Changes Default Behavior

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 and destination address
  2. Source ports and destination ports
  3. Applications
  4. User-ID
  5. URL category
  6. Source and destination zones

 

Screen Shot 2014-07-18 at 3.19.35 PM.png

In the above configuration example, when application "web-browsing" on TCP port 80 from the Trust zone to the 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 rules.
  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 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

How to Schedule Policy Actions

Security Policy Management with Panorama

Session Log Best Practice

 

owner: sdurga

Comments
by pulukas
on ‎08-05-2014 06:12 PM

This is a great and well organized general introduction.  I especially like the resources for further reference too.

Well done.

by brucegarlock
on ‎06-27-2015 02:50 PM

A must read for a PA admin.  This is a pre-req for any other PA documents.

by strobins
on ‎11-10-2015 06:16 PM

Ok, this is a good read. however, I'm confused as to why under " Security Tips"  that the second point " 2.

  • Source ports and destination ports - Since Rule A, B, and C have "any" services, the traffic matches all these rules.", but C has the service as application-default" can someone exlain why this would match?

 

by bantam
on ‎09-19-2016 03:25 PM

The NATing section has an incorrect screenshot. The IP address under consideration in the text ends in .1 but the screenshot shows the last octet as .10.

by RamBista1
on ‎12-14-2016 10:35 AM

I think this statement "Implicit security policies are rules that are not visible to the user via CLI interface or Web-UI interface." should be changed now with newer PANOS code > 7.0.1. Correct? 

by cloudit24
on ‎01-28-2017 04:50 PM

Very well written article.

Thank you

Atif

 

by Mateusz
on ‎03-17-2017 12:42 AM

I am a little disappointed. I hit this page because I'm looking for answers to the relationship between the rules. It is a pity that nowhere on the PA pages there isn't an advanced example of fw security polices.

 

I have firewall security polices from LAN to WAN ( Identify users after LDAP AD ) with:

- 1 rule (allow from server's services from win, linux servers with sec.group profile) I also have to use the non-decripting rule for part of this traffice (goverment app don't like change of sing cert).
- 2 rule (allow administrators traffic from their PCs with sec.group profile)
- 3 rule (allow teamviewer app. and dep. app. like ssl, web-br for AD teamviewer group) Most of delivered app have included remonte app support and users do what they want by letting foreign teams to lan networks.
- 4 rule (allow anydesk app. and dep. app. like ssl for AD anydesk group)
- 5 rule (allow facebook app. and dep. app. like ssl,web-br .... for AD facebook group)
- 6 rule (allow dropbox app. and dep. app. like ssl,web-br .... for AD dropbox group)
- 7 rule (allow wetrransfer.....)
- 8 rule (allow skype .... like above
- 9 block applications (those allowed above and others app.)
- 10 allow ssl and web-brousing for all users withsec.group profile
- 11 rule blocks all traffic from the local network to wan

 

And now the problem

 

All web / ssl traffic for facebook(expl) users goes by fecebook rule rather than rule 10.
I have scaled rule 10 between 2 and 3 and remove dep. app from app allow rule (3-8) but  all rules still shout that they need dependencies app. (ssl and web-br) because unnecessary traffic is deny in 11 rule. 

 

What am I doing wrong?

 

My PA is 7.1.4 and from 3 day 8.0. 

 

Mateusz

by pkawula
on ‎03-28-2017 01:03 PM

I am curious as the Security Policy Tips section lists Zones as the last component checked in a security policy, yet the documentation from Palo Alto says that policies are applied left to right, top to bottom. Which would mean Zone would be applpied first. 

 

https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/policy/security-policy

 

I would appreciate if someone could help me understand that...

by slevine
on ‎04-04-2017 02:00 PM

Good article, but there's an unexplained config change buried in the "rule shadowing" example. You not only resequenced the rules (no questions there), for Rule A, you also changed the source address from 192.168.1.0 to "any", but you did not describe why you did that or what the consequences would be of retaining 192.168.1.0 as the source address. (I don't think 192.168.1.3 shadows 192.168.1.0; but if there are no consequences for using the IP address, then why change to "any"?) 

Learn more
Ask Questions Get Answers Join the Live Community
Contributors