Network Security
Security Rules
Table of Contents
Expand All
|
Collapse All
Network Security Docs
Security Rules
| Where Can I Use This? | What Do I Need? |
|---|---|
|
|
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 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 rule. When a session match occurs, the
Security 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 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.
A network configuration can have a maximum of 10,000 security rules.
Components of a Security Rule
The Security 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:
| |
|
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 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 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.
| ||
|
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.
|
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.
| |