Building Blocks in a Security Policy Rule

The following section describes each component in a Security policy rule. When you create a Security policy rule, you can configure the options described here.
Building Blocks in a Security Rule
Configured In
Rule number
Each rule is automatically numbered and the order changes as rules are moved. When you filter rules to match specific filter(s), each rule is listed with its number in the context of the complete set of rules in the rulebase and its place in the evaluation order.
In Panorama, pre-rules and post-rules are independently numbered. When rules are pushed from Panorama to a managed firewall, the rule numbering incorporates hierarchy in pre-rules, firewall rules, and post-rules within a rulebase and reflects the rule sequence and its evaluation order.
Enter a name to identify the rule. The name is case-sensitive and can have up to 31 characters, which can be letters, numbers, spaces, hyphens, and underscores. The name must be unique on a firewall and, on Panorama, unique within its device group and any ancestor or descendant device groups.
and specify the tag for the policy.
A policy tag is a keyword or phrase that allows you to sort or filter policies. This is useful when you have defined many policies and want to view those that are tagged with a particular keyword. For example, you may want to tag certain rules with specific words like Decrypt and No-decrypt, or use the name of a specific data center for policies associated with that location.
You can also add tags to the default rules.
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
source zones (default is
). Zones must be of the same type (Layer 2, Layer 3, or virtual wire). To define new zones, refer to Network > Zones.
Multiple zones can be used to simplify management. For example, if you have three different internal zones (Marketing, Sales, and Public Relations) that are all directed to the untrusted destination zone, you can create one rule that covers all cases.
Source Address
source addresses, address groups, or regions (default is
). Select from the drop-down or select
Address Group
, or
(bottom of the drop-down) to specify the settings.
Source User
the source users or groups of users subject to the policy. The following source user types are supported:
  • any
    —Includes any traffic regardless of user data.
  • pre-logon
    —Includes remote users that are connected to the network using GlobalProtect, but are not logged into their system. When the Pre-logon option is configured on the Portal for GlobalProtect endpoints, any user who is not currently logged into their machine will be identified with the username pre-logon. You can then create policies for pre-logon users and although the user is not logged in directly, their machines are authenticated on the domain as if they were fully logged in.
  • known-user
    —Includes all authenticated users, which means any IP with user data mapped. This option is equivalent to the domain users group on a domain.
  • unknown
    —Includes all unauthenticated users, which means IP addresses that are not mapped to a user. For example, you could use
    for guest level access to something because they will have an IP on your network but will not be authenticated to the domain and will not have IP to user mapping information on the firewall.
  • Select
    —Includes selected users as determined by the selection in this window. For example, you may want to add one user, a list of individuals, some groups, or manually add users.
If the firewall collects user information from a RADIUS, TACACS+, or SAML identity provider server and not from the User-ID™ agent, the list of users does not display; you must enter user information manually.
Source HIP Profile
host information profiles (HIP) to collect information about the security status of your end hosts, such as whether they have the latest security patches and antivirus definitions installed. Using host information profiles for policy enforcement enables granular security that ensures that the remote hosts accessing your critical resources are adequately maintained and in adherence with your security standards before they are allowed to access your network resources. The following source HIP profiles are supported:
  • any
    —Includes any endpoint, regardless of HIP information.
  • select
    —Includes selected HIP profiles as determined by your configuration. For example, you can add one HIP profile, a list of HIP profiles, or you can add HIP profiles manually.
  • no-hip
    —HIP information is not required. This setting enables access from third-party clients that cannot collect or submit HIP information.
Destination Zone
destination zones (default is
). Zones must be of the same type (Layer 2, Layer 3, or virtual wire). To define new zones, refer to Network > Zones.
Multiple zones can be used to simplify management. For example, if you have three different internal zones (Marketing, Sales, and Public Relations) that are all directed to the untrusted destination zone, you can create one rule that covers all cases.
On intrazone rules, you cannot define a Destination Zone because these types of rules match only traffic with a source and a destination within the same zone. To specify the zones that match an intrazone rule you need to specify only the Source Zone.
Destination Address
destination addresses, address groups, or regions (default is
). Select from the drop-down or click
(bottom of the drop-down) to specify address settings.
Select specific applications for the Security policy rule. If an application has multiple functions, you can select the overall application or individual functions. If you select the overall application, all functions are included and the application definition is automatically updated as future functions are added.
If you are using application groups, filters, or containers in the Security policy rule, you can view details of these objects by hovering over the object in the Application column, opening the drop-down, and selecting
. This allows you to view application members directly from the policy without having to navigate to the
Always specify one or more applications so that only applications you want on your network are allowed, which reduces the attack surface and gives you greater control over network traffic. Don’t set the application to
, which allows any application’s traffic and increases the attack surface.
Service/URL Category
Select the services that you want to limit to specific TCP or UDP port numbers. Choose one of the following from the drop-down:
  • any
    —The selected applications are allowed or denied on any protocol or port.
  • application-default
    —The selected applications are allowed or denied only on their default
    ports defined by Palo Alto Networks
    ®. This option is recommended for allow policies because it prevents applications from running on unusual ports and protocols which, if unintentional, can be a sign of undesired application behavior and usage.
When you use this option, the firewall still checks for all applications on all ports, but applications are only allowed on their default ports and protocols.
For most applications, use
to prevent the application from using non-standard ports or exhibiting other evasive behaviors. If the default port for the application changes, the firewall automatically updates the rule to the correct default port. For applications that use non-standard ports, such as internal custom applications, either modify the application or create a rule that specifies the non-standard ports and apply the rule only to the traffic that requires the application.
URL Category
Select URL categories for the security rule.
  • Choose
    to allow or deny all sessions regardless of the URL category.
  • To specify a category,
    one or more specific categories (including custom categories) from the drop-down. Select Objects > External Dynamic Lists to define custom categories.
To specify the action for traffic that matches the attributes defined in a rule, select from the following actions:
  • Allow
    —(default) Allows the matched traffic.
  • Deny
    —Blocks matched traffic and enforces the default
    Deny Action
    defined for the application that is denied. To view the deny action defined by default for an application, view the application details (
Because the default deny action varies by application, the firewall could block the session and send a reset for one application while it silently drops the session for another application.
  • Drop
    —Silently drops the application. A TCP reset is not sent to the host or application unless you select
    Send ICMP Unreachable
  • 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.
  • Send ICMP Unreachable
    —Available only for Layer 3 interfaces. When you configure Security policy rule to drop traffic or to reset the connection, the traffic does not reach the destination host. In such cases, for all UDP traffic and for TCP traffic that is dropped, you can enable the firewall to send an ICMP Unreachable response to the source IP address from where the traffic originated. Enabling this setting allows the source to gracefully close or clear the session and prevents applications from breaking.
To view the ICMP Unreachable Packet Rate configured on the firewall, view Session Settings (
To override the default action defined on the predefined interzone and intrazone rules: see Overriding or Reverting a Security Policy Rule.
Profile Setting
To specify the additional checking that the firewall performs on packets that match the Security profile rule, select individual Antivirus, Anti-Spyware, Vulnerability Protection, URL Filtering, File Blocking, Data Filtering, WildFire Analysis, GTP Protection, and SCTP Protection profiles.
To specify a profile group rather than individual profiles, select
Profile Type Group
and then select a
Group Profile
To define new profiles or profile groups, click
next to the appropriate profile or group (refer to Objects > Security Profiles > GTP Protection).
You can also attach Security Profiles (or profile groups) to the default rules.
tab includes the logging settings and a combination of other options listed below.
To generate entries in the local traffic log for traffic that matches this rule, select the following options:
  • Log At Session Start
    (disabled by default)—Generates a traffic log entry for the start of a session.
    Don’t enable
    Log at Session Start
    except for troubleshooting purposes or for tunnel session logs to show active GRE tunnels in the ACC. Logging at the session end consumes fewer resources and identifies the exact application if the application changes after a few packets, for example, from facebook-base to facebook-chat.
  • Log At Session End
    (enabled by default)—Generates a traffic log entry for the end of a session.
If the session start or end entries are logged, drop and deny entries are also logged.
  • Log Forwarding Profile
    —To forward the local traffic log and threat log entries to remote destinations, such as Panorama and syslog servers, select a
    Log Forwarding Profile
The generation of threat log entries is determined by the Security Profiles. Define
log profiles as needed (refer to Objects > Log Forwarding).
Create and enable Log Forwarding profiles to send logs to dedicated external storage devices. This preserves the logs because the firewall has limited log storage space and when the space is consumed, the firewall purges the oldest logs.
You can also modify the log settings on the default rules. Specify any combination of the following options:
  • Schedule
    —To limit the days and times when the rule is in effect, select a schedule from the drop-down. Define
    schedules as needed (refer to Settings to Control Decrypted SSL Traffic).
  • QoS Marking
    —To change the Quality of Service (QoS) setting on packets matching the rule, select
    IP Precedence
    and enter the QoS value in binary form or select a predefined value from the drop-down. For more information on QoS, refer to Quality of Service TechDocs_logo_cropped.png .
  • Disable Server Response Inspection
    —Disables packet inspection from the server to the client. The option is disabled by default.
    For the best security posture, do not enable
    Disable Server Response Inspection
    . With this option selected, the firewall only inspects the client-to-server flows. It does not inspect the server-to-client flows and therefore cannot identify if there are any threats in these traffic flows.
Enter a description for the policy (up to 255 characters).

Related Documentation