- Newest
- Most votes
- Most comments
Hi, It seems to me that you are looking to restrict the number of calls from a particular IP address in a specific time period for a specific resource. If this is correct then this use-case would fit into the second rate based rule (URI-specific rate-based rule) out of three rate based rule as mentioned by AWS documentation here.
It would been more useful if you could have given your precise example and what is your expection that is 'not working' but in absence of it lets assume a maximum of 50 calls in an interval of 5 minutes is allowed.
In this scenario although it seems reasonable to expect that the 51st call will be blocked if made within any 5 minute window, but it may not work. There are rate based rule caveats in AWS WAF that indicates that AWS WAF estimates and does not guarantee and exact limit match.
High level process:
- The request comes in and the counter needs to be incremented in the sliding window of 5 minutes
- This state of counter and IP address map is maintained somewhere this needs updating
- The enforcement engine needs to look into the incoming ip check the current count and make a decision...
In a HA and resilient system the requests would come enforcement needs to take place in a distributed way but the state needs to be in sync a single place. Its not an easy problem to solve, if you do too much calculations and synchronous checking at every request then you risk adding significant latencies that may not be desirable hence some of these key steps to propogate the data, counting and enforcing would take place asynchronously and periodically. The above may help undertand why the AWS documentaion talks about propogation delays (which are generally less than 30 seconds).
Now imagine if you send 30 requests in first second 10 seconds and 30 requests in next 10 seconds, effectively sending 60 requests within 20 seconds and during these two requests the evaluation has not taken place, so the requests will go through successfully, and this should explain why 51st and subsequent calls are not blocked.
The question you need to double click is around your use-case - Do you need to detect (monitor) or enforce (block) the call? Are you in breach of compliance or some other policy if more calls from an IP goes through? Do you need this detection / prevention (blocking) for authenticated requests in that case you may want to consider using usage plan in AWS API gateway as it can use api keys to count.
If your use-case requires you to block all calls above a certain threshold and you need guarantee then you may have to implement a bespoke solution with some kind of centralised database (dynamo db - global tables) and using Lambda (may be at edge) or any other third party components/solutions but remember you have to weigh the pros and cons (added latency mainly) of the solution and engineering effort needed to build and maintain the solution.
The behavior you're experiencing with AWS WAF rules not working as expected, particularly for throttling controls, is a known characteristic of how AWS WAF implements rate-based rules.
AWS WAF's rate limiting is designed to control high request rates and protect application availability, but it's not intended for precise request-rate limiting. The system uses an algorithm that gives more importance to recent requests when estimating the current request rate. This can lead to situations where requests may exceed or fall below the set limit for several minutes before AWS WAF detects and applies or removes rate limiting.
There are a few factors to consider:
-
Detection delay: It's possible for requests to come in at a higher rate than your set limit for up to several minutes before AWS WAF detects and starts rate limiting them. Similarly, the request rate can be below the limit for a period before AWS WAF detects the decrease and stops rate limiting.
-
Estimation algorithm: AWS WAF doesn't guarantee an exact limit match but applies rate limiting near the limit you set.
-
Evaluation window: Each time AWS WAF estimates the request rate, it looks back at requests during the configured evaluation window, which can cause some delay in applying limits.
-
Rule changes: If you modify any rate limit settings in an active rule (such as evaluation window, rate limit, request aggregation settings, etc.), it resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.
To improve your WAF implementation:
-
Allow some time for the WAF configuration changes to propagate, especially if testing immediately after making changes.
-
Enable AWS WAF logging and inspect the logs to see if your requests are being matched against the rules. This can help determine why requests are not being blocked as expected.
-
Consider implementing additional layers of protection, such as client-side checks or server-side validations, to complement WAF rules.
-
If precise control is crucial, you might need to explore alternative or additional solutions to supplement WAF's rate-based rules.
Remember, WAF's rate-based rules are designed for efficiency in controlling high request rates rather than for exact request-rate limiting. Adjusting your expectations and implementation strategy accordingly may help in achieving your security goals.
Sources
Rate-based rule caveats in AWS WAF - AWS WAF, AWS Firewall Manager, and AWS Shield Advanced
AWS WAF rate limiting is not working as expected. | AWS re:Post
WAF IP Blocking not working | AWS re:Post
If you could share your WAF rules, it may help indicate where the problem lies
Thanks
Hi, we need to understand what type of rule you want to configure and block. Below are some examples of four standard rules within AWS WAF:
1. SQL Injection What it is: Blocks attempts to inject SQL commands aimed at accessing or manipulating database data.
How to configure:
- Go to AWS WAF in the Console.
- Create or edit a Web ACL.
- Click "Add Rule" > "Add my own rules and rule groups".
- Select "Rule builder".
- Rule name: SQLInjectionRule.
- In "Inspect", choose Body, Query string, or both.
- In "Match type", select "SQL injection".
- Action: Block.
2. Cross-site Scripting (XSS) What it is: Prevents malicious scripts from executing in other users’ browsers.
How to configure:
- Inside the Web ACL, click "Add Rule".
- Select "Rule builder".
- Rule name: XSSRule.
- In "Inspect", select Body, URI, or Headers.
- In "Match type", select "Cross-site scripting (XSS)".
- Action: Block.
3. Rate-based Rule What it is: Limits the number of requests from a single IP within a specific time window.
How to configure:
- In the Web ACL, click "Add Rule".
- Rule name: RateLimitRule.
- Check "Rate-based rule".
- Set the rate limit (e.g., 100 requests every 5 minutes).
- Scope: per IP.
- Action: Block or Count.
4. AWS Managed Rules What it is: AWS-managed rule sets with automatic updates for known threats.
How to configure:
- In the Web ACL, click "Add Rule" > "Use a managed rule group".
- Select a provider (e.g., AWS, AWSManagedRulesCommonRuleSet).
- Add the group.
- Default action: Block (or Count if you prefer to monitor first).
I hope this was helpful. If you have any further questions, feel free to leave a message
Relevant content
- asked 9 months ago
- asked 2 years ago
AWS OFFICIALUpdated a year ago
Thank you - your understanding of my problem is spot on and your scenario have explained why i was seeing the behaviour i saw. We like to avoid latency where we can so i guess your challenge to have a second pass at the rquirement is a great suggestion.