This article explains the legacy version of
Profile setup has been organized into the following categories:
Assign a template to a new profile to quickly apply the desired default configuration to it.
A template provides a quick method through which a default set of settings, access controls, and threat detection policies may be assigned to a new profile. The available set of templates consists of:
All previously created profiles.
A profile may be updated at any time. Modifying an existing profile:
Provides the means for updating the manner through which production traffic is screened without having to modify an instance.
WAF always screens traffic using a profile's latest configuration.
Assign a template to a profile via the Template option. Selecting a template overwrites most profile settings (e.g., rule set, policy status, individual rule status, and access controls) to match the values defined in the template.
Core and advanced profile settings are grouped under the Settings tab.
Core profile settings allow you to:
Define the name of the response header included with responses blocked by WAF. This header name, which may be set via the Response Header Name option, only supports alphanumeric characters and dashes.
Prevent false positives by defining the cookies, headers, and query string arguments that will be ignored when analyzing a request.
The characteristics of certain cookies, headers, and query string arguments may resemble malicious traffic. This may result in WAF incorrectly identifying a request as a threat. Avoid this situation by identifying the cookies, headers, and query string arguments that should be ignored when WAF performs threat assessment.
Key information:
An ignore list does not behave like a whitelist, accesslist, or blacklist. Rather, it simply allows the system to ignore specific cookies when assessing whether a request is malicious traffic.
Each line defines a regular expression.
By default, a regular expression defines a case-sensitive match. Use syntax (e.g., [a-zA-Z]) to make it case-insensitive.
To set up an ignore list
Advanced settings, which may be viewed by expanding the More Details section, define query string argument and file size limitations that cannot be exceeded by valid requests.
The modification of these advanced settings is strongly discouraged.
Type | Description |
---|---|
File size |
The Single File Upload Limit option defines the maximum file size, in bytes, for a POST request. The Multiple File Upload Limit option defines the total file size, in bytes, for a POST request that is a multipart message. For the purpose of these settings, file size is calculated from the body (i.e., message or payload) of POST requests with a Content-Type header that is set to "multipart/form-data." The recommended maximum value for both of these settings is 6,291,456 bytes. |
Query string value/parameters |
A variety of restrictions may be placed on either a request's query string value or parameters. The Total Argument Length option defines the maximum number of characters for the query string value in the request URL. The Max # of Arguments /Request option defines the maximum number of parameters that a query string may contain. The Single Argument Length option defines the maximum number of characters for any single query string parameter value in the request URL. The Argument Name Length option defines the maximum number of characters for any single query string parameter name in the request URL. |
JSON Inspection |
Determines whether JSON payloads will be inspected. |
Identify valid and/or malicious requests by:
Control access to your content by creating whitelists, accesslists, and blacklists for the following categories:
Type | Description |
---|---|
ASN |
Identifies requests according to the autonomous system (AS) from which the request originated. Specify each desired AS by its autonomous system number (ASN). |
Identifies requests by the country from which the request originated. Specify each desired country using its country code. |
|
IP Address |
Identifies requests by the requester’s IPv4 and/or IPv6 address. Specify each desired IP address using standard IPv4/IPv6 and CIDR notation. Specify a subnet by appending a slash (/) and the desired bit-length of the prefix (e.g., 11.22.33.0/22). Do not specify more than 1,000 IP addresses or IP blocks. Whitelist, accesslist, and blacklist entries count towards this limit. |
Referrer |
Identifies requests by referrer. A successful match is found when the specified regular expression matches any portion of the Referer request header value. The Referer request header identifies the URL of the resource (e.g., web page) from which the request was initiated. The specified regular expression may match any portion of the entire URL including the protocol and hostname. |
URL |
Identifies requests by searching for a value that matches the specified regular expression within the request URI. Do not include a protocol or a hostname (e.g., http://cdn.mydomain.com) when defining a regular expression for this access control. Certain common characters (e.g., ?.+) have special meaning in a regular expression. Use a backslash to escape a special character (e.g., main\.html\?user=Joe). Example All of the entries in the following sample access control list will match the sample request: /marketing/.* .*images.* .*/ad[0-9]*\.png Sample request:
http://www.mydomain.com/marketing/images/ad001.png
|
User Agent |
Identifies requests by the user agent that acted on behalf of a user to submit the request. A successful match is found when the specified regular expression matches any portion of the User-Agent request header value. |
The purpose of a whitelist is to identify legitimate traffic.
The purpose of an accesslist is to identify traffic that may access your content upon passing a threat assessment. If one or more accesslists have been defined, WAF will only inspect requests that satisfy at least one criterion in each defined accesslist. All other traffic, unless it has been whitelisted, will be blocked.
The purpose of a blacklist is to describe unwanted traffic.
Traffic is blacklisted when it satisfies all of the following conditions:
Key information:
The order of precedence is:
For example, WAF will inspect a request that satisfies both an accesslist and a blacklist. However, it will automatically allow the delivery of a request that satisfies a whitelist, an accesslist, and a blacklist.
All entries within a URL, referrer, or user agent whitelist, accesslist, and blacklist are regular expressions.
By default, a regular expression defines a case-sensitive match. Use syntax (e.g., [a-zA-Z]) to make it case-insensitive.
The maximum number of entries varies by category.
Category | Combined Limit (Whitelist, Accesslist, and Blacklist) |
---|---|
ASN |
200 |
Country |
600 |
IP Address |
1,000 |
Referrer |
200 |
URL |
200 |
User Agent |
200 |
Whitelist, accesslist, and blacklist entries count towards this limit.
Unlike the access controls described above, the following access controls are limited to identifying malicious traffic:
Define the set of valid and invalid HTTP request methodIndicates the type of action that a server should perform on the asset identified in the request URL. Common HTTP request methods are GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, and CONNECT.s via the Allowed HTTP Methods option.
GET
POST
OPTIONS
HEAD
PUT
DELETE
Define the set of valid media typesIdentifies/classifies the data contained in a file. (aka content types or MIME types) via the Allowed Request Content Types option.
Key information:
WAF performs a threat assessment when either of the following conditions are true:
A request does not include the Content-Type header.
A Content-Type header should only be included when the request includes a payload (e.g., HTTP PUT and POST requests). As a result, HTTP GET requests should not include this header.
WAF automatically sends an alert or blocks a request when its Content-Type header doesn't match a media type defined by this option.
application/x-www-form-urlencoded
multipart/form-data
text/xml
application/xml
application/x-amf
application/json
Define the set of invalid file extensions via the Extension Blacklist option.
Key information:
WAF sends an alert or blocks a request when its file extension matches one defined by this option.
Syntax:
.asa
.asax
.ascx
.axd
.backup
.bak
.bat
.cdx
.cer
.cfg
.cmd
.com
.config
.conf
.cs
.csproj
.csr
.dat
.db
.dbf
.dll
.dos
.htr
.htw
.ida
.idc
.idq
.inc
.ini
.key
.licx
.lnk
.log
.mdb
.old
.pass
.pdb
.pol
.printer
.pwd
.resources
.resx
.sql
.sys
.vb
.vbs
.vbproj
.vsdisco
.webinfo
.xsd
.xsx
A profile must be assigned a rule set. The purpose of this rule set is to identify malicious traffic. The manner in which threats are detected varies by rule set. WAF offers the following rule sets:
Rule Set | Description |
---|---|
OWASP-CRS |
The Open Web Application Security Project (OWASP) Core Rule Sets (CRS) provides generic protection against a variety of unknown vulnerabilities. This rule set does not rely on signatures to check for known vulnerabilities. Rather, it analyzes all HTTP data for malicious payloads. |
Trustwave-OWASPIntegration-Application |
This rule set is undergoing end-of-life and will stop working after 3/31/2020. Please update your profile to use ECRS as soon as possible. This rule set combines key policies from the following rule sets:
This provides comprehensive protection against common attacks and known vulnerabilities. |
ECRS |
This rule set is primarily based off of OWASP CRS 3.x rules. This allows it to provide generic protection against a variety of unknown vulnerabilities. This rule set does not solely rely on signatures to check for known vulnerabilities. Rather, it analyzes all HTTP data for malicious payloads. In addition to defining a threshold, this rule set allows you to balance protection against false positivesWeb Application Firewall: A false positive is a legitimate request that was identified as malicioius traffic by Web Application Firewall. via the Paranoia Level option. Paranoia levels are explained below.
|
Before leveraging a new rule set to secure production traffic, it is strongly recommended to fine-tune its configuration to account for your traffic profile.
Learn more.
Automatically verify that your web applications are compatible with our latest threat detection policies by enabling the Automatically opt-in to the latest ECRS ruleset option. It is recommended that you enable this capability on a profile whose instance has been set to Alert Only. This type of setup provides you with the opportunity to minimize false positives before enforcing our latest threat detection policies on your production traffic.
Each rule set consists of a set of threat detection policies. Each threat detection policy contains a set of rules that define how threats to site traffic will be detected.
Key information:
A threat detection policy or its rules may be disabled.
View a policy's rules by clicking its "N Rules Disabled" link.
The link's label (e.g., 0 Rules Disabled) indicates the number of rules that have been disabled for that policy.
Requests that are identified as a threat will either trigger an alert or be blocked. An instance determines the enforcement action that will take place.
Multiple instances may apply a single profile to different traffic profiles.
Periodic updates to the policies and rules in a rule set are necessary to address the dynamic nature of threats to site traffic. Due to this changing landscape of threats, it is critical to keep up with the latest rule set updates. Using the latest rule set version maximizes the degree to which HTTP/HTTPS traffic is protected.
Identify a rule set's version by the date on which it was released.
Syntax:
Example:
Wait a reasonable amount of time (e.g., 24 to 48 hours) to screen traffic. After which, review the dashboard for false positives.
A brief description for each available threat detection policy is provided below.
The set of available policies varies according to the selected rule set.
Balance security with optimal data delivery performance by disabling policies that do not apply to your site's traffic. For example, the Typo3 attacks policy should be disabled if your site does not use that CMS.
The ability to monitor outbound traffic is currently unsupported. Therefore, none of the following policies are applicable to outbound traffic.
Policy | Description |
---|---|
Bad Robots |
Detects known bad robots. |
Botnet Attacks |
Detects a variety of botnet attacks. |
CC Known |
Detects traffic containing credit card information. |
CC Track Pan |
Detects credit card data leakage. |
ColdFusion Attacks |
Detects attacks that target ColdFusion installations. |
Common Exceptions |
Defines exceptions for traffic that may generate false positives but should not be identified as malicious. This policy contains rules that targets specific Apache and Adobe Flash player behavior. |
cPanel Attacks |
Detects attacks that target sites that leverage cPanel. |
Custom EC Rules |
Detects Bash shellshock and httpoxy attacks. |
DOS Attacks |
Detects Denial of Service attacks. |
Drupal Attacks |
Detects attacks that target Drupal CMS installations. |
Generic Attacks |
Detects common application security attacks (e.g., session fixation and LDAP injection). |
IP Reputation |
Detects requests originating from blacklisted IP addresses. |
Joomla Attacks |
Detects attacks that target Joomla! CMS installations. |
Known Vulns |
Detects a wide variety of known vulnerabilities. This policy contains many rules that target specific types of traffic. Ensure optimal performance by reviewing each rule in this policy and disabling those that are not applicable to your site. |
Malware Detection |
This category is reserved for future use and does not currently have an impact on site traffic. |
MODX Attacks |
Detects attacks that target MODX CMS installations. |
Netcat Attacks |
Detects attacks that target origin servers that leverage the Netcat tool. |
osCommerce Attacks |
Detects attacks that target osCommerce installations. |
phpBB Attacks |
Detects attacks that target phpBB installations. |
Protocol Anomalies |
Detects protocol anomalies, such as empty/missing header data. |
Protocol Violations |
Detects violations of the HTTP protocol, such as URL encoding abuse, missing/duplicate/conflicting headers, invalid characters, etc. |
SharePoint Attacks |
Detects attacks that target SharePoint installations. |
SQL Injection Attacks |
Detects a variety of different methods for initiating a SQL injection (SQLi) attack. |
Tight Security |
Detects path traversal attacks. This type of attack is designed to gain unauthorized access to a private location on a web server. One use for this type of attack is to gain access to a web application’s source code. This category is prone to generate false positives. Use care when enabling this category. |
Trojans |
Detects access to Trojan horses already installed on a server. |
TYPO3 Attacks |
Detects attacks that target TYPO3 CMS installations. |
vBulletin Attacks |
Detects attacks that target vBulletin installations. |
Webshell Backdoors |
Detects attempts to gain backdoor access. |
WordPress Attacks |
Detects attacks that target WordPress installations. |
XSS Attacks |
Detects cross-site scripting (XSS) attacks. An XSS attack is designed to add an unauthorized client-side script to a site. |
The EC Custom Rule policy and polices that start with "Adv" run in signature mode, while all other policies run in anomaly mode. Signature mode means that a single violation will result in a request being categorized as a threat. Anomaly mode means that a threshold must be met before a request will be considered a threat.
Policy | Description |
---|---|
Adv CPanel |
Detects attacks that target sites that leverage cPanel. |
Adv Drupal |
Detects attacks that target Drupal CMS installations. |
Adv IIS |
Detects attacks that target Microsoft IIS servers. |
Adv Joomla |
Detects attacks that target Joomla! CMS installations. |
Adv SharePoint |
Detects attacks that target SharePoint installations. |
Adv Struts |
Detects attacks that target Apache Struts installations. |
Adv WordPress |
Detects attacks that target WordPress installations. |
Cross Site Scripting (XSS) |
Detects cross-site scripting (XSS) attacks. An XSS attack is designed to add an unauthorized client-side script to a site. |
EC Custom Rule |
Detects Bash shellshock attacks, httpoxy attacks, and attacks on Drupal and Apache installations. |
HTTP Attack |
Detects attacks that leverage HTTP requests and responses. |
HTTP Protocol Validation |
Detects attacks that violate the HTTP protocol. |
Java Attack |
Detects Java-based attacks. |
Local File Inclusion (LFI) |
Detects attacks that target the web server's file system. |
PHP Injection (PHPi) |
Detects a variety of different methods for initiating a PHP injection (PHPi) attack. |
Remote Code Execution (RCE) |
Detects a variety of different methods for initiating a Remote Code Execution (RCE) attack. |
Remote File Inclusion (RFI) |
Detects a variety of different methods for initiating a Remote File Inclusion (RFI) attack. |
Scanner Detection |
Detects requests generated by a security scanner or web crawler/bot. |
Session Fixation |
Detects session fixation attack by referrer and cookie values. |
SQL Injection (SQLi) |
Detects a variety of different methods for initiating a SQL injection (SQLi) attack. |
TW IP Reputation |
Detects requests that originate from blacklisted IP addresses. |
An effective strategy for reducing false positivesWeb Application Firewall: A false positive is a legitimate request that was identified as malicioius traffic by Web Application Firewall. is to create rule exceptions. A rule exception identifies one or more rules that will be ignored for a set of requests. Identify requests using any of the following criteria:
If you are using ECRS, then another strategy for reducing false positives is to reduce the Paranoia Level option. The recommended level is 1.
Tips for setting up rule exceptions:
The best strategy for defining exceptions is to:
Use the information identified in step 2 to create a rule exception.