Azure FrontDoor WAF rate limit unexpected behavior

Question

Hi, recently I configured WAF on Azure FrontDoor, but I noticed that the “rate limit” feature not working as expected.
I have 2 rules configured with “rate limit”:

Then I used the following batch script to make requests to my URL:

@echo off  
Set count=0  
:a  
curl -N "https://%my_custom_url%/" -o NUL -s -w "%%{http_code}  "  
set /a count+=1  
Echo %time% request_number:%count%  
if %count% GEQ 50 goto b  
sleep 2  
goto :a  
:b  
pause  

Here I used the CURL utility to make 50 requests for ~2.5minutes. Where -N (Disable buffering of the output stream). -o NUL -s -w "%%{http_code} " part is used to output only status code, where if http_code == 200 then request completed without any problems, and 403 means that request was blocked by WAF.
Script output format: http_code local_time request_number.
I got the following result:
Only 7/50 requests were blocked.

And here are related logs from Azure:

Expected behavior: 5 requests completed successfully and 45 requests blocked. OR ~35 requests have to be logged by the “LogAfterRequestsCount” rule.

Manual page open from a browser (clean “private” window without cache): I was able to open the same website 3 times per row, after the next refresh I was blocked by WAF. If I close that browser window and try to open web site again from the new “private” window, I can open it 1-3 times before the block. That testing was done a few times, in less than 2 minutes (I was not exceeding 5 minutes intervals).
Expected behavior: I get banned for 5 minutes after I open the page 3 times.

Also, I was tried to make 500 requests using the same script, with the following result: 214/500 requests were blocked for 22 minutes. 0 requests were logged by the “LogAfterRequestsCount” rule. 158332-500-requests-output.txt

Notes: every time I open the page, I make 2 requests (page + favicon). My IP address was unchanged over the test period. I tried different rules configurations with the same result. I don’t have any other rules with priority numbers less than 30. I also tried to test that with the different query parameters, but the result is the same.

Am I’m right with my “expected behavior”? Is there any way to prevent, or at least make brute-force attacks more complicated using WAF?
Please suggest.
Thanks.

Related documentation:
https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/afds-overview#waf-rules
https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-rate-limit-powershell

Answer 1

Hello @Maksym Kharchenko2 ,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

The rate limit feature is designed to filter attacks (DOS) and it's approximate by design. Putting a really low number (like 5 per minute) is not going to work well because the counting is done post-response (as well as the propagation within the environment). In other words, one particular server is never going to block the first request from a given Client IP address.
Our documentation also states this is intended for high traffic:
Rate limiting rules: A rate control rule is to limit abnormal high traffic from any client IP. You may configure a threshold on the number of web requests allowed from a client IP during a one-minute duration.
Refer : https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/afds-overview

The system behaves this way because we are optimizing it for maximum performance (lowest latency and max throughput).

The rate limiting feature is optimized for DOS scenarios, so low thresholds may not start blocking traffic immediately once a client passes the threshold . An exact minimum threshold is not documented, but we generally recommend a setting it to a value of at least 30 or more (this is recommended by the WAF product group team). We have also requested them to update the documentation to include this information.

Could you try configuring the minimum threshold to 30 or more and try again?

Kindly let us know if the above helps or you need further assistance on this issue.

----------------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.