Use managed rules to:
Prevent false positives by:
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.
You may 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 Multiple File Upload Limit option defines the total file size, in bytes, for a POST request that is a multipart message. The recommended maximum value is 6,291,456 bytes. For the purpose of this setting, 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. Define the maximum file size for all other requests through an access rule. |
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. |
The ECRS rule set, which is primarily based off of OWASP CRS 3.x rules, identifies malicious traffic and provides 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. This mode is only recommended for auditing new rule sets. You should set your Security Application Manager configuration's Audit Managed Rule option to a managed rule that has opted-in to automatic updates to the latest rule set. This type of setup provides you with the opportunity to minimize false positives before enforcing our latest threat detection policies on your production traffic.
The ECRS 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.
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 Threats 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.
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:
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:
You may create, modify, and delete managed rules.
Key information:
To create a managed rule
Navigate to the Managed Rules page.
Determine whether WAF will ignore specific cookies, request headers, or query string arguments when assessing whether a request is a threat.
Advanced Users Only
Customize file size and query string limits by expanding More Details and then making the necessary adjustments.
Enable the desired threat detection rules and define the threat identification threshold.
Click the Policies tab. In the Ruleset option, select the type and date for the rule set that may be used to monitor traffic for threats. The Policies section will be refreshed to reflect the selected rule set.
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. This mode is only recommended for auditing new rule sets. You should set your Security Application Manager configuration's Audit Managed Rule option to a managed rule that has opted-in to automatic updates to the latest rule set. This type of setup provides you with the opportunity to minimize false positives before enforcing our latest threat detection policies on your production traffic.
Set the Threshold option to a level (e.g., 5) that balances security with risk tolerance. Requests that are scored at or higher than the specified value will be identified as malicious traffic.
This option only applies to policies other than Custom EC Rules and policies that start with Adv.
Set the Paranoia Level option to a level (e.g., 1) that balances security with risk tolerance.
This is an advanced setting. The recommended paranoia level is 1. Setting this option to a higher value will increase the number of false positivesWeb Application Firewall: A false positive is a legitimate request that was identified as malicioius traffic by Web Application Firewall..
Optional. Add one or more rule exceptions.
From the Parameter option, select whether requests will be identified by argument (i.e., query string argument or request body parameter), cookie, or request header.
From the Argument | Cookie | Header Name option, type one of the following values:
To modify a managed rule
A common reason for updating a managed rule is to reduce false positivesWeb Application Firewall: A false positive is a legitimate request that was identified as malicioius traffic by Web Application Firewall. by adding a rule exception. A rule exception identifies one or more rules that should be ignored for a specific set of requests. Typically, rule exceptions are identified via analysis within the Threats Dashboard.
Navigate to the Managed Rules page.
To delete a managed rule
Navigate to the Managed Rules page.