PAN‐OS Administrator’s Guide Policy

Policy

PAN‐OS

Administrator’s

Guide

Version 7.1

Copyright © 2007-2015 Palo Alto Networks

Contact Information

Corporate Headquarters:

Palo Alto Networks

4401 Great America Parkway

Santa Clara, CA 95054 www.paloaltonetworks.com/company/contact‐us

About this Guide

This guide takes you through the configuration and maintenance of your Palo Alto Networks next‐generation firewall. For additional information, refer to the following resources:



For information on how to configure other components in the Palo Alto Networks Next‐Generation Security

Platform, go to the Technical Documentation portal: https://www.paloaltonetworks.com/documentation or search the documentation.





For access to the knowledge base and community forums, refer to https://live.paloaltonetworks.com

.

For contacting support, for information on support programs, to manage your account or devices, or to open a support case, refer to https://www.paloaltonetworks.com/support/tabs/overview.html

.



For the most current PAN‐OS and Panorama 7.1 release notes, go to https://www.paloaltonetworks.com/documentation/71/pan‐os/pan‐os‐release‐notes.html

.

To provide feedback on the documentation, please write to us at: [email protected]

.

Palo Alto Networks, Inc.

www.paloaltonetworks.com

© 2016 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be found at http://www.paloaltonetworks.com/company/trademarks.html

. All other marks mentioned herein may be trademarks of their respective companies.

Revision Date: April 26, 2016

2 • PAN‐OS 7.1 Administrator’s Guide


© Palo Alto Networks, Inc.

Policy

Policies allow you to enforce rules and take action. The different types of policy rules that you can create on the firewall are: Security, NAT, Quality of Service (QoS), Policy Based Forwarding (PBF), Decryption,

Application Override, Captive Portal, Denial of Service (DoS), and Zone protection policies. All these different policies work together to allow, deny, prioritize, forward, encrypt, decrypt, make exceptions, authenticate access, and reset connections as needed to help secure your network. The following topics describe how to work with policy:



Policy Types





Security Policy

Policy Objects









Security Profiles

Best Practice Internet Gateway Security Policy

Enumeration of Rules Within a Rulebase

Move or Clone a Policy Rule or Object to a Different Virtual System

















Use Tags to Group and Visually Distinguish Objects

Use an External Dynamic List in Policy

Register IP Addresses and Tags Dynamically

Monitor Changes in the Virtual Environment

CLI Commands for Dynamic IP Addresses and Tags

Identify Users Connected through a Proxy Server

Policy‐Based Forwarding

DoS Protection Against Flooding of New Sessions



PAN‐OS 7.1 Administrator’s Guide • 791

Policy Types

Policy Types

Policy

The Palo Alto Networks next‐generation firewall supports a variety of policy types that work together to safely enable applications on your network.

Policy Type Description

Security

NAT

QoS Identify traffic requiring QoS treatment (either preferential treatment or bandwidth‐limiting) using a defined parameter or multiple parameters and assign it a class. For more details, see Quality of Service .

Policy Based Forwarding Identify traffic that should use a different egress interface than the one that would normally be used based on the routing table. For details, see Policy‐Based

Forwarding .

Decryption

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, user, and the service. For more details, see Security Policy .

Instruct the firewall which packets need translation and how to do the translation.

The firewall supports both source address and/or port translation and destination address and/or port translation. For more details, see NAT .

Application Override

Identify encrypted traffic that you want to inspect for visibility, control, and granular security. For more details, see Decryption .

Identify sessions that you do not want processed by the App‐ID engine, which is a

Layer‐7 inspection. Traffic matching an application override policy forces the firewall to handle the session as a regular stateful inspection firewall at Layer‐4. For more details, see Manage Custom or Unknown Applications .

Captive Portal

DoS Protection

Identify traffic that requires the user to be known. The captive portal policy is only triggered if other User‐ID mechanisms did not identify a user to associate with the source IP address. For more details, see Captive Portal .

Identify potential denial‐of‐service (DoS) attacks and take protective action in response to rule matches. DoS Protection Profiles .




Policy

Security Policy

Security Policy

Security policy protects network assets from threats and disruptions and aids in optimally allocating network resources for enhancing productivity and efficiency in business processes. On the Palo Alto Networks firewall, 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, user, and the service.

All traffic passing through the firewall is matched against a session and each session is matched against a security policy. When a session match occurs, the security policy is applied to bi‐directional traffic (client to server and server to client) in that session. 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 (within the zone) traffic and deny all interzone (between zones) traffic. Although these rules are part of the pre‐defined 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 policies are evaluated left to right and from top to bottom. A packet is matched against the first rule that meets the defined criteria; after a match is triggered the 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 logging is enabled 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.

 Components of a Security Policy Rule





Security Policy Actions

Create a Security Policy Rule

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 tables:



Required Fields



Optional Fields




Security Policy

Required Fields

Policy

Required Field

Name

Rule Type

Source Zone

Destination Zone

Application

Action

Description

A label that supports up to 31 characters, used to identify the rule.

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 role 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.

The zone from which the traffic originates.

The zone at which the traffic terminates. If you use NAT, make sure to always reference the post‐NAT zone.

The application which 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.

Specifies an Allow or Block action for the traffic based on the criteria you define in the rule.

When you configure the firewall to block traffic, it either resets the connection or silently drops packets. To provide a better user experience, you can configure granular options to block 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 Fields

Optional Field Description

Tag

Description

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.

A text field, up to 255 characters, used to describe the rule.

Source IP Address

Define host IP or FQDN, subnet, named 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 IP Address

The location or destination for the traffic. If you use NAT, make sure to always refer to the original IP addresses in the packet (i.e. the pre‐NAT IP address).




Policy

Optional Field

User

URL Category

Service

Security Profiles

HIP Profile

(for

GlobalProtect)

Options

Security Policy

Description (Continued)

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 .

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 the 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 Define Basic Security Policy Rules for information on using the default profiles in your security policy and see Control

Access to Web Content for more details.

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.

Provide additional protection from threats, vulnerabilities, and data leaks. Security profiles are only evaluated for rules that have an allow action.

Allows you to identify clients with Host Information Profile (HIP) and then enforce access privileges.

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 Policy

Security Policy Actions

For traffic that matches the attributes defined in a security policy, you can apply the following actions:

Action

Allow

(default action)

Deny

Drop

Reset client

Reset server

Reset both

Description

Allows the traffic.

Blocks traffic and enforces the default Deny Action defined for the application that is being denied. To view the deny action defined by default for an application, view the application details in Objects > Applications or check the application details in

Applipedia .

Silently drops the traffic; for an application, it overrides the default deny action. A

TCP reset is not 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 firewall sends the ICMP code for communication with the destination is

administratively prohibited—ICMPv4: Type 3, Code 13; ICMPv6: Type 1, Code 1.

Sends a TCP reset to the client‐side device.

Sends a TCP reset to the server‐side device.

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 firewall will not send the reset.

For a TCP session with a reset action, the firewall does not send an ICMP

Unreachable response.

For a UDP session with a drop or reset action, if the ICMP Unreachable check box is selected, the firewall sends an ICMP message to the client.

Policy

Create a Security Policy Rule

Create a Security Policy Rule

Step 1 (Optional) Delete the default security policy rule.

Step 2

Step 3

Add a rule.

Define the matching criteria for the source fields in the packet.

By default, the firewall includes a security rule named rule1 that allows all traffic from Trust zone to Untrust zone. You can either delete the rule or modify the rule to reflect your zone naming conventions.

1.

Select Policies > Security and click Add.

2.

Enter a descriptive Name for the rule in the General tab.

3.

Select a

Rule Type

.

1.

In the Source tab, select a

Source Zone

.

2.

Specify a

Source IP Address

or leave the value set to any.

3.

Specify a Source

User





Policy Security Policy

Create a Security Policy Rule (Continued)

Step 4 Define the matching criteria for the destination fields in the packet.

4.

In the Destination tab, set the

Destination Zone

.

5.

Specify a

Destination IP Address


As a best practice, consider using address objects in the Destination Address field to enable access to specific servers or groups of servers only, particularly for services such as DNS and SMTP that are commonly exploited. By restricting users to specific destination server addresses you can prevent data exfiltration and command and control traffic from establishing communication through techniques such as DNS tunneling.

Step 5 Specify the application the rule will allow or block.

As a best practice, always use application‐based security policy rules instead of port based rules and always set the Service to application‐default unless you are using a more restrictive list of ports than the standard ports for an application.

1.

In the Applications tab, Add the

Application

to safely enable.

You can select multiple applications, or use application groups or application filters.

2.

In the Service/URL Category tab, keep the

Service

set to application-default

to ensure that any applications the rule allows are only allowed on their standard ports.

Step 6 (Optional) Specify a URL category as match criteria for the rule.

Step 7 Define what action you want the firewall to take for traffic that matches the rule.

In the Actions tab, select an Action. See Security Policy Actions for a description of each action.

Step 8 Configure the log settings.

In the Service/URL Category tab, select the

URL Category

.

If you select a URL category, only web traffic will match the rule and only if the traffic is to the specified category.

• By default, the rule is set to Log at Session End. You can clear this setting if you don’t want any logs generated when traffic matches this rule, or select Log at Session Start for more detailed logging.

• Select a Log Forwarding profile.

Step 9 Attach security profiles to enable the firewall to scan all allowed traffic for threats.

See Create Best Practice Security

Profiles to learn how to create security profiles that protect your network from both known and unknown threats.

In the Actions tab, select Profiles from the Profile Type drop‐down and then select the individual security profiles to attach to the rule.

Alternatively, select Group from the Profile Type drop‐down and select a security Group Profile to attach.

Step 10 Save the policy rule to the running configuration on the firewall.

Click Commit.




Security Policy Policy

Create a Security Policy Rule (Continued)

Step 11 To verify that you have set up your basic policies effectively, test whether your security policy rules are being evaluated and determine which security policy rule applies to a traffic flow.

To verify the policy rule that matches a flow, use the following CLI command: test security‐policy‐match source <IP_address> destination

<IP_address> destination port <port_number> protocol

<protocol_number>

The output displays the best rule that matches the source and destination IP address specified in the CLI command.

For example, to verify the policy rule that will be applied for a server in the data center with the IP address 208.90.56.11 when it accesses the Microsoft update server: test security-policy-match source 208.80.56.11 destination 176.9.45.70 destination-port 80 protocol 6

"Updates-DC to Internet" {

from data_center_applications;

source any;

source-region any;

to untrust;

destination any;

destination-region any;

user any;

category any; application/service[dns/tcp/any/53 dns/udp/any/53 dns/udp/any/5353 ms-update/tcp/any/80 ms-update/tcp/any/443]; action allow;

terminal yes;




Policy

Policy Objects

Policy Objects

A policy object is a single object or a collective unit that groups discrete identities such as IP addresses, URLs, applications, or users. With policy objects that are a collective unit, you can reference the object in security policy instead of manually selecting multiple objects one at a time. Typically, when creating a policy object, you group objects that require similar permissions in policy. For example, if your organization uses a set of server IP addresses for authenticating users, you can group the set of server IP addresses as an address group policy object and reference the address group in the security policy. By grouping objects, you can significantly reduce the administrative overhead in creating policies.

You can create the following policy objects on the firewall:

Policy Object

Address/Address Group,

Region

User/User Group

Application Group and

Application Filter

Service/Service Groups

Description

Allow you to group specific source or destination addresses that require the same policy enforcement. The address object can include an IPv4 or IPv6 address (single

IP, range, subnet) or the FQDN. Alternatively, a region can be defined by the latitude and longitude coordinates or you can select a country and define an IP address or IP range. You can then group a collection of address objects to create an address group object.

You can also use dynamic address groups to dynamically update IP addresses in environments where host IP addresses change frequently.

Allow you to create a list of users from the local database or an external database and group them.

An Application Filter allows you to filter applications dynamically. It allows you to filter, and save a group of applications using the attributes defined in the application database on the firewall. For example, you can Create an Application Filter by one or more attributes—category, sub‐category, technology, risk, characteristics. With an application filter, when a content update occurs, any new applications that match your filter criteria are automatically added to your saved application filter.

An Application Group allows you to create a static group of specific applications that you want to group together for a group of users or for a particular service, or to achieve a particular policy goal. See Create an Application Group .

Allows you to specify the source and destination ports and protocol that a service can use. The firewall includes two pre‐defined services—service‐http and service‐https— that use TCP ports 80 and 8080 for HTTP, and TCP port 443 for HTTPS. You can however, create any custom service on any TCP/UDP port of your choice to restrict application usage to specific ports on your network (in other words, you can define the default port for the application).

To view the standard ports used by an application, in Objects > Applications search for the application and click the link. A succinct description displays.




Security Profiles

Security Profiles

Policy

While security policy rules enable you to allow or block traffic on your network, security profiles help you define an allow but scan rule, which scans allowed applications for threats, such as viruses, malware, spyware, and DDOS attacks. When traffic matches the allow rule defined in the security policy, the security profile(s) that are attached to the rule are applied for further content inspection rules such as antivirus checks and data filtering.

Security profiles are not used in the match criteria of a traffic flow. The security profile is applied to scan traffic after the application or category is allowed by the security policy.

The firewall provides default security profiles that you can use out of the box to begin protecting your network from threats. See Set Up a Basic Security Policy for information on using the default profiles in your security policy. As you get a better understanding about the security needs on your network, you can create custom profiles. See Scan Traffic for Threats for more information.

For recommendations on the best‐practice settings for security profiles, see Create Best Practice Security

Profiles .

You can add security profiles that are commonly applied together to a Security Profile Group ; this set of profiles can be treated as a unit and added to security policies in one step (or included in security policies by default, if you choose to set up a default security profile group).

The following topics provide more detailed information about each type of security profile and how to set up a security profile group:



Antivirus Profiles





Anti‐Spyware Profiles

Vulnerability Protection Profiles









URL Filtering Profiles

Data Filtering Profiles

File Blocking Profiles

WildFire Analysis Profiles







DoS Protection Profiles

Zone Protection Profiles

Security Profile Group




Policy Security Profiles

Antivirus Profiles

Antivirus profiles protect against viruses, worms, and trojans as well as spyware downloads. Using a stream‐based malware prevention engine, which inspects traffic the moment the first packet is received, the

Palo Alto Networks antivirus solution can provide protection for clients without significantly impacting the performance of the firewall. This profile scans for a wide variety of malware in executables, PDF files, HTML and JavaScript viruses, including support for scanning inside compressed files and data encoding schemes. If you have enabled Decryption on the firewall, the profile also enables scanning of decrypted content.

The default profile inspects all of the listed protocol decoders for viruses, and generates alerts for SMTP,

IMAP, and POP3 protocols while blocking for FTP, HTTP, and SMB protocols. You can configure the action for a decoder or Antivirus signature and specify how the firewall responds to a threat event:

Action

Default

Allow

Alert

Drop

Reset Client

Reset Server

Reset Both

Description

For each threat signature and Antivirus signature that is defined by Palo Alto

Networks, a default action is specified internally. Typically, the default action is an alert or a reset‐both. The default action is displayed in parenthesis, for example default (alert) in the threat or Antivirus signature.

Permits the application traffic.

Generates an alert for each application traffic flow. The alert is saved in the threat log.

Drops the application traffic.

For TCP, resets the client‐side connection. For UDP, drops the connection.

For TCP, resets the server‐side connection. For UDP, drops the connection.

For TCP, resets the connection on both client and server ends. For UDP, drops the connection.

Customized profiles can be used to minimize antivirus inspection for traffic between trusted security zones, and to maximize the inspection of traffic received from untrusted zones, such as the Internet, as well as the traffic sent to highly sensitive destinations, such as server farms.

The Palo Alto Networks WildFire system also provides signatures for persistent threats that are more evasive and have not yet been discovered by other antivirus solutions. As threats are discovered by WildFire, signatures are quickly created and then integrated into the standard Antivirus signatures that can be downloaded by Threat Prevention subscribers on a daily basis (sub‐hourly for WildFire subscribers).

Anti-Spyware Profiles

Anti‐Spyware profiles blocks spyware on compromised hosts from trying to phone‐home or beacon out to external command‐and‐control (C2) servers, allowing you to detect malicious traffic leaving the network from infected clients. You can apply various levels of protection between zones. For example, you may want to have custom Anti‐Spyware profiles that minimize inspection between trusted zones, while maximizing inspection on traffic received from an untrusted zone, such as Internet facing zones.

You can define your own custom Anti‐Spyware profiles, or choose one of the following predefined profiles when applying Anti‐Spyware to a Security policy rule:

 Default

—Uses the default action for every signature, as specified by Palo Alto Networks when the signature is created.




Security Profiles Policy

 Strict

—Overrides the default action of critical, high, and medium severity threats to the block action, regardless of the action defined in the signature file. This profile still uses the default action for medium and informational severity signatures.

When the firewall detects a threat event, you can configure the following actions in an Anti‐Spyware profile:

 Default

—For each threat signature and Anti‐Spyware signature that is defined by Palo Alto Networks, a default action is specified internally. Typically the default action is an alert or a reset‐both. The default action is displayed in parenthesis, for example default (alert) in the threat or Antivirus signature.









Allow

—Permits the application traffic

Alert

—Generates an alert for each application traffic flow. The alert is saved in the threat log.

Drop

—Drops the application traffic.

Reset Client

—For TCP, resets the client‐side connection. For UDP, drops the connection.







Reset Server

—For TCP, resets the server‐side connection. For UDP, drops the connection.

Reset Both

—For TCP, resets the connection on both client and server ends. For UDP, drops the connection.

Block IP

— This action blocks traffic from either a source or a source‐destination pair. It is configurable for a specified period of time.

In addition, you can enable the DNS Sinkholing action in Anti‐Spyware profiles to enable the firewall to forge a response to a DNS query for a known malicious domain, causing the malicious domain name to resolve to an IP address that you define. This feature helps to identify infected hosts on the protected network using

DNS traffic Infected hosts can then be easily identified in the traffic and threat logs because any host that attempts to connect to the sinkhole IP address are most likely infected with malware.

Anti‐Spyware and Vulnerability Protection profiles are configured similarly.

Vulnerability Protection Profiles

Vulnerability Protection profiles stop attempts to exploit system flaws or gain unauthorized access to systems. While Anti‐Spyware profiles help identify infected hosts as traffic leaves the network, Vulnerability

Protection profiles protect against threats entering the network. For example, Vulnerability Protection profiles help protect against buffer overflows, illegal code execution, and other attempts to exploit system vulnerabilities. The default Vulnerability Protection profile protects clients and servers from all known critical, high, and medium‐severity threats. You can also create exceptions, which allow you to change the response to a specific signature.

To configure how the firewall responds to a threat, see Anti‐Spyware Profiles for a list of supported actions.

URL Filtering Profiles

URL Filtering profiles enable you to monitor and control how users access the web over HTTP and HTTPS.

The firewall comes with a default profile that is configured to block websites such as known malware sites, phishing sites, and adult content sites. You can use the default profile in a security policy, clone it to be used as a starting point for new URL filtering profiles, or add a new URL profile that will have all categories set to allow for visibility into the traffic on your network. You can then customize the newly added URL profiles and add lists of specific websites that should always be blocked or allowed, which provides more granular control over URL categories.





Data Filtering Profiles

Data filtering profiles prevent sensitive information such as credit card or social security numbers from leaving a protected network. The data filtering profile also allows you to filter on key words, such as a sensitive project name or the word confidential. It is important to focus your profile on the desired file types to reduce false positives. For example, you may only want to search Word documents or Excel spreadsheets.

You may also only want to scan web‐browsing traffic, or FTP.

You can use default profiles, or create custom data patterns. There are two default profiles:





CC# (Credit Card)—Identifies credit card numbers using a hash algorithm. The content must match the hash algorithm in order for data to be detected as a credit card number. This method will reduce false positives.

SSN# (Social Security Number)—Uses an algorithm to detect nine digit numbers, regardless of format.

There are two fields: SSN# and SSN# (no dash).

Weight and Threshold Values

It is important to understand how the weight of an object (SSN, CC#, pattern) is calculated in order to set the appropriate threshold for a condition you are trying to filter. Each occurrence multiplied by the weight value will be added together in order to reach an action threshold (alert or block).

Example: Filter for Social Security Numbers Only

For simplicity, if you only want to filter files with Social Security Numbers (SSN) and you define a weight of

3 for SSN#, you would use the following formula: each instance of a SSN x weight = threshold increment. In this case, if a Word document has 10 social security numbers you multiply that by the weight of 3, so 10 x

3 = 30. In order to take action for a file that contains 10 social security numbers you would set the threshold to 30. You may want to set an alert at 30 and then block at 60. You may also want to set a weight in the field

SSN# (no dash) for Social Security Numbers that do not contain dashes. If multiple settings are used, they will accumulate to reach a given threshold.

Example: Filter for Social Security Numbers and a Custom Pattern

In this example, we will filter on files that contain Social Security Numbers and the custom pattern confidential. In other words, if a file has Social Security Numbers in addition to the word confidential and the combined instances of those items hit the threshold, the file will trigger an alert or block, depending on the action setting.

SSN# weight = 3

Custom Pattern confidential weight = 20

The custom pattern is case sensitive.

If the file contains 20 Social Security Numbers and a weight of 3 is configured, that is 20 x 3 = 60. If the file also contains one instance of the term confidential and a weight of 20 is configured, that is 1 x 20 = 20 for a total of 80. If your threshold for block is set to 80, this scenario would block the file. The alert or block action will be triggered as soon as the threshold is hit.





File Blocking Profiles

The firewall uses file blocking profiles to block specified file types over specified applications and in the specified session flow direction (inbound/outbound/both). You can set the profile to alert or block on upload and/or download and you can specify which applications will be subject to the file blocking profile. You can also configure custom block pages that will appear when a user attempts to download the specified file type.

This allows the user to take a moment to consider whether or not they want to download a file.

Configure a file blocking profile with the following actions:

 Alert

—When the specified file type is detected, a log is generated in the data filtering log.





Block

—When the specified file type is detected, the file is blocked and a customizable block page is presented to the user. A log is also generated in the data filtering log.

Continue

—When the specified file type is detected, a customizable response page is presented to the user.

The user can click through the page to download the file. A log is also generated in the data filtering log.

Because this type of forwarding action requires user interaction, it is only applicable for web traffic.

WildFire Analysis Profiles

Use a WildFire analysis profile to enable the firewall to forward unknown files or email links for WildFire analysis . Specify files to be forwarded for analysis based on application, file type, and transmission direction

(upload or download). Files or email links matched to the profile rule are forwarded either the WildFire public cloud or the WildFire private cloud (hosted with a WF‐500 appliance), depending on the analysis location defined for the rule.

You can also use the WildFire analysis profiles to set up a Wildfire hybrid cloud deployment. If you are using a WildFire appliance to analyze sensitive files locally (such as PDFs), you can specify for less sensitive files types (such as PE files) or file types that are not supported for WildFire appliance analysis (such as APKs) to be analyzed by the WildFire public cloud. Using both the WildFire appliance and the WildFire cloud for analysis allows you to benefit from a prompt verdict for files that have already been processed by the cloud, and for files that are not supported for appliance analysis, and frees up the appliance capacity to process sensitive content.

DoS Protection Profiles

DoS protection profiles provide detailed control for Denial of Service (DoS) protection policies. DoS policies allow you to control the number of sessions between interfaces, zones, addresses, and countries based on aggregate sessions or source and/or destination IP addresses. There are two DoS protection mechanisms that the Palo Alto Networks firewalls support.



Flood Protection—Detects and prevents attacks where the network is flooded with packets resulting in too many half‐open sessions and/or services being unable to respond to each request. In this case the source address of the attack is usually spoofed. See DoS Protection Against Flooding of New Sessions .



Resource Protection— Detects and prevent session exhaustion attacks. In this type of attack, a large number of hosts (bots) are used to establish as many fully established sessions as possible to consume all of a system’s resources.

You can enable both types of protection mechanisms in a single DoS protection profile.





The DoS profile is used to specify the type of action to take and details on matching criteria for the DoS policy. The DoS profile defines settings for SYN, UDP, and ICMP floods, can enable resource protect and defines the maximum number of concurrent connections. After you configure the DoS protection profile, you then attach it to a DoS policy.

When configuring DoS protection, it is important to analyze your environment in order to set the correct thresholds and due to some of the complexities of defining DoS protection policies, this guide will not go into detailed examples. For more information, refer to the Threat Prevention Tech Note .

Zone Protection Profiles

Zone protection profiles provide additional protection between specific network zones in order to protect the zones against attack. The profile must be applied to the entire zone, so it is important to carefully test the profiles in order to prevent issues that may arise with the normal traffic traversing the zones. When defining packets per second (pps) thresholds limits for zone protection profiles, the threshold is based on the packets per second that do not match a previously established session. For more information, refer to the

Threat Prevention Tech Note .

Security Profile Group

A security profile group is a set of security profiles that can be treated as a unit and then easily added to security policies. Profiles that are often assigned together can be added to profile groups to simplify the creation of security policies. You can also setup a default security profile group—new security policies will use the settings defined in the default profile group to check and control traffic that matches the security policy. Name a security profile group default to allow the profiles in that group to be added to new security policies by default. This allows you to consistently include your organization’s preferred profile settings in new policies automatically, without having to manually add security profiles each time you create new rules.

For recommendations on the best‐practice settings for security profiles, see Create Best Practice Security

Profiles .

The following sections show how to create a security profile group and how to enable a profile group to be used by default in new security policies:



Create a Security Profile Group



Set Up or Override a Default Security Profile Group





Create a Security Profile Group

Use the following steps to create a security profile group and add it to a security policy.

Create a Security Profile Group

Step 1 Create a security profile group.

If you name the group default, the firewall will automatically attach it to any new rules you create. This is a time saver if you have a preferred set of security profiles that you want to make sure get attached to every new rule.

1.

Select Objects > Security Profile Groups and Add a new security profile group.

2.

Give the profile group a descriptive Name, for example,

Threats.

3.

If the firewall is in Multiple Virtual System Mode, enable the profile to be Shared by all virtual systems.

4.

Add existing profiles to the group.

5.

Click OK to save the profile group.

Step 2 Add a security profile group to a security policy.

1.

Select Policies > Security and Add or modify a security policy rule.

2.

Select the Actions tab.

3.

In the Profile Setting section, select Group for the Profile Type.

4.

In the Group Profile drop‐down, select the group you created

(for example, select the best‐practice group):

Step 3 Save your changes.

5.

Click OK to save the policy and Commit your changes.

Click Commit.





Set Up or Override a Default Security Profile Group

Use the following options to set up a default security profile group to be used in new security policies, or to override an existing default group. When an administrator creates a new security policy, the default profile group will be automatically selected as the policy’s profile settings, and traffic matching the policy will be checked according to the settings defined in the profile group (the administrator can choose to manually select different profile settings if desired). Use the following options to set up a default security profile group or to override your default settings.

If no default security profile exists, the profile settings for a new security policy are set to None by default.

Set Up or Override a Default Security Profile Group

• Create a security profile group.

1.

Select Objects > Security Profile Groups and Add a new security profile group.

2.

Give the profile group a descriptive Name, for example,

Threats.

3.

If the firewall is in Multiple Virtual System Mode, enable the profile to be Shared by all virtual systems.

4.

Add existing profiles to the group. For details on creating profiles, see Security Profiles .

5.

Click OK to save the profile group.

6.

Add the security profile group to a security policy.

7.

Add

or modify a security policy rule and select the Actions tab.

8.

Select Group for the Profile Type.

9.

In the Group Profile drop‐down, select the group you created

(for example, select the Threats group):


10.

Click OK to save the policy and Commit your changes.




Set Up or Override a Default Security Profile Group

• Set up a default security profile group.

1.

Select Objects > Security Profile Groups and add a new security profile group or modify an existing security profile group.

2.

Name

the security profile group default:

3.

Click OK and Commit.

4.

Confirm that the default security profile group is included in new security policies by default: a. Select Policies > Security and Add a new security policy.

b. Select the Actions tab and view the Profile Setting fields:

• Override a default security profile group.

By default, the new security policy correctly shows the Profile Type set to Group and the default Group Profile is selected.

If you have an existing default security profile group, and you do not want that set of profiles to be attached to a new security policy, you can continue to modify the Profile Setting fields according to your preference. Begin by selecting a different Profile Type for your policy (Policies > Security > Security Policy Rule > Actions).




Policy Best Practice Internet Gateway Security Policy


One of the cheapest and easiest ways for an attacker to gain access to your network is through users accessing the Internet. By successfully exploiting an endpoint, an attacker can take hold in your network and begin to move laterally towards the end goal, whether that is to steal your source code, exfiltrate your customer data, or take down your infrastructure. To protect your network from cyberattack and improve your overall security posture, implement a best practice Internet gateway security policy. A best practice policy allows you to safely enable applications, users, and content by classifying all traffic, across all ports, all the time.

The following topics describe the overall process for deploying a best practice Internet gateway security policy and provide detailed instructions for creating it.



What Is a Best Practice Internet Gateway Security Policy?





Why Do I Need a Best Practice Internet Gateway Security Policy?

How Do I Deploy a Best Practice Internet Gateway Security Policy?









Identify Whitelist Applications

Create User Groups for Access to Whitelist Applications

Decrypt Traffic for Full Visibility and Threat Inspection

Create Best Practice Security Profiles









Define the Initial Internet Gateway Security Policy

Monitor and Fine Tune the Policy Rulebase

Remove the Temporary Rules

Maintain the Rulebase

What Is a Best Practice Internet Gateway Security Policy?

A best practice Internet gateway security policy has two main security goals:



Minimize the chance of a successful intrusion—Unlike legacy port‐based security policies that either block everything in the interest of network security, or enable everything in the interest of your business, a best practice security policy leverages App‐ID, User‐ID, and Content‐ID to ensure safe enablement of applications across all ports, for all users, all the time, while simultaneously scanning all traffic for both known and unknown threats.



Identify the presence of an attacker—A best practice Internet gateway security policy provides built‐in mechanisms to help you identify gaps in the rulebase and detect alarming activity and potential threats on your network.

To achieve these goals, the best practice Internet gateway security policy uses application‐based rules to allow access to whitelisted applications by user, while scanning all traffic to detect and block all known threats, and send unknown files to WildFire to identify new threats and generate signatures to block them:




Best Practice Internet Gateway Security Policy Policy

The best practice policy is based on the following methodologies. The best practice methodologies ensure detection and prevention at multiple stages of the attack life cycle.

Best Practice Methodology Why is this important?

Inspect All Traffic for Visibility Because you cannot protect against threats you cannot see, you must make sure you have full visibility into all traffic across all users and applications all the time. To accomplish this:

• Deploy GlobalProtect to extend the next‐generation security platform to users and devices no matter where they are located.

• Enable SSL decryption so the firewall can inspect encrypted traffic (SSL/TLS traffic flows account for 40% or more of the total traffic on a typical network today).

• Enable User‐ID to map application traffic and associated threats to users/devices.

The firewall can then inspect all traffic—inclusive of applications, threats, and content—and tie it to the user, regardless of location or device type, port, encryption, or evasive techniques employed using the native App‐ID, Content‐ID, and User‐ID technologies.

Complete visibility into the the applications, the content, and the users on your network is the first step toward informed policy control.

Reduce the Attack Surface

Prevent Known Threats

After you have context into the traffic on your network—applications, their associated content, and the users who are accessing them—create application‐based

Security policy rules to allow those applications that are critical to your business and additional rules to block all high‐risk applications that have no legitimate use case.

To further reduce your attack surface, attach File Blocking and URL Filtering profiles to all rules that allow application traffic to prevent users from visiting threat‐prone web sites and prevent them from uploading or downloading dangerous file types

(either knowingly or unknowingly).

Enable the firewall to scan all all allowed traffic for known threats by attaching security profiles to all allow rules to detect and block network and application layer vulnerability exploits, buffer overflows, DoS attacks, and port scans, known malware variants, (including those hidden within compressed files or compressed

HTTP/HTTPS traffic). To enable inspection of encrypted traffic, enable SSL decryption.





Best Practice Methodology

Detect Unknown Threats

Why is this important?

Forward all unknown files to WildFire for analysis. WildFire identifies unknown or targeted malware (also called advanced persistent threats or APTs) hidden within files by directly observing and executing unknown files in a virtualized sandbox environment in the cloud or on the WF‐500 appliance. WildFire monitors more than

250 malicious behaviors and, if malware is found, it automatically develops a signature and delivers it to you in as little as 5 minutes (and now that unknown threat is a known threat).

Why Do I Need a Best Practice Internet Gateway Security Policy?

Unlike legacy port‐based security policies that either block everything in the interest of network security, or enable everything in the interest of your business, a best practice security policy allows you to safely enable applications by classifying all traffic, across all ports, all the time, including encrypted traffic. By determining the business use case for each application, you can create security policy rules to allow and protect access to relevant applications. Simply put, a best practice security policy is a policy that leverages the next‐generation technologies—App‐ID, Content‐ID, and User‐ID—on the Palo Alto Networks enterprise security platform to:





Identify applications regardless of port, protocol, evasive tactic or encryption

Identify and control users regardless of IP address, location, or device





Protect against known and unknown application‐borne threats

Provide fine‐grained visibility and policy control over application access and functionality

A best practice security policy uses a layered approach to ensure that you not only safely enable sanctioned applications, but also block applications with no legitimate use case. To mitigate the risk of breaking applications when moving from a port‐based enforcement to an application‐based enforcement, the best‐practice rulebase provides built‐in mechanisms to help you identify gaps in the rulebase and detect alarming activity and potential threats on your network. These temporary best practice rules ensure that applications your users are counting on don’t break, while allowing you to monitor application usage and craft appropriate rules. You may find that some of the applications that were being allowed through existing port‐based policy rules are not necessarily applications that you want to continue to allow or that you want to limit to a more granular set of users.

Unlike a port‐based policy, a best‐practice security policy is easy to administer and maintain because each rule meets a specific goal of allowing an application or group of applications to a specific user group based on your business needs. Therefore, you can easily understand what traffic the rule enforces by looking at the match criteria. Additionally, a best‐practice security policy rulebase leverages tags and objects to make the rulebase more scannable and easier to keep synchronized with your changing environment.





How Do I Deploy a Best Practice Internet Gateway Security Policy?

Moving from a port‐based security policy to an application‐based security policy may seem like a daunting task. However, the security risks of sticking with a port‐based policy far outweigh the effort required to implement an application‐based policy. And, while legacy port‐based security policies may have hundreds, if not thousands of rules (many of which nobody in the organization knows the purpose), a best practice policy has a streamlined set of rules that align with your business goals, simplifying administration and reducing the chance of error. Because the rules in an application‐based policy align with your business goals and acceptable use policies, you can quickly scan the policy to understand the reason for each and every rule.

As with any technology, there is usually a gradual approach to a complete implementation, consisting of carefully planned deployment phases to make the transition as smooth as possible, with minimal impact to your end users. Generally, the workflow for implementing a best practice Internet gateway security policy is:

 Assess your business and identify what you need to protect—The first step in deploying a security architecture is to assess your business and identify what your most valuable assets are as well as what the biggest threats to those assets are. For example, if you are a technology company, your intellectual property is your most valuable asset. In this case, one of your biggest threats would be source code theft.





Segment Your Network Using Interfaces and Zones —Traffic cannot flow between zones unless there is a security policy rule to allow it. One of the easiest defenses against lateral movement of an attacker that has made its way into your network is to define granular zones and only allow access to the specific user groups who need to access an application or resource in each zone. By segmenting your network into granular zones, you can prevent an attacker from establishing a communication channel within your network (either via malware or by exploiting legitimate applications), thereby reducing the likelihood of a successful attack on your network.

Identify Whitelist Applications —Before you can create an Internet gateway best practice security policy, you must have an inventory of the applications you want to allow on your network, and distinguish between those applications you administer and officially sanction and those that you simply want users to be able to use safely. After you identify the applications (including general types of applications) you want to allow, you can map them to specific best practice rules.









Create User Groups for Access to Whitelist Applications —After you identify the applications you plan to allow, you must identify the user groups that require access to each one. Because compromising an end user’s system is one of the cheapest and easiest ways for an attacker to gain access to your network, you can greatly reduce your attack surface by only allowing access to applications to the user groups that have a legitimate business need.

Decrypt Traffic for Full Visibility and Threat Inspection —You can’t inspect traffic for threats if you can’t see it. And today SSL/TLS traffic flows account for 40% or more of the total traffic on a typical network.

This is precisely why encrypted traffic is a common way for attackers to deliver threats. For example, an attacker may use a web application such as Gmail, which uses SSL encryption, to email an exploit or malware to employees accessing that application on the corporate network. Or, an attacker may compromise a web site that uses SSL encryption to silently download an exploit or malware to site visitors. If you are not decrypting traffic for visibility and threat inspection, you are leaving a very large surface open for attack.

Create Best Practice Security Profiles —Command and control traffic, CVEs, drive‐by downloads of malicious content, APTs are all delivered via legitimate applications. To protect against known and unknown threats, you must attach stringent security profiles to all Security policy allow rules.

Define the Initial Internet Gateway Security Policy —Using the application and user group inventory you conducted, you can define an initial policy that allows access to all of the applications you want to whitelist by user or user group. The initial policy rulebase you create must also include temporary rules









 to prevent other applications you might not have known about from breaking and to identify policy gaps and security holes in your existing design.

Monitor and Fine Tune the Policy Rulebase —After the temporary rules are in place, you can begin monitoring traffic that matches to them so that you can fine tune your policy. Because the temporary rules are designed to uncover unexpected traffic on the network, such as traffic running on non‐default ports or traffic from unknown users, you must assess the traffic matching these rules and adjust your application allow rules accordingly.

Remove the Temporary Rules —After a monitoring period of several months, you should see less and less traffic hitting the temporary rules. When you reach the point where traffic no longer hits the temporary rules, you can remove them to complete your best practice Internet Gateway Security policy.

Maintain the Rulebase —Due to the dynamic nature of applications, you must continually monitor your application whitelist and adapt your rules to accommodate new applications that you decide to sanction as well to determine how new or modified App‐IDs impact your policy. Because the rules in a best practice rulebase align with your business goals and leverage policy objects for simplified administration, adding support for a new sanctioned application or new or modified App‐ID oftentimes is as simple as adding or removing an application from an application group or modifying an application filter.

Identify Whitelist Applications

The application whitelist includes not only the applications you provision and administer for business and infrastructure purposes, but also other applications that your users may need to use in order to get their jobs done, and applications you may choose to allow for personal use. Before you can begin creating your best practice Internet Gateway Security policy, you must create an inventory of the applications you want to whitelist.

 Map Applications to Business Goals for a Simplified Rulebase





Use Temporary Rules to Tune the Whitelist

Application Whitelist Example

Map Applications to Business Goals for a Simplified Rulebase

As you inventory the applications on your network, consider your business goals and acceptable use policies and identify the applications that correspond to each. This will allow you to create a goal‐driven rulebase.

For example, one goal might be to allow all users on your network to access data center applications. Another goal might be to allow the sales and support groups access your customer database. You can then create a whitelist rule that correspond to each goal you identify and group all of the applications that align with the goal into a single rule. This approach allows you to create a rulebase with a smaller number of individual rules, each with a clear purpose.

In addition, because the individual rules you create align with your business goals, you can use application objects to group the whitelist to further simplify administration of the best practice rulebase:



Create application groups for sanctioned applications —Because you will know exactly what applications you require and sanction for official use, create application groups that explicitly include only those applications. Using application groups also simplifies the administration of your policy because it allows you to add and remove sanctioned applications without requiring you to modify individual policy rules.

Generally, if the applications that map to the same goal have the same requirements for enabling access







(for example, they all have a destination address that points to your data center address group, they all allow access to any known user, and you want to enable them on their default ports only) you would add them to the same application group.

Create application filters to allow general types of applications —Besides the applications you officially sanctioned, you will also need to decide what additional applications you will want to allow your users to access. Application filters allow you to safely enable certain categories of applications using application filters (based on category, subcategory, technology, risk factor, or characteristic). Separate the different types of applications based on business and personal use. Create separate filters for each type of application to make it easier to understand each policy rule at a glance.

Use Temporary Rules to Tune the Whitelist

Although the end‐goal of a best‐practice application‐based policy is to use positive enforcement to safely enable your whitelist applications, the initial rulebase requires some additional rules designed to ensure that you have full visibility into the all applications in use on your network so that you can properly tune it. The initial rulebase you create will have the following types of rules:





Whitelist rules for the applications you officially sanction and deploy.

Whitelist rules for safely enabling access to general types of applications you want to allow per your acceptable use policy.





Blacklist rules that block applications that have no legitimate use case. You need these rules so that the temporary rules that “catch” applications that haven’t yet been accounted for in your policy don’t let anything bad onto your network.

Temporary allow rules to give you visibility into all of the applications running on your network so that you can tune the rulebase.

The temporary rules are a very important part of the initial best practice rulebase. Not only will they give you visibility into applications you weren’t aware were running on your network (and prevent legitimate applications you didn’t know about from breaking), but they will also help you identify things such as unknown users and applications running on non‐standard ports. Because attackers commonly use standard applications on non‐standard ports as an evasion technique, allowing applications on any port opens the door for malicious content. Therefore, you must identify any legitimate applications running on non‐standard ports (for example, internally developed applications) so that you can either modify what ports are used or create a custom applications to enable them.

Application Whitelist Example

Keep in mind that you do not need to capture every application that might be in use on your network in your initial inventory. Instead you should focus here on the applications (and general types of applications) that you want to allow. Temporary rules in the best practice rulebase will catch any additional applications that may be in use on your network so that you are not inundated with complaints of broken applications during your transition to application‐based policy. The following is an example application whitelist for an enterprise gateway deployment.





Application Type Best Practice for Securing

Sanctioned Applications These are the applications that your IT department administers specifically for business use within your organization or to provide infrastructure for your network and applications. For example, in an Internet gateway deployment these applications fall into the following categories:

• Infrastructure Applications—These are the applications that you must allow to enable networking and security, such as ping, NTP, SMTP, and DNS.

• IT Sanctioned Applications—These are the applications that you provision and administer for your users. These fall into two categories:

• IT Sanctioned On‐Premise Applications—These are the applications you install and host in your data center for business use. With IT sanctioned on‐premise applications, the application infrastructure and the data reside on enterprise‐owned equipment. Examples include Microsoft Exchange and active sync, as well as authentication tools such as Kerberos and LDAP.

• IT Sanctioned SaaS Applications—SaaS applications are those where the software and infrastructure are owned and managed by the application service provider, but where you retain full control of the data, including who can create, access, share, and transfer it (for example, Salesforce, Box, and GitHub).

• Administrative Applications—These are applications that only a specific group of administrative users should have access to in order to administer applications and support users (for example, remote desktop applications).

General Types of

Applications

Besides the applications you officially sanction and deploy, you will also want to allow your users to safely use other types of applications:

• General Business Applications—For example, allow access to software updates, and web services, such as WebEx, Adobe online services, and Evernote.

• Personal Applications—For example, you may want to allow your users to browse the web or safely use web‐based mail, instant messaging, or social networking applications.

The recommended approach here is to begin with wide application filters so you can gain an understanding of what applications are in use on your network. You can then decide how much risk you are willing to assume and begin to pare down the application whitelist.

For example, suppose you find that Box, Dropbox, and Office 365 file‐sharing applications are all on use on your network. Each of these applications has an inherent risk associated with it, from data leakage to risks associated with transfer of malware‐infected files. The best approach would be to officially sanction a single file‐sharing application and then begin to phase out the others by slowly transitioning from an allow policy to an alert policy, and finally, after giving users ample warning, a block policy for all file sharing applications except the one you choose to sanction. In this case, you might also choose to enable a small group of users to continue using an additional file‐sharing application as needed to perform job functions with partners.

Custom Applications

Specific to Your

Environment

If you have proprietary applications on your network or applications that you run on non‐standard ports, it is a best practice to create custom applications for them. This way you can allow the application as a sanctioned application and lock it down to its default port. Otherwise you would either have to open up additional ports (for applications running on non‐standard ports), or allow unknown traffic (for proprietary applications), neither of which are recommended in a best practice Security policy.





Create User Groups for Access to Whitelist Applications

Safely enabling applications means not only defining the list of applications you want to allow, but also enabling access only for those users who have a legitimate business need. For example, some applications, such as SaaS applications that enable access to Human Resources services (such as Workday or Service Now) must be available to any known user on your network. However, for more sensitive applications you can reduce your attack surface by ensuring that only users who need these applications can access them. For example, while IT support personnel may legitimately need access to remote desktop applications, the majority of your users do not. Limiting user access to applications prevents potential security holes for an attacker to gain access to and control over systems in your network.

To enable user‐based access to applications:

 Enable User‐ID in zones from which your users initiate traffic.





For each application whitelist rule you define, identify the user groups that have a legitimate business need for the applications allowed by the rule. Keep in mind that because the best practice approach is to map the application whitelist rules to your business goals (which includes considering which users have a business need for a particular type of application), you will have a much smaller number of rules to manage than if you were trying to map individual port‐based rules to users.

If you don’t have an existing group on your AD server, you can alternatively create custom LDAP groups to match the list of users who need access to a particular application.

Decrypt Traffic for Full Visibility and Threat Inspection

The best practice security policy dictates that you decrypt all traffic except sensitive categories, which include Health, Finance, Government, Military, and Shopping.

Use decryption exceptions only where required, and be precise to ensure that you are limiting the exception to a specific application or user based on need only:



If decryption breaks an important application, create an exception for the specific IP address, domain, or common name in the certificate associated with the application.



If a specific user needs to be excluded for regulatory or legal reasons, create an exception for just that user.

To ensure that certificates presented during SSL decryption area valid, configure the firewall to perform

CRL/OCSP checks .

Best practice Decryption policy rules include a strict Decryption Profile. Before you configure SSL Forward

Proxy , create a best practice Decryption Profile (

Objects > Decryption Profile

) to attach to your Decryption policy rules:





Best Practice Decryption Profile

• Configure the SSL Decryption > SSL Forward Proxy settings to block exceptions during SSL negotiation and block sessions that can’t be decrypted:

• Configure the SSL Decryption > SSL Protocol Settings to block use of vulnerable SSL/TLS versions (TLS 1.0 and SSLv3) and to avoid weak algorithms (MD5, RC4, and 3DES):





Best Practice Decryption Profile (Continued)

• For traffic that you are not decrypting, configure the No Decryption settings to to block encrypted sessions to sites with expired certificates or untrusted issuers:

Policy

Create Best Practice Security Profiles

Most malware sneaks onto the network in legitimate applications or services. Therefore, to safely enable applications you must scan all traffic allowed into the network for threats. To do this, attach security profiles to all Security policy rules that allow traffic so that you can detect threats—both known and unknown—in your network traffic. The following are the recommended best practice settings for each of the security profiles that you should attach to every Security policy rule.

Consider adding the best practice security profiles to a default security profile group so that it will automatically attach to any new Security policy rules you create.





Security Profile Best Practice Settings

File Blocking Create a File Blocking profile that blocks files that are commonly included in malware attack campaigns or that have no real use case for upload/download. Currently, these include batch files, DLLs, Java class files, help files, Windows shortcuts (.lnk), and BitTorrent files as well as

Windows Portable Executable (PE) files, which include .exe, .cpl, .dll, .ocx, .sys, .scr, .drv, .efi, .fon, and .pif files. You can allow download/upload of executables and archive files (.zip and .rar), but force users to click continue before transferring a file to give them pause. Finally, alert on all other file types for visibility into what other file transfers are happening so that you can determine if you need to make policy changes.

Antivirus

Why do I need this profile?

There are many ways for attackers to deliver malicious files: As attachments or links in corporate email or in webmail, links or IMs in social media, Exploit Kits, through file sharing applications

(such as FTP, Google Drive, or Dropbox), or on USB drives. Attaching a File Blocking profile reduces your attack surface by preventing these types of attacks.

What if I can’t block all of the recommended file types?

If you cannot block all PE files per the recommendation, make sure you send all unknown files to WildFire for analysis. Additionally, set the Action to continue to prevent drive‐by downloads.

A drive‐by download is when an end user downloads content that installs malicious files, such as Java applets or executables, without knowing they are doing it. Drive‐by downloads can occur when users visit web sites, view email messages, or click into pop‐up windows meant to deceive them. Educate your users that if they are prompted to continue with a file transfer they didn’t knowingly initiate, they may be subject to a malicious download.

Attach an Antivirus profile to all allowed traffic to detect and prevent viruses and malware from being transferred over the HTTP, SMTP, IMAP, POP3, FTP, and SMB protocols. The best practice Antivirus profile uses the default action when it detects traffic that matches either an

Antivirus signature or a WildFire signature. The default action differs for each protocol and follows the most up‐to‐date recommendation from Palo Alto Networks for how to best prevent malware in each type of protocol from propagating.

By default, the firewall alerts on viruses found in SMTP traffic. However, if you don’t have a dedicated Antivirus gateway solution in place for your SMTP traffic, define a stricter action for this protocol to protect against infected email content. Use the reset‐both action to return a 541 response to the sending SMTP server to prevent it from resending the blocked message.


By attaching Antivirus profiles to all Security rules you can block known malicious files (malware, ransomware bots, and viruses) as they are coming into the network. Common ways for users to receive malicious files include malicious attachments in email, links to download malicious files, or silent compromise with Exploit Kits that exploit a vulnerability and then automatically deliver malicious payloads to the end user.






Vulnerability

Protection

Attach a Vulnerability Protection profile to all allowed traffic to protect against buffer overflows, illegal code execution, and other attempts to exploit client‐ and server‐side vulnerabilities. The best practice profile is a clone of the predefined Strict profile, with packet capture settings enabled to help you track down the source of any potential attacks.

Policy

Anti-Spyware


Without strict vulnerability protection, attackers can leverage client‐ and server‐side vulnerabilities to compromise end‐users. For example, an attacker could leverage a vulnerability to install malicious code on client systems or use an Exploit Kit ( Angler , Nuclear, Fiesta, KaiXin) to automatically deliver malicious payloads to the end user. Vulnerability Protection profiles also prevent an attacker from using vulnerabilities on internal hosts to move laterally within your network.

Attach an Anti‐Spyware profile to all allowed traffic to detect command and control traffic (C2) initiated from spyware installed on a server or endpoint and prevents compromised systems from establishing an outbound connection from your network. The best practice Anti‐Spyware profile resets the connection when the firewall detects a medium, high, or critical severity threat and blocks or sinkholes any DNS queries for known malicious domains.

To create this profile, clone the predefined strict profile and make sure to enable DNS sinkhole and packet capture to help you track down the endpoint that attempted to resolve the malicious domain. For the best possible protection, enable passive DNS monitoring, which enables the firewall to act as a passive DNS sensor and send select

DNS information to Palo Alto Networks for analysis in order to improve threat intelligence and threat prevention capabilities.






URL Filtering As a best practice, use PAN‐DB URL filtering to prevent access to web content that is at high‐risk for being malicious. Attach a URL Filtering profile to all rules that allow access to web‐based applications to protect against URLs that have been observed hosting malware or exploitive content.

The best practice URL Filtering profile sets all known dangerous URL categories to block. These include malware, phishing, dynamic DNS, unknown, proxy‐avoidance‐and‐anonymizers, questionable, and parked. Failure to block these dangerous categories puts you at risk for exploit infiltration, malware download, command and control activity, and data exfiltration.

In addition to blocking known bad categories, you should also alert on all other categories so that you have visibility into the sites your users are visiting. If you need to phase in a block policy, set categories to continue and create a custom response page to educate users on your acceptable use policies and alert them to the fact that they are visiting a site that may pose a threat. This will pave the way for you to outright block the categories after a monitoring period.

What if I can’t block all of the recommended categories?

If you find that users need access to sites in the blocked categories, consider creating an allow list for just the specific sites, if you feel the risk is justified. Allowing traffic to a recommended block category poses the following risks:

• malware—Sites known to host malware or used for command and control (C2) traffic. May also exhibit Exploit Kits.

• phishing—Known to host credential phishing pages or phishing for personal identification.

• dynamic-dns—Hosts and domain names for systems with dynamically assigned IP addresses and which are oftentimes used to deliver malware payloads or C2 traffic. Also, dynamic DNS domains do not go through the same vetting process as domains that are registered by a reputable domain registration company, and are therefore less trustworthy.

• unknown—Sites that have not yet been identified by PAN‐DB, perhaps because they were just registered. However, oftentimes these are sites that are generated by domain generation algorithms and are later found to exhibit malicious behavior.

• proxy-avoidance-and-questionable—URLs and services often used to bypass content filtering products.

• questionable—Domains with illegal content, such as content that infringes on copyrights or that allows illegal download of software or other intellectual property.

• parked—Domains registered by individuals, oftentimes later found to be used for credential phishing. These domains may be similar to legitimate domains, for example, pal0alto0netw0rks.com, with the intent of phishing for credentials or personal identify information. Or, they may be domains that an individual purchases rights to in hopes that it may be valuable someday, such as panw.net.






WildFire

Analysis

While the rest of the best practice security profiles significantly reduce the attack surface on your network by detecting and blocking known threats, the threat landscape is ever changing and the risk of unknown threats lurking in the files we use daily—PDFs, Microsoft Office documents (.doc and .xls files)—is ever growing. And, because these unknown threats are increasingly sophisticated and targeted, they often go undetected until long after a successful attack. To protect your network from unknown threats, you must configure the firewall to forward files to WildFire for analysis. Without this protection, attackers have free reign to infiltrate your network and exploit vulnerabilities in the applications your employees use everyday. Because WildFire protects against unknown threats, it is your greatest defense against advanced persistent threats (APTs).

The best practice WildFire Analysis profile sends all files in both directions (upload and download) to WildFire for analysis. Specifically, make sure you are sending all PE files (if you’re not blocking them per the file blocking best practice), Adobe Flash and Reader files (PDF, SWF),

Microsoft Office files (PowerPoint, Excel, Word, RTF), Java files (Java, .CLASS), and Android files

(.APK).

Define the Initial Internet Gateway Security Policy

The overall goal of a best practice Internet gateway security policy is to use positive enforcement of whitelist applications. However, it takes some time to identify exactly what applications are running on your network, which of these applications are critical to your business, and who the users are that need access to each one.

The best way to accomplish the end goal of a policy rulebase that includes only application allow rules is to create an initial policy rulebase that liberally allows both the applications you officially provision for your users as well as other general business and, if appropriate, personal applications. This initial policy also includes additional rules that explicitly block bad applications as well as some temporary allow rules that are designed to help you refine your policy and prevent applications your users may need from breaking while you transition to the best practices.

The following topics describe how to create the initial rulebase and describe why each rule is necessary and what the risks are of not following the best practice recommendation:

 Step 1: Create the Application Whitelist Rules







Step 2: Create the Application Block Rules

Step 3: Create the Temporary Tuning Rules

Step 4: Enable Logging for Traffic that Doesn’t Match Any Rules





Step 1: Create the Application Whitelist Rules

After you Identify Whitelist Applications you are ready to create the first part of the best practice Internet

Gateway Security policy rulebase: the application whitelist rules. Every whitelist rule you create must allow traffic based on application (not port) and, with the exception of certain infrastructure applications that require user access before the firewall can identify the user, must only allow access to known users.

Whenever possible, Create User Groups for Access to Whitelist Applications so that you can limit user access to the specific users or user groups who have a business need to access the application.

When creating the application whitelist rules, make sure to place more specific rules above more general rules. For example, the rules for all of your sanctioned and infrastructure applications would come before the rules that allow general access to certain types of business and personal applications. This first part of the rulebase includes the allow rules for the applications you identified as part of your application whitelist:







Sanctioned applications you provision and administer for business and infrastructure purposes

General business applications that your users may need to use in order to get their jobs done

General applications you may choose to allow for personal use

Every application whitelist rule also requires that you attach the best practice security profiles to ensure that you are scanning all allowed traffic for known and unknown threats. If you have not yet created these profiles, see Create Best Practice Security Profiles . And, because you can’t inspect what you can’t see, you must also make sure you have configured the firewall to Decrypt Traffic for Full Visibility and Threat

Inspection .

Create the Application Whitelist Rules

Step 1 Allow access to your corporate DNS servers.

Why do I need this rule?

 Access to DNS is required to provide network infrastructure services, but it is commonly exploited by attackers.

 Allowing access only on your internal DNS server reduces your attack surface.

Rule Highlights

• Because this rule is very specific, place it at the top of the rulebase.

• Create an address object to use for the destination address to ensure that users only access the DNS server in your data center.

• Because users will need access to these services before they are logged in, you must allow access to any user.

Step 2 Allow access to other required IT infrastructure resources.


 Enable the applications that provide your network infrastructure and management functions, such as NTP, OCSP, STUN, and ping.

 While DNS traffic allowed in the preceding rule is restricted to the destination address in the data center, these applications may not reside in your data center and therefore require a separate rule.

Rule Highlights

• Because these applications run on the default port, allow access to any user (users may not yet be a known‐user because of when these services are needed), and all have a destination address of any, contain them in a single application group and create a single rule to enable access to all of them.

• Users may not have logged in yet at the time they need access to the infrastructure applications, so make sure this rule allows access to any user.





Create the Application Whitelist Rules (Continued)

Policy

Step 3 Allow access to IT sanctioned SaaS applications.


 With SaaS applications, your proprietary data is in the cloud. This rule ensures that only your known users have access to these applications (and the underlying data).

 Scan allowed SaaS traffic for threats.

Rule Highlights

• Group all sanctioned SaaS applications in an application group .

• SaaS applications should always run on the application default port.

• Restrict access to your known users. See Create User Groups for

Access to Whitelist Applications .

Step 4 Allow access to IT provisioned on‐premise applications.


 Business‐critical data center applications are often leveraged in attacks during the exfiltration stage, using applications such as

FTP, or in the lateral movement stage by exploiting application vulnerabilities.

 Many data center applications use multiple ports; setting the Service to application‐default safely enables the applications on their standard ports. You should not allow applications on non‐standard ports because it is often associated with evasive behavior.

Rule Highlights

• Group all data center applications in an application group .

• Create an address group for your data center server addresses.



Step 5 Allow access to applications your administrative users need.


 To reduce your attack surface, Create User

Groups for Access to Whitelist Applications .

 Because administrators often need access to sensitive account data and remote access to other systems (for example RDP), you can greatly reduce your attack surface by only allowing access to the administrators who have a business need.

Rule Highlights

• This rule restricts access to users in the IT_admins group.

• Create custom applications for internal applications or applications that run on non‐standard ports so that you can enforce them on their default ports rather than opening additional ports on your network.

• If you have different user groups for different applications, create separate rules for granular control.






Step 6 Allow access to general business applications.


 Beyond the applications you sanction for use and administer for your users, there are a variety of applications that users may commonly use for business purposes, for example to interact with partners, such as

WebEx, Adobe online services, or Evernote, but which you may not officially sanction.

 Because malware often sneaks in with legitimate web‐based applications, this rule allows you to safely allow web browsing while still scanning for threats. See Create

Best Practice Security Profiles .

Rule Highlights



• For visibility, create separate application filters for each type of application you want to allow.

• Attach the best practice security profiles to ensure that all traffic is free of known and unknown threats. See Create Best Practice

Security Profiles .

Step 7 (Optional) Allow access to personal applications.


 As the lines blur between work and personal devices, you want to ensure that all applications your users access are safely enabled and free of threats.

 By using application filters, you can safely enable access to personal applications when you create this initial rulebase. After you assess what applications are in use, you can use the information to decide whether to remove the filter and allow a smaller subset of personal applications appropriate for your acceptable use policies.

Rule Highlights



• For visibility, create separate application filters for each type of application you want to allow.

• Scan all traffic for threats by attaching your best practice security profile group. See Create Best Practice Security

Profiles .






Step 8 Allow general web browsing.


 While the previous rule allowed access to personal applications (many of them browser‐based), this rule allows general web browsing.

 General web browsing is more risk‐prone than other types of application traffic. You must Create Best Practice Security Profiles and attach them to this rule in order to safely enable web browsing.

 Because threats often hide in encrypted traffic, you must Decrypt Traffic for Full

Visibility and Threat Inspection if you want to safely enable web browsing.

Rule Highlights

• This rule uses the same best practice security profiles as the rest of the rules, except for the File Blocking profile, which is more stringent because general web browsing traffic is more vulnerable to threats.

• This rule allows only known users to prevent devices with malware or embedded devices from reaching the Internet.

• Use application filters to allow access to general types of applications.

• Make sure you also explicitly allow SSL as an application here if you want to allow users to be able to browse to HTTPS sites. that are excluded from decryption.

Step 2: Create the Application Block Rules

Although the overall goal of your security policy is to safely enable applications using application whitelist rules (also known as positive enforcement), the initial best practice rulebase must also include rules to help you find gaps in your policy and identify possible attacks. Because these rules are designed to catch things you didn’t know were running on your network, they allow traffic that could also pose security risks on your network. Therefore, before you can create the temporary rules, you must create rules that explicitly blacklist applications designed to evade or bypass security or that are commonly exploited by attackers, such as public DNS and SMTP, encrypted tunnels, remote access, and non‐sanctioned file‐sharing applications.

Each of the tuning rules you will define in Step 3: Create the Temporary Tuning Rules are designed to identify a specific gap in your initial policy. Therefore some of these rules will need to go above the application block rules and some will need to go after.





Create the Application Block Rules

Step 1 Block applications that do not have a legitimate use case.


 Block nefarious applications such as encrypted tunnels and peer‐to‐peer file sharing, as well as web‐based file sharing applications that are not IT sanctioned.

 Because the tuning rules that follow are designed to allow traffic with malicious intent or legitimate traffic that is not matching your policy rules as expected, these rules could also allow risky or malicious traffic into your network. This rule prevents that by blocking traffic that has no legitimate use case and that could be used by an attacker or a negligent user.

Rule Highlights

• Use the Drop Action to silently drop the traffic without sending a signal to the client or the server.

• Enable logging for traffic matching this rule so that you can investigate misuse of applications and potential threats on your network.

• Because this rule is intended to catch malicious traffic, it matches to traffic from any user running on any port.

Step 2 Block public DNS and SMTP applications.


 Block public DNS/SMTP applications to avoid

DNS tunneling, command and control traffic, and remote administration.

Rule Highlights

• Use the Reset both client and server Action to send a TCP reset message to both the client‐side and server‐side devices.

• Enable logging for traffic matching this rule so that you can investigate a potential threat on your network.

Step 3: Create the Temporary Tuning Rules

The temporary tuning rules are explicitly designed to help you monitor the initial best practice rulebase for gaps and alert you to alarming behavior. For example, you will create temporary rules to identify traffic that is coming from unknown user or applications running on unexpected ports. By monitoring the traffic matching on the temporary rules you can also gain a full understanding of all of the applications in use on your network (and prevent applications from breaking while you transition to a best practice rulebase). You can use this information to help you fine tune your whitelist, either by adding new whitelist rules to allow applications you weren’t aware were needed or to narrow your whitelist rules to remove application filters and instead allow only specific applications in a particular category. When traffic is no longer hitting these rules you can Remove the Temporary Rules .

Some of the temporary tuning rules must go above the rules to block bad applications and some must go after to ensure that targeted traffic hits the appropriate rule, while still ensuring that bad traffic is not allowed onto your network.





Create Temporary Tuning Rules

Step 1 Allow web‐browsing and SSL on non‐standard ports for known users to determine if there are any legitimate applications running on non‐standard ports.


 This rule helps you determine if you have any gaps in your policy where users are unable to access legitimate applications because they are running on non‐standard ports.

 You must monitor all traffic that matches this rule. For any traffic that is legitimate, you should tune the appropriate allow rule to include the application, perhaps creating a custom application where appropriate.

Rule Highlights

• Unlike the whitelist rules that allow applications on the default port only, this rule allows web‐browsing and SSL traffic on any port so that you can find gaps in your whitelist.

• Because this rule is intended to find gaps in policy, limit it to known users on your network. See Create User Groups for


• Make sure you also explicitly allow SSL as an application here if you want to allow users to be able to browse to HTTPS sites that aren’t decrypted (such as financial services and healthcare sites).

• You must add this rule above the application block rules or no traffic will hit this rule.

Step 2 Allow web‐browsing and SSL traffic on non‐standard ports from unknown users to highlight all unknown users regardless of port.


 This rule helps you determine whether you have gaps in your User‐ID coverage.

 This rule also helps you identify compromised or embedded devices that are trying to reach the Internet.

 It is important to block non‐standard port usage, even for web‐browsing traffic, because it is usually an evasion technique.

Rule Highlights

• While the majority of the application whitelist rules apply to known users or specific user groups, this rule explicitly matches traffic from unknown users.

• Note that this rule must go above the application block rules or traffic will never hit it.

• Because it is an allow rule, you must attach the best practice security profiles to scan for threats.

Step 3 Allow all applications on the application‐default port to identify unexpected applications.


 This rule provides visibility into applications that you weren’t aware were running on your network so that you can fine‐tune your application whitelist.

 Monitor all traffic matching this rule to determine whether it represents a potential threat, or whether you need to modify your whitelist rules to allow the traffic.

Rule Highlights

• Because this rule allows all applications, you must add it after the application block rules to prevent bad applications from running on your network.

• If you are running PAN‐OS 7.0.x or earlier, to appropriately identify unexpected applications, you must use an application filter that includes all applications, instead of setting the rule to allow any application.





Create Temporary Tuning Rules

Step 4 Allow any application on any port to identify applications running where they shouldn’t be.


 This rule helps you identify legitimate, known applications running on unknown ports.

 This rule also helps you identify unknown applications for which you need to create a custom application to add to your application whitelist.

 Any traffic matching this rule is actionable and requires that you track down the source of the traffic and ensure that you are not allowing any unknown tcp, udp or non‐syn‐tcp traffic.

Rule Highlights

• Because this is a very general rule that allows any application from any user on any port, it must come at the end of your rulebase.

• Enable logging for traffic matching this rule so that you can investigate for misuse of applications and potential threats on your network or identify legitimate applications that require a custom application.

Step 4: Enable Logging for Traffic that Doesn’t Match Any Rules

Traffic that does not match any of the rules you defined will match the predefined interzone‐default rule at the bottom of the rulebase and be denied. For visibility into the traffic that is not matching any of the rules you created, enable logging on the interzone‐default rule:

Enable Logging for Traffic That Doesn’t Match Any Rules

Step 1 Select the interzone‐default row in the rulebase and click Override to enable editing on this rule.

Step 2 Select the interzone-default rule name to open the rule for editing.

Step 3 On the Actions tab, select Log at Session End and click OK.

Step 4 Create a custom report to monitor traffic that hits this rule.

1. Select Monitor > Manage Custom Reports.

2.

Add

a report and give it a descriptive Name.

3. Set the Database to Traffic Summary.

4. Select the Scheduled check box.

5. Add the following to the Selected Columns list: Rule, Application, Bytes, Sessions.

6. Set the desired Time Frame, Sort By and Group By fields.

7. Define the query to match traffic hitting the interzone‐default rule:

(rule eq 'interzone-default')

Step 5

Commit

the changes you made to the rulebase.





Monitor and Fine Tune the Policy Rulebase

A best practice security policy is iterative. It is a tool for safely enabling applications, users, and content by classifying all traffic, across all ports, all the time. As soon as you Define the Initial Internet Gateway Security

Policy , you must begin to monitor the traffic that matches the temporary rules designed to identify policy gaps and alarming behavior and tune your policy accordingly. By monitoring traffic hitting these rules, you can make appropriate adjustments to your rules to either make sure all traffic is hitting your whitelist application allow rules or assess whether particular applications should be allowed. As you tune your rulebase, you should see less and less traffic hitting these rules. When you no longer see traffic hitting these rules, it means that your positive enforcement whitelist rules are complete and you can Remove the

Temporary Rules .

Because new App‐IDs are added in weekly content releases, you should review the impact the changes in

App‐IDs have on your policy .

Identify Policy Gaps

Step 1 Create custom reports that let you monitor traffic that hits the rules designed to identify policy gaps.

1. Select Monitor > Manage Custom Reports.

2.

Add

a report and give it a descriptive Name that indicates the particular policy gap you are investigating, such as Best Practice Policy Tuning.

3. Set the Database to Traffic Summary.

4. Select the Scheduled check box.

5. Add the following to the Selected Columns list: Rule, Application, Bytes, Sessions.

6. Set the desired Time Frame, Sort By and Group By fields.

7. Define the query to match traffic hitting the rules designed to find policy gaps and alarming behavior. You can create a single report that details traffic hitting any of the rules (using the or operator), or create individual reports to monitor each rule. Using the rule names defined in the example policy, you would enter the corresponding queries:

• (rule eq 'Unexpected Port SSL and Web')

• (rule eq 'Unknown User SSL and Web')

• (rule eq 'Unexpected Traffic')

• (rule eq 'Unexpected Port Usage')





Identify Policy Gaps (Continued)

Step 2 Review the report regularly to make sure you understand why traffic is hitting each of the best practice policy tuning rules and either update your policy to include legitimate applications and users, or use the information in the report to assess the risk of that application usage and implement policy reforms.

Remove the Temporary Rules

After several months of monitoring your initial Internet Gateway best practice Security policy, you should see less and traffic hitting the temporary rules as you make adjustments to the rulebase. When you no longer see any traffic hitting these rules, you have achieved your goal of transitioning to a fully application‐based

Security policy rulebase. At this point, you can finalize your policy rulebase by removing the temporary rules, which includes the rules you created to block bad applications and the rules you created for tuning the rulebase.

Remove the Temporary Rules

Step 1 Select Policies > Security.

Step 2 Select the rule and click Delete.

Alternatively, Disable the rules for a period of time before deleting them. This would allow you to Enable them again if traffic logs show traffic matching the interzone‐default rule.

Step 3

Commit

the changes.





Maintain the Rulebase

Because applications are always evolving, your application whitelist will need to evolve also. Each time you make a change in what applications you sanction, you must make a corresponding policy change. As you do this, instead of just adding a new rule like you would do with a port‐based policy, instead identify and modify the rule that aligns with the business use case for the application. Because the best practice rules leverage policy objects for simplified administration, adding support for a new application or removing an application from your whitelist typically means modifying the corresponding application group or application filter accordingly.

Additionally, installing new App‐IDs included in a content release version can sometimes cause a change in policy enforcement for applications with new or modified App‐IDs. Therefore, before installing a new content release, review the policy impact for new App‐IDs and stage any necessary policy updates. Assess the treatment an application receives both before and after the new content is installed. You can then modify existing Security policy rules using the new App‐IDs contained in a downloaded content release

(prior to installing the App‐IDs). This enables you to simultaneously update your security policy rules and install new content, and allows for a seamless shift in policy enforcement. Alternatively, you can choose to disable new App‐IDs when installing a new content release version; this enables protection against the latest threats, while giving you the flexibility to enable the new App‐IDs after you've had the chance to prepare any policy changes.

Maintain the Best Practice Rulebase

Step 1 Before installing a new content release version, review the new App‐IDs to determine if there is policy impact.

Step 2 Disable new App‐IDs introduced in a content release, in order to immediately benefit from protection against the latest threats while continuing to have the flexibility to later enable App‐IDs after preparing necessary policy updates. You can disable all App‐IDs introduced in a content release, set scheduled content updates to automatically disable new App‐IDs, or disable App‐IDs for specific applications.

Step 3 Tune security policy rules to account for App‐ID changes included in a content release or to add new sanctioned applications to or remove applications from your application whitelist rules.




Policy Enumeration of Rules Within a Rulebase

Enumeration of Rules Within a Rulebase

Each rule within a rulebase is automatically numbered and the ordering adjusts as rules are moved or reordered. When filtering rules to find rules that match the specified 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.

On Panorama, pre‐rules, post‐rules, and default rules are independently numbered. When Panorama pushes rules to a firewall, the rule numbering reflects the hierarchy and evaluation order of shared rules, device group pre‐rules, firewall rules, device group post‐rules, and default rules. The

Preview Rules

option in

Panorama displays an ordered list view of the total number of rules on a firewall

.

View the Ordered List of Rules Within a Rulebase

• View the numbered list of rules on the firewall.

Select Policies and any rulebase under it. For example, Policies > Security. The left‐most column in the table displays the rule number.

• View the numbered list of rules on Panorama.

Select Policies and any rulebase under it. For example, Policies > Security> Pre-rules.

• After you push the rules from Panorama, view the complete list of rules with numbers on the firewall.

From the web interface of the firewall, select Policies and pick any rulebase under it. For example, select Policies >

Security

and view the complete set of numbered rules that the firewall will evaluate.




Move or Clone a Policy Rule or Object to a Different Virtual System Policy

Move or Clone a Policy Rule or Object to a Different Virtual

System

On a firewall that has more than one virtual system (vsys), you can move or clone policy rules and objects to a different vsys or to the Shared location. Moving and cloning save you the effort of deleting, recreating, or renaming rules and objects. If the policy rule or object that you will move or clone from a vsys has references to objects in that vsys, move or clone the referenced objects also. If the references are to shared objects, you do not have to include those when moving or cloning. You can Use Global Find to Search the Firewall or

Panorama Management Server for references.

Move or Clone a Policy Rule or Object to a Virtual System

Step 1 Select the policy type (for example, Policy > Security) or object type (for example, Objects > Addresses).

Step 2 Select the Virtual System and select one or more policy rules or objects.

Step 3 Perform one of the following steps:

• Select Move > Move to other vsys (for policy rules).

• Click Move (for objects).

• Click Clone (for policy rules or objects).

Step 4 In the Destination drop‐down, select the new virtual system or Shared. The default is the Virtual System selected in Step 2 .

Step 5 (Policy rules only) Select the Rule order:

• Move top (default)—The rule will come before all other rules.

• Move bottom—The rule will come after all other rules.

• Before rule—In the adjacent drop‐down, select the rule that comes after the Selected Rules.

• After rule—In the adjacent drop‐down, select the rule that comes before the Selected Rules.

Step 6 The Error out on first detected error in validation check box is selected by default. The firewall stops performing the checks for the move or clone action when it finds the first error, and displays just this error.

For example, if an error occurs when the Destination vsys doesn’t have an object that the policy rule you are moving references, the firewall will display the error and stop any further validation. When you move or clone multiple items at once, selecting this check box will allow you to find one error at a time and troubleshoot it.

If you clear the check box, the firewall collects and displays a list of errors. If there are any errors in validation, the object is not moved or cloned until you fix all the errors.

Step 7 Click OK to start the error validation. If the firewall displays errors, fix them and retry the move or clone operation. If the firewall doesn’t find errors, the object is moved or cloned successfully. After the operation finishes, click Commit.




Policy Use Tags to Group and Visually Distinguish Objects


You can tag objects to group related items and add color to the tag in order to visually distinguish them for easy scanning. You can create tags for the following objects: address objects, address groups, zones, service groups, and policy rules.

The firewall and Panorama support both static tags and dynamic tags. Dynamic tags are registered from a variety of sources and are not displayed with the static tags because dynamic tags are not part of the firewall/Panorama configuration. See Register IP Addresses and Tags Dynamically for information on registering tags dynamically. The tags discussed in this section are statically added and are part of the configuration.

You can apply one or more tags to objects and to policy rules, up to a maximum of 64 tags per object device groups) and the managed firewalls (including firewalls with multiple virtual systems).

.

Panorama supports a maximum of 10,000 tags, which you can apportion across Panorama (shared and

 Create and Apply Tags





Modify Tags

Use the Tag Browser

Create and Apply Tags

Create and Apply Tags

Step 1 Create tags.

To tag a zone, you must create a tag with the same name as the zone. When the zone is attached in policy rules, the tag color automatically displays as the background color against the zone name.

1.

Select Objects > Tags.

2.

On Panorama or a multiple virtual system firewall, select the

Device Group

or the Virtual System to to make the tag available.

3.

Click Add and enter a Name to identify the tag, or select a zone name from the drop‐down to create a tag for a zone. The maximum length is 127 characters.

4.

(Optional) Select Shared to create the object in a shared location for access as a shared object in Panorama or for use across all virtual systems in a multiple virtual system firewall.

5.

(Optional) Assign one of the 17 predefined colors to the tag.

By default, Color is None.

6.

Click OK and Commit to save the changes.





Create and Apply Tags (Continued)

Step 2 Apply tags to policy.

Policy

1.

Select Policies and any rulebase under it.

2.

Click Add to create a policy rule and use the tagged objects you created in Step 1.

3.

Verify that the tags are in use.

Step 3 Apply tags to an address object, address group, service, or service group.

1.

Create the object.

For example to create a service group, select Objects >

Service Groups > Add

.

2.

Select a tag from the Tags drop‐down or enter a name in the field to create a new tag.

To edit a tag or add color to the tag, see Modify Tags .

Modify Tags

Modify Tags

• Select Objects > Tags to perform any of the following operations with tags:

• Click the link in the Name column to edit the properties of a tag.

• Select a tag in the table, and click Delete to remove the tag from the firewall.

• Click Clone to create a duplicate tag with the same properties. A numerical suffix is added to the tag name.

For example, FTP‐1.

For details on creating tags, see Create and Apply Tags . For information on working with tags, see Use the

Tag Browser .

Use the Tag Browser

The tag browser provides a way to view all the tags used within a rulebase. In rulebases with a large number of rules, the tag browser simplifies the display by presenting the tags, the color code, and the rule numbers in which the tags are used.

It also allows you to group rules using the first tag applied to the rule. As a best practice, use the first tag to identify the primary purpose for a rule. For example, the first tag can identify a rule by a high‐level function such as best practice, or Internet access or IT sanctioned applications or high‐risk applications. In the tag browser, when you

Filter by first tag in rule

, you can easily identify gaps in coverage and move rules or add new rules within the rulebase. All the changes are saved to the candidate configuration until you commit the changes on the firewall and make them a part of the running configuration.

For firewalls that are managed by Panorama, the tags applied to pre‐rules and post‐rules that have been pushed from Panorama, display in a green background and are demarcated with green lines so that you can identify these tags from the local tags on the firewall.




Policy Use Tags to Group and Visually Distinguish Objects





Use the Tag Browser

• Explore the tag browser.

Policy

1.

Access the Tag Browser on the left pane of the Policies > tab.

The tag browser displays the tags that have been used in the rules for the selected rulebase, for example Policies >

Security

.

2.

Tag (#)

—Displays the label and the rule number or range of numbers in which the tag is used contiguously. Hover over the label to see the location where the rule was defined, it can be inherited from a shared location, a device group, or a virtual system.

3.

Rule

—Lists the rule number or range of numbers associated with the tags.

4.

Sort the tags.

• Filter by first tag in rule—Sorts rules using the first tag applied to each rule in the rulebase. This view is particularly useful if you want to narrow the list and view related rules that might be spread around the rulebase. For example if the first tag in each rule denotes its function—best practices, administration, web‐access, data center access, proxy—you can narrow the result and scan the rules based on function.

• Rule Order—Sorts the tags in the order of appearance within the selected rulebase. When displayed in order of appearance, tags used in contiguous rules are grouped. The rule number with which the tag is associated is displayed along with the tag name.

• Alphabetical—Sorts the tags in alphabetical order within the selected rulebase. The display lists the tag name and color (if a color is assigned) and the number of times it is used within the rulebase.

The label None represents rules without any tags; it does not display rule numbers for untagged rules. When you select None, the right pane is filtered to display rules that have no tags assigned to them.

5.

Clear

—Clears the filter on the currently selected tags in the search bar.

6.

Search bar

—To search for a tag, enter the term and click the green arrow icon to apply the filter. It also displays the total number of tags in the rulebase and the number of selected tags.

7.

Expand or collapse the tag browser.




Policy

Use the Tag Browser (Continued)

• Tag a rule.


1.

Select a rule on the right pane.

2.

Do one of the following:

• Select a tag in the tag browser and select Apply the Tag to the Selection(s)

from the drop‐down.

• Drag and drop tag(s) from the tag browser on to the Tags column of the rule. When you drop a tag, a confirmation dialog displays.

3.

Commit

the changes.

• View rules that match the selected tags.

You can filter rules based on tags with an AND or an OR operator.

• OR filter: To view rules that have specific tags, select one or more tags in the tag browser; the right pane only displays the rules that include any of the currently selected tags.

• AND filter: To view rules that have all the selected tags, hover over the number associated with the tag in the Rule column of the tag browser and select Filter. Repeat to add more tags.

Click the apply filter icon in the search bar on the right pane. The results are displayed using an AND operator.

• View the currently selected tags.

To view the currently selected tags, hover over the Clear label in the tag browser.

• Untag a rule.

Hover over the rule number associated with a tag in the Rule column of the tag browser and select Untag Rule(s). Confirm that you want to remove the selected tag from the rule. Commit the changes.




Use Tags to Group and Visually Distinguish Objects Policy

Use the Tag Browser (Continued)

• Reorder rules using tags.

Select one or more tags and hover over the rule number in the Rule column of the tag browser and select Move Rule(s).

Select a tag from the drop‐down in the move rule window and select whether you want to Move Before or Move After the tag selected in the drop‐down. Commit the changes.

• Add a new rule that applies the selected tags.

Select one or more tags and hover over the rule number in the Rule column of the tag browser, and select Add New Rule. Define the rule and Commit the changes.

The numerical order of the new rule varies by whether you selected a rule on the right pane. If you did not select a rule on the right pane, the new rule will be added after the rule to which the selected tag(s) belongs. Otherwise, the new rule is added after the selected rule.

• Search for a tag.

In the tag browser, enter the first few letters of the tag name you want to search for and click the Apply Filter icon. The tags that match your input will display.




Policy



An external dynamic list (formerly called dynamic block list) is a text file that you host on an external web server so that the firewall can import objects—IP addresses, URLs, domains—to enforce policy on the entries in the list. As you update the list, the firewall dynamically imports the list at the configured interval and enforces policy without the need to make a configuration change or a commit on the firewall.

 External Dynamic List





Formatting Guidelines for an External Dynamic List

Enforce Policy on Entries in an External Dynamic List





View the List of Entries in an External Dynamic List

Retrieve an External Dynamic List from the Web Server

External Dynamic List

An External Dynamic List is a text file that is hosted on an external web server so that the firewall can import objects—IP addresses, URLs, domains—included in the list and enforce policy. To enforce policy on the entries included in the external dynamic list, you must reference the list in a supported policy rule or profile.

As you modify the list, the firewall dynamically imports the list at the configured interval and enforces policy without the need to make a configuration change or a commit on the firewall. If the web server is unreachable, the firewall will use the last successfully retrieved list for enforcing policy until the connection is restored with the web server. To retrieve the external dynamic list, the firewall uses the interface attached to the service route that it uses to access the Palo Alto Updates service.

The firewall supports three types of external dynamic lists:



IP Address—The firewall typically enforces policy for a source or destination IP address that is defined as a static object on the firewall. If you need agility in enforcing policy for a list of source or destination IP addresses that emerge ad hoc, you can use an external dynamic list of type IP address as a source or destination address object in policy rules, and configure the firewall to deny or allow access to the IP addresses (IPv4 and IPv6 address, IP range and IP subnets) included in the list. The firewall treats an external dynamic list of type IP address as an address object; all the IP addresses included in a list are handled as one address object.





URL—An external dynamic list of type URL gives you the agility to protect your network from new sources of threat or malware. The firewall handles an external dynamic list with URLs like a custom URL category and you can use this list in two ways:

– As a match criteria in Security policy rules, Decryption policy rules, and QoS policy rules to allow, deny, decrypt, not decrypt, or allocate bandwidth for the URLs in the custom category.

– In a URL Filtering profile where you can define more granular actions, such as continue, alert, or override, before you attach the profile to a Security policy rule.

Domain—An external dynamic list of type domain allows you to import custom domain names into the firewall to enforce policy using an Anti‐Spyware profile. This capability is very useful if you subscribe to third‐party threat intelligence and want to protect your network from new sources of threat or malware as soon as you learn of a malicious domain. For each domain you include in the external dynamic list, the firewall creates a custom DNS‐based spyware signature so that you can enable DNS sinkholing. The




Use an External Dynamic List in Policy Policy

DNS‐based spyware signature is of type spyware with medium severity and each signature is named

Custom Malicious DNS Query <domain name>

. For details, see Configure DNS Sinkholing for a

List of Custom Domains .

On each firewall platform, you can configure a maximum of 30 unique sources for external dynamic lists; these limits are not applicable to Panorama. When using Panorama to manage a firewall that is enabled for multiple virtual systems, if you exceed the limit for the firewall, a commit error displays on Panorama. A source is a URL that includes the IP address or hostname, the path, and the filename for the external dynamic list. The firewall matches the URL (complete string) to determine whether a source is unique.

While the firewall does not impose a limit on the number of lists of a specific type, the following limits are enforced:





IP address—The PA‐5000 Series and the PA‐7000 Series firewalls support a maximum of 150,000 total

IP addresses; all other platforms support a maximum of 50,000 total IP addresses. No limits are enforced for the number of IP addresses per list. When the maximum supported IP address limit is reached on the firewall, the firewall generates a syslog message.

URL and domain—A maximum of 50,000 URLs and 50,000 domains are supported on each platform, with no limits enforced on the number of entries per list.

When parsing the list, the firewall skips entries that do not match the list type, and ignores entries that exceed the maximum number supported for the platform.

Formatting Guidelines for an External Dynamic List

An external dynamic list of one type —IP address, URL or Domain—must include entries of that type only.

 IP Address List





Domain List

URL List

IP Address List

The external dynamic list can include individual IP addresses, subnet addresses (address/mask), or range of

IP addresses. In addition, the block list can include comments and special characters such as * , : , ; , #, or

/

. The syntax for each line in the list is [IP address, IP/Mask, or IP start range-IP end range] [space] [comment]

.

Enter each IP address/range/subnet in a new line; URLs or domains are not supported in this list. If you add comments, the comment must be on the same line as the IP address/range/subnet. The space at the end of the IP address is the delimiter that separates a comment from the IP address.

An example IP address list:

192.168.20.10/32

2001:db8:123:1::1 #test IPv6 address

192.168.20.0/24 ; test internal subnet

2001:db8:123:1::/64 test internal IPv6 range

192.168.20.40-192.168.20.50




Policy Use an External Dynamic List in Policy

For an IP address that is blocked, you can display a notification page only if the protocol is HTTP.

Domain List

Enter each domain name in a new line; URLs or IP addresses are not supported in this list. Do not prefix the domain name with the protocol, http:// or https://. Wildcards are not supported.

An example list of domains: www.example.com

baddomain.com

qqq.abcedfg.au

URL List

See Block and Allow Lists .

Enforce Policy on Entries in an External Dynamic List

Enforce Policy on Entries in an External Dynamic List

Step 1 Create the external dynamic list and host it on a web server so that the firewall can retrieve the list for policy evaluation.

Create a text file and enter the URLs, domains, or IP addresses in the file.

To prevent commit errors and invalid entries, do not prefix http:// or https:// to any of the entries. See Formatting

Guidelines for an External Dynamic List .





Enforce Policy on Entries in an External Dynamic List (Continued)

Step 2 Configure the firewall to access the external dynamic list.

1.

Select Objects > External Dynamic Lists.

2.

Click Add and enter a descriptive Name for the list.

3.

( Optional ) Select Shared to share the list with all virtual systems on a device that is enabled for multiple virtual systems. By default, the object is created on the virtual system that is currently selected in the Virtual Systems drop‐down.

4.

( Panorama only ) Select Disable override to ensure that a firewall administrator cannot override settings locally on a firewall that inherits this configuration through a Device

Group commit from Panorama.

5.

In the Type drop‐down, select the list type, for example, URL

List

.

Ensure that the list only includes entries for the list type. See

Verify whether entries in the external dynamic list were ignored or skipped.

6.

Enter the Source for the list you just created on the web server. The source must include the full path to access the list.

For example, https://1.2.3.4/EDL_IP_2015.

7.

Click Test Source URL to verify that the firewall (not available on Panorama) can connect to the web server.

If the web server is unreachable after the connection is established, the firewall uses the last successfully retrieved list for enforcing policy until the connection is restored with the web server.

8.

( Optional ) Specify the Repeat frequency at which the firewall retrieves the list. By default, the firewall retrieves the list once every hour and commits the changes.

The interval is relative to the last commit. So, for the five‐minute interval, the commit occurs in 5 minutes if the last commit was an hour ago. To retrieve the list immediately, see Retrieve an External Dynamic List from the Web Server .

9.

Click OK.

10.

Use the external dynamic list in a security profile or directly in a policy rule, as supported. See the following:

• Use an External Dynamic List in a URL Filtering Profile .

• Configure DNS Sinkholing for a List of Custom Domains

• Use an External Dynamic List of Type URL as Match Criteria in a Security Policy Rule.

• Use an External Dynamic List of Type IP as a Source or

Destination Address Object in a Security Policy Rule.






Use an External Dynamic List of Type URL as

Match Criteria in a Security Policy Rule.

You can also Use an External Dynamic List in a

URL Filtering Profile .

1.

Select Policies > Security.

2.

Click Add and enter a descriptive Name for the rule.

3.

In the Source tab, select the Source Zone.

4.

In the Destination tab, select the Destination Zone.

5.

In the Service/URL Category tab, click Add to select the appropriate external dynamic list from the URL Category list.

6.

In the Actions tab, set the Action Setting to Allow or Deny.

7.


8.

Verify whether entries in the external dynamic list were ignored or skipped.

Use the following CLI command on a firewall to review the details for a list.

request system external-list show type <domain | ip

| url>

name_of_ list

For example: request system external-list show type url

EBL_ISAC_Alert_List

9.

Test that the policy action is enforced.

a. Attempt to access a URL that is included in the external dynamic list.

b. Verify that the action you defined is enforced in the browser.

c. To monitor the activity on the firewall: d. Select ACC and add a URL Domain as a global filter to view the Network Activity and Blocked Activity for the URL you accessed.

e. Select Monitor > Logs > URL Filtering to access the detailed log view.






Use an External Dynamic List of Type IP as a

Source or Destination Address Object in a

Security Policy Rule.

This capability is useful if you deploy new servers and want to allow access to the newly deployed servers without requiring a firewall commit.

1.


2.

Click Add and give the rule a descriptive name in the General tab.

3.

In the Source tab, select the Source Zone and optionally select the external dynamic list as the Source Address.

4.

In the Destination tab, select the Destination Zone and optionally select the external dynamic list as the Destination

Address.

5.

In the Service/ URL Category tab, make sure the Service is set to application-default.

6.

In the Actions tab, set the Action Setting to Allow or Deny.

Create separate external dynamic lists if you want to specify allow and deny actions for specific IP addresses.

7.

Leave all the other options at the default values.

8.

Click OK to save the changes.

9.

Commit

the changes.

10.

Test that the policy action is enforced.

a. Access a IP address that is included in the external dynamic list and verify that action you defined is enforced.

b. Select Monitor > Logs > Traffic and view the log entry for the session.

c. To verify the policy rule that matches a flow, use the following CLI command: test security-policy-match source <IP_address> destination <IP_address> destination port <port_number>

protocol <protocol_number>

View the List of Entries in an External Dynamic List

View the List of Entries in an External Dynamic List

To view the list of entries that the firewall has retrieved from the web server enter the following CLI command: request system external-list show name <name>

For example, for a list named case DBL_2014 of type IP address, the output is: vsys1/DBL_2014:

Next update at: Wed Aug 27 16:00:00 2014

IPs:

1.1.1.1

1.2.2.2/20 #test China

192.168.255.0; test internal

192.168.254.0/24 test internal range





Retrieve an External Dynamic List from the Web Server

You can configure the firewall to retrieve the External Dynamic List from the web server on an hourly, daily, weekly, or monthly basis. If you have added or deleted IP addresses on the list and need to trigger an immediate refresh, use the following process:

Retrieve an External Dynamic List

1.

To retrieve the list on demand, select Objects > External Dynamic Lists.

2.

Select the list that you want to refresh, and click Import Now. The job to import the list will be added to queue.

To view the status of the job in the Task Manager, see Manage and Monitor Administrative Tasks .






Policy

To mitigate the challenges of scale, lack of flexibility and performance, the architecture in networks today allows for clients, servers, and applications to be provisioned, changed, and deleted on demand. This agility poses a challenge for security administrators because they have limited visibility into the IP addresses of the dynamically provisioned clients and servers, and the plethora of applications that can be enabled on these virtual resources.

The firewall (hardware‐based platforms and the VM‐Series) supports the ability to register IP addresses and tags dynamically. The IP addresses and tags can be registered on the firewall directly or registered on the firewall through Panorama.This dynamic registration process can be enabled using any of the following options:



User‐ID agent for Windows—In an environment where you’ve deployed the User‐ID agent, you can enable the User‐ID agent to monitor up to 100 VMware ESXi and/or vCenter Servers. As you provision or modify virtual machines on these VMware servers, the agent can retrieve the IP address changes and share them with the firewall.







VM Information Sources—Allows you to monitor VMware ESXi and vCenter Server, and the AWS‐VPC to retrieve IP address changes when you provision or modify virtual machines on these sources. VM

Information Sources polls for a predefined set of attributes and does not require external scripts to register the IP addresses through the XML API. See Monitor Changes in the Virtual Environment .

VMware Service Manager (only available for the integrated NSX solution)—The integrated NSX solution is designed for automated provisioning and distribution of Palo Alto Networks next‐generation security services and the delivery of dynamic context‐based security policies using Panorama. The NSX Manager updates Panorama with the latest information on the IP addresses and tags associated with the virtual machines deployed in this integrated solution. For information on this solution, see Set Up a VM‐Series

NSX Edition Firewall .

XML API—The firewall and Panorama support an XML API that uses standard HTTP requests to send and receive data. You can use this API to register IP addresses and tags with the firewall or Panorama. API calls can be made directly from command line utilities such as cURL or using any scripting or application framework that supports REST‐based services. Refer to the PAN‐OS XML API Usage Guide for details.

For information on creating and using Dynamic Address Groups, see Use Dynamic Address Groups in Policy .

For the CLI commands for registering tags dynamically, see CLI Commands for Dynamic IP Addresses and

Tags .




Policy Monitor Changes in the Virtual Environment

Monitor Changes in the Virtual Environment

To secure applications and prevent threats in an environment where new users and servers are constantly emerging, your security policy must be nimble. To be nimble, the firewall must be able to learn about new or modified IP addresses and consistently apply policy without requiring configuration changes on the firewall.

This capability is provided by the coordination between the

VM Information Sources

and

Dynamic Address

Groups

features on the firewall. The firewall and Panorama provide an automated way to gather information on the virtual machine (or guest) inventory on each monitored source and create policy objects that stay in sync with the dynamic changes on the network.



Enable VM Monitoring to Track Changes on the Virtual Network





Attributes Monitored in the AWS and VMware Environments

Use Dynamic Address Groups in Policy

Enable VM Monitoring to Track Changes on the Virtual Network

VM information sources provides an automated way to gather information on the Virtual Machine (VM) inventory on each monitored source (host); the firewall can monitor the VMware ESXi and vCenter Server, and the AWS‐VPC. As virtual machines (guests) are deployed or moved, the firewall collects a predefined set of attributes (or metadata elements) as tags; these tags can then be used to define Dynamic Address Groups

(see Use Dynamic Address Groups in Policy ) and matched against in policy.

Up to 10 VM information sources can be configured on the firewall or pushed using Panorama templates.

By default, the traffic between the firewall and the monitored sources uses the management (MGT) port on the firewall.

VM Information Sources offers easy configuration and enables you to monitor a predefined set of 16 metadata elements or attributes. See Attributes Monitored in the AWS and VMware

Environments for the list.

When monitoring ESXi hosts that are part of the VM‐Series NSX edition solution, use Dynamic

Address Groups instead of using VM Information Sources to learn about changes in the virtual environment. For the VM‐Series NSX edition solution, the NSX Manager provides Panorama with information on the NSX security group to which an IP address belongs. The information from the

NSX Manager provides the full context for defining the match criteria in a Dynamic Address

Group because it uses the service profile ID as a distinguishing attribute and allows you to properly enforce policy when you have overlapping IP addresses across different NSX security groups. Up to a maximum of 32 tags (from vCenter server and NSX Manager) that can be registered to an IP address.




Monitor Changes in the Virtual Environment Policy

Set up the VM Monitoring Agent

Step 1 Enable the VM Monitoring Agent.

You can configure up to 10 VM information sources for each firewall, or for each virtual system on a multiple virtual systems capable firewall.

If your firewalls are configured in a high availability configuration:

• In an active/passive setup, only the active firewall monitors the VM sources.

• In an active/active setup, only the firewall with the priority value of primary monitors the VM sources.

1.

Select Device > VM Information Sources.

2.

Click Add and enter the following information:

• A Name to identify the VMware ESX(i) or vCenter Server that you want to monitor.

• Enter the Host information for the server—hostname or IP address and the Port on which it is listening.

• Select the Type to indicate whether the source is a VMware

ESX(i)

server or a VMware vCenter Server.

• Add the credentials (Username and Password) to authenticate to the server specified above.

• Use the credentials of an administrative user to enable access.

• (Optional) Modify the Update interval to a value between

5‐600 seconds. By default, the firewall polls every 5 seconds. The API calls are queued and retrieved within every 60 seconds, so updates may take up to 60 seconds plus the configured polling interval.

• (Optional) Enter the interval in hours when the connection to the monitored source is closed, if the host does not respond. (default: 2 hours, range 2‐10 hours)

To change the default value, select the check box to Enable timeout when the source is disconnected

and specify the value. When the specified limit is reached or if the host cannot be accessed or does not respond, the firewall will close the connection to the source.

• Click OK, and Commit the changes.

• Verify that the connection Status displays as connected .





Set up the VM Monitoring Agent (Continued)

Step 2 Verify the connection status.

Verify that the connection Status displays as connected.

If the connection status is pending or disconnected, verify that the source is operational and that the firewall is able to access the source. If you use a port other than the MGT port for communicating with the monitored source, you must change the service route (Device > Setup > Services, click the Service Route

Configuration

link and modify the Source Interface for the VM

Monitor service).

Attributes Monitored in the AWS and VMware Environments

Each VM on a monitored ESXi or vCenter server must have VMware Tools installed and running. VMware

Tools provide the capability to glean the IP address(es) and other values assigned to each VM.

In order to collect the values assigned to the monitored VMs, the firewall monitors the following predefined set of attributes:

Attributes Monitored on a VMware Source Attributes Monitored on the AWS‐VPC

• UUID

• Name

• Architecture

• Guest OS

• Guest OS • Image ID

• VM State — the power state can be poweredOff, poweredOn, standBy, and unknown.

• Instance ID

• Annotation • Instance State

• Version

• Network — Virtual Switch Name, Port Group

Name, and VLAN ID

• Instance Type

• Key Name

• Container Name —vCenter Name, Data Center

Object Name, Resource Pool Name, Cluster Name,

Host, Host IP address.

• Placement—Tenancy, Group Name, Availability Zone

• Private DNS Name

• Public DNS Name

• Subnet ID

• Tag (key, value) (up to5 tags supported per instance

• VPC ID





Use Dynamic Address Groups in Policy

Dynamic address groups are used in policy. They allow you to create policy that automatically adapts to changes—adds, moves, or deletions of servers. It also enables the flexibility to apply different rules to the same server based on tags that define its role on the network, the operating system, or the different kinds of traffic it processes.

A dynamic address group uses tags as a filtering criteria to determine its members. The filter uses logical and and or operators. All IP addresses or address groups that match the filtering criteria become members of the dynamic address group. Tags can be defined statically on the firewall and/or registered (dynamically) to the firewall. The difference between static and dynamic tags is that static tags are part of the configuration on the firewall, and dynamic tags are part of the runtime configuration. This implies that a commit is not required to update dynamic tags; the tags must however be used by Dynamic Address Groups that are referenced in policy, and the policy must be committed on the firewall.

To dynamically register tags, you can use the XML API or the VM Monitoring agent on the firewall or on the

User‐ID agent. Each tag is a metadata element or attribute‐value pair that is registered on the firewall or

Panorama. For example, IP1 {tag1, tag2,.....tag32}, where the IP address and the associated tags are maintained as a list; each registered IP address can have up to 32 tags such as the operating system, the datacenter or the virtual switch to which it belongs. Within 60 seconds of the API call, the firewall registers the IP address and associated tags, and automatically updates the membership information for the dynamic address group(s).

The maximum number of IP addresses that can be registered for each platform is different. Use the following table for specifics on your platform:

Platform

PA‐7000 Series, PA‐5060, VM‐1000‐HV

PA‐5050

PA‐5020

PA‐4000 Series, PA‐3000 Series

PA‐2000 Series, PA‐500, PA‐200, VM‐300,

VM‐200, VM‐100

Maximum number of dynamically registered IP addresses

100,000

50,000

25,000

5,000

1,000

The following example shows how dynamic address groups can simplify network security enforcement. The example workflow shows how to:



Enable the VM Monitoring agent on the firewall, to monitor the VMware ESX(i) host or vCenter Server and register VM IP addresses and the associated tags.







Create dynamic address groups and define the tags to filter. In this example, two address groups are created. One that only filters for dynamic tags and another that filters for both static and dynamic tags to populate the members of the group.

Validate that the members of the dynamic address group are populated on the firewall.

Use dynamic address groups in policy. This example uses two different security policies:

– A security policy for all Linux servers that are deployed as FTP servers; this rule matches on dynamically registered tags.

– A security policy for all Linux servers that are deployed as web servers; this rule matches on a dynamic address group that uses static and dynamic tags.







Validate that the members of the dynamic address groups are updated as new FTP or web servers are deployed. This ensure that the security rules are enforced on these new virtual machines too.

Use Dynamic Address Groups in Policy

Step 1 Enable VM Source Monitoring.

Step 2 Create dynamic address groups on the firewall.

View the tutorial to see a big picture view of the feature.

See Enable VM Monitoring to Track Changes on the Virtual

Network .

1.

Log in to the web interface of the firewall.

2.

Select Object > Address Groups.

3.

Click Add and enter a Name and a Description for the address group.

4.

Select Type as Dynamic.

5.

Define the match criteria. You can select dynamic and static tags as the match criteria to populate the members of the group. Click Add Match Criteria, and select the And or Or operator and select the attributes that you would like to filter for or match against. and then click OK.

6.

Click Commit.

The match criteria for each dynamic address group in this example is as follows: ftp_server: matches on the guest operating system “Linux 64‐bit” and annotated as “ftp” ('guestos.Ubuntu Linux 64‐bit' and 'annotation.ftp').

web‐servers: matches on two criteria—the tag black or if the guest operating system is Linux 64‐bit and the name of the server us Web_server_Corp. ('guestos.Ubuntu Linux 64‐bit' and 'vmname.WebServer_Corp' or 'black')





Use Dynamic Address Groups in Policy (Continued)

Step 3 Use dynamic address groups in policy.

View the tutorial .

1.


2.

Click Add and enter a Name and a Description for the policy.

3.

Add the Source Zone to specify the zone from which the traffic originates.

4.

Add the Destination Zone at which the traffic is terminating.

5.

For the Destination Address, select the Dynamic address group you created in Step 2 above.

6.

Specify the action— Allow or Deny—for the traffic, and optionally attach the default security profiles to the rule.

7.

Repeats Steps 1 through 6 above to create another policy rule.

8.

Click Commit.

This example shows how to create two policies: one for all access to FTP servers and the other for access to web servers.

Step 4 Validate that the members of the dynamic address group are populated on the firewall.

1.

Select Policies > Security, and select the rule.

2.

Select the drop‐down arrow next to the address group link, and select Inspect. You can also verify that the match criteria is accurate.

3.

Click the more link and verify that the list of registered IP addresses is displayed.

Policy will be enforced for all IP addresses that belong to this address group, and are displayed here.




Policy CLI Commands for Dynamic IP Addresses and Tags

CLI Commands for Dynamic IP Addresses and Tags

The Command Line Interface on the firewall and Panorama give you a detailed view into the different sources from which tags and IP addresses are dynamically registered. It also allows you to audit registered and unregistered tags. The following examples illustrate the capabilities in the CLI.

Example CLI Command

View all registered IP addresses that match the tag, state.poweredOn or that are not tagged as vSwitch0 show log iptag tag_name equal state.poweredOn

show log iptag tag_name not-equal switch.vSwitch0

View all dynamically registered IP addresses that were sourced by VM Information Source with name vmware1 and tagged as poweredOn show vm-monitor source source-name vmware1 tag state.poweredOn registered-ip all registered IP Tags

----------------------------- ----------------fe80::20c:29ff:fe69:2f76 "state.poweredOn"

10.1.22.100 "state.poweredOn"

2001:1890:12f2:11:20c:29ff:fe69:2f76

"state.poweredOn" fe80::20c:29ff:fe69:2f80 "state.poweredOn"



2001:1890:12f2:11:2cf8:77a9:5435:c0d

"state.poweredOn" fe80::2cf8:77a9:5435:c0d "state.poweredOn"

Clear all IP addresses and tags learned from a specific VM Monitoring source without disconnecting the source.

Display IP addresses registered from all sources.

debug vm-monitor clear source-name <name> show object registered-ip all

Display the count for IP addresses registered from all sources.

show object registered-ip all option count

Clear IP addresses registered from all sources debug object registered-ip clear all

Add or delete tags for a given IP address that was registered using the XML API.

debug object test registered-ip

[<register/unregister>] <ip/netmask> <tag>




CLI Commands for Dynamic IP Addresses and Tags Policy

Example CLI Command

View all tags registered from a specific information source.

show vm-monitor source source-name vmware1 tag all vlanId.4095

vswitch.vSwitch1

host-ip.10.1.5.22

portgroup.TOBEUSED

hostname.panserver22

portgroup.VM Network 2 datacenter.ha-datacenter vlanId.0

state.poweredOn

vswitch.vSwitch0

vmname.Ubuntu22-100 vmname.win2k8-22-105 resource-pool.Resources

vswitch.vSwitch2

guestos.Ubuntu Linux 32-bit guestos.Microsoft Windows Server 2008 32-bit annotation.

version.vmx-08 portgroup.VM Network vm-info-source.vmware1

uuid.564d362c-11cd-b27f-271f-c361604dfad7 uuid.564dd337-677a-eb8d-47db-293bd6692f76

Total: 22

View all tags registered from a specific data source, for example from the VM Monitoring

Agent on the firewall, the XML API, Windows

User‐ID Agent or the CLI.

• To view tags registered from the CLI: show log iptag datasource_type equal unknown

• To view tags registered from the XML API: show log iptag datasource_type equal xml-api

• To view tags registered from VM Information sources: show log iptag datasource_type equal vm-monitor

• To view tags registered from the Windows User‐ID agent: show log iptag datasource_type equal xml-api datasource_subtype equal user-id-agent

View all tags that are registered for a specific IP address (across all sources).

debug object registered-ip show tag-source ip

ip_address tag all




Policy Identify Users Connected through a Proxy Server

Identify Users Connected through a Proxy Server

If you have a proxy server deployed between the users on your network and the firewall, in HTTP/HTTPS requests the firewall might see the proxy server IP address as the source IP address in the traffic that the proxy forwards rather than the IP address of the client that requested the content. In many cases, the proxy server adds an X‐Forwarded‐For (XFF) header to traffic packets that includes the actual IPv4 or IPv6 address of the client that requested the content or from whom the request originated. In such cases, you can configure the firewall to read the XFF header values and determine the IP addresses of the client who requested the content. The firewall matches the XFF IP addresses with usernames that your policy rules reference so that those rules can control access for the associated users and groups. The firewall also uses the XFF‐derived usernames to populate the source user fields of logs so you can monitor user access to web services.

You can also configure the firewall to add XFF values to URL Filtering logs. In these logs, an XFF value can be the client IP address, client username (if available), the IP address of the last proxy server traversed in a proxy chain, or any string of up to 128 characters that the XFF header stores.

XFF user identification applies only to HTTP or HTTPS traffic, and only if the proxy server supports the XFF header. If the header has an invalid IP address, the firewall uses that IP address as a username for group mapping references in policies. If the XFF header has multiple IP addresses, the firewall uses the first entry from the left.

 Use XFF Values for Policies and Logging Source Users

 Add XFF Values to URL Filtering Logs

Use XFF Values for Policies and Logging Source Users

You can configure the firewall to use XFF values in user‐based policies and in the source user fields of logs.

To use XFF values in policies, you must also Map IP Addresses to Users , Map Users to Groups (if you have group‐based policies), and configure policies based on users or groups.

Logging XFF values doesn’t populate the source IP address values of logs. When you view the logs, the source field displays the IP address of the proxy server if one is deployed between the user clients and the firewall. However, you can configure the firewall to Add XFF Values to URL

Filtering Logs so that you can see user IP addresses in those logs.

To ensure that attackers can’t read and exploit the XFF values in web request packets that exit the firewall to retrieve content from an external server, you can also configure the firewall to strip the XFF values from outgoing packets.

These options are not mutually exclusive: if you configure both, the firewall zeroes out XFF values only after using them in policies and logs.

Use XFF Values for Policies and Logging Source Users

Step 1 Enable the firewall to use XFF values in policies and in the source user fields of logs.

1.

Select Device > Setup > Content-ID and edit the

X‐Forwarded‐For Headers settings.

2.

Select the Use X-Forwarded-For Header in User-ID check box.




Identify Users Connected through a Proxy Server Policy

Use XFF Values for Policies and Logging Source Users (Continued)

Step 2 Remove XFF values from outgoing web requests.

Step 3 Verify the firewall is populating the source user fields of logs.

1.

Select the Strip X-Forwarded-For Header check box.

2.


1.

Select a log type that has a source user field (for example,

Monitor > Logs > Traffic

).

2.

Verify that the Source User column displays the usernames of users who access the web.

Add XFF Values to URL Filtering Logs

You can configure the firewall to add the XFF values from web requests to URL Filtering logs. The XFF values that the logs display can be client IP addresses, usernames if available, or any values of up to 128 characters that the XFF fields store.

This method of logging XFF values doesn’t add usernames to the source user fields in URL

Filtering logs. To populate the source user fields, see Use XFF Values for Policies and Logging

Source Users .

Add XFF Values to URL Filtering Logs

Step 1 Configure a URL Filtering profile.

1.

Select Objects > Security Profiles > URL Filtering.

2.

Select an existing profile or Add a new profile and enter a descriptive Name.

You can’t enable XFF logging in the default URL Filtering profile.

3.

In the Categories tab, Define how to control access to web content.

4.

Select the Settings tab and select the X-Forwarded-For check box.

5.

Click OK to save the profile.

Step 2 Attach the URL Filtering profile to a policy rule.

1.

Select Policies > Security and click the rule.

2.

Select the Actions tab, set the Profile Type to Profiles, and select the URL Filtering profile you just created.

3.


Step 3 Verify the firewall is logging XFF values. 1.

Select Monitor > Logs > URL Filtering.

2.

Display the XFF values in one of the following ways:

• To display the XFF value for a single log—Click the icon for the log to displays its details. The HTTP Headers section displays the X‐Forwarded‐For value.

• To display the XFF values for all logs—Open the drop‐down in any column header, select Columns, and select the

X-Forwarded-For

check box. The page then displays an

X‐Forwarded‐For column.




Policy



Normally, the firewall uses the destination IP address in a packet to determine the outgoing interface. The firewall uses the routing table associated with the virtual router to which the interface is connected to perform the route lookup. Policy‐Based Forwarding (PBF) allows you to override the routing table, and specify the outgoing or egress interface based on specific parameters such as source or destination IP address, or type of traffic.

 PBF







Create a Policy‐Based Forwarding Rule

Use Case: PBF for Outbound Access with Dual ISPs

Use Case: PBF for Routing Traffic Through Virtual Systems

PBF

PBF rules allow traffic to take an alternative path from the next hop specified in the route table, and are typically used to specify an egress interface for security or performance reasons. Let's say your company has two links between the corporate office and the branch office: a cheaper Internet link and a more expensive leased line. The leased line is a high‐bandwidth, low‐latency link. For enhanced security, you can use PBF to send applications that aren’t encrypted traffic, such as FTP traffic, over the private leased line and all other traffic over the Internet link. Or, for performance, you can choose to route business‐critical applications over the leased line while sending all other traffic, such as web browsing, over the cheaper link.

Egress Path and Symmetric Return

Using PBF, you can direct traffic to a specific interface on the firewall, drop the traffic, or direct traffic to another virtual system (on systems enabled for multiple virtual systems).

In networks with asymmetric routes, such as in a dual ISP environment, connectivity issues occur when traffic arrives at one interface on the firewall and leaves from another interface. If the route is asymmetrical, where the forward (SYN packet) and return (SYN/ACK) paths are different, the firewall is unable to track the state of the entire session and this causes a connection failure. To ensure that the traffic uses a symmetrical path, which means that the traffic arrives at and leaves from the same interface on which the session was created, you can enable the Symmetric Return option.

With symmetric return, the virtual router overrides a routing lookup for return traffic and instead directs the flow back to the MAC address from which it received the SYN packet (or first packet). However, if the destination IP address is on the same subnet as the ingress/egress interface’s IP address, a route lookup is performed and symmetric return is not enforced. This behavior prevents traffic from being blackholed.




Policy‐Based Forwarding Policy

To determine the next hop for symmetric returns, the firewall uses an Address Resolution Protocol (ARP) table.

The maximum number of entries that this ARP table supports is limited by the firewall model and the value is not user configurable. To determine the limit for your model, use the CLI command: show pbf return-mac all.

Path Monitoring

Path monitoring allows you to verify connectivity to an IP address so that the firewall can direct traffic through an alternate route, when needed. The firewall uses ICMP pings as heartbeats to verify that the specified IP address is reachable.

A monitoring profile allows you to specify the threshold number of heartbeats to determine whether the IP address is reachable. When the monitored IP address is unreachable, you can either disable the PBF rule or specify a fail‐over or wait‐recover action. Disabling the PBF rule allows the virtual router to take over the routing decisions. When the fail‐over or wait‐recover action is taken, the monitoring profile continues to monitor whether the target IP address is reachable, and when it comes back up, the firewall reverts back to using the original route.

The following table lists the difference in behavior for a path monitoring failure on a new session versus an established session.

Behavior of a session on a monitoring failure

If the rule stays enabled when the monitored IP address is unreachable

If rule is disabled when the monitored IP address is unreachable

For an established session

For a new session wait-recover

—Continue to use egress interface specified in the PBF rule fail-over

—Use path determined by routing table (no PBF) wait-recover

—Continue to use egress interface specified in the PBF rule fail-over



—Check the remaining PBF rules. If no match, use the routing table fail-over

—Use path determined by routing table (no PBF) fail-over

—Check the remaining PBF rules. If no match, use the routing table

Service Versus Applications in PBF

PBF rules are applied either on the first packet (SYN) or the first response to the first packet (SYN/ACK). This means that a PBF rule may be applied before the firewall has enough information to determine the application. Therefore, application‐specific rules are not recommended for use with PBF. Whenever possible, use a service object, which is the Layer 4 port (TCP or UDP) used by the protocol or application.

However, if you specify an application in a PBF rule, the firewall performs App‐ID caching. When an application passes through the firewall for the first time, the firewall does not have enough information to identify the application and therefore cannot enforce the PBF rule. As more packets arrive, the firewall determines the application and creates an entry in the App‐ID cache and retains this App‐ID for the session.When a new session is created with the same destination IP address, destination port, and protocol

ID, the firewall could identify the application as the same from the initial session (based on the App‐ID cache) and apply the PBF rule. Therefore, a session that is not an exact match and is not the same application, can be forwarded based on the PBF rule.




Policy Policy‐Based Forwarding

Further, applications have dependencies and the identity of the application can change as the firewall receives more packets. Because PBF makes a routing decision at the start of a session, the firewall cannot enforce a change in application identity. YouTube, for example, starts as web‐browsing but changes to Flash,

RTSP, or YouTube based on the different links and videos included on the page. However with PBF, because the firewall identifies the application as web‐browsing at the start of the session, the change in application is not recognized thereafter.

PBF rules cannot be based on domain names; only IP addresses are valid; also, you cannot use custom‐applications, application‐filters or application groups in PBF rules.





Create a Policy-Based Forwarding Rule

Use a PBF rule to direct traffic to a specific egress interface on the firewall, and override the default path for the traffic.

Create a PBF Rule

Step 1 Create a PBF rule.

When creating a PBF rule you must specify a name for the rule, a source zone or interface, and an egress interface. All other components are either optional or have a default value provided.

1.

Select Policies > Policy Based Forwarding and click Add.

2.

Give the rule a descriptive name in the General tab.

3.

In the Source tab, select the following: a. Select the Type—Zone or Interface— to which the forwarding policy will be applied, and the relevant zone or interface.

PBF is only supported on Layer 3 interfaces.

b. (Optional) Specify the Source Address to which PBF will apply. For example, a specific IP address or subnet IP address from which you want to forward traffic to the interface or zone specified in this rule.

Use the Negate option to exclude a one or more source IP addresses from the PBF rule. For example, if your PBF rule directs all traffic from the specified zone to the Internet, Negate allows you to exclude internal

IP addresses from the PBF rule.

The evaluation order is top down. A packet is matched against the first rule that meets the defined criteria; after a match is triggered the subsequent rules are not evaluated.

c. (Optional) Add and select the Source User or groups of users to whom the policy applies.

4.

In the Destination/Application/Service tab, select the following: a.

Destination Address

. By default the rule applies to Any IP address. Use the Negate option to exclude one or more destination IP addresses from the PBF rule.

b. Select the Application(s) or Service(s) that you want to control using PBF.

Application‐specific rules are not recommended for use with PBF. Whenever possible, use a service object, which is the Layer 4 port (TCP or UDP) used by the protocol or application. For more details, see Service

Versus Applications in PBF .




Policy

Create a PBF Rule (Continued)


Step 2 Save the policies to the running configuration on the firewall.

5.

In the Forwarding tab, select the following: a. Set the Action. The options are as follows:

– Forward—Directs the packet to a specific Egress

Interface

. Enter the Next Hop IP address for the packet.

– Forward To VSYS—(On a firewall enabled for multiple virtual systems) Select the virtual system to which to forward the packet.

– Discard—Drop the packet.

– No PBF—Exclude the packets that match the criteria for source/destination/application/service defined in the rule. Matching packets use the route table instead of PBF; the firewall uses the route table to exclude the matched traffic from the redirected port.

To trigger the specified action at a daily, weekly or non‐recurring frequency, create and attach a Schedule.

(Optional) Enable Monitoring to verify connectivity to a target

IP address or to the next hop IP address. Select Monitor and attach a monitoring Profile (default or custom) that specifies the action when the IP address is unreachable.

b. (Optional, required for asymmetric routing environments)

Select Enforce Symmetric Return and enter one or more IP addresses in the Next Hop Address List.

Enabling symmetric return ensures that return traffic (say, from the Trust zone on the LAN to the Internet) is forwarded out through the same interface through which traffic ingresses from the Internet.

Click Commit.

The PBF rule is in effect.

Use Case: PBF for Outbound Access with Dual ISPs

In this use case, the branch office has a dual ISP configuration and implements PBF for redundant Internet access. The backup ISP is the default route for traffic from the client to the web servers. In order to enable redundant Internet access without using an internetwork protocol such as BGP, we use PBF with destination interface‐based source NAT and static routes, and configure the firewall as follows:



Enable a PBF rule that routes traffic through the primary ISP, and attach a monitoring profile to the rule.

The monitoring profile triggers the firewall to use the default route through the backup ISP when the primary ISP is unavailable.



Define Source NAT rules for both the primary and backup ISP that instruct the firewall to use the source

IP address associated with the egress interface for the corresponding ISP. This ensures that the outbound traffic has the correct source IP address.







Add a static route to the backup ISP, so that when the primary ISP is unavailable, the default route comes into effect and the traffic is directed through the backup ISP.

.

PBF for Outbound Access with Dual ISPs

Step 1 Configure the ingress and the egress interfaces on the firewall.

Egress interfaces can be in the same zone. In this example we assign the egress interfaces to different zones.

1.

Select Network > Interfaces and then select the interface you want to configure, for example, Ethernet1/1 and Ethernet1/3.

The interface configuration on the firewall used in this example is as follows:

• Ethernet 1/1 connected to the primary ISP:

– Zone: ISP‐East

– IP Address:1.1.1.2/30

– Virtual Router: Default

• Ethernet 1/3 connected to the backup ISP:

– Zone: ISP‐West

– IP Address:2.2.2.2/30


• Ethernet 1/2 is the ingress interface, used by the network clients to connect to the Internet:

– Zone: Trust

– IP Address:192.168. 54.1/24


2.

To save the interface configuration, click OK.





PBF for Outbound Access with Dual ISPs (Continued)

Step 2 On the virtual router, add a static route to the backup ISP.

1.

Select Network > Virtual Router and then select the default link to open the Virtual Router dialog.

2.

Select the Static Routes tab and click Add. Enter a Name for the route and specify the Destination IP address for which you are defining the static route. In this example, we use 0.0.0.0/0 for all traffic.

3.

Select the IP Address radio button and set the Next Hop IP address for your router that connects to the backup Internet gateway. In this example, 2.2.2.1.

4.

Specify a cost metric for the route. In this example, we use 10.

5.

Click OK twice to save the virtual router configuration.






Step 3 Create a PBF rule that directs traffic to the interface that is connected to the primary ISP.

Make sure to exclude traffic destined to internal servers/IP addresses from PBF.

Define a negate rule so that traffic destined to internal IP addresses is not routed through the egress interface defined in the PBF rule.

1.

Select Policies > Policy Based Forwarding and click Add.

2.

Give the rule a descriptive Name in the General tab.

3.

In the Source tab, set the Source Zone to Trust.

4.

In the Destination/Application/Service tab, set the following: a. In the Destination Address section, Add the IP addresses or address range for servers on the internal network or create an address object for your internal servers. Select Negate to exclude the IP addresses or address object listed above from using this rule.

b. In the Service section, Add the service-http and service-https

services to allow HTTP and HTTPS traffic to use the default ports. For all other traffic that is allowed by security policy, the default route will be used.

To forward all traffic using PBF, set the Service to Any.

5.

In the Forwarding tab, specify the interface to which you want to forward traffic and enable path monitoring. a. To forward traffic, set the Action to Forward, and select the

Egress Interface and specify the Next Hop. In this example, the egress interface is ethernet1/1, and the next hop IP address is 1.1.1.1.





PBF for Outbound Access with Dual ISPs (Continued) b. Enable Monitor and attach the default monitoring profile, to trigger a failover to the backup ISP. In this example, we do not specify a target IP address to monitor. The firewall will monitor the next hop IP address; if this IP address is unreachable the firewall will direct traffic to the default route specified on the virtual router.

c. (Required if you have asymmetric routes). Select Enforce

Symmetric Return

to ensure that return traffic from the

Trust zone to the Internet is forwarded out on the same interface through which traffic ingressed from the Internet.

NAT ensures that the traffic from the Internet is returned to the correct interface/IP address on the firewall.

d. Click OK to save the changes.

Step 4 Create NAT rules based on the egress interface and ISP. These rules ensure that the correct source IP address is used for outbound connections.

1.

Select Policies > NAT and click Add.

2.

In this example, the NAT rule we create for each ISP is as follows:

NAT for Primary ISP

In the Original Packet tab,

• Source Zone: Trust

• Destination Zone: ISP‐West

In the Translated Packet tab, under Source Address

Translation

• Translation Type: Dynamic IP and Port

• Address Type: Interface Address

• Interface: ethernet1/1

• IP Address: 1.1.1.2/30

NAT for Backup ISP

In the Original Packet tab,

• Source Zone: Trust

• Destination Zone: ISP‐East

In the Translated Packet tab, under Source Address

Translation

• Translation Type: Dynamic IP and Port

• Address Type: Interface Address

• Interface: ethernet1/3

• IP Address: 2.2.2.2/30






Step 5 Create security policy to allow outbound access to the Internet.

To safely enable applications, create a simple rule that allows access to the Internet and attach the security profiles available on the firewall.

1.

Select Policies > Security and click Add.

2.

Give the rule a descriptive Name in the General tab.

3.

In the Source tab, set the Source Zone to Trust.

4.

In the Destination tab, Set the Destination Zone to ISP‐East and ISP‐West.

5.

In the Service/ URL Category tab, leave the default application-default

.

6.

In the Actions tab, complete these tasks: a. Set the Action Setting to Allow. b. Attach the default profiles for Antivirus, Anti‐Spyware,

Vulnerability Protection and URL Filtering, under Profile

Setting.

7.

Under Options, verify that logging is enabled at the end of a session. Only traffic that matches a security rule is logged.

Step 6 Save the policies to the running configuration on the firewall.

Click Commit.






Step 7 Verify that the PBF rule is active and that the primary ISP is used for Internet access.

1.

Launch a web browser and access a web server. On the firewall check the traffic log for web‐browsing activity.

2.

From a client on the network, use the ping utility to verify connectivity to a web server on the Internet. and check the traffic log on the firewall.

C:\Users\pm-user1>ping 4.2.2.1

Pinging 4.2.2.1 with 32 bytes of data:

Reply from 4.2.2.1: bytes=32 time=34ms TTL=117




Ping statistics for 4.2.2.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 3ms, Maximum = 34ms, Average = 18ms

3.

To confirm that the PBF rule is active, use the CLI command show pbf rule all admin@PA-NGFW> show pbf rule all

Rule ID Rule State Action Egress IF/VSYS NextHop

========== === ========== ====== ============== =======

Use ISP-Pr 1 Active Forward ethernet1/1 1.1.1.1

Step 8 Verify that the failover to the backup ISP occurs and that the Source NAT is correctly applied.

1.

Unplug the connection to the primary ISP.

2.

Confirm that the PBF rule is inactive with the CLI command show pbf rule all admin@PA-NGFW> show pbf rule all

Rule ID Rule State Action Egress IF/VSYS NextHop

========== === ========== ====== ============== =======

Use ISP-Pr 1 Disabled Forward ethernet1/1 1.1.1.1

3.

Access a web server, and check the traffic log to verify that traffic is being forwarded through the backup ISP.






4.

View the session details to confirm that the NAT rule is working properly.

admin@PA-NGFW> show session all

---------------------------------------------------------

ID Application State Type Flag Src[Sport]/Zone/Proto

(translated IP[Port]) Vsys Dst[Dport]/Zone (translated

IP[Port])

---------------------------------------------------------

87212 ssl ACTIVE FLOW NS 192.168.54.56[53236]/Trust/6

(2.2.2.2[12896]) vsys1 204.79.197.200[443]/ISP-East

(204.79.197.200[443])

5.

Obtain the session identification number from the output and view the session details. Note that the PBF rule is not used and hence is not listed in the output.

admin@PA-NGFW> show session id 87212

Session 87212

c2s flow:

source: 192.168.54.56 [Trust]

dst: 204.79.197.200

proto: 6

sport: 53236 dport: 443

state: ACTIVE type: FLOW

src user: unknown

dst user: unknown

s2c flow:

source: 204.79.197.200 [ISP-East]

dst: 2.2.2.2

proto: 6

sport: 443 dport: 12896

state: ACTIVE type: FLOW

src user: unknown

dst user: unknown start time : Wed Nov5 11:16:10 2014

timeout : 1800 sec

time to live : 1757 sec

total byte count(c2s) : 1918

total byte count(s2c) : 4333

layer7 packet count(c2s) : 10

layer7 packet count(s2c) : 7

vsys : vsys1

application : ssl

rule : Trust2ISP

session to be logged at end : True

session in session ager : True

session synced from HA peer : False

address/port translation : source

nat-rule : NAT-Backup ISP(vsys1)

layer7 processing : enabled

URL filtering enabled : True

URL category : search-engines

session via syn-cookies : False

session terminated on host : False

session traverses tunnel : False

captive portal session : False

ingress interface : ethernet1/2

egress interface : ethernet1/3

session QoS rule : N/A (class 4)




Policy DoS Protection Against Flooding of New Sessions

DoS Protection Against Flooding of New Sessions

The following topics describe how to configure DoS protection to better block IP addresses in order to handle high‐volume attacks more efficiently.

 DoS Protection Against Flooding of New Sessions





Configure DoS Protection Against Flooding of New Sessions

Use the CLI to End a Single Attacking Session





Identify Sessions That Use an Excessive Percentage of the Packet Buffer

Discard a Session Without a Commit

DoS Protection Against Flooding of New Sessions

DoS protection against flooding of new sessions is beneficial against high‐volume single‐session and multiple‐session attacks. In a single‐session attack, an attacker uses a single session to target a device behind the firewall. If a Security rule allows the traffic, the session is established and the attacker initiates an attack by sending packets at a very high rate with the same source IP address and port number, destination IP address and port number, and protocol, trying to overwhelm the target. In a multiple‐session attack, an attacker uses multiple sessions (or connections per second [cps]) from a single host to launch a DoS attack.

This feature defends only against DoS attacks of new sessions, that is, traffic that has not been offloaded to hardware. An offloaded attack is not protected by this feature. However, this topic describes how you can create a Security policy rule to reset the client; the attacker reinitiates the attack with numerous connections per second and is blocked by the defenses illustrated in this topic.





Multiple‐Session DoS Attack

Single‐Session DoS Attack

Multiple‐Session DoS Attack

Configure DoS Protection Against Flooding of New Sessions by configuring a DoS Protection policy rule, which determines the criteria that, when matched by incoming packets, trigger the protect action. The DoS

Protection profile counts each new connection toward the Alarm Rate, Activate Rate, and Max Rate thresholds. When the incoming new connections per second exceed the Max Rate allowed, the firewall takes the action specified in the DoS Protection policy rule.

The following figure and table describe how the Security policy rules, DoS Protection policy rules and profile work together in an example.




DoS Protection Against Flooding of New Sessions Policy

Sequence of Events as Firewall Quarantines an IP Address

In this example, an attacker launches a DoS attack at a rate of 10,000 new connections per second to UDP port 53. The attacker also sends 10 new connections per second to HTTP port 80.

The new connections match criteria in the DoS Protection policy rule, such as a source zone or interface, source IP address, destination zone or interface, destination IP address, or a service, among other settings. In this example, the policy rule specifies UDP.

The DoS rule also specifies the Protect action and Classified, two settings that dynamically put the DoS

Protection Profile settings into effect. The DoS Protection Profile specifies that a Max Rate of 3000 packets per second is allowed. When incoming packets match the DoS rule, new connections per second are counted toward the Alert, Activate, and Max Rate thresholds.

You can also use a Security policy rule to block all traffic from the source IP address if you deem that address to be malicious all the time.

The 10,000 new connections per second exceed the Max Rate threshold. When all of the following occur:

• the threshold is exceeded,

• a Block Duration is specified, and

• Classified is set to includes source IP address, the firewall puts the offending source IP address on the block list.

An IP address on the block list is in quarantine, meaning all traffic from that IP address is blocked. The firewall blocks the offending source IP address before additional attack packets reach the Security policy.

The following figure describes in more detail what happens after an IP address that matches the DoS

Protection policy rule is put on the block list. It also describes the Block Duration timer.





Every one second, the firewall allows the IP address to come off the Block List so that the firewall can test the traffic patterns and determine if the attack is ongoing. The firewall takes the following action:





During this one‐second test period, the firewall allows packets that do not match the DoS Protection policy criteria (HTTP traffic in this example) through the DoS Protection policy rules to the Security policy for validation. Very few packets, if any, have time to get through because the first attack packet that the firewall receives after the IP address is let off the Block List will match the DoS Protection policy criteria, quickly causing the IP address to be placed back on the block list for another second. The firewall repeats this test each second until the attack stops.

The firewall blocks all attack traffic from going past the DoS Protection policy rules until the Block

Duration expires.

When the attack stops, the firewall does not put the IP address back on the block list. The firewall allows non‐attack traffic to proceed through the DoS Protection policy rules to the Security policy rules for validation. You must configure a Security policy rule because without one, an implicit deny rule denies all traffic.

The block list is based on a source zone and source address combination. This behavior allows duplicate IP addresses to exist as long as they are in different zones belonging to separate virtual routers.

The Block Duration setting in a DoS Protection profile specifies how long the firewall blocks the [offending] packets that exactly match a DoS Protection policy rule. The attack traffic remains blocked until the Block

Duration expires, after which the attack traffic must again exceed the Max Rate threshold to be blocked again.





If the attacker uses multiple sessions or bots that initiate multiple attack sessions, the sessions count toward the thresholds in the DoS Protection profile without a Security policy deny rule in place. Hence, a single‐session attack requires a Security policy deny rule in order for each packet to count toward the thresholds; a multiple‐session attack does not.

Therefore, the DoS protection against flooding of new sessions allows the firewall to efficiently defend against a source IP address while attack traffic is ongoing and to permit non‐attack traffic to pass as soon as the attack stops. Putting the offending IP address on the block list allows the DoS protection functionality to take advantage of the block list, which is designed to quarantine all activity. Quarantining the IP address from all activity protects against a modern attacker who attempts a rotating application attack, in which the attacker simply changes applications to start a new attack or uses a combination of different attacks in a hybrid DoS attack.

Beginning with PAN‐OS 7.0.2, it is a change in behavior that the firewall places the attacking source IP address on the block list. When the attack stops, non‐attack traffic is allowed to proceed to the Security policy rules. The attack traffic that matched the DoS Protection profile and DoS

Protection policy rules remains blocked until the Block Duration expires.

Single‐Session DoS Attack

A single‐session DoS attack typically will not trigger Zone or DoS Protection profiles because they are attacks that are formed after the session is created. These attacks are allowed by the Security policy because a session is allowed to be created, and after the session is created, the attack drives up the packet volume and takes down the target device.

Configure DoS Protection Against Flooding of New Sessions to protect against flooding of new sessions

(single‐session and multiple‐session flooding). In the event of a single‐session attack that is underway, additionally Use the CLI to End a Single Attacking Session .

Configure DoS Protection Against Flooding of New Sessions

Configure DoS Protection Against Flooding of New Sessions

Step 1 (Required for single‐session attack mitigation or attacks that have not triggered the DoS Protection policy threshold; optional for multiple‐session attack mitigation)

Configure Security policy rules to deny traffic from the attacker’s IP address and allow other traffic based on your network needs. You can specify any of the match criteria in a Security policy rule, such as source IP address.

This step is one of the steps typically performed to stop an existing attack. See Use the CLI to

End a Single Attacking Session .

• Components of a Security Policy Rule

• Create a Security Policy Rule





Configure DoS Protection Against Flooding of New Sessions (Continued)

Step 2 Configure a DoS Protection profile for flood protection.

Because flood attacks can occur over multiple protocols, as a best practice, activate protection for all of the flood types in the DoS

Protection profile.

1.

Select Objects > Security Profiles > DoS Protection and Add a profile Name.

2.

Select Classified as the Type.

3.

For Flood Protection, select all types of flood protection:

• SYN Flood

• UDP Flood

• ICMP Flood

• ICMPv6 Flood

• Other IP Flood

4.

( Optional ) On each of the flood tabs, change the following thresholds to suit your environment:

• Alarm Rate (packets/s)—Specify the threshold rate

(packets per second [pps]) above which a DoS alarm is generated. (Range is 0‐2000000; default is 10000.)

• Activate Rate (packets/s)—Specify the threshold rate (pps) above which a DoS response is activated. The DoS response is configured in the Action field of the DoS policy where this profile is referenced. When the Activate Rate threshold is reached, Random Early Drop occurs. (Range is

0‐2000000; default is 10000.)

• Max Rate (packets/s)—Specify the threshold rate of incoming packets per second that the firewall allows. When the threshold is exceeded, new packets that arrive are dropped and the Action specified in the DoS Policy rule is triggered. (Range is 2‐2000000; default is 40000.)

The default threshold values in this step are only starting points and might not be appropriate for your network.

You must analyze the behavior of your network to properly set initial threshold values.

5.

On each of the flood tabs, specify the Block Duration (in seconds), which is the length of time the firewall blocks packets that match the DoS Protection policy rule that references this profile. Specify a value greater than zero.

(Range is 1‐21600; default is 300.)

Set a low Block Duration value if you are concerned that packets you incorrectly identified as attack traffic will be blocked unnecessarily.

Set a high Block Duration value if you are more concerned about blocking volumetric attacks than you are about incorrectly blocking packets that are not part of an attack.

6.

Click OK.





Configure DoS Protection Against Flooding of New Sessions (Continued)

Step 3 Configure a DoS Protection policy rule that specifies the criteria for matching the incoming traffic.

Step 4 Save the configuration.

1.

Select Policies > DoS Protection and Add a Name on the

General

tab. The name is case‐sensitive and can be a maximum of 31 characters, including letters, numbers, spaces, hyphens, and underscores.

2.

On the Source tab, choose the Type to be a Zone or Interface, and then Add the zone(s) or interface(s).

3.

( Optional ) For Source Address, select Any for any incoming IP address to match the rule or Add an address object such as a geographical region.

4.

( Optional ) For Source User, select any or specify a user.

5.

( Optional ) Select Negate to match any sources except those you specify.

6.

( Optional ) On the Destination tab, choose the Type to be a

Zone

or Interface, and then Add the destination zone(s) or interface(s). For example, enter the security zone you want to protect.

7.

( Optional ) For Destination Address, select Any or enter the IP address of the device you want to protect.

8.

( Optional ) On the Option/Protection tab, Add a Service. Select a service or click Service and enter a Name. Select TCP or

UDP

. Enter a Destination Port. Not specifying a particular service allows the rule to match a flood of any protocol type without regard to an application‐specific port.

9.

On the Option/Protection tab, for Action, select Protect.

10.

Select Classified.

11.

For Profile, select the name of the DoS Protection profile you created.

12.

For Address, select source-ip-only or src-dest-ip-both, which determines the type of IP address to which the rule applies. Choose the setting based on how you want the firewall to identify offending traffic.

• Specify source-ip-only if you want the firewall to classify only on the source IP address. Because attackers often test the entire network for hosts to attack, source-ip-only is the typical setting for a wider examination.

• Specify src-dest-ip-both if you want to protect only against DoS attacks on the server that has a specific destination address and also ensure that every source IP address will not surpass a specific connections‐per‐second threshold to that server.

13.

Click OK.

Click Commit.





Use the CLI to End a Single Attacking Session

To mitigate a single‐session DoS attack, you would still Configure DoS Protection Against Flooding of New

Sessions in advance. At some point after you configure the feature, a session might be established before you realize a DoS attack (from the IP address of that session) is underway. When you see a single‐session

DoS attack, perform the following task to end the session, so that subsequent connection attempts from that

IP address trigger the DoS protection against flooding of new sessions.

Use the CLI to End a Single Attacking Session

Step 1 Identify the source IP address that is causing the attack.

For example, use the firewall Packet Capture feature with a destination filter to collect a sample of the traffic going to the destination IP address. Alternatively, in PAN‐OS 7.0 and later, you can use ACC to filter on destination address to view the activity to the target host being attacked.

Step 2 Create a DoS Protection policy rule that will block the attacker’s IP address after the attack thresholds are exceeded.

Step 3 Create a Security policy rule to deny the source IP address and its attack traffic.

Step 4 End any existing attacks from the attacking source IP address by executing the clear session all filter source <ip-address>

operational command.

Alternatively, if you know the session ID, you can execute the clear session id <value> command to end that session only.

If you use the clear session all filter source <ip-address> command, all sessions matching the source IP address are discarded, which can include both good and bad sessions.

After you end the existing attack session, any subsequent attempts to form an attack session are blocked by the Security policy. The DoS Protection policy counts all connection attempts toward the thresholds. When the Max Rate threshold is exceeded, the source IP address is blocked for the Block Duration, as described in

Sequence of Events as Firewall Quarantines an IP Address .

Identify Sessions That Use an Excessive Percentage of the Packet Buffer

When a firewall exhibits signs of resource depletion, it might be experiencing an attack that is sending an overwhelming number of packets. In such events, the firewall starts buffering inbound packets. You can quickly identify the sessions that are using an excessive percentage of the packet buffer and mitigate their impact by discarding them.

Perform the following task on any hardware‐based firewall platform (not a VM‐Series firewall) to identify, for each slot and dataplane, the packet buffer percentage used, the top five sessions using more than two percent of the packet buffer, and the source IP addresses associated with those sessions. Having that information allows you to take appropriate action.





View Firewall Resource Usage, Top Sessions, and Session Details

Step 1 View firewall resource usage, top sessions, and session details. Execute the following operational command in the CLI (sample output from the command follows): admin@PA-7050> show running resource‐monitor ingress‐backlogs

-- SLOT:s1, DP:dp1 --

USAGE - ATOMIC: 92% TOTAL: 93%

TOP SESSIONS:

SESS-ID

6

PCT

92%

GRP-ID

1

7

COUNT

156

1732

SESSION DETAILS

SESS-ID PROTO SZONE SRC SPORT DST DPORT IGR-IF EGR-IF APP

6 6 trust 192.168.2.35 55653 10.1.8.89 80 ethernet1/21 ethernet1/22 undecided

The command displays a maximum of the top five sessions that each use 2% or more of the packet buffer.

The sample output above indicates that Session 6 is using 92% of the packet buffer with TCP packets

(protocol 6) coming from source IP address 192.168.2.35.

• SESS‐ID—Indicates the global session ID that is used in all other

show session commands. The global session ID is unique within the firewall.

• GRP‐ID—Indicates an internal stage of processing packets.

• COUNT—Indicates how many packets are in that GRP‐ID for that session.

• APP—Indicates the App‐ID extracted from the Session information, which can help you determine whether the traffic is legitimate. For example, if packets use a common TCP or UDP port but the CLI output indicates an APP of

undecided

, the packets are possibly attack traffic. The APP is undecided

when

Application IP Decoders cannot get enough information to determine the application. An APP of unknown

indicates that Application IP Decoders cannot determine the application; a session of unknown

APP that uses a high percentage of the packet buffer is also suspicious.

To restrict the display output:

On a PA‐7000 Series platform, you can limit output to a slot, a dataplane, or both. For example: admin@PA-7050> show running resource‐monitor ingress‐backlogs slot s1 admin@PA-7050> show running resource‐monitor ingress‐backlogs slot s1 dp dp1

On a PA‐5000 Series platform, you can limit output to a dataplane. For example: admin@PA-5060> show running resource‐monitor ingress‐backlogs dp dp1





View Firewall Resource Usage, Top Sessions, and Session Details

Step 2 Use the command output to determine whether the source at the source IP address using a high percentage of the packet buffer is sending legitimate or attack traffic.

In the sample output above, a single‐session attack is likely occurring. A single session (Session ID 6) is using

92% of the packet buffer for Slot 1, DP 1, and the application at that point is

undecided

.

• If you determine a single user is sending an attack and the traffic is not offloaded, you can Use the CLI to

End a Single Attacking Session . At a minimum, you can Configure DoS Protection Against Flooding of New

Sessions .

• On a hardware platform that has a field‐programmable gate array (FPGA), the firewall offloads traffic to the FPGA when possible to increase performance. If the traffic is offloaded to hardware, clearing the session does not help because then it is the software that must handle the barrage of packets. You should instead Discard a Session Without a Commit .

To see whether a session is offloaded or not, use the

show session id <session-id> operational command in the CLI as shown in the following example. The

layer7 processing value indicates

completed for sessions offloaded or

enabled for sessions not offloaded.





Discard a Session Without a Commit

Perform this task to permanently discard a session, such as a session that is overloading the packet buffer.

No commit is required; the session is discarded immediately after executing the command. The commands apply to both offloaded and non‐offloaded sessions.

Discard a Session Without a Commit

Step 1 In the CLI, execute the following operational command on any hardware platform: admin@PA-7050> request session‐discard [timeout <seconds>] [reason <reason‐string>] id <session‐id>

The default timeout is 3600 seconds.

Step 2 Verify that sessions have been discarded.

admin@PA-7050> show session all filter state discard




No results