Security Rules
Focus
Focus

Network Security

Security Rules

Table of Contents

Security Rules

Where Can I Use This?
What Do I Need?
  • NGFW (Cloud Managed)
  • NGFW (PAN-OS & Panorama Managed)
  • Prisma Access (Cloud Management)
  • Prisma Access (Panorama Managed)
Check for any license or role requirements for the products you're using:
  • Prisma Access
    license or AIOps for NGFW license
  • Additionally, certain features may require Advanced WildFire, Advanced URL Filtering, Advanced Threat Prevention, or DNS Security license
Security policy protects network assets from threats and disruptions and helps to optimally allocate network resources for enhancing productivity and efficiency in business processes. Individual Security policy rules determine whether to block or allow a session based on traffic attributes, such as the source and destination security zone, the source and destination IP address, the application, the user, and the service.
All traffic passing through your environment is matched against a session and each session is matched against a Security policy rule. When a session match occurs, the Security policy rule is applied to bidirectional traffic in that session (client to server and server to client). For traffic that doesn’t match any defined rules, the default rules apply. The default rules—displayed at the bottom of the security rulebase—are predefined to allow all intrazone traffic (within a zone) and deny all interzone traffic (between zones). Although these rules are part of the predefined configuration and are read-only by default, you can override them and change a limited number of settings, including the tags, action (allow or block), log settings, and security profiles.
Security policy rules are evaluated left to right and from top to bottom. A packet is matched against the first rule that meets the defined criteria and, after a match is triggered, subsequent rules are not evaluated. Therefore, the more specific rules must precede more generic ones in order to enforce the best match criteria. Traffic that matches a rule generates a log entry at the end of the session in the traffic log if you enable logging for that rule. The logging options are configurable for each rule and can, for example, be configured to log at the start of a session instead of, or in addition to, logging at the end of a session.
After an administrator configures a rule, you can track it in your rulebase and view policy rule usage to determine when and how many times traffic matches the Security policy rule to determine its effectiveness. As your rulebase evolves, change and audit information can get lost over time unless you archived this information at the time the rule is created or modified. You can Enforce Policy Rule Description, Tag, and Audit Comment to ensure that all administrators enter audit comments so that you can view the audit comment archive and review comments and configuration log history and can compare rule configuration versions for a selected rule. Together, you now have more visibility into and control over the rulebase.
A network configuration can have a maximum of 10,000 security policy rules.

Components of a Security Rule

The Security policy rule permits a combination of the required and optional fields as detailed in the following table.
Required/Optional
Field
Description
Required
Name
A label (up to 63 characters) that identifies the rule.
UUID
(for Panorama and PAN-OS only)
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 App-ID is used, the traffic classification technology, to identify traffic on your network. App-ID provides application control and visibility in creating security policy rules 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 your environment 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 Rule 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 1,024 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).
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).
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 to take advantage of the dynamic URL categorization updates available, 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.
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 checks are still performed for all applications on all ports, with this configuration, applications are only allowed on their standard ports/protocols.
Provide additional protection from threats, vulnerabilities, and data leaks. Security profiles are evaluated only for rules that have an allow action.
(
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.

Security Rule Actions

For traffic that matches the attributes defined in a security policy, you can apply the following actions:
Action
Description
Allow
(default)
Allows the traffic.
Deny
Blocks traffic and enforces the default Deny Action defined for the application that is being denied.
Drop
Silently drops the traffic; for an application, it overrides the default deny action. A TCP reset isn't sent to the host/application.
For Layer 3 interfaces, to optionally send an ICMP unreachable response to the client, set Action:
Drop
and enable the
Send ICMP Unreachable
check box. When enabled, the ICMP code is sent for communication with the destination is administratively prohibited—ICMPv4: Type 3, Code 13; ICMPv6: Type 1, Code 1.
Reset client
Sends a TCP reset to the client-side device.
Reset server
Sends a TCP reset to the server-side device.
Reset both
Sends a TCP reset to both the client-side and server-side devices.
A reset is sent only after a session is formed. If the session is blocked before a 3-way handshake is completed, the reset won't be sent.
For a TCP session with a reset action, an ICMP Unreachable response isn't sent.
For a UDP session with a drop or reset action, if the
ICMP Unreachable
check box is selected, an ICMP message to the client is sent.

Recommended For You