Azure Front Door WAF rate-limit behind NAT

Hi,

Thank you for the prompt response. Unfortunately this doesn't help all that much. We cannot safely put values in a header match rule that would be different per client.

Imagine if someone behind a NAT network opened our login page and entered some credentials and for some unknown reason the API call to authorize the credentials starts hitting the endpoint multiple times per second. How would I construct a rate-limit rule to say "this person behind the NAT network is abusing my endpoint, rate-limit them" instead of "this IP is abusing my endpoint, rate-limit it"?

And of course, the rule should be such that an actual attacker would get blocked, and that blocking should happen at the edge (where the rate-limit rules are defined).

Thank you again for your answers,
Vasilis

Hello @Pantelis, Vasilis ,

Thank you for the update.

Let me discuss this requirement with the Azure Front Door Product Group to get more information and will keep you posted.

Regards,
Gita

Hello @Pantelis, Vasilis ,

Below is the response from our Product Group team on this requirement:

There is no straightforward way to achieve this. Some of the options that can be tried are as below:

1) We can match based on specific url and do rate limiting only for that url. For example we can do rate limiting based on www.contoso-ad.com/login.php
Refer the rate limiting section in the below blog where this approach is covered:
https://techcommunity.microsoft.com/t5/azure-network-security-blog/azure-waf-custom-rule-samples-and-use-cases/ba-p/2033020

2) There are some header values which are unique per client ( e.g: Cookie ). Those header values can be leveraged.

3) Other option is to ask the NAT device to insert X-Forward-for header with the client ip value

Kindly let us know if the above helps.
I've also reached out to the Azure WAF Product Group team and awaiting their response. Will keep you posted.

Regards,
Gita

Hello @Pantelis, Vasilis ,

One more addition to this:

There are two type of match variables in IP address match, RemoteAddr and SocketAddr. RemoteAddr is the original client IP that is usually sent via X-Forwarded-For request header. SocketAddr is the source IP address WAF sees. If your user is behind a proxy, SocketAddr is often the proxy server address.

You can configure a rate limiting rule with the "RemoteAddr" match variable.

Refer : https://video2.skills-academy.com/en-us/azure/web-application-firewall/afds/waf-front-door-configure-ip-restriction

Regards,
Gita

Hello again,

Sorry for the delay in my response. This is pretty much what we already knew about Azure Front Door. It's impossible to control our customers' network configuration so a lot of them will probably not use a proxy that applies the X-Forwarded-For header in requests but use NAT on a lower level.

Cookies are probably the only way that makes some sense as they can be created per session and then used as a parameter for rate-limiting. We are considering our options but would love to see automatic cookie handling or some other mechanism on Azure Front Door for rate limiting, in the sense that we would like to leverage Azure's edge network to do this work for us and not have packets even reaching our backend if they are considered malicious per our rate-limiting rules.

Thank you for your time and effort in this request.

Kind regards,
Vasilis