Edgecast Web Application Firewall Administration Guide

Disclaimer Care was taken in the creation of this guide. However, Edgecast cannot accept any responsibility for errors or omissions. There are no warranties, expressed or implied, including the warranty of merchantability or fitness for a particular purpose, accompanying this product.

Trademark Information EDGECAST is a registered trademark of Verizon Digital Media Services Inc.

About This Guide Web Application Firewall Administration Guide Version 3.00 8/28/2021

©2021 Verizon Media. All rights reserved.

Table of Contents

Web Application Firewall (WAF) ...... 1 Introduction ...... 1 Configuration ...... 3 Overview ...... 3 Profiles ...... 4 Threat Detection (Legitimate Traffic) ...... 4 Production Traffic ...... 6 Profile Configuration ...... 6 Profile Management ...... 20 Instances ...... 22 Handling Detected Threats ...... 23 Instance Management ...... 26 Activating/Deactivating an Instance ...... 27 Best Practices ...... 29 Setup ...... 29 Threat Analysis (Dashboard) ...... 31 Overview ...... 31 Usage ...... 31 Chart View ...... 32 Event Log View ...... 34 Filters...... 37 User Experience ...... 40 Overview ...... 40 Appendix A ...... 41 Country Codes (ISO 3166) ...... 41 Appendix B ...... 50

Table of Contents Edgecast Page i

Matched On Variables ...... 50

Table of Contents Edgecast Page ii

Web Application Firewall (WAF)

Introduction

Many web sites, web applications, and web servers receive and process requests from outside a company's protected internal network. As a result, they are vulnerable to a variety of malicious attacks including SQL injections, cross-site scripting, and application layer distributed denial of service (DDoS). This exposure poses a threat to your infrastructure and the confidentiality, integrity, and availability of the data delivered by those resources over the Internet. These types of attacks can result in unauthorized access to content, the loss of personally identifiable information (PII), and the dissemination of private/copyrighted information. The Web Application Firewall (WAF) service provides a layer of security between many of these security threats and your external web infrastructure. Our WAF increases security by monitoring, detecting, and preventing application layer attacks. It inspects inbound HTTP/HTTPS traffic against reactive and proactive security policies and blocks malicious activity in-band and on a real-time basis. There are various layers to the protection provided to an origin server via Web Application Firewall, such as:

• Inherent protection from DDoS attacks. . Our worldwide presence establishes an imposing and extensive barrier between an origin server and malicious traffic, regardless of whether it consists of a high- volume HTTP GET flood attack or a slow DDoS attack.

• Protection from application layer attacks. . Enable a comprehensive set of threat detection measures for the purpose of identifying malicious traffic. These measures define the types of application layer attacks that will be detected, such as:

o Protocol validation o Malicious client identification o Generic attack signatures o Known vulnerabilities signatures o Trojan/backdoor access o Denial of Service Web Application Firewall Administration Guide Edgecast Page 1

• Filtering out unwanted traffic by screening for a custom delivery profile. . Traffic that doesn’t meet the requirements defined in this HTTP delivery profile may be blocked before it even reaches our core network.

• Establishing traffic restrictions to block malicious traffic. . Use a whitelist, blacklist, or accesslist to restrict traffic by ASN, country, IP address, referrer, URL, user agent, HTTP method, media type, and/or file extension. The following diagram highlights how traffic is screened before it is processed for delivery. The distributed nature of our worldwide network provides an additional layer of protection to origin servers.

Securing an Origin Server via WAF

Web Application Firewall Administration Guide Edgecast Page 2

Configuration

Overview

The configuration of Web Application Firewall consists of three sequential steps. Once all three steps have been performed, near-real-time threat monitoring may be performed through the dashboard. A brief overview for each WAF setup step is illustrated below.

Configuring Web Application Firewall

Additional information on each WAF configuration step is provided below.

Step Name Description 1 Create Profile Define a security policy for inbound HTTP/HTTPS traffic that defines the: • Whitelists, blacklists, and/or accesslists for ASNs, countries, IP addresses, referrers, URLs, user agents, HTTP methods, media types, and file extensions. • Threshold for threat detection and the types of threat detection policies that will be enacted.

Web Application Firewall Administration Guide Edgecast Page 3

Step Name Description 2 Create Instance Select the profiles that may be applied to site traffic and the manner in which detected threats may be handled. An instance defines: • A profile that may be applied to production traffic. • How potential threats are handled. • A profile that may be used to audit production traffic. 3 Activate Instance Define both of the following items through HTTP Rules Engine: • The type of requests that should be secured by Web Application Firewall. • The instance that identifies the profile(s) that may be used to secure/audit site traffic.

Tip: Different types of requests may require varying levels of protection. Create a profile and an instance for each type of request that requires a unique level of protection.

Profiles

A profile defines the set of security restrictions that will be applied to inbound HTTP/HTTPS traffic.

Threat Detection (Legitimate Traffic)

A profile defines the criteria for determining whether traffic is legitimate or malicious. WAF leverages this security configuration and performs a sequential check for each criterion. An overview of this security check is provided below. 1. Does the request meet a whitelist criterion? If so, it is considered legitimate and no further checks will be performed. 2. Does the request meet a blacklist criterion? If so, it is considered malicious and no further checks will be performed. 3. Does the request satisfy at least one criterion in each defined accesslist? If not, then the request is considered malicious and no further checks will be performed. 4. Will the request be served from cache instead of being forwarded to an origin server? If so, it is considered legitimate and no further checks will be performed. 5. The request will undergo threat detection analysis according to the profile's core rule set and its delivery profile. A request will be classified as malicious traffic when the severity and frequency of rule violations exceeds the configured threshold.

Web Application Firewall Administration Guide Edgecast Page 4

How Does It Work? A request will not be considered a threat until a threshold of violations is met. The score assigned to a request is determined according to the severity and frequency of the violations.

• Severity: Each rule is assigned a severity. Each severity is assigned an anomaly score from 2 to 5.

Severity Anomaly Score Description Critical 5 This severity level is triggered by web attack violations. Error 4 This severity level is reserved for future use. Warning 3 This severity level is triggered by malicious client violations. Notice 2 This severity level is generally used to indicate protocol policy violations.

• Frequency: A threat is identified when the aggregate score for all violations meets or exceeds the configured threshold value. This allows WAF to account for minor violations without forcing it to take action for a single offense. The workflow for threat detection is illustrated below.

A profile may be assigned a threshold value from 2 to 20. However, the recommended value is 5. A threshold value of 5 triggers threat identification after a single severe violation or multiple minor violations. This balanced approach identifies questionable requests without impacting legitimate traffic.

Web Application Firewall Administration Guide Edgecast Page 5

Production Traffic

By itself, a profile will not affect production traffic. It requires both of the following conditions: 1. An instance must define:

• A profile through which production traffic will be screened.

• The action that should take place in response to threats detected in production traffic. 2. A rule in HTTP Rules Engine must activate the above instance for the desired type of traffic. An instance may be activated through the Web Application Firewall feature.

Profile Configuration

Profile setup has been organized into the following categories:

• Settings

• Access Controls

• Policies

• Rule Exceptions

Tip: Assign a template to a new profile to quickly apply the desired default configuration to it.

Templates A template provides a quick method through which a default set of threat detection policies, access controls, and global settings may be assigned to a new profile. The available set of templates consists of:

• A system-defined template (i.e., Defend Basic Profile Template) that contains the recommended default configuration.

• All previously created profiles. . Upon creating a profile, a copy of it is automatically added to the Template option. . A profile may be updated at any time. Modifying an existing profile:

o Updates the corresponding template. o Provides the means for updating the manner through which production traffic is screened without having to modify an instance.

Note: WAF will always screen traffic using a profile's latest configuration.

Web Application Firewall Administration Guide Edgecast Page 6

o Does not affect profiles or templates created from that profile's template.

Important: 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.

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.

• Apply a default configuration to it via a template.

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

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, blacklist, or accesslist. 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.

Note: By default, a regular expression defines a case-sensitive match. Use syntax (e.g., [a-zA-Z]) to make it case-insensitive.

Web Application Firewall Administration Guide Edgecast Page 7

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.

Warning: 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. Note: 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."

Note: The recommended maximum value for both of these settings is 6,291,456 bytes.

Query string value / A variety of restrictions may be placed on either a request's query string parameters 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.

Web Application Firewall Administration Guide Edgecast Page 8

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:

Category 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. Please refer to Appendix A: Country Codes (ISO 3166) to view a list of country codes. IP Address Identifies requests by the requester’s IPv4 and/or IPv6 address. IP addresses may be specified using standard IPv4/IPv6 and CIDR notation. Note: Specify a subnet by appending a slash (/) and the desired bit- length of the prefix (e.g., 11.22.33.0/22).

Note: Do not specify more than 1,000 IP addresses or IP blocks. Whitelist, accesslist, and blacklist entries count towards this limit.

Web Application Firewall Administration Guide Edgecast Page 9

Category Description Referrer Identifies requests by referrer. A successful match is found when the specified regular expression matches any portion of the Referer request header value. Note: 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.

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. URL Identifies requests by searching for a value that matches the specified regular expression within the request URI. Important: Do not include a protocol or a hostname (e.g., http://cdn.mydomain.com) when defining a regular expression for this access control.

Reminder: 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).

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.

Web Application Firewall Administration Guide Edgecast Page 10

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 items (i.e., IP address, country, URL, and referrer).

• A blank whitelist, accesslist, and 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.

Note: 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. . ASN: 200 . Country: 600 . IP Address: 1,000 . Referrer: 200 . URL: 200 . User Agent: 200

Note: Whitelist, accesslist, and blacklist entries count towards this limit.

Web Application Firewall Administration Guide Edgecast Page 11

• 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 methods 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 types (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.

Note: 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.

Note: 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.

Web Application Firewall Administration Guide Edgecast Page 12

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) A profile must be assigned a rule set. The purpose of a rule set is to identify malicious traffic. The manner in which malicious traffic is detected varies according to rule set.

• 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 combines key policies from the following rule sets: . Trustwave This rule set is designed to look for malicious payloads in specific attack vectors (e.g., request parameters, request headers, cookies, etc.). . OWASP-CRS This provides comprehensive protection against common attacks and known vulnerabilities.

Web Application Firewall Administration Guide Edgecast Page 13

• ECRS: This rule set is primarily based off of OWASP CRS 3.0.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 positives via the Paranoia Level option. Paranoia levels are explained below. . 1: Recommended. Choose this level to keep the number of false positives to a minimum. . 2: Choose this level to provide a slightly higher level of protection to your web applications. . 3: Choose this level to provide more protection with a higher rate of false positives. . 4: Choose this level to provide the most amount of protection. This level may cause a much higher rate of false positives.

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

Note: The link's label (e.g., 0 Rules Disabled) indicates the number of disabled rules within the corresponding policy.

. Take care when disabling a policy or an individual rule since it increases the vulnerability of site traffic.

• Changing the rule set associated with a profile will replace the existing threat detection configuration with the selected one. By default, all policies and rules will be enabled on the newly selected rule set.

Web Application Firewall Administration Guide Edgecast Page 14

• 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 fresh 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. The manner in which threats detected for a given profile are handled may be defined by one or more instances.

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: Rule_Set Date Example: ECRS 2018-09-14 To apply an updated rule set to production traffic (recommended) 1. Create a new profile that points to the updated rule set. 2. Modify the desired instance to set the above profile as the audit profile. 3. Wait a reasonable amount of time (e.g., 24 to 48 hours) to screen traffic. After which, review the dashboard for false positives.

• If many false positives are found, identify the policies and/or rules that are causing them and disable them from the profile created in step 1. After which, repeat step 3.

• If few false positives are found, set the instance's production profile to the profile created in step 1.

Web Application Firewall Administration Guide Edgecast Page 15

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

Note: The set of available policies varies according to the selected rule set.

Note: 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.

Note: The ability to monitor outbound traffic is currently unsupported. Therefore, none of the following policies are applicable to outbound traffic.

Trustwave-OWASPIntegration-Application Policies Trustwave-OWASPIntegration-Application policies are listed below.

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. This policy should only be enabled for eCommerce traffic. Coldfusion attacks Detects 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 rules Detects Bash shellshock 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. Tip: 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.

Web Application Firewall Administration Guide Edgecast Page 16

Policy Description Malware detection Note: 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. Warning: 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.

Web Application Firewall Administration Guide Edgecast Page 17

ECRS Policies ECRS policies are listed below.

Note: 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 Detects a variety of different methods for initiating a Remote (RCE) 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.

Web Application Firewall Administration Guide Edgecast Page 18

Rule Exceptions An effective strategy for reducing false positives 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.

Tip: 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:

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

Web Application Firewall Administration Guide Edgecast Page 19

Profile Management

Learn how to create, view, and modify profiles. Key information:

• Perform profile administration from the Profile Manager page. • Production traffic will not be screened by WAF unless both of the following conditions are true: 1. A profile has been associated with an instance. 2. The above instance has been activated via HTTP Rules Engine.

Tip: Multiple instances may be activated via HTTP Rules Engine. Leverage this capability to tailor WAF screening by traffic profile.

• It may take up to 5 minutes for an updated profile configuration to be applied across our entire network.

Creating a Profile This section provides step-by-step instructions on how to create a profile.

Tip: Templates are an easy way to apply a default configuration to a new profile.

Reminder: Creating a profile will automatically add it to the Template option.

To create a profile 1. From the Profile Manager page, click Add Profile. 2. In the Name option, type the name by which this profile will be identified. This name should be sufficiently descriptive to identify it when setting up an instance. 3. Verify that the Template option is set to a template that best reflects how your traffic should be screened. If unsure, set this option to the "Defend Basic Practices Profile Template." 4. Click the Access Controls tab. Define the desired whitelists/blacklists/accesslists. 5. Click the Policies tab. In the Rulesets option, select the type and version for the rule set that may be used to monitor traffic for threats. The Choose Policies section will be refreshed to reflect the selected rule set.

Tip: 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

Web Application Firewall Administration Guide Edgecast Page 20

minimize false positives before enforcing our latest threat detection policies on your production traffic.

6. Set the Threshold option to a level (e.g., 15) that balances security with risk tolerance. Requests that are scored at or higher than the specified value will be identified as malicious traffic.

Note: If you selected the ECRS rule set in the previous step, then this option only applies to policies other than Custom EC Rules and policies that start with "Adv."

7. ECRS Only: If you selected ECRS in step 5, then set the Paranoia Level option to a level (e.g., 1) that balances security with risk tolerance.

Tip: This is an advanced setting. The recommended paranoia level is 1. Setting this option to a higher value will increase the number of false positives.

8. Review all enabled policies and rules to ensure that the legitimate traffic is not targeted by mistake. 9. Click Create Profile.

Modifying a Profile Modifying an existing profile:

• Updates the template that was created from that profile.

• Provides the means for updating the manner through which production traffic is screened without having to modify an instance.

• Does not affect profiles created from that profile's template.

Tip: A common reason for updating a profile is to reduce false positives 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 WAF Dashboard.

To modify a profile 1. From the Profile Manager page, click on the desired profile. 2. After making the desired changes, click Save.

Web Application Firewall Administration Guide Edgecast Page 21

Deleting a Profile A profile may be permanently deleted from the system.

Important: Profiles associated with an instance may not be deleted. Please either modify the instance to point to a different profile or delete that instance.

To delete a profile 1. From the Profile Manager page, click the desired profile. 2. Click Delete Profile. 3. Type "DELETE" and then click Delete.

Instances

The purpose of an instance is to identify profiles which may be used to assess threats against production traffic. To this end, an instance:

• Identifies a profile that may be applied to production traffic.

• Identifies how unwanted traffic, as defined by the above profile, will be handled.

Note: Each detected threat is logged regardless of the action (i.e., block, custom response, redirect, or alert) defined within an instance.

• Identifies whether the threats detected from an additional profile should be audited. . Use this capability to test out a new WAF configuration without impacting production traffic. . Threats detected by an audit profile may be tracked through the dashboard.

o Use "Profile Type" to graph threats according to whether they were detected as a result of a production or audit profile.

o Use the "Instance" and "Profile Type" filters to only display threats detected by a production or audit profile.

Note: Auditing a profile that is already being applied to production traffic will cause the same threat to be logged twice.

Web Application Firewall Administration Guide Edgecast Page 22

Handling Detected Threats

All threats detected by Web Application Firewall will be logged. Logged threats may be viewed from the Web Application Firewall dashboard.

Note: Standard security practices dictate that measures should be taken to prevent sensitive data (e.g., credit card information or passwords) from being passed as clear text from the client to your origin server. Another incentive for encrypting sensitive data is that it will be logged by our system when an alert is triggered as a result of this data. If sensitive data cannot be encrypted or obfuscated, then it is strongly recommended to contact our technical customer support to disable logging for the Matched Value field.

An instance configuration determines whether any of the following additional actions will be applied to the detected threat.

Mode Description Block Request Detected threats will be dropped and the client will receive a 403 Forbidden response. Alert Only Detected threats will only generate an alert. Note: Use this mode to track detected threats through the dashboard without affecting traffic.

Redirect (HTTP 302) Detected threats will be redirected to the specified URL. Key information: • The HTTP status code for this response will be a 302 Found. • Set the URL option to the URL to which detected threats will be redirected. Make sure to specify a full URL. Example: http://cdn.mydomain.com/marketing/busy.html

Web Application Firewall Administration Guide Edgecast Page 23

Mode Description Custom Response Detected threats will receive a custom response. Define the custom response that will be sent in response to a detected threat. • Response Body: Configure whether the response body will consist of a default error page or the value defined in the Response Body option. . Display Default Error Page: Mark this option to respond to detected threats with a web page that describes the detected threat. Specifically, it will indicate the client's IP address, the requested URL, and the date/time at which the request was screened. . Response Body: Defines the payload that will be delivered to the client in response to a detected threat. Tip: This option supports the use of event variables to customize the response according to the detected threat.

Note: Setting a value in the Response Body option will cause it to take precedence over the Display Default Error Page option.

• HTTP Status Code: Defines the HTTP status code that will be sent to the client. • Custom Response Headers: Defines one or more response headers that will be sent to the client. Define each custom response header on a separate line. Tip: This option supports the use of event variables to customize the response according to the detected threat.

Syntax: Name:Value Example: MyCustomHeader:True Note: All characters, including spaces, defined before or after the colon will be treated as a part of the specified header name or value, respectively.

Web Application Firewall Administration Guide Edgecast Page 24

Event Variables A custom response header value or a custom response body may include variables that describe the event. These variables are described below.

Variable Description EVENT_ID Represents the system-defined ID assigned to the request that was identified as a threat. Tip: Find out detailed information about the detected threat by passing this ID to the Get Event Log Entry endpoint (REST API).

CLIENT_IP Represents the IP address of the device that submitted the detected threat. TIMESTAMP Represents the date and time at which the detected threat was submitted. REQUEST_URL Represents the URL for the request that was deemed a threat.

Add an event variable to a custom response header value or a custom response body by enclosing it with double curly braces as shown below. Syntax:

{{VARIABLE_NAME}}

Example:

{{EVENT_ID}}

Web Application Firewall Administration Guide Edgecast Page 25

Instance Management

Learn how to create, modify, and view instances.

Note: It may take up to 5 minutes for an updated instance configuration to be applied across our entire network.

Creating an Instance Create an instance that identifies a profile that WAF may use to screen traffic.

Reminder: An instance will not affect production traffic unless it has been activated.

To create an instance 1. From the Instance Manager page, click Add Instance. 2. In the Name option, type the name by which this instance will be identified. This name should be sufficiently descriptive to identify it during the activation process that is performed from within HTTP Rules Engine. 3. From the Production Profile option, select a profile that may be applied to production traffic. 4. From the Production Action option, determine how unwanted traffic will be handled (i.e., block, alert, redirect, or send a custom response). 5. Use the Audit Profile option to test out a new security configuration. Perform one of the following steps:

• Enable Auditing: Select a profile that contains the security configuration that should be tested on production traffic. Detected threats will generate alerts of type "audit."

• Disable Auditing: Make sure that the Audit Profile option is set to blank. 6. Click Save.

Modifying an Instance Any setting associated with an instance configuration may be modified. To modify an instance 1. From the Instance Manager page, click on the desired instance. 2. After making the desired changes, click Save.

Web Application Firewall Administration Guide Edgecast Page 26

Deleting an Instance An instance may be permanently deleted from the system.

Important: Instances associated with a rule may not be deleted. Please either modify the rule to point to a different instance or delete that rule.

To delete an instance 1. From the Instance Manager page, click the desired instance. 2. Click Delete Instance. 3. Type "DELETE" and then click Delete.

Activating/Deactivating an Instance

An instance must be activated via HTTP Rules Engine before Web Application Firewall may assess production traffic for potential threats and ensure that traffic conforms to a specific delivery profile. This activation process is a safety measure designed to ensure the following:

• Only vetted WAF profiles are applied to site traffic.

• WAF is only applied to requests that match the criteria defined in rules containing a Web Application Firewall feature.

• The use of instances combined with HTTP Rules Engine provides the following benefits: . Centralized Configuration: Instances provide a central location for changing the WAF profile used to screen traffic. This reduces the possibility for the oversight of an old WAF configuration. . Flexibility: The use of HTTP Rules Engine to define the type of requests that will be screened allows WAF to be configured to meet any and all organizational needs. It allows a single or multiple instances to be applied to different types of requests. Activate an instance by: 1. Creating or modifying a rule to include the Web Application Firewall feature. 2. Setting the Web Application Firewall feature to the desired instance.

Web Application Firewall Administration Guide Edgecast Page 27

Consider the following items when activating an instance:

• The placement of the Web Application Firewall feature within a rule determines the type of requests that will be secured via WAF.

• Activate the Web Application Firewall feature for each type of request that should be secured via WAF. . Determine a rule's scope (e.g., all requests or by customer origin) by balancing the need to secure as much traffic as possible with the level of restrictive measures imposed by the WAF security profile.

Tip: The recommended approach for instance activation is to apply the most restrictive policy to as much traffic as possible while causing minimal impact to data delivery.

. Only a single Web Application Firewall feature should be activated per request type (e.g., all requests or origin-specific requests).

Warning: Setting up Rules Engine to activate multiple WAF instances for a single type of request will only activate one of those instances.

. Multiple occurrences of the Web Application Firewall feature may point to the same instance. This allows the corresponding security policy to be applied to different types of requests.

• A WAF instance may be deactivated by simply deleting the Web Application Firewall feature associated with the desired rule. This action will not affect any other previously activated WAF instances.

• The activation/deactivation of a Web Application Firewall instance is dependent on HTTP Rules Engine. Rule changes, such as adding, modifying, or deleting a rule, may take up to 1 hour to propagate. Additionally, all rule changes must undergo an internal review process. For more information, please refer to the HTTP Rules Engine Administration Guide. • Do not delete either of the following configurations: . A WAF instance while it is associated with the Web Application Firewall feature. . A WAF profile assigned to a WAF instance associated with the Web Application Firewall feature.

Web Application Firewall Administration Guide Edgecast Page 28

Best Practices

Best practices on setting up Web Application Firewall vary by organization due to a variety of factors, such as those listed below.

Factor Description Web Applications The type of web applications running on the origin server may affect the level of protection that may be applied via WAF. Traffic Delivery The level of security that should be applied to site traffic may vary for a Profile variety of reasons, such as: • Public vs. private content that requires authentication • CMS vs. non-CMS traffic Additionally, there may be multiple traffic delivery profiles that are specific to a site, role, or the action being performed. Acceptable Risk WAF allows the flexibility to determine the degree to which a site will be protected. A balance must be found between security and allowing the flow of legitimate traffic. A major factor in this balancing act is the degree to which an organization is able to cope with risk.

As a result of the above factors, it may make sense to tailor WAF security by request type. This may require the following configuration:

• A profile for each custom set of security requirements.

• An instance for each profile that should be activated on production traffic.

• A rule or a rule statement for each traffic profile with custom security requirements.

Setup

WAF security profiles that may interfere with legitimate traffic should be handled as indicated below: 1. Create the desired profile. 2. Create an instance that generates alerts for the new profile. 3. Add/modify a rule. It should contain the Web Application Firewall feature that points to the instance created above. 4. After an acceptable period of time has passed (e.g., 24 to 48 hours), review the alerts logged in the dashboard. Assess whether the new security policy is too restrictive, too permissive, or balanced. Perform one of the following:

Web Application Firewall Administration Guide Edgecast Page 29

• Too Permissive: Close any security loopholes by defining additional restrictions on the corresponding profile’s threat detection policies/rules, access controls, and/or global settings.

• Too Restrictive: If the dashboard indicates that legitimate traffic is being flagged, then filter for the alert in question, switch to Event Log, expand the alert, and then take a look at the Rule Tags field to determine whether a rule, access control, or delivery profile was violated. Take the following action: . Rules: The recommended approach is to avoid disabling policies and rules whenever possible. Assess the rule that was violated and consider whether the web application should be updated to conform to that rule. If careful analysis indicates that the security profile must be changed, then disable the rule in question.

Tip: A rule may be identified through the Rule Tags and Rule ID fields. The Rule Tags field identifies a rule category, while the Rule ID field provides the identification number for the rule that triggered the alert.

Tip: Each rule category contains a search feature that finds all rules within that category whose name contains the specified term or that are an exact match for the specified ID.

. Access Control: Consider modifying the access control to allow that type of request. . Delivery Profile: Consider modifying the delivery profile to account for that type of request.

• Balanced: Set the corresponding instance's Production Action option to "block." This will cause WAF to block requests that violate the profile’s security configuration. Learn more.

Web Application Firewall Administration Guide Edgecast Page 30

Threat Analysis (Dashboard)

Overview

The dashboard provides an avenue through which a historical analysis of recent threats to site traffic may be performed. This type of an analysis provides the means through which you may:

• Visualize the time periods during which site traffic is most heavily targeted.

• Understand the variety, frequency, and severity of illegitimate traffic.

• Identify the countries from which illegitimate traffic originates.

• Identify key individual offenders by their IP address.

• Learn detailed information on the types of attack being mounted against your site.

Usage

The dashboard contains two different views through which threat analysis may be performed, which are chart and event log. To view the WAF Dashboard 1. From the main menu, navigate to Defend | WAF | Dashboard. The dashboard will display a chart showing recent violations of your security policy. 2. Optional. View event log data by clicking Event Logs from the side navigation bar.

Web Application Firewall Administration Guide Edgecast Page 31

Chart View

Chart view is a useful tool for detecting patterns for objectionable traffic directed to your origin servers. This view consists of two basic components:

Component Description Chart A chart or line graph displays the number of malicious threats detected over a given time period. By default, a single line on the graph represents all malicious traffic. Alternatively, categorize malicious traffic by selecting the desired categorization criteria from the option that appears directly above the graph. A line will be drawn on the chart for each unique value. For example, if you select "Profile Type" and requests were screened by a production and audit profile, then the graph will contain a line for audit and another one for production. Note: By default, graphing malicious traffic by type will include up to the 10 most popular entries. Customize this limit through the Max Top Number option. This option also affects the maximum number of unique entries that may be listed for each type of statistic listed under the graph.

Statistics Statistics on the malicious threats detected over a given time period are displayed directly below the chart. Statistics are broken down by category. Note: By default, statistics for up to the 10 most popular entries may be displayed for each category. Customize this limit through the Max Top Number option. This option also affects the maximum number of lines that may be graphed.

The following information is displayed for each category: • Value: Groups malicious threats by the request's value for the current category. • %: Indicates the percentage of detected threats over a given time period that belong to the group identified by the Value field. • Events: Indicates the number of detected threats that belong to the group identified by the Value field. Important: Percentages are calculated on the total threats detected during the given time period. Since there is a limit of 10 entries per category, the sum of the percentages for larger categories will not add up to 100%.

Web Application Firewall Administration Guide Edgecast Page 32

Key information: • By default, a chart includes all rule violations within the last seven days. . The chart may be filtered by the criteria listed directly below it. Additional filters are available when viewing an individual alert from the event log. . The time period being charted may be adjusted through the Time Range option.

o This option is displayed directly to the left of the chart. o The unit associated with the selected time period determines whether events will be graphed by minute, hour, or day.

• A timeline, which appears directly below the chart, displays a mini-chart for the time period defined by the Time Range option. Use this timeline to update the chart to only display data for either of the following time periods: . Custom Time Period: Click and drag anywhere in the timeline to update the chart to only display the selected time period. . Entire Time Period: Click anywhere in the timeline to clear the selection. After which, the chart will now display the entire time period defined by the Time Range option. • Hovering over the line graph will indicate the exact number of warnings that took place during that time slot.

Web Application Firewall Administration Guide Edgecast Page 33

Event Log View

This view provides the means to delve into the details of an illegitimate request. The information derived from this view provides a deeper understanding as to why a request was deemed objectionable and the type of attacks being mounted on an origin server. The event log contains a list of recent rule violations. Syntax:

Anomaly Score Threshold Exceeded, Total Score: # Elapsed_Time Time

Example:

Anomaly Score Threshold Exceeded, Total Score: 5 10s ago 15:01:23.45 UTC

Field Definitions Clicking on a rule violation will expand that entry and display detailed information about it. A brief description for each field used to describe rule violations is provided below.

Field Description Action Type Indicates the type of action that was taken in response to the rule violation. Valid values are: • ALERT: This term has been deprecated in favor of NOP. • BLOCK_REQUEST: Indicates that the request that violated a rule was blocked. • BLOCK: This term has been deprecated in favor of BLOCK_REQUEST. • NOP: Indicates that an alert was generated in response to the rule violation. • REDIRECT_302: Indicates that the request that violated a rule was redirected to the URL associated with the instance defined by the Instance Name field. • CUSTOM_RESPONSE: Indicates that a custom response was returned to the client that submitted a request that violated a rule. Client IP Identifies the IP address of the client from which the request originated. Country Name Identifies the country from which the request originated by its name. Instance Name Indicates the name of the instance that activated the profile containing the rule that the requested violated. Profile Name Indicates the name of the profile that the request violated. Profile Type Indicates whether the request was screened as a result of an instance’s production or audit profile.

Web Application Firewall Administration Guide Edgecast Page 34

Field Description Referer Indicates the request’s referrer as defined by the Referer request header. Rule ID Indicates the ID for the rule that the request violated. Tip: This field indicates that the rule met or exceeded the maximum anomaly score. Please refer to the Sub Event(s) section, which contains a sub event for each rule violated by a request, to find out why the request was flagged or blocked. Each sub event indicates the rule that was violated and the data used to identify the violation.

Rule Message Provides a description of the rule that the request violated. Syntax: Inbound Anomaly Score Exceeded (Total Score: 3, SQLi=0, XSS=0): Last Matched Message: Rule Message This term "Rule Message" represents the message for the last rule that the request violated. Tip: More information about the violation(s) incurred by the request is reported in the violation's Sub Event section.

Timestamp Indicates the date and time (UTC) at which the rule violation occurred. URL Indicates the URL of the request that triggered the rule violation. User Agent Indicates the user agent that submitted the request that triggered the rule violation. This information is derived from the User-Agent request header.

Web Application Firewall Administration Guide Edgecast Page 35

Sub Events In addition to the core set of fields described above, a sub event for each rule that was violated by the request will be reported. The syntax for the header bar associated with each sub event is described below.

Anomaly Score Threshold Exceeded, Total Score: # Elapsed_Time UTC_Time

Each sub event contains the following fields:

Field Description Matched Data Deprecated. Indicates the client-side data that triggered the violation. For example, this response element may report a client's IP address or a portion of the URL that violated the request. Matched On Indicates a variable that identifies where the violation was found. Please refer to Appendix B: Matched On Variables section for more information on variables. Matched Value Indicates the value of the variable defined by the Matched On field. Reminder: Standard security practices dictate that measures should be taken to prevent sensitive data (e.g., credit card information or passwords) from being passed as clear text from the client to your origin server. Another incentive for encrypting sensitive data is that it will be logged by our system when an alert is triggered as a result of this data. If sensitive data cannot be encrypted or obfuscated, then it is strongly recommended to contact our technical customer support to disable logging for the Matched Value field.

Operator Name Identifies a rule parameter that was violated. Operator Indicates the value assigned to the rule parameter that was violated. Parameter Rule ID Indicates the ID for the rule that the request violated. Rule Message Provides a description of the rule that the request violated. Rule Tags Indicates the tags associated with the rule that the request violated. These tags may be used to determine whether a rule, access control, or global setting was violated. Naming convention: Rule Set/Category/Subcategory Total Anomaly Indicates the anomaly score assigned to the request. This score is Score determined by the number of rules that were violated and their severity.

Web Application Firewall Administration Guide Edgecast Page 36

Filters

Both the chart and the event log will be filtered by the time at which the violation occurred. Use the Time Range option to define the relative time period from the present (e.g., Last 12 hours or Last 7 Days) for which data will be reported in the dashboard.

Note: Events will be reported using the selected time unit (i.e., events per minute, hour, or day).

Additionally, events may be filtered using one or more of the following criteria:

Filter Description Action Type Filters requests by the manner in which the violation was handled. Valid values are: • ALERT: This term has been deprecated in favor of NOP. • BLOCK_REQUEST: Indicates that the request that violated a rule was blocked. • BLOCK: This term has been deprecated in favor of BLOCK_REQUEST. • NOP: Indicates that an alert was generated in response to the rule violation. • REDIRECT_302: Indicates that the request that violated a rule was redirected to the URL associated with the instance defined by the Instance Name field. • CUSTOM_RESPONSE: Indicates that a custom response was returned to the client that submitted a request that violated a rule. Client IP Filters requests by the IP address of the client from which it originated. Country Code Filters requests by country of origin. Identify a country by its country code. Instance Name Filters requests by the instance that triggered the violation. An instance is identified by its name. Profile Type Filters requests by the type of profile (i.e., production or audit) that triggered the violation. Note: A production and an audit profile may be defined for each instance. This configuration determines the value that will be reported by this field.

Web Application Firewall Administration Guide Edgecast Page 37

Filter Description Rule ID Filters requests by the type of rule that was violated. Rule Message Filter the dashboard by rule by clicking on the desired rule message or ID. Note: Filtering by rule message or ID will include all related rule messages/ID.

URL Filters requests by the request URL. User Agent Filters requests by user agent.

Web Application Firewall Administration Guide Edgecast Page 38

Key information: • Most filters may be applied by simply clicking on the desired entry. After which, the icon will be displayed next to it. This icon indicates that the dashboard is being filtered by that entry. . Chart: Look for the statistics shown under the graph and then click on the desired value to filter for all requests that match it. . Event Log: Expand a rule violation and then click on the desired field value.

Tip: Blue font indicates a field value that may be applied as a filter to the dashboard.

Important: Filtering by rule message or ID will filter for the selected rule and all other rules that contributed to the violation of the anomaly score threshold.

• The Time Range option is different from other filters in that it is mandatory. Specify the time period by which the chart and the event log will be filtered.

• The Filters section, which appears on the left-hand side of the dashboard, displays a list of active filters. It also allows a filter to be cleared by clicking on the icon displayed next to it.

Web Application Firewall Administration Guide Edgecast Page 39

User Experience

Overview

Once a WAF instance has been activated through HTTP Rules Engine, all requests that meet the specified match criteria will be screened according to the profile associated with that instance. Additionally, that instance's Production Action setting determines whether WAF will generate alerts or block unwanted traffic. The user experience for each possible configuration is described below.

Configuration Description Alert The requester will be unaware that the request was screened by WAF. Block The user experience for requests blocked by WAF is described below. • The user will receive a 403 Forbidden instead of the requested asset. • The response for the blocked request will include an additional response header. The name of this response header is defined by the corresponding profile's Response Header Name option. This response header will be set to "403." Default WAF response header name/value: • X-EC-Security-Audit: 403

Web Application Firewall Administration Guide Edgecast Page 40

Appendix A

Country Codes (ISO 3166)

Use the following ISO 3166 country codes when defining a country whitelist, accesslist, and blacklist.

Reminder: Country codes are case-insensitive.

Code Country AF Afghanistan AL Albania DZ Algeria AS American Samoa AD Andorra AO Angola AI Anguilla AQ Antarctica AG Antigua and Barbuda AR Argentina AM Armenia AW Aruba AP Asia/Pacific Region AU Australia AT Austria AZ Azerbaijan BS Bahamas BH Bahrain BD Bangladesh BB Barbados BY Belarus BE Belgium

Web Application Firewall Administration Guide Edgecast Page 41

Code Country BZ Belize BJ Benin BM Bermuda BT Bhutan BO Bolivia BA Bosnia and Herzegovina BW Botswana BV Bouvet Island BR Brazil IO British Indian Ocean Territory BN Brunei Darussalam BG Bulgaria BF Burkina Faso BI Burundi KH Cambodia CM Cameroon CA Canada CV Cape Verde KY Cayman Islands CF Central African Republic TD Chad CL Chile CN China CX Christmas Island CC Cocos (Keeling) Islands CO Colombia KM Comoros CG Congo CD Congo, The Democratic Republic of the CK Cook Islands CR Costa Rica

Web Application Firewall Administration Guide Edgecast Page 42

Code Country CI Cote d'Ivoire HR Croatia CU Cuba CY Cyprus CZ Czech Republic DK Denmark DJ Djibouti DM Dominica DO Dominican Republic EC Ecuador EG Egypt SV El Salvador GQ Equatorial Guinea ER Eritrea EE Estonia ET Ethiopia EU Europe FK Falkland Islands (Malvinas) FO Faroe Islands FJ Fiji FI Finland FR France GF French Guiana PF French Polynesia TF French Southern Territories GA Gabon GM Gambia GE Georgia DE Germany GG Guernsey GH Ghana

Web Application Firewall Administration Guide Edgecast Page 43

Code Country GI Gibraltar GR Greece GL Greenland GD Grenada GP Guadeloupe GU Guam GT Guatemala GN Guinea GW Guinea-Bissau GY Guyana HT Haiti HM Heard Island and McDonald Islands VA Holy See (Vatican City State) HN Honduras HK Hong Kong HU Hungary IS Iceland IM Isle of Man IN India ID Indonesia IR Iran, Islamic Republic of IQ Iraq IE Ireland IL Israel IT Italy JE Jersey JM Jamaica JP Japan JO Jordan KZ Kazakhstan KE Kenya

Web Application Firewall Administration Guide Edgecast Page 44

Code Country KI Kiribati KP Korea, Democratic People's Republic of KR Korea, Republic of KW Kuwait KG Kyrgyzstan LA Lao People's Democratic Republic LV Latvia LB Lebanon LS Lesotho LR Liberia LY Libyan Arab Jamahiriya LI Liechtenstein LT Lithuania LU Luxembourg MO Macao MK Macedonia MG Madagascar MW Malawi MY Malaysia MV Maldives ML Mali MT Malta MH Marshall Islands MQ Martinique MR Mauritania MU Mauritius YT Mayotte MX Mexico FM Micronesia, Federated States of MD Moldova, Republic of MC Monaco

Web Application Firewall Administration Guide Edgecast Page 45

Code Country MN Mongolia ME Montenegro MS Montserrat MA Morocco MZ Mozambique MM Myanmar NA Namibia NR Nauru NP Nepal NL Netherlands AN Netherlands Antilles NC New Caledonia NZ New Zealand NI Nicaragua NE Niger NG Nigeria NU Niue NF Norfolk Island MP Northern Mariana Islands NO Norway OM Oman PK Pakistan PW Palau PS Palestinian Territory PA Panama PG Papua New Guinea PY Paraguay PE Peru PH Philippines PL Poland PT Portugal

Web Application Firewall Administration Guide Edgecast Page 46

Code Country PR Puerto Rico QA Qatar RE Reunion RO Romania RU Russian Federation RW Rwanda SH Saint Helena KN Saint Kitts and Nevis LC Saint Lucia PM Saint Pierre and Miquelon VC Saint Vincent and the Grenadines WS Samoa SM San Marino ST Sao Tome and Principe SA Saudi Arabia SN Senegal RS Serbia SC Seychelles SL Sierra Leone SG Singapore SK Slovakia SI Slovenia SB Solomon Islands SO Somalia ZA South Africa GS South Georgia and the South Sandwich Islands ES Spain LK Sri Lanka SD Sudan SR Suriname SJ Svalbard and Jan Mayen

Web Application Firewall Administration Guide Edgecast Page 47

Code Country SZ Swaziland SE Sweden CH Switzerland SY Syrian Arab Republic TW Taiwan TJ Tajikistan TZ Tanzania, United Republic of TH Thailand TG Togo TK Tokelau TO Tonga TT Trinidad and Tobago TN Tunisia TR Turkey TM Turkmenistan TC Turks and Caicos Islands TV Tuvalu UG Uganda UA Ukraine AE United Arab Emirates GB United Kingdom US United States UM United States Minor Outlying Islands UY Uruguay UZ Uzbekistan VU Vanuatu VE Venezuela VN Vietnam VG Virgin Islands, British VI Virgin Islands, U.S. WF Wallis and Futuna

Web Application Firewall Administration Guide Edgecast Page 48

Code Country EH Western Sahara YE Yemen ZM Zambia ZW Zimbabwe

Web Application Firewall Administration Guide Edgecast Page 49

Appendix B

Matched On Variables

A short description of the information contained for each variable referenced in the Matched On field is provided below.

Variable Scope ARGS Contains: • All query string parameters • All parameters in the POST request body ARGS_COMBINED_SIZE Describes the combined size of all request parameters. ARGS_GET Contains all query string parameters. ARGS_GET_NAMES Contains the names of all query string parameters. ARGS_NAMES Contains the names for: • All query string parameters • All parameters in the POST request body ARGS_POST Contains all parameters in the POST request body. ARGS_POST_NAMES Contains the names of all parameters in the POST request body. AUTH_TYPE Describes the built-in HTTP authentication method (e.g., Basic) used to validate a user. DURATION Describes the length of time, in milliseconds, it took to fulfill the request. ENV Identifies an environment variable. FILES Describes the original file name for a multipart/form-data (e.g., byte range) request. FILES_COMBINED_SIZE Describes the total file size of the request body for a multipart/form-data (e.g., byte range) request. FILES_NAMES Contains a list of form fields that were used for file upload for a multipart/form-data request. FULL_REQUEST Describes the request including request headers and the request body.

Web Application Firewall Administration Guide Edgecast Page 50

Variable Scope FULL_REQUEST_LENGTH Indicates the number of bytes that may be used by FULL_REQUEST. FILES_SIZES Contains a list of file sizes for a multipart/form-data (e.g., byte range) request. FILES_TMPNAMES Contains a list of file names for the temporary files generated for a multipart/form-data (e.g., byte range) request. GEO Contains a geographical description of the request. This variable may contain any of the following fields: • AREA_CODE: Identifies the area code from which the request originated. This information is only gathered for requests that originate from the United States. • CITY: Identifies the name of the city from which the request originated. • COUNTRY_CODE: Identifies the country from which the request originated through its two character country code. Please refer to Appendix A: Country Codes (ISO 3166) for more information. • COUNTRY_CODE3: Identifies the country from which the request originated through its country code. This code may consist of up to three characters. • COUNTRY_CONTINENT: Identifies the continent from which the request originated by its two character continent code (e.g., EU). • COUNTRY_NAME: Identifies the country from which the request originated by its name. • DMA_CODE: Identifies the metropolitan area code from which the request originated. This information is only gathered for requests that originate from the United States. • LATITUDE: Identifies the latitude from which the request originated. • LONGITUDE: Identifies the longitude from which the request originated. • POSTAL_CODE: Identifies the postal code from which the request originated. • REGION: Identifies the region from which the request originated by its two character region code. . US: Identifies a state.

Web Application Firewall Administration Guide Edgecast Page 51

Variable Scope . Canada: Identifies a province. HIGHEST_SEVERITY Indicates the highest threat severity assigned to the request. INBOUND_DATA_ERROR Set to 1 when the request body size exceeds the corresponding profile's Max File Size option. MULTIPART_CRLF_LF_LINES Set to 1 when a multipart request (e.g., byte range request) uses mixed line terminators. MULTIPART_FILENAME Contains a request's multipart data. MULTIPART_NAME Contains a request's multipart data. MULTIPART_STRICT_ERROR Set to 1 when an error is detected in the request body for a multipart/form-data (e.g., byte range) request. MULTIPART_UNMATCHED_BO Set to 1 when a faux boundary is detected within a UNDARY multipart/form-data (e.g., byte range) request. PATH_INFO Contains the extra path information that may be appended to a URL. For example, this variable would contain "/abc" for the following request: /index.php/abc. QUERY_STRING Contains the entire raw query string defined in the request URL. REMOTE_ADDR Identifies the requester by its IP address. REMOTE_HOST Identifies a host by its domain or IP address. REMOTE_PORT Contains the port defined in the request. REMOTE_USER Identifies the user name of an authenticated user. REQBODY_ERROR Indicates whether an error occurred during the parsing of the request body. Valid values are: • 0: An error was not detected. • 1: Error REQBODY_ERROR_MSG Contains an error message if an error occurred during the parsing of the request body. REQBODY_PROCESSOR Contains the name of the request body parser. REQUEST_BASENAME Identifies the file name of the requested content. REQUEST_BODY Contains the raw request body. REQUEST_BODY_LENGTH Contains the size of the request body in bytes. REQUEST_COOKIES Contains the set of request cookie values. REQUEST_COOKIES_NAMES Contains the set of request cookie names. REQUEST_FILENAME Identifies the request's file name. This value does not include query strings.

Web Application Firewall Administration Guide Edgecast Page 52

Variable Scope REQUEST_HEADERS Contains a set of request header values. REQUEST_HEADERS_NAMES Contains a set of request header names. REQUEST_LINE Contains the request method, URL, and HTTP version. REQUEST_METHOD Contains the request method. REQUEST_PROTOCOL Contains the request's HTTP version. REQUEST_URI Contains the request URL starting directly after the domain. REQUEST_URI_RAW Contains the raw request URL. SESSION Contains session information. STREAM_INPUT_BODY Contains the raw request body. TX Contains transaction information and transaction anomaly score. URLENCODED_ERROR Indicates that invalid URL encoding was detected. USERAGENT_IP Indicates the IP address from which the request originated. WEBSERVER_ERROR_LOG Contains zero or more error messages.

Web Application Firewall Administration Guide Edgecast Page 53