Building your first AWS WAF web ACL to protect against evolving threats

Applications face a variety of security threats, such as distributed denial of service (DDoS) attacks, web application exploits like SQL injection and cross-site scripting (XSS), and bot traffic.

In this post, to help protect your applications against these threats, we demonstrate how to build your first web access control list (web ACL) in AWS WAF. AWS WAF is a web application firewall that you use to monitor web requests and control access to your application. We cover building the initial version of your web ACL and show you how to evolve it to protect your web applications from external threats.

Initial rules in your AWS WAF web ACL

Step 1: Enable protection using one-click AWS WAF integration

To create an initial security posture that protects your application against the most common security threats, we recommend the following to provide out-of-the-box protections for your applications.

• If you are using Amazon CloudFront to host your applications, enable protection using CloudFront one-click AWS WAF integration
• If you are using Application Load Balancer (ALB) to host your applications, enable protection using ALB one-click AWS WAF integration

When you enable one-click AWS WAF integration with CloudFront or ALB, the service automatically creates a web ACL with the following AWS managed rule groups and attaches it to the resource. These managed rule groups protect your application from most common web threats, and they are applicable to most web applications. Using AWS managed rule groups saves you time to implement protection with AWS WAF, because AWS automatically updates managed rule groups and provides new versions of rule groups when new vulnerabilities and threats emerge.

• Amazon IP reputation list managed rule group
  The Amazon IP reputation list rule group contains rules that are based on Amazon internal threat intelligence. The rules inspect for IP addresses associated with bots or other threats. This helps to mitigate bot traffic and reduce the risk of a malicious actor discovering a vulnerable application.
• Core rule set (CRS) managed rule group
  The CRS rule group contains rules that are generally applicable to web applications. This provides protection against exploitation of a wide range of vulnerabilities, including some of the high risk and commonly occurring vulnerabilities described in OWASP publications, such as OWASP Top 10.
• Known bad inputs managed rule group
  The Known bad inputs managed rule group contains rules to block request patterns that are known to be invalid and are associated with exploitation or discovery of vulnerabilities. This helps reduce the risk of a malicious actor discovering a vulnerable application.

Step 2: Add additional commonly used AWS WAF rules

We recommend you also add the following AWS WAF rules that are commonly used for most web applications, which need configuration according to your requirements. If you have trusted sources, then add the IP allow list to allow traffic from your trusted sources to reduce false positives. You add the IP block list to block known malicious traffic that you identify over time, and you add a rate-based rule based on your application’s expected traffic patterns to protect against request floods.

• IP Allow list rule (if applicable)
  This rule provides a way to let known good traffic pass through. This rule typically includes trusted IP ranges from data centers and offices. You create an IP set to include trusted IP ranges, then create an IP set match rule and set rule action to Allow to allow requests from those IP ranges.
• IP Block list rule
  This rule provides a way to block known malicious sources without further processing. This rule typically includes IP ranges that indicate traffic from malicious sources. You create an IP set to include the IP ranges, then create an IP set match rule and set rule action to Block to block requests from those IP ranges. You start with an empty IP set, and then update the IP set to add malicious sources identified over time.
• Blanket rate-based rule
  The rate-based rule counts incoming requests and rate limits requests when exceeding the defined rate limit threshold. This rule protects your resource from getting a sudden spike of requests. You configure the rate-based rule with the rate limit threshold and evaluation window that you define to aggregate requests based on the source IP address, and set rule action to Block. To learn how to identify rate-based rule threshold and best practices on creating rate-based rules, refer to the post on the three most important AWS WAF rate-based rules.

Step 3: Enable AWS WAF logging

After configuring the rules in your web ACL, using the default Web ACL traffic overview dashboard, you quickly gain visibility into the traffic summary that the web ACL evaluates.

We recommend you also enable AWS WAF logging to get detailed information on the traffic. This visibility is useful for threat intelligence, hardening rules, troubleshooting false positives, and responding to an incident. To learn how to analyze AWS WAF logs, refer to the post Analyzing AWS WAF Logs in Amazon CloudWatch Logs and How to use Amazon Athena queries to analyze AWS WAF logs.

AWS WAF rule order and rule actions

Before we evolve from these initial rules in your web ACL, you must understand the concept of rule order and rule actions.

• Rules evaluation order: AWS WAF evaluates the rules from the lowest numeric priority settings in order, until it finds a match that terminates the evaluation. If none of the matching rules terminates the evaluation, then the web ACL default action is applied. The rule order significantly impacts flexibility and cost. You should place more specific rules before generic rules to ensure accurate matching and enforcement. You should also consider placing free AWS managed rule groups before Intelligent Threat Mitigation features to be cost-efficient. This is because when requests match the rules with the terminating action, AWS WAF stops processing the requests, which avoids further cost regarding AWS WAF pricing when requests are evaluated by intelligent threat mitigation rule groups.
• Terminating action and non-terminating action: The rule action tells AWS WAF what to do with a web request when it matches the criteria defined in the rule.
  AWS WAF supports five different actions for the rules: Allow and Block are terminating actions, which stop all other processing of the web ACL on the matching web request. Count is a non-terminating action, which means that, after matching a request, AWS WAF continues processing the following rules. Count action is commonly used to monitor requests matching the rule using AWS WAF metrics, or it’s used to apply AWS WAF label and evaluate later in the web ACL evaluation. CAPTCHA and Challenge are non-terminating or terminating actions, depending on whether or not the request has a valid AWS WAF token.

Thinking through your applications

Although the initial rules mentioned previously offer a good starting point for web application security, it is essential to fine-tune AWS WAF rules specific to your applications’ or companies’ needs. Each application has its unique characteristics, functionality, and potential attack vectors. Fine-tuning AWS WAF rules in consideration of these factors allows you to protect your web applications while minimizing the impact on legitimate traffic and user experience.

In the following three scenarios we observe the threats your web applications may face to see how your web ACL might look.

Scenario 1: DDoS Protection

Imagine a scenario where you have developed a web-based e-commerce platform allowing customers to browse products, add items to their cart, and complete purchases. In the past, you have experienced request floods on your application, which led to degraded response times. A core need revolves around protecting your application from malicious actors, and limiting the number of requests sent to your backends during request floods, particularly with stricter limits on requests with URIs such as “/search”, which are computationally expensive to process. In this scenario, your customers are only based in the United States.

You take the initial rules suggested in the first section and add the following rules for your web ACL with optimized prioritization:

• Update rule action of AWSManagedIPDDoSList rule in Amazon IP reputation list rule group to Block: The rule AWSManagedIPDDoSList inspects for IP addresses that have been identified as actively engaging in DDoS activities. By default, the rule action is Count to decrease a risk of false positives.
  After reviewing AWS WAF metrics for rule AWSManagedIPDDoSList, you see that the CountedRequests metric for this rule is minimum, and you are confident that this rule doesn’t cause false positives. Therefore, you override the rule action to Block.
• Add geographic match rule to block traffic outside of the United States: This geographic match rule blocks requests based on their country of origin. You create this rule to inspect requests that are not originating from the United States and set the rule action to Block.
• Add rate-based rule on particular URI paths: This rule protects particular URI paths such as “/search” with a stricter rate limit. You create the rate-based rule with a lower threshold than the blanket rate-based rule in the initial rules, and also limit the scope of inspection with a URI path matching “/search”.

In addition, we recommend using CloudFront to host your application to be more resilient against DDoS attacks. CloudFront only accepts well-formed connections, which helps prevent common DDoS attacks, such as SYN floods and UDP reflection attacks. CloudFront allows for the default AWS WAF quota on maximum number of requests per second per web ACL to be much higher when compared to regional resources such as ALB. For further guidance, see AWS Best Practices for DDoS Resiliency.

With these rules implemented, your web ACL looks like this:

Scenario 2: Web Application Exploits Protection

Imagine a scenario where you have developed a web-based human resources management system that uses a SQL database to store and manage employee records, payroll information, and other sensitive data. Over the past months, by analyzing application logs, your security team has identified a high volume of requests with URI and request body matching XSS and SQL injection attack patterns. You must implement robust security measures to protect the application and its underlying database. In addition, you want to ensure robust security measures for your customer login page, as well as security on the admin portal that you access.

You take the initial rules suggested in the first section and add the following rules for your web ACL with optimized prioritization. Note that the CRS managed rule group in the initial rules contains rules to block requests matching XSS patterns, so you don’t need to add new rules to protect from this attack.

• Add SQL database managed rule group: The SQL database rule group contains rules to block request patterns associated with the exploitation of SQL databases, such as SQL injection attacks. You add this rule group to prevent remote injection of unauthorized queries.
• Add admin protection managed rule group: The Admin protection rule group contains rules that allow you to block external access to exposed administrative pages. You add this rule group to reduce the risk of a malicious actor gaining administrative access to your application, and also limit the scope of inspection with a URI path matching your admin portal.
• Add size constraint rule on request body for login URI: You create this rule with a size constraint statement to restrict the request body size. You add this rule as a further layer of protection against injection attacks from malicious actors.
• Add rate-based rule for login URI: You determine that based on the application’s traffic patterns and requirements, a stricter rate-limiting rule protects from brute force attacks. You create this rate-based rule with a lower threshold than the blanket rate-based rule and scope of inspection with a URI path matching your login portal, and set the rule action to CAPTCHA.
  CAPTCHA is commonly used when a Block action stops too many legitimate requests, but letting all traffic through results in unacceptably high levels of unwanted requests. You set the rule action to CAPTCHA to minimize potential impact to legitimate users while mitigating a high volume of requests to the login URI.

With these rules implemented, your web ACL looks like this:

Scenario 3: Bot Mitigation

You are managing an online travel website that customers use to search and book flights, hotels, and other services. You recently found that although traffic to the website has increased considerably, the bookings haven’t increased. In addition, you have noticed a large number of login attempts to the website and fake accounts created and used in fraudulent activities. You suspect the website is experiencing malicious bot activities and would like to gain visibility into bot traffic and mitigate it.

You take the initial rules suggested in the first section and start by adding the following free or less expensive rules as a starting point to mitigate bot traffic.

• Add Anonymous IP list rule group with rule action set to Count: The Anonymous IP list rule group identifies requests originating from VPN, proxies, Tor nodes, and hosting providers. Restricting requests from these IP addresses helps mitigate bot traffic. You add this rule group and set the rule action to Count, because these requests can also be sent by your legitimate users. Moreover, instead of blocking them you set the action to Count, which allows you label these requests and rate limit them in the next step.
• Add rate-based rule for requests identified by Anonymous IP list rule group: This rule applies rate limit to the requests that hide their identity and are being identified by the preceding rule. You create the rate-based rule with lower threshold than the blanket rate-based rule in the initial rules, and also limit the scope of inspection with matching the label namespace “awswaf:managed:aws:anonymous-ip-list:”. Refer to the post how to customize the behavior of AWS managed rule groups for more details.
• Add rate-based rule for login and sign-up endpoints: This rule protects the login and sign-up endpoints with a stricter rate limit per source IP. You create the rate-based rule with a lower threshold than the blanket rate-based rule in the initial rules, and limit the scope of inspection with a URI path matching login and sign-up endpoint.
• Add AWS WAF Bot Control rule group with Common Inspection level for sensitive resources: The Bot Control managed rule group with common level protection identifies common bots by checking the details of the request against known bot patterns, performing reverse DNS lookups, and other system verifications. Bot Control is a premium feature and paid managed rule group, thus you must keep the costs under control. You add this rule group and limit the scope of inspection with certain URI paths or sensitive APIs, and leave static content such as images and CSS files out of the scope, which you may not mind bots accessing. Refer to the post Fine-tune and optimize AWS WAF Bot Control mitigation capability for more details.

After adding the preceding rules in your AWS WAF web ACL, using the web ACL traffic overview dashboard, you notice a large amount of bot traffic is now blocked. However, you also notice the following:

• Looking at your application metrics, the allowed traffic is still higher than the expected level, and the bookings in your website remain lower than the expected level.
• Although the login attempts and sign-ups in the backend are greatly reduced, they are still higher than expected.
• Looking at AWS WAF logs, there are many allowed requests that contain the same request headers as normal client browsers but exhibit abnormal behavior as compared to legitimate users.

You suspect that those requests are from malicious bots. You want to enable an advanced bot mitigation solution; so you add/update the following rules in order:

• Update AWS WAF Bot Control rule group with Targeted inspection level for sensitive resources: The Bot Control rule group with targeted level protection detects advanced bots that do not self-identify and applies mitigations such as rate limiting and challenge or CAPTCHA responses, besides common level protections. You update this rule group with the following setup:
  • Set Bot Control inspection level to Targeted.
  • Enable machine learning (ML) to detect and mitigate distributed, coordinated bot activity. This provides several rules based on the level of confidence that a group of requests are participants in a coordinated attack.
  • Set rule action for rule TGT_ML_CoordinatedActivityMedium to Challenge, and set rule action for rule TGT_ML_CoordinatedActivityHigh to Block.
• Add AWS WAF Fraud Control account takeover prevention rule group for login endpoint: The Fraud Control account takeover prevention rule group provides protection for your login endpoint against stolen credentials, credential stuffing attacks, brute force login attempts, and other anomalous login activities. You add this rule group and also limit the scope of inspection with a URI path matching login endpoint.
• Add AWS WAF Fraud Control account creation fraud prevention rule group for sign-up endpoint: The Fraud Control account creation fraud prevention managed rule group provides protection against the creation of fraudulent accounts on your site. You add this rule group and also limit the scope of inspection with a URI path matching sign-up endpoint.

Furthermore, you implement AWS WAF application integration SDKs in the application, because this makes the most effective use of the Bot Control and Fraud Control rule groups. The challenge script must run before the Bot Control and Fraud Control rule groups to benefit from the tokens that the script acquires, and with the application integration SDKs the script runs automatically.

With these rules implemented, your web ACL looks like this:

Conclusion

This post provides guidelines for building AWS WAF web ACL to protect your web applications against threats such as DDoS attacks, web application exploits, and malicious bots. You start by adding initial rules in your web ACL, then update and add further customized rules tailored to the threat that your application is facing and your application’s specific needs, while keeping in mind the importance of prioritizing rules. Following the guidelines in this post allows you to effectively protect your web applications against threats they are facing, minimize impact to legitimate traffic, and also be cost-efficient.

If you have feedback about this post, submit it in the Comments section. If you have questions about this post, start a new thread on AWS WAF re:Post or contact AWS Support.

About the authors