
Application Security - Managing false positives in AWS WAF
Thwart cyber threats, such as DDoS attacks, undesired bot traffic and malicious CVE exploits.
- 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.
- 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.
- 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.
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.