Bad bots - Guidelines for Implementing AWS WAF

Bad bots

To protect against bot traffic, you can use AWS WAF Bot Control. Bot Control allows you to monitor, block, or rate-limit bot traffic activity in real time and gain additional insights such as bot categories, identities, and other bot traffic details. When AWS WAF evaluates a web request against the Bot Control managed rule group, the evaluation adds labels to requests that it detects as bot related. This label information can then be used to create any custom rules. By blocking the bot traffic at the edge, your application costs and performance are unaffected. Bot Control can be added as a managed rule to any new or existing WAF web ACL.

IP reputation rule groups allow you to block requests based on their source. Blocking these IP addresses can help mitigate bots and reduce the risk of a malicious actor discovering a vulnerable application. You can also use reputation rules for bot protection. AWS WAF has two managed reputation lists: Amazon IP reputation list and Anonymous IP list. The Amazon IP reputation list rule group contains rules that are based on Amazon internal threat intelligence. The Anonymous IP list rule group contains rules to block requests from services that allow the obfuscation of viewer identity, and these include requests from VPNs, proxies, Tor nodes, and hosting providers (including AWS). 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.

You can configure AWS WAF rules to require WAF CAPTCHA challenges to be solved for specific resources that are frequently targeted by bots such as login, search, and form submissions. You can also require WAF CAPTCHA challenges for suspicious requests based on the rate, attributes, or labels generated from AWS Managed Rules, such as AWS WAF Bot Control or the Amazon IP reputation list.

You can use the AWS WAF Security Automations solution to defend against bots by implementing honeypots and behavioral detection with WAF logs. For more sophisticated detections of the most difficult bots involved in application-level attacks (such as bots attempting credential-stuffing), AWS recommends adding a bot management solution to your architecture. You can find third-party solutions on the AWS Marketplace that provide advanced bot mitigation capabilities. Some of these solutions also provide the ability to integrate with CloudFront using Lambda@Edge for inline protection.

You can add a scope-down statement inside some rules. The scope-down statement narrows the scope of the requests that the rule evaluates. If a rule has a scope-down statement, traffic is first evaluated using the scope-down statement. If it matches the scope-down statement criteria, then it's evaluated using the rule’s standard criteria. Traffic that doesn't match the scope-down statement is not evaluated further by AWS WAF. You can define a scope-down statement inside the following statement types:

  • Managed rule group statement – If you add a scope-down statement to a managed rule group statement, any request that doesn't match the scope-down statement results as not matching the rule group. Only requests that match the scope-down statement are evaluated against the rule group. For managed rule groups with pricing that’s based on the number of requests evaluated, scope- down statements can help contain costs. For more information about managed rule group statements, refer to the Managed rule group statement.

  • Rate-based rule statement – A rate-based rule without a scope-down statement controls the rate of all requests that come in to your applications. If you want to only control the rate for a specific category of requests, you add a scope-down statement to the rate-based rule. For example, to only track and control the rate of requests from a specific geographical area, you specify that geographical areas in a geographic match rule as the scope-down statement. For more information about rate-based rule statements, refer to the Rate-based rule statement.

AWS WAF uses web ACL capacity units to calculate and control the operating resources that are required to run your rules, rule groups, and web ACLs. AWS WAF calculates capacity differently for each rule type, to reflect each rule's relative cost. The maximum capacity for a web ACL is 5000, which is sufficient for most use cases. If you need more capacity, contact the AWS Support Center.