Managing false positives in AWS WAF
Overview
Adding security controls such as WAF to a web application, increases the risks of introducing false positives. False positives are the occurrences of blocking legitimate user requests, which is not a desirable side effect of using a WAF. Managing false positives include designing rules that minimize them, detecting their occurrences, and mitigating them either on the application side or on WAF. AWS WAF simplifies the management of false positives thanks to the flexibility of its rule language, and to the details available in its generated logs.
Designing WAF rules with low false positives
To reduce the low positives when using AWS WAF, carefully configure the rules in your WebACL. First, adjusting the detection threshold of rules. For example, this blog provides guidance on configuring rate limiting detection thresholds. Another example is to configure the detection sensitivity of SQL injection (SQLi) rules. Second, enable the most relevant rules on the most relevant part of your applications in the most specific way. For example, only enable SQLi rules if your application uses an SQL database, and scope it down to the URLs that interact with this database. Third, respond to matched requests with nuanced actions. With this approach, you would only configure a Block action for requests when you have high confidence in their maliciousness. When you have less confidence in blocking a request, consider one of the following nuanced response strategies:
- Count the request, and let it flow upstream to your application, but include a WAF generated header in the request forwarded to your application. Your application can then respond differently based on the header value, for example trigger Multi-Factor Authentication with suspicious login attempts. You can also dynamically increase the WAF response severity based on the ongoing threat level. For example, OLX dynamically change the response to suspicious IPs based on the risk level on their application. In low risk mode, they let more traffic pass through to their application, which minimizes false positives. In high risk mode, they prefer reducing false negative over false positive by blocking all suspicious IPs.
- Respond with a CAPTCHA or silent challenges, which will only block the request if the browser fails the challenge.
Amazon Managed Rules
AWS WAF provides a list of Amazon Managed Rule groups (AMR) that can be added to your WAF WebACL. AMRs are curated to block the most critical and impactful threats, while minimizing false positives.
To better manage false positives, AMRs provides you with the the following configuration possibilities:
- You can disable automatic updates by AMR, and instead use and manually update to specific version. This would give you the opportunity to test updates for false positives before enabling the latest version.
- AMRs emit labels when they are evaluated. Instead of using AMRs default blocking rules, you set them to count, and use the emitted labels in combination with other WAF rules to block requests with a higher confidence level. For example, you can use Amazon IP reputation list AMR in count mode, and then create a subsequent rule based on labels emitted by this AMR to rate limit with very low threshold. AMR generated labels are described in the WAF documentation.
The same applies to the managed rule group created by Shield Advanced when you have subscribed to this service and enabled automatic application layer DDoS mitigation. As described in the documentation, Shield Advanced place blocking rules WAF, only if it has high confidence that the rule only matches the attack signature, based on historical traffic patterns.
Identifying false positives
The following guidance helps you identify false positives when they occur:
- Include false positive detection in your software release processes or infrastructure change processes, for example by testing your WAF rules in developement and staging environements, then validating them in Count mode in production before final deployment. The AWS WAF documentation provides guidelines for deploying Bot Control rules and Account Takeover Prevention rules to production in a safe way.
- Set up alarming on CloudWatch metrics emitted by WAF rules. You will be notified when a rule is matching traffic at abnormal levels. For example, this could occur following an application code change, wrongly identified as an attack, that propagated to production.
- Enable WAF logging, and regularly audit blocked traffic to identify legitimate traffic that has been blocked. For simple use cases, you can use the sampled request dashboard in AWS WAF console.
- Update your application to allow users to report unexpected 403 responses. For example, when WAF is deployed with CloudFront, you can use CloudFront's custom error page to return, instead of the 403 error page, a page in which they can report the issue to you.
Excluding false positives from rule scope
When a false positive is identified, you can update your WAF rules to add exclusions and mitigate the false positive. With custom rules, exclusions can be simply expressed using AND/OR logic. For example, apply SQLi rules if the request's IP is not part of an allowed IP list, and the request URL is not one of the excluded URLs. With AMRs, you can create exclusions using scope-down statements. Consider the following documentation for managing false positives specific to WS WAF Bot Control AMRs.