Profile Settings

Profile setup has been organized into the following categories:

• Settings
• Access Controls
• Policies
• Rule Exceptions

Settings

Core and advanced profile settings are grouped under the Settings tab.

Core Settings

Core profile settings allow you to:

• Assign a name to the profile.

• 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.

  Learn more.

• Prevent false positives by defining the cookies, headers, and query string arguments that will be ignored when analyzing a request.

Preventing False Positives

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.

• Specify each unique cookie, header, or query string argument on a separate line.

• 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.

• A maximum of 100 entries may be defined within a single ignore list.

To set up an ignore list

1. Create or modify a profile.

2. From the Ignore List option, select whether an ignore list will be defined for cookies, headers, or query string arguments. The corresponding option will appear directly below this option.
3. Set this option to a list of cookies, headers, or query string arguments that should be ignored. Identify each one by its name.

Advanced Settings

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.

Access Controls

Identify valid and/or malicious requests by:

• ASN
• Country
• IP address
• Referrer
• URL
• User agent
• HTTP method
• Media type (aka content type)
• File extension

Basic Access Controls

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).
Country	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.

Whitelists

The purpose of a whitelist is to identify legitimate traffic.

• Traffic is whitelisted if it satisfies at least one whitelist criterion.
• WAF automatically approves the delivery of whitelisted requests without inspecting them. As a result, all other security requirements defined in the corresponding profile are not applicable to whitelisted traffic.

Accesslists

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.

Blacklists

The purpose of a blacklist is to describe unwanted traffic.

• Traffic is blacklisted when it satisfies all of the following conditions:

  • The request satisfies at least one blacklist criterion.
  • The request does not qualify for whitelisting or accesslisting.
• WAF automatically generates alerts or blocks blacklisted requests without inspecting them.

Key information:

• A whitelist, accesslist, and blacklist may consist of zero or more entries (i.e., IP address, country, user agent, URL, and referrer).
• A blank whitelist, accesslist, or blacklist is ignored.

• The order of precedence is:

  Whitelist > Accesslist > Blacklist

  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.

• Specify only a single item per line.

• 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.

• Unlike whitelists and blacklists, a request must satisfy at least one criterion in each defined accesslist.

• 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 WAF rule sets, access controls are enforced regardless of whether the requested content will be served from cache or your web server.

Additional Access Controls

Unlike the access controls described above, the following access controls are limited to identifying malicious traffic:

• HTTP method
• Media type
• File extension

HTTP Methods

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.

• Valid: WAF performs a threat assessment on requests whose HTTP method matches a marked option.
• Invalid: WAF automatically sends an alert or blocks a request when its HTTP method does not match a marked option.

Media Types (aka Content Types)

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's Content-Type header matches a media type defined by this option.

  • 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.

• List each desired media type on a separate line.
• Media types are case-insensitive.

File Extensions

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:

  .ext
• File extensions are case-insensitive.
• List each desired file extension on a separate line.

Policies (Rule Set)

WAF provides protection for known and unknown vulnerabilities through the ECRS rule set. Balance security against false positivesWeb Application Firewall: A false positive is a legitimate request that was identified as malicioius traffic by Web Application Firewall. via the Security Level option. Security levels are explained below.

• Low: Choose this level to keep the number of false positives to a minimum.
• Medium: Recommended. Choose this level to provide a slightly higher level of protection to your web applications.
• High: Choose this level to provide the most amount of protection. This level may cause a much higher rate of false positives.

• Custom: Choose this level to select the aggregate score of violations that a request must satisfy before being considered a threat.

  Learn more.

Ensure that your web applications are secured by the latest threat detection policies by enabling the Automatically opt-in to the latest ECRS ruleset option.

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:

• Only a single rule set may be associated with a profile.

• 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.

  • Take care when disabling a policy or an individual rule since it increases the vulnerability of site traffic.
• The purpose of a WAF rule set is to protect your origin servers. As a result, rules are only applied to requests that will be served from your web servers. WAF threat analysis for freshIdentifies cached content that can be served directly by an edge server without requiring revalidation with an origin server. It also indicates that the cached content's TTL has not expired. content solely consists of checking whether the request violates an access control. Specifically, requests served directly from our edge servers will not undergo rule analysis.

• 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.

Policy and Rule Updates

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:

Threat Detection Policies

A brief description for each available threat detection policy is provided below.

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.

Rule Exceptions

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:

• Argument: Identifies all requests with a query string parameter or body parameter whose name matches the specified value.
• Cookies: Identifies all requests with a cookie whose name matches the specified value.
• Header: Identifies all requests with a request header whose name matches the specified value.

Tips for setting up rule exceptions:

• Use regular expressions to create a pattern through which requests will be identified. Mark the Regex? option to specify a regular expression instead of a literal value.

• The best strategy for defining exceptions is to:

  1. Identify false positives within the WAF Dashboard or via our REST API (Get Event Log Entries) by reviewing recent threats and identifying requests that were made by actual users.
  2. Identify a common attribute within those requests and the rule(s) that they inadvertently triggered.

  3. Use the information identified in step 2 to create a rule exception.