Threat Prevention Deployment TechNote Version 3.0 RevA

Advanced Threat Prevention Deployment
Tech Note
PAN-OS 7.0
Version 3.0 - Revision A 2015, Palo Alto Networks, Inc. www.paloaltonetworks.com

Contents
Summary ........................................................................................................................................................................4
The attack Kill-Chain ......................................................................................................................................................5
Zero Trust Network Security ..........................................................................................................................................5
Palo Alto Networks Firewall Deployment ......................................................................................................................6
Palo Alto Networks Advanced Threat Prevention .........................................................................................................7
Application Identification (App-ID) ................................................................................................................................8
Kill-Chain ....................................................................................................................................................................9
Recommendations .....................................................................................................................................................9
Use Case ..................................................................................................................................................................10
Observations ............................................................................................................................................................11
User Identification (User-ID) ........................................................................................................................................14
Recommendations ...................................................................................................................................................14
Use Case ..................................................................................................................................................................14
Observations ............................................................................................................................................................15
URL Filtering ................................................................................................................................................................17
Kill-Chain ..................................................................................................................................................................17
Use Case ..................................................................................................................................................................18
Observations ............................................................................................................................................................20
Vulnerability Protection...............................................................................................................................................22
Kill-Chain ..................................................................................................................................................................23
Use Case ..................................................................................................................................................................24
Observations ............................................................................................................................................................24
Anti-Spyware ...............................................................................................................................................................26
Kill-Chain ..................................................................................................................................................................27
Use Case ..................................................................................................................................................................28
Observations ............................................................................................................................................................28
Antivirus .......................................................................................................................................................................29
Kill-Chain ..................................................................................................................................................................29
Use Case ..................................................................................................................................................................30
2015, Palo Alto Networks, Inc. [2]

Observations ............................................................................................................................................................30
File Blocking .................................................................................................................................................................32
Kill-Chain ..................................................................................................................................................................32
Use Case ..................................................................................................................................................................32
Observations ............................................................................................................................................................33
WildFire Advanced Malware Prevention .....................................................................................................................35
Kill-Chain ..................................................................................................................................................................35
Use Case ..................................................................................................................................................................36
Observations ............................................................................................................................................................38
DoS Protection .............................................................................................................................................................41
Kill-Chain ..................................................................................................................................................................41
Use Case ..................................................................................................................................................................43
Observations ............................................................................................................................................................44
Zone Protection ...........................................................................................................................................................46
Kill-Chain ..................................................................................................................................................................46
Use Case ..................................................................................................................................................................47
Observations ............................................................................................................................................................47
Automated Correlation Engine ....................................................................................................................................49
Observations ............................................................................................................................................................49
Behavioral Botnet Report ............................................................................................................................................50
Observations ............................................................................................................................................................51
Appendix A: Performance ............................................................................................................................................52
Appendix B: Default Action for Threat Prevention Signatures ....................................................................................53
Appendix C: Guidelines for the Vulnerability Protection Analysis Phase ....................................................................54
Appendix D: Slow HTTP Test Output ...........................................................................................................................56
Appendix E: Evasions ...................................................................................................................................................61
Revision History ...........................................................................................................................................................62

Summary
Over the past years cybersecurity threats have evolved from single-vector attacks to the current incarnations of
advanced persistent threat actors and sophisticated multi-stage malware. In order to provide efficient protection,
todays security solutions need to understand and address all stages of the malware kill-chain.
Palo Alto Networks next-generation Firewall offers Application Identification, URL Filtering, Vulnerability
Protection, Antivirus, Anti-Spyware, WildFire and DoS Protection technologies capable of detecting and preventing
a vast range of threats and malicious communications over the network. Additionally each of these technologies
can assist in breaking the malware kill-chain through automated coordination and interaction between the Threat
Intelligence Cloud and all layers of defense.
This document provides a general overview and use case information regarding the deployment of security policies
and profiles on the Palo Alto Networks next-generation firewall in order to maximize the benefit of an integrated
approach to threat prevention.

The attack Kill-Chain
The term Kill-Chain was originally coined by Lockheed Martin and describes the different stages an attacker
needs to successfully progress in order to achieve its desired objective. The mitigation of just one of these stages
disrupts the chain and the adversary. It is paramount to understand that mitigation requires proactive preventative
measures to be in place. An approach that relies mainly on detection and reactive measures will never result in
timely disruption of the kill-chain. Palo Alto Networks firewalls offer several key technologies that can assist in
disrupting the attack kill-chain. Moreover, with the automation of threat intelligence collection that is provided by
WildFire and the Threat Intelligence Cloud, each firewall has the ability to provide automated protection against
known and unknown threats through timely updates of its threat signatures.
Command Actions on
Reconnaissance Weaponization Delivery Exploitation Installation
and Control Objectives
For a more detailed overview of the kill-chain principle, the following document is available:
http://www.lockheedmartin.com/content/dam/lockheed/data/corporate/documents/LM-White-Paper-Intel-Driven-
Defense.pdf
Zero Trust Network Security

The concept of Zero Trust Network Security is gaining adoption as the preferred foundation for network security
architectures throughout organizations worldwide. Palo Alto Networks next-generation firewall is an obvious
choice when it comes to selecting the Zero Trust segmentation platform that will provide the majority of the
security functionality needed to deliver on the Zero-Trust operational objectives.
For further details on the zero-trust model, the following document is available:
http://csrc.nist.gov/cyberframework/rfi_comments/040813_forrester_research.pdf
The following page discusses a zero-trust approach to network segmentation:
https://www.paloaltonetworks.com/solutions/initiative/network-segmentation.html

Palo Alto Networks Firewall Deployment
Palo Alto Networks next-generation firewalls can be deployed in many different ways. The following deployment
modes are available:
Monitor or visibility mode (tap or span)
Inline transparent mode (virtual wire)
L2 Bridging
L3 Routing
Deployment modes are configured on an interface level and can be combined on the same firewall appliance. The
threat prevention capabilities discussed in this document can be enabled for each of these deployment modes.
For detailed information on the different deployment modes and an overview of available scenarios, please refer
to the following document:
https://live.paloaltonetworks.com/docs/DOC-2561

Palo Alto Networks Advanced Threat Prevention
Palo Alto Networks next-generation firewalls offer a wide range of threat prevention functionalities that interact
with our Threat Intelligence Cloud through a feedback loop mechanism to offer automated protection against
todays advanced threats. By integrating all these functionalities in a single solution, Palo Alto Networks firewalls
offer a unified approach in both security policy design as well as reporting.
Each of these functionalities can protect against specific types of threats and can be configured through firewall
rules, security profiles and zone settings. When combined, these functionalities provide an excellent mechanism to
disrupt an adversarys kill-chain and at the same time improve visibility and control over the network.
This document will cover each of these functionalities and provide guidance on how to create a next-generation
firewall policy by means of a use case. The use case will be built around an example company and focus on
reducing the attack surface for all users and systems present on the network.
Command Actions on
Delivery Exploitation Installation
Block High-Risk Prevent data

Block C2 on
Applications exfiltration and
App-ID non-standard
lateral
Decrypt SSL ports
movement
Block
Block known
Malware and
URL Filtering malicious sites
fast-flux
and links
domains
Vulnerability Prevent lateral
Block exploits
Protection movement
Coordinated
Block spyware intelligence to
Anti-Spyware
and C2 traffic detect and
Block malicious Prevent lateral block active
Antivirus attacks based
files movement
on signatures,
Block source and
Prevent data
unwanted file behaviors.
exfiltration and
File Blocking types and
lateral
prevent drive-
movement
by downloads
WildFire Detect
Detect new Detect new C2
Threat unknown
malicious sites traffic
Intelligence malware
Prevent DoS
DoS/Zone Prevent L3/L4 attacks and
Protection evasions lateral
movement

Application Identification (App-ID)
In todays networking environments, Application Identification is a critical component towards building an
effective security policy. Over the last ten years, use of both the Internet and internal networking has increased
dramatically resulting in an abundance of applications now accessing network services as part of day-to-day
business operations.
The following trends are observed upon closer inspection of network application behavior:
Many Internet bound networking applications are designed to access the Internet over port 80 using the
HTTP protocol or they use port 80 as a fallback port in case their regular port is blocked.
SSL encryption is used more and more in order to securely tunnel applications through the firewall.
Internal applications often use multiple and/or dynamic ports to facilitate communication between end
points.
Using traditional firewalls, it becomes difficult for security administrators to maintain visibility and
distinguish between applications based on port or protocol alone.
Applications by themselves can be used as a launch platform for attacks and carry threats inside a companys
network. Application identification and control helps in reducing the attack surface for your organization, which is
defined as the sum of all possible exploitable targets. All systems, services, applications and users on your network
are a potential target for cybercriminals. By creating security policies based on true application identification
rather than port or protocol alone, it is possible to reduce the risk your systems, services, applications and users
are exposed to. This is done by only allowing those applications that are required for day-to-day business use and
by consequently blocking all others.
Here are some examples of common applications as seen in todays company networks:
http-proxy ms-ds-smb linkedin-base snmpv1 snmp-trap ping active-directory
ssl facebook-base http-video outlook-web google-video- telnet dailymotion

base
web-browsing citrix adobe-update unknown-tcp radius livelink genesys
dns mssql-db ms-sms youtube-base ms-update yammer sharepoint-

documents
twitter-base rtmpt symantec-av- snmp-base rss photobucket webdav

update
ldap facebook-social- google-maps limelight google-translate- ms-netlogon yahoo-mail

plugin base
netbios-ns snmpv2 msrpc google- google-translate- google-picasa tumblr-base

safebrowsing manual
ftp kerberos ntp hotmail netlog ike ssh
flash netbios-dg ms-exchange blackberry flickr gmail-base xing
google-analytics sharepoint-base ipsec-esp unknown-udp netbios-ss soap dostupest
Some applications will also contain a number of application functions. For example, the application Facebook has
application functions such as facebook-base, facebook-chat, facebook-mail, facebook-posting, etc. In order to
enforce proper security policies, it may be required to only allow certain applications functions instead of the
complete application.

A full overview of each supported application is available via the Applications view under the Objects tab or via the
Applipedia web page at: http://apps.paloaltonetworks.com/applipedia/
More information on App-ID can be found here:
https://www.paloaltonetworks.com/products/technologies/app-id.html
Additional technical documentation on App-ID is available here:
https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/app-id.html
Unknown applications
One specific use case of application identification is the ability of the App-ID engine to identify and control
unknown applications. Unknown applications are applications that are not part of the current App-ID application
database and are identified as unknown-udp, unknown-tcp or unknown-p2p.
With regards to App-ID as a threat prevention mechanism, the ability to identify and control unknown applications
becomes important as a generic approach to block malware communication. Malware will often use a proprietary
protocol to communicate with outside command-and-control servers and in many cases this traffic is identified as
unknown.
Kill-Chain
Command Actions on
Block High-Risk Prevent data

Block C2 on
Applications exfiltration and
App-ID non-standard
lateral
Decrypt SSL ports
movement
App-ID can play an important role during several stages of the Kill-Chain. It can disrupt the Delivery stage by
blocking user access to applications that are commonly used for targeted delivery such as social media sites,
personal webmail and file-sharing applications. During the application identification process, it can also provide SSL
decryption to avoid inspection bypass for encrypted content and applications.
One particular feature of App-ID is its ability to classify unknown traffic as unknown-tcp, unknown-udp or
unknown-p2p. This can be leveraged to block connections where the underlying application cannot be identified,
as is often the case with custom outbound C2 channels. As such, App-ID can assist in disrupting the kill-chain at the
Command-and-Control stage.
Finally, App-ID can reenforce a zero-trust architecture by limiting application usage based on user groups. This can
aid in limiting lateral movement capabilities and data exfiltration through specific applications.
Recommendations
The key principle to apply when defining an application based firewall policy is to build a policy that uses a positive
enforcement approach. Positive enforcement means that you selectively allow what is required for day-to-day
business operations as opposed to a negative enforcement approach where you would selectively block everything
that is not allowed. A negative enforcement approach requires you to keep track of any new applications and
constantly adapt your policy to block them. This would be a non-stop task and would still leave a high risk gap. A
positive enforcement approach only requires you to define an allowed list of applications and have the firewall
block everything else with a cleanup rule at the end of the rule base.
Heres an example of the recommended approach showing a positive enforcement firewall policy.

And heres an example of a negative enforcement firewall policy.
As you can see, it will be much easier to maintain a positive enforcement firewall policy over time as you will only
need to add those applications required for day-to-day business operations.
When switching from a port-based to an application-based firewall security policy, the most important task is to
determine what applications should be allowed for day-to-day business operations. If no well-defined list of
allowed applications exists, it is advisable to first configure the Palo Alto Networks firewall as a traditional port-
based firewall or to deploy it in monitoring mode in order to obtain a list of all applications running across your
network. This list should then be examined in order to maintain the required applications and have any non-
desired applications removed from the final policy.
L7 Evasions
App-ID can play an important role in securing your network from L7 evasions. For more information on how to
correctly configure a firewall to protect against evasion techniques, please refer to Appendix E: Evasions.
Given that the App-ID application database now covers most Internet applications, any observation of unknown
traffic should be investigated. In order to apply better control over unknown applications and potentially related
malware, it is advised to create custom applications or configure application override policies where needed to
identify and allow known-good applications that are initially detected as unknown. Combining this approach with a
positive enforcement firewall policy will give you strict control over unknown applications, both known-good and
bad ones.
More information on handling unknown applications can be found here:
User-based access control
Besides explicitly defining what applications are allowed, access to applications should also be restricted on a user
group level as opposed to using IP addresses in the source fields. The following topic will discuss User-ID in detail.
Use Case
The use case section for each topic will create an example policy that describes how to enable and deploy each
feature in an actual security policy.

This first part of the use case will focus on controlling application access for external hosts to public services such
as web or mail servers for our example company. In our use case, access policies for two services will be created:
web and e-mail.
DMZ Inbound Security Policy
To allow outbound access from the DMZ for update purposes, an additional rule will be created.
DMZ Outbound Security Policy
Note: the above rule is very generic and just serves for clarification purposes. In a real
environment, the allowed destinations should be limited to those required for update purposes
where possible.
By defining access by application rather than port or protocol, any traffic to the public services that does not match
the application will be denied. This approach reduces the attack surface for these services by disallowing any
applications that may have been inadvertently been left enabled on the server, but are not required for proper
operation.
Observations
Logs
An overview of all application activity can be consulted via the App Scope Network Monitor, under the Monitor tab.
Drill-down analysis can be performed via the Application Command Center (ACC).

Network Monitor
Traffic that matches a rule will generate a log entry in the firewall traffic log if logging is enabled for that rule. A
rule can have logging enabled on session end (default), but also on session start.
Traffic Log
Any new instances of traffic identified as unknown-udp, unknown-tcp or unknown-p2p will trigger a packet capture
that is included in the corresponding traffic log. These packet captures may provide an initial indication about the
type of traffic.
Traffic Log
Application dependency
Certain applications will depend on other applications for proper operation. In order to allow applications, it is
required that the parent applications are allowed as well. The most common example of such application
dependency is the reliance of web-based applications on applications ssl and web-browsing. Within one particular
application it is also possible that applications functions depend on a parent application. For example, the
application function facebook-posting depends on the parent application facebook-base.
The application web-browsing is a very generic application that encompasses any http-based traffic that is not
recognized as a specific application. If the Palo Alto Networks firewall is positioned in between host systems and a
web-proxy, any proxied http traffic is classified as application http-proxy instead of web-browsing.

As of 5.0, application dependency has been removed for applications that can be identified within a pre-
determined point in the session, and use any of the following protocols: HTTP, SSL, MSRPC, RPC, t.120, RTSP, RTMP,
and NETBIOS-SS. Custom applications based on HTTP, SSL, MS-RPC, or RTSP can also be allowed in security policy
without explicitly allowing a parent application. For example, if you want to allow Java software updates, which
use HTTP, you no longer have to allow web-browsing.
Should you want to allow only specific applications that still have an explicit dependency on web-browsing and at
the same time block all or selected generic web-browsing, you can apply a URL Filtering profile for this purpose.
For more information on URL filtering, see the dedicated topic on this.

User Identification (User-ID)
User Identification allows you to create policies and perform reporting based on users and groups rather than
individual IP addresses. The Palo Alto Networks next-generation firewall supports the following enterprise
directory services:
Active Directory
LDAP
eDirectory
In addition, there is a User-ID agent for Citrix and Microsoft Terminal Services environments and it is possible to
feed 3rd party authentication information to a syslog listener on the firewall or User-ID agent. This allows
integration with other network components that have already authenticated a user, e.g. wireless access solutions.
When using Active Directory, User-ID can be performed transparent to the end-user by deploying one or more
User-ID agents that can monitor user logon events on domain controllers and Exchange servers and perform IP-
address-to-user name mapping. This information is then passed on to the firewall(s) that will perform user-to-
group mapping and match user IDs and/or user groups to the right policy rules.
More information on User-ID can be found here:
https://www.paloaltonetworks.com/products/technologies/user-id.html
Additional technical documentation on User-ID is available here:
https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/user-id.html
Recommendations
When creating policies based on users and groups, it is advised that you make separate rules per user or user
group rather than combine users or groups into one rule, even if they have the same access privileges. This
approach will make overall access management easier for each group. It will also provide more rule-based filtering
possibilities when building custom reports.
In case the User-ID agent is used to provide IP-address-to-user name mapping, it is advised that you deploy
multiple agent instances for redundancy purposes. In addition, you can define a Captive Portal rule for any users
on the network that are not authenticated transparently, e.g. because their host machine is not part of the AD
domain.
Use Case
In this particular part of the security policy design, the following list of applications required per user group has
been defined:
Sales Marketing IT Human Production Management
Resources
web-browsing
linkedin
facebook-base
facebook-posting
twitter
google-analytics

salesforce
webex
google-maps
adobe-update
paloalto-update
ms-update
symantec-av-update
Translating this allow-list into a firewall security policy results in the following rule base:
Internal Users Security Policy
The policy as shown above will reduce the attack surface for these user groups and at the same time improve
workforce performance by blocking access to non-work related applications.
Observations
User identification
Most User-ID mechanisms can identify a user in a transparent way meaning the user will not have to explicitly re-
authenticate against the firewall. In the case where none of these mechanisms apply, a Captive Portal page can be
presented to the user.

Logs
Log entries can be consulted from the Monitor tab, under Logs -> Traffic. As you can see from the screenshot
below, the user name will be present in the log entry.
Traffic Log
User Notification
When access to a web-based application is blocked, the user will receive a notification in the browser window. The
message and page layout can be customized.

URL Filtering
The URL Filtering feature can block access to specific URLs, web sites and web site categories, or generate an alert
when URLs are accessed. You can also define a block list of URLs that are always blocked (or generate alerts) and
an allow list of URLs that are always allowed.
Once firewall access rules have been enabled, a URL Filtering profile can be applied to those rules that allow web
access for internal hosts and users in order to further reduce the overall attack surface of your company. In its
most basic form this can be done by blocking access to those sites classified as being undeniably malicious. Other
possibilities include blocking access to those web categories or sites that pose an increased risk because they serve
a large audience and as such are a favorite source platform for malware propagation by cybercriminals. Examples
include file-sharing sites, user forums or social media sites.
URL Filtering can be enabled either by placing categories directly in the security rule or by defining and enabling a
URL Filtering profile per rule.
There is one default profile available for URL Filtering, which blocks access to the following categories:
Abused-drugs
Adult
Gambling
Hacking
Malware
Phishing
Questionable
Weapons
Custom profiles can be created to filter categories following the companys security or acceptable-use policies.
More information on URL filtering can be found here:
https://www.paloaltonetworks.com/products/features/url-filtering.html
Additional technical documentation on URL Filtering is available here:
https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/url-filtering.html
Kill-Chain
Command Actions on
Block
Block known
Malware and
URL Filtering malicious sites
fast-flux
and links
domains
URL Filtering can be used to reduce the attack surface for employees as well as disrupt the malware kill-chain at
the Delivery stage by blocking access to malicious websites and links pointing to malware deliverables. Additionally,
URL Filtering can prevent access to websites, pages and domains that serve as a C2 servers.
In the case of PAN-DB, the malware category is continuously updated with malicious URLs obtained during
WildFire Analysis of unknown malware. This provides near real-time protection for URL Filtering subscribers
against fast-flux C2 servers.

Recommendations
Depending on your companies risk profile and security policy, you could consider either the Block or Continue
action, besides Allow or Alert. The advantage of the Continue action is that it still allows access after an employee
clicks a Continue button, while at the same time this action will block any unwanted or obfuscated visits to
particular categories or unknown URLs. This offers great protection against drive-by exploits where a link is visited
without the employee being aware of it.
The most obvious categories to block are Malware and Phishing, although other categories can be considered as
well if they are not required for your business daily operations. Additionally, the Unknown category can also be
given a different action than allow or alert to reduce potential risk from unknown URLs or web-sites.
Container Pages
The default setting for a new URL Filtering profile is to only log container pages. This will create a log entry only for
those URIs where the requested page or file matches certain mime-types. The default set includes the following
mime-types:
application/pdf
application/soap+xml
application/xhtml+xml
text/html
text/plain
text/xml
When container page logging is enabled, there may not always be a correlated URL log entry for threats detected
by Antivirus or Vulnerability Protection. If you want to maintain full logging for any URL that was requested, it is
advised to disable container page logging. Alternatively, you can add additional container page mime-types under
Device -> Setup -> Content-ID -> Content-ID features -> Container Pages.
Use Case
In our use case, we will define a URL filtering policy based on the following requirements:
1. Access to the following external sites should be blocked for everyone using the companys Internet link.
This includes employees and guests.
Hacking
Malware
Peer-to-peer
Phishing
Proxy-avoidance-and-anonymizers
Questionable
2. Access to any other external site should be monitored and alerted on for known users, but not blocked.
3. Access to any other external site should be blocked for systems where the user is not identified.
4. Access to the company web site should be allowed for everyone, both internal and external. No URL
filtering should be performed on this type of traffic.

The first requirement can be accomplished by creating a firewall block rule for these categories. By placing this rule
before any other rules that allow outbound access you can assure that no person or system behind the firewall can
access any of these categories.
Restricted URL Categories Security Policy
The second requirement can be accomplished by creating a URL Filtering profile that alerts on all categories and
applying this profile to the access rule that is already in place for each user group. One additional firewall rule will
be created to match any remaining authenticated users that do not match the existing rules.
Note: As long as the user group access rules are positioned below the generic Restricted Sites
block rule there is no need to enable blocking for these categories in the Alert All URL Filtering
profile. If you want to have additional safety built-in or if you do not wish to use a general rule for
these Restricted Sites as described under the first requirement, then you can enable blocking for
those categories in the URL profile as well.
Security Policy with URL Filtering profile enabled

The third requirement is accomplished by adding a general block rule that blocks any traffic not explicitly allowed.
This rule is then placed at the bottom of the rule base.
Security Policy with Block All rule configured
Note: A Block All rule overrides the default intrazone and interzone rules and can potentially
block intrazone connections that are otherwise allowed. Make sure you add the necessary rules
above the Block All rule to explicitly allow this traffic should this be the case. As of PAN-OS 6.1 the
default intrazone and interzone rules are editable and can be configured to also log traffic. As
such, they may offer a good alternative to a more generic Block All rule without changing the
intrazone default behavior.
The fourth requirement is accomplished by the External Web Access rule that was placed at the top of the rule
base under the Application Identification section of this use case.
Observations
Logs
URL Filtering log entries can be consulted via the URL Filtering log view, under the Monitor tab. The detailed view
for a particular URL will also reference related logs associated with that URL log entry.
URL Filtering Log

URL Filtering Log Detailed Log View
User Notification
When access to a web site is blocked, the user will receive a notification in the browser window. The message and
page layout can be customized.

Vulnerability Protection
The Vulnerability Protection feature detects and prevents network-borne attacks against vulnerabilities on client
and server systems. Vulnerabilities can be system and service specific or generic and are not bound to a specific
port, but to a protocol or application.
Predefined Vulnerability Protection Profiles
Currently there are two predefined profiles available for the Vulnerability Protection feature:
The default profile applies the default action to all client and server critical, high, and medium severity
vulnerabilities. It does not detect low and informational vulnerability protection events.
The strict profile applies the block response to all client and server critical, high and medium severity
spyware events and uses the default action for low and informational vulnerability protection events.
Custom Vulnerability Protection Profiles

In addition to the predefined Vulnerability Protection profiles, you can create custom profiles tailored to the
environment you want to protect. A custom profile can contain one or more rules and exceptions that define
which vulnerability protection signatures to include.

Custom profiles also allow you to enable packet captures of matching traffic. This can be used for evidence
gathering or troubleshooting purposes.
More information on Vulnerability Protection can be found here:
https://www.paloaltonetworks.com/products/features/ips.html
Additional technical documentation on Threat Prevention is available here:
https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/threat-prevention.html
Kill-Chain
Command Actions on
Vulnerability Prevent lateral
Block exploits
Protection movement
Vulnerability Protection can assist in breaking the attack kill-chain at the Exploitation stage by preventing client
and server vulnerabilities from being exploited. It can also provide the same protection during lateral movement
attempts where vulnerabilities on internal hosts can provide a means to compromise additional systems.
Recommendations
When deploying vulnerability protection, special care should be taken to avoid a negative impact on the protected
traffic. While vulnerability protection signatures are developed with great care and are submitted to extensive
regression tests, some of the signatures are generic in nature and can trigger on traffic coming from misconfigured
services or faulty applications. This is especially true for applications that have been custom-built such as in-house
developed web applications. Because of this, it is generally not a good idea to simply turn on blocking for large
groups of signatures without prior examination of those signatures and the potential impact they may have on the
network.
If time and circumstances permit, it is advised to include an analysis phase in the vulnerability protection
deployment timeline. In particular for environments where service availability is critical, such a phase will be
required to assure proper functionality of the infrastructure once vulnerability protection is made fully operational.

In general, it is advised to start with a profile that uses the default action for each signature. Alternatively, it is
possible to deploy a custom vulnerability protection profile in alert-only or monitoring mode first, to obtain a clear
picture on how blocking-mode may affect the infrastructure. Such a profile will have the action set to alert for
each signature. For a more detailed description of the steps involved to deploy an alert-only profile during an
analysis phase, see Appendix C: Guidelines for the Vulnerability Protection Analysis Phase.
Use Case
In our use case, we will enable Vulnerability Protection for all traffic generated by internal users as well as
outbound traffic for the DMZ. A clone of the default Vulnerability Protection profile will be applied to each rule.
Internal Users Security Policy with Vulnerability Protection profile enabled
DMZ Security Policy with Vulnerability Protection profile enabled
Observations
Logs
Details for Vulnerability Protection alerts can be consulted via the Threat log view, under the Monitor tab. The
detailed view for a particular threat will also reference related logs associated with the threat log entry.
Threat Log

Threat Log Detailed Log View
Starting with firmware 5.0, it is possible to create IP address-based exceptions for Vulnerability Protection events.
This can be accomplished by clicking on the threat name in the Threat log view and adding the exempt IP
addresses for selected exempt profiles in the pop up window.
This will create an exception for this threat/IP address combination in the selected Vulnerability Protection
profiles.

Anti-Spyware
The Anti-Spyware feature detects and prevents spyware and malware network communications. Unlike the
Antivirus feature, the Anti-Spyware feature is not limited to specific protocols and can detect any type of phone-
home communication.
Predefined Anti-Spyware Profiles
There are two predefined profiles available for the Anti-Spyware feature:
The default profile applies the default action to all critical, high, medium and low severity spyware
events. It does not detect informational severity spyware events.
As of 5.0, the default profile applies the alert action to DNS queries that trigger DNS signatures for
malware domains.
The strict profile applies the block response to critical, high and medium severity spyware events and
uses the default action for low and informational severity spyware events.
As of 5.0, the strict profile applies the block action to DNS queries that trigger DNS signatures for
malware domains.
Custom Anti-Spyware Profiles

In addition to the predefined Anti-Spyware profiles, you can create custom profiles tailored to the environment
you want to protect. A custom profile can contain one or more rules and exceptions that define which Anti-
Spyware signatures to include.

Custom profiles also allow you to enable packet captures of matching traffic. This can be used for evidence
gathering or troubleshooting purposes.
DNS Sinkholing
The Anti-Spyware profile offers the ability to apply a sinkhole action to DNS queries made to malicious domains.
The DNS sinkhole action provides administrators with a method of identifying infected hosts on the network using
DNS traffic, even when the firewall is north of a local DNS server (i.e. the firewall cannot see the originator of the
DNS query). When a threat prevention license is installed and an anti-spyware profile is enabled in a security
profile, the DNS-based signatures will trigger on DNS queries directed at malware domains. In a typical deployment
where the firewall is north of the local DNS server, the threat log will identify the local DNS resolver as the source
of the traffic rather than the actual infected host. Sinkholing malware DNS queries solves this visibility problem by
forging responses to the queries directed at malicious domains, so that clients attempting to connect to malicious
domains (for command-and-control, for example) instead attempt connections to an IP address specified by the
administrator. Infected hosts can then be easily identified in the traffic logs because any host that attempts to
connect to the sinkhole IP are most likely infected with malware.
Passive DNS
The Anti-Spyware profile also offers the ability to enable passive DNS collection. Passive DNS is an opt-in feature
that 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. The data collected includes non-
recursive (i.e. originating from the local recursive resolver, not individual clients) DNS query and response packet
payloads.
More information on Anti-Spyware can be found here:

https://www.paloaltonetworks.com/products/technologies/content-id.html
Additional technical documentation on Anti-Virus is available here:
Kill-Chain
Command Actions on
Block spyware
Anti-Spyware
and C2 traffic
The Anti-Spyware feature can be used to disrupt the attack kill-chain at the Command-and-Control stage by
preventing compromised hosts to establish a C2 channel to control systems outside the company network.

Recommendations
The predefined profiles will cover the majority of use cases. Because predefined profiles are read-only, it is advised
to work with a custom clone of the predefined profiles, so exceptions can be defined when needed. In
environments where blocking traffic is not allowed, a custom profile can also be used to only alert on spyware
events.
Use Case
In our use case, we will enable Anti-Spyware for all traffic generated by internal users. A clone of the strict Anti-
Spyware profile will be applied to each rule.
Internal Users Security Policy with Anti-Spyware profile enabled
In addition, it is advisable to also turn on Anti-spyware for any security rules that allow outbound traffic from the
DMZ.
DMZ Security Policy with Anti-Spyware profile enabled
Observations
Logs
Details for Anti-Spyware alerts can be consulted via the Threat log view, under the Monitor tab. The detailed view
for a particular threat will also reference related logs associated with the threat log entry.

Antivirus
The Antivirus feature detects and prevents viruses and malware from being transferred over the following
protocols:
HTTP
FTP
SMTP
IMAP
POP3
SMB
Files transferred by any application that uses any of the above protocols can be inspected by the Antivirus feature.
Inspection is done through stream-based analysis, which means files are not cached or stored in their entirety on
the firewall, but analyzed in real-time as they pass through the firewall.
There is one predefined profile - named default - available for the Antivirus profile. This profile has the default
action configured for each protocol. The default action differs for each protocol and follows the most up-to-date
recommendation from Palo Alto Networks. The default action for each protocol is listed below.
Note: The reason why SMTP, POP3 and IMAP have the default action set to ALERT is because in
most cases there is already a dedicated Antivirus gateway solution in place for these protocols.
Specifically for POP3 and IMAP, it is not possible to clean files or properly terminate an infected
file-transfer in-stream without affecting the entire session. This is due to shortcomings in these
protocols to deal with this kind of situation.
Custom profiles can be created and allow you to customize the action for each protocol.
More information on Antivirus can be found here:
https://www.paloaltonetworks.com/products/features/antivirus.html
Additional technical documentation on Anti-Virus is available here:
Kill-Chain
Command Actions on
Block malicious Prevent lateral
Antivirus
files movement

The Antivirus feature can be used to disrupt the attack kill-chain at the Installation stage by blocking malicious files
and exploit tools as they traverse the network. It can also provide the same protection during lateral movement
attempts where exploit kits or other tools are copied over to other compromised hosts.
Recommendations
The Antivirus feature can be used to disrupt the attack kill-chain at the Installation stage as well as prevent lateral
movement by blocking malicious files and exploit tools as they traverse the network.
The default Antivirus profile settings can be used in most situations where dedicated SMTP, POP3 and/or IMAP-
scanning solutions are also present. Because predefined profiles are read-only, it is advised to work with a custom
clone of the predefined profiles, so exceptions can be defined when needed.
If no dedicated Antivirus gateway solution is present for SMTP, it is possible to define a custom Antivirus profile
and apply the reset-both action to infected attachments. In such case, a 541 response will be sent back to the
sending SMTP server to prevent it from resending the blocked message.
Typically, Antivirus signatures have an extremely low false positive rate. Should a false positive occur, it is possible
to exclude specific Threat IDs from detection by defining Virus Exceptions in the Antivirus profile. For the same
purpose, certain applications can also be excluded from being inspected. In such cases, it is best practice to create
a specific profile and apply this profile to only the rules that are affected.
Use Case
In our use case, we will enable Antivirus for all traffic generated by internal users. A clone of the default Antivirus
profile will be applied to each rule.
Internal Users Security Policy with Antivirus profile enabled
Additionally we will also enable Antivirus for outbound update traffic from the DMZ.
DMZ Security Policy with Antivirus profile enabled
Observations
Logs
Details for each Antivirus alert can be consulted via the Threat log view, under the Monitor tab. The detailed view
for a particular threat will also reference related logs associated with the threat log entry.
Threat Log

Threat Log Detailed Log View
User Notification
Users who are attempting to download an infected file will be presented with a Virus Download Blocked message
in the browser. The message and page layout can be customized.

File Blocking
By using File Blocking profiles, it is possible to detect and prevent downloads or uploads of specific file types. As
with all other security profiles, file blocking profiles can be enabled on a per rule basis and as such granular control
can be applied to file transfers for specific network segments, users and user groups.
Kill-Chain
Command Actions on
Block
Prevent data
unwanted file
exfiltration and
File Blocking types and
lateral
prevent drive-
movement
by downloads
File Blocking profiles can be used to disrupt the attack kill-chain at the Installation stage by preventing downloads
or uploads of specific file types such as executables. This can be particularly useful in blocking drive-by download
attempts after exploitation where a user is not aware a file is being transferred in the background. File Blocking
profiles can also help in preventing data leakage by preventing file uploads to public hosted services other than
company approved services.
Recommendations
File blocking can be particularly useful in preventing users from downloading and installing unverified software on
company assets and can also prevent drive-by downloads. No predefined file blocking profiles exist, but they are
easy to create. If blocking files is too strict for your environment, you should consider using the Continue action
instead. This will require a user to explicitly confirm a download and provides a simple but effective protection
mechanism against drive-by downloads.
Use Case
In our use case, we will implement the following requirements with regards to file blocking for all user groups
except the IT user group.
- Block executables
- Block torrent files
- Warn the user when downloading encrypted files
The file blocking profile looks as follows:

This profile is then enabled for each user access rule except the IT user group.
Internal Users Security Policy with File Blocking profile enabled
Observations
Logs
File transfers in sessions matching a rule with a file blocking profile enabled will generate a log entry in the Data
Filtering log view, under the Monitor tab.
Data Filtering Log
User notification
When a file download is blocked, the user will see a block or continue notification in the browser.

WildFire Advanced Malware Prevention
Modern malware is at the heart of many of today's most sophisticated network attacks and is increasingly
customized to avoid traditional security solutions. Palo Alto Networks has developed an integrated approach that
addresses the full malware life cycle, which includes preventing infections, identifying zero-day malware (that is,
malware that has not previously been identified by other antivirus vendors) or targeted malware (malware
targeting a specific industry or corporation), as well as pinpointing and disrupting active infections.
The Palo Alto Networks WildFire engine exposes zero-day and targeted malware through direct observation in a
virtual environment within the WildFire system. The WildFire feature also makes extensive use of Palo Alto
Networks App-ID technology by identifying file transfers within all applications, not just email attachments or
browser-based file downloads.
The key benefits of the Palo Alto Networks WildFire feature is that it can discover zero-day malware and can
quickly generate signatures to protect against future infections of all of the malware it discovers. The firewall can
provide instant alerts whenever malware is detected on your network by sending email alerts, syslog alerts, or
SNMP traps. This allows you to quickly identify the user who downloaded the malware and eradicate it before it
causes extensive damage or propagates to other users. In addition, every signature generated by WildFire is
automatically propagated to all Palo Alto Networks firewalls protected with a Threat Prevention, URL Filtering
and/or WildFire subscription, which provides automatic protection from malware even if it was not found in your
network. Palo Alto Networks is currently discovering and generating signatures for thousands of zero-day malware
every week and this number continues to grow.
WildFire is available as both a cloud-based as well as an on-premise solution: the WF-500.
More information on WildFire can be found here:
https://www.paloaltonetworks.com/products/technologies/wildfire.html
Additional technical documentation on WildFire is available here:
https://www.paloaltonetworks.com/documentation/70/wildfire/wf_admin.html
Kill-Chain
Command Actions on
WildFire Detect
Detect new Detect new C2
Threat unknown
malicious sites traffic
Intelligence malware
WildFire Analysis results are used to generate signatures for several protection mechanisms. Currently, WildFire
can generate file and dns signatures as well as add malicious URLs to the PAN-DB malware category. As such it
provides a very useful capability to automate the kill-chain disruption approach for unknown malware.
Recommendations
Due to the proliferation of unknown malware it is highly recommended to enable WildFire Analysis for files coming
from locations that are not trusted. WildFire Analysis profiles can be configured to forward files to either the
public-cloud WildFire or a private-cloud WF-500. WildFire is capable of analyzing files of type apk, ms-office, jar,
flash, email-link and pdf in addition to executable file types (PE). To forward these file types to the WildFire
analysis engine, a WildFire Analysis profile needs to be created.
Note: For pre-7.0 deployments, a file blocking profile with an action of forward or continue-and-
forward needs to be created to forward files to WildFire.

In addition to forwarding files for analysis, malicious file transfers can also be immediately blocked if a WildFire file
signature is already available. To achieve this, configure the Antivirus profile with a reset-both action for the
WildFire Action for applicable protocols.
Antivirus profile WildFire Action
Use Case
In our use case, we will enable forwarding of files to the WildFire public cloud for all communication between users
and the untrust zone. In addition, all communication between users and the datacenter will be subject to
forwarding to the WildFire private cloud (WF-500). Finally, all inbound smtp traffic to the mail-relay in the DMZ will
also be subject to forwarding.
Files originating from or destined to a public source are generally allowed to be forwarded to the WildFire public
cloud. So the WildFire Analysis profile that will be used to forward files between users and the untrust zone looks
as follows:
WildFire Analysis profile for user communication to untrust
This profile is enabled for all rules that allow users access to the untrust zone.

Security Policy for user communication to untrust with WildFire Analysis profile enabled
For files that contain sensitive information or are considered classified, there is the option to have these analyzed
using the WildFire private cloud (WF-500). In our example use case, it is decided that executable files can be
forwarded to the public cloud even if they originate from an internal source, but document files should be
analyzed using the private cloud option. The WildFire Analysis profile looks like this:
WildFire Analysis profile for user communication to datacenter
Security Policy for user communication to the datacenter with WildFire Analysis profile enabled
Enabling WildFire Analysis for all files received via email requires a WildFire Analysis profile to be enabled on the
rules that allow inbound smtp communication. Additionally, this profile can also be enabled for outbound
communication. The WildFire Analysis profile for our use case looks as follows:

WildFire Analysis profile for communication between DMZ and untrust zones
This profile is then enabled on the security rules that allow smtp communication between the DMZ and untrust
zones.
Security Policy for communication between DMZ and untrust zones with WildFire Analysis profile enabled
Observations
Logs
Once a file has been analyzed or verified against the WildFire DB, a log entry will be created in the WildFire
Submissions log view, under the Monitor tab.
WildFire Submissions Log
Detailed reporting of the WildFire Analysis results are available through the Detailed Log View.

The WildFire Analysis report can be downloaded as a pdf from this window and it is also possible to download the
original sample file and pcap file of network traffic from the malware sample as seen by WildFire. Furthermore, the
report includes dynamic analysis results from all virtual environments against which the sample was executed.
Finally, the new report also allows you to report an incorrect verdict for each analysis directly from the report.
Signature Generation
If a file is found to be malicious during WildFire Analysis, protection signatures will be generated and made
available as part of the Dynamic Updates mechanism. WildFire file signatures updates are generated every 15
minutes and Anti-Spyware DNS signatures are generated daily. Furthermore, malicious URLs are added to the
malware URL Filtering category in PAN-DB within 15 minutes of analysis.
If a file is malicious and a WildFire file signature is available and installed, the file can be blocked by the Antivirus
functionality and the firewall will generate a wildfire-virus log entry in the Threat Log.
User notification
When a file download is performed and the file is identified as malicious because it matches a WildFire signature,
the file will be blocked according to the settings in the Anti- Virus profile and the user will receive a notification in
his browser.

DoS Protection
The DoS Protection feature detects and prevents network-borne Denial-of-Service attacks. Two DoS protection
mechanisms are available:
Flood ProtectionDetect and prevent flooding attacks where the network is flooded with packets which
typically result in too many half-open sessions and/or services being unable to respond to each request. In
this type of attack, the source address is often spoofed. Flood Protection can start blocking packets on an
aggregate or classified basis as soon as a configurable threshold has been exceeded.
Resources ProtectionDetect and prevent session exhaustion attacks. This type of attack is typically
performed using a large amount of source hosts (bots) to create as many fully established sessions as
possible. It is more difficult to detect as the sessions may be used to send valid-looking requests to the
target host. Resources Protection can limit the amount of available sessions on an aggregate or classified
basis.
Both mechanisms can be used together in the same DoS Protection profile.
Kill-Chain
Command Actions on
Prevent DoS
movement
While DoS Protection in itself does not provide any mechanism to disrupt the kill-chain, it can assist in reducing the
impact of any cybercriminal action or objective that is aimed at impacting internal or public company services by
performing a DoS or resource starvation attack against.

Recommendations
Defining the correct DoS Protection profile(s) largely depends on what services require protection and what
audience will be served. Because each environment is different, a certain amount of up-front analysis will need to
be done. Some configuration examples are provided further down this guide.
Regardless of the environment, it is important to pay special attention to the following factors.
Default threshold values
Maximal Rate
Aggregate vs Classified profiles
SYN-cookie vs Random Early Drop
Default threshold values
The default DoS Protection threshold values do not represent best practice values. Threshold values should be
configured based on actual session data for the environment (i.e. zones, hosts) where DoS Protection profiles will
be applied. A proper method to obtain this baseline data is to configure Netflow reporting on the firewall to a
Netflow analyzer.
Note: As of 4.0, SYN-cookie is active by default if selected as a protection mechanism with the
default Activate Rate setting (Activate Rate = 0).
SYN-cookie & Maximal Rate default values
Maximal Rate
When the Maximal Rate threshold is exceeded, any further packets that match the DoS Protection rule and
classification criteria (in case of a classified profile) will be dropped for the block duration specified. The default
value for SYN-cookie is 1.000.000 which will prevent it from being triggered in almost any environment. You should
adjust this value to match your environment in the following scenarios:
To protect against TCP SYN floods where Random Early Drop is used.
To protect against UDP, ICMP or other IP floods.

When SYN-cookie is used in a source-ip classification profile and there is never a need for a client to send
more SYN pps than the maximal rate value. The SYN-cookie mechanism already provides protection by
itself, so the maximal rate value will not provide additional protection to any service except for the
firewalls SYN-cookie mechanism itself.
Aggregate vs Classified profiles
When configuring DoS thresholds for flood and resources protection it is important to understand the difference
between aggregate and classified profile types.
AggregateApplies the DoS thresholds configured in the profile to all packets that match the rule criteria
on which this profile is applied. For example, an aggregate rule with a SYN flood threshold of 10000
packets per second (pps) counts all packets that hit that particular DoS rule.
ClassifiedApplies the DoS thresholds configured in the profile to all packets matching the rule and
classification criteria (source IP, destination IP or source-and-destination IP). For example, a classified rule
with a SYN flood threshold of 10000 packets per second (pps) and source-ip as the classification criterion
counts all packets per source IP address that hit that particular DoS rule.
From these definitions, you can already guess that an aggregate profile will be the better choice when protecting
against attacks from the Internet. A classified profile is less appropriate here because there may be many clients
residing behind a NAT device.
For internal clients not behind a NAT device, a source-ip classification profile may be a good fit from a resource
limitation point of view. For example, in an educational environment where internal clients are allowed to run any
type of tool (e.g. peer-to-peer) this can be used to limit the amount of concurrent sessions per client to prevent
overall session saturation.
SYN-cookie vs Random Early Drop
SYN-cookie is a superior mechanism to counter SYN flood attacks. It is preferred over Random Early Drop for
defending against SYN floods. For other traffic, Random Early Drop is the default and only option. Random Early
Drop starts randomly dropping packets if the packet rate is between the Activate Rate value and Maximal Rate
value. The drop probability increases linearly with the packet rate. If the packet rate exceeds the Maximal Rate
value then all excess packets will be dropped.
Use Case
The following examples will provide some ideas on how to implement DoS Protection profiles.
With only one or more web servers to protect, DoS Protection profiles and rules can be very generic. However, it is
good practice to already plan for future service additions by making the DoS Protection rules as specific as possible.
Requirements:
A DoS Protection profile that protects against SYN floods as well as TCP session exhaustion attacks.
One or more DoS Protection rules that apply the profile to matching traffic.
DoS Protection profile
To protect against SYN Floods, it is advised to use the SYN-cookie mechanism over Random Early Drop as it is
superior in preventing floods to reach the target. Adjust the rate values based on actual session data from the
protected environment.
To protect against session exhaustion, you should balance the advantages and disadvantages of the following
techniques and choose the most appropriate one or a combination for your environment:
Use a classified profile with limited concurrent sessions per source-destination-ip. This will reduce the
impact from a limited botnet attack while maintaining availability for regular clients. If you set the session

limit too low, this may affect concurrent clients accessing your web service from behind a NAT device. If
you set it too high, it becomes easier for a small botnet attack to exhaust all available sessions.
Use an aggregate profile in combination with geo-IP location data in the DoS Protection rule base. An
aggregate profile in itself is not sufficient to prevent a session exhaustion attack, but combined with geo-
IP location data in the DoS Protection rule base, it can reduce the impact of a global DDoS attack. This
approach is acceptable if the main audience for your web service resides in a select list of countries.
Use a classified profile with limited concurrent sessions per source-destination-ip in combination with
geo-IP location data. This approach will require some time to set up and tune, but may prove very
effective in the end.
DoS Protection rules

Once the necessary DoS Protection profiles have been defined, you can make them active by creating DoS
Protection rules. DoS Protection rules define source and destination parameters on which the profile will be
applied.
It is best practice to make the rules as specific as possible. For this particular example situation, you would define a
rule for each server/service you want to protect. By doing so, the counter values defined in the profile will apply
only to the server/service defined in the rule.
The screenshot below shows a DoS rule configuration using an aggregate profile in combination with geo-IP
location data.
Note: you can use negate to assign a specific DoS Protection profile to any source IP address not
from a particular country. This can be a worthwile approach in DDoS defense by limiting sessions
for countries that do not typically fall within the general visitor audience for an enterprises web
site.
Observations
Flood Protection
When enabled and triggered, Flood Protection alerts are sent to the Threat Log. Log entries will display different
values for source and destination zones and addresses depending on the type of DoS Flood Protection that was
configured. Destination port will always show 0.
When set to aggregate, then both source and destination address fields will display 0.0.0.0 and no zone
information is displayed.

When set to classified, source and destination address fields will display the actual addresses if they are
part of the classification criteria.
o E.g. source-ip will only list actual source IP addresses
o E.g. source-dest-ip will list actual source and destination IP addresses
Resources Protection
When enabled, Resources Protection will limit the number of concurrent sessions that match the DoS Protection
rule. No log entries will be created when the maximum number is reached. There is a session timeout that will
keep a session in the state table for 30 seconds by default after the session has been ended with FIN/RST. The
result is that the actual number of concurrent active sessions as perceived from the client side may not always
match the maximum number configured in the DoS Protection profile. See Appendix D: Slow HTTP Test Output for
the output of a slowhttptest attack for further clarification.

Zone Protection
Zone Protection profiles provide the possibility to configure additional protection mechanism that can be applied
to specific network zones.
The following protection mechanisms are available:
Flood ProtectionPrevents flooding attacks in the same way as the Flood Protection feature in DoS
Protection profiles.
Reconnaissance ProtectionDetects and blocks port scans and host sweeps.
Packet Based Attack ProtectionProvides protection against specific IP level attacks.
Kill-Chain
Command Actions on
Prevent DoS
movement
Zone Protection can prevent L3/L4 evasions through its Packet Based Attack Protection functionality and can as
such play an important role in disrupting the kill-chain at the Exploitation stage. It can also prevent network/host
scans which are typically used during the Reconnaissance stage.
Recommendations
Zone protection profiles can only be applied to entire zones. Therefore it is important to investigate any possible
issues that may arise when applying zone protection profiles.
Flood Protection
Configure Flood Protection settings based on the number of packets you want to allow to each service behind the
firewall. Settings apply to all traffic that enters the network through any interface in the zone on which the Zone
Protection Profile is active, but a separate counter is maintained for each source IP/destination IP/destination port
tuple.
Reconnaissance Protection
In general it should be safe to enable this feature on external zones. For internal zones however, you should make
sure settings will not negatively affect any monitoring tools that often use the same scanning techniques to
determine if servers and services are up and running.
Packet Based Attack Protection
In general it should be safe to enable this feature on external zones. For internal zones however, you should make
sure settings will not negatively affect network communications from other devices that may rely on some of these
techniques for proper operation.
One specific example is the use of ICMP Ping ID 0, where other devices may use this type of packet to check
availability of hosts they need to communicate with. Blue Coat proxy devices have been known to do this.
L4 evasions

Packet Based Attack Protection can play an important role in securing your network from L4 evasions. For more
information on how to correctly configure a firewall to protect against evasion techniques, please refer to
Appendix E: Evasions.
Use Case
In our use case, we will enable a Zone Protection profile for the untrust zone, i.e. the zone where public traffic is
reaching the firewall.
Zone Protection profile
Zone settings
Observations
Flood Protection

Flood Protection is identical to the same feature available in DoS Protection profiles. However, since it can be
applied to a zone only, there are less fine-tuning options available to match specific traffic flows based on service
or IP address as you could do with DoS Protection rules.
Flood Protection enabled under Zone Protection is applied to the aggregate traffic seen on a specific zone. It will
maintain a single counter for all traffic, regardless of source IP/destination IP/destination port. This is similar to
Flood Protection under DoS Protection, when an aggregate profile type is selected.
When enabled and triggered, Flood Protection alerts are sent to the Threat Log. Log entries will show the zone
name for which the profile was triggered in both source and destination zone fields, while source and destination
addresses will show 0.0.0.0. Destination port will also show 0, even if the flood attack was against a specific port.
Reconnaissance Protection
Reconnaissance protection can detect and block host sweep and TCP & UDP port scans. It will trigger when the
amount of scan packets exceeds the thresholds within the intervals specified.
TCP and UDP Port scan will trigger when a TCP or UDP port scan is executed against a single host and the
scan packet rate exceeds the configured threshold.
Host Sweep will trigger when a range of hosts is scanned on specific ports either through TCP, UDP or
ICMP.
When enabled and triggered, Reconnaissance Protection alerts are sent to the Threat Log.
Packet Based Attack Protection

Packet Based Attack Protection can detect and prevent attacks that try to evade firewall inspection. When enabled,
packets that match detection criteria will be dropped and since this type of traffic is considered noise, no log entry
will be written to the Threat Log.

Automated Correlation Engine
The Automated Correlation Engine is an exciting new addition to the alerting capabilities of Palo Alto Networks
firewalls and Panorama. It is an analytics tool that uses the logs on the firewall to detect actionable events on your
network. The engine correlates a series of related threat events that, when combined, indicate a likely attack on
your network. It pinpoints areas of risk, such as compromised hosts on the network, allows you to assess the risk
and take action to prevent exploitation of network resources. The automated correlation engine uses correlation
objects to analyze the logs for patterns and when a match occurs, it generates a correlated event.
More information on the Automated Correlation Engine can be found here:
https://www.paloaltonetworks.com/documentation/70/pan-os/newfeaturesguide/management-
features/automated-correlation-engine.html
Recommendations
The Automated Correlation Engine uses Correlation Objects which are by default all enabled. Correlation Objects
can be viewed and enabled/disabled via Monitor > Automated Correlation Engine > Correlation Objects.
Observations
Correlated events can be viewed under Monitor > Automated Correlation Engine > Correlated Events.

Behavioral Botnet Report
The Palo Alto Networks Behavioral Botnet Report automates the process of tracking and correlating the behaviors
that indicate the presence of a bot. This intelligence looks for a variety of characteristics, which are briefly
summarized below:
Unknown TCP/UDP Botnet traffic is regularly encrypted and unknown. Since Palo Alto Networks
identifies all traffic tracking unknown TCP and UDP traffic can be a perfect starting point for finding bot-
infected machines. The report allows staff to track unknown traffic by sessions, destinations and bytes.
Presence of Dynamic DNS Malware will often use dynamic DNS in order to make botnet
communications more difficult to track. By bouncing traffic between multiple infected hosts with an ever-
changing list of IP addresses, it can become very difficult to track the path of the bot and its true source
and destination.
Activity on Known Malware Sites As part of the URL filtering solution, Palo Alto Networks constantly
tracks sites that have hosted malware whether intentionally or unintentionally. Palo Alto Networks can
track if a user is repeatedly visiting one of these sites and attempting to download files.
Visiting Recently Registered Domains Botnets are constantly moving around in order to avoid detection
and to recover as servers are discovered or disabled. As a result, botnets will often have to use new
domains to support the command and control infrastructure. A user repeatedly visiting a newly registered
domain will certainly not be conclusive, but may help to provide corroborating evidence of an infection.
Browsing to IP domains Instead of URL In a similar vein, bots will often use hard-coded IP addresses or
known IP ranges in order to communicate as opposed to users which typically prefer to use URLs. As with
tracking newly registered domains, tracking connections using IP domains can sometimes indicate the
presence of a bot at work as opposed to a human.
Executable files from unknown sites Identifies executable files downloaded from unknown URLs.
IRC traffic IRC traffic is one of the most well-known communication methods for botnets, and provides
an additional strong piece of correlating data for finding a bot.
The Behavioral Botnet Report takes all of the factors above and automatically correlates them to find hosts that
are likely infected with a bot. When run, the report provides specific directory user names of the users or machines
that are likely infected along with what behaviors contributed to the analysis. Each user is also provided a score
based on how many of the factors listed above were correlated, allowing staff to focus on the devices that are the
most likely to be infected.
Recommendations
The behavioral botnet report is enabled by default. It will run on a daily basis and generate a report on the
detected behaviors for the previous day. It may be required to further tune the default detection threshold values
based on the initial report findings.

Observations
When enabled, the botnet report is run every night on the log data that was collected for the previous day. The
report will display hosts together with a confidence score and suspicious behavior details.

Appendix A: Performance
Threat Prevention performance will not be impacted by the number of Threat Prevention profiles or the number of
signatures that are enabled thanks to the single pass parallel processing architecture (SP3) unique to the Palo Alto
Networks firewall. Any session content is inspected in parallel by the Antivirus, Anti-Spyware and Vulnerability
Protection features.
One notable configuration setting that will have a positive impact on performance is DSRI or Disable Server
Response Inspection. With DSRI turned on, server response traffic is not inspected, which will increase the
throughput capacity. Obviously, enabling this feature is only recommended for trusted servers.

Appendix B: Default Action for Threat Prevention Signatures
Every threat signature present in the Anti-Spyware and Vulnerability Protection profiles has a default action
assigned to it. This default action is the action that will be performed when default is selected as the action in
threat prevention rules that define the security profile.
Upon the initial installation of a Threat Prevention update, the default action for each signature is set by the Palo
Alto Networks Threat Prevention research team to the most appropriate response at any moment based on a
wider set of criteria. The default action can change over time when new threat prevention updates are released.
The default action can also be modified on a per-signature basis when creating a custom profile.
Below are the available actions that can be applied to individual Anti-Spyware and Vulnerability Protection events.
Default
Allow
Alert
Drop
Reset-both
Reset-client
Reset-server
Block-IP
For the Antivirus feature, the default action is not set on a per-signature basis, but configured and applied per
protocol.
Below are the available actions that can be applied to Antivirus events.
Allow
Alert
Drop
Reset-client
Reset-server
Reset-both

Appendix C: Guidelines for the Vulnerability Protection Analysis
Phase
The goal of this phase will be to determine the correct vulnerability protection profile settings for each of the
protected segments and hosts. Multiple profile configurations may be needed for different segments and hosts in
your network.
The following steps will help you determine the correct profile settings for a given location or host.
1. Configure an alert-only protection profile.
2. Configure the necessary firewall rules for hosts and segments you want to protect.
3. Apply the alert-only protection profile to each rule.
4. Monitor the threat logs for a representative period of time (e.g. 1 week, 1 month).
5. Investigate any potential false positives.
6. Use the gathered analysis information to build and fine-tune a block-enabled protection profile.
Configure an alert-only protection profile
The goal here is to create a alert-only protection profile that has alert defined as the action for each signature.
This will prevent the accidental blocking of legitimate traffic during the analysis phase. You can accomplish this
with one profile rule that includes all signatures. The disadvantage of this approach is that the threat log will not
display the actual action applied when in blocking mode using the default action for each signature.
Alternatively you can monitor a segment or host via a port of the firewall in TAP-mode and use a protection profile
that applies the default action for each signature. This will also prevent the accidental blocking of legitimate
traffic, but the advantage here is that the threat log displays the actual action that would be taken for each
signature when in blocking mode.
Configure the necessary firewall rules for hosts and segments you want to protect.
During the analysis phase, it is important to define and match the firewall security policy rules as close as possible
to what the final security policy will look like. This will help you map vulnerability protection events to specific
segments, hosts and traffic flows in your network and facilitate the analysis phase.
Apply the alert-only protection profile to each rule.
Initially, you will have the alert-only profile applied to each rule. Over time, it may be required to create
additional profiles that are fine-tuned for specific network segments or hosts.
Monitor the threat logs for a representative period of time.
The goal here is to acquire a representative baseline set of threat log events that can be used as the starting point
for further fine-tuning of the vulnerability protection profile(s). It is important to define the monitor period in line
with regular business and infrastructure management processes that may only occur at specific times, e.g. once a
month.
Investigate any potential false positives.
This step is crucial in defining the correct vulnerability protection profile to be deployed in blocking mode. Special
attention should be given to those events that are more generic in nature and have a blocking action as their
default action.
Depending on the severity and type of threat detected, the source and destination as well as the recurrence of an
event, this may or may not be an easy task at hand. Especially for those events that are generic in nature and

where custom applications are involved, this may require some detailed analysis. The possibility to take a packet
capture of these events can be of great help here.
A classic example is a custom web application that relies on a back-end database system. If the web application is
not well coded, certain injection attack signatures may in fact trigger on what is typical traffic for the application.
The same applies to generic cross-site scripting signatures.
Another example is the probing that some network infrastructure monitoring tools perform against components
in the network. While these can also trigger certain signatures, the severity for this type of event is typically low or
informational. Nevertheless, it is important to verify that there is an exception defined in case a block action
should be required.
Use the gathered analysis information to build and fine-tune a block-enabled protection profile.
Once the analysis results are consistent, they can be used to create vulnerability protection profiles that provide
adequate protection tailored to the requirements for the different segments or hosts in the network. In most cases,
fine-tuning will consist of adding exceptions to the general vulnerability protection rules, either in order to avoid a
false positive or to modify the default action for specific signatures.

Appendix D: Slow HTTP Test Output
A DoS Protection profile enabled with Resources Protection Session Limit set to 300 concurrent sessions.
Slowhttptest tool used to open 1000 connections at a rate of 200 new connections per second.
root@attacker:~/slowhttptest/bin# ./slowhttptest -c 1000 -B -g -o my_server_stats -i 110 -r 200 -
s 8192 -t FAKEVERB -u http://192.168.2.20 -x 10 -p 3
Thu Oct 20 17:50:15 2011:
Using:
slow section: BODY
number of connections: 1000
URL: http://192.168.2.20/
verb: FAKEVERB
Content-Length header value: 8192
follow up data max size: 22
interval between follow up data: 110 seconds
connections per seconds: 200
probe connection timeout: 3 seconds
test duration: 240 seconds
Thu Oct 20 17:50:15 2011:slow HTTP test status on 0th second:
inititalizing: 0
pending: 1
connected: 0
error: 0
closed: 0
service available: YES
inititalizing: 0
pending: 677
connected: 226
error: 0
closed: 0
service available: NO
inititalizing: 0
pending: 662
connected: 338
error: 0
closed: 0
inititalizing: 0
pending: 629

connected: 334
error: 0
closed: 37
inititalizing: 0
pending: 629
connected: 221
error: 0
closed: 150
inititalizing: 0
pending: 519
connected: 294
error: 0
closed: 187
inititalizing: 0
pending: 473
connected: 228
error: 0
closed: 299
inititalizing: 0
pending: 473
connected: 190
error: 0
closed: 337
inititalizing: 0
pending: 473
connected: 78
error: 0
closed: 449
inititalizing: 0
pending: 473

connected: 40
error: 0
closed: 487
inititalizing: 0
pending: 193
connected: 284
error: 0
closed: 523
inititalizing: 0
pending: 183
connected: 292
error: 0
closed: 525
inititalizing: 0
pending: 183
connected: 147
error: 0
closed: 670
inititalizing: 0
pending: 183
connected: 142
error: 0
closed: 675
inititalizing: 0
pending: 183
connected: 8
error: 0
closed: 809
inititalizing: 0
pending: 183

connected: 0
error: 0
closed: 817
inititalizing: 0
pending: 183
connected: 0
error: 0
closed: 817
inititalizing: 0
pending: 183
connected: 0
error: 0
closed: 817
inititalizing: 0
pending: 183
connected: 0
error: 0
closed: 817
inititalizing: 0
pending: 183
connected: 0
error: 0
closed: 817
inititalizing: 0
pending: 0
connected: 183
error: 0
closed: 817
inititalizing: 0
pending: 0

connected: 183
error: 0
closed: 817
inititalizing: 0
pending: 0
connected: 61
error: 0
closed: 939
inititalizing: 0
pending: 0
connected: 33
error: 0
closed: 967
Thu Oct 20 17:52:12 2011:
Using:
slow section: BODY
number of connections: 1000
URL: http://192.168.2.20/
verb: FAKEVERB
Content-Length header value: 8192
follow up data max size: 22
interval between follow up data: 110 seconds
connections per seconds: 200
probe connection timeout: 3 seconds
test duration: 240 seconds
Thu Oct 20 17:52:12 2011:Test ended on 116th second
status: No open connections left
root@attacker:~/slowhttptest/bin#

Appendix E: Evasions
Evasions are a way to bypass a firewalls inspection functionalities by applying techniques such as fragmentation or
overlapping TCP segments. In addition to L4 evasion techniques, L7 evasions also exist and are even more popular
due to their simplicity. SSL encryption for example is a very simple yet effective technique to bypass inspection
mechanisms where no SSL decryption is performed.
The following topic from the product documentation provides best practices for securing your network from layer-
4 and layer-7 evasions.
https://www.paloaltonetworks.com/documentation/70/pan-os/pan-os/threat-prevention/best-practices-for-
securing-your-network-from-layer-4-and-layer-7-evasions.html#16594

Revision History
Date Version Revision Comment
August 11, 2015 3.0 A Adapted content to firmware 7.0
Added attack kill-chain and zero-trust principles
and additional information for each threat
prevention functionality.
March 4, 2014 2.0 A Adapted content to firmware 6.0
July 8, 2013 1.2 A Adapted content to firmware 5.0
July 24, 2012 1.1 B URL Filtering use case p14: inserted a note that
explains and provides alternative solution for the
warning messages during commit on the security
policy rule for the first requirement of this use
case. Modified the rule so destination zone is
now untrustL3 instead of any.
June 22th, 2012 1.1 A First release of this document.

Threat Prevention Deployment TechNote Version 3.0 RevA

Uploaded by

Copyright:

Available Formats

You might also like

Threat Prevention Deployment TechNote Version 3.0 RevA

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Threat Prevention Deployment TechNote Version 3.0 RevA

Uploaded by

Copyright:

Available Formats

Advanced Threat Prevention Deployment

Version 3.0 - Revision A 2015, Palo Alto Networks, Inc. www.paloaltonetworks.com

2015, Palo Alto Networks, Inc. [2]

2015, Palo Alto Networks, Inc. [3]

2015, Palo Alto Networks, Inc. [4]

Zero Trust Network Security

2015, Palo Alto Networks, Inc. [5]

2015, Palo Alto Networks, Inc. [6]

Block High-Risk Prevent data

2015, Palo Alto Networks, Inc. [7]

http-proxy ms-ds-smb linkedin-base snmpv1 snmp-trap ping active-directory

ssl facebook-base http-video outlook-web google-video- telnet dailymotion

web-browsing citrix adobe-update unknown-tcp radius livelink genesys

dns mssql-db ms-sms youtube-base ms-update yammer sharepoint-

twitter-base rtmpt symantec-av- snmp-base rss photobucket webdav

ldap facebook-social- google-maps limelight google-translate- ms-netlogon yahoo-mail

netbios-ns snmpv2 msrpc google- google-translate- google-picasa tumblr-base

ftp kerberos ntp hotmail netlog ike ssh

flash netbios-dg ms-exchange blackberry flickr gmail-base xing

google-analytics sharepoint-base ipsec-esp unknown-udp netbios-ss soap dostupest

2015, Palo Alto Networks, Inc. [8]

Block High-Risk Prevent data

2015, Palo Alto Networks, Inc. [9]

2015, Palo Alto Networks, Inc. [10]

DMZ Inbound Security Policy

DMZ Outbound Security Policy

2015, Palo Alto Networks, Inc. [11]

2015, Palo Alto Networks, Inc. [12]

2015, Palo Alto Networks, Inc. [13]

2015, Palo Alto Networks, Inc. [14]

Internal Users Security Policy

2015, Palo Alto Networks, Inc. [15]

2015, Palo Alto Networks, Inc. [16]

2015, Palo Alto Networks, Inc. [17]

2015, Palo Alto Networks, Inc. [18]

Restricted URL Categories Security Policy

Security Policy with URL Filtering profile enabled

2015, Palo Alto Networks, Inc. [19]

Security Policy with Block All rule configured

URL Filtering Log

2015, Palo Alto Networks, Inc. [20]

2015, Palo Alto Networks, Inc. [21]

Custom Vulnerability Protection Profiles

2015, Palo Alto Networks, Inc. [22]

2015, Palo Alto Networks, Inc. [23]

Internal Users Security Policy with Vulnerability Protection profile enabled

DMZ Security Policy with Vulnerability Protection profile enabled

2015, Palo Alto Networks, Inc. [24]

2015, Palo Alto Networks, Inc. [25]

Custom Anti-Spyware Profiles

2015, Palo Alto Networks, Inc. [26]

More information on Anti-Spyware can be found here:

2015, Palo Alto Networks, Inc. [27]

Internal Users Security Policy with Anti-Spyware profile enabled

DMZ Security Policy with Anti-Spyware profile enabled

2015, Palo Alto Networks, Inc. [28]

2015, Palo Alto Networks, Inc. [29]

Internal Users Security Policy with Antivirus profile enabled

DMZ Security Policy with Antivirus profile enabled