**Introducing a new console experience for AWS WAF**

You can now use the updated experience to access AWS WAF functionality anywhere in the console. For more details, see [Working with the console](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html). 

# AWS WAF Classic
<a name="classic-waf-chapter"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

AWS WAF Classic is a web application firewall that lets you monitor the HTTP and HTTPS requests that are forwarded to an Amazon API Gateway API, Amazon CloudFront or an Application Load Balancer. AWS WAF Classic also lets you control access to your content. Based on conditions that you specify, such as the IP addresses that requests originate from or the values of query strings, API Gateway, CloudFront or an Application Load Balancer responds to requests either with the requested content or with an HTTP 403 status code (Forbidden). You also can configure CloudFront to return a custom error page when a request is blocked.

**Topics**
+ [Setting up AWS WAF Classic](classic-setting-up-waf.md)
+ [How AWS WAF Classic works](classic-how-aws-waf-works.md)
+ [AWS WAF Classic pricing](classic-aws-waf-pricing.md)
+ [Getting started with AWS WAF Classic](classic-getting-started.md)
+ [Creating and configuring a Web Access Control List (Web ACL)](classic-web-acl.md)
+ [Working with AWS WAF Classic rule groups for use with AWS Firewall Manager](classic-working-with-rule-groups.md)
+ [Getting started with AWS Firewall Manager to enable AWS WAF Classic rules](classic-getting-started-fms.md)
+ [Tutorial: Creating an AWS Firewall Manager policy with hierarchical rules](hierarchical-rules.md)
+ [Logging Web ACL traffic information](classic-logging.md)
+ [Listing IP addresses blocked by rate-based rules](classic-listing-managed-ips.md)
+ [How AWS WAF Classic works with Amazon CloudFront features](classic-cloudfront-features.md)
+ [Security in AWS WAF Classic](classic-security.md)
+ [AWS WAF Classic quotas](classic-limits.md)

# Setting up AWS WAF Classic
<a name="classic-setting-up-waf"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

This topic describes preliminary steps, such as creating a user account, to prepare you to use AWS WAF Classic. You aren't charged for these. You are charged only for AWS services that you use. 

**Note**  
If you're a new user to AWS WAF, don't follow these setup steps for AWS WAF Classic. Instead, follow the steps for the latest version of AWS WAF, at [Setting up your account to use the services](setting-up-waf.md). 

After you complete these steps, see [Getting started with AWS WAF Classic](classic-getting-started.md) to continue getting started with AWS WAF Classic.

**Note**  
AWS Shield Standard is included with AWS WAF Classic and does not require additional setup. For more information, see [How AWS Shield and Shield Advanced work](ddos-overview.md).

Before you use AWS WAF Classic or AWS Shield Advanced for the first time, complete the steps in this section. 

**Topics**
+ [Sign up for an AWS account](#sign-up-for-aws)
+ [Create a user with administrative access](#create-an-admin)
+ [Download tools](#classic-setting-up-waf-tools)

## Sign up for an AWS account
<a name="sign-up-for-aws"></a>

If you do not have an AWS account, complete the following steps to create one.

**To sign up for an AWS account**

1. Open [https://portal.aws.amazon.com/billing/signup](https://portal.aws.amazon.com/billing/signup).

1. Follow the online instructions.

   Part of the sign-up procedure involves receiving a phone call or text message and entering a verification code on the phone keypad.

   When you sign up for an AWS account, an *AWS account root user* is created. The root user has access to all AWS services and resources in the account. As a security best practice, assign administrative access to a user, and use only the root user to perform [tasks that require root user access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks).

AWS sends you a confirmation email after the sign-up process is complete. At any time, you can view your current account activity and manage your account by going to [https://aws.amazon.com/](https://aws.amazon.com/) and choosing **My Account**.

## Create a user with administrative access
<a name="create-an-admin"></a>

After you sign up for an AWS account, secure your AWS account root user, enable AWS IAM Identity Center, and create an administrative user so that you don't use the root user for everyday tasks.

**Secure your AWS account root user**

1.  Sign in to the [AWS Management Console](https://console.aws.amazon.com/) as the account owner by choosing **Root user** and entering your AWS account email address. On the next page, enter your password.

   For help signing in by using root user, see [Signing in as the root user](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html#introduction-to-root-user-sign-in-tutorial) in the *AWS Sign-In User Guide*.

1. Turn on multi-factor authentication (MFA) for your root user.

   For instructions, see [Enable a virtual MFA device for your AWS account root user (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/enable-virt-mfa-for-root.html) in the *IAM User Guide*.

**Create a user with administrative access**

1. Enable IAM Identity Center.

   For instructions, see [Enabling AWS IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-set-up-for-idc.html) in the *AWS IAM Identity Center User Guide*.

1. In IAM Identity Center, grant administrative access to a user.

   For a tutorial about using the IAM Identity Center directory as your identity source, see [ Configure user access with the default IAM Identity Center directory](https://docs.aws.amazon.com//singlesignon/latest/userguide/quick-start-default-idc.html) in the *AWS IAM Identity Center User Guide*.

**Sign in as the user with administrative access**
+ To sign in with your IAM Identity Center user, use the sign-in URL that was sent to your email address when you created the IAM Identity Center user.

  For help signing in using an IAM Identity Center user, see [Signing in to the AWS access portal](https://docs.aws.amazon.com/signin/latest/userguide/iam-id-center-sign-in-tutorial.html) in the *AWS Sign-In User Guide*.

**Assign access to additional users**

1. In IAM Identity Center, create a permission set that follows the best practice of applying least-privilege permissions.

   For instructions, see [ Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/get-started-create-a-permission-set.html) in the *AWS IAM Identity Center User Guide*.

1. Assign users to a group, and then assign single sign-on access to the group.

   For instructions, see [ Add groups](https://docs.aws.amazon.com//singlesignon/latest/userguide/addgroups.html) in the *AWS IAM Identity Center User Guide*.

## Download tools
<a name="classic-setting-up-waf-tools"></a>

The AWS Management Console includes a console for AWS WAF Classic, but if you want to access AWS WAF Classic programmatically, see the following:
+ If you want to call the AWS WAF Classic API without having to handle low-level details like assembling raw HTTP requests, you can use an AWS SDK. The AWS SDKs provide functions and data types that encapsulate the functionality of AWS WAF Classic and other AWS services. To download an AWS SDK, see the applicable page, which also includes prerequisites and installation instructions:
  + [Java](https://aws.amazon.com/sdk-for-java/)
  + [JavaScript](http://aws.amazon.com/sdkforbrowser/)
  + [.NET](https://aws.amazon.com/sdk-for-net/)
  + [Node.js](https://aws.amazon.com/sdk-for-node-js/)
  + [PHP](https://aws.amazon.com/sdk-for-php/)
  + [Python](https://github.com/boto/boto)
  + [Ruby](https://aws.amazon.com/sdk-for-ruby/)

  For a complete list of AWS SDKs, see [Tools for Amazon Web Services](http://aws.amazon.com/tools/).
+ If you're using a programming language for which AWS doesn't provide an SDK, the [AWS WAF API Reference](https://docs.aws.amazon.com/waf/latest/APIReference/) documents the operations that AWS WAF Classic supports. 
+ The AWS Command Line Interface (AWS CLI) supports AWS WAF Classic. The AWS CLI lets you control multiple AWS services from the command line and automate them through scripts. For more information, see [AWS Command Line Interface](https://aws.amazon.com/cli/).
+ AWS Tools for Windows PowerShell supports AWS WAF Classic. For more information, see [AWS Tools for PowerShell Cmdlet Reference](http://aws.amazon.com/documentation/powershell/).

# How AWS WAF Classic works
<a name="classic-how-aws-waf-works"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

You use AWS WAF Classic to control how API Gateway, Amazon CloudFront or an Application Load Balancer responds to web requests. You start by creating conditions, rules, and web access control lists (web ACLs). You define your conditions, combine your conditions into rules, and combine the rules into a web ACL.

**Note**  
You can also use AWS WAF Classic to protect your applications that are hosted in Amazon Elastic Container Service (Amazon ECS) containers. Amazon ECS is a highly scalable, fast container management service that makes it easy to run, stop, and manage Docker containers on a cluster. To use this option, you configure Amazon ECS to use an AWS WAF Classic enabled Application Load Balancer to route and protect HTTP/HTTPS (layer 7) traffic across the tasks in your service. For more information, see the topic [Service Load Balancing](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html) in the *Amazon Elastic Container Service Developer Guide*.

**Conditions**  
Conditions define the basic characteristics that you want AWS WAF Classic to watch for in web requests:  
+ Scripts that are likely to be malicious. Attackers embed scripts that can exploit vulnerabilities in web applications. This is known as *cross-site scripting*.
+ IP addresses or address ranges that requests originate from.
+ Country or geographical location that requests originate from.
+ Length of specified parts of the request, such as the query string.
+ SQL code that is likely to be malicious. Attackers try to extract data from your database by embedding malicious SQL code in a web request. This is known as *SQL injection*.
+ Strings that appear in the request, for example, values that appear in the `User-Agent` header or text strings that appear in the query string. You can also use regular expressions (regex) to specify these strings.
Some conditions take multiple values. For example, you can specify up to 10,000 IP addresses or IP address ranges in an IP condition.

**Rules**  
You combine conditions into rules to precisely target the requests that you want to allow, block, or count. AWS WAF Classic provides two types of rules:    
Regular rule  
Regular rules use only conditions to target specific requests. For example, based on recent requests that you've seen from an attacker, you might create a rule that includes the following conditions:   
+ The requests come from 192.0.2.44.
+ They contain the value `BadBot` in the `User-Agent` header.
+ They appear to include SQL-like code in the query string.
When a rule includes multiple conditions, as in this example, AWS WAF Classic looks for requests that match all conditions—that is, it `AND`s the conditions together.   
Add at least one condition to a regular rule. A regular rule without conditions can't match any requests, so the rule's action (allow, count, or block) is never triggered.   
Rate-based rule  
Rate-based rules are like regular rules with an added rate limit. A rate-based rule counts the requests that arrive from IP addresses that satisfy the rule's conditions. If the requests from an IP address exceed the rate limit in a five-minute period, the rule can trigger an action. It can take a minute or two for the action to trigger.   
Conditions are optional for rate-based rules. If you don't add any conditions in a rate-based rule, the rate limit applies to all IP addresses. If you combine conditions with the rate limit, the rate limit applies to IP addresses that match the conditions.   
For example, based on recent requests that you've seen from an attacker, you might create a rate-based rule that includes the following conditions:   
+ The requests come from 192.0.2.44.
+ They contain the value `BadBot` in the `User-Agent` header.
In this rate-based rule, you also define a rate limit. In this example, let's say that you create a rate limit of 1,000. Requests that meet both of the preceding conditions and exceed 1,000 requests per five minutes trigger the rule's action (block or count), which is defined in the web ACL.  
Requests that don't meet both conditions aren't counted towards the rate limit and aren't affected by this rule.  
As a second example, suppose that you want to limit requests to a particular page on your website. To do this, you could add the following string match condition to a rate-based rule:  
+ The **Part of the request to filter on** is `URI`.
+ The **Match Type** is `Starts with`. 
+ A **Value to match** is `login`. 
Further, you specify a `RateLimit` of 1,000.  
By adding this rate-based rule to a web ACL, you could limit requests to your login page without affecting the rest of your site.

**Web ACLs**  
After you combine your conditions into rules, you combine the rules into a web ACL. This is where you define an action for each rule—allow, block, or count—and a default action:    
**An action for each rule**  
When a web request matches all the conditions in a rule, AWS WAF Classic can either block the request or allow the request to be forwarded to the API Gateway API, CloudFront distribution or an Application Load Balancer. You specify the action that you want AWS WAF Classic to perform for each rule.  
AWS WAF Classic compares a request with the rules in a web ACL in the order in which you listed the rules. AWS WAF Classic then takes the action that is associated with the first rule that the request matches. For example, if a web request matches one rule that allows requests and another rule that blocks requests, AWS WAF Classic will either allow or block the request depending on which rule is listed first.  
If you want to test a new rule before you start using it, you also can configure AWS WAF Classic to count the requests that meet all the conditions in the rule. As with rules that allow or block requests, a rule that counts requests is affected by its position in the list of rules in the web ACL. For example, if a web request matches a rule that allows requests and another rule that counts requests, and if the rule that allows requests is listed first, the request isn't counted.   
**A default action**  
The default action determines whether AWS WAF Classic allows or blocks a request that doesn't match all the conditions in any of the rules in the web ACL. For example, suppose you create a web ACL and add only the rule that you defined before:  
+ The requests come from 192.0.2.44.
+ They contain the value `BadBot` in the `User-Agent` header.
+ They appear to include malicious SQL code in the query string.
If a request doesn't meet all three conditions in the rule and if the default action is `ALLOW`, AWS WAF Classic forwards the request to API Gateway, CloudFront or an Application Load Balancer, and the service responds with the requested object.  
If you add two or more rules to a web ACL, AWS WAF Classic performs the default action only if a request doesn't satisfy all the conditions in any of the rules. For example, suppose you add a second rule that contains one condition:  
+ Requests that contain the value `BIGBadBot` in the `User-Agent` header.
AWS WAF Classic performs the default action only when a request doesn't meet all three conditions in the first rule and doesn't meet the one condition in the second rule.
On some occasions, AWS WAF might encounter an internal error that delays the response to Amazon API Gateway, Amazon CloudFront or an Application Load Balancer about whether to allow or block a request. On those occasions CloudFront will typically allow the request or serve the content. API Gateway and an Application Load Balancer typically will deny the request and not serve the content.

# AWS WAF Classic pricing
<a name="classic-aws-waf-pricing"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

With AWS WAF Classic, you pay only for the web ACLs and rules that you create, and for the number of HTTP requests that AWS WAF Classic inspects. For more information, see [AWS WAF Classic Pricing](http://aws.amazon.com/waf/pricing/). 

# Getting started with AWS WAF Classic
<a name="classic-getting-started"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

This tutorial shows how to use AWS WAF Classic to perform the following tasks:
+ Set up AWS WAF Classic.
+ Create a web access control list (web ACL) using the AWS WAF Classic console, and specify the conditions that you want to use to filter web requests. For example, you can specify the IP addresses that the requests originate from and values in the request that are used only by attackers.
+ Add the conditions to a rule. Rules let you target the web requests that you want to block or allow. A web request must match all the conditions in a rule before AWS WAF Classic blocks or allows requests based on the conditions that you specify.
+ Add the rules to your web ACL. This is where you specify whether you want to block web requests or allow them based on the conditions that you add to each rule.
+ Specify a default action, either block or allow. This is the action that AWS WAF Classic takes when a web request doesn't match any of your rules.
+ Choose the Amazon CloudFront distribution that you want AWS WAF Classic to inspect web requests for. This tutorial covers the steps only for CloudFront, but the process for an Application Load Balancer and Amazon API Gateway APIs essentially is the same. AWS WAF Classic for CloudFront is available for all AWS Regions. AWS WAF Classic for use with API Gateway or an Application Load Balancer is available in the Regions listed at [AWS service endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html). 

**Note**  
AWS typically bills you less than US \$10.25 per day for the resources that you create during this tutorial. When you're finished with the tutorial, we recommend that you delete the resources to prevent incurring unnecessary charges. 

**Topics**
+ [Step 1: Set up AWS WAF Classic](#classic-getting-started-aws-account)
+ [Step 2: Create a Web ACL](#classic-getting-started-wizard-create-web-acl)
+ [Step 3: Create an IP match condition](#classic-getting-started-wizard-create-ip-condition)
+ [Step 4: Create a geo match condition](#classic-getting-started-wizard-create-geo-condition)
+ [Step 5: Create a string match condition](#classic-getting-started-wizard-create-string-condition)
+ [Step 5A: Create a regex condition (optional)](#classic-getting-started-wizard-create-regex-condition)
+ [Step 6: Create a SQL injection match condition](#classic-getting-started-wizard-create-sql-condition)
+ [Step 7: (Optional) create additional conditions](#classic-getting-started-wizard-create-optional-conditions)
+ [Step 8: Create a rule and add conditions](#classic-getting-started-wizard-create-rule)
+ [Step 9: Add the rule to a Web ACL](#classic-getting-started-wizard-add-rule)
+ [Step 10: Clean up your resources](#classic-getting-started-wizard-clean-up)

## Step 1: Set up AWS WAF Classic
<a name="classic-getting-started-aws-account"></a>

If you haven't already followed the general setup steps in [Setting up AWS WAF Classic](classic-setting-up-waf.md), do that now. 

## Step 2: Create a Web ACL
<a name="classic-getting-started-wizard-create-web-acl"></a>

The AWS WAF Classic console guides you through the process of configuring AWS WAF Classic to block or allow web requests based on conditions that you specify, such as the IP addresses that the requests originate from or values in the requests. In this step, you create a web ACL.<a name="classic-getting-started-wizard-create-web-acl-procedure"></a>

**To create a web ACL**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. If this is your first time using AWS WAF Classic, choose **Go to AWS WAF Classic**, and then choose **Configure web ACL**. 

   If you've used AWS WAF Classic before, choose **Web ACLs** in the navigation pane, and then choose **Create web ACL**.

1. On the **Name web ACL** page, for **Web ACL name**, enter a name. 
**Note**  
You can't change the name after you create the web ACL.

1. For **CloudWatch metric name**, enter a name. The name can contain only alphanumeric characters (A-Z, a-z, 0-9). It can't contain white space.
**Note**  
You can't change the name after you create the web ACL.

1. For **Region**, choose a Region. If you will associate this web ACL with a CloudFront distribution, choose **Global (CloudFront)**. 

1. For **AWS resource to associate**, choose the resource that you want to associate with your web ACL, and then choose **Next**.

## Step 3: Create an IP match condition
<a name="classic-getting-started-wizard-create-ip-condition"></a>

An IP match condition specifies the IP addresses or IP address ranges that requests originate from. In this step, you create an IP match condition. In a later step, you specify whether you want to allow requests or block requests that originate from the specified IP addresses.

**Note**  
For more information about IP match conditions, see [Working with IP match conditions](classic-web-acl-ip-conditions.md).<a name="classic-getting-started-wizard-create-ip-condition-procedure"></a>

**To create an IP match condition**

1. On the **Create conditions** page, for **IP match conditions**, choose **Create condition**.

1. In the **Create IP match condition** dialog box, for **Name**, enter a name. The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: \$1-\$1"\$1`\$1\$1\$1,./ .

1. For **Address**, enter **192.0.2.0/24**. This IP address range, specified in CIDR notation, includes the IP addresses from 192.0.2.0 to 192.0.2.255. (The 192.0.2.0/24 IP address range is reserved for examples, so no web requests will originate from these IP addresses.)

   AWS WAF Classic supports IPv4 address ranges: /8 and any range between /16 through /32. AWS WAF Classic supports IPv6 address ranges: /24, /32, /48, /56, /64, and /128. (To specify a single IP address, such as 192.0.2.44, enter **192.0.2.44/32**.) Other ranges aren't supported.

   For more information about CIDR notation, see the Wikipedia article [Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing).

1. Choose **Create**.

## Step 4: Create a geo match condition
<a name="classic-getting-started-wizard-create-geo-condition"></a>

A geo match condition specifies the country or countries that requests originate from. In this step, you create a geo match condition. In a later step, you specify whether you want to allow requests or block requests that originate from the specified countries.

**Note**  
For more information about geo match conditions, see [Working with geographic match conditions](classic-web-acl-geo-conditions.md).<a name="classic-getting-started-wizard-create-geo-condition-procedure"></a>

**To create a geo match condition**

1. On the **Create conditions** page, for **Geo match conditions**, choose **Create condition**.

1. In the **Create geo match condition** dialog box, for **Name**, enter a name. The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: \$1-\$1"\$1`\$1\$1\$1,./ . 

1. Choose a **Location type** and a country. Currently, **Location type** can only be **Country**.

1. Choose **Add location**.

1. Choose **Create**.

## Step 5: Create a string match condition
<a name="classic-getting-started-wizard-create-string-condition"></a>

A string match condition identifies the strings that you want AWS WAF Classic to search for in a request, such as a specified value in a header or in a query string. Usually, a string consists of printable ASCII characters, but you can specify any character from hexadecimal 0x00 to 0xFF (decimal 0 to 255). In this step, you create a string match condition. In a later step, you specify whether you want to allow or block requests that contain the specified strings.

**Note**  
For more information about string match conditions, see [Working with string match conditions](classic-web-acl-string-conditions.md).<a name="classic-getting-started-wizard-create-string-condition-procedure"></a>

**To create a string match condition**

1. On the **Create conditions** page, for **String and regex match conditions**, choose **Create condition**.

1. In the **Create string match condition** dialog box, enter the following values:  
**Name**  
Enter a name. The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: \$1-\$1"\$1`\$1\$1\$1,./ .  
**Type**  
Choose **String match**.  
**Part of the request to filter on**  
Choose the part of the web request that you want AWS WAF Classic to inspect for a specified string.   
For this example, choose **Header**.  
If you choose **Body** for the value of **Part of the request to filter on**, AWS WAF Classic inspects only the first 8192 bytes (8 KB) because CloudFront forwards only the first 8192 bytes for inspection. To allow or block requests for which the body is longer than 8192 bytes, you can create a size constraint condition. (AWS WAF Classic gets the length of the body from the request headers.) For more information, see [Working with size constraint conditions](classic-web-acl-size-conditions.md).  
**Header (Required if "Part of the request to filter on" is "Header")**  
Because you chose **Header** for **Part of the request to filter on**, you must specify which header you want AWS WAF Classic to inspect. Enter **User-Agent**. (This value is not case sensitive.)  
**Match type**  
Choose where the specified string must appear in the **User-Agent** header, for example, at the beginning, at the end, or anywhere in the string.   
For this example, choose **Exactly matches**, which indicates that AWS WAF Classic inspects web requests for a header value that is identical to the value that you specify.  
**Transformation**  
In an effort to bypass AWS WAF Classic, attackers use unusual formatting in web requests, for example, by adding white space or by URL-encoding some or all of the request. Transformations convert the web request to a more standard format by removing white space, by URL-decoding the request, or by performing other operations that eliminate much of the unusual formatting that attackers commonly use.  
You can only specify a single type of text transformation.  
For this example, choose **None**.  
**Value is base64 encoded**  
When the value that you enter in **Value to match** is already base64-encoded, select this check box.   
For this example, don't select the check box.  
**Value to match**  
Specify the value that you want AWS WAF Classic to search for in the part of web requests that you indicated in **Part of the request to filter on**.  
For this example, enter **BadBot**. AWS WAF Classic will inspect the `User-Agent` header in web requests for the value **BadBot**.  
The maximum length of **Value to match** is 50 characters. If you want to specify a base64-encoded value, you can provide up to 50 characters before encoding.

1. If you want AWS WAF Classic to inspect web requests for multiple values, such as a `User-Agent` header that contains `BadBot` and a query string that contains `BadParameter`, you have two choices:
   + If you want to allow or block web requests only when they contain both values (`AND`), you create one string match condition for each value. 
   + If you want to allow or block web requests when they contain either value or both (`OR`), you add both values to the same string match condition. 

   For this example, choose **Create**.

## Step 5A: Create a regex condition (optional)
<a name="classic-getting-started-wizard-create-regex-condition"></a>

A regular expression condition is a type of string match condition and similar in that it identifies the strings that you want AWS WAF Classic to search for in a request, such as a specified value in a header or in a query string. The primary difference is that you use a regular expression (regex) to specify the string pattern that you want AWS WAF Classic to search for. In this step, you create a regex match condition. In a later step, you specify whether you want to allow or block requests that contain the specified strings.

**Note**  
For more information about regex match conditions, see [Working with regex match conditions](classic-web-acl-regex-conditions.md).<a name="classic-getting-started-wizard-create-regex-condition-procedure"></a>

**To create a regex match condition**

1. On the **Create conditions** page, for **String match and regex conditions**, choose **Create condition**.

1. In the **Create string match condition** dialog box, enter the following values:  
**Name**  
Enter a name. The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: \$1-\$1"\$1`\$1\$1\$1,./ .  
**Type**  
Choose **Regex match**.  
**Part of the request to filter on**  
Choose the part of the web request that you want AWS WAF Classic to inspect for a specified string.   
For this example, choose **Body**.  
If you choose **Body** for the value of **Part of the request to filter on**, AWS WAF Classic inspects only the first 8192 bytes (8 KB) because CloudFront forwards only the first 8192 bytes for inspection. To allow or block requests for which the body is longer than 8192 bytes, you can create a size constraint condition. (AWS WAF Classic gets the length of the body from the request headers.) For more information, see [Working with size constraint conditions](classic-web-acl-size-conditions.md).  
**Transformation**  
In an effort to bypass AWS WAF Classic, attackers use unusual formatting in web requests, for example, by adding white space or by URL-encoding some or all of the request. Transformations convert the web request to a more standard format by removing white space, by URL-decoding the request, or by performing other operations that eliminate much of the unusual formatting that attackers commonly use.  
You can only specify a single type of text transformation.  
For this example, choose **None**.  
**Regex patterns to match to request**  
Choose **Create regex pattern set**.  
**New pattern set name**  
Enter a name and then specify the regex pattern that you want AWS WAF Classic to search for.   
Next, enter the regular expression **I[a@]mAB[a@]dRequest**. AWS WAF Classic will inspect the `User-Agent` header in web requests for the values:  
   + **IamABadRequest**
   + **IamAB@dRequest**
   + **I@mABadRequest**
   + **I@mAB@dRequest**

1. Choose **Create pattern set and add filter**.

1. Choose **Create**.

## Step 6: Create a SQL injection match condition
<a name="classic-getting-started-wizard-create-sql-condition"></a>

A SQL injection match condition identifies the part of web requests, such as a header or a query string, that you want AWS WAF Classic to inspect for malicious SQL code. Attackers use SQL queries to extract data from your database. In this step, you create a SQL injection match condition. In a later step, you specify whether you want to allow requests or block requests that appear to contain malicious SQL code.

**Note**  
For more information about string match conditions, see [Working with SQL injection match conditions](classic-web-acl-sql-conditions.md).<a name="classic-getting-started-wizard-create-sql-condition-procedure"></a>

**To create a SQL injection match condition**

1. On the **Create conditions** page, for **SQL injection match conditions**, choose **Create condition**.

1. In the **Create SQL injection match condition** dialog box, enter the following values:  
**Name**  
Enter a name.  
**Part of the request to filter on**  
Choose the part of web requests that you want AWS WAF Classic to inspect for malicious SQL code.   
For this example, choose **Query string**.  
If you choose **Body** for the value of **Part of the request to filter on**, AWS WAF Classic inspects only the first 8192 bytes (8 KB) because CloudFront forwards only the first 8192 bytes for inspection. To allow or block requests for which the body is longer than 8192 bytes, you can create a size constraint condition. (AWS WAF Classic gets the length of the body from the request headers.) For more information, see [Working with size constraint conditions](classic-web-acl-size-conditions.md).  
**Transformation**  
For this example, choose **URL decode**.  
Attackers use unusual formatting, such as URL encoding, in an effort to bypass AWS WAF Classic. The **URL decode** option eliminates some of that formatting in the web request before AWS WAF Classic inspects the request.  
You can only specify a single type of text transformation.

1. Choose **Create**.

1. Choose **Next**. 

## Step 7: (Optional) create additional conditions
<a name="classic-getting-started-wizard-create-optional-conditions"></a>

AWS WAF Classic includes other conditions, including the following:
+ **Size constraint conditions** – Identifies the part of web requests, such as a header or a query string, that you want AWS WAF Classic to check for length. For more information, see [Working with size constraint conditions](classic-web-acl-size-conditions.md).
+ **Cross-site scripting match conditions** – Identifies the part of web requests, such as a header or a query string, that you want AWS WAF to inspect for malicious scripts. For more information, see [Working with cross-site scripting match conditions](classic-web-acl-xss-conditions.md).

You can optionally create these conditions now, or you can skip to [Step 8: Create a rule and add conditions](#classic-getting-started-wizard-create-rule).

## Step 8: Create a rule and add conditions
<a name="classic-getting-started-wizard-create-rule"></a>

You create a rule to specify the conditions that you want AWS WAF Classic to search for in web requests. If you add more than one condition to a rule, a web request must match all the conditions in the rule for AWS WAF Classic to allow or block requests based on that rule.

**Note**  
For more information about rules, see [Working with rules](classic-web-acl-rules.md).<a name="classic-getting-started-wizard-create-rule-procedure"></a>

**To create a rule and add conditions**

1. On the **Create rules** page, choose **Create rule**.

1. In the **Create rule** dialog box, enter the following values:  
**Name**  
Enter a name.   
**CloudWatch metric name**  
Enter a name for the CloudWatch metric that AWS WAF Classic will create and will associate with the rule. The name can contain only alphanumeric characters (A-Z, a-z, 0-9). It can't contain white space.  
**Rule type**  
Choose either **Regular rule** or **Rate-based rule**. Rate-based rules are identical to regular rules but also take into account how many requests arrive from the identified IP address in any five-minute period. For more information about the rule types, see [How AWS WAF Classic works](classic-how-aws-waf-works.md). For this example, choose `Regular rule`.  
**Rate limit**  
For a rate-based rule, enter the maximum number of requests to allow in any five-minute period from an IP address that matches the rule's conditions.

1. For the first condition that you want to add to the rule, specify the following settings:
   + Choose whether you want AWS WAF Classic to allow or block requests based on whether a web request does or does not match the settings in the condition.

     For this example, choose **does**.
   + Choose the type of condition that you want to add to the rule: an IP match set condition, a string match set condition, or a SQL injection match set condition.

     For this example, choose **originate from IP addresses in**.
   + Choose the condition that you want to add to the rule.

     For this example, choose the IP match condition that you created in previous tasks.

1. Choose **Add condition**.

1. Add the geo match condition that you created earlier. Specify the following values:
   + **When a request does**
   + **originate from a geographic location in**
   + Choose your geo match condition.

1. Choose **Add another condition**.

1. Add the string match condition that you created earlier. Specify the following values:
   + **When a request does**
   + **match at least one of the filters in the string match condition**
   + Choose your string match condition.

1. Choose **Add condition**.

1. Add the SQL injection match condition that you created earlier. Specify the following values:
   + **When a request does**
   + **match at least one of the filters in the SQL injection match condition**
   + Choose your SQL injection match condition.

1. Choose **Add condition**.

1. Add the size constraint condition that you created earlier. Specify the following values:
   + **When a request does**
   + **match at least one of the filters in the size constraint condition**
   + Choose your size constraint condition.

1. If you created any other conditions, such as a regex condition, add those in a similar manner.

1. Choose **Create**. 

1. For the **Default action**, choose **Allow all requests that don't match any rules**. 

1. Choose **Review and create**. 

## Step 9: Add the rule to a Web ACL
<a name="classic-getting-started-wizard-add-rule"></a>

When you add the rule to a web ACL, you specify the following settings:
+ The action that you want AWS WAF Classic to take on web requests that match all the conditions in the rule: allow, block, or count the requests.
+ The default action for the web ACL. This is the action that you want AWS WAF Classic to take on web requests that *do not* match all the conditions in the rule: allow or block the requests.

AWS WAF Classic starts blocking CloudFront web requests that match all the following conditions (and any others you might have added):
+ The value of the `User-Agent` header is `BadBot`
+ (If you created and added the regex condition) The value of the `Body` is any of the four strings that matches the pattern `I[a@]mAB[a@]dRequest`
+ The requests originate from IP addresses in the range 192.0.2.0-192.0.2.255
+ The requests originate from the country that you selected in your geo match condition
+ The requests appear to include malicious SQL code in the query string

AWS WAF Classic allows CloudFront to respond to any requests that don't meet all three of these conditions. 

## Step 10: Clean up your resources
<a name="classic-getting-started-wizard-clean-up"></a>

You've now successfully completed the tutorial. To prevent your account from accruing additional AWS WAF Classic charges, you should clean up the AWS WAF Classic objects that you created. Alternatively, you can change the configuration to match the web requests that you really want to allow, block, and count.

**Note**  
AWS typically bills you less than US \$10.25 per day for the resources that you create during this tutorial. When you're finished, we recommend that you delete the resources to prevent incurring unnecessary charges. <a name="classic-getting-started-wizard-clean-up-procedure"></a>

**To delete the objects that AWS WAF Classic charges for**

1. Disassociate your web ACL from your CloudFront distribution:

   1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

      If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

   1. Choose the name of the web ACL that you want to delete. This opens a page with the web ACL's details in the right pane. 

   1. In the right pane, on the **Rules** tab, go to the **AWS resources using this web ACL** section. For the CloudFront distribution that you associated the web ACL with, choose the **x** in the **Type** column. 

1. Remove the conditions from your rule:

   1. In the navigation pane, choose **Rules**.

   1. Choose the rule that you created during the tutorial.

   1. Choose **Edit rule**. 

   1. Choose the **x** at the right of each condition heading.

   1. Choose **Update**.

1. Remove the rule from your web ACL, and delete the web ACL:

   1. In the navigation pane, choose **Web ACLs**.

   1. Choose the name of the web ACL that you created during the tutorial. This opens a page with the web ACL's details in the right pane.

   1. On the **Rules** tab, choose **Edit web ACL**. 

   1. Choose the **x** at the right of the rule heading.

   1. Choose **Actions**, and then choose **Delete web ACL**.

1. Delete your rule:

   1. In the navigation pane, choose **Rules**.

   1. Choose the rule that you created during the tutorial.

   1. Choose **Delete**.

   1. In the **Delete** dialog box, choose **Delete** again to confirm.

AWS WAF Classic doesn't charge for conditions, but if you want to complete the cleanup, perform the following procedure to remove filters from conditions and delete the conditions.<a name="classic-getting-started-wizard-clean-up-conditions-procedure"></a>

**To delete filters and conditions**

1. Delete the IP address range in your IP match condition, and delete the IP match condition:

   1. In the navigation pane of the AWS WAF Classic console, choose **IP addresses**.

   1. Choose the IP match condition that you created during the tutorial.

   1. Select the check box for the IP address range that you added. 

   1. Choose **Delete IP address or range**.

   1. In the **IP match conditions** pane, choose **Delete**.

   1. In the **Delete** dialog box, choose **Delete** again to confirm.

1. Delete the filter in your SQL injection match condition, and delete the SQL injection match condition:

   1. In the navigation pane, choose **SQL injection**.

   1. Choose the SQL injection match condition that you created during the tutorial.

   1. Select the check box for the filter that you added. 

   1. Choose **Delete filter**.

   1. In the **SQL injection match conditions** pane, choose **Delete**.

   1. In the **Delete** dialog box, choose **Delete** again to confirm.

1. Delete the filter in your string match condition, and delete the string match condition:

   1. In the navigation pane, choose **String and regex matching**.

   1. Choose the string match condition that you created during the tutorial.

   1. Select the check box for the filter that you added. 

   1. Choose **Delete filter**.

   1. In the **String match conditions** pane, choose **Delete**.

   1. In the **Delete** dialog box, choose **Delete** again to confirm.

1. If you created one, delete the filter in your regex match condition, and delete the regex match condition:

   1. In the navigation pane, choose **String and regex matching**.

   1. Choose the regex match condition that you created during the tutorial.

   1. Select the check box for the filter that you added. 

   1. Choose **Delete filter**.

   1. In the **Regex match conditions** pane, choose **Delete**.

   1. In the **Delete** dialog box, choose **Delete** again to confirm.

1. Delete the filter in your size constraint condition, and delete the size constraint condition:

   1. In the navigation pane, choose **Size constraints**.

   1. Choose the size constraint condition that you created during the tutorial.

   1. Select the check box for the filter that you added. 

   1. Choose **Delete filter**.

   1. In the **Size constraint conditions** pane, choose **Delete**.

   1. In the **Delete** dialog box, choose **Delete** again to confirm.

# Creating and configuring a Web Access Control List (Web ACL)
<a name="classic-web-acl"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

A web access control list (web ACL) gives you fine-grained control over the web requests that your Amazon API Gateway API, Amazon CloudFront distribution or Application Load Balancer responds to. You can allow or block the following types of requests: 
+ Originate from an IP address or a range of IP addresses
+ Originate from a specific country or countries
+ Contain a specified string or match a regular expression (regex) pattern in a particular part of requests
+ Exceed a specified length
+ Appear to contain malicious SQL code (known as SQL injection)
+ Appear to contain malicious scripts (known as cross-site scripting)

You can also test for any combination of these conditions, or block or count web requests that not only meet the specified conditions, but also exceed a specified number of requests in any 5-minute period. 

To choose the requests that you want to allow to have access to your content or that you want to block, perform the following tasks:

1. Choose the default action, allow or block, for web requests that don't match any of the conditions that you specify. For more information, see [Deciding on the default action for a Web ACL](classic-web-acl-default-action.md).

1. Specify the conditions under which you want to allow or block requests:
   + To allow or block requests based on whether the requests appear to contain malicious scripts, create cross-site scripting match conditions. For more information, see [Working with cross-site scripting match conditions](classic-web-acl-xss-conditions.md).
   + To allow or block requests based on the IP addresses that they originate from, create IP match conditions. For more information, see [Working with IP match conditions](classic-web-acl-ip-conditions.md).
   + To allow or block requests based on the country that they originate from, create geo match conditions. For more information, see [Working with geographic match conditions](classic-web-acl-geo-conditions.md).
   + To allow or block requests based on whether the requests exceed a specified length, create size constraint conditions. For more information, see [Working with size constraint conditions](classic-web-acl-size-conditions.md).
   + To allow or block requests based on whether the requests appear to contain malicious SQL code, create SQL injection match conditions. For more information, see [Working with SQL injection match conditions](classic-web-acl-sql-conditions.md).
   + To allow or block requests based on strings that appear in the requests, create string match conditions. For more information, see [Working with string match conditions](classic-web-acl-string-conditions.md).
   + To allow or block requests based on a regex pattern that appear in the requests, create regex match conditions. For more information, see [Working with regex match conditions](classic-web-acl-regex-conditions.md).

1. Add the conditions to one or more rules. If you add more than one condition to the same rule, web requests must match all the conditions for AWS WAF Classic to allow or block requests based on the rule. For more information, see [Working with rules](classic-web-acl-rules.md). Optionally, you can use a rate-based rule instead of a regular rule to limit the number of requests from any IP address that meets the conditions.

1. Add the rules to a web ACL. For each rule, specify whether you want AWS WAF Classic to allow or block requests based on the conditions that you added to the rule. If you add more than one rule to a web ACL, AWS WAF Classic evaluates the rules in the order that they're listed in the web ACL. For more information, see [Working with web ACLs](classic-web-acl-working-with.md).

   When you add a new rule or update existing rules, it can take up to one minute for those changes to appear and be active across your web ACLs and resources.

**Topics**
+ [Working with conditions](classic-web-acl-create-condition.md)
+ [Working with rules](classic-web-acl-rules.md)
+ [Working with web ACLs](classic-web-acl-working-with.md)

# Working with conditions
<a name="classic-web-acl-create-condition"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

Conditions specify when you want to allow or block requests.
+ To allow or block requests based on whether the requests appear to contain malicious scripts, create cross-site scripting match conditions. For more information, see [Working with cross-site scripting match conditions](classic-web-acl-xss-conditions.md).
+ To allow or block requests based on the IP addresses that they originate from, create IP match conditions. For more information, see [Working with IP match conditions](classic-web-acl-ip-conditions.md).
+ To allow or block requests based on the country that they originate from, create geo match conditions. For more information, see [Working with geographic match conditions](classic-web-acl-geo-conditions.md).
+ To allow or block requests based on whether the requests exceed a specified length, create size constraint conditions. For more information, see [Working with size constraint conditions](classic-web-acl-size-conditions.md).
+ To allow or block requests based on whether the requests appear to contain malicious SQL code, create SQL injection match conditions. For more information, see [Working with SQL injection match conditions](classic-web-acl-sql-conditions.md).
+ To allow or block requests based on strings that appear in the requests, create string match conditions. For more information, see [Working with string match conditions](classic-web-acl-string-conditions.md).
+ To allow or block requests based on a regex pattern that appear in the requests, create regex match conditions. For more information, see [Working with regex match conditions](classic-web-acl-regex-conditions.md).

**Topics**
+ [Working with cross-site scripting match conditions](classic-web-acl-xss-conditions.md)
+ [Working with IP match conditions](classic-web-acl-ip-conditions.md)
+ [Working with geographic match conditions](classic-web-acl-geo-conditions.md)
+ [Working with size constraint conditions](classic-web-acl-size-conditions.md)
+ [Working with SQL injection match conditions](classic-web-acl-sql-conditions.md)
+ [Working with string match conditions](classic-web-acl-string-conditions.md)
+ [Working with regex match conditions](classic-web-acl-regex-conditions.md)

# Working with cross-site scripting match conditions
<a name="classic-web-acl-xss-conditions"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

Attackers sometimes insert scripts into web requests in an effort to exploit vulnerabilities in web applications. You can create one or more cross-site scripting match conditions to identify the parts of web requests, such as the URI or the query string, that you want AWS WAF Classic to inspect for possible malicious scripts. Later in the process, when you create a web ACL, you specify whether to allow or block requests that appear to contain malicious scripts.

**Topics**
+ [Creating cross-site scripting match conditions](#classic-web-acl-xss-conditions-creating)
+ [Values that you specify when you create or edit cross-site scripting match conditions](#classic-web-acl-xss-conditions-values)
+ [Adding and deleting filters in a cross-site scripting match condition](#classic-web-acl-xss-conditions-editing)
+ [Deleting cross-site scripting match conditions](#classic-web-acl-xss-conditions-deleting)

## Creating cross-site scripting match conditions
<a name="classic-web-acl-xss-conditions-creating"></a>

When you create cross-site scripting match conditions, you specify filters. The filters indicate the part of web requests that you want AWS WAF Classic to inspect for malicious scripts, such as the URI or the query string. You can add more than one filter to a cross-site scripting match condition, or you can create a separate condition for each filter. Here's how each configuration affects AWS WAF Classic behavior:
+ **More than one filter per cross-site scripting match condition (recommended)** – When you add a cross-site scripting match condition that contains multiple filters to a rule and add the rule to a web ACL, a web request must match only one of the filters in the cross-site scripting match condition for AWS WAF Classic to allow or block the request based on that condition.

  For example, suppose you create one cross-site scripting match condition, and the condition contains two filters. One filter instructs AWS WAF Classic to inspect the URI for malicious scripts, and the other instructs AWS WAF Classic to inspect the query string. AWS WAF Classic allows or blocks requests if they appear to contain malicious scripts *either* in the URI *or* in the query string.
+ **One filter per cross-site scripting match condition** – When you add the separate cross-site scripting match conditions to a rule and add the rule to a web ACL, web requests must match all the conditions for AWS WAF Classic to allow or block requests based on the conditions. 

  Suppose you create two conditions, and each condition contains one of the two filters in the preceding example. When you add both conditions to the same rule and add the rule to a web ACL, AWS WAF Classic allows or blocks requests only when both the URI and the query string appear to contain malicious scripts.

**Note**  
When you add a cross-site scripting match condition to a rule, you also can configure AWS WAF Classic to allow or block web requests that *do not* appear to contain malicious scripts.<a name="classic-web-acl-xss-conditions-creating-procedure"></a>

**To create a cross-site scripting match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Cross-site scripting**.

1. Choose **Create condition**.

1. Specify the applicable filter settings. For more information, see [Values that you specify when you create or edit cross-site scripting match conditions](#classic-web-acl-xss-conditions-values).

1. Choose **Add another filter**.

1. If you want to add another filter, repeat steps 4 and 5.

1. When you're done adding filters, choose **Create**.

## Values that you specify when you create or edit cross-site scripting match conditions
<a name="classic-web-acl-xss-conditions-values"></a>

When you create or update a cross-site scripting match condition, you specify the following values: 

**Name**  
The name of the cross-site scripting match condition.  
The name can contain only the characters A-Z, a-z, 0-9, and the special characters: \$1-\$1"\$1`\$1\$1\$1,./ . You can't change the name of a condition after you create it.

**Part of the request to filter on**  
Choose the part of each web request that you want AWS WAF Classic to inspect for malicious scripts:    
**Header**  
A specified request header, for example, the `User-Agent` or `Referer` header. If you choose **Header**, specify the name of the header in the **Header** field.  
**HTTP method**  
The HTTP method, which indicates the type of operation that the request is asking the origin to perform. CloudFront supports the following methods: `DELETE`, `GET`, `HEAD`, `OPTIONS`, `PATCH`, `POST`, and `PUT`.  
**Query string**  
The part of a URL that appears after a `?` character, if any.  
For cross-site scripting match conditions, we recommend that you choose **All query parameters (values only)** instead of **Query string** for **Part of the request to filter on**.  
**URI**  
The URI path of the request, which identifies the resource, for example, `/images/daily-ad.jpg`. This doesn't include the query string or fragment components of the URI. For information, see [Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986#section-3.3).   
Unless a **Transformation** is specified, a URI is not normalized and is inspected just as AWS receives it from the client as part of the request. A **Transformation** will reformat the URI as specified.  
**Body**  
The part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form.  
If you choose **Body** for the value of **Part of the request to filter on**, AWS WAF Classic inspects only the first 8192 bytes (8 KB). To allow or block requests for which the body is longer than 8192 bytes, you can create a size constraint condition. (AWS WAF Classic gets the length of the body from the request headers.) For more information, see [Working with size constraint conditions](classic-web-acl-size-conditions.md).  
**Single query parameter (value only)**  
Any parameter that you have defined as part of the query string. For example, if the URL is "www.xyz.com?UserName=abc&SalesRegion=seattle" you can add a filter to either the *UserName* or *SalesRegion* parameter.   
If you choose **Single query parameter (value only)**, you will also specify a **Query parameter name**. This is the parameter in the query string that you will inspect, such as *UserName* or *SalesRegion*. The maximum length for **Query parameter name** is 30 characters. **Query parameter name** is not case sensitive. For example, it you specify *UserName* as the **Query parameter name**, this will match all variations of *UserName*, such as *username* and *UsERName*.  
**All query parameters (values only)**  
Similar to **Single query parameter (value only)**, but rather than inspecting the values of a single parameter, AWS WAF Classic inspects all parameter values within the query string for possible malicious scripts. For example, if the URL is "www.xyz.com?UserName=abc&SalesRegion=seattle," and you choose **All query parameters (values only)**, AWS WAF Classic will trigger a match if either the value of *UserName* or *SalesRegion* contain possible malicious scripts. 

**Header**  
If you chose **Header** for **Part of the request to filter on**, choose a header from the list of common headers, or enter the name of a header that you want AWS WAF Classic to inspect for malicious scripts.

**Transformation**  
A transformation reformats a web request before AWS WAF Classic inspects the request. This eliminates some of the unusual formatting that attackers use in web requests in an effort to bypass AWS WAF Classic.   
You can only specify a single type of text transformation.  
Transformations can perform the following operations:    
**None**  
AWS WAF Classic doesn't perform any text transformations on the web request before inspecting it for the string in **Value to match**.  
**Convert to lowercase**  
AWS WAF Classic converts uppercase letters (A-Z) to lowercase (a-z).  
**HTML decode**  
AWS WAF Classic replaces HTML-encoded characters with unencoded characters:  
+ Replaces `&quot;` with `&`
+ Replaces `&nbsp;` with a non-breaking space
+ Replaces `&lt;` with `<`
+ Replaces `&gt;` with `>`
+ Replaces characters that are represented in hexadecimal format, `&#xhhhh;`, with the corresponding characters
+ Replaces characters that are represented in decimal format, `&#nnnn;`, with the corresponding characters  
**Normalize white space**  
AWS WAF Classic replaces the following characters with a space character (decimal 32):  
+ \$1f, formfeed, decimal 12
+ \$1t, tab, decimal 9
+ \$1n, newline, decimal 10
+ \$1r, carriage return, decimal 13
+ \$1v, vertical tab, decimal 11
+ non-breaking space, decimal 160
In addition, this option replaces multiple spaces with one space.  
**Simplify command line**  
For requests that contain operating system command line commands, use this option to perform the following transformations:  
+ Delete the following characters: \$1 " ' ^
+ Delete spaces before the following characters: / (
+ Replace the following characters with a space: , ;
+ Replace multiple spaces with one space
+ Convert uppercase letters (A-Z) to lowercase (a-z)  
**URL decode**  
Decode a URL-encoded request.

## Adding and deleting filters in a cross-site scripting match condition
<a name="classic-web-acl-xss-conditions-editing"></a>

You can add or delete filters in a cross-site scripting match condition. To change a filter, add a new one and delete the old one.<a name="classic-web-acl-xss-conditions-editing-procedure"></a>

**To add or delete filters in a cross-site scripting match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Cross-site scripting**.

1. Choose the condition that you want to add or delete filters in.

1. To add filters, perform the following steps:

   1. Choose **Add filter**.

   1. Specify the applicable filter settings. For more information, see [Values that you specify when you create or edit cross-site scripting match conditions](#classic-web-acl-xss-conditions-values).

   1. Choose **Add**.

1. To delete filters, perform the following steps:

   1. Select the filter that you want to delete.

   1. Choose **Delete filter**.

## Deleting cross-site scripting match conditions
<a name="classic-web-acl-xss-conditions-deleting"></a>

If you want to delete a cross-site scripting match condition, you must first delete all filters in the condition and remove the condition from all the rules that are using it, as described in the following procedure.<a name="classic-web-acl-xss-conditions-deleting-procedure"></a>

**To delete a cross-site scripting match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Cross-site scripting**.

1. In the **Cross-site scripting match conditions** pane, choose the cross-site scripting match condition that you want to delete.

1. In the right pane, choose the **Associated rules** tab.

   If the list of rules using this cross-site scripting match condition is empty, go to step 6. If the list contains any rules, make note of the rules, and continue with step 5.

1. To remove the cross-site scripting match condition from the rules that are using it, perform the following steps:

   1. In the navigation pane, choose **Rules**.

   1. Choose the name of a rule that is using the cross-site scripting match condition that you want to delete.

   1. In the right pane, select the cross-site scripting match condition that you want to remove from the rule, and choose **Remove selected condition**.

   1. Repeat steps b and c for all the remaining rules that are using the cross-site scripting match condition that you want to delete.

   1. In the navigation pane, choose **Cross-site scripting**.

   1. In the **Cross-site scripting match conditions** pane, choose the cross-site scripting match condition that you want to delete.

1. Choose **Delete** to delete the selected condition.

# Working with IP match conditions
<a name="classic-web-acl-ip-conditions"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

If you want to allow or block web requests based on the IP addresses that the requests originate from, create one or more IP match conditions. An IP match condition lists up to 10,000 IP addresses or IP address ranges that your requests originate from. Later in the process, when you create a web ACL, you specify whether to allow or block requests from those IP addresses.

**Topics**
+ [Creating an IP Match Condition](#classic-web-acl-ip-conditions-creating)
+ [Editing IP match conditions](#classic-web-acl-ip-conditions-editing)
+ [Deleting IP match conditions](#classic-web-acl-ip-conditions-deleting)

## Creating an IP Match Condition
<a name="classic-web-acl-ip-conditions-creating"></a>

If you want to allow some web requests and block others based on the IP addresses that the requests originate from, create an IP match condition for the IP addresses that you want to allow and another IP match condition for the IP addresses that you want to block.

**Note**  
When you add an IP match condition to a rule, you also can configure AWS WAF Classic to allow or block web requests that *do not* originate from the IP addresses that you specify in the condition.<a name="classic-web-acl-ip-conditions-creating-procedure"></a>

**To create an IP match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **IP addresses**.

1. Choose **Create condition**.

1. Enter a name in the **Name** field.

   The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: \$1-\$1"\$1`\$1\$1\$1,./ . You can't change the name of a condition after you create it.

1. Select the correct IP version and specify an IP address or range of IP addresses by using CIDR notation. Here are some examples:
   + To specify the IPv4 address 192.0.2.44, type **192.0.2.44/32**.
   + To specify the IPv6 address 0:0:0:0:0:ffff:c000:22c, type **0:0:0:0:0:ffff:c000:22c/128**.
   + To specify the range of IPv4 addresses from 192.0.2.0 to 192.0.2.255, type **192.0.2.0/24**.
   + To specify the range of IPv6 addresses from 2620:0:2d0:200:0:0:0:0 to 2620:0:2d0:200:ffff:ffff:ffff:ffff, enter **2620:0:2d0:200::/64**.

   AWS WAF Classic supports IPv4 address ranges: /8 and any range between /16 through /32. AWS WAF Classic supports IPv6 address ranges: /24, /32, /48, /56, /64, and /128. For more information about CIDR notation, see the Wikipedia entry [Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing).

1. Choose **Add another IP address or range**.

1. If you want to add another IP address or range, repeat steps 5 and 6.

1. When you're finished adding values, choose **Create IP match condition**.

## Editing IP match conditions
<a name="classic-web-acl-ip-conditions-editing"></a>

You can add an IP address range to an IP match condition or delete a range. To change a range, add a new one and delete the old one.<a name="classic-web-acl-ip-conditions-editing-procedure"></a>

**To edit an IP match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **IP addresses**.

1. In the **IP match conditions** pane, choose the IP match condition that you want to edit.

1. To add an IP address range:

   1. In the right pane, choose **Add IP address or range**.

   1. Select the correct IP version and enter an IP address range by using CIDR notation. Here are some examples:
      + To specify the IPv4 address 192.0.2.44, enter **192.0.2.44/32**.
      + To specify the IPv6 address 0:0:0:0:0:ffff:c000:22c, enter **0:0:0:0:0:ffff:c000:22c/128**.
      + To specify the range of IPv4 addresses from 192.0.2.0 to 192.0.2.255, enter **192.0.2.0/24**.
      + To specify the range of IPv6 addresses from 2620:0:2d0:200:0:0:0:0 to 2620:0:2d0:200:ffff:ffff:ffff:ffff, enter **2620:0:2d0:200::/64**.

      AWS WAF Classic supports IPv4 address ranges: /8 and any range between /16 through /32. AWS WAF Classic supports IPv6 address ranges: /24, /32, /48, /56, /64, and /128. For more information about CIDR notation, see the Wikipedia entry [Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing).

   1. To add more IP addresses, choose **Add another IP address** and enter the value.

   1. Choose **Add**.

1. To delete an IP address or range:

   1. In the right pane, select the values that you want to delete.

   1. Choose **Delete IP address or range**.

## Deleting IP match conditions
<a name="classic-web-acl-ip-conditions-deleting"></a>

If you want to delete an IP match condition, you must first delete all IP addresses and ranges in the condition and remove the condition from all the rules that are using it, as described in the following procedure.<a name="classic-web-acl-ip-conditions-deleting-procedure"></a>

**To delete an IP match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **IP addresses**.

1. In the **IP match conditions** pane, choose the IP match condition that you want to delete.

1. In the right pane, choose the **Rules** tab.

   If the list of rules using this IP match condition is empty, go to step 6. If the list contains any rules, make note of the rules, and continue with step 5.

1. To remove the IP match condition from the rules that are using it, perform the following steps:

   1. In the navigation pane, choose **Rules**.

   1. Choose the name of a rule that is using the IP match condition that you want to delete.

   1. In the right pane, select the IP match condition that you want to remove from the rule, and choose **Remove selected condition**.

   1. Repeat steps b and c for all the remaining rules that are using the IP match condition that you want to delete.

   1. In the navigation pane, choose **IP match conditions**.

   1. In the **IP match conditions** pane, choose the IP match condition that you want to delete.

1. Choose **Delete** to delete the selected condition.

# Working with geographic match conditions
<a name="classic-web-acl-geo-conditions"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

If you want to allow or block web requests based on the country that the requests originate from, create one or more geo match conditions. A geo match condition lists countries that your requests originate from. Later in the process, when you create a web ACL, you specify whether to allow or block requests from those countries.

You can use geo match conditions with other AWS WAF Classic conditions or rules to build sophisticated filtering. For example, if you want to block certain countries, but still allow specific IP addresses from that country, you could create a rule containing a geo match condition and an IP match condition. Configure the rule to block requests that originate from that country and do not match the approved IP addresses. As another example, if you want to prioritize resources for users in a particular country, you could include a geo match condition in two different rate-based rules. Set a higher rate limit for users in the preferred country and set a lower rate limit for all other users.

**Note**  
If you are using the CloudFront geo restriction feature to block a country from accessing your content, any request from that country is blocked and is not forwarded to AWS WAF Classic. So if you want to allow or block requests based on geography plus other AWS WAF Classic conditions, you should *not* use the CloudFront geo restriction feature. Instead, you should use an AWS WAF Classic geo match condition.

**Topics**
+ [Creating a geo match condition](#classic-web-acl-geo-conditions-creating)
+ [Editing geo match conditions](#classic-web-acl-geo-conditions-editing)
+ [Deleting geo match conditions](#classic-web-acl-geo-conditions-deleting)

## Creating a geo match condition
<a name="classic-web-acl-geo-conditions-creating"></a>

If you want to allow some web requests and block others based on the countries that the requests originate from, create a geo match condition for the countries that you want to allow and another geo match condition for the countries that you want to block.

**Note**  
When you add a geo match condition to a rule, you also can configure AWS WAF Classic to allow or block web requests that *do not* originate from the country that you specify in the condition.<a name="classic-web-acl-geo-conditions-creating-procedure"></a>

**To create a geo match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Geo match**.

1. Choose **Create condition**.

1. Enter a name in the **Name** field.

   The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: \$1-\$1"\$1`\$1\$1\$1,./ . You can't change the name of a condition after you create it.

1. Choose a **Region**.

1. Choose a **Location type** and a country. **Location type** can currently only be **Country**.

1. Choose **Add location**.

1. Choose **Create**.

## Editing geo match conditions
<a name="classic-web-acl-geo-conditions-editing"></a>

You can add countries to or delete countries from your geo match condition.<a name="classic-web-acl-geo-conditions-editing-procedure"></a>

**To edit a geo match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Geo match**.

1. In the **Geo match conditions** pane, choose the geo match condition that you want to edit.

1. To add a country:

   1. In the right pane, choose **Add filter**.

   1. Choose a **Location type** and a country. **Location type** can currently only be **Country**.

   1. Choose **Add**.

1. To delete a country:

   1. In the right pane, select the values that you want to delete.

   1. Choose **Delete filter**.

## Deleting geo match conditions
<a name="classic-web-acl-geo-conditions-deleting"></a>

If you want to delete a geo match condition, you must first remove all countries in the condition and remove the condition from all the rules that are using it, as described in the following procedure.<a name="classic-web-acl-geo-conditions-deleting-procedure"></a>

**To delete a geo match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. Remove the geo match condition from the rules that are using it:

   1. In the navigation pane, choose **Rules**.

   1. Choose the name of a rule that is using the geo match condition that you want to delete.

   1. In the right pane, choose **Edit rule**.

   1. Choose the **X** next to the condition you want to delete.

   1. Choose **Update**.

   1. Repeat for all the remaining rules that are using the geo match condition that you want to delete.

1. Remove the filters from the condition you want to delete:

   1. In the navigation pane, choose **Geo match**.

   1. Choose the name of the geo match condition that you want to delete.

   1. In the right pane, choose the check box next to **Filter** in order to select all of the filters.

   1. Choose the **Delete filter**.

1. In the navigation pane, choose **Geo match**.

1. In the **Geo match conditions** pane, choose the geo match condition that you want to delete.

1. Choose **Delete** to delete the selected condition.

# Working with size constraint conditions
<a name="classic-web-acl-size-conditions"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

If you want to allow or block web requests based on the length of specified parts of requests, create one or more size constraint conditions. A size constraint condition identifies the part of web requests that you want AWS WAF Classic to look at, the number of bytes that you want AWS WAF Classic to look for, and an operator, such as greater than (>) or less than (<). For example, you can use a size constraint condition to look for query strings that are longer than 100 bytes. Later in the process, when you create a web ACL, you specify whether to allow or block requests based on those settings.

Note that if you configure AWS WAF Classic to inspect the request body, for example, by searching the body for a specified string, AWS WAF Classic inspects only the first 8192 bytes (8 KB). If the request body for your web requests will never exceed 8192 bytes, you can create a size constraint condition and block requests that have a request body greater than 8192 bytes.

**Topics**
+ [Creating size constraint conditions](#classic-web-acl-size-conditions-creating)
+ [Values that you specify when you create or edit size constraint conditions](#classic-web-acl-size-conditions-values)
+ [Adding and deleting filters in a size constraint condition](#classic-web-acl-size-conditions-editing)
+ [Deleting size constraint conditions](#classic-web-acl-size-conditions-deleting)

## Creating size constraint conditions
<a name="classic-web-acl-size-conditions-creating"></a>

When you create size constraint conditions, you specify filters that identify the part of web requests for which you want AWS WAF Classic to evaluate the length. You can add more than one filter to a size constraint condition, or you can create a separate condition for each filter. Here's how each configuration affects AWS WAF Classic behavior:
+ **One filter per size constraint condition** – When you add the separate size constraint conditions to a rule and add the rule to a web ACL, web requests must match all the conditions for AWS WAF Classic to allow or block requests based on the conditions. 

  For example, suppose you create two conditions. One matches web requests for which query strings are greater than 100 bytes. The other matches web requests for which the request body is greater than 1024 bytes. When you add both conditions to the same rule and add the rule to a web ACL, AWS WAF Classic allows or blocks requests only when both conditions are true.
+ **More than one filter per size constraint condition** – When you add a size constraint condition that contains multiple filters to a rule and add the rule to a web ACL, a web request needs only to match one of the filters in the size constraint condition for AWS WAF Classic to allow or block the request based on that condition.

  Suppose you create one condition instead of two, and the one condition contains the same two filters as in the preceding example. AWS WAF Classic allows or blocks requests if either the query string is greater than 100 bytes or the request body is greater than 1024 bytes.

**Note**  
When you add a size constraint condition to a rule, you also can configure AWS WAF Classic to allow or block web requests that *do not* match the values in the condition.<a name="classic-web-acl-size-conditions-creating-procedure"></a>

**To create a size constraint condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Size constraints**.

1. Choose **Create condition**.

1. Specify the applicable filter settings. For more information, see [Values that you specify when you create or edit size constraint conditions](#classic-web-acl-size-conditions-values).

1. Choose **Add another filter**.

1. If you want to add another filter, repeat steps 4 and 5.

1. When you're finished adding filters, choose **Create size constraint condition**.

## Values that you specify when you create or edit size constraint conditions
<a name="classic-web-acl-size-conditions-values"></a>

When you create or update a size constraint condition, you specify the following values: 

**Name**  
Enter a name for the size constraint condition.  
The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: \$1-\$1"\$1`\$1\$1\$1,./. You can't change the name of a condition after you create it.

**Part of the request to filter on**  
Choose the part of each web request for which you want AWS WAF Classic to evaluate the length:    
**Header**  
A specified request header, for example, the `User-Agent` or `Referer` header. If you choose **Header**, specify the name of the header in the **Header** field.  
**HTTP method**  
The HTTP method, which indicates the type of operation that the request is asking the origin to perform. CloudFront supports the following methods: `DELETE`, `GET`, `HEAD`, `OPTIONS`, `PATCH`, `POST`, and `PUT`.  
**Query string**  
The part of a URL that appears after a `?` character, if any.  
**URI**  
The URI path of the request, which identifies the resource, for example, `/images/daily-ad.jpg`. This doesn't include the query string or fragment components of the URI. For information, see [Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986#section-3.3).   
Unless a **Transformation** is specified, a URI is not normalized and is inspected just as AWS receives it from the client as part of the request. A **Transformation** will reformat the URI as specified.  
**Body**  
The part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form.  
**Single query parameter (value only)**  
Any parameter that you have defined as part of the query string. For example, if the URL is "www.xyz.com?UserName=abc&SalesRegion=seattle" you can add a filter to either the *UserName* or *SalesRegion* parameter.   
If you choose **Single query parameter (value only)**, you will also specify a **Query parameter name**. This is the parameter in the query string that you will inspect, such as *UserName*. The maximum length for **Query parameter name** is 30 characters. **Query parameter name** is not case sensitive. For example, it you specify *UserName* as the **Query parameter name**, this will match all variations of *UserName*, such as *username* and *UsERName*.  
**All query parameters (values only)**  
Similar to **Single query parameter (value only)**, but rather than inspecting the value of a single parameter, AWS WAF Classic inspects the values of all parameters within the query string for the size constraint. For example, if the URL is "www.xyz.com?UserName=abc&SalesRegion=seattle," and you choose **All query parameters (values only)**, AWS WAF Classic will trigger a match the value of if either *UserName* or *SalesRegion* exceed the specified size. 

**Header (Only When "Part of the request to filter on" is "Header")**  
If you chose **Header** for **Part of the request to filter on**, choose a header from the list of common headers, or type the name of a header for which you want AWS WAF Classic to evaluate the length.

**Comparison operator**  
Choose how you want AWS WAF Classic to evaluate the length of the query string in web requests with respect to the value that you specify for **Size**.  
For example, if you choose **Is greater than** for **Comparison operator** and type **100** for **Size**, AWS WAF Classic evaluates web requests for a query string that is longer than 100 bytes.

**Size**  
Enter the length, in bytes, that you want AWS WAF Classic to watch for in query strings.  
If you choose **URI** for the value of **Part of the request to filter on**, the **/** in the URI counts as one character. For example, the URI path `/logo.jpg` is nine characters long.

**Transformation**  
A transformation reformats a web request before AWS WAF Classic evaluates the length of the specified part of the request. This eliminates some of the unusual formatting that attackers use in web requests in an effort to bypass AWS WAF Classic.   
If you choose **Body** for **Part of the request to filter on**, you can't configure AWS WAF Classic to perform a transformation because only the first 8192 bytes are forwarded for inspection. However, you can still filter your traffic based on the size of the HTTP request body and specify a transformation of **None**. (AWS WAF Classic gets the length of the body from the request headers.)
You can only specify a single type of text transformation.  
Transformations can perform the following operations:    
**None**  
AWS WAF Classic doesn't perform any text transformations on the web request before checking the length.  
**Convert to lowercase**  
AWS WAF Classic converts uppercase letters (A-Z) to lowercase (a-z).  
**HTML decode**  
AWS WAF Classic replaces HTML-encoded characters with unencoded characters:  
+ Replaces `&quot;` with `&`
+ Replaces `&nbsp;` with a non-breaking space
+ Replaces `&lt;` with `<`
+ Replaces `&gt;` with `>`
+ Replaces characters that are represented in hexadecimal format, `&#xhhhh;`, with the corresponding characters
+ Replaces characters that are represented in decimal format, `&#nnnn;`, with the corresponding characters  
**Normalize white space**  
AWS WAF Classic replaces the following characters with a space character (decimal 32):  
+ \$1f, formfeed, decimal 12
+ \$1t, tab, decimal 9
+ \$1n, newline, decimal 10
+ \$1r, carriage return, decimal 13
+ \$1v, vertical tab, decimal 11
+ non-breaking space, decimal 160
In addition, this option replaces multiple spaces with one space.  
**Simplify command line**  
For requests that contain operating system command line commands, use this option to perform the following transformations:  
+ Delete the following characters: \$1 " ' ^
+ Delete spaces before the following characters: / (
+ Replace the following characters with a space: , ;
+ Replace multiple spaces with one space
+ Convert uppercase letters (A-Z) to lowercase (a-z)  
**URL decode**  
Decode a URL-encoded request.

## Adding and deleting filters in a size constraint condition
<a name="classic-web-acl-size-conditions-editing"></a>

You can add or delete filters in a size constraint condition. To change a filter, add a new one and delete the old one.<a name="classic-web-acl-size-conditions-editing-procedure"></a>

**To add or delete filters in a size constraint condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Size constraint**.

1. Choose the condition that you want to add or delete filters in.

1. To add filters, perform the following steps:

   1. Choose **Add filter**.

   1. Specify the applicable filter settings. For more information, see [Values that you specify when you create or edit size constraint conditions](#classic-web-acl-size-conditions-values).

   1. Choose **Add**.

1. To delete filters, perform the following steps:

   1. Select the filter that you want to delete.

   1. Choose **Delete filter**.

## Deleting size constraint conditions
<a name="classic-web-acl-size-conditions-deleting"></a>

If you want to delete a size constraint condition, you need to first delete all filters in the condition and remove the condition from all the rules that are using it, as described in the following procedure.<a name="classic-web-acl-size-conditions-deleting-procedure"></a>

**To delete a size constraint condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Size constraints**.

1. In the **Size constraint conditions** pane, choose the size constraint condition that you want to delete.

1. In the right pane, choose the **Associated rules** tab.

   If the list of rules using this size constraint condition is empty, go to step 6. If the list contains any rules, make note of the rules, and continue with step 5.

1. To remove the size constraint condition from the rules that are using it, perform the following steps:

   1. In the navigation pane, choose **Rules**.

   1. Choose the name of a rule that is using the size constraint condition that you want to delete.

   1. In the right pane, select the size constraint condition that you want to remove from the rule, and then choose **Remove selected condition**.

   1. Repeat steps b and c for all the remaining rules that are using the size constraint condition that you want to delete.

   1. In the navigation pane, choose **Size constraint**.

   1. In the **Size constraint conditions** pane, choose the size constraint condition that you want to delete.

1. Choose **Delete** to delete the selected condition.

# Working with SQL injection match conditions
<a name="classic-web-acl-sql-conditions"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

Attackers sometimes insert malicious SQL code into web requests in an effort to extract data from your database. To allow or block web requests that appear to contain malicious SQL code, create one or more SQL injection match conditions. A SQL injection match condition identifies the part of web requests, such as the URI path or the query string, that you want AWS WAF Classic to inspect. Later in the process, when you create a web ACL, you specify whether to allow or block requests that appear to contain malicious SQL code.

**Topics**
+ [Creating SQL injection match conditions](#classic-web-acl-sql-conditions-creating)
+ [Values that you specify when you create or edit SQL injection match conditions](#classic-web-acl-sql-conditions-values)
+ [Adding and deleting filters in a SQL injection match condition](#classic-web-acl-sql-conditions-editing)
+ [Deleting SQL injection match conditions](#classic-web-acl-sql-conditions-deleting)

## Creating SQL injection match conditions
<a name="classic-web-acl-sql-conditions-creating"></a>

When you create SQL injection match conditions, you specify filters, which indicate the part of web requests that you want AWS WAF Classic to inspect for malicious SQL code, such as the URI or the query string. You can add more than one filter to a SQL injection match condition, or you can create a separate condition for each filter. Here's how each configuration affects AWS WAF Classic behavior:
+ **More than one filter per SQL injection match condition (recommended)** – When you add a SQL injection match condition containing multiple filters to a rule and add the rule to a web ACL, a web request needs only to match one of the filters in the SQL injection match condition for AWS WAF Classic to allow or block the request based on that condition.

  For example, suppose you create one SQL injection match condition, and the condition contains two filters. One filter instructs AWS WAF Classic to inspect the URI for malicious SQL code, and the other instructs AWS WAF Classic to inspect the query string. AWS WAF Classic allows or blocks requests if they appear to contain malicious SQL code *either* in the URI *or* in the query string.
+ **One filter per SQL injection match condition** – When you add the separate SQL injection match conditions to a rule and add the rule to a web ACL, web requests must match all the conditions for AWS WAF Classic to allow or block requests based on the conditions. 

  Suppose you create two conditions, and each condition contains one of the two filters in the preceding example. When you add both conditions to the same rule and add the rule to a web ACL, AWS WAF Classic allows or blocks requests only when both the URI and the query string appear to contain malicious SQL code.

**Note**  
When you add a SQL injection match condition to a rule, you also can configure AWS WAF Classic to allow or block web requests that *do not* appear to contain malicious SQL code.<a name="classic-web-acl-sql-conditions-creating-procedure"></a>

**To create a SQL injection match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **SQL injection**.

1. Choose **Create condition**.

1. Specify the applicable filter settings. For more information, see [Values that you specify when you create or edit SQL injection match conditions](#classic-web-acl-sql-conditions-values).

1. Choose **Add another filter**.

1. If you want to add another filter, repeat steps 4 and 5.

1. When you're finished adding filters, choose **Create**.

## Values that you specify when you create or edit SQL injection match conditions
<a name="classic-web-acl-sql-conditions-values"></a>

When you create or update a SQL injection match condition, you specify the following values: 

**Name**  
The name of the SQL injection match condition.  
The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: \$1-\$1"\$1`\$1\$1\$1,./. You can't change the name of a condition after you create it.

**Part of the request to filter on**  
Choose the part of each web request that you want AWS WAF Classic to inspect for malicious SQL code:    
**Header**  
A specified request header, for example, the `User-Agent` or `Referer` header. If you choose **Header**, specify the name of the header in the **Header** field.  
**HTTP method**  
The HTTP method, which indicates the type of operation that the request is asking the origin to perform. CloudFront supports the following methods: `DELETE`, `GET`, `HEAD`, `OPTIONS`, `PATCH`, `POST`, and `PUT`.  
**Query string**  
The part of a URL that appears after a `?` character, if any.  
For SQL injection match conditions, we recommend that you choose **All query parameters (values only)** instead of **Query string** for **Part of the request to filter on**.  
**URI**  
The URI path of the request, which identifies the resource, for example, `/images/daily-ad.jpg`. This doesn't include the query string or fragment components of the URI. For information, see [Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986#section-3.3).   
Unless a **Transformation** is specified, a URI is not normalized and is inspected just as AWS receives it from the client as part of the request. A **Transformation** will reformat the URI as specified.  
**Body**  
The part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form.  
If you choose **Body** for the value of **Part of the request to filter on**, AWS WAF Classic inspects only the first 8192 bytes (8 KB). To allow or block requests for which the body is longer than 8192 bytes, you can create a size constraint condition. (AWS WAF Classic gets the length of the body from the request headers.) For more information, see [Working with size constraint conditions](classic-web-acl-size-conditions.md).  
**Single query parameter (value only)**  
Any parameter that you have defined as part of the query string. For example, if the URL is "www.xyz.com?UserName=abc&SalesRegion=seattle" you can add a filter to either the *UserName* or *SalesRegion* parameter.   
If you choose **Single query parameter (value only)** you will also specify a **Query parameter name**. This is the parameter in the query string that you will inspect, such as *UserName* or *SalesRegion*. The maximum length for **Query parameter name** is 30 characters. **Query parameter name** is not case sensitive. For example, it you specify *UserName* as the **Query parameter name**, this will match all variations of *UserName*, such as *username* and *UsERName*.  
**All query parameters (values only)**  
Similar to **Single query parameter (value only)**, but rather than inspecting the value of a single parameter, AWS WAF Classic inspects the value of all parameters within the query string for possible malicious SQL code. For example, if the URL is "www.xyz.com?UserName=abc&SalesRegion=seattle," and you choose **All query parameters (values only)**, AWS WAF Classic will trigger a match if the value of either *UserName* or *SalesRegion* contain possible malicious SQL code. 

**Header**  
If you chose **Header** for **Part of the request to filter on**, choose a header from the list of common headers, or enter the name of a header that you want AWS WAF Classic to inspect for malicious SQL code.

**Transformation**  
A transformation reformats a web request before AWS WAF Classic inspects the request. This eliminates some of the unusual formatting that attackers use in web requests in an effort to bypass AWS WAF Classic.   
You can only specify a single type of text transformation.  
Transformations can perform the following operations:    
**None**  
AWS WAF Classic doesn't perform any text transformations on the web request before inspecting it for the string in **Value to match**.  
**Convert to lowercase**  
AWS WAF Classic converts uppercase letters (A-Z) to lowercase (a-z).  
**HTML decode**  
AWS WAF Classic replaces HTML-encoded characters with unencoded characters:  
+ Replaces `&quot;` with `&`
+ Replaces `&nbsp;` with a non-breaking space
+ Replaces `&lt;` with `<`
+ Replaces `&gt;` with `>`
+ Replaces characters that are represented in hexadecimal format, `&#xhhhh;`, with the corresponding characters
+ Replaces characters that are represented in decimal format, `&#nnnn;`, with the corresponding characters  
**Normalize white space**  
AWS WAF Classic replaces the following characters with a space character (decimal 32):  
+ \$1f, formfeed, decimal 12
+ \$1t, tab, decimal 9
+ \$1n, newline, decimal 10
+ \$1r, carriage return, decimal 13
+ \$1v, vertical tab, decimal 11
+ non-breaking space, decimal 160
In addition, this option replaces multiple spaces with one space.  
**Simplify command line**  
For requests that contain operating system command line commands, use this option to perform the following transformations:  
+ Delete the following characters: \$1 " ' ^
+ Delete spaces before the following characters: / (
+ Replace the following characters with a space: , ;
+ Replace multiple spaces with one space
+ Convert uppercase letters (A-Z) to lowercase (a-z)  
**URL decode**  
Decode a URL-encoded request.

## Adding and deleting filters in a SQL injection match condition
<a name="classic-web-acl-sql-conditions-editing"></a>

You can add or delete filters in a SQL injection match condition. To change a filter, add a new one and delete the old one.<a name="classic-web-acl-sql-conditions-editing-procedure"></a>

**To add or delete filters in a SQL injection match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **SQL injection**.

1. Choose the condition that you want to add or delete filters in.

1. To add filters, perform the following steps:

   1. Choose **Add filter**.

   1. Specify the applicable filter settings. For more information, see [Values that you specify when you create or edit SQL injection match conditions](#classic-web-acl-sql-conditions-values).

   1. Choose **Add**.

1. To delete filters, perform the following steps:

   1. Select the filter that you want to delete.

   1. Choose **Delete filter**.

## Deleting SQL injection match conditions
<a name="classic-web-acl-sql-conditions-deleting"></a>

If you want to delete a SQL injection match condition, you need to first delete all filters in the condition and remove the condition from all the rules that are using it, as described in the following procedure.<a name="classic-web-acl-sql-conditions-deleting-procedure"></a>

**To delete a SQL injection match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **SQL injection**.

1. In the **SQL injection match conditions** pane, choose the SQL injection match condition that you want to delete.

1. In the right pane, choose the **Associated rules** tab.

   If the list of rules using this SQL injection match condition is empty, go to step 6. If the list contains any rules, make note of the rules, and continue with step 5.

1. To remove the SQL injection match condition from the rules that are using it, perform the following steps:

   1. In the navigation pane, choose **Rules**.

   1. Choose the name of a rule that is using the SQL injection match condition that you want to delete.

   1. In the right pane, select the SQL injection match condition that you want to remove from the rule, and choose **Remove selected condition**.

   1. Repeat steps b and c for all of the remaining rules that are using the SQL injection match condition that you want to delete.

   1. In the navigation pane, choose **SQL injection**.

   1. In the **SQL injection match conditions** pane, choose the SQL injection match condition that you want to delete.

1. Choose **Delete** to delete the selected condition.

# Working with string match conditions
<a name="classic-web-acl-string-conditions"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

If you want to allow or block web requests based on strings that appear in the requests, create one or more string match conditions. A string match condition identifies the string that you want to search for and the part of web requests, such as a specified header or the query string, that you want AWS WAF Classic to inspect for the string. Later in the process, when you create a web ACL, you specify whether to allow or block requests that contain the string.

**Topics**
+ [Creating a string match condition](#classic-web-acl-string-conditions-creating)
+ [Values that you specify when you create or edit string match conditions](#classic-web-acl-string-conditions-values)
+ [Adding and deleting filters in a string match condition](#classic-web-acl-string-conditions-editing)
+ [Deleting string match conditions](#classic-web-acl-string-conditions-deleting)

## Creating a string match condition
<a name="classic-web-acl-string-conditions-creating"></a>

When you create string match conditions, you specify filters that identify the string that you want to search for and the part of web requests that you want AWS WAF Classic to inspect for that string, such as the URI or the query string. You can add more than one filter to a string match condition, or you can create a separate string match condition for each filter. Here's how each configuration affects AWS WAF Classic behavior:
+ **One filter per string match condition** – When you add the separate string match conditions to a rule and add the rule to a web ACL, web requests must match all the conditions for AWS WAF Classic to allow or block requests based on the conditions. 

  For example, suppose you create two conditions. One matches web requests that contain the value `BadBot` in the `User-Agent` header. The other matches web requests that contain the value `BadParameter` in query strings. When you add both conditions to the same rule and add the rule to a web ACL, AWS WAF Classic allows or blocks requests only when they contain both values.
+ **More than one filter per string match condition** – When you add a string match condition that contains multiple filters to a rule and add the rule to a web ACL, a web request needs only to match one of the filters in the string match condition for AWS WAF Classic to allow or block the request based on the one condition.

  Suppose you create one condition instead of two, and the one condition contains the same two filters as in the preceding example. AWS WAF Classic allows or blocks requests if they contain *either* `BadBot` in the `User-Agent` header *or* `BadParameter` in the query string.

**Note**  
When you add a string match condition to a rule, you also can configure AWS WAF Classic to allow or block web requests that *do not* match the values in the condition.<a name="classic-web-acl-string-conditions-creating-procedure"></a>

**To create a string match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **String and regex matching**.

1. Choose **Create condition**.

1. Specify the applicable filter settings. For more information, see [Values that you specify when you create or edit string match conditions](#classic-web-acl-string-conditions-values).

1. Choose **Add filter**.

1. If you want to add another filter, repeat steps 4 and 5.

1. When you're finished adding filters, choose **Create**.

## Values that you specify when you create or edit string match conditions
<a name="classic-web-acl-string-conditions-values"></a>

When you create or update a string match condition, you specify the following values: 

**Name**  
Enter a name for the string match condition. The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: \$1-\$1"\$1`\$1\$1\$1,./. You can't change the name of a condition after you create it.

**Type**  
Choose **String match**.

**Part of the request to filter on**  
Choose the part of each web request that you want AWS WAF Classic to inspect for the string that you specify in **Value to match**:    
**Header**  
A specified request header, for example, the `User-Agent` or `Referer` header. If you choose **Header**, specify the name of the header in the **Header** field.  
**HTTP method**  
The HTTP method, which indicates the type of operation that the request is asking the origin to perform. CloudFront supports the following methods: `DELETE`, `GET`, `HEAD`, `OPTIONS`, `PATCH`, `POST`, and `PUT`.  
**Query string**  
The part of a URL that appears after a `?` character, if any.  
**URI**  
The URI path of the request, which identifies the resource, for example, `/images/daily-ad.jpg`. This doesn't include the query string or fragment components of the URI. For information, see [Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986#section-3.3).   
Unless a **Transformation** is specified, a URI is not normalized and is inspected just as AWS receives it from the client as part of the request. A **Transformation** will reformat the URI as specified.  
**Body**  
The part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form.  
If you choose **Body** for the value of **Part of the request to filter on**, AWS WAF Classic inspects only the first 8192 bytes (8 KB). To allow or block requests for which the body is longer than 8192 bytes, you can create a size constraint condition. (AWS WAF Classic gets the length of the body from the request headers.) For more information, see [Working with size constraint conditions](classic-web-acl-size-conditions.md).  
**Single query parameter (value only)**  
Any parameter that you have defined as part of the query string. For example, if the URL is "www.xyz.com?UserName=abc&SalesRegion=seattle" you can add a filter to either the *UserName* or *SalesRegion* parameter.   
If duplicate parameters appear in the query string, the values are evaluated as an "OR." That is, either value will trigger a match. For example, in the URL "www.xyz.com?SalesRegion=boston&SalesRegion=seattle", either "boston" or "seattle" in **Value to match** will trigger a match.  
If you choose **Single query parameter (value only)** you will also specify a **Query parameter name**. This is the parameter in the query string that you will inspect, such as *UserName* or *SalesRegion*. The maximum length for **Query parameter name** is 30 characters. **Query parameter name** is not case sensitive. For example, it you specify *UserName* as the **Query parameter name**, this will match all variations of *UserName*, such as *username* and *UsERName*.  
**All query parameters (values only)**  
Similar to **Single query parameter (value only)**, but rather than inspecting the value of a single parameter, AWS WAF Classic inspects the value of all parameters within the query string for the **Value to match**. For example, if the URL is "www.xyz.com?UserName=abc&SalesRegion=seattle," and you choose **All query parameters (values only)**, AWS WAF Classic will trigger a match if the value of either *UserName* or *SalesRegion* is specified as the **Value to match**. 

**Header (Only When "Part of the request to filter on" is "Header")**  
If you chose **Header** from the **Part of the request to filter on** list, choose a header from the list of common headers, or enter the name of a header that you want AWS WAF Classic to inspect.

**Match type**  
Within the part of the request that you want AWS WAF Classic to inspect, choose where the string in **Value to match** must appear to match this filter:    
**Contains**  
The string appears anywhere in the specified part of the request.   
**Contains word**  
The specified part of the web request must include **Value to match**, and **Value to match** must contain only alphanumeric characters or underscore (A-Z, a-z, 0-9, or \$1). In addition, **Value to match** must be a word, which means one of the following:   
+ **Value to match** exactly matches the value of the specified part of the web request, such as the value of a header.
+ **Value to match** is at the beginning of the specified part of the web request and is followed by a character other than an alphanumeric character or underscore (\$1), for example, `BadBot;`.
+ **Value to match** is at the end of the specified part of the web request and is preceded by a character other than an alphanumeric character or underscore (\$1), for example, `;BadBot`.
+ **Value to match** is in the middle of the specified part of the web request and is preceded and followed by characters other than alphanumeric characters or underscore (\$1), for example, `-BadBot;`.  
**Exactly matches**  
The string and the value of the specified part of the request are identical.  
**Starts with**  
The string appears at the beginning of the specified part of the request.   
**Ends with**  
The string appears at the end of the specified part of the request. 

**Transformation**  
A transformation reformats a web request before AWS WAF Classic inspects the request. This eliminates some of the unusual formatting that attackers use in web requests in an effort to bypass AWS WAF Classic.   
You can only specify a single type of text transformation.  
Transformations can perform the following operations:    
**None**  
AWS WAF Classic doesn't perform any text transformations on the web request before inspecting it for the string in **Value to match**.  
**Convert to lowercase**  
AWS WAF Classic converts uppercase letters (A-Z) to lowercase (a-z).  
**HTML decode**  
AWS WAF Classic replaces HTML-encoded characters with unencoded characters:  
+ Replaces `&quot;` with `&`
+ Replaces `&nbsp;` with a non-breaking space
+ Replaces `&lt;` with `<`
+ Replaces `&gt;` with `>`
+ Replaces characters that are represented in hexadecimal format, `&#xhhhh;`, with the corresponding characters
+ Replaces characters that are represented in decimal format, `&#nnnn;`, with the corresponding characters  
**Normalize white space**  
AWS WAF Classic replaces the following characters with a space character (decimal 32):  
+ \$1f, formfeed, decimal 12
+ \$1t, tab, decimal 9
+ \$1n, newline, decimal 10
+ \$1r, carriage return, decimal 13
+ \$1v, vertical tab, decimal 11
+ non-breaking space, decimal 160
In addition, this option replaces multiple spaces with one space.  
**Simplify command line**  
When you're concerned that attackers are injecting an operating system command line command and using unusual formatting to disguise some or all of the command, use this option to perform the following transformations:  
+ Delete the following characters: \$1 " ' ^
+ Delete spaces before the following characters: / (
+ Replace the following characters with a space: , ;
+ Replace multiple spaces with one space
+ Convert uppercase letters (A-Z) to lowercase (a-z)  
**URL decode**  
Decode a URL-encoded request.

**Value is base64 encoded**  
If the value in **Value to match** is base64-encoded, select this check box. Use base64-encoding to specify non-printable characters, such as tabs and linefeeds, that attackers include in their requests.

**Value to match**  
Specify the value that you want AWS WAF Classic to search for in web requests. The maximum length is 50 bytes. If you're base64-encoding the value, the 50-byte maximum length applies to the value before you encode it.

## Adding and deleting filters in a string match condition
<a name="classic-web-acl-string-conditions-editing"></a>

You can add filters to a string match condition or delete filters. To change a filter, add a new one and delete the old one.<a name="classic-web-acl-string-conditions-editing-procedure"></a>

**To add or delete filters in a string match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **String and regex matching**.

1. Choose the condition that you want to add or delete filters in.

1. To add filters, perform the following steps:

   1. Choose **Add filter**.

   1. Specify the applicable filter settings. For more information, see [Values that you specify when you create or edit string match conditions](#classic-web-acl-string-conditions-values).

   1. Choose **Add**.

1. To delete filters, perform the following steps:

   1. Select the filter that you want to delete.

   1. Choose **Delete Filter**.

## Deleting string match conditions
<a name="classic-web-acl-string-conditions-deleting"></a>

If you want to delete a string match condition, you need to first delete all filters in the condition and remove the condition from all the rules that are using it, as described in the following procedure.<a name="classic-web-acl-string-conditions-deleting-procedure"></a>

**To delete a string match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. Remove the string match condition from the rules that are using it:

   1. In the navigation pane, choose **Rules**.

   1. Choose the name of a rule that is using the string match condition that you want to delete.

   1. In the right pane, choose **Edit rule**.

   1. Choose the **X** next to the condition you want to delete.

   1. Choose **Update**.

   1. Repeat for all the remaining rules that are using the string match condition that you want to delete.

1. Remove the filters from the condition you want to delete:

   1. In the navigation pane, choose **String and regex matching**.

   1. Choose the name of the string match condition that you want to delete.

   1. In the right pane, choose the check box next to **Filter** in order to select all of the filters.

   1. Choose the **Delete filter**.

1. In the navigation pane, choose **String and regex matching**.

1. In the **String and regex match conditions** pane, choose the string match condition that you want to delete.

1. Choose **Delete** to delete the selected condition.

# Working with regex match conditions
<a name="classic-web-acl-regex-conditions"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

If you want to allow or block web requests based on strings that match a regular expression (regex) pattern that appears in the requests, create one or more regex match conditions. A regex match condition is a type of string match condition that identifies the pattern that you want to search for and the part of web requests, such as a specified header or the query string, that you want AWS WAF Classic to inspect for the pattern. Later in the process, when you create a web ACL, you specify whether to allow or block requests that contain the pattern.

**Topics**
+ [Creating a regex match condition](#classic-web-acl-regex-conditions-creating)
+ [Values that you specify when you create or edit RegEx match conditions](#classic-web-acl-regex-conditions-values)
+ [Editing a regex match condition](#classic-web-acl-regex-conditions-editing)

## Creating a regex match condition
<a name="classic-web-acl-regex-conditions-creating"></a>

When you create regex match conditions, you specify pattern sets that identify the string (using a regular expression) that you want to search for. You then add those pattern sets to filters that specify the part of web requests that you want AWS WAF Classic to inspect for that pattern set, such as the URI or the query string.

You can add multiple regular expressions to a single pattern set. If you do so, those expressions are combined with an *OR*. That is, a web request will match the pattern set if the appropriate part of the request matches any of the expressions listed.

When you add a regex match condition to a rule, you also can configure AWS WAF Classic to allow or block web requests that *do not* match the values in the condition.

AWS WAF Classic supports most [standard Perl Compatible Regular Expressions (PCRE)](http://www.pcre.org/). However, the following are not supported:
+ Backreferences and capturing subexpressions
+ Arbitrary zero-width assertions
+ Subroutine references and recursive patterns
+ Conditional patterns
+ Backtracking control verbs
+ The \$1C single-byte directive
+ The \$1R newline match directive
+ The \$1K start of match reset directive
+ Callouts and embedded code
+ Atomic grouping and possessive quantifiers<a name="classic-web-acl-regex-conditions-creating-procedure"></a>

**To create a regex match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **String and regex matching**.

1. Choose **Create condition**.

1. Specify the applicable filter settings. For more information, see [Values that you specify when you create or edit RegEx match conditions](#classic-web-acl-regex-conditions-values).

1. Choose **Create pattern set and add filter** (if you created a new pattern set) or **Add filter** if you used an existing pattern set.

1. Choose **Create**.

## Values that you specify when you create or edit RegEx match conditions
<a name="classic-web-acl-regex-conditions-values"></a>

When you create or update a regex match condition, you specify the following values: 

**Name**  
Enter a name for the regex match condition. The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: \$1-\$1"\$1`\$1\$1\$1,./. You can't change the name of a condition after you create it.

**Type**  
Choose **Regex match**.

**Part of the request to filter on**  
Choose the part of each web request that you want AWS WAF Classic to inspect for the pattern that you specify in **Value to match**:    
**Header**  
A specified request header, for example, the `User-Agent` or `Referer` header. If you choose **Header**, specify the name of the header in the **Header** field.  
**HTTP method**  
The HTTP method, which indicates the type of operation that the request is asking the origin to perform. CloudFront supports the following methods: `DELETE`, `GET`, `HEAD`, `OPTIONS`, `PATCH`, `POST`, and `PUT`.  
**Query string**  
The part of a URL that appears after a `?` character, if any.  
**URI**  
The URI path of the request, which identifies the resource, for example, `/images/daily-ad.jpg`. This doesn't include the query string or fragment components of the URI. For information, see [Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986#section-3.3).   
Unless a **Transformation** is specified, a URI is not normalized and is inspected just as AWS receives it from the client as part of the request. A **Transformation** will reformat the URI as specified.  
**Body**  
The part of a request that contains any additional data that you want to send to your web server as the HTTP request body, such as data from a form.  
If you choose **Body** for the value of **Part of the request to filter on**, AWS WAF Classic inspects only the first 8192 bytes (8 KB). To allow or block requests for which the body is longer than 8192 bytes, you can create a size constraint condition. (AWS WAF Classic gets the length of the body from the request headers.) For more information, see [Working with size constraint conditions](classic-web-acl-size-conditions.md).  
**Single query parameter (value only)**  
Any parameter that you have defined as part of the query string. For example, if the URL is "www.xyz.com?UserName=abc&SalesRegion=seattle" you can add a filter to either the *UserName* or *SalesRegion* parameter.   
If duplicate parameters appear in the query string, the values are evaluated as an "OR." That is, either value will trigger a match. For example, in the URL "www.xyz.com?SalesRegion=boston&SalesRegion=seattle", a pattern that matches either "boston" or "seattle" in **Value to match** will trigger a match.  
If you choose **Single query parameter (value only)** you will also specify a **Query parameter name**. This is the parameter in the query string that you will inspect, such as *UserName* or *SalesRegion*. The maximum length for **Query parameter name** is 30 characters. **Query parameter name** is not case sensitive. For example, it you specify *UserName* as the **Query parameter name**, this will match all variations of *UserName*, such as *username* and *UsERName*.  
**All query parameters (values only)**  
Similar to **Single query parameter (value only)**, but rather than inspecting the value of a single parameter, AWS WAF Classic inspects the value of all parameters within the query string for the pattern specified in the **Value to match**. For example, in the URL "www.xyz.com?UserName=abc&SalesRegion=seattle", a pattern in **Value to match** that matches either the value in *UserName* or *SalesRegion* will trigger a match.

**Header (Only When "Part of the request to filter on" is "Header")**  
If you chose **Header** from the **Part of the request to filter on** list, choose a header from the list of common headers, or enter the name of a header that you want AWS WAF Classic to inspect.

**Transformation**  
A transformation reformats a web request before AWS WAF Classic inspects the request. This eliminates some of the unusual formatting that attackers use in web requests in an effort to bypass AWS WAF Classic.   
You can only specify a single type of text transformation.  
Transformations can perform the following operations:    
**None**  
AWS WAF Classic doesn't perform any text transformations on the web request before inspecting it for the string in **Value to match**.  
**Convert to lowercase**  
AWS WAF Classic converts uppercase letters (A-Z) to lowercase (a-z).  
**HTML decode**  
AWS WAF Classic replaces HTML-encoded characters with unencoded characters:  
+ Replaces `&quot;` with `&`
+ Replaces `&nbsp;` with a non-breaking space
+ Replaces `&lt;` with `<`
+ Replaces `&gt;` with `>`
+ Replaces characters that are represented in hexadecimal format, `&#xhhhh;`, with the corresponding characters
+ Replaces characters that are represented in decimal format, `&#nnnn;`, with the corresponding characters  
**Normalize white space**  
AWS WAF Classic replaces the following characters with a space character (decimal 32):  
+ \$1f, formfeed, decimal 12
+ \$1t, tab, decimal 9
+ \$1n, newline, decimal 10
+ \$1r, carriage return, decimal 13
+ \$1v, vertical tab, decimal 11
+ non-breaking space, decimal 160
In addition, this option replaces multiple spaces with one space.  
**Simplify command line**  
When you're concerned that attackers are injecting an operating system command line command and using unusual formatting to disguise some or all of the command, use this option to perform the following transformations:  
+ Delete the following characters: \$1 " ' ^
+ Delete spaces before the following characters: / (
+ Replace the following characters with a space: , ;
+ Replace multiple spaces with one space
+ Convert uppercase letters (A-Z) to lowercase (a-z)  
**URL decode**  
Decode a URL-encoded request.

**Regex pattern to match to request**  
You can choose an existing pattern set, or create a new one. If you create a new one specify the following:    
New pattern set name  
Enter a name and then specify the regex pattern that you want AWS WAF Classic to search for.   
If you add multiple regular expressions to a pattern set, those expressions are combined with an *OR*. That is, a web request will match the pattern set if the appropriate part of the request matches any of the expressions listed.  
The maximum length of **Value to match** is 70 characters. 

## Editing a regex match condition
<a name="classic-web-acl-regex-conditions-editing"></a>

You can make the following changes to an existing regex match condition:
+ Delete a pattern from an existing pattern set
+ Add a pattern to an existing pattern set
+ Delete a filter to an existing regex match condition
+ Add a filter to an existing regex match condition (You can have only one filter in a regex match condition. Therefore, in order to add a filter, you must delete the existing filter first.)
+ Delete an existing regex match condition

**Note**  
You cannot add or delete a pattern set from an existing filter. You must either edit the pattern set, or delete the filter and create a new filter with a new pattern set.<a name="classic-web-acl-regex-conditions-editing-procedure-delete-pattern"></a>

**To delete a pattern from an existing pattern set**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **String and regex matching**.

1. Choose **View regex pattern sets**.

1. Choose the name of the pattern set you want to edit.

1. Choose **Edit**.

1. Choose the **X** next to the pattern you want to delete.

1. Choose **Save**.<a name="classic-web-acl-regex-conditions-editing-procedure-add-pattern"></a>

**To add a pattern to an existing pattern set**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **String and regex matching**.

1. Choose **View regex pattern sets**.

1. Choose the name of the pattern set to edit.

1. Choose **Edit**.

1. Enter a new regex pattern.

1. Choose the **\$1** next to the new pattern.

1. Choose **Save**.<a name="classic-web-acl-regex-conditions-editing-procedure-delete-filter"></a>

**To delete a filter from an existing regex match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **String and regex matching**.

1. Choose the name of the condition with the filter you want to delete.

1. Choose the box next to the filter you want to delete.

1. Choose **Delete filter**.<a name="classic-web-acl-regex-conditions-editing-procedure-delete-regex-condition"></a>

**To delete a regex match condition**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. Delete the filter from the regex condition. See [To delete a filter from an existing regex match condition](#classic-web-acl-regex-conditions-editing-procedure-delete-filter) for instructions to do this.)

1. Remove the regex match condition from the rules that are using it:

   1. In the navigation pane, choose **Rules**.

   1. Choose the name of a rule that is using the regex match condition that you want to delete.

   1. In the right pane, choose **Edit rule**.

   1. Choose the **X** next to the condition you want to delete.

   1. Choose **Update**.

   1. Repeat for all the remaining rules that are using the regex match condition that you want to delete.

1. In the navigation pane, choose **String and regex matching**.

1. Select the button next to the condition you want to delete.

1. Choose **Delete**.<a name="classic-web-acl-regex-conditions-editing-procedure-add-filter"></a>

**To add or change a filter to an existing regex match condition**

You can have only one filter in a regex match condition. If you want to add or change the filter, you must first delete the existing filter.

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. Delete the filter from the regex condition you want to change. See [To delete a filter from an existing regex match condition](#classic-web-acl-regex-conditions-editing-procedure-delete-filter) for instructions to do this.)

1. In the navigation pane, choose **String and regex matching**.

1. Choose the name of the condition you want to change.

1. Choose **Add filter**.

1. Enter the appropriate values for the new filter and choose **Add**.

# Working with rules
<a name="classic-web-acl-rules"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

Rules let you precisely target the web requests that you want AWS WAF Classic to allow or block by specifying the exact conditions that you want AWS WAF Classic to watch for. For example, AWS WAF Classic can watch for the IP addresses that requests originate from, the strings that the requests contain and where the strings appear, and whether the requests appear to contain malicious SQL code.

**Topics**
+ [Creating a rule and adding conditions](classic-web-acl-rules-creating.md)
+ [Adding and removing conditions in a rule](classic-web-acl-rules-editing.md)
+ [Deleting a rule](classic-web-acl-rules-deleting.md)
+ [AWS Marketplace rule groups](classic-waf-managed-rule-groups.md)

# Creating a rule and adding conditions
<a name="classic-web-acl-rules-creating"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

If you add more than one condition to a rule, a web request must match all the conditions for AWS WAF Classic to allow or block requests based on that rule.<a name="classic-web-acl-rules-creating-procedure"></a>

**To create a rule and add conditions**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Rules**.

1. Choose **Create rule**.

1. Enter the following values:  
**Name**  
Enter a name.   
**CloudWatch metric name**  
Enter a name for the CloudWatch metric that AWS WAF Classic will create and will associate with the rule. The name can contain only alphanumeric characters (A-Z, a-z, 0-9), with maximum length 128 and minimum length one. It can't contain white space or metric names reserved for AWS WAF Classic, including "All" and "Default\$1Action.  
**Rule type**  
Choose either `Regular rule` or `Rate–based rule`. Rate–based rules are identical to regular rules, but also take into account how many requests arrive from an IP address in a five-minute period. For more information about these rule types, see [How AWS WAF Classic works](classic-how-aws-waf-works.md).  
**Rate limit**  
For a rate-based rule, enter the maximum number of requests to allow in any five-minute period from an IP address that matches the rule's conditions. The rate limit must be at least 100.   
You can specify a rate limit alone, or a rate limit and conditions. If you specify only a rate limit, AWS WAF places the limit on all IP addresses. If you specify a rate limit and conditions, AWS WAF places the limit on IP addresses that match the conditions.   
When an IP address reaches the rate limit threshold, AWS WAF applies the assigned action (block or count) as quickly as possible, usually within 30 seconds. Once the action is in place, if five minutes pass with no requests from the IP address, AWS WAF resets the counter to zero.

1. To add a condition to the rule, specify the following values:   
**When a request does/does not**  
If you want AWS WAF Classic to allow or block requests based on the filters in a condition, choose **does**. For example, if an IP match condition includes the IP address range 192.0.2.0/24 and you want AWS WAF Classic to allow or block requests that come from those IP addresses, choose **does**.  
If you want AWS WAF Classic to allow or block requests based on the inverse of the filters in a condition, choose **does not**. For example, if an IP match condition includes the IP address range 192.0.2.0/24 and you want AWS WAF Classic to allow or block requests that *do not* come from those IP addresses, choose **does not**.  
**match/originate from**  
Choose the type of condition that you want to add to the rule:  
   + Cross-site scripting match conditions – choose **match at least one of the filters in the cross-site scripting match condition**
   + IP match conditions – choose **originate from an IP address in**
   + Geo match conditions – choose **originate from a geographic location in**
   + Size constraint conditions – choose **match at least one of the filters in the size constraint condition**
   + SQL injection match conditions – choose **match at least one of the filters in the SQL injection match condition**
   + String match conditions – choose **match at least one of the filters in the string match condition**
   + Regular expression match conditions – choose **match at least one of the filters in the regex match condition**  
**condition name**  
Choose the condition that you want to add to the rule. The list displays only conditions of the type that you chose in the preceding step.

1. To add another condition to the rule, choose **Add another condition**, and repeat steps 4 and 5. Note the following:
   + If you add more than one condition, a web request must match at least one filter in every condition for AWS WAF Classic to allow or block requests based on that rule 
   + If you add two IP match conditions to the same rule, AWS WAF Classic will only allow or block requests that originate from IP addresses that appear in both IP match conditions 

1. When you're finished adding conditions, choose **Create**.

# Adding and removing conditions in a rule
<a name="classic-web-acl-rules-editing"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

You can change a rule by adding or removing conditions. <a name="classic-web-acl-rules-editing-procedure"></a>

**To add or remove conditions in a rule**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Rules**.

1. Choose the name of the rule in which you want to add or remove conditions.

1. Choose **Add rule**.

1. To add a condition, choose **Add condition** and specify the following values:  
**When a request does/does not**  
If you want AWS WAF Classic to allow or block requests based on the filters in a condition, for example, web requests that originate from the range of IP addresses 192.0.2.0/24, choose **does**.  
If you want AWS WAF Classic to allow or block requests based on the inverse of the filters in a condition, choose **does not**. For example, if an IP match condition includes the IP address range 192.0.2.0/24 and you want AWS WAF Classic to allow or block requests that *do not* come from those IP addresses, choose **does not**.  
**match/originate from**  
Choose the type of condition that you want to add to the rule:  
   + Cross-site scripting match conditions – choose **match at least one of the filters in the cross-site scripting match condition**
   + IP match conditions – choose **originate from an IP address in**
   + Geo match conditions – choose **originate from a geographic location in**
   + Size constraint conditions – choose **match at least one of the filters in the size constraint condition**
   + SQL injection match conditions – choose **match at least one of the filters in the SQL injection match condition**
   + String match conditions – choose **match at least one of the filters in the string match condition**
   + Regular expression match conditions – choose **match at least one of the filters in the regex match condition**  
***condition name***  
Choose the condition that you want to add to the rule. The list displays only conditions of the type that you chose in the preceding step.

1. To remove a condition, select the **X** to the right of the condition name

1. Choose **Update**.

# Deleting a rule
<a name="classic-web-acl-rules-deleting"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

If you want to delete a rule, you need to first remove the rule from the web ACLs that are using it and remove the conditions that are included in the rule.<a name="classic-web-acl-rules-deleting-procedure"></a>

**To delete a rule**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. To remove the rule from the web ACLs that are using it, perform the following steps for each of the web ACLs:

   1. In the navigation pane, choose **Web ACLs**.

   1. Choose the name of a web ACL that is using the rule that you want to delete.
**Note**  
If you don't see the web ACL, make sure the Region selection is correct. Web ACLs that protect Amazon CloudFront distributions are in **Global (CloudFront)**.

   1. Choose the **Rules** tab.

   1. Choose **Edit web ACL**.

   1. Choose the **X** to the right of the rule that you want to delete, and then choose **Update**.

1. In the navigation pane, choose **Rules**.

1. Select the name of the rule you want to delete.
**Note**  
If you don't see the rule, make sure the Region selection is correct. Rules that protect Amazon CloudFront distributions are in **Global (CloudFront)**.

1. Choose **Delete**.

# AWS Marketplace rule groups
<a name="classic-waf-managed-rule-groups"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

AWS WAF Classic provides *AWS Marketplace rule groups* to help you protect your resources. AWS Marketplace rule groups are collections of predefined, ready-to-use rules that are written and updated by AWS and AWS partner companies.

Some AWS Marketplace rule groups are designed to help protect specific types of web applications like WordPress, Joomla, or PHP. Other AWS Marketplace rule groups offer broad protection against known threats or common web application vulnerabilities, such as those listed in the [OWASP Top 10](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).

You can install a single AWS Marketplace rule group from your preferred AWS partner, and you can also add your own customized AWS WAF Classic rules for increased protection. If you are subject to regulatory compliance like PCI or HIPAA, you might be able to use AWS Marketplace rule groups to satisfy web application firewall requirements.

AWS Marketplace rule groups are available with no long-term contracts, and no minimum commitments. When you subscribe to a rule group, you are charged a monthly fee (prorated hourly) and ongoing request fees based on volume. For more information, see [AWS WAF Classic Pricing](https://aws.amazon.com/waf/pricing/) and the description for each AWS Marketplace rule group on AWS Marketplace.

## Automatic updates
<a name="classic-waf-managed-rule-group-updates"></a>

Keeping up to date on the constantly changing threat landscape can be time consuming and expensive. AWS Marketplace rule groups can save you time when you implement and use AWS WAF Classic. Another benefit is that AWS and our AWS partners automatically update AWS Marketplace rule groups when new vulnerabilities and threats emerge.

Many of our partners are notified of new vulnerabilities before public disclosure. They can update their rule groups and deploy them to you even before a new threat is widely known. Many also have threat research teams to investigate and analyze the most recent threats in order to write the most relevant rules.

## Access to the rules in an AWS Marketplace rule group
<a name="classic-waf-managed-rule-group-edits"></a>

Each AWS Marketplace rule group provides a comprehensive description of the types of attacks and vulnerabilities that it's designed to protect against. To protect the intellectual property of the rule group providers, you can't view the individual rules within a rule group. This restriction also helps to keep malicious users from designing threats that specifically circumvent published rules.

Because you can’t view individual rules in an AWS Marketplace rule group, you also can't edit any rules in an AWS Marketplace rule group. However, you can exclude specific rules from a rule group. This is called a "rule group exception." Excluding rules does not remove those rules. Rather, it changes the action for the rules to `COUNT`. Therefore, requests that match an excluded rule are counted but not blocked. You will receive COUNT metrics for each excluded rule.

Excluding rules can be helpful when troubleshooting rule groups that are blocking traffic unexpectedly (false positives). One troubleshooting technique is to identify the specific rule within the rule group that is blocking the desired traffic and then disable (exclude) that particular rule.

In addition to excluding specific rules, you can refine your protection by enabling or disabling entire rule groups, as well as choosing the rule group action to perform. For more information, see [Using AWS Marketplace rule groups](#classic-waf-managed-rule-group-using). 

## Quotas
<a name="classic-waf-managed-rule-group-limits"></a>

You can enable only one AWS Marketplace rule group. You can also enable one custom rule group that you create using AWS Firewall Manager. These rule groups count towards the 10 rule maximum quota per web ACL. Therefore, you can have one AWS Marketplace rule group, one custom rule group, and up to eight custom rules in a single web ACL.

## Pricing
<a name="classic-waf-managed-rule-group-pricing"></a>

For AWS Marketplace rule group pricing, see [AWS WAF Classic Pricing](https://aws.amazon.com/waf/pricing/) and the description for each AWS Marketplace rule group on AWS Marketplace.

## Using AWS Marketplace rule groups
<a name="classic-waf-managed-rule-group-using"></a>

You can subscribe to and unsubscribe from AWS Marketplace rule groups on the AWS WAF Classic console. You can also exclude specific rules from a rule group.<a name="classic-waf-managed-rule-group-using-procedure"></a>

**To subscribe to and use an AWS Marketplace rule group**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Marketplace**.

1. In the **Available marketplace products** section, choose the name of a rule group to view the details and pricing information.

1. If you want to subscribe to the rule group, choose **Continue**.
**Note**  
If you don't want to subscribe to this rule group, simply close this page in your browser.

1. Choose **Set up your account**.

1. Add the rule group to a web ACL, just as you would add an individual rule. For more information, see [Creating a Web ACL](classic-web-acl-creating.md) or [Editing a Web ACL](classic-web-acl-editing.md).
**Note**  
When adding a rule group to a web ACL, the action that you set for the rule group (either **No override** or **Override to count**) is called the rule group override action. For more information, see [Rule group override](#classic-waf-managed-rule-group-override).<a name="classic-waf-managed-rule-group-unsubscribe-procedure"></a>

**To unsubscribe from an AWS Marketplace rule group**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. Remove the rule group from all web ACLs. For more information, see [Editing a Web ACL](classic-web-acl-editing.md).

1. In the navigation pane, choose **Marketplace**.

1. Choose **Manage your subscriptions**.

1. Choose **Cancel subscription** next to the name of the rule group that you want to unsubscribe from.

1. Choose **Yes, cancel subscription**.<a name="classic-waf-managed-rule-group-exclude-rule-procedure"></a>

**To exclude a rule from a rule group (rule group exception)**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. If not already enabled, enable AWS WAF Classic logging. For more information, see [Logging Web ACL traffic information](classic-logging.md). Use the AWS WAF Classic logs to identify the IDs of the rules that you want to exclude. These are typically rules that are blocking legitimate requests.

1. In the navigation pane, choose **Web ACLs**.

1. Choose the name of the web ACL that you want to edit. This opens a page with the web ACL's details in the right pane.
**Note**  
The rule group that you want to edit must be associated with a web ACL before you can exclude a rule from that rule group.

1. On the **Rules** tab in the right pane, choose **Edit web ACL**.

1. In the **Rule group exceptions** section, expand the rule group that you want to edit.

1. Choose the **X** next to the rule that you want to exclude. You can identify the correct rule ID by using the AWS WAF Classic logs.

1. Choose **Update**.

   Excluding rules does not remove those rules from the rule group. Rather, it changes the action for the rules to `COUNT`. Therefore, requests that match an excluded rule are counted but not blocked. You will receive `COUNT` metrics for each excluded rule.
**Note**  
You can use this same procedure to exclude rules from custom rule groups that you have created in AWS Firewall Manager. However, rather than excluding a rule from a custom rule group using these steps, you can also simply edit a custom rule group using the steps described in [Adding and deleting rules from an AWS WAF Classic rule group](classic-rule-group-editing.md).

## Rule group override
<a name="classic-waf-managed-rule-group-override"></a>

AWS Marketplace rule groups have two possible actions: **No override** and **Override to count**. If you want to test the rule group, set the action to **Override to count**. This rule group action overrides any *block* action that is specified by individual rules contained within the group. That is, if the rule group's action is set to **Override to count**, instead of potentially blocking matching requests based on the action of individual rules within the group, those requests will be counted. Conversely, if you set the rule group's action to **No override**, actions of the individual rules within the group will be used.

## Troubleshooting AWS Marketplace rule groups
<a name="classic-waf-managed-rule-group-troubleshooting"></a>

If you find that an AWS Marketplace rule group is blocking legitimate traffic, perform the following steps.<a name="classic-waf-managed-rule-group-troubleshooting-procedure"></a>

**To troubleshoot an AWS Marketplace rule group**

1. Exclude the specific rules that are blocking legitimate traffic. You can identify which rules are blocking which requests using the AWS WAF Classic logs. For more information about excluding rules, see [To exclude a rule from a rule group (rule group exception)](#classic-waf-managed-rule-group-exclude-rule-procedure).

1. If excluding specific rules does not solve the problem, you can change the action for the AWS Marketplace rule group from **No override** to **Override to count**. This allows the web request to pass through, regardless of the individual rule actions within the rule group. This also provides you with Amazon CloudWatch metrics for the rule group.

1. After setting the AWS Marketplace rule group action to **Override to count**, contact the rule group provider‘s customer support team to further troubleshoot the issue. For contact information, see the rule group listing on the product listing pages on AWS Marketplace.

### Contacting customer support
<a name="classic-waf-managed-rule-group-troubleshooting-support"></a>

For problems with AWS WAF Classic or a rule group that is managed by AWS, contact AWS Support. For problems with a rule group that is managed by an AWS partner, contact that partner's customer support team. To find partner contact information, see the partner’s listing on AWS Marketplace.

## Creating and selling AWS Marketplace rule groups
<a name="classic-waf-managed-rule-group-creating"></a>

If you want to sell AWS Marketplace rule groups on AWS Marketplace, see [How to Sell Your Software on AWS Marketplace](https://aws.amazon.com/marketplace/management/tour/).

# Working with web ACLs
<a name="classic-web-acl-working-with"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

When you add rules to a web ACL, you specify whether you want AWS WAF Classic to allow or block requests based on the conditions in the rules. If you add more than one rule to a web ACL, AWS WAF Classic evaluates each request against the rules in the order that you list them in the web ACL. When a web request matches all the conditions in a rule, AWS WAF Classic immediately takes the corresponding action—allow or block—and doesn't evaluate the request against the remaining rules in the web ACL, if any. 

If a web request doesn't match any of the rules in a web ACL, AWS WAF Classic takes the default action that you specified for the web ACL. For more information, see [Deciding on the default action for a Web ACL](classic-web-acl-default-action.md).

If you want to test a rule before you start using it to allow or block requests, you can configure AWS WAF Classic to count the web requests that match the conditions in the rule. For more information, see [Testing web ACLs](classic-web-acl-testing.md).

**Topics**
+ [Deciding on the default action for a Web ACL](classic-web-acl-default-action.md)
+ [Creating a Web ACL](classic-web-acl-creating.md)
+ [Associating or disassociating a Web ACL with an Amazon API Gateway API, a CloudFront distribution or an Application Load Balancer](classic-web-acl-associating-cloudfront-distribution.md)
+ [Editing a Web ACL](classic-web-acl-editing.md)
+ [Deleting a Web ACL](classic-web-acl-deleting.md)
+ [Testing web ACLs](classic-web-acl-testing.md)

# Deciding on the default action for a Web ACL
<a name="classic-web-acl-default-action"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

When you create and configure a web ACL, the first and most important decision that you must make is whether the default action should be for AWS WAF Classic to allow web requests or to block web requests. The default action indicates what you want AWS WAF Classic to do after it inspects a web request for all the conditions that you specify, and the web request doesn't match any of those conditions:
+ **Allow** – If you want to allow most users to access your website, but you want to block access to attackers whose requests originate from specified IP addresses, or whose requests appear to contain malicious SQL code or specified values, choose **Allow** for the default action.
+ **Block** – If you want to prevent most would-be users from accessing your website, but you want to allow access to users whose requests originate from specified IP addresses, or whose requests contain specified values, choose **Block** for the default action.

Many decisions that you make after you've decided on a default action depend on whether you want to allow or block most web requests. For example, if you want to *allow* most requests, then the match conditions that you create generally should specify the web requests that you want to *block*, such as the following:
+ Requests that originate from IP addresses that are making an unreasonable number of requests
+ Requests that originate from countries that either you don't do business in or are the frequent source of attacks
+ Requests that include fake values in the **User-Agent** header
+ Requests that appear to include malicious SQL code

# Creating a Web ACL
<a name="classic-web-acl-creating"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). <a name="classic-web-acl-creating-procedure"></a>

**To create a web ACL**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. If this is your first time using AWS WAF Classic, choose **Go to AWS WAF Classic** and then **Configure Web ACL**. If you've used AWS WAF Classic before, choose **Web ACLs** in the navigation pane, and then choose **Create web ACL**.

1. For **Web ACL name**, enter a name. 
**Note**  
You can't change the name after you create the web ACL.

1. For **CloudWatch metric name**, change the default name if applicable. The name can contain only alphanumeric characters (A-Z, a-z, 0-9), with maximum length 128 and minimum length one. It can't contain white space or metric names reserved for AWS WAF Classic, including "All" and "Default\$1Action."
**Note**  
You can't change the name after you create the web ACL.

1. For **Region**, choose a Region.

1.  For **AWS resource**, choose the resource that you want to associate with this web ACL, and then choose **Next**.

1. If you've already created the conditions that you want AWS WAF Classic to use to inspect your web requests, choose **Next**, and then continue to the next step.

   If you haven't already created conditions, do so now. For more information, see the following topics:
   + [Working with cross-site scripting match conditions](classic-web-acl-xss-conditions.md)
   + [Working with IP match conditions](classic-web-acl-ip-conditions.md)
   + [Working with geographic match conditions](classic-web-acl-geo-conditions.md)
   + [Working with size constraint conditions](classic-web-acl-size-conditions.md)
   + [Working with SQL injection match conditions](classic-web-acl-sql-conditions.md)
   + [Working with string match conditions](classic-web-acl-string-conditions.md)
   + [Working with regex match conditions](classic-web-acl-regex-conditions.md)

1. If you've already created the rules or rule groups (or subscribed to an AWS Marketplace rule group) that you want to add to this web ACL, add the rules to the web ACL:

   1. In the **Rules** list, choose a rule.

   1. Choose **Add rule to web ACL**.

   1. Repeat steps a and b until you've added all the rules that you want to add to this web ACL.

   1. Go to step 10.

1. If you haven't created rules yet, you can add rules now:

   1. Choose **Create rule**.

   1. Enter the following values:  
**Name**  
Enter a name.  
**CloudWatch metric name**  
Enter a name for the CloudWatch metric that AWS WAF Classic will create and will associate with the rule. The name can contain only alphanumeric characters (A-Z, a-z, 0-9), with maximum length 128 and minimum length one. It can't contain white space or metric names reserved for AWS WAF Classic, including "All" and "Default\$1Action."  
You can't change the metric name after you create the rule.

   1. To add a condition to the rule, specify the following values:   
**When a request does/does not**  
If you want AWS WAF Classic to allow or block requests based on the filters in a condition, for example, web requests that originate from the range of IP addresses 192.0.2.0/24, choose **does**.  
If you want AWS WAF Classic to allow or block requests based on the inverse of the filters in a condition, choose **does not**. For example, if an IP match condition includes the IP address range 192.0.2.0/24 and you want AWS WAF Classic to allow or block requests that *do not* come from those IP addresses, choose **does not**.  
**match/originate from**  
Choose the type of condition that you want to add to the rule:  
      + Cross-site scripting match conditions – choose **match at least one of the filters in the cross-site scripting match condition**
      + IP match conditions – choose **originate from an IP address in**
      + Geo match conditions – choose **originate from a geographic location in**
      + Size constraint conditions – choose **match at least one of the filters in the size constraint condition**
      + SQL injection match conditions – choose **match at least one of the filters in the SQL injection match condition**
      + String match conditions – choose **match at least one of the filters in the string match condition**
      + Regex match conditions – choose **match at least one of the filters in the regex match condition**  
**condition name**  
Choose the condition that you want to add to the rule. The list displays only conditions of the type that you chose in the preceding list.

   1. To add another condition to the rule, choose **Add another condition**, and then repeat steps b and c. Note the following:
      + If you add more than one condition, a web request must match at least one filter in every condition for AWS WAF Classic to allow or block requests based on that rule. 
      + If you add two IP match conditions to the same rule, AWS WAF Classic will only allow or block requests that originate from IP addresses that appear in both IP match conditions. 

   1. Repeat step 9 until you've created all the rules that you want to add to this web ACL. 

   1. Choose **Create**.

   1. Continue with step 10.

1. For each rule or rule group in the web ACL, choose the kind of management you want AWS WAF Classic to provide, as follows: 
   + For each rule, choose whether you want AWS WAF Classic to allow, block, or count web requests based on the conditions in the rule:
     + **Allow** – API Gateway, CloudFront or an Application Load Balancer responds with the requested object. In the case of CloudFront, if the object isn't in the edge cache, CloudFront forwards the request to the origin.
     + **Block** – API Gateway, CloudFront or an Application Load Balancer responds to the request with an HTTP 403 (Forbidden) status code. CloudFront also can respond with a custom error page. For more information, see [Using AWS WAF Classic with CloudFront custom error pages](classic-cloudfront-features.md#classic-cloudfront-features-custom-error-pages).
     + **Count** – AWS WAF Classic increments a counter of requests that match the conditions in the rule, and then continues to inspect the web request based on the remaining rules in the web ACL. 

       For information about using **Count** to test a web ACL before you start to use it to allow or block web requests, see [Counting the web requests that match the rules in a web ACL](classic-web-acl-testing.md#classic-web-acl-testing-count). 
   + For each rule group, set the override action for the rule group: 
     + **No override** – Causes the actions of the individual rules within the rule group to be used.
     + **Override to count** – Overrides any block actions that are specifieid by individual rules in the group, so that all matching requests are only counted. 

     For more information, see [Rule group override](classic-waf-managed-rule-groups.md#classic-waf-managed-rule-group-override).

1. If you want to change the order of the rules in the web ACL, use the arrows in the **Order** column. AWS WAF Classic inspects web requests based on the order in which rules appear in the web ACL. 

1. If you want to remove a rule that you added to the web ACL, choose the **x** in the row for the rule.

1. Choose the default action for the web ACL. This is the action that AWS WAF Classic takes when a web request doesn't match the conditions in any of the rules in this web ACL. For more information, see [Deciding on the default action for a Web ACL](classic-web-acl-default-action.md).

1. Choose **Review and create**.

1. Review the settings for the web ACL, and choose **Confirm and create**.

# Associating or disassociating a Web ACL with an Amazon API Gateway API, a CloudFront distribution or an Application Load Balancer
<a name="classic-web-acl-associating-cloudfront-distribution"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

To associate or disassociate a web ACL, perform the applicable procedure. Note that you also can associate a web ACL with a CloudFront distribution when you create or update the distribution. For more information, see [Using AWS WAF Classic to Control Access to Your Content](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html) in the *Amazon CloudFront Developer Guide*.

The following restrictions apply when associating a web ACL:
+ Each API Gateway API, Application Load Balancer and CloudFront distribution can be associated with only one web ACL.
+ Web ACLs associated with a CloudFront distribution cannot be associated with an Application Load Balancer or API Gateway API. The web ACL can, however, be associated with other CloudFront distributions.

**To associate a web ACL with an API Gateway API, CloudFront distribution or Application Load Balancer**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Web ACLs**.

1. Choose the name of the web ACL that you want to associate with an API Gateway API, CloudFront distribution or Application Load Balancer. This opens a page with the web ACL's details in the right pane. 

1. On the **Rules** tab, under **AWS resources using this web ACL**, choose **Add association**.

1. When prompted, use the **Resource** list to choose the API Gateway API, CloudFront distribution or Application Load Balancer that you want to associate this web ACL with. If you choose an Application Load Balancer, you also must specify a Region.

1. Choose **Add**.

1. To associate this web ACL with an additional API Gateway API, CloudFront distribution or another Application Load Balancer, repeat steps 4 through 6.<a name="classic-web-acl-disassociating-cloudfront-distribution-procedure"></a>

**To disassociate a web ACL from an API Gateway API, CloudFront distribution or Application Load Balancer**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Web ACLs**.

1. Choose the name of the web ACL that you want to disassociate from an API Gateway API, CloudFront distribution or Application Load Balancer. This opens a page with the web ACL's details in the right pane. 

1. On the **Rules** tab, under **AWS resources using this web ACL**, choose the **x** for each API Gateway API, CloudFront distribution or Application Load Balancer that you want to disassociate this web ACL from.

# Editing a Web ACL
<a name="classic-web-acl-editing"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

To add or remove rules from a web ACL or change the default action, perform the following procedure. <a name="classic-web-acl-editing-procedure"></a>

**To edit a web ACL**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Web ACLs**.

1. Choose the name of the web ACL that you want to edit. This opens a page with the web ACL's details in the right pane.

1. On the **Rules** tab in the right pane, choose **Edit web ACL**.

1. To add rules to the web ACL, perform the following steps:

   1. In the **Rules** list, choose the rule that you want to add. 

   1. Choose **Add rule to web ACL**.

   1. Repeat steps a and b until you've added all the rules that you want.

1. If you want to change the order of the rules in the web ACL, use the arrows in the **Order** column. AWS WAF Classic inspects web requests based on the order in which rules appear in the web ACL. 

1. To remove a rule from the web ACL, choose the **x** at the right of the row for that rule. This doesn't delete the rule from AWS WAF Classic, it just removes the rule from this web ACL.

1. To change the action for a rule or the default action for the web ACL, choose the preferred option.
**Note**  
When setting the action for a rule group or an AWS Marketplace rule group (as opposed to a single rule), the action you set for the rule group (either **No override** or **Override to count**) is called the override action. For more information, see [Rule group override](classic-waf-managed-rule-groups.md#classic-waf-managed-rule-group-override)

1. Choose **Save changes**.

# Deleting a Web ACL
<a name="classic-web-acl-deleting"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

**Important**  
Deleting a web ACL is permanent and can't be undone. If the selected web ACL contains any rules or is associated with any CloudFront distributions, Application load balancer or API Gateway, remove the rules and associations before deleting. Otherwise, the delete will fail.

To delete a web ACL, you must remove the rules that are included in the web ACL and disassociate all CloudFront distributions and Application Load Balancers from the web ACL. Perform the following procedure.<a name="classic-web-acl-deleting-procedure"></a>

**To delete a web ACL**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Web ACLs**.

1. Choose the name of the web ACL that you want to delete. This opens a page with the web ACL's details in the right pane.
**Note**  
If you don't see the web ACL, make sure the Region selection is correct. Web ACLs that protect Amazon CloudFront distributions are in **Global (CloudFront)**.

1. On the **Rules** tab in the right pane, choose **Edit web ACL**.

1. To remove all rules from the web ACL, choose the **x** at the right of the row for each rule. This doesn't delete the rules from AWS WAF Classic, it just removes the rules from this web ACL.

1. Choose **Update**.

1. Disassociate the web ACL from all CloudFront distributions and Application Load Balancers. On the **Rules** tab, under **AWS resources using this web ACL**, choose the **x** for each API Gateway API, CloudFront distribution or Application Load Balancer.

1. On the **Web ACLs** page, confirm that the web ACL that you want to delete is selected, and then choose **Delete**.

# Testing web ACLs
<a name="classic-web-acl-testing"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

To ensure that you don't accidentally configure AWS WAF Classic to block web requests that you want to allow or allow requests that you want to block, we recommend that you test your web ACL thoroughly before you start using it on your website or web application. 

**Topics**
+ [Counting the web requests that match the rules in a web ACL](#classic-web-acl-testing-count)
+ [Viewing a sample of the web requests that API Gateway CloudFront or an Application Load Balancer has forwarded to AWS WAF Classic](#classic-web-acl-testing-view-sample)

## Counting the web requests that match the rules in a web ACL
<a name="classic-web-acl-testing-count"></a>

When you add rules to a web ACL, you specify whether you want AWS WAF Classic to allow, block, or count the web requests that match all the conditions in that rule. We recommend that you begin with the following configuration:
+ Configure all the rules in a web ACL to count web requests
+ Set the default action for the web ACL to allow requests

In this configuration, AWS WAF Classic inspects each web request based on the conditions in the first rule. If the web request matches all the conditions in that rule, AWS WAF Classic increments a counter for that rule. Then AWS WAF Classic inspects the web request based on the conditions in the next rule. If the request matches all the conditions in that rule, AWS WAF Classic increments a counter for the rule. This continues until AWS WAF Classic has inspected the request based on the conditions in all of your rules. 

After you've configured all the rules in a web ACL to count requests and associated the web ACL with an Amazon API Gateway API, CloudFront distribution or Application Load Balancer, you can view the resulting counts in an Amazon CloudWatch graph. For each rule in a web ACL and for all the requests that API Gateway, CloudFront or an Application Load Balancer forwards to AWS WAF Classic for a web ACL, CloudWatch lets you:
+ View data for the preceding hour or preceding three hours,
+ Change the interval between data points
+ Change the calculation that CloudWatch performs on the data, such as maximum, minimum, average, or sum

**Note**  
AWS WAF Classic with CloudFront is a global service and metrics are available only when you choose the **US East (N. Virginia) Region** in the AWS Management Console. If you choose another region, no AWS WAF Classic metrics will appear in the CloudWatch console.<a name="classic-web-acl-testing-count-procedure"></a>

**To view data for the rules in a web ACL**

1. Sign in to the AWS Management Console and open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. In the navigation pane, under **Metrics**, choose **WAF**.

1. Select the check box for the web ACL that you want to view data for.

1. Change the applicable settings:  
**Statistic**  
Choose the calculation that CloudWatch performs on the data.  
**Time range**  
Choose whether you want to view data for the preceding hour or the preceding three hours.  
**Period**  
Choose the interval between data points in the graph.  
**Rules**  
Choose the rules for which you want to view data.

   Note the following:
   + If you just associated a web ACL with an API Gateway API, CloudFront distribution or Application Load Balancer, you might need to wait a few minutes for data to appear in the graph and for the metric for the web ACL to appear in the list of available metrics.
   + If you associate more than one API Gateway API, CloudFront distribution or Application Load Balancer with a web ACL, the CloudWatch data will include all the requests for all the distributions that are associated with the web ACL.
   + You can hover the mouse cursor over a data point to get more information.
   + The graph doesn't refresh itself automatically. To update the display, choose the refresh (![\[Icon to refresh the Amazon CloudWatch graph\]](http://docs.aws.amazon.com/waf/latest/developerguide/images/cloudwatch-refresh-icon.png)) icon.

1. (Optional) View detailed information about individual requests that API Gateway CloudFront or an Application Load Balancer has forwarded to AWS WAF Classic. For more information, see [Viewing a sample of the web requests that API Gateway CloudFront or an Application Load Balancer has forwarded to AWS WAF Classic](#classic-web-acl-testing-view-sample).

1. If you determine that a rule is intercepting requests that you don't want it to intercept, change the applicable settings. For more information, see [Creating and configuring a Web Access Control List (Web ACL)](classic-web-acl.md).

   When you're satisfied that all of your rules are intercepting only the correct requests, change the action for each of your rules to **Allow** or **Block**. For more information, see [Editing a Web ACL](classic-web-acl-editing.md).

## Viewing a sample of the web requests that API Gateway CloudFront or an Application Load Balancer has forwarded to AWS WAF Classic
<a name="classic-web-acl-testing-view-sample"></a>

In the AWS WAF Classic console, you can view a sample of the requests that API Gateway CloudFront or an Application Load Balancer has forwarded to AWS WAF Classic for inspection. For each sampled request, you can view detailed data about the request, such as the originating IP address and the headers included in the request. You also can view which rule the request matched, and whether the rule is configured to allow or block requests.

The sample of requests contains up to 100 requests that matched all the conditions in each rule and another 100 requests for the default action, which applies to requests that didn't match all the conditions in any rule. The requests in the sample come from all the API Gateway APIs, CloudFront edge locations or Application Load Balancers that have received requests for your content in the previous 15 minutes.<a name="classic-web-acl-testing-view-sample-procedure"></a>

**To view a sample of the web requests that API Gateway; CloudFront or an Application Load Balancer has forwarded to AWS WAF Classic**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose the web ACL for which you want to view requests.

1. In the right pane, choose the **Requests** tab.

   The **Sampled requests** table displays the following values for each request:  
**Source IP**  
Either the IP address that the request originated from or, if the viewer used an HTTP proxy or an Application Load Balancer to send the request, the IP address of the proxy or Application Load Balancer.   
**URI**  
The URI path of the request, which identifies the resource, for example, `/images/daily-ad.jpg`. This doesn't include the query string or fragment components of the URI. For information, see [Uniform Resource Identifier (URI): Generic Syntax](https://tools.ietf.org/html/rfc3986#section-3.3).   
**Matches rule**  
Identifies the first rule in the web ACL for which the web request matched all the conditions. If a web request doesn't match all the conditions in any rule in the web ACL, the value of **Matches rule** is **Default**.  
Note that when a web request matches all the conditions in a rule and the action for that rule is **Count**, AWS WAF Classic continues inspecting the web request based on subsequent rules in the web ACL. In this case, a web request could appear twice in the list of sampled requests: once for the rule that has an action of **Count** and again for a subsequent rule or for the default action.  
**Action**  
Indicates whether the action for the corresponding rule is **Allow**, **Block**, or **Count**.  
**Time**  
The time that AWS WAF Classic received the request from API Gateway, CloudFront or your Application Load Balancer.

1. To display additional information about the request, choose the arrow on the left side of the IP address for that request. AWS WAF Classic displays the following information:  
**Source IP**  
The same IP address as the value in the **Source IP** column in the table.  
**Country**  
The two-letter country code of the country that the request originated from. If the viewer used an HTTP proxy or an Application Load Balancer to send the request, this is the two-letter country code of the country that the HTTP proxy or an Application Load Balancer is in.  
For a list of two-letter country codes and the corresponding country names, see the Wikipedia entry [ISO 3166-1 alpha-2](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2).  
**Method**  
The HTTP request method for the request: `GET`, `HEAD`, `OPTIONS`, `PUT`, `POST`, `PATCH`, or `DELETE`.   
**URI**  
The same URI as the value in the **URI** column in the table.  
**Request headers**  
The request headers and header values in the request.

1. To refresh the list of sample requests, choose **Get new samples**.

# Working with AWS WAF Classic rule groups for use with AWS Firewall Manager
<a name="classic-working-with-rule-groups"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

An AWS WAF Classic *rule group* is a set of rules that you add to an AWS WAF Classic AWS Firewall Manager policy. You can create your own rule group, or you can purchase a managed rule group from AWS Marketplace. 

**Important**  
If you want to add an AWS Marketplace rule group to your Firewall Manager policy, each account in your organization must first subscribe to that rule group. After all accounts have subscribed, you can then add the rule group to a policy. For more information, see [AWS Marketplace rule groups](classic-waf-managed-rule-groups.md).

**Topics**
+ [Creating an AWS WAF Classic rule group](classic-create-rule-group.md)
+ [Adding and deleting rules from an AWS WAF Classic rule group](classic-rule-group-editing.md)

# Creating an AWS WAF Classic rule group
<a name="classic-create-rule-group"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

When you create an AWS WAF Classic rule group to use with AWS Firewall Manager, you specify which rules to add to the group.<a name="classic-create-rule-group-procedure"></a>

**To create a rule group (console)**

1. Sign in to the AWS Management Console using the AWS Firewall Manager administrator account that you set up in the prerequisites, and then open the Firewall Manager console at [https://console.aws.amazon.com/wafv2/fms](https://console.aws.amazon.com/wafv2/fms). 
**Note**  
For information about setting up a Firewall Manager administrator account, see [Creating an AWS Firewall Manager default administrator account](enable-integration.md).

1. In the navigation pane, choose **Switch to AWS WAF Classic**.

1. In the AWS WAF Classic navigation pane, choose **Rule groups**.

1. Choose **Create rule group**.
**Note**  
You can't add rate-based rules to a rule group.

1. If you have already created the rules that you want to add to the rule group, choose **Use existing rules for this rule group **. If you want to create new rules to add to the rule group, choose **Create rules and conditions for this rule group**. 

1. Choose **Next**.

1. If you chose to create rules, follow the steps to create them at [Creating a rule and adding conditions](classic-web-acl-rules-creating.md). 
**Note**  
Use the AWS WAF Classic console to create your rules. 

   When you've created all the rules you need, go to the next step.

1. Type a rule group name.

1. To add a rule to the rule group, select a rule then choose **Add rule**. Choose whether to allow, block, or count requests that match the rule's conditions. For more information on the choices, see [How AWS WAF Classic works](classic-how-aws-waf-works.md). 

1. When you are finished adding rules, choose **Create**.

You can test your rule group by adding it to an AWS WAF WebACL and setting the WebACL action to **Override to Count**. This action overrides any action that you choose for the rules contained in the group, and only counts matching requests. For more information, see [Creating a Web ACL](classic-web-acl-creating.md).

# Adding and deleting rules from an AWS WAF Classic rule group
<a name="classic-rule-group-editing"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

You can add or delete rules in an AWS WAF Classic rule group.

Deleting a rule from the rule group does not delete the rule itself. It only removes the rule from the rule group.<a name="classic-rule-group-editing-procedure"></a>

**To add or delete rules in a rule group (console)**

1. Sign in to the AWS Management Console using the AWS Firewall Manager administrator account that you set up in the prerequisites, and then open the Firewall Manager console at [https://console.aws.amazon.com/wafv2/fms](https://console.aws.amazon.com/wafv2/fms). 
**Note**  
For information about setting up a Firewall Manager administrator account, see [Creating an AWS Firewall Manager default administrator account](enable-integration.md).

1. In the navigation pane, choose **Switch to AWS WAF Classic**.

1. In the AWS WAF Classic navigation pane, choose **Rule groups**.

1. Choose the rule group that you want to edit.
**Note**  
If you don't see the rule group that you want to edit, make sure you have the correct Region selected. For rule groups used to protect Amazon CloudFront distributions, use the **Global (CloudFront)** setting. 

1. Choose **Edit rule group**.

1. To add rules, perform the following steps:

   1. Select a rule, and then choose **Add rule to rule group**. Choose whether to allow, block, or count requests that match the rule's conditions. For more information on the choices, see [How AWS WAF Classic works](classic-how-aws-waf-works.md). Repeat to add more rules to the rule group. 
**Note**  
You cannot add rate-based rules to rule group.

   1. Choose **Update**.

1. To delete rules, perform the following steps:

   1. Choose the **X** next to the rule to delete. Repeat to delete more rules from the rule group.

   1. Choose **Update**.

# Getting started with AWS Firewall Manager to enable AWS WAF Classic rules
<a name="classic-getting-started-fms"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

You can use AWS Firewall Manager to enable AWS WAF rules, AWS WAF Classic rules, AWS Shield Advanced protections, and Amazon VPC security groups. The steps for getting set up are slightly different for each:
+ To use Firewall Manager to enable rules using the latest version of AWS WAF, don't use this topic. Instead, follow the steps in [Setting up AWS Firewall Manager​ AWS WAF policies](getting-started-fms.md). 
+ To use Firewall Manager to enable AWS Shield Advanced protections, follow the steps in [Setting up AWS Firewall Manager​ AWS Shield Advanced policies](getting-started-fms-shield.md).
+ To use Firewall Manager to enable Amazon VPC security groups, follow the steps in [Setting up AWS Firewall Manager​ Amazon VPC security group policies](getting-started-fms-security-group.md). 

To use Firewall Manager to enable AWS WAF Classic rules, perform the following steps in sequence. 

**Topics**
+ [Step 1: Complete the prerequisites](classic-complete-prereq.md)
+ [Step 2: Create rules](classic-get-started-fms-create-rules.md)
+ [Step 3: Create a rule group](classic-get-started-fms-create-rule-group.md)
+ [Step 4: Create and apply an AWS Firewall Manager AWS WAF Classic policy](classic-get-started-fms-create-security-policy.md)

# Step 1: Complete the prerequisites
<a name="classic-complete-prereq"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

There are several mandatory steps to prepare your account for AWS Firewall Manager. Those steps are described in [AWS Firewall Manager prerequisites](fms-prereq.md). Complete all the prerequisites before proceeding to [Step 2: Create rules](classic-get-started-fms-create-rules.md).

# Step 2: Create rules
<a name="classic-get-started-fms-create-rules"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

In this step, you create rules using AWS WAF Classic. If you already have AWS WAF Classic rules that you want to use with AWS Firewall Manager, skip this step and go to [Step 3: Create a rule group](classic-get-started-fms-create-rule-group.md). 

**Note**  
Use the AWS WAF Classic console to create your rules. <a name="classic-get-started-fms-create-rules-procedure"></a>

**To create AWS WAF Classic rules (console)**
+ Create your rules, and then add your conditions to your rules. For more information, see [Creating a rule and adding conditions](classic-web-acl-rules-creating.md). 

You are now ready to go to [Step 3: Create a rule group](classic-get-started-fms-create-rule-group.md).

# Step 3: Create a rule group
<a name="classic-get-started-fms-create-rule-group"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

A rule group is a set of rules that defines what actions to take when a particular set of conditions is met. You can use managed rule groups from AWS Marketplace, and you can create your own rule groups. For information about managed rule groups, see [AWS Marketplace rule groups](classic-waf-managed-rule-groups.md).

To create your own rule group, perform the following procedure.<a name="classic-get-started-fms-create-rule-group-procedure"></a>

**To create a rule group (console)**

1. Sign in to the AWS Management Console using the AWS Firewall Manager administrator account that you set up in the prerequisites, and then open the Firewall Manager console at [https://console.aws.amazon.com/wafv2/fms](https://console.aws.amazon.com/wafv2/fms). 

1. In the navigation pane, choose **Security policies**. 

1. If you have not met the prerequisites, the console displays instructions about how to fix any issues. Follow the instructions, and then begin this step (create a rule group) again. If you have met the prerequisites, choose **Close**. 

1. Choose **Create policy**.

   For **Policy type**, choose **AWS WAF Classic**. 

1. Choose **Create an AWS Firewall Manager policy and add a new rule group**.

1. Choose an AWS Region, and then choose **Next**.

1. Because you already created rules, you don't need to create conditions. Choose **Next**.

1. Because you already created rules, you don't need to create rules. Choose **Next**.

1. Choose **Create rule group**.

1. For **Name**, enter a friendly name. 

1. Enter a name for the CloudWatch metric that AWS WAF Classic will create and will associate with the rule group. The name can contain only alphanumeric characters (A-Z, a-z, 0-9) or the following special characters: \$1-\$1"\$1`\$1\$1\$1,./. It can't contain white space.

1. Select a rule, and then choose **Add rule**. A rule has an action setting that allows you to choose whether to allow, block, or count requests that match the rule's conditions. For this tutorial, choose **Count**. Repeat adding rules until you have added all the rules that you want to the rule group.

1. Choose **Create**.

You are now ready to go to [Step 4: Create and apply an AWS Firewall Manager AWS WAF Classic policy](classic-get-started-fms-create-security-policy.md).

# Step 4: Create and apply an AWS Firewall Manager AWS WAF Classic policy
<a name="classic-get-started-fms-create-security-policy"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

After you create the rule group, you create an AWS Firewall Manager AWS WAF policy. A Firewall Manager AWS WAF policy contains the rule group that you want to apply to your resources.<a name="classic-get-started-fms-create-security-policy-procedure"></a>

**To create a Firewall Manager AWS WAF policy (console)**

1. After you create the rule group (the last step in the preceding procedure, [Step 3: Create a rule group](classic-get-started-fms-create-rule-group.md)), the console displays the **Rule group summary** page. Choose **Next**.

1. For **Name**, enter a friendly name. 

1. For **Policy type**, choose **WAF**. 

1. For **Region**, choose an AWS Region. To protect Amazon CloudFront resources, choose **Global**.

   To protect resources in multiple regions (other than CloudFront resources), you must create separate Firewall Manager policies for each Region.

1. Select a rule group to add, and then choose **Add rule group**. 

1. A policy has two possible actions: **Action set by rule group** and **Count**. If you want to test the policy and rule group, set the action to **Count**. This action overrides any *block* action specified by the rule group contained in the policy. That is, if the policy's action is set to **Count**, those requests are only counted and not blocked. Conversely, if you set the policy's action to **Action set by rule group**, actions of the rule group in the policy are used. For this tutorial, choose **Count**.

1. Choose **Next**.

1. If you want to include only specific accounts in the policy, or alternatively exclude specific accounts from the policy, select **Select accounts to include/exclude from this policy (optional)**. Choose either **Include only these accounts in this policy** or **Exclude these accounts from this policy**. You can choose only one option. Choose **Add**. Select the account numbers to include or exclude, and then choose **OK**. 
**Note**  
If you don't select this option, Firewall Manager applies a policy to all accounts in your organization in AWS Organizations. If you add a new account to the organization, Firewall Manager automatically applies the policy to that account.

1. Choose the types of resources that you want to protect.

1. If you want to protect only resources with specific tags, or alternatively exclude resources with specific tags, select **Use tags to include/exclude resources**, enter the tags, and then choose either **Include** or **Exclude**. You can choose only one option. 

   If you enter more than one tag (separated by commas), and if a resource has any of those tags, it is considered a match.

   For more information about tags, see [Working with Tag Editor](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html).

1. Choose **Create and apply this policy to existing and new resources**.

   This option creates a web ACL in each applicable account within an organization in AWS Organizations, and associates the web ACL with the specified resources in the accounts. This option also applies the policy to all new resources that match the preceding criteria (resource type and tags). Alternatively, if you choose **Create but do not apply this policy to existing or new resources**, Firewall Manager creates a web ACL in each applicable account within the organization, but doesn't apply the web ACL to any resources. You must apply the policy to resources later.

1. Leave the choice for **Replace existing associated web ACLs** at the default setting.

   When this option is selected, Firewall Manager removed all existing web ACL associations from in-scope resources before it associates the new policy's web ACLs to them. 

1. Choose **Next**.

1. Review the new policy. To make any changes, choose **Edit**. When you are satisfied with the policy, choose **Create policy**.

# Tutorial: Creating an AWS Firewall Manager policy with hierarchical rules
<a name="hierarchical-rules"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

With AWS Firewall Manager, you can create and apply AWS WAF Classic protection policies that contain hierarchical rules. That is, you can create and enforce certain rules centrally, but delegate the creation and maintenance of account-specific rules to other individuals. You can monitor the centrally applied (common) rules for any accidental removal or mishandling, thereby ensuring that they are applied consistently. The account-specific rules add further protection customized for the needs of individual teams.

**Note**  
In the latest version of AWS WAF, this capability is built in and doesn't require any special handling. If you aren't already using AWS WAF Classic, use the latest version instead. See [Creating an AWS Firewall Manager policy for AWS WAF](create-policy.md#creating-firewall-manager-policy-for-waf).

The following tutorial describes how to create a hierarchical set of protection rules. 

**Topics**
+ [Step 1: Designate a Firewall Manager administrator account](#hierarchical-rules-set-firewall-administrator)
+ [Step 2: Create a rule group using the Firewall Manager administrator account](#hierarchical-rules-create-a-rule-group)
+ [Step 3: Create a Firewall Manager policy and attach the common rule group](#hierarchical-rules-create-policy)
+ [Step 4: Add account-specific rules](#hierarchical-rules-add-account-specific-rules)
+ [Conclusion](#hierarchical-rules-conclusion)

## Step 1: Designate a Firewall Manager administrator account
<a name="hierarchical-rules-set-firewall-administrator"></a>

To use AWS Firewall Manager, you must designate an account in your organization as the Firewall Manager administrator account. This account can be either the management account or a member account in the organization. 

You can use the Firewall Manager administrator account to create a set of common rules that you apply to other accounts in the organization. Other accounts in the organization can't change these centrally applied rules.

To designate an account as a Firewall Manager administrator account and complete other prerequisites for using Firewall Manager, see the instructions in [AWS Firewall Manager prerequisites](fms-prereq.md). If you've already completed the prerequisites, you can skip to step 2 of this tutorial. 

In this tutorial, we refer to the administrator account as **Firewall-Administrator-Account**.

## Step 2: Create a rule group using the Firewall Manager administrator account
<a name="hierarchical-rules-create-a-rule-group"></a>

Next, create a rule group using **Firewall-Administrator-Account**. This rule group contains the common rules that you will apply to all member accounts governed by the policy that you create in the next step. Only **Firewall-Administrator-Account** can make changes to these rules and the container rule group.

In this tutorial, we refer to this container rule group as **Common-Rule-Group**.

To create a rule group, see the instructions in [Creating an AWS WAF Classic rule group](classic-create-rule-group.md). Remember to sign in to the console using your Firewall Manager administrator account (**Firewall-Administrator-Account**) when following these instructions.

## Step 3: Create a Firewall Manager policy and attach the common rule group
<a name="hierarchical-rules-create-policy"></a>

Using **Firewall-Administrator-Account**, create a Firewall Manager policy. When you create this policy, you must do the following:
+ Add **Common-Rule-Group** to the new policy.
+ Include all accounts in the organization that you want **Common-Rule-Group** applied to.
+ Add all resources that you want **Common-Rule-Group** applied to.

For instructions on creating a policy, see [Creating an AWS Firewall Manager policy](create-policy.md).

This creates a web ACL in each specified account and adds **Common-Rule-Group** to each of those web ACLs. After you create the policy, this web ACL and the common rules are deployed to all specified accounts.

In this tutorial, we refer to this web ACL as **Administrator-Created-ACL**. A unique **Administrator-Created-ACL** now exists in each specified member account of the organization. 

## Step 4: Add account-specific rules
<a name="hierarchical-rules-add-account-specific-rules"></a>

Each member account in the organization can now add their own account-specific rules to the **Administrator-Created-ACL** that exists in their account. The common rules already in **Administrator-Created-ACL** continue to apply, along with the new, account-specific rules. AWS WAF inspects web requests based on the order in which rules appear in the web ACL. This applies to both **Administrator-Created-ACL** and account-specific rules.

To add rules to **Administrator-Created-ACL**, see [Editing a protection pack (web ACL) in AWS WAF](web-acl-editing.md).

## Conclusion
<a name="hierarchical-rules-conclusion"></a>

You now have a web ACL that contains common rules administered by the Firewall Manager administrator account as well as account-specific rules maintained by each member account.

The **Administrator-Created-ACL** in each account references the single **Common-Rule-Group**. Therefore, future changes by the Firewall Manager administrator account to **Common-Rule-Group** will immediately take effect in each member account.

Member accounts can't change or remove the common rules in **Common-Rule-Group**.

Account-specific rules don't affect other accounts.

# Logging Web ACL traffic information
<a name="classic-logging"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

**Note**  
You cannot use Amazon Security Lake to collect AWS WAF Classic data. 

You can enable logging to get detailed information about traffic that is analyzed by your web ACL. Information that is contained in the logs include the time that AWS WAF Classic received the request from your AWS resource, detailed information about the request, and the action for the rule that each request matched.

To get started, you set up an Amazon Kinesis Data Firehose. As part of that process, you choose a destination for storing your logs. Next, you choose the web ACL that you want to enable logging for. After you enable logging, AWS WAF delivers logs through the firehose to your storage destination. 

For information about how to create an Amazon Kinesis Data Firehose and review your stored logs, see [What Is Amazon Data Firehose?](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html) To understand the permissions required for your Kinesis Data Firehose configuration, see [Controlling Access with Amazon Kinesis Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html).

You must have the following permissions to successfully enable logging:
+ `iam:CreateServiceLinkedRole`
+ `firehose:ListDeliveryStreams`
+ `waf:PutLoggingConfiguration`

For more information about service-linked roles and the `iam:CreateServiceLinkedRole` permission, see [Using service-linked roles for AWS WAF Classic](classic-using-service-linked-roles.md).<a name="classic-logging-procedure"></a>

**To enable logging for a web ACL**

1. Create an Amazon Kinesis Data Firehose using a name starting with the prefix "aws-waf-logs-" For example, `aws-waf-logs-us-east-2-analytics`. Create the data firehose with a `PUT` source and in the region that you are operating. If you are capturing logs for Amazon CloudFront, create the firehose in US East (N. Virginia). For more information, see [Creating an Amazon Data Firehose Delivery Stream](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).
**Important**  
Do not choose `Kinesis stream` as your source.  
One AWS WAF Classic log is equivalent to one Firehose record. If you typically receive 10,000 requests per second and you enable full logs, you should have a 10,000 records per second setting in Firehose. If you don't configure Firehose correctly, AWS WAF Classic won't record all logs. For more information, see [Amazon Kinesis Data Firehose Quotas](https://docs.aws.amazon.com/firehose/latest/dev/limits.html). 

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Web ACLs**.

1. Choose the name of the web ACL that you want to enable logging for. This opens a page with the web ACL's details in the right pane.

1. On the **Logging** tab, choose **Enable logging**.

1. Choose the Kinesis Data Firehose that you created in the first step. You must choose a firehose that begins with "aws-waf-logs-."

1. (Optional) If you don't want certain fields and their values included in the logs, redact those fields. Choose the field to redact, and then choose **Add**. Repeat as necessary to redact additional fields. The redacted fields appear as `REDACTED` in the logs. For example, if you redact the **cookie** field, the **cookie** field in the logs will be `REDACTED`. 

1. Choose **Enable logging**.
**Note**  
When you successfully enable logging, AWS WAF Classic will create a service linked role with the necessary permissions to write logs to the Amazon Kinesis Data Firehose. For more information, see [Using service-linked roles for AWS WAF Classic](classic-using-service-linked-roles.md).<a name="classic-logging-disable-procedure"></a>

**To disable logging for a web ACL**

1. In the navigation pane, choose **Web ACLs**.

1. Choose the name of the web ACL that you want to disable logging for. This opens a page with the web ACL's details in the right pane.

1. On the **Logging** tab, choose **Disable logging**.

1. In the dialog box, choose **Disable logging**.

**Example log**  

```
{
			
	"timestamp":1533689070589,                            
	"formatVersion":1,                                   
	"webaclId":"385cb038-3a6f-4f2f-ac64-09ab912af590",  
	"terminatingRuleId":"Default_Action",                
	"terminatingRuleType":"REGULAR",                     
	"action":"ALLOW",                                    
	"httpSourceName":"CF",                               
	"httpSourceId":"i-123",                             
	"ruleGroupList":[                                    
                         {  
                          "ruleGroupId":"41f4eb08-4e1b-2985-92b5-e8abf434fad3",
                          "terminatingRule":null,    
                          "nonTerminatingMatchingRules":[                  
                                                         {"action" : "COUNT",   
                                                         "ruleId" : "4659b169-2083-4a91-bbd4-08851a9aaf74"}       
                                                        ],
                          "excludedRules":              [
                                                         {"exclusionType" : "EXCLUDED_AS_COUNT",   
                                                          "ruleId" : "5432a230-0113-5b83-bbb2-89375c5bfa98"}
                                                        ]                          
                         }
                        ],
     
	"rateBasedRuleList":[                                 
                             {  
                              "rateBasedRuleId":"7c968ef6-32ec-4fee-96cc-51198e412e7f",   
                              "limitKey":"IP",
                              "maxRateAllowed":100                                                                                           
                             },
                             {  
                              "rateBasedRuleId":"462b169-2083-4a93-bbd4-08851a9aaf30",
                              "limitKey":"IP",
                              "maxRateAllowed":100
                              }
                              ],
			
	"nonTerminatingMatchingRules":[                                
                                       {"action" : "COUNT",                                                           
                                       "ruleId" : "4659b181-2011-4a91-bbd4-08851a9aaf52"}    
                                      ],
                                  
	"httpRequest":{                                                             
                       "clientIp":"192.10.23.23",                                           
                       "country":"US",                                                         
                       "headers":[                                                                 
                                   {  
                                    "name":"Host",
                                    "value":"127.0.0.1:1989"
                                   },
                                   {  
                                    "name":"User-Agent",
                                    "value":"curl/7.51.2"
                                   },
                                   {  
                                    "name":"Accept",
                                    "value":"*/*"
                                   }
                                 ],
                      "uri":"REDACTED",                                                
                      "args":"usernam=abc",                                         
                      "httpVersion":"HTTP/1.1",
                      "httpMethod":"GET",
                      "requestId":"cloud front Request id"                    
                      }
}
```

Following is an explanation of each item listed in these logs:

**timestamp**  
The timestamp in milliseconds.

**formatVersion**  
The format version for the log.

**webaclId**  
The GUID of the web ACL.

**terminatingRuleId**  
The ID of the rule that terminated the request. If nothing terminates the request, the value is `Default_Action`.

**terminatingRuleType**  
The type of rule that terminated the request. Possible values: RATE\$1BASED, REGULAR, and GROUP.

**action**  
The action. Possible values for a terminating rule: ALLOW and BLOCK. COUNT is not a valid value for a terminating rule.

**terminatingRuleMatchDetails**  
Detailed information about the terminating rule that matched the request. A terminating rule has an action that ends the inspection process against a web request. Possible actions for a terminating rule are ALLOW and BLOCK. This is only populated for SQL injection and cross-site scripting (XSS) match rule statements. As with all rule statements that inspect for more than one thing, AWS WAF applies the action on the first match and stops inspecting the web request. A web request with a terminating action could contain other threats, in addition to the one reported in the log.

**httpSourceName**  
The source of the request. Possible values: CF (if the source is Amazon CloudFront), APIGW (if the source is Amazon API Gateway), and ALB (if the source is an Application Load Balancer).

**httpSourceId**  
The source ID. This field shows the ID of the associated Amazon CloudFront distribution, the REST API for API Gateway, or the name for an Application Load Balancer.

**ruleGroupList**  
The list of rule groups that acted on this request. In the preceding code example, there is only one.

**ruleGroupId**  
The ID of the rule group. If the rule blocked the request, the ID for `ruleGroupID` is the same as the ID for `terminatingRuleId`. 

**terminatingRule**  
The rule within the rule group that terminated the request. If this is a non-null value, it also contains a **ruleid** and **action**. In this case, the action is always BLOCK.

**nonTerminatingMatchingRules**  
The list of rules in the rule group that match the request. These are always COUNT rules (non-terminating rules that match).

**action (nonTerminatingMatchingRules group)**  
This is always COUNT (non-terminating rules that match).

**ruleId (nonTerminatingMatchingRules group)**  
The ID of the rule within the rule group that matches the request and was non-terminating. That is, COUNT rules.

**excludedRules**  
The list of rules in the rule group that you have excluded. The action for these rules is set to COUNT.

**exclusionType (excludedRules group)**  
A type that indicates that the excluded rule has the action COUNT.

**ruleId (excludedRules group)**  
The ID of the rule within the rule group that is excluded.

**rateBasedRuleList**  
The list of rate-based rules that acted on the request.

**rateBasedRuleId**  
The ID of the rate-based rule that acted on the request. If this has terminated the request, the ID for `rateBasedRuleId` is the same as the ID for `terminatingRuleId`.

**limitKey**  
The field that AWS WAF uses to determine if requests are likely arriving from a single source and thus subject to rate monitoring. Possible value: IP. 

**maxRateAllowed**  
The maximum number of requests, which have an identical value in the field that is specified by `limitKey`, allowed in a five-minute period. If the number of requests exceeds the `maxRateAllowed` and the other predicates specified in the rule are also met, AWS WAF triggers the action that is specified for this rule.

**httpRequest**  
The metadata about the request.

**clientIp**  
The IP address of the client sending the request.

**country**  
The source country of the request. If AWS WAF is unable to determine the country of origin, it sets this field to `-`. 

**headers**  
The list of headers.

**uri**  
The URI of the request. The preceding code example demonstrates what the value would be if this field had been redacted.

**args**  
The query string.

**httpVersion**  
The HTTP version.

**httpMethod**  
The HTTP method in the request.

**requestId**  
The ID of the request.

# Listing IP addresses blocked by rate-based rules
<a name="classic-listing-managed-ips"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

AWS WAF Classic provides a list of IP addresses that are blocked by rate-based rules.<a name="classic-listing-managed-ips-procedure"></a>

**To view addresses blocked by rate-based rules**

1. Sign in to the AWS Management Console and open the AWS WAF console at [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/). 

   If you see **Switch to AWS WAF Classic** in the navigation pane, select it.

1. In the navigation pane, choose **Rules**.

1. In the **Name** column, choose a rate-based rule.

   The list shows the IP addresses that the rule currently blocks.

# How AWS WAF Classic works with Amazon CloudFront features
<a name="classic-cloudfront-features"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

When you create a web ACL, you can specify one or more CloudFront distributions that you want AWS WAF Classic to inspect. AWS WAF Classic starts to allow, block, or count web requests for those distributions based on the conditions that you identify in the web ACL. CloudFront provides some features that enhance the AWS WAF Classic functionality. This chapter describes a few ways that you can configure CloudFront to make CloudFront and AWS WAF Classic work better together.

**Topics**
+ [Using AWS WAF Classic with CloudFront custom error pages](#classic-cloudfront-features-custom-error-pages)
+ [Using AWS WAF Classic with CloudFront for applications running on your own HTTP server](#classic-cloudfront-features-your-own-http-server)
+ [Choosing the HTTP methods that CloudFront responds to](#classic-cloudfront-features-allowed-http-methods)

## Using AWS WAF Classic with CloudFront custom error pages
<a name="classic-cloudfront-features-custom-error-pages"></a>

When AWS WAF Classic blocks a web request based on the conditions that you specify, it returns HTTP status code 403 (Forbidden) to CloudFront. Next, CloudFront returns that status code to the viewer. The viewer then displays a brief and sparsely formatted default message similar to this:

`Forbidden: You don't have permission to access /myfilename.html on this server.`

If you'd rather display a custom error message, possibly using the same formatting as the rest of your website, you can configure CloudFront to return to the viewer an object (for example, an HTML file) that contains your custom error message. 

**Note**  
CloudFront can't distinguish between an HTTP status code 403 that is returned by your origin and one that is returned by AWS WAF Classic when a request is blocked. This means that you can't return different custom error pages based on the different causes of an HTTP status code 403. 

For more information about CloudFront custom error pages, see [Customizing Error Responses](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html) in the *Amazon CloudFront Developer Guide*.

## Using AWS WAF Classic with CloudFront for applications running on your own HTTP server
<a name="classic-cloudfront-features-your-own-http-server"></a>

When you use AWS WAF Classic with CloudFront, you can protect your applications running on any HTTP webserver, whether it's a webserver that's running in Amazon Elastic Compute Cloud (Amazon EC2) or a webserver that you manage privately. You can also configure CloudFront to require HTTPS between CloudFront and your own webserver, as well as between viewers and CloudFront.

**Requiring HTTPS Between CloudFront and Your Own Webserver**  
To require HTTPS between CloudFront and your own webserver, you can use the CloudFront custom origin feature and configure the **Origin Protocol Policy** and the **Origin Domain Name **settings for specific origins. In your CloudFront configuration, you can specify the DNS name of the server along with the port and the protocol that you want CloudFront to use when fetching objects from your origin. You should also ensure that the SSL/TLS certificate on your custom origin server matches the origin domain name you’ve configured. When you use your own HTTP webserver outside of AWS, you must use a certificate that is signed by a trusted third-party certificate authority (CA), for example, Comodo, DigiCert, or Symantec. For more information about requiring HTTPS for communication between CloudFront and your own webserver, see the topic [Requiring HTTPS for Communication Between CloudFront and Your Custom Origin](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html) in the *Amazon CloudFront Developer Guide*.

**Requiring HTTPS Between a Viewer and CloudFront**  
To require HTTPS between viewers and CloudFront, you can change the **Viewer Protocol Policy** for one or more cache behaviors in your CloudFront distribution. For more information about using HTTPS between viewers and CloudFront, see the topic [Requiring HTTPS for Communication Between Viewers and CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) in the *Amazon CloudFront Developer Guide*. You can also bring your own SSL certificate so viewers can connect to your CloudFront distribution over HTTPS using your own domain name, for example *https://www.mysite.com*. For more information, see the topic [Configuring Alternate Domain Names and HTTPS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html) in the *Amazon CloudFront Developer Guide*.

## Choosing the HTTP methods that CloudFront responds to
<a name="classic-cloudfront-features-allowed-http-methods"></a>

When you create an Amazon CloudFront web distribution, you choose the HTTP methods that you want CloudFront to process and forward to your origin. You can choose from the following options:
+ **GET, HEAD** – You can use CloudFront only to get objects from your origin or to get object headers.
+ **GET, HEAD, OPTIONS** – You can use CloudFront only to get objects from your origin, get object headers, or retrieve a list of the options that your origin server supports.
+ **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE** – You can use CloudFront to get, add, update, and delete objects, and to get object headers. In addition, you can perform other POST operations such as submitting data from a web form. 

You also can use AWS WAF Classic string match conditions to allow or block requests based on the HTTP method, as described in [Working with string match conditions](classic-web-acl-string-conditions.md). If you want to use a combination of methods that CloudFront supports, such as `GET` and `HEAD`, then you don't need to configure AWS WAF Classic to block requests that use the other methods. If you want to allow a combination of methods that CloudFront doesn't support, such as `GET`, `HEAD`, and `POST`, you can configure CloudFront to respond to all methods, and then use AWS WAF Classic to block requests that use other methods.

For more information about choosing the methods that CloudFront responds to, see [Allowed HTTP Methods](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesAllowedHTTPMethods) in the topic [Values that You Specify When You Create or Update a Web Distribution](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html) in the *Amazon CloudFront Developer Guide*.

# Security in AWS WAF Classic
<a name="classic-security"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.

Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. The effectiveness of our security is regularly tested and verified by third-party auditors as part of the [AWS compliance programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to AWS WAF Classic, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your organization’s requirements, and applicable laws and regulations. 

This documentation helps you understand how to apply the shared responsibility model when using AWS WAF Classic. The following topics show you how to configure AWS WAF Classic to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your AWS WAF Classic resources. 

**Topics**
+ [Data protection in AWS WAF Classic](classic-data-protection.md)
+ [Identity and access management for AWS WAF Classic](classic-security-iam.md)
+ [Logging and monitoring in AWS WAF Classic](classic-waf-incident-response.md)
+ [Compliance validation for AWS WAF Classic](classic-waf-compliance.md)
+ [Resilience in AWS WAF Classic](classic-disaster-recovery-resiliency.md)
+ [Infrastructure security in AWS WAF Classic](classic-infrastructure-security.md)

# Data protection in AWS WAF Classic
<a name="classic-data-protection"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS WAF Classic. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.

For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).

We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with AWS WAF Classic or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.

AWS WAF Classic entities—such as web ACLs, rules, and conditions—are encrypted at rest, except in certain Regions where encryption is not available, including China (Beijing) and China (Ningxia). Unique encryption keys are used for each Region. 

## Deleting AWS WAF Classic resources
<a name="classic-deleting-resources"></a>

You can delete the resources that you create in AWS WAF Classic. See the guidance for each resource type in following sections.
+ [Deleting a Web ACL](classic-web-acl-deleting.md)
+ [Adding and deleting rules from an AWS WAF Classic rule group](classic-rule-group-editing.md)
+ [Deleting a rule](classic-web-acl-rules-deleting.md)

# Identity and access management for AWS WAF Classic
<a name="classic-security-iam"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 



AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use AWS WAF Classic resources. IAM is an AWS service that you can use with no additional charge.

**Topics**
+ [Audience](#security_iam_audience)
+ [Authenticating with identities](#security_iam_authentication)
+ [Managing access using policies](#security_iam_access-manage)
+ [How AWS WAF Classic works with IAM](classic-security_iam_service-with-iam.md)
+ [Identity-based policy examples for AWS WAF Classic](classic-security_iam_id-based-policy-examples.md)
+ [Troubleshooting AWS WAF Classic identity and access](classic-security_iam_troubleshoot.md)
+ [Using service-linked roles for AWS WAF Classic](classic-using-service-linked-roles.md)

## Audience
<a name="security_iam_audience"></a>

How you use AWS Identity and Access Management (IAM) differs, depending on the work that you do in AWS WAF Classic.

**Service user** – If you use the AWS WAF Classic service to do your job, then your administrator provides you with the credentials and permissions that you need. As you use more AWS WAF Classic features to do your work, you might need additional permissions. Understanding how access is managed can help you request the right permissions from your administrator. If you cannot access a feature in AWS WAF Classic, see [Troubleshooting AWS WAF Classic identity and access](classic-security_iam_troubleshoot.md).

**Service administrator** – If you're in charge of AWS WAF Classic resources at your company, you probably have full access to AWS WAF Classic. It's your job to determine which AWS WAF Classic features and resources your service users should access. You must then submit requests to your IAM administrator to change the permissions of your service users. Review the information on this page to understand the basic concepts of IAM. To learn more about how your company can use IAM with AWS WAF Classic, see [How AWS WAF Classic works with IAM](classic-security_iam_service-with-iam.md).

**IAM administrator** – If you're an IAM administrator, you might want to learn details about how you can write policies to manage access to AWS WAF Classic. To view example AWS WAF Classic identity-based policies that you can use in IAM, see [Identity-based policy examples for AWS WAF Classic](classic-security_iam_id-based-policy-examples.md).

## Authenticating with identities
<a name="security_iam_authentication"></a>

Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role.

You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.

For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*.

### AWS account root user
<a name="security_iam_authentication-rootuser"></a>

 When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*. 

### Federated identity
<a name="security_iam_authentication-federated"></a>

As a best practice, require human users to use federation with an identity provider to access AWS services using temporary credentials.

A *federated identity* is a user from your enterprise directory, web identity provider, or Directory Service that accesses AWS services using credentials from an identity source. Federated identities assume roles that provide temporary credentials.

For centralized access management, we recommend AWS IAM Identity Center. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center User Guide*.

### IAM users and groups
<a name="security_iam_authentication-iamuser"></a>

An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*.

An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*.

### IAM roles
<a name="security_iam_authentication-iamrole"></a>

An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an AWS CLI or AWS API operation. For more information, see [Methods to assume a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*.

IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.

## Managing access using policies
<a name="security_iam_access-manage"></a>

You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy defines permissions when associated with an identity or resource. AWS evaluates these policies when a principal makes a request. Most policies are stored in AWS as JSON documents. For more information about JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*.

Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**.

By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation.

### Identity-based policies
<a name="security_iam_access-manage-id-based-policies"></a>

Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.

Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*.

### Resource-based policies
<a name="security_iam_access-manage-resource-based-policies"></a>

Resource-based policies are JSON policy documents that you attach to a resource. Examples include IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy.

Resource-based policies are inline policies that are located in that service. You can't use AWS managed policies from IAM in a resource-based policy.

### Access control lists (ACLs)
<a name="security_iam_access-manage-acl"></a>

Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.

Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To learn more about ACLs, see [Access control list (ACL) overview](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) in the *Amazon Simple Storage Service Developer Guide*.

### Other policy types
<a name="security_iam_access-manage-other-policies"></a>

AWS supports additional policy types that can set the maximum permissions granted by more common policy types:
+ **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*.
+ **Service control policies (SCPs)** – Specify the maximum permissions for an organization or organizational unit in AWS Organizations. For more information, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*.
+ **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *AWS Organizations User Guide*.
+ **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*.

### Multiple policy types
<a name="security_iam_access-manage-multiple-policies"></a>

When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.

# How AWS WAF Classic works with IAM
<a name="classic-security_iam_service-with-iam"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

Before you use IAM to manage access to AWS WAF Classic, learn what IAM features are available to use with AWS WAF Classic.






**IAM features you can use with AWS WAF Classic**  

| IAM feature | AWS WAF Classic support | 
| --- | --- | 
|  [Identity-based policies](#classic-security_iam_service-with-iam-id-based-policies)  |   Yes  | 
|  [Resource-based policies](#classic-security_iam_service-with-iam-resource-based-policies)  |   No   | 
|  [Policy actions](#classic-security_iam_service-with-iam-id-based-policies-actions)  |   Yes  | 
|  [Policy resources](#classic-security_iam_service-with-iam-id-based-policies-resources)  |   Yes  | 
|  [Policy condition keys (service-specific)](#classic-security_iam_service-with-iam-id-based-policies-conditionkeys)  |   Yes  | 
|  [ACLs](#classic-security_iam_service-with-iam-acls)  |   No   | 
|  [ABAC (tags in policies)](#classic-security_iam_service-with-iam-tags)  |   Partial  | 
|  [Temporary credentials](#classic-security_iam_service-with-iam-roles-tempcreds)  |   Yes  | 
|  [Forward access sessions (FAS)](#classic-security_iam_service-with-iam-principal-permissions)  |   Yes  | 
|  [Service roles](#classic-security_iam_service-with-iam-roles-service)  |   Yes  | 
|  [Service-linked roles](#classic-security_iam_service-with-iam-roles-service-linked)  |   Yes  | 

To get a high-level view of how AWS WAF Classic and other AWS services work with most IAM features, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.

## Identity-based policies for AWS WAF Classic
<a name="classic-security_iam_service-with-iam-id-based-policies"></a>

**Supports identity-based policies:** Yes

Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, group of users, or role. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.

With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. To learn about all of the elements that you can use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.

To view examples of AWS WAF Classic identity-based policies, see [Identity-based policy examples for AWS WAF Classic](classic-security_iam_id-based-policy-examples.md).

## Resource-based policies within AWS WAF Classic
<a name="classic-security_iam_service-with-iam-resource-based-policies"></a>

**Supports resource-based policies:** No 

Resource-based policies are JSON policy documents that you attach to a resource. Examples of resource-based policies are IAM *role trust policies* and Amazon S3 *bucket policies*. In services that support resource-based policies, service administrators can use them to control access to a specific resource. For the resource where the policy is attached, the policy defines what actions a specified principal can perform on that resource and under what conditions. You must [specify a principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) in a resource-based policy. Principals can include accounts, users, roles, federated users, or AWS services.

To enable cross-account access, you can specify an entire account or IAM entities in another account as the principal in a resource-based policy. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.

## Policy actions for AWS WAF Classic
<a name="classic-security_iam_service-with-iam-id-based-policies-actions"></a>

**Supports policy actions:** Yes

Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.

The `Action` element of a JSON policy describes the actions that you can use to allow or deny access in a policy. Include actions in a policy to grant permissions to perform the associated operation.



To see a list of AWS WAF Classic actions, see [Actions defined by AWS WAF](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswaf.html#awswaf-actions-as-permissions) and [Actions defined by AWS WAF Regional](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafregional.html#awswafregional-actions-as-permissions) in the *Service Authorization Reference*.

Policy actions in AWS WAF Classic use the following prefix before the action:

```
waf
```

To specify multiple actions in a single statement, separate them with commas.

```
"Action": [
      "waf:action1",
      "waf:action2"
         ]
```



You can specify multiple actions using wildcards (\$1). For example, to specify all actions in AWS WAF Classic that begin with `List`, include the following action:

```
"Action": "waf:List*"
```

To view examples of AWS WAF Classic identity-based policies, see [Identity-based policy examples for AWS WAF Classic](classic-security_iam_id-based-policy-examples.md).

## Policy resources for AWS WAF Classic
<a name="classic-security_iam_service-with-iam-id-based-policies-resources"></a>

**Supports policy resources:** Yes

Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.

The `Resource` JSON policy element specifies the object or objects to which the action applies. As a best practice, specify a resource using its [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). For actions that don't support resource-level permissions, use a wildcard (\$1) to indicate that the statement applies to all resources.

```
"Resource": "*"
```

To see the list of AWS WAF Classic resource types and their ARNs, see [Resources defined by AWS WAF](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswaf.html#awswaf-resources-for-iam-policies) and [Resources defined by AWS WAF Regional](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafregional.html#awswafregional-resources-for-iam-policies) in the *Service Authorization Reference*. To learn with which actions you can specify the ARN of each resource, see [Actions defined by AWS WAF](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswaf.html#awswaf-actions-as-permissions) and [Actions defined by AWS WAF Regional](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafregional.html#awswafregional-actions-as-permissions). To allow or deny access to a subset of AWS WAF Classic resources, include the ARN of the resource in the `resource` element of your policy.

In AWS WAF Classic, the resources are *web ACLs* and *rules*. AWS WAF Classic also supports conditions such as *byte match*, *IP match*, and *size constraint*. 

These resources and conditions have unique Amazon Resource Names (ARNs) associated with them, as shown in the following table. 


****  

| Name in AWS WAF Console | Name in AWS WAF SDK/CLI | ARN Format  | 
| --- | --- | --- | 
| Web ACL | WebACL |  `arn:aws:waf::account:webacl/ID`  | 
| Rule | Rule |  `arn:aws:waf::account:rule/ID `  | 
| String match condition | ByteMatchSet |  `arn:aws:waf::account:bytematchset/ID`  | 
| SQL injection match condition | SqlInjectionMatchSet | arn:aws:waf::account:sqlinjectionset/ID | 
| Size constraint condition | SizeConstraintSet | arn:aws:waf::account:sizeconstraintset/ID | 
| IP match condition | IPSet | arn:aws:waf::account:ipset/ID | 
| Cross-site scripting match condition | XssMatchSet | arn:aws:waf::account:xssmatchset/ID |  | 

To allow or deny access to a subset of AWS WAF Classic resources, include the ARN of the resource in the `resource` element of your policy. The ARNs for AWS WAF Classic have the following format:

```
arn:aws:waf::account:resource/ID
```

Replace the *account*, *resource*, and *ID* variables with valid values. Valid values can be the following:
+ *account*: The ID of your AWS account. You must specify a value.
+ *resource*: The type of AWS WAF Classic resource. 
+ *ID*: The ID of the AWS WAF Classic resource, or a wildcard (`*`) to indicate all resources of the specified type that are associated with the specified AWS account.

For example, the following ARN specifies all web ACLs for the account `111122223333`:

```
arn:aws:waf::111122223333:webacl/*
```

## Policy condition keys for AWS WAF Classic
<a name="classic-security_iam_service-with-iam-id-based-policies-conditionkeys"></a>

**Supports service-specific policy condition keys:** Yes

Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.

The `Condition` element specifies when statements execute based on defined criteria. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.

To see a list of AWS WAF Classic condition keys, see [Condition keys for AWS WAF](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswaf.html#awswaf-policy-keys) and [Resources defined by AWS WAF Regional](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafregional.html#awswafregional-resources-for-iam-policies) in the *Service Authorization Reference*. To learn with which actions and resources you can use a condition key, see [Actions defined by AWS WAF](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswaf.html#awswaf-actions-as-permissions) and [Actions defined by AWS WAF Regional](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafregional.html#awswafregional-actions-as-permissions).

To view examples of AWS WAF Classic identity-based policies, see [Identity-based policy examples for AWS WAF Classic](classic-security_iam_id-based-policy-examples.md).

## ACLs in AWS WAF Classic
<a name="classic-security_iam_service-with-iam-acls"></a>

**Supports ACLs:** No 

Access control lists (ACLs) control which principals (account members, users, or roles) have permissions to access a resource. ACLs are similar to resource-based policies, although they do not use the JSON policy document format.

## ABAC with AWS WAF Classic
<a name="classic-security_iam_service-with-iam-tags"></a>

**Supports ABAC (tags in policies):** Partial

Attribute-based access control (ABAC) is an authorization strategy that defines permissions based on attributes called tags. You can attach tags to IAM entities and AWS resources, then design ABAC policies to allow operations when the principal's tag matches the tag on the resource.

To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys.

If a service supports all three condition keys for every resource type, then the value is **Yes** for the service. If a service supports all three condition keys for only some resource types, then the value is **Partial**.

For more information about ABAC, see [Define permissions with ABAC authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To view a tutorial with steps for setting up ABAC, see [Use attribute-based access control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) in the *IAM User Guide*.

## Using temporary credentials with AWS WAF Classic
<a name="classic-security_iam_service-with-iam-roles-tempcreds"></a>

**Supports temporary credentials:** Yes

Temporary credentials provide short-term access to AWS resources and are automatically created when you use federation or switch roles. AWS recommends that you dynamically generate temporary credentials instead of using long-term access keys. For more information, see [Temporary security credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) and [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.

## Forward access sessions for AWS WAF Classic
<a name="classic-security_iam_service-with-iam-principal-permissions"></a>

**Supports forward access sessions (FAS):** Yes

 Forward access sessions (FAS) use the permissions of the principal calling an AWS service, combined with the requesting AWS service to make requests to downstream services. For policy details when making FAS requests, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). 

## Service roles for AWS WAF Classic
<a name="classic-security_iam_service-with-iam-roles-service"></a>

**Supports service roles:** Yes

 A service role is an [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) that a service assumes to perform actions on your behalf. An IAM administrator can create, modify, and delete a service role from within IAM. For more information, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*. 

**Warning**  
Changing the permissions for a service role might break AWS WAF Classic functionality. Edit service roles only when AWS WAF Classic provides guidance to do so.

## Service-linked roles for AWS WAF Classic
<a name="classic-security_iam_service-with-iam-roles-service-linked"></a>

**Supports service-linked roles:** Yes

 A service-linked role is a type of service role that is linked to an AWS service. The service can assume the role to perform an action on your behalf. Service-linked roles appear in your AWS account and are owned by the service. An IAM administrator can view, but not edit the permissions for service-linked roles. 

For details about creating or managing AWS WAF Classic service-linked roles, see [Using service-linked roles for AWS WAF Classic](classic-using-service-linked-roles.md).

# Identity-based policy examples for AWS WAF Classic
<a name="classic-security_iam_id-based-policy-examples"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

By default, users and roles don't have permission to create or modify AWS WAF Classic resources. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies.

To learn how to create an IAM identity-based policy by using these example JSON policy documents, see [Create IAM policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) in the *IAM User Guide*.

For details about actions and resource types defined by AWS WAF Classic, including the format of the ARNs for each of the resource types, see [Actions, resources, and condition keys for AWS WAF](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswaf.html) and [Actions, resources, and condition keys for AWS WAF Regional](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafregional.html) in the *Service Authorization Reference*.

**Topics**
+ [Policy best practices](#classic-security_iam_service-with-iam-policy-best-practices)
+ [Using the AWS WAF Classic console](#classic-security_iam_id-based-policy-examples-console)
+ [Allow users to view their own permissions](#classic-security_iam_id-based-policy-examples-view-own-permissions)

## Policy best practices
<a name="classic-security_iam_service-with-iam-policy-best-practices"></a>

Identity-based policies determine whether someone can create, access, or delete AWS WAF Classic resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the *AWS managed policies* that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
+ **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [ Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
+ **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [ IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
+ **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [Validate policies with IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*.
+ **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or a root user in your AWS account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [ Secure API access with MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*.

For more information about best practices in IAM, see [Security best practices in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*.

## Using the AWS WAF Classic console
<a name="classic-security_iam_id-based-policy-examples-console"></a>

To access the AWS WAF Classic console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the AWS WAF Classic resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy.

You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that they're trying to perform.

Users who can access and use the AWS console can also access the AWS WAF Classic console. No additional permissions are required.

## Allow users to view their own permissions
<a name="classic-security_iam_id-based-policy-examples-view-own-permissions"></a>

This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}
```







# Troubleshooting AWS WAF Classic identity and access
<a name="classic-security_iam_troubleshoot"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

Use the following information to help you diagnose and fix common issues that you might encounter when working with AWS WAF Classic and IAM.

**Topics**
+ [I am not authorized to perform an action in AWS WAF Classic](#classic-security_iam_troubleshoot-no-permissions)
+ [I am not authorized to perform iam:PassRole](#classic-security_iam_troubleshoot-passrole)
+ [I want to allow people outside of my AWS account to access my AWS WAF Classic resources](#classic-security_iam_troubleshoot-cross-account-access)

## I am not authorized to perform an action in AWS WAF Classic
<a name="classic-security_iam_troubleshoot-no-permissions"></a>

If you receive an error that you're not authorized to perform an action, your policies must be updated to allow you to perform the action.

The following example error occurs when the `mateojackson` IAM user tries to use the console to view details about a fictional `my-example-widget` resource but doesn't have the fictional `waf:GetWidget` permissions.

```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: waf:GetWidget on resource: my-example-widget
```

In this case, the policy for the `mateojackson` user must be updated to allow access to the `my-example-widget` resource by using the `waf:GetWidget` action.

If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.

## I am not authorized to perform iam:PassRole
<a name="classic-security_iam_troubleshoot-passrole"></a>

If you receive an error that you're not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to AWS WAF Classic.

Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.

The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in AWS WAF Classic. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service.

```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```

In this case, Mary's policies must be updated to allow her to perform the `iam:PassRole` action.

If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.

## I want to allow people outside of my AWS account to access my AWS WAF Classic resources
<a name="classic-security_iam_troubleshoot-cross-account-access"></a>

You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.

To learn more, consult the following:
+ To learn whether AWS WAF Classic supports these features, see [How AWS WAF Classic works with IAM](classic-security_iam_service-with-iam.md).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) in the *IAM User Guide*.

# Using service-linked roles for AWS WAF Classic
<a name="classic-using-service-linked-roles"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

AWS WAF Classic uses AWS Identity and Access Management (IAM)[ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to AWS WAF Classic. Service-linked roles are predefined by AWS WAF Classic and include all the permissions that the service requires to call other AWS services on your behalf. 

A service-linked role makes setting up AWS WAF Classic easier because you don’t have to manually add the necessary permissions. AWS WAF Classic defines the permissions of its service-linked roles, and unless defined otherwise, only AWS WAF Classic can assume its roles. The defined permissions include the trust policy and the permissions policy. That permissions policy can't be attached to any other IAM entity.

You can delete a service-linked role only after first deleting the role's related resources. This protects your AWS WAF Classic resources because you can't inadvertently remove permission to access the resources.

For information about other services that support service-linked roles, see [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes **in the **Service-Linked Role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.

## Service-linked role permissions for AWS WAF Classic
<a name="classic-slr-permissions"></a>

AWS WAF Classic uses the following service-linked roles:
+ `AWSServiceRoleForWAFLogging`
+ `AWSServiceRoleForWAFRegionalLogging`

AWS WAF Classic uses these service-linked roles to write logs to Amazon Data Firehose. These roles are used only if you enable logging in AWS WAF. For more information, see [Logging Web ACL traffic information](classic-logging.md).

The `AWSServiceRoleForWAFLogging` and `AWSServiceRoleForWAFRegionalLogging` service-linked roles trust the following services (respectively) to assume the role:
+ `waf.amazonaws.com`

  `waf-regional.amazonaws.com`

The permissions policies of the roles allow AWS WAF Classic to complete the following actions on the specified resources:
+ Action: `firehose:PutRecord` and `firehose:PutRecordBatch` on Amazon Data Firehose data stream resources with a name that starts with "aws-waf-logs-." For example, `aws-waf-logs-us-east-2-analytics`.

You must configure permissions to allow an IAM entity (such as a user, group, or role) to create, edit, or delete a service-linked role. For more information, see [Service-Linked Role Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.

## Creating a service-linked role for AWS WAF Classic
<a name="classic-create-slr"></a>

You don't need to manually create a service-linked role. When you enable AWS WAF Classic logging on the AWS Management Console, or you make a `PutLoggingConfiguration` request in the AWS WAF Classic CLI or the AWS WAF Classic API, AWS WAF Classic creates the service-linked role for you. 

You must have the `iam:CreateServiceLinkedRole` permission to enable logging.

If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you enable AWS WAF Classic logging, AWS WAF Classic creates the service-linked role for you again. 

## Editing a service-linked role for AWS WAF Classic
<a name="classic-edit-slr"></a>

AWS WAF Classic doesn't allow you to edit the `AWSServiceRoleForWAFLogging` and `AWSServiceRoleForWAFRegionalLogging` service-linked roles. After you create a service-linked role, you can't change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.

## Deleting a service-linked role for AWS WAF Classic
<a name="classic-delete-slr"></a>

If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up the resources for your service-linked role before you can manually delete it.

**Note**  
If the AWS WAF Classic service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.

**To delete AWS WAF Classic resources used by the `AWSServiceRoleForWAFLogging` and `AWSServiceRoleForWAFRegionalLogging`**

1. On the AWS WAF Classic console, remove logging from every web ACL. For more information, see [Logging Web ACL traffic information](classic-logging.md).

1. Using the API or CLI, submit a `DeleteLoggingConfiguration` request for each web ACL that has logging enabled. For more information, see [AWS WAF Classic API Reference](https://docs.aws.amazon.com/waf/latest/APIReference/Welcome.html).

**To manually delete the service-linked role using IAM**

Use the IAM console, the IAM CLI, or the IAM API to delete the `AWSServiceRoleForWAFLogging` and `AWSServiceRoleForWAFRegionalLogging` service-linked roles. For more information, see [Deleting a Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.

## Supported Regions for AWS WAF Classic service-linked roles
<a name="classic-slr-regions"></a>

AWS WAF Classic supports using service-linked roles in the following AWS Regions.


****  

| Region Name | Region Identity | Support in AWS WAF Classic | 
| --- | --- | --- | 
| US East (N. Virginia) | us-east-1 | Yes | 
| US East (Ohio) | us-east-2 | Yes | 
| US West (N. California) | us-west-1 | Yes | 
| US West (Oregon) | us-west-2 | Yes | 
| Asia Pacific (Mumbai) | ap-south-1 | Yes | 
| Asia Pacific (Osaka) | ap-northeast-3 | Yes | 
| Asia Pacific (Seoul) | ap-northeast-2 | Yes | 
| Asia Pacific (Singapore) | ap-southeast-1 | Yes | 
| Asia Pacific (Sydney) | ap-southeast-2 | Yes | 
| Asia Pacific (Tokyo) | ap-northeast-1 | Yes | 
| Canada (Central) | ca-central-1 | Yes | 
| Europe (Frankfurt) | eu-central-1 | Yes | 
| Europe (Ireland) | eu-west-1 | Yes | 
| Europe (London) | eu-west-2 | Yes | 
| Europe (Paris) | eu-west-3 | Yes | 
| South America (São Paulo) | sa-east-1 | Yes | 

# Logging and monitoring in AWS WAF Classic
<a name="classic-waf-incident-response"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

Monitoring is an important part of maintaining the reliability, availability, and performance of AWS WAF Classic and your AWS solutions. You should collect monitoring data from all parts of your AWS solution so that you can more easily debug a multi-point failure if one occurs. AWS provides several tools for monitoring your AWS WAF Classic resources and responding to potential events:

**Amazon CloudWatch Alarms**  
Using CloudWatch alarms, you watch a single metric over a time period that you specify. If the metric exceeds a given threshold, CloudWatch sends a notification to an Amazon SNS topic or AWS Auto Scaling policy. For more information, see [Monitoring with Amazon CloudWatch](monitoring-cloudwatch.md).

**AWS CloudTrail Logs**  
CloudTrail provides a record of actions taken by a user, role, or an AWS service in AWS WAF Classic. Using the information collected by CloudTrail, you can determine the request that was made to AWS WAF Classic, the IP address from which the request was made, who made the request, when it was made, and additional details. For more information, see [Logging API calls with AWS CloudTrail](logging-using-cloudtrail.md).

# Compliance validation for AWS WAF Classic
<a name="classic-waf-compliance"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

To learn whether an AWS service is within the scope of specific compliance programs, see [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) and choose the compliance program that you are interested in. For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/).

You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).

Your compliance responsibility when using AWS services is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. For more information about your compliance responsibility when using AWS services, see [AWS Security Documentation](https://docs.aws.amazon.com/security/).

# Resilience in AWS WAF Classic
<a name="classic-disaster-recovery-resiliency"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. 

For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).

# Infrastructure security in AWS WAF Classic
<a name="classic-infrastructure-security"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

As a managed service, AWS WAF Classic is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.

You use AWS published API calls to access AWS WAF Classic through the network. Clients must support the following:
+ Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
+ Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.

# AWS WAF Classic quotas
<a name="classic-limits"></a>

**Warning**  
AWS WAF Classic is is going through a planned end-of-life process. Refer to your AWS Health dashboard for the milestones and dates specific to your Region.

**Note**  
This is **AWS WAF Classic** documentation. You should only use this version if you created AWS WAF resources, like rules and web ACLs, in AWS WAF prior to November 2019, and you have not migrated them over to the latest version yet. To migrate your web ACLs, see [Migrating your AWS WAF Classic resources to AWS WAF](waf-migrating-from-classic.md).  
**For the latest version of AWS WAF**, see [AWS WAF](waf-chapter.md). 

AWS WAF Classic is subject to the following quotas (formerly referred to as limits). 

AWS WAF Classic has default quotas on the number of entities per account per Region. You can [request an increase](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase&limitType=service-code-waf) to these.


| Resource | Default quota per account per Region | 
| --- | --- | 
| Web ACLs  | 50 | 
| Rules  | 100 | 
| Rate-based-rules  | 5 | 
| Conditions per account per Region | For all conditions except for regex match and geo match, 100 of each condition type. For example, 100 size constraint conditions and 100 IP match conditions. For regex and geo match conditions, see the following table.  | 
| Requests per Second | 25,000 per web ACL\$1 | 

\$1This quota applies only to AWS WAF Classic on an Application Load Balancer. Requests per Second (RPS) quotas for AWS WAF Classic on CloudFront are the same as the RPS quotas support by CloudFront that is described in the [CloudFront Developer Guide](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html).

The following quotas on AWS WAF Classic entities can't be changed.


| Resource | Quota per account per Region | 
| --- | --- | 
| Rule groups per web ACL | 2: 1 customer-created rule group and 1 AWS Marketplace rule group | 
| Rules per web ACL | 10 | 
| Conditions per rule | 10 | 
| IP address ranges (in CIDR notation) per IP match condition | 10,000You can update up to 1,000 addresses at a time. The API call `UpdateIPSet` accepts a maximum of 1,000 addresses in a single request. | 
| IP addresses blocked per rate-based rule | 10,000 | 
| Minimum rate-based rule rate limit per 5 minute period | 100 | 
| Filters per cross-site scripting match condition | 10 | 
| Filters per size constraint condition | 10 | 
| Filters per SQL injection match condition | 10 | 
| Filters per string match condition | 10 | 
| In string match conditions, the number of characters in HTTP header names, when you've configured AWS WAF Classic to inspect the headers in web requests for a specified value | 40 | 
| In string match conditions, the number of characters in the value that you want AWS WAF Classic to search for | 50 | 
| Regex match conditions  | 10  | 
| In regex match conditions, the number of characters in the pattern that you want AWS WAF Classic to search for | 70 | 
| In regex match conditions, the number of patterns per pattern set | 10 | 
| In regex match conditions, the number of pattern sets per regex condition | 1 | 
| Pattern sets  | 5 | 
| Geo match conditions  | 50  | 
| Locations per geo match condition | 50 | 

AWS WAF Classic has the following fixed quotas on calls per account per Region. These quotas apply to the total calls to the service through any available means, including the console, CLI, AWS CloudFormation, the REST API, and the SDKs. These quotas can't be changed.


| Call type | Quota per account per Region | 
| --- | --- | 
| Maximum number of calls to AssociateWebACL |  1 request every 2 seconds   | 
| Maximum number of calls to DisassociateWebACL |  1 request every 2 seconds   | 
| Maximum number of calls to GetWebACLForResource  |  1 request per second  | 
| Maximum number of calls to ListResourcesForWebACL |  1 request per second  | 
| Maximum number of calls to CreateWebACLMigrationStack |  1 request per second  | 
| Maximum number of calls to GetChangeToken |  10 requests per second  | 
| Maximum number of calls to GetChangeTokenStatus |  1 request per second  | 
| Maximum number of calls to any individual List action, if no other quota is defined for it  |  5 requests per second  | 
| Maximum number of calls to any individual Create, Put, Get, or Update action, if no other quota is defined for it  |  1 request per second  |