Step 1. Launch the stack

Choose the type of resource being used.

Choose yes to turn on the component designed to add Amazon IP reputation List Managed Rule Group to the web ACL.

This rule group is based on Amazon internal threat intelligence. This is useful if you want to block IP addresses typically associated with bots or other threats. Blocking these IP addresses can help mitigate bots and reduce the risk of a malicious actor discovering a vulnerable application.

The required WCU is 25. Your account should have sufficient WCU capacity to avoid web ACL stack deployment failure due to exceeding the capacity limit.

For more information, see AWS Managed Rules rule groups list.

Choose yes to turn on the component designed to add Anonymous IP List Managed Rule Group to the web ACL.

This rule group blocks requests from services that permit the obfuscation of viewer identity. These include requests from VPNs, proxies, Tor nodes, and hosting providers. This rule group is useful if you want to filter out viewers that might be trying to hide their identity from your application. Blocking the IP addresses of these services can help mitigate bots and evasion of geographic restrictions.

The required WCU is 50. Your account should have sufficient WCU capacity to avoid web ACL stack deployment failure due to exceeding the capacity limit.

For more information, see AWS Managed Rules rule groups list.

Choose yes to turn on the component designed to add Core Rule Set Managed Rule Group to the web ACL.

This rule group provides protection against exploitation of a wide range of vulnerabilities, including some of the high risk and commonly occurring vulnerabilities. Consider using this rule group for any AWS WAF use case.

The required WCU is 700. Your account should have sufficient WCU capacity to avoid web ACL stack deployment failure due to exceeding the capacity limit.

For more information, see AWS Managed Rules rule groups list.

Choose yes to turn on the component designed to add Admin Protection Managed Rule Group to the web ACL.

This rule group blocks external access to exposed administrative pages. This might be useful if you run third-party software or want to reduce the risk of a malicious actor gaining administrative access to your application.

The required WCU is 100. Your account should have sufficient WCU capacity to avoid web ACL stack deployment failure due to exceeding the capacity limit.

For more information, see AWS Managed Rules rule groups list.

Choose yes to turn on the component designed to add Known Bad Inputs Managed Rule Group to the web ACL.

This rule group blocks external access to exposed administrative pages. This might be useful if you run third-party software or want to reduce the risk of a malicious actor gaining administrative access to your application.

The required WCU is 100. Your account should have sufficient WCU capacity to avoid web ACL stack deployment failure due to exceeding the capacity limit.

For more information, see AWS Managed Rules rule groups list.

Choose yes to turn on the component designed to add SQL Database Managed Rule Group to the web ACL.

This rule group blocks request patterns associated with exploitation of SQL databases, like SQL injection attacks. This can help prevent remote injection of unauthorized queries. Evaluate this rule group for use if your application interfaces with an SQL database. Using the SQL injection custom rule is optional if you already have AWS managed SQL rule group activated.

The required WCU is 200. Your account should have sufficient WCU capacity to avoid web ACL stack deployment failure due to exceeding the capacity limit.

For more information, see AWS Managed Rules rule groups list.

Choose yes to turn on the component designed to add Linux Operating System Managed Rule Group to the web ACL.

This rule group blocks request patterns associated with the exploitation of vulnerabilities specific to Linux, including Linux-specific Local File Inclusion (LFI) attacks. This can help prevent attacks that expose file contents or run code for which the attacker should not have had access. Evaluate this rule group if any part of your application runs on Linux. You should use this rule group in conjunction with the POSIX operating system rule group.

The required WCU is 200. Your account should have sufficient WCU capacity to avoid web ACL stack deployment failure due to exceeding the capacity limit.

For more information, see AWS Managed Rules rule groups list.

Choose yes to turn on the component designed to add Core Rule Set Managed Rule Group Protection to the web ACL.

This rule group blocks request patterns associated with the exploitation of vulnerabilities specific to POSIX and POSIX-like operating systems, including LFI attacks. This can help prevent attacks that expose file contents or run code for which the attacker should not have had access. Evaluate this rule group if any part of your application runs on a POSIX or POSIX-like operating system.

The required WCU is 100. Your account should have sufficient WCU capacity to avoid web ACL stack deployment failure due to exceeding the capacity limit.

For more information, see AWS Managed Rules rule groups list.

Choose yes to turn on the component designed to add Windows Operating System Managed Rule Group to the web ACL.

This rule group blocks request patterns associated with the exploitation of vulnerabilities specific to Windows, like remote execution of PowerShell commands. This can help prevent exploitation of vulnerabilities that permit an attacker to run unauthorized commands or run malicious code. Evaluate this rule group if any part of your application runs on a Windows operating system.

The required WCU is 200. Your account should have sufficient WCU capacity to avoid web ACL stack deployment failure due to exceeding the capacity limit.

For more information, see AWS Managed Rules rule groups list.

Choose yes to turn on the component designed to add PHP Application Managed Rule Group to the web ACL.

This rule group blocks request patterns associated with the exploitation of vulnerabilities specific to the use of the PHP programming language, including injection of unsafe PHP functions. This can help prevent exploitation of vulnerabilities that permit an attacker to remotely run code or commands for which they are not authorized. Evaluate this rule group if PHP is installed on any server with which your application interfaces.

The required WCU is 100. Your account should have sufficient WCU capacity to avoid web ACL stack deployment failure due to exceeding the capacity limit.

For more information, see AWS Managed Rules rule groups list.

Choose yes to turn on the component designed to add WordPress Application Managed Rule Group to the web ACL.

This rule group blocks request patterns associated with the exploitation of vulnerabilities specific to WordPress sites. Evaluate this rule group if you are running WordPress. This rule group should be used in conjunction with the SQL database and PHP application rule groups.

The required WCU is 100. Your account should have sufficient WCU capacity to avoid web ACL stack deployment failure due to exceeding the capacity limit.

For more information, see AWS Managed Rules rule groups list.

If you chose yes for the Activate Scanner & Probe Protection parameter, enter the name of the Amazon S3 bucket (new or existing) where you want to store access logs for your CloudFront distribution(s) or ALB(s). If you’re using an existing Amazon S3 bucket, it must be located in the same AWS Region where you are deploying the CloudFormation template. You should use a different bucket for each solution deployment.

To deactivate this protection, ignore this parameter.

If you chose yes for the Activate Scanner & Probe Protection parameter, you can enter an optional user defined prefix for the application access logs bucket above.

If you chose CloudFront for the Endpoint parameter, you can enter any prefix such as yourprefix/.

If you chose ALB for the Endpoint parameter, you must append AWSLogs/ to your prefix such as yourprefix/AWSLogs/.

Use AWSLogs/ (default) if there isn't a user-defined prefix.

To deactivate this protection, ignore this parameter.

Choose yes if you entered an existing Amazon S3 bucket name for the Application Access Log Bucket Name parameter and the server access logging for the bucket is already turned on.

If you choose no, the solution turns on server access logging for your bucket.

If you chose no for the Activate Scanner & Probe Protection parameter, ignore this parameter.

If you chose yes for the Activate Scanner & Probe Protection parameter, enter the maximum acceptable bad requests per minute, per IP address.

If you chose no for the Activate Scanner & Probe Protection parameter, ignore this parameter.

If you chose yes - Amazon Athena log parser for the Activate Scanner & Probe Protection parameter, the solution applies partitioning to application access log files and Athena queries. By default, the solution moves log files from their original location to a partitioned folder structure in Amazon S3.

Choose yes if you also want to keep a copy of the logs in their original location. This will duplicate your log storage.

If you didn’t choose yes - Amazon Athena log parser for the Activate Scanner & Probe Protection parameter, ignore this parameter.

If you chose yes for the Activate HTTP Flood Protection parameter, enter the maximum acceptable requests per five minutes, per IP address.

If you chose yes - AWS WAF rate-based rule for the Activate HTTP Flood Protection parameter, the minimum acceptable value is 100.

If you chose yes - AWS Lambda log parser or yes – Amazon Athena log parser for the Activate HTTP Flood Protection parameter, it can be any value.

To deactivate this protection, ignore this parameter.

If you chose yes – Amazon Athena log parser for the Activate HTTP Flood Protection parameter, you can enter a threshold by country following this JSON format {"TR":50,"ER":150}. The solution uses these thresholds for the requests originated from the specified countries. The solution uses the Default Request Threshold parameter for the remaining requests.

If you chose to deactivate this protection, ignore this parameter.

If you chose yes – Amazon Athena log parser for the Activate HTTP Flood Protection parameter, you can choose a group-by field to count requests per IP and the selected group-by field. For example, if you choose URI, the solution counts the requests per IP and URI.

If you chose to deactivate this protection, ignore this parameter.

If you chose yes - AWS Lambda log parser or yes – Amazon Athena log parser for the Activate Scanner & Probe Protection or Activate HTTP Flood Protection parameters, enter the period (in minutes) to block applicable IP addresses.

To deactivate log parsing, ignore this parameter.

If you chose yes – Amazon Athena log parser for the Activate Scanner & Probe Protection or Activate HTTP Flood Protection parameters, you can enter a time interval (in minutes) over which the Athena query runs. By default, the Athena query runs every 5 minutes.

If you chose to deactivate these protections, ignore this parameter.

Provide an optional ARN of an IAM role that has write access to CloudWatch logs in your account. For example: ARN: arn:aws:iam::account_id:role/myrolename. See Setting up CloudWatch logging for a REST API in API Gateway for instructions on how to create the role.

If you leave this parameter blank (default), the solution creates a new role for you.

If you chose yes for the Activate HTTP Flood Protection parameter, enter the maximum acceptable requests per five minutes, per IP address.

If you chose yes - AWS WAF rate-based rule for the Activate HTTP Flood Protection parameter, the minimum acceptable value is 100.

If you chose yes - AWS Lambda log parser or yes – Amazon Athena log parser for the Activate HTTP Flood Protection parameter, it can be any value.

To deactivate this protection, ignore this parameter.

Choose yes to turn on the component designed to block common SQL injection attacks. Consider activating it if you aren’t using an AWS managed core rule set or AWS managed SQL database rule group.

You can choose one of the options (yes (continue), yes - MATCH, or yes - NO_MATCH) that you want AWS WAF to handle oversized request exceeding 8 KB (8192 bytes). By default, yes inspects the request component contents that are within the size limitations according to the rule inspection criteria. For more information, refer to Handling oversize web request components.

Choose no to deactivate this feature.

Choose the sensitivity level that you want AWS WAF to use to inspect for SQL injection attacks.

HIGH detects more attacks, but might generate more false positives.

LOW is generally a better choice for resources that already have other protections against SQL injection attacks or that have a low tolerance for false positives.

For more information, refer to AWS WAF adds sensitivity levels for SQL injection rule statements and SensitivityLevel property in the AWS CloudFormation User Guide.

If you choose to deactivate SQL injection protection, ignore this parameter.

Choose yes to turn on the component designed to block common XSS attacks. Consider activating it if you aren’t using an AWS managed core rule set. You can also select one of the options (yes (continue), yes - MATCH, or yes - NO_MATCH) that you want AWS WAF to handle oversized request exceeding 8 KB (8192 bytes). By default, yes uses the Continue option, which inspects the request component contents that are within the size limitations according to the rule inspection criteria. For more information, refer to Oversize handling for request components.

Choose no to deactivate this feature.

If you want to activate IP retention for the Allowed IP set, enter a number (15 or greater) as the retention period (minutes). IP addresses reaching the retention period expire, and the solution removes them from the IP set. The solution supports a minimum 15-minute retention period. If you enter a number between 0 and 15, the solution treats it as 15.

Leave it as -1 (default) to turn off IP retention.

If you want to activate IP retention for the Denied IP set, enter a number (15 or greater) as the retention period (minutes). IP addresses reaching the retention period expire, and the solution removes them from the IP set. The solution supports a minimum 15-minute retention period. If you enter a number between 0 and 15, the solution treats it as 15.

Leave it as -1 (default) to turn off IP retention.

If you activated the IP retention period parameters (see two previous parameters) and want to receive an email notification when IP addresses expire, enter a valid email address.

If you didn’t activate IP retention or want to turn off email notifications, leave it blank (default).

If you want to activate retention for the CloudWatch Log Groups, enter a number (1 or greater) as the retention period (days). You can choose a retention period between one day (1) and ten years (3650). By default logs will expire after one year.

Set it to -1 to keep the logs indefinitely.