Working with web ACLs can be really difficult at times, especially when you have a large, distributed environment and don't necessarily have a dedicated security team to create and manage the rules on a regular basis. Luckily for us, AWS makes things far simpler by providing easy to use and customize CloudFormation templates that can spin up a single web ACL, with all the basic security conditions configured, in a mere matter of minutes! The collective solution is called AWS WAF Security Automations, and, is available free of charge for all to use. All the end user has to do is specify which security feature is required, configure that, and deploy the solution! The rest is completely taken care of by AWS itself!

The architecture of the AWS WAF Security Automation solution is relatively simple, and comprises of a few more AWS services than AWS WAF, such as AWS Lambda, Amazon CloudWatch, Amazon API Gateway, and Amazon S3, as depicted in the diagram later in this section.

At the core of the solution is the WAF service that acts as the central point for making all security-related decisions and filtering. Based on the inputs specified by the user during the CloudFormation template's configuration, the respective solution components get activated accordingly. These components are further explained here:

• Honeypot for bad bots and scraper protection (A): This security component automatically sets up a honeypot to lure and deflect a possible attack on your application. The solution provides you with an API Gateway endpoint that you need to insert into your web application as a trap to detect and lure inbound requests from various bots and scrapers. If a source accesses the trap request, an associated Lambda function intercepts that request, gathers its source IP address, and adds the same to the WAF's web ACL block list.
• SQL injection protection (B) and cross-site scripting protection (C): Selecting this solution enables the creation of two AWS WAF rules that provide protection against commonly occurring SQL injection or cross-site scripting patterns:

• HTTP flood, scanner and probe protection (D): Also called log parsing protection, this solution comes in handy when you want to analyze your web application's access logs for any abnormalities that can cause a potential threat. This is performed by a dedicated AWS Lambda function that does the parsing of the access logs which get stored in a S3 bucket created by the CloudFormation template itself.
• IP address whitelist/blacklist (E): Similar to the SQL injection and cross-site scripting solution, WAF creates two rules to allow you to manually enter IP addresses that you wish to either allow or block to your application.
• Known-attacker protection (F): This solution also leverages a simple Lambda function that monitors certain third-party sites for a list of potential IP addresses to block against threats. The sites include Spamhaus (https://www.spamhaus.org/drop/), Proofpoint (https://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt), and TOR (https://check.torproject.org/exit-addresses), to name a few.

With these basics in mind, let's quickly move on to deploying these solutions using the CloudFormation templates. At the time of writing this book, AWS WAF Security Automations provides two templates for use: one intended for the CloudFront CDN based deployments and the other for the Application Load Balancer. Both of the templates provide a default configuration that consists of a web ACL with eight pre-configured sets of rules that you can always change or extend as required. The following are the links to download the respective templates:

• CloudFront CDN-based template: https://s3.amazonaws.com/solutions-reference/aws-waf-security-automations/latest/aws-waf-security-automations.template
• Application Load Balancer-based template: https://s3.amazonaws.com/solutions-reference/aws-waf-security-automations/latest/aws-waf-security-automations-alb.template

With the correct template downloaded, we can now move on to configuring and deploying the solution using CloudFormation:

1. To do so, first log in to your CloudFormation dashboard by navigating to https://console.aws.amazon.com/cloudformation/home. Note that in this case, we will be deploying the CloudFront CDN-based template in the N.Virginia region.
2. In the CloudFormation dashboard, select the option Create new stack to get started. Here, in the Select Template page, you can either choose to upload your downloaded template, or simply copy the template's URL in the Specify an Amazon S3 template URL field, as shown in the following screenshot. Click on Next to continue with the setup:

3. In the Specify Details page, you can start off by providing a suitable Stack name for your CloudFormation stack.
4. Next, in the Parameters section, select the Protection services that you wish to opt for. Remember, these are the same services that we discussed at the beginning of this section. In this case, I've opted for a rather simple setup that involves activating protection against SQL injection, cross-site scripting, and bad bots. You can alternatively select your own protection services, as required.
5. Moving on, in the CloudFront Access Log Bucket Name field, provide a unique name for the S3 bucket that will store your Amazon CloudFront's access logs. You can either provide the name of an existing bucket or a new one.
6. Finally, in the Advanced Settings section, you can additionally opt to modify a few parameters, such as Request Threshold, Error Threshold, and the WAF Block Period, as per your requirements. These parameters would come in handy especially if you select the HTTP Flood Protection or the Activate Scanners & Probes Protection, otherwise, you can leave these values to their defaults, as I have done in my case. Select Next to continue with the deployment process.

7. In the Options page, you can specify Tags for the resources that will be created by the CloudFormation template, as well as opt to provide any special IAM Role to allow CloudFormation to create, modify, or delete the resources in the stack. Click on Next to review the changes made and, finally, go ahead with the stack's creation by selecting the Create option on the Review page.

8. The stack takes a good few minutes to deploy successfully. Once done, you can verify the status of your stack's completion by checking the Status column, as depicted in the following screenshot:

9. Additionally, based on your Protection service selection, you can also verify the additional outputs created by the template for your application, such as the Honeypot Endpoint, that's actually an Amazon API Gateway endpoint that you need to insert somewhere in your application to capture bots and scrapers. In my case, the template created a Lambda function for bad bots scraping, WAF rules for SQL injections, IP whitelisting, and XSS detection, along with an API Gateway as well.

10. With the stack up and running, you can additionally go back to the WAF dashboard and check out the individual rules that the template auto-populated against some of the protection services. In this case, the SQL injection and cross-site scripting conditions were auto-populated; however, the IP Whitelist and Bad Bot rules still require you to manually provide the IP ranges and addresses to start off with, or allow the Lambda function to inject the IP addresses into the lists at runtime as well. Here is a snapshot of the list of rules created for the SQL injection condition:

With this we come to the end of this particular section. You can additionally use these templates to spin up newer web ACLs for your Application Load Balancers. Just remember to delete your stack once your testing is completed, to avoid incurring any unnecessary charges. In the next section, we will be briefly looking at how to effectively monitor your WAF rules using a few essential monitoring tools provided by AWS.