Threat Prevention

Threat Prevention
Palo Alto Networks
PAN-OS® Administrator’s Guide

Version 6.1
Copyright © 2007-2015 Palo Alto Networks

Contact Information
Corporate Headquarters:
Palo Alto Networks
4401 Great America Parkway
Santa Clara, CA 95054
www.paloaltonetworks.com/company/contact-us
About this Guide
This guide takes you through the configuration and maintenance of your Palo Alto Networks next-generation firewall.
For additional information, refer to the following resources:
 For information on the additional capabilities and for instructions on configuring the features on the firewall, refer
to https://www.paloaltonetworks.com/documentation.
 For access to the knowledge base, discussion forums, and videos, refer to https://live.paloaltonetworks.com.
 For contacting support, for information on the support programs, or to manage your account or devices, refer to
https://support.paloaltonetworks.com.
 For the latest release notes, go to the software downloads page at

https://support.paloaltonetworks.com/Updates/SoftwareUpdates.
To provide feedback on the documentation, please write to us at: [email protected].
Palo Alto Networks, Inc.

www.paloaltonetworks.com
© 2014–2015 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be
found at http://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their
respective companies.
Revision Date: December 23, 2015
2 • PAN-OS 6.1 Administrator’s Guide Palo Alto Networks

Threat Prevention
The Palo Alto Networks next-generation firewall protects and defends your network from commodity threats
and advanced persistent threats (APTs). The firewall’s multi-pronged detection mechanisms include a
signature-based (IPS/Command and Control/Antivirus) approach, heuristics-based (bot detection) approach,
sandbox-based (WildFire) approach, and Layer 7 protocol analysis-based (App-ID) approach.
Commodity threats are exploits that are less sophisticated and more easily detected and prevented using a
combination of the antivirus, anti-spyware, vulnerability protection and the URL filtering/Application
identification capabilities on the firewall.
Advanced threats are perpetuated by organized cyber criminals or malicious groups that use sophisticated attack
vectors to target your network, most commonly for intellectual property theft and financial data theft. These
threats are more evasive and require intelligent monitoring mechanisms for detailed host and network forensics
on malware. The Palo Alto Networks next-generation firewall in conjunction with WildFire and Panorama
provides a comprehensive solution that intercepts and break the attack chain and provides visibility to prevent
security infringement on your network—including mobile and virtualized—infrastructure.
 Set Up Security Profiles and Policies
 Prevent Brute Force Attacks
 Best Practices for Securing Your Network from Layer 4 and Layer 7 Evasions
 Enable Passive DNS Collection for Improved Threat Intelligence
 Use DNS Queries to Identify Infected Hosts on the Network
 Content Delivery Network Infrastructure for Dynamic Updates
 Threat Prevention Resources
Palo Alto Networks PAN-OS 6.1 Administrator’s Guide • 307

Set Up Security Profiles and Policies Threat Prevention
Set Up Security Profiles and Policies

The following sections provide basic threat prevention configuration examples:
 Set Up Antivirus, Anti-spyware, and Vulnerability Protection
 Set Up Data Filtering
 Set Up File Blocking
For information on controlling web access as part of your threat prevention strategy, see URL Filtering.

Threat Prevention Set Up Security Profiles and Policies
Set Up Antivirus, Anti-spyware, and Vulnerability Protection
The following describes the steps needed to set up the default Antivirus, Anti-spyware, and Vulnerability
Protection Security Profiles.
All Anti-spyware and Vulnerability Protection signatures have a default action defined by Palo Alto
Networks. You can view the default action by navigating to Objects > Security Profiles >
Anti-Spyware or Objects > Security Profiles >Vulnerability Protection and then
selecting a profile. Click the Exceptions tab and then click Show all signatures and you will
see a list of the signatures with the default action in the Action column. To change the default
action, you must create a new profile and then create rules with a non-default action, and/or add
individual signature exceptions to Exceptions in the profile.
Set up Antivirus/Anti-spyware/Vulnerability Protection
Step 1 Verify that you have a Threat Prevention • The Threat Prevention license bundles the Antivirus,
license. Anti-spyware, and the Vulnerability Protection features in one
license.
• Select Device > Licenses to verify that the Threat Prevention
license is installed and check the expiration date.
Step 2 Download the latest antivirus threat 1. Select Device > Dynamic Updates and click Check Now at the
signatures. bottom of the page to retrieve the latest signatures.
In the Actions column, click Download to install the latest Antivirus
and Applications and Threats signatures.
Step 3 Schedule signature updates. 1. From Device > Dynamic Updates, click the text to the right of
Schedule to automatically retrieve signature updates for
Antivirus and Applications and Threats.
2. Specify the frequency and timing for the updates and whether
the update will be downloaded and installed or only
downloaded. If you select Download Only, you would need to
manually go in and click the Install link in the Action column to
install the signature. When you click OK, the update is scheduled.
No commit is required.
3. (Optional) You can also enter the number of hours in the
Threshold field to indicate the minimum age of a signature
before a download will occur. For example, if you entered 10, the
signature must be at least 10 hours old before it will be
downloaded, regardless of the schedule.
4. In an HA configuration, you can also click the Sync To Peer
option to synchronize the content update with the HA peer
after download/install. This will not push the schedule settings
to the peer device, you need to configure the schedule on each
device.

Set up Antivirus/Anti-spyware/Vulnerability Protection (Continued)
Best Practices for Antivirus Schedules

The general recommendation for antivirus signature update schedules is to perform a download-and-install on a daily
basis for antivirus and weekly for applications and vulnerabilities.
Recommendations for HA Configurations:

• Active/Passive HA—If the MGT port is used for antivirus signature downloads, you should configure a schedule on
both devices and both devices will download/install independently. If you are using a data port for downloads, the
passive device will not perform downloads while it is in the passive state. In this case you would set a schedule on both
devices and then select the Sync To Peer option. This will ensure that whichever device is active, the updates will occur
and will then push to the passive device.
• Active/Active HA—If the MGT port is used for antivirus signature downloads on both devices, then schedule the
download/install on both devices, but do not select the Sync To Peer option. If you are using a data port, schedule the
signature downloads on both devices and select Sync To Peer. This will ensure that if one device in the active/active
configuration goes into the active-secondary state, the active device will download/install the signature and will then
push it to the active-secondary device.
Step 4 Attach the security profiles to a security 1. Select Policies > Security, select the desired policy to modify it
policy. and then click the Actions tab.
2. In Profile Settings, click the drop-down next to each security
profile you would like to enable. In this example we choose
default for Antivirus, Vulnerability Protection, and
Anti-spyware.
If no security profiles have been previously defined,
select Profiles from the Profile Type drop-down. You
will then see the list of options to select the security
profiles.
Step 5 Save the configuration. Click Commit.

Set Up Data Filtering
The following describes the steps needed to configure a data filtering profile that will detect Social Security
Numbers and a custom pattern identified in .doc and .docx documents.
Data Filtering Configuration Example
Step 1 Create a Data Filtering security profile. 1. Select Objects > Security Profiles > Data Filtering and click
Add.
2. Enter a Name and a Description for the profile. In this example
the name is DF_Profile1 with the description Detect Social Security
Numbers.
3. (Optional) If you want to collect data that is blocked by the filter,
select the Data Capture check box.
You must set a password as described in Step 2 if you are
using the data capture feature.
Step 2 (Optional) Secure access to the data 1. Select Device > Setup > Content-ID.
filtering logs to prevent other 2. Click Manage Data Protection in the Content-ID Features
administrators from viewing sensitive section.
data.
3. Set the password that will be required to view the data filtering
When you enable this option, you will be logs.
prompted for the password when you
view logs in Monitor > Logs > Data
Filtering.

Data Filtering Configuration Example (Continued)
Step 3 Define the data pattern that will be used 1. From the Data Filtering Profile page click Add and select New
in the Data Filtering Profile. from the Data Pattern drop-down. You can also configure data
patterns from Objects > Custom Signatures > Data Patterns.
In this example, we will use the keyword
confidential and will set the option to 2. For this example, name the Data Pattern signature Detect SS
search for SSN numbers with dashes Numbers and add the description Data Pattern to detect
(Example - 987-654-4320). Social Security numbers.
3. In the Weight section for SSN# enter 3. See Weight and
It is helpful to set the appropriate
Threshold Values for more details.
thresholds and define keywords
within documents to reduce false
positives.
4. (Optional) You can also set Custom Patterns that will be

subject to this profile. In this case, you specify a pattern in the
custom patterns Regex field and set a weight. You can add
multiple match expressions to the same data pattern profile. In
this example, we will create a Custom Pattern named
SSN_Custom with a custom pattern of confidential (the
pattern is case sensitive) and use a weight of 20. The reason we
use the term confidential in this example is because we know
that our social security Word docs contain this term, so we
define that specifically.

Step 4 Specify which applications to filter and set 1. Set Applications to Any. This will detect any supported
the file types. application such as: web-browsing, FTP, or SMTP. If you want
to narrow down the application, you can select it from the list.
For applications such as Microsoft Outlook Web App that uses
SSL, you will need to enable decryption. Also make sure you
understand the naming for each application. For example,
Outlook Web App, which is the Microsoft name for this
application is identified as the application outlook-web in the
PAN-OS list of applications. You can check the logs for a given
application to identify the name defined in PAN-OS.
2. Set File Types to doc and docx to only scan doc and docx files.
Step 5 Specify the direction of traffic to filter and 1. Set the Direction to Both. Files that are uploaded or
the threshold values. downloaded will be scanned.
2. Set the Alert Threshold to 35. In this case, an alert will be
triggered if 5 instances of Social Security Numbers exist and 1
instance of the term confidential exists. The formula is 5 SSN
instances with a weight of 3 = 15 plus 1 instance of the term
confidential with a weight of 20 = 35.
3. Set the Block Threshold to 50. The file will be blocked if the
threshold of 50 instances of a SSN and/or the term confidential
exists in the file. In this case, if the doc contained 1 instance of
the word confidential with a weight of 20 that equals 20 toward
the threshold, and the doc has 15 Social Security Numbers with
a weight of 3 that equals 45. Add 20 and 45 and you have 65,
which will exceed the block threshold of 50.

Step 6 Attach the Data Filtering profile to the 1. Select Policies > Security and select the security policy rule to
security rule. which to apply the profile.
2. Click the security policy rule to modify it and then click the
Actions tab. In the Data Filtering drop-down, select the new
data filtering profile you created and then click OK to save. In
this example, the data filtering rule name is DF_Profile1.
Step 7 Commit the configuration.
Step 8 Test the data filtering configuration. When testing, you must use real Social Security Numbers and each
number must be unique. Also, when defining Custom Patterns as we
If you have problems getting Data
did in this example with the word confidential, the pattern is case
Filtering to work, you can check the Data
sensitive. To keep your test simple, you may want to just test using a
Filtering log or the Traffic log to verify the
data pattern first, then test the SSNs.
application that you are testing with and
1. Access a client PC in the trust zone of the firewall and send an
make sure your test document has the
HTTP request to upload a .doc or .docx file that contains the
appropriate number of unique Social
exact information you defined for filtering.
Security Number instances. For example,
an application such as Microsoft Outlook 2. Create a Microsoft Word document with one instance of the
Web App may seem to be identified as term confidential and five Social Security numbers with dashes.
web-browsing, but if you look at the logs, 3. Upload the file to a website. Use an HTTP site unless you have
the application is outlook-web. Also decryption configured, in which case you can use HTTPS.
increase the number of SSNs, or your 4. Select Monitoring > Logs > Data Filtering logs.
custom pattern to make sure you are
5. Locate the log that corresponds to the file you just uploaded. To
hitting the thresholds.
help filter the logs, use the source of your client PC and the
destination of the web server. The action column in the log will
show reset-both. You can now increase the number of Social
Security Numbers in the document to test the block threshold.

Set Up File Blocking
This example will describe the basic steps needed to set up file blocking and forwarding. In this configuration,
we will configure the options needed to prompt users to continue before downloading .exe files from websites.
When testing this example, be aware that you may have other systems between you and the source that may be
blocking content.
Configure File Blocking
Step 1 Create the file blocking profile. 1. Select Objects > Security Profiles > File Blocking and click
Add.
2. Enter a Name for the file blocking profile, for example
Block_EXE. Optionally enter a Description, such as Block users
from downloading exe files from websites.
Step 2 Configure the file blocking options. 1. Click Add to define the profile settings.
2. Enter a Name, such as BlockEXE.
3. Set the Applications for filtering, for example web-browsing.
4. Set File Types to exe.
5. Set the Direction to download.
6. Set the Action to continue. By choosing the continue option,
users will be prompted with a response page prompting them to
click continue before the file will be downloaded.
7. Click OK to save the profile.
Step 3 Apply the file blocking profile to a 1. Select Policies > Security and either select an existing policy or
security policy. create a new policy as described in Set Up Basic Security
Policies.
2. Click the Actions tab within the policy rule.
3. In the Profile Settings section, click the drop-down and select
the file blocking profile you configured. In this case, the profile
name is Block_EXE.
4. Commit the configuration.
If no security profiles have been previously defined, select the
Profile Type drop-down and select Profiles. You will then see the list
of options to select the security profiles.

Configure File Blocking (Continued)
Step 4 To test your file blocking configuration, access a client PC in the trust zone of the firewall and attempt to
download a .exe file from a website in the untrust zone. A response page should display. Click Continue to
download the file. You can also set other actions, such as alert only, forward (which will forward to WildFire), or
block, which will not provide a continue page to the user. The following shows the default response page for
File Blocking:
Example: Default File Blocking Response Page
Step 5 (Optional) Define custom file blocking response pages (Device > Response Pages). This allows you to provide
more information to users when they see a response page. You can include information such as company policy
information and contact information for a Helpdesk.
When you create a file blocking profile with the action continue or continue-and-forward (used for
WildFire forwarding), you can only choose the application web-browsing. If you choose any other
application, traffic that matches the security policy will not flow through the firewall due to the fact that
the users will not be prompted with a continue page. Also, if the website uses HTTPS, you will need to
have a decryption policy in place.
You may want to check your logs to confirm what application is being used when testing this feature. For example, if you
are using Microsoft Sharepoint to download files, even though you are using a web-browser to access the site, the
application is actually sharepoint-base, or sharepoint-document. You may want to set the application type to Any for
testing.

Threat Prevention Prevent Brute Force Attacks
Prevent Brute Force Attacks

A brute force attack uses a large volume of requests/responses from the same source or destination IP address
to break into a system. The attacker employs a trial-and-error method to guess the response to a challenge or a
request.
The Vulnerability Protection profile on the firewall includes signatures to protect you from brute force attacks.
Each signature has an ID, Threat Name, Severity and is triggered when a pattern is recorded. The pattern
specifies the conditions and interval at which the traffic is identified as a brute-force attack; some signatures are
associated with another child signature that is of a lower severity and specifies the pattern to match against.
When a pattern matches against the signature or child signature, it triggers the default action for the signature.
To enforce protection:
 Attach the vulnerability profile to a security rule. See Set Up Antivirus, Anti-spyware, and Vulnerability
Protection.
 Install content updates that include new signatures to protect against emerging threats. See Manage Content
Updates.
 Brute Force Attack Signatures and Triggers
 Customize the Action and Trigger Conditions for a Brute Force Signature

Prevent Brute Force Attacks Threat Prevention
Brute Force Attack Signatures and Triggers
The following table lists some brute-force attack signatures and the conditions that trigger them:
Signature ID Threat Name Child Signature ID Trigger Conditions
40001 FTP: Login Brute Force 40000 Frequency: 10 times in 60 seconds

Attempt Pattern: The child signature 40000 records the
FTP response message with error code 430 to
indicate that an invalid username or password
was sent after the pass command.
40003 DNS: Spoofing Cache 40002 Frequency: 100 times in 60 seconds
Record Attempt Pattern: The child signature 40002 records
DNS response header with count of 1 for the
Question, Answer, Authority and Additional
resource record fields.
40004 SMB: User Password 31696 Frequency: 14 times in 60 seconds

Brute-force Attempt Pattern: The child signature 31696 records the
response error code 0x50001, and error code
0xc000006d for any smb command.
40005 LDAP: User Login 31706 Frequency: 20 times in 60 seconds

Brute-force Attempt Pattern: The child signature, 31706 is looks for
result code 49 in an LDAP bindResponse(27);
the result code 49 indicates invalid credentials.
40006 HTTP: User 31708 Frequency: 100 times in 60 seconds

Authentication Pattern: The child signature, 31708 looks for
Brute-force Attempt http status code 401 with WWW-Authenticate in
the response header field; the status code 401
indicates authentication failure.
40007 MAIL: User Login 31709 Frequency: 10 times in 60 seconds

Brute-force Attempt Pattern: The child signature, 31709 works on
smtp, pop3 and imap applications. The trigger
condition for each application is:
smtp: response code 535
imap: No/bad logon/login failure
pop3: ERR on pop3 PASS command.
40008 MySQL Authentication 31719 Frequency: 25 times in 60 seconds

Brute-force Attempt Pattern: The child signature, 31719 looks for
error code 1045 on mysql clientauth stage.
40009 Telnet Authentication 31732 Frequency: 10 times in 60 seconds

Brute-force Attempt Pattern: The child signature, 31732 looks for
login incorrect in the response packet.

40010 Microsoft SQL Server 31753 Frequency: 20 times in 60 seconds

User Authentication Pattern: The child signature, 31753 looks for
Brute-force Attempt Login failed for user in the response packet.
40011 Postgres Database User 31754 Frequency: 10 times in 60 seconds

Brute-force Attempt password authentication failed for user in the
response packet.
40012 Oracle Database User 31761 Frequency: 7 times in 60 seconds

Brute-force Attempt password authentication failed for user in the
response packet
40013 Sybase Database User 31763 Frequency: 10 times in 60 seconds

Brute-force Attempt Login failed in the response packet.
40014 DB2 Database User 31764 Frequency: 20 times in 60 seconds

Brute-force Attempt 0x1219 Code point with severity code 8 and
security check code 0xf.
40015 SSH User Authentication 31914 Frequency: 20 times in 60 seconds

Brute-force Attempt Pattern: The child signature, 31914 is alerted
on every connection to the ssh server.
40016 SIP INVITE Method 31993 Frequency: 20 times in 60 seconds

Request Flood Attempt Pattern: The child signature, 31993 looks for
the INVITE method on SIP sessions where a
client is invited to participate in a call.
40017 VPN: PAN BOX SSL 32256 Frequency: 10 times in 60 seconds

VPN Authentication Pattern: The child signature 32256 looks for
Brute-force Attempt x-private-pan-sslvpn: auth-failed in the http
response header.
40018 HTTP: Apache Denial 32452 Frequency: 40 times in 60 seconds

Of Service Attempt Pattern: The child signature looks for 32452
which has content-length but does not include
\r\n\r\n in the request.
40019 HTTP: IIS Denial Of 32513 Frequency: 10 times in 20 seconds

Service Attempt Pattern: The child signature 32513 looks for
%3f on http uri path with .aspx.
40020 Digium Asterisk IAX2 32785 Frequency: 10 times in 30 seconds

Call Number Exhaustion Pattern: The child signature 32785 looks for
Attempt call number field in an Asterisk message.

40021 MS-RDP: MS Remote 33020 Frequency: 8 times in 100 seconds

Desktop Connect Pattern: The child signature 33020 looks for
Attempt CONNECT action in the ms-rdp request.
40022 HTTP: Microsoft 33435 Frequency: 30 times in 60 seconds

ASP.Net Information Pattern: The child signature 33435 looks for
Leak brute force response code 500 and response header
Attempt contain \nX-Powered-By: ASP\.NET
40023 SIP: SIP Register 33592 Frequency: 60 times in 60 seconds

Request Attempt Pattern: The child signature 33592 looks for
REGISTER SIP method which registers the
address listed in the To header field with a SIP
server.
40028 SIP: SIP Bye Message 34520 Frequency: 20 times in 60 seconds

Brute Force Attack Pattern: The child signature 34520 looks for
SIP BYE request that is used to terminate a call.
40030 HTTP: HTTP NTLM 34548 Frequency: 20 times in 60 seconds

Authentication Brute Pattern: The child signature 34548 looks for
Force Attack HTTP status code 407 and failure to
authenticate to an NTLM proxy server.
40031 HTTP: HTTP 34556 Frequency: 100 times in 60 seconds

Forbidden Brute Force Pattern: The child signature 34556 looks for
Attack HTTP 403 response that indicates that the
server is refusing a valid HTTP request.
40032 HTTP: HOIC Tool 34767 Frequency: 100 times in 60 seconds

Brute Force Attack Pattern: The child signature 34767 looks for
HTTP request from the High Orbit Ion
Cannon (HOIC) DDoS tool.
40033 DNS: ANY Queries 34842 Frequency: 60 times in 60 seconds

Brute Force DOS Attack Pattern: The child signature 34842 looks for
DNS ANY record queries.
40034 SMB: Microsoft 35364 Frequency: 60 times in 60 seconds

Windows SMB NTLM Pattern: The child signature 35364 looks for
Authentication Lack of an SMB Negotiate (0x72) request. Multiple
Entropy Vulnerability requests in a short time could indicate an attack
for CVE-2010-0231.

Customize the Action and Trigger Conditions for a Brute Force Signature
The firewall includes two types of predefined brute force signatures—parent signature and child signature. A
child signature is a single occurrence of a traffic pattern that matches the signature. A parent signature is
associated with a child signature and is triggered when multiple events occur within a time interval and match
the traffic pattern defined in the child signature.
Typically, a child signature is of default action allow because a single event is not indicative of an attack. In most
cases, the action for a child signature is set to allow so that legitimate traffic is not blocked and threat logs are
not generated for non-noteworthy events. Therefore, Palo Alto Networks recommends that you only change
the default action after careful consideration.
In most cases, the brute force signature is a noteworthy event because of its recurrent pattern. If you would like
to customize the action for a brute-force signature, you can do one of the following:
 Create a rule to modify the default action for all signatures in the brute force category. You can define the
action to allow, alert, block, reset, or drop the traffic.
 Define an exception for a specific signature. For example, you can search for a CVE and define an exception
for it.
For a parent signature, you can modify both the trigger conditions and the action; for a child signature only
the action can be modified.
To effectively mitigate an attack, the block-ip address action is recommended over the drop or
reset action for most brute force signatures.
Customize the Threshold and Action for a Signature
Step 1 Create a new Vulnerability Protection 1. Select Objects > Security Profiles > Vulnerability Protection.
Profile. 2. Click Add and enter a Name for the Vulnerability Protection
Profile.
Step 2 Create a rule that defines the action for all 1. Select Rules, click Add and enter a Name for the rule.
signatures in a category. 2. Set the Action. In this example, it is set to Block.
3. Set Category to brute-force.
4. (Optional) If blocking, specify whether to block server or client,
the default is any.
5. See Step 3 to customize the action for a specific signature.
6. See Step 4 to customize the trigger threshold for a parent
signature.
7. Click OK to save the rule and the profile.

Step 3 (Optional) Customize the action for a 1. Select Exceptions and click Show all signatures to find the
specific signature. signature you want to modify.
To view all the signatures in the brute-force category, search for
( category contains 'brute-force' ).
2. To edit a specific signature, click the predefined default action in
the Action column.
3. Set the action to allow, alert or block-ip.
4. If you select block-ip, complete these additional tasks:

a. Specify the Time period (in seconds) after which to trigger
the action.
b. In the Track By field, define whether to block the IP address
by IP source or by IP source and destination.
5. Click OK
6. For each modified signature, select the check box in the Enable
column.
7. Click OK.

Step 4 Customize the trigger conditions for a 1. Click to edit the time attribute and the aggregation criteria
parent signature. for the signature.
A parent signature that can be edited is
marked with this icon: .
In this example, the search criteria was
brute force category and
CVE-2008-1447.
2. To modify the trigger threshold specify the Number of Hits per

x seconds.
3. Specify whether to aggregate the number of hits by source,
destination or by source and destination.
4. Click OK.
Step 5 Attach this new profile to a security rule.
Step 6 Save your changes. 1. Click Commit.

Best Practices for Securing Your Network from Layer 4 and Layer 7 Evasions Threat Prevention
Best Practices for Securing Your Network from Layer 4 and

Layer 7 Evasions
To monitor and protect your network from most Layer 4 and Layer 7 attacks, here are a few recommendations.
 Upgrade to the most current PAN-OS software version and content release version to ensure that you
have the latest security updates. See Manage Content Updates and Install Software Updates.
 For servers, create security policy rules to only allow the application(s) that you sanction on each server.
Verify that the standard port for the application matches the listening port on the server. For example, to
ensure that only SMTP traffic is allowed to your email server set the Application to smtp and the Service
to application-default. If your server uses only a subset of the standard ports (for example, if your SMTP
server uses only port 587 while the smtp application has standard ports defined as 25 and 587), you should
create a new custom service that only includes port 587 and use that new service in your security policy
rule instead of using application-default. Additionally, make sure to restrict access to specific source and
destinations zones and sets of IP addresses.
 Attach the following security profiles to your security policies to provide signature-based protection.
– Create a vulnerability protection profile to block all vulnerabilities with severity low and higher.
– Create an anti-spyware profile to block all spyware.
– Create an antivirus profile to block all content that matches an antivirus signature.
 Block all unknown applications/traffic using security policy. Typically, the only applications that are
classified as unknown traffic are internal or custom applications on your network, or potential threats.
Because unknown traffic can be a non-compliant application or protocol that is anomalous or abnormal,
or a known application that is using non-standard ports, unknown traffic should be blocked. See Manage
Custom or Unknown Applications.
 Create a file blocking profile that blocks Portable Executable (PE) file types for Internet-based SMB
(Server Message Block) traffic from traversing the trust to untrust zones, (ms-ds-smb applications).
For additional protection, create an antivirus policy to detect and block any known malicious DLL files.
 Create a zone protection profile that is configured to protect against packet-based attacks:
– Remove TCP timestamps on SYN packets before the firewall forwards the packet—When you remove
the TCP timestamp option in a SYN packet, the TCP stack on both ends of the TCP connection will
not support TCP timestamps. Therefore, by disabling the TCP timestamp for a SYN packet, you can
prevent an attack that uses different timestamps on multiple packets for the same sequence number.
– Drop malformed packets.
– Drop mismatched and overlapping TCP segments—By deliberately constructing connections with
overlapping but different data in them, attackers can attempt to cause misinterpretation of the intent of
the connection. This can be used to deliberately induce false positives or false negatives. An attacker
can use IP spoofing and sequence number prediction to intercept a user's connection and inject his/her
own data into the connection. PAN-OS uses this field to discard such frames with mismatched and
overlapping data. The scenarios where the received segment will be discarded are when the segment
received is contained within another segment, the segment received overlaps with part of another
segment, or the segment completely contains another segment.

Threat Prevention Best Practices for Securing Your Network from Layer 4 and Layer 7 Evasions
 Verify that support for IPv6 is enabled, if you have configured IPv6 addresses on your network hosts.
(Network > Interfaces > Ethernet> IPv6)
This allows access to IPv6 hosts and filters IPv6 packets that are encapsulated in IPv4 packets. Enabling
support for IPv6 prevents IPv6 over IPv4 multicast addresses from being leveraged for network
reconnaissance.
 Enable support for multicast traffic so that the firewall can enforce policy on multicast traffic. (Network >
Virtual Router > Multicast)
 Enable the following CLI command to clear the URG bit flag in the TCP header and disallow out-of-band
processing of packets.
The urgent pointer in the TCP header is used to promote a packet for immediate processing by removing it
from the processing queue and expediting it through the TCP/IP stack on the host. This process is called
out-of-band processing. Because the implementation of the urgent pointer varies by host, to eliminate
ambiguity, use the following CLI command to disallow out-of-band processing; the out-of-band byte in the
payload becomes part of the payload and the packet is not processed urgently. Making this change allows
you to remove ambiguity in how the packet is processed on the firewall and the host, and the firewall sees
the exact same stream in the protocol stack as the host for whom the packet is destined.
set deviceconfig setting tcp urgent-data clear
 If you configure the firewall to clear the URG bit flag and the packet has no other flags set in the TCP
header, use the following CLI command to configure the firewall to drop packets with no flags:
set deviceconfig setting tcp drop-zero-flag yes
 Enable the following CLI command for disabling the bypass-exceed-queue.
The bypass exceed queue is required for out of order packets. This scenario is most common in an
asymmetric environment where the firewall receives packets out of order. For identification of certain
applications (App-ID) the firewall performs heuristic analysis. If the packets are received out of order, the
data must be copied to a queue in order to complete the analysis for the application.
set deviceconfig setting application bypass-exceed-queue no
 Enable the following CLI commands for disabling the inspection of packets when the out-of-order packet
limit is reached. The Palo Alto Networks firewall can collect up to 32 out-of-order packets per session.
This counter identifies that packets have exceeded the 32-packet limit. When the bypass setting is set to
no, the device drops the out-of-order packets that exceed the 32-packet limit. A commit is required.
set deviceconfig setting tcp bypass-exceed-oo-queue no
set deviceconfig setting ctd tcp-bypass-exceed-queue no
set deviceconfig setting ctd udp-bypass-exceed-queue no
 Enable the following CLI commands for checking the TCP timestamp. The TCP timestamp records when
the segment was sent and allows the firewall to verify that the timestamp is valid for that session. Packets
with invalid timestamps are dropped with this setting is enabled.
set deviceconfig setting tcp check-timestamp-option yes

Enable Passive DNS Collection for Improved Threat Intelligence Threat Prevention
Enable Passive DNS Collection for Improved Threat

Intelligence
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. Data submitted via the Passive DNS Monitoring
feature consists solely of mappings of domain names to IP addresses. Palo Alto Networks retains no record of
the source of this data and does not have the ability to associate it with the submitter at a future date.
The Palo Alto Networks threat research team uses this information to gain insight into malware propagation
and evasion techniques that abuse the DNS system. Information gathered through this data collection is used
to improve accuracy and malware detection abilities within PAN-DB URL filtering, DNS-based
command-and-control signatures, and WildFire.
DNS responses are only forwarded to the Palo Alto Networks and will only occur when the following
requirements are met:
 DNS response bit is set
 DNS truncated bit is not set
 DNS recursive bit is not set
 DNS response code is 0 or 3 (NX)
 DNS question count bigger than 0
 DNS Answer RR count is bigger than 0 or if it is 0, the flags need to be 3 (NX)
 DNS query record type are A, NS, CNAME, AAAA, MX

Passive DNS monitoring is disabled by default, but it is recommended that you enable it to facilitate enhanced
threat intelligence. Use the following procedure to enable Passive DNS:
Enable Passive DNS
1. Select Objects > Security Profiles > Anti-Spyware.
2. Select an existing profile to modify it or configure a new profile.

The Anti-Spyware profile must be attached to a security policy that governs your DNS
server’s external DNS traffic.
3. Select the DNS Signatures tab and click the Enable Passive DNS Monitoring check box.
4. Click OK and then Commit.

Threat Prevention Use DNS Queries to Identify Infected Hosts on the Network
Use DNS Queries to Identify Infected Hosts on the Network

The DNS sinkhole action in Anti-Spyware profiles enables the firewall to forge a response to a DNS query for
a known malicious domain, causing the malicious domain name to resolve to an IP address that you define. This
allows you to identify hosts on your network that have been infected with malware. The following topics
describe the DNS sinkhole action and provide instructions for enabling it and monitoring logs to identify
infected hosts.
 DNS Sinkholing
 Configure DNS Sinkholing
 Identify Infected Hosts

Use DNS Queries to Identify Infected Hosts on the Network Threat Prevention
DNS Sinkholing
DNS sinkholing helps you to identify infected hosts on the protected network using DNS traffic in situations
where the firewall cannot see the infected client's DNS query (that is, the firewall cannot see the originator of
the DNS query). 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 client host queries directed at
malicious domains, so that clients attempting to connect to malicious domains (for command-and-control, for
example) will instead attempt to connect to a sinkhole IP address you define as illustrated in Configure DNS
Sinkholing. Infected hosts can then be easily identified in the traffic logs because any host that attempts to
connect to the sinkhole IP address are most likely infected with malware.
Figure: DNS Sinkholing Example

Configure DNS Sinkholing
To enable DNS Sinkholing, you must enable the action in an Anti-spyware profile and attach the profile to a
security rule. When a client host attempts to access a malicious domain, the firewall forges the destination IP
address in the packet using the IP address you configure as the DNS sinkhole address.
Configure DNS Sinkholing
Step 1 Obtain both an IPv4 and IPv6 address to This configuration example uses the following DNS sinkhole
use as the sinkhole IP addresses. addresses:
The DNS sinkhole address must be in a IPv4 DNS sinkhole address—10.15.0.20
different zone than the client hosts to IPv6 DNS sinkhole address—fd97:3dec:4d27:e37c:5:5:5:5
ensure that when an infected host
attempts to start a session with the
sinkhole IP address, it will be routed
through the firewall. The reason both
IPv4 and IPv6 are needed is because
malicious software may perform DNS
queries using one or both of these
protocols.
This sinkhole addresses must be
reserved for this purpose and do
not need to be assigned to a
physical host. You can optionally
use a honey-pot server as a
physical host to further analyze
the malicious traffic.
Step 2 Configure the sinkhole interface and 1. Select Network > Interfaces and select an interface to configure
zone. as your sinkhole interface.
Traffic from the zone where the client 2. In the Interface Type drop-down, select Layer3.
hosts reside must route to the zone where 3. To add an IPv4 address, select the IPv4 tab and select Static and
the sinkhole IP address is defined, so then click Add. In this example, use the IPv4 address 10.15.0.20
traffic will be logged. as the sinkhole address.
Use a dedicated zone for sinkhole 4. Select the IPv6 tab and click Static and then click Add and enter
traffic, because the infected host an IPv6 address and subnet mask. In this example, use the IPv6
will be sending traffic to this zone. address fd97:3dec:4d27:e37c::/64 as the sinkhole address.
5. Click OK to save.
6. To add a zone for the sinkhole, select Network > Zones and
click Add.
7. Enter zone Name.
8. In the Type drop-down select Layer3.
9. In the Interfaces section, click Add and add the interface you
just configured.
10. Click OK.

Configure DNS Sinkholing (Continued)
Step 3 Enable DNS sinkholing on the 1. Select Objects > Security Profiles > Anti-Spyware.
anti-spyware profile. 2. Modify an existing profile, or select one of the existing defaults
and clone it.
3. Name the profile and then select the DNS Signatures tab.
4. In the Action on DNS queries drop-down, select sinkhole.
5. In the Sinkhole IPv4 field enter the sinkhole IPv4 sinkhole
address you configured in Step 2 (10.15.0.20 in this example).
6. In the Sinkhole IPv6 field enter the sinkhole IPv6 sinkhole
address you configured in Step 2 (fd97:3dec:4d27:e37c:5:5:5:5
in this example).
The default sinkhole address is the loopback address
(127.0.0.1 for IPv4 and ::1 for IPv6).
7. (Optional) In the Packet Capture drop-down, select
single-packet or extended-capture. The single-packet option
will capture the first packet of the session or you can select
extended to capture between 1-50 packets. You can then use the
packet captures for further analysis.
8. Click OK to save the profile.
Step 4 Edit the security policy rule that allows 1. Select Policies > Security.
traffic from client hosts in the trust zone 2. Select an existing rule that allows traffic from the client host
to the untrust zone to include the zone to the untrust zone.
sinkhole zone as a destination and attach
3. On the Destination tab, Add the Sinkhole zone. This allows
the anti-spyware profile.
client host traffic to flow to the sinkhole zone.
To ensure that you are identifying traffic 4. On the Actions tab, select the Log at Session Start check box
from infected hosts, make these changes to enable logging. This will ensure that traffic from client hosts
to the security rule(s) that allow traffic in the Trust zone will be logged when accessing the Untrust or
from client hosts in the trust zone to the Sinkhole zones.
untrust zone. By adding the sinkhole zone
5. In the Profile Setting section, select the Anti-Spyware profile
as a destination on the rule, you enable
in which you enabled DNS sinkholing.
infected clients to send bogus DNS
queries to the DNS sinkhole. 6. Click OK to save the security rule and then Commit.

Step 5 To ensure that you will be able to identify 1. From a client host in the trust zone, open a command prompt
infected hosts, verify that traffic going and run the following command:
from the client host in the Trust zone to C:\>ping <sinkhole address>
the new Sinkhole zone is being logged. The following example output shows the ping request to the
In this example, the infected client host is DNS sinkhole address at 10.15.0.2 and the result, which is
192.168.2.10 and the Sinkhole IPv4 Request timed out because in this example the sinkhole IP
address is 10.15.0.20. address is not assigned to a physical host:
C:\>ping 10.15.0.20
Pinging 10.15.0.20 with 32 bytes of data:
Request timed out.
Request timed out.
Ping statistics for 10.15.0.20:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
2. On the firewall, select Monitor > Logs > Traffic and find the log
entry with the Source 192.168.2.10 and Destination 10.15.0.20.
This will confirm that the traffic to the sinkhole IP address is
traversing the firewall zones.
You can search and/or filter the logs and only show logs
with the destination 10.15.0.20. To do this, click the IP
address (10.15.0.20) in the Destination column, which
will add the filter (addr.dst in 10.15.0.20) to the search
field. Click the Apply Filter icon to the right of the
search field to apply the filter.
Step 6 Identify a malicious domain that you can To find a malicious domain for testing:
use to verify that the DNS sinkhole 1. Select Device > Dynamic Updates and in the Antivirus section
functionality is configured properly. click the Release Notes link for the current antivirus DB that is
installed. You can also find the antivirus release notes on the
You must test this feature using a
support site in Dynamic Updates. In most cases, the signature
malicious domain that is included in the
update is an incremental update, so only new viruses and DNS
firewall’s current antivirus signature
signatures are listed. There are many antivirus signatures and
database. The DNS Signatures used to
identify malicious domains is only part of DNS signatures that will already be installed on the firewall.
the full antivirus signature database, 2. In the second column of the release note, locate a line item with
which contains hundreds of thousands of a domain extension (for example, com, edu, or net). The left
signatures. column will show the domain name. For example, in Antivirus
release 1117-1560, there is an item in the left column named
"tbsbana" and the right column lists "net".
The following shows the content in the release note for this line
item:
conficker:tbsbana1 variants: net
Because this domain shows up in the current database, it will
work for testing.

Step 7 Test the sinkhole action 1. From the client host, open a command prompt.
This is similar to the action that would be 2. Perform an NSLOOKUP to a URL that you identified as a
performed if the client host was infected known malicious domain in Step 6.
and the malicious application was For example, using the URL track.bidtrk.com:
attempting to reach a hacker server using C:\>nslookup track.bidtrk.com
DNS queries. Server: my-local-dns.local
Address: 10.0.0.222
Non-authoritative answer:
Name: track.bidtrk.com.org
Addresses: fd97:3dec:4d27:e37c:5:5:5:5
10.15.0.20
In the output, note that the NSLOOKUP to the malicious
domain has been forged using the sinkhole IP addresses that we
configured (10.15.0.20). Because the domain matched a
malicious DNS signature, the sinkhole action was performed.
3. Select Monitor > Logs > Threat and locate the corresponding
threat log entry to verify that the correct action was taken on the
NSLOOKUP request.
4. Perform a ping to track.bidtrk.com, which will generate
network traffic to the sinkhole address.

Identify Infected Hosts
After you have configured DNS sinkholing and verified that traffic to a malicious domain goes to the sinkhole
address, you should regularly monitor traffic to the sinkhole address, so that you can track down the infected
hosts and eliminate the threat.
DNS Sinkhole Verification and Reporting
Step 1 Use App Scope to identify infected client 1. Select Monitor > App Scope and select Threat Monitor.
hosts. 2. Click the Show spyware button along the top of the display
page.
3. Select a time range.
The following screenshot shows three instances of Suspicious
DNS queries, which were generated when the test client host
performed an NSLOOKUP on a known malicious domain.
Click the graph to see more details about the event.

DNS Sinkhole Verification and Reporting (Continued)
Step 2 Configure a custom report to identify all 1. Select Monitor > Manage Custom Reports.
client hosts that have sent traffic to the 2. Click Add and Name the report.
sinkhole IP address, which is 10.15.0.20 in
3. Define a custom report that captures traffic to the sinkhole
this example.
address as follows:
Forward to an SNMP manager, • Database—Select Traffic Log.
Syslog server and/or Panorama to
enable alerts on these events. • Scheduled—Enable Scheduled and the report will run
every night.
In this example, the infected client host
• Time Frame—30 days
performed an NSLOOKUP to a known
malicious domain that is listed in the Palo • Selected Columns—Select Source address or Source User
Alto Networks DNS Signature database. (if you have User-ID configured), which will identify the
When this occurred, the query was sent to infected client host in the report, and Destination address,
the local DNS server, which then which will be the sinkhole address.
forwarded the request through the • In the section at the bottom of the screen, create a custom
firewall to an external DNS server. The query for traffic to the sinkhole address (10.15.0.20 in this
firewall security policy with the
example). You can either enter the destination address in the
Anti-Spyware profile configured matched Query Builder window (addr.dst in 10.15.0.20) or select the
the query to the DNS Signature database, following in each column and click Add: Connector = and,
which then forged the reply using the Attribute = Destination Address, Operator = in, and Value =
sinkhole address of 10.15.0.20 and 10.15.0.20. Click Add to add the query.
fd97:3dec:4d27:e37c:5:5:5:5. The client
attempts to start a session and the traffic
log records the activity with the source
host and the destination address, which is
now directed to the forged sinkhole
address.
Viewing the traffic log on the firewall
allows you to identify any client host that
is sending traffic to the sinkhole address.
In this example, the logs show that the
source address 192.168.2.10 sent the
malicious DNS query. The host can then
be found and cleaned. Without the DNS
sinkhole option, the administrator would 4. Click Run Now to run the report. The report will show all client
only see the local DNS server as the hosts that have sent traffic to the sinkhole address, which
system that performed the query and indicates that they are most likely infected. You can now track
would not see the client host that is down the hosts and check them for spyware.
infected. If you attempted to run a report
on the threat log using the action
“Sinkhole”, the log would show the local
DNS server, not the infected host.
5. To view scheduled reports that have run, select Monitor >

Reports.

Threat Prevention Content Delivery Network Infrastructure for Dynamic Updates
Content Delivery Network Infrastructure for Dynamic

Updates
Palo Alto Networks maintains a Content Delivery Network (CDN) infrastructure for delivering content updates
to the Palo Alto Networks devices. The devices access the web resources in the CDN to perform various
App-ID and Content-ID functions. For enabling and scheduling the content updates, see Manage Content
Updates.
The following table lists the web resources that the firewall accesses for a feature or application:
Resource URL Static Addresses (If a static server is

required)
Application Database • updates.paloaltonetworks.com:443 staticupdates.paloaltonetworks.com or the IP

address 199.167.52.15
Threat/Antivirus Database • updates.paloaltonetworks.com:443 staticupdates.paloaltonetworks.com or the IP

address 199.167.52.15
• downloads.paloaltonetworks.com:443
As a best practice, set the update server to
updates.paloaltonetworks.com.This
allows the Palo Alto Networks device to
receive content updates from the server
closest to it in the CDN infrastructure.
PAN-DB URL Filtering *.urlcloud.paloaltonetworks.com Static IP addresses are not available. However,
Resolves to the primary URL you can manually resolve a URL to an IP
s0000.urlcloud.paloaltonetworks.com and address and allow access to the regional server
is then redirected to the regional server that IP address.
is closest:
• s0100.urlcloud.paloaltonetworks.com
BrightCloud URL Filtering • database.brightcloud.com:443/80 Contact BrightCloud Customer Support.

• service.brightcloud.com:80

Content Delivery Network Infrastructure for Dynamic Updates Threat Prevention
Resource URL Static Addresses (If a static server is

required)
WildFire • beta.wildfire.paloaltonetworks.com:443/8 • mail.wildfire.paloaltonetworks.com:25 or

0 the IP address 54.241.16.83
• beta-s1.wildfire.paloaltonetworks.com:443 • wildfire.paloaltonetworks.com:443/80 or
/80 54.241.8.199
Beta sites are only accessed by a • The regional URL/IP addresses are as
firewall running a Beta release follows:
version. • ca-s1.wildfire.paloaltonetworks.com:44 or
• mail.wildfire.paloaltonetworks.com:25 54.241.34.71
• wildfire.paloaltonetworks.com:443/80 • va-s1.wildfire.paloaltonetworks.com:443or
174.129.24.252
• eu-s1.wildfire.paloaltonetworks.com:443 or
54.246.95.247
• sg-s1.wildfire.paloaltonetworks.com:443or
54.251.33.241
• jp-s1.wildfire.paloaltonetworks.com:443 or
54.238.53.161
• portal3.wildfire.paloaltonetworks.com:443/8
0 or 54.241.8.199
• ca-s3.wildfire.paloaltonetworks.com:443 or
54.241.34.71
• va-s3.wildfire.paloaltonetworks.com:443 or
23.21.208.35
• eu-s3.wildfire.paloaltonetworks.com:443 or
54.246.95.247
• sg-s3.wildfire.paloaltonetworks.com:443 or
54.251.33.241
• jp-s3.wildfire.paloaltonetworks.com:443 or
54.238.53.161
• wildfire.paloaltonetworks.com.jp:443/80 or
180.37.183.53
• wf1.wildfire.paloaltonetowrks.jp:443 or
180.37.180.37
• wf2.wildfire.paloaltonetworks.jp:443 or
180.37.181.18
• portal3.wildfire.paloaltonetworks.jp:443/80
or 180.37.183.53

Threat Prevention Threat Prevention Resources
Threat Prevention Resources

For more information on Threat Prevention, refer to the following sources:
 Creating Custom Threat Signatures
 Threat Prevention Deployment
 Understanding DoS Protection

To view a list of Threats and Applications that Palo Alto Networks products can identify, use the following links:
 Applipedia—Provides details on the applications that Palo Alto Networks can identify.
 Threat Vault—Lists threats that Palo Alto Networks products can identify. You can search by Vulnerability,
Spyware, or Virus. Click the Details icon next to the ID number for more information about a threat.

Threat Prevention Resources Threat Prevention

Threat Prevention

Uploaded by

Copyright:

Available Formats

Threat Prevention

Uploaded by

Document Information

Original Title

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

Uploaded by

Copyright:

Available Formats

Threat Prevention

Palo Alto Networks

PAN-OS® Administrator’s Guide

Copyright © 2007-2015 Palo Alto Networks

About this Guide

 For the latest release notes, go to the software downloads page at

Palo Alto Networks, Inc.

Revision Date: December 23, 2015

2 • PAN-OS 6.1 Administrator’s Guide Palo Alto Networks

Copyright © 2007-2015 Palo Alto Networks

Palo Alto Networks PAN-OS 6.1 Administrator’s Guide • 307

Copyright © 2007-2015 Palo Alto Networks

Set Up Security Profiles and Policies

308 • PAN-OS 6.1 Administrator’s Guide Palo Alto Networks

Copyright © 2007-2015 Palo Alto Networks

Set Up Antivirus, Anti-spyware, and Vulnerability Protection

Set up Antivirus/Anti-spyware/Vulnerability Protection

Palo Alto Networks PAN-OS 6.1 Administrator’s Guide • 309

Copyright © 2007-2015 Palo Alto Networks

Set up Antivirus/Anti-spyware/Vulnerability Protection (Continued)

Best Practices for Antivirus Schedules

Recommendations for HA Configurations:

Step 5 Save the configuration. Click Commit.

310 • PAN-OS 6.1 Administrator’s Guide Palo Alto Networks

Copyright © 2007-2015 Palo Alto Networks

Set Up Data Filtering

Data Filtering Configuration Example

Palo Alto Networks PAN-OS 6.1 Administrator’s Guide • 311

Copyright © 2007-2015 Palo Alto Networks

Data Filtering Configuration Example (Continued)

4. (Optional) You can also set Custom Patterns that will be

312 • PAN-OS 6.1 Administrator’s Guide Palo Alto Networks

Copyright © 2007-2015 Palo Alto Networks

Data Filtering Configuration Example (Continued)

Palo Alto Networks PAN-OS 6.1 Administrator’s Guide • 313

Copyright © 2007-2015 Palo Alto Networks

Data Filtering Configuration Example (Continued)

Step 7 Commit the configuration.

314 • PAN-OS 6.1 Administrator’s Guide Palo Alto Networks

Copyright © 2007-2015 Palo Alto Networks

Set Up File Blocking

Configure File Blocking

7. Click OK to save the profile.

Palo Alto Networks PAN-OS 6.1 Administrator’s Guide • 315

Copyright © 2007-2015 Palo Alto Networks

Configure File Blocking (Continued)

Example: Default File Blocking Response Page

316 • PAN-OS 6.1 Administrator’s Guide Palo Alto Networks

Copyright © 2007-2015 Palo Alto Networks

Prevent Brute Force Attacks

Palo Alto Networks PAN-OS 6.1 Administrator’s Guide • 317

Copyright © 2007-2015 Palo Alto Networks

Brute Force Attack Signatures and Triggers

Signature ID Threat Name Child Signature ID Trigger Conditions

40001 FTP: Login Brute Force 40000 Frequency: 10 times in 60 seconds

40004 SMB: User Password 31696 Frequency: 14 times in 60 seconds

40005 LDAP: User Login 31706 Frequency: 20 times in 60 seconds

40006 HTTP: User 31708 Frequency: 100 times in 60 seconds

40007 MAIL: User Login 31709 Frequency: 10 times in 60 seconds