Components of a Security Policy Rule
Table of Contents
Expand All
|
Collapse All
Next-Generation Firewall Docs
-
PAN-OS 11.1 & Later
- PAN-OS 11.1 & Later
- PAN-OS 11.0 (EoL)
- PAN-OS 10.2
- PAN-OS 10.1
- PAN-OS 10.0 (EoL)
- PAN-OS 9.1 (EoL)
- Cloud Management of NGFWs
-
- Management Interfaces
-
- Launch the Web Interface
- Use the Administrator Login Activity Indicators to Detect Account Misuse
- Manage and Monitor Administrative Tasks
- Commit, Validate, and Preview Firewall Configuration Changes
- Commit Selective Configuration Changes
- Export Configuration Table Data
- Use Global Find to Search the Firewall or Panorama Management Server
- Manage Locks for Restricting Configuration Changes
-
-
- Define Access to the Web Interface Tabs
- Provide Granular Access to the Monitor Tab
- Provide Granular Access to the Policy Tab
- Provide Granular Access to the Objects Tab
- Provide Granular Access to the Network Tab
- Provide Granular Access to the Device Tab
- Define User Privacy Settings in the Admin Role Profile
- Restrict Administrator Access to Commit and Validate Functions
- Provide Granular Access to Global Settings
- Provide Granular Access to the Panorama Tab
- Provide Granular Access to Operations Settings
- Panorama Web Interface Access Privileges
-
- Reset the Firewall to Factory Default Settings
-
- Plan Your Authentication Deployment
- Pre-Logon for SAML Authentication
- Configure SAML Authentication
- Configure Kerberos Single Sign-On
- Configure Kerberos Server Authentication
- Configure TACACS+ Authentication
- Configure TACACS Accounting
- Configure RADIUS Authentication
- Configure LDAP Authentication
- Configure Local Database Authentication
- Configure an Authentication Profile and Sequence
- Test Authentication Server Connectivity
- Troubleshoot Authentication Issues
-
- Keys and Certificates
- Default Trusted Certificate Authorities (CAs)
- Certificate Deployment
- Configure the Master Key
- Export a Certificate and Private Key
- Configure a Certificate Profile
- Configure an SSL/TLS Service Profile
- Configure an SSH Service Profile
- Replace the Certificate for Inbound Management Traffic
- Configure the Key Size for SSL Forward Proxy Server Certificates
-
- HA Overview
-
- Prerequisites for Active/Active HA
- Configure Active/Active HA
-
- Use Case: Configure Active/Active HA with Route-Based Redundancy
- Use Case: Configure Active/Active HA with Floating IP Addresses
- Use Case: Configure Active/Active HA with ARP Load-Sharing
- Use Case: Configure Active/Active HA with Floating IP Address Bound to Active-Primary Firewall
- Use Case: Configure Active/Active HA with Source DIPP NAT Using Floating IP Addresses
- Use Case: Configure Separate Source NAT IP Address Pools for Active/Active HA Firewalls
- Use Case: Configure Active/Active HA for ARP Load-Sharing with Destination NAT
- Use Case: Configure Active/Active HA for ARP Load-Sharing with Destination NAT in Layer 3
- HA Clustering Overview
- HA Clustering Best Practices and Provisioning
- Configure HA Clustering
- Refresh HA1 SSH Keys and Configure Key Options
- HA Firewall States
- Reference: HA Synchronization
-
- Use the Dashboard
- Monitor Applications and Threats
- Monitor Block List
-
- Report Types
- View Reports
- Configure the Expiration Period and Run Time for Reports
- Disable Predefined Reports
- Custom Reports
- Generate Custom Reports
- Generate the SaaS Application Usage Report
- Manage PDF Summary Reports
- Generate User/Group Activity Reports
- Manage Report Groups
- Schedule Reports for Email Delivery
- Manage Report Storage Capacity
- View Policy Rule Usage
- Use External Services for Monitoring
- Configure Log Forwarding
- Configure Email Alerts
-
- Configure Syslog Monitoring
-
- Traffic Log Fields
- Threat Log Fields
- URL Filtering Log Fields
- Data Filtering Log Fields
- HIP Match Log Fields
- GlobalProtect Log Fields
- IP-Tag Log Fields
- User-ID Log Fields
- Decryption Log Fields
- Tunnel Inspection Log Fields
- SCTP Log Fields
- Authentication Log Fields
- Config Log Fields
- System Log Fields
- Correlated Events Log Fields
- GTP Log Fields
- Audit Log Fields
- Syslog Severity
- Custom Log/Event Format
- Escape Sequences
- Forward Logs to an HTTP/S Destination
- Firewall Interface Identifiers in SNMP Managers and NetFlow Collectors
- Monitor Transceivers
-
- User-ID Overview
- Enable User-ID
- Map Users to Groups
- Enable User- and Group-Based Policy
- Enable Policy for Users with Multiple Accounts
- Verify the User-ID Configuration
-
- App-ID Overview
- App-ID and HTTP/2 Inspection
- Manage Custom or Unknown Applications
- Safely Enable Applications on Default Ports
- Applications with Implicit Support
-
- Prepare to Deploy App-ID Cloud Engine
- Enable or Disable the App-ID Cloud Engine
- App-ID Cloud Engine Processing and Policy Usage
- New App Viewer (Policy Optimizer)
- Add Apps to an Application Filter with Policy Optimizer
- Add Apps to an Application Group with Policy Optimizer
- Add Apps Directly to a Rule with Policy Optimizer
- Replace an RMA Firewall (ACE)
- Impact of License Expiration or Disabling ACE
- Commit Failure Due to Cloud Content Rollback
- Troubleshoot App-ID Cloud Engine
- Application Level Gateways
- Disable the SIP Application-level Gateway (ALG)
- Maintain Custom Timeouts for Data Center Applications
-
- Decryption Overview
-
- Keys and Certificates for Decryption Policies
- SSL Forward Proxy
- SSL Forward Proxy Decryption Profile
- SSL Inbound Inspection
- SSL Inbound Inspection Decryption Profile
- SSL Protocol Settings Decryption Profile
- SSH Proxy
- SSH Proxy Decryption Profile
- Profile for No Decryption
- SSL Decryption for Elliptical Curve Cryptography (ECC) Certificates
- Perfect Forward Secrecy (PFS) Support for SSL Decryption
- SSL Decryption and Subject Alternative Names (SANs)
- TLSv1.3 Decryption
- High Availability Not Supported for Decrypted Sessions
- Decryption Mirroring
- Configure SSL Forward Proxy
- Configure SSL Inbound Inspection
- Configure SSH Proxy
- Configure Server Certificate Verification for Undecrypted Traffic
- Post-Quantum Cryptography Detection and Control
- Enable Users to Opt Out of SSL Decryption
- Temporarily Disable SSL Decryption
- Configure Decryption Port Mirroring
- Verify Decryption
- Activate Free Licenses for Decryption Features
-
- Policy Types
- Policy Objects
- Track Rules Within a Rulebase
- Enforce Policy Rule Description, Tag, and Audit Comment
- Move or Clone a Policy Rule or Object to a Different Virtual System
-
- External Dynamic List
- Built-in External Dynamic Lists
- Configure the Firewall to Access an External Dynamic List
- Retrieve an External Dynamic List from the Web Server
- View External Dynamic List Entries
- Exclude Entries from an External Dynamic List
- Enforce Policy on an External Dynamic List
- Find External Dynamic Lists That Failed Authentication
- Disable Authentication for an External Dynamic List
- Register IP Addresses and Tags Dynamically
- Use Dynamic User Groups in Policy
- Use Auto-Tagging to Automate Security Actions
- CLI Commands for Dynamic IP Addresses and Tags
- Application Override Policy
- Test Policy Rules
-
- Network Segmentation Using Zones
- How Do Zones Protect the Network?
-
PAN-OS 11.1 & Later
- PAN-OS 11.1 & Later
- PAN-OS 11.0 (EoL)
- PAN-OS 10.2
- PAN-OS 10.1
-
- Tap Interfaces
-
- Layer 2 and Layer 3 Packets over a Virtual Wire
- Port Speeds of Virtual Wire Interfaces
- LLDP over a Virtual Wire
- Aggregated Interfaces for a Virtual Wire
- Virtual Wire Support of High Availability
- Zone Protection for a Virtual Wire Interface
- VLAN-Tagged Traffic
- Virtual Wire Subinterfaces
- Configure Virtual Wires
- Configure a PPPoE Client on a Subinterface
- Configure an IPv6 PPPoE Client
- Configure an Aggregate Interface Group
- Configure Bonjour Reflector for Network Segmentation
- Use Interface Management Profiles to Restrict Access
-
- DHCP Overview
- Firewall as a DHCP Server and Client
- Firewall as a DHCPv6 Client
- DHCP Messages
- Dynamic IPv6 Addressing on the Management Interface
- Configure an Interface as a DHCP Server
- Configure an Interface as a DHCPv4 Client
- Configure an Interface as a DHCPv6 Client with Prefix Delegation
- Configure the Management Interface as a DHCP Client
- Configure the Management Interface for Dynamic IPv6 Address Assignment
- Configure an Interface as a DHCP Relay Agent
-
- DNS Overview
- DNS Proxy Object
- DNS Server Profile
- Multi-Tenant DNS Deployments
- Configure a DNS Proxy Object
- Configure a DNS Server Profile
- Use Case 1: Firewall Requires DNS Resolution
- Use Case 2: ISP Tenant Uses DNS Proxy to Handle DNS Resolution for Security Policies, Reporting, and Services within its Virtual System
- Use Case 3: Firewall Acts as DNS Proxy Between Client and Server
- DNS Proxy Rule and FQDN Matching
-
- NAT Rule Capacities
- Dynamic IP and Port NAT Oversubscription
- Dataplane NAT Memory Statistics
-
- Translate Internal Client IP Addresses to Your Public IP Address (Source DIPP NAT)
- Create a Source NAT Rule with Persistent DIPP
- PAN-OS
- Strata Cloud Manager
- Enable Clients on the Internal Network to Access your Public Servers (Destination U-Turn NAT)
- Enable Bi-Directional Address Translation for Your Public-Facing Servers (Static Source NAT)
- Configure Destination NAT with DNS Rewrite
- Configure Destination NAT Using Dynamic IP Addresses
- Modify the Oversubscription Rate for DIPP NAT
- Reserve Dynamic IP NAT Addresses
- Disable NAT for a Specific Host or Interface
-
- Network Packet Broker Overview
- How Network Packet Broker Works
- Prepare to Deploy Network Packet Broker
- Configure Transparent Bridge Security Chains
- Configure Routed Layer 3 Security Chains
- Network Packet Broker HA Support
- User Interface Changes for Network Packet Broker
- Limitations of Network Packet Broker
- Troubleshoot Network Packet Broker
-
- Enable Advanced Routing
- Logical Router Overview
- Configure a Logical Router
- Create a Static Route
- Configure BGP on an Advanced Routing Engine
- Create BGP Routing Profiles
- Create Filters for the Advanced Routing Engine
- Configure OSPFv2 on an Advanced Routing Engine
- Create OSPF Routing Profiles
- Configure OSPFv3 on an Advanced Routing Engine
- Create OSPFv3 Routing Profiles
- Configure RIPv2 on an Advanced Routing Engine
- Create RIPv2 Routing Profiles
- Create BFD Profiles
- Configure IPv4 Multicast
- Configure MSDP
- Create Multicast Routing Profiles
- Create an IPv4 MRoute
-
-
PAN-OS 11.2
- PAN-OS 11.2
- PAN-OS 11.1
- PAN-OS 11.0 (EoL)
- PAN-OS 10.2
- PAN-OS 10.1
- PAN-OS 10.0 (EoL)
- PAN-OS 9.1 (EoL)
- PAN-OS 9.0 (EoL)
- PAN-OS 8.1 (EoL)
- Cloud Management and AIOps for NGFW
Components of a Security Policy Rule
The Security policy rule construct permits a combination
of the required and optional fields as detailed in the following
table. Details about using a wildcard address object in a source
or destination address follow the table.
Required/Optional | Field | Description |
---|---|---|
Required | Name | A label (up to 63 characters) that identifies
the rule. |
UUID | The Universally Unique Identifier (UUID)
is a distinct 32-character string that permanently identifies rules
so that you can track a rule regardless of any changes to it, such
as the name. | |
Rule Type | Specifies whether the rule applies to traffic
within a zone, between zones, or both:
| |
Source Zone | The zone from which the traffic originates. | |
Destination Zone | The zone at which the traffic terminates.
If you use NAT, make sure to always reference the post-NAT zone. | |
Application | The application that you wish to control.
The firewall uses App-ID, the traffic classification technology,
to identify traffic on your network. App-ID provides application
control and visibility in creating security policies that block
unknown applications, while enabling, inspecting, and shaping those
that are allowed. | |
Action | Specifies an Allow or Deny action
for the traffic based on the criteria you define in the rule. When
you configure the firewall to deny traffic, it either resets the connection
or silently drops packets. To provide a better user experience,
you can configure granular options to deny traffic instead of silently
dropping packets, which can cause some applications to break and
appear unresponsive to the user. For more details, see Security
Policy Actions. | |
Optional | Tag | A keyword or phrase that allows you to filter
security rules. This is handy when you have defined many rules and
wish to then review those that are tagged with a keyword such as IT-sanctioned
applications or High-risk applications. |
Description | A text field, up to 1024 characters, used
to describe the rule. | |
Source Address | Define host IP addresses, subnets, address objects (of
type IP netmask, IP range, FQDN, or IP wildcard mask), address groups,
or country-based enforcement. If you use NAT, make sure to always
refer to the original IP addresses in the packet (i.e. the pre-NAT
IP address). Details about IP wildcard mask follow this table. | |
Destination Address | The location or destination for the packet.
Define IP addresses, subnets, address objects (of
type IP netmask, IP range, FQDN, or IP wildcard mask), address groups,
or country-based enforcement. If you use NAT, make sure to always refer
to the original IP addresses in the packet (i.e. the pre-NAT IP address).
Details about IP wildcard mask follow this table. | |
User | The user or group of users for whom the
policy applies. You must have User-ID enabled on the zone. To enable
User-ID, see User-ID
Overview. | |
URL Category | Using the URL Category as match criteria
allows you to customize security profiles (Antivirus, Anti-Spyware,
Vulnerability, File-Blocking, Data Filtering, and DoS) on a per-URL-category
basis. For example, you can prevent.exe file download/upload for
URL categories that represent higher risk while allowing them for
other categories. This functionality also allows you to attach schedules
to specific URL categories (allow social-media websites during lunch
& after-hours), mark certain URL categories with QoS (financial, medical,
and business), and select different log forwarding profiles on a
per-URL-category-basis. Although you can manually configure
URL categories on your firewall, to take advantage of the dynamic
URL categorization updates available on Palo Alto Networks firewalls,
you must purchase a URL filtering license. To block
or allow traffic based on URL category, you must apply a URL Filtering
profile to the security policy rules. Define the URL Category as
Any and attach a URL Filtering profile to the security policy. See Set Up a Basic Security
Policy for information on using the default profiles in your
security policy. | |
Service | Allows you to select a Layer 4 (TCP or UDP)
port for the application. You can choose any, specify
a port, or use application-default to permit use of
the standards-based port for the application. For example, for applications
with well-known port numbers such as DNS, the application-default option
will match against DNS traffic only on TCP port 53. You can also
add a custom application and define the ports that the application
can use. For inbound allow rules (for example, from untrust
to trust), using application-default prevents applications from running
on unusual ports and protocols. Application-default is the default
option; while the firewall still checks for all applications on
all ports, with this configuration, applications are only allowed
on their standard ports/protocols. | |
Security Profiles | Provide additional protection from threats,
vulnerabilities, and data leaks. Security profiles are evaluated
only for rules that have an allow action. | |
HIP Profile (for GlobalProtect) | Allows you to identify clients with Host
Information Profile (HIP) and then enforce access privileges. | |
Options | Allow you to define logging for the session,
log forwarding settings, change Quality of Service (QoS) markings
for packets that match the rule, and schedule when (day and time)
the security rule should be in effect. |
This section describes the use of a wildcard address object in
a Source Address or Destination Address of a Security policy rule.
When you assign private IPv4 addresses to internal devices, you
can use an IP addressing structure that assigns meaning to certain
bits in the address. For example, the first three bits in the third
octet of an IP address signify the device type. This structure helps
you easily identify details about a device, such as device type
or location, based on the IP address of the device. You can use
this same IP addressing structure in Security policy rules for easier
deployment. You create an address object that uses
a wildcard address (IP address and wildcard mask separated by a
slash, such as 10.1.2.3/0.127.248.0). A wildcard address can identify
many source or destination addresses in a single Security policy
rule, which is especially helpful for data center firewalls serving
many devices. You won’t have to manage an unnecessarily large number
of address objects to cover all the matching IP addresses or use
less restrictive Security policy rules than you need due to IP address
capacity constraints.
For example, suppose you use the IPv4 addressing scheme shown
in the following figure where the first octet represents your organization
(bits 00001010 are fixed). In the second octet, the first four bits
designate the country where the network device is located (1000
indicates the U.S.) and the last four bits indicate the region (0100
indicates the northeast). In the third octet, the first four bits
are zeros and the last four bits indicate device type (0001 indicates
cash register and 0011 indicates printer). The last octet indicates the
ID number of the networking device.

Based on that structure, the IP address of cash register number
156 in the northeastern U.S. would be 10.132.1.156:

You can use an address object of type IP Wildcard
Mask to support such an addressing structure in a Security
policy rule. You apply a wildcard mask to an IPv4 source or destination
address to specify which addresses are subject to the rule. In a
Palo Alto Networks wildcard mask, a zero bit indicates that the
bit being compared must match the bit in the IP address that is
covered by the zero. A one bit in the mask is a wildcard or “ignore”
bit, meaning the bit being compared need not match the bit in the IP
address. For example, the following snippets of an IP address and
wildcard mask illustrate how they yield four matches:

Not all vendors use a one as a wildcard bit and a zero
as a matching bit.
In the example, cash registers have an IPv4 address with the
third octet 00000001 and printers have an IPv4 address with the
third octet 00000011. Suppose you want to apply a Security policy
rule to all cash registers and printers having any ID number from
0 to 255. To get that result, you need a wildcard mask; the third
octet of the wildcard mask must be 2 and the device ID (the fourth
octet) must be 255. The address object to specify all cash registers
and printers in the northeastern U.S. would use wildcard address 10.132.1.2/0.0.2.255:

Thus, a single Security policy rule that uses an address object
with wildcard address 10.132.1.2/0.0.2.255 as the destination address
matches the addresses of 512 devices (256 cash registers + 256 printers),
which is an efficient way to apply a rule to many devices. The wildcard
mask must begin with at least one zero (0), such as 0.0.2.255.
Consider the following when you use an address object of type IP
Wildcard Mask in a Security policy rule:
- A source or destination address that uses an address object of type IP Wildcard Mask doesn’t support the Negate option.
- The firewall doesn’t consider wildcard addresses when doing shadow matching, which means you won’t be warned if a Security policy rule using an address object of type IP Wildcard Mask overlaps a subsequent rule or is overlapped by a rule higher on the list.
- If an address matches rules that have overlapping wildcard masks, the firewall chooses the match to the longest prefix in the wildcard mask, as shown in the following figure:

The preceding bullet describes the default behavior. However,
there are use cases where you want to have broad rules that allow
some sources access to generic applications (such as Ping, Traceroute,
and web-browsing), but have narrower rules that allow a subset of
these sources access to different applications (such as SSH, SCP)
in addition to the generic applications. In earlier releases, such
a deployment did not work because only the match to the rule with
the longest prefix in the wildcard mask was processed and other rules
were not considered.
Beginning with PAN-OS 10.2.1, you can enable Wildcard
Top Down Match Mode so that if a packet with an IP address
matches prefixes in Security policy rules that have overlapping
wildcard masks, the firewall chooses the first fully matching rule
in top-down order (instead of choosing the matching rule with the
longest prefix in a wildcard mask). A packet is found to match the
prefix in rules that use overlapping wildcard masks; then the firewall
chooses those rules that fully match all address bits based on masking,
keeping in mind the ones in the mask indicate wildcard or “ignore”
bits. Then other rule criteria, such as application and zones, are
examined. During the other rule criteria examination, the firewall
chooses the first of those rules (in top-down order) that match
the criteria. No other rules are evaluated.
The Wildcard Top Down Match Mode means
that more than one rule has the potential to be enforced on different
packets (not just the rule with the longest matching prefix). Place
your more specific rules toward the top of the list. For example,
you can allow a smaller range of matching addresses (a longer wildcard
mask) to access certain applications, and also, in a subsequent
rule allow a larger range of IP addresses (a shorter wildcard mask)
to access a different (more generic) set of applications. You can
enable Wildcard Top Down Match Mode by selecting DeviceSetupManagement and
editing the Policy Rulebase Settings.
The following example has Wildcard Top Down Match
Mode enabled and three Security policy rules, each specifying
a source IP address with wildcard mask address object, and the wildcard
masks overlap:

In this example, Client A with source IP address 10.143.8.1 (0000
1010 1000 1111 0000 1000 0000 0001) fully matches Rule 1, Rule 2,
and Rule 3; the first match is to Rule 1 (top-down order). Assuming
other rule criteria match, the packet from Client A is subject to
the Rule 1 action.
Client B with source IP address 10.160 2.1 (0000 1010 1010 0000
0000 0010 0000 0001) does not fully match the address in Rule 1
and does not match the prefix in Rule 2. Client B’s address fully
matches Rule 3, which is the first matching rule in top-down order.
Assuming other rule criteria match, the packet from Client B is
subject to the Rule 3 action. Thus we see the benefit of Wildcard
Top Down Match Mode, that both Rule 1 and Rule 3 can
be in effect on different packets.