Components of a Security Policy Rule
Focus
Focus

Components of a Security Policy Rule

Table of Contents

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:
  • universal (default)—Applies the rule to all matching interzone and intrazone traffic in the specified source and destination zones. For example, if you create a universal rule with source zones A and B and destination zones A and B, the rule would apply to all traffic within zone A, all traffic within zone B, and all traffic from zone A to zone B and all traffic from zone B to zone A.
  • intrazone—Applies the rule to all matching traffic within the specified source zones (you cannot specify a destination zone for intrazone rules). For example, if you set the source zone to A and B, the rule would apply to all traffic within zone A and all traffic within zone B, but not to traffic between zones A and B.
  • interzone—Applies the rule to all matching traffic between the specified source and destination zones. For example, if you set the source zone to A, B, and C and the destination zone to A and B, the rule would apply to traffic from zone A to zone B, from zone B to zone A, from zone C to zone A, and from zone C to zone B, but not traffic within zones A, B, or C.
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.