Best Practises - Threat Prevention Deployment Best Practices

Next Generation Firewall Threat Prevention Deployment For 4.1 firmware Version 1.0b Proprietary and Confidential

2011 Palo Alto Networks Proprietary and confidential Page 2

Summary

The Palo Alto Networks Next Generation Firewall offers Application Identification, URL Filtering, Vulnerability Protection, Antivirus, Anti-Spyware, Anti-Malware and DoS Protection technologies capable of detecting and preventing threats over the network. This document provides recommendations and best practices with regards to the deployment of policies and profiles on the Palo Alto Networks Next Generation Firewall.


Contents Summary .................................................................................................................................................. 2 Palo Alto Networks Threat Prevention .......................................................................................................... 5 Before you get started ................................................................................................................................ 6

Default Action for Threat Prevention Signatures ......................................................................................... 6 Application Identification ............................................................................................................................ 7

Recommendations.................................................................................................................................. 8 Use Case ............................................................................................................................................... 9 Observations ....................................................................................................................................... 10

User Identification ................................................................................................................................... 11 Recommendations................................................................................................................................ 11 Use Case ............................................................................................................................................. 12 Observations ....................................................................................................................................... 13

URL Filtering ............................................................................................................................................ 14 Recommendations................................................................................................................................ 15 Use Case ............................................................................................................................................. 16 Observations ....................................................................................................................................... 19

Antivirus ................................................................................................................................................. 20 Recommendations................................................................................................................................ 21 Use Case ............................................................................................................................................. 21 Observations ....................................................................................................................................... 22

Anti-Spyware ........................................................................................................................................... 23 Recommendations................................................................................................................................ 23 Use Case ............................................................................................................................................. 24 Observations ....................................................................................................................................... 25

Vulnerability Protection ............................................................................................................................ 26 Recommendations................................................................................................................................ 27 Use Case ............................................................................................................................................. 28 Observations ....................................................................................................................................... 29

File Blocking ............................................................................................................................................ 30 Recommendations................................................................................................................................ 30 Use Case ............................................................................................................................................. 30 Observations ....................................................................................................................................... 31

WildFire Advanced Malware Detection ....................................................................................................... 32 Recommendations................................................................................................................................ 32 Use Case ............................................................................................................................................. 32 Observations ....................................................................................................................................... 33

DoS Protection ........................................................................................................................................ 34 Recommendations................................................................................................................................ 34 Use Case ............................................................................................................................................. 36 Observations ....................................................................................................................................... 38

Zone Protection ....................................................................................................................................... 39 Recommendations................................................................................................................................ 39 Use Case ............................................................................................................................................. 40 Observations ....................................................................................................................................... 41


Appendix A: Performance ......................................................................................................................... 43 Appendix B: Guidelines for the analysis phase.............................................................................................. 44 Appendix C: Slow HTTP test output ............................................................................................................ 46


Palo Alto Networks Threat Prevention

Threat prevention capabilities of the Palo Alto Networks Next Generation Firewall currently include the following:

Application Identification

User Identification

URL Filtering

Antivirus

Anti-Spyware

Vulnerability Protection

File Blocking

Wildfire Advanced Malware Protection

DOS Protection

Zone Protection 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 defense-in-depth mechanism and at the same time improve visibility and control over the network. This document will cover best practices for 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.


Before you get started

Before you get started, make sure you read the following below.

Default Action for Threat Prevention Signatures

Every threat signature present in the Anti-Spyware and Vulnerability Protection modules 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 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.

Allow

Alert

Block-IP

Drop

Drop-all-packets

Reset-both

Reset-client

Reset-server For the Antivirus module 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

Block


Application Identification

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-base

telnet dailymotion

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-update

snmp-base rss photobucket webdav

ldap facebook-social-plugin

google-maps limelight google-translate-base

ms-netlogon yahoo-mail

netbios-ns snmpv2 msrpc google-safebrowsing

google-translate-manual

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

Some applications will also contain a number of child applications. Facebook is a good example of this. The application Facebook has child applications such as facebook-base, facebook-chat, facebook-mail, facebook-posting etc. In order to enforce to correct security policy, it may be required to only allow certain child applications instead of the complete application. A full overview of all applications is available via the Applications view under the Objects tab or via the Applipedia web page on our web site: http://apps.paloaltonetworks.com/applipedia/ More information on App-ID can be found here: http://www.paloaltonetworks.com/literature/techbriefs/App_ID_tech.pdf


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 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 configure the Palo Alto Networks Next Generation Firewall first as a traditional port-based firewall or to deploy it in monitoring mode in order to obtain a list of all applications running across. This list should then be examined in order to maintain the required applications and have any non-desired applications removed from the final policy. 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 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 that 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. 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

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 many web-based applications on parent applications ssl and web-browsing. Within one particular application it is also possible that child applications depend on a parent application. For example, the child application facebook-posting depends on the parent application facebook-base, which in turn depends on web-browsing. 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 Next-Generation 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.


User Identification

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 Citrix Microsoft Terminal Services In addition it is possible to feed 3rd party authentication information through a User-ID API. This allows integration with other network components that have already authenticated a user such as e.g. wireless access solutions. When using Active Directory, user identification can be performed transparent to the end-user, by deploying one or more User-ID agents that will monitor user logon events and perform user-to-ip mapping. This information is then passed on to the firewall(s) who will match user IDs to the right policy rules. More information on User-ID can be found here: http://www.paloaltonetworks.com/literature/techbriefs/User_ID_tech.pdf

Recommendations

When creating policies based on users and groups, it is advised to 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 user-to-ip-address mapping, it is advised to 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 port of the AD domain. Finally, as of firmware 4.1 there is also the option to monitor Exchange logon events for any hosts that do not belong to 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

Resources Production Management

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

Authentication If user authentication is performed against Microsoft Active Directory using the User-ID agent, then authentication will be done transparent to the user if the user has previously logged on to the domain, i.e. the user will not notice the authentication process. If user authentication is performed against an LDAP directory or Novell eDirectory, a Captive Portal page will 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 module can block access to specific web sites and web site categories, or generate an alert when web sites are accessed. You can also define a block list of web sites that are always blocked (or generate alerts) and an allow list of web sites 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-and-pornography

Hacking

Online-gambling

Questionable

Spyware-and-adware

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: http://www.paloaltonetworks.com/literature/datasheets/URL_Filtering_ds.pdf


Recommendations

The URL Filtering module can potentially generate a large amount of log entries. In order to reduce the log volume, you can configure a URL Filtering profile to only log container pages. This will only create a log entry for those URIs where the requested page file name 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 You can add additional container page mime-types under Device -> Setup -> Content-ID -> Content-ID features -> Container Pages. Note that when container page logging is enabled, there may not always be a correlated URL log entry for threats detected by the Antivirus or Vulnerability Protection modules.


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.

Bot-nets

Confirmed-spam-sources

Hacking

Keyloggers-and-monitoring

Malware-sites

Open-http-proxies

Pay-to-surf

Peer-to-peer

Phishing-and-other-frauds

Proxy-avoidance-and-anonymizers

Questionable

Spam-urls

Spyware-and-adware

2. Access to any other external site should be monitored and alerted on for authenticated users, but not blocked.

3. Access to any other external site should be blocked for non-authenticated users.

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. Since these categories should not be allowed to anyone, using a firewall block rule is preferred over using a URL Filtering profile. By placing this rule at the top of your rule base* you can assure that no person or system behind the firewall can access any of these categories.

Restricted URL Categories Security Policy

*Note: make sure you place this rule below any inbound access rules for your own web servers, to avoid issues should your web site accidentally be classified under one of the blocked categories. 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 an additional safety built-in, then you can enable blocking for those categories in the profile as well.

Security Policy with URL Filtering profile enabled

The third requirement is accomplished by creating 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 that a Block All rule can potentially block connections that are required for proper firewall management and operation of the firewall if the firewall management IP address is accessed through the firewall. Make sure you include the necessary rules to allow firewall management traffic should this be the case. The fourth requirement is accomplished by the External Web Access rule that was placed at the top of the rule base under the Application ID section of this use case.


Observations

Logs Drill-down analysis based on URL categories can be performed via the Application Command Center (ACC). 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 the traffic log(s) associated with that URL log entry.

URL Filtering Log

URL Filtering log entry details

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.


Antivirus

The Antivirus module detects and prevents viruses 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 module. 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. Currently 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 current default action for each protocol is listed below.

HTTP BLOCK

FTP BLOCK

SMTP ALERT

IMAP ALERT

POP3 ALERT

SMB BLOCK 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 Anti-Virus can be found here: http://www.paloaltonetworks.com/literature/datasheets/Threat_Prevention_ds.pdf


Recommendations

The default Antivirus profile can be used in most situations where dedicated SMTP, POP3 and/or IMAP-scanning solutions are also present. In case no dedicated Antivirus gateway solution is present for SMTP it is possible to define a custom Antivirus profile and apply the BLOCK 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 those connections that are affected by creating a specific firewall rule for those connections.

Use Case

In our use case, we will enable Anti-Virus for all traffic generated by internal users. The default Anti-Virus profile will be applied to each rule.

Internal Users Security Policy with Anti-Virus profile enabled

Additionally we will also enable Anti-Virus for outbound update traffic from the DMZ.

DMZ Security Policy with Anti-Virus profile enabled


Observations

Logs An overview of Anti-Virus activity can be consulted via the App Scope Threat Monitor, under the Monitor tab. Drill- down analysis can be performed via the Application Command Center (ACC).

Threat Monitor - Viruses

Details for each Anti-Virus alert can be consulted via the Threat log view, under the Monitor tab. The detailed view for a particular threat will also reference the traffic log(s) associated with the threat log entry.

Threat Log

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


Anti-Spyware

The Anti-Spyware module detects and prevents phone-home and download network activity for known and unknown spyware. Unlike the Antivirus module, the Anti-Spyware module 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 module:

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.

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.

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. More information on Anti-Spyware can be found here: http://www.paloaltonetworks.com/literature/datasheets/Threat_Prevention_ds.pdf

Recommendations

The predefined profiles will cover the majority of use cases. In environments where blocking traffic is not allowed, a custom profile can be defined to only alert on spyware events.


Use Case

In our use case, we will enable Anti-Spyware for all traffic generated by internal users. 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 An overview of all Anti-Spyware activity can be consulted via the App Scope Threat Monitor, under the Monitor tab. Drill-down analysis can be performed via the Application Command Center (ACC).

Threat Monitor - Spyware

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 the traffic log(s) associated with the threat log entry.


Vulnerability Protection

The Vulnerability Protection module 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 module:

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 IPS 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: http://www.paloaltonetworks.com/literature/datasheets/Threat_Prevention_ds.pdf


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 this 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 the proper functioning 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 B.


Use Case

In our use case, we will enable Vulnerability Protection for all traffic generated by internal users as well as in- and outbound traffic for the DMZ. 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 An overview of all Vulnerability Protection activity can be consulted via the App Scope Threat Monitor, under the Monitor tab. Drill-down analysis can be performed via the Application Command Center (ACC).

Threat Monitor - Vulnerabilities

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 the traffic log(s) associated with the threat log entry.

Threat Log


File Blocking

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.

Recommendations

File blocking can be particularly useful in preventing users from downloading and installing additional software on company assets and can also prevent drive-by-downloads. No predefined file blocking profiles exist, but they are easy to configure.

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 notification in the browser.


WildFire Advanced Malware Detection

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 lifecycle from preventing infections, identifying unknown or targeted malware as well as pinpointing and disrupting any active infections. Palo Alto Networks WildFire engine exposes targeted and unknown malware through direct observation in a virtual environment. When the firewall encounters an unknown .EXE or .DLL that has been delivered by any application, even those that are encrypted with SSL, the file can be submitted to the WildFire virtualized sandbox, where Palo Alto Networks can directly observe more than 70 malicious behaviors that can reveal the presence of malware. Submissions can be made manually or automatically based on policy. When a sample is identified as malware, the sample is passed on to WildFire's signature generator, which automatically generates a signature for the sample and tests it for accuracy. The new signature is then distributed in the next content update. Palo Alto Networks also develops signatures for the all-important command and control traffic, enabling staff to immediately disrupt the communications of any malware inside the network. More information on WildFire can be found here: http://www.paloaltonetworks.com/literature/whitepapers/WildFire_WP.pdf

Recommendations

Today, WildFire is capable of analyzing exe, scr and dll files with a maximum file size of 10MB. To forward these file types to the WildFire analysis engine, a file blocking profile needs to be created with an action of forward or continue-and-forward.

Use Case

In our use case, we will enable forwarding of files to WildFire for the IT user group. The file blocking profile looks as follows:

This profile is then enabled for the IT user group rule.

Internal Users Security Policy with File Blocking profile enabled


Observations

Logs File transfers in sessions matching a rule with file blocking profile 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 performed and the continue-and-forward action is specified in the file blocking profile, the user will see a block notification in the browser with the option to continue the file download.


DoS Protection

The DoS Protection module detects and prevents network-borne Denial-of-Service attacks. Two DoS protection mechanisms are available:

Flood Protection can detect 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 Protection can detect 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.

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.

Aggregate applies 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.

Classified applies 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 show a DoS rule configuration uses an aggregate profile in combination with geo-IP location data.


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 C: 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 Protection can be configured to prevent flooding attacks in the same way as the Flood Protection feature in DoS Protection profiles.

Reconnaissance Protection can detect and block port scans and host sweeps.

Packet Based Attack Protection provides protection against specific IP level attacks.

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.


Use Case

In our use case, we will enable a Zone Protection profile for the UntrustL3 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 tracks activity based on a source/destination IP/port basis. It will maintain separate counters based on source IP/destination IP/destination port. This is different from Flood Protection under DoS Protection, where activity is tracked depending on the DoS Protection rules and the aggregate vs classified profile types. 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.


Appendix A: Performance

Threat Prevention performance will not be impacted by the number of Threat Prevention modules or the number of signatures that is enabled thanks to the single pass parallel processing architecture unique to the Palo Alto Networks firewall. Any session content is inspected in parallel by the Antivirus, Anti-Spyware and Vulnerability Protection modules. 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: Guidelines for the 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 C: Slow HTTP test output

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#

Documents

Best Practises - Threat Prevention Deployment Best Practices