Azure WAF : diagnostiquer un rate limit avant d'augmenter le seuil

Un rate limit Azure WAF peut proteger une application et casser un parcours legitime dans la meme minute. Les requetes sont bloquees, les utilisateurs voient des 403 ou des 429 selon la couche exposee, les equipes applicatives demandent d’augmenter le seuil, et la securite craint de rouvrir une porte a un abus reel. Sous pression, le mauvais reflexe consiste a multiplier le seuil par deux pour faire redescendre l’incident. Cela peut masquer un bot, un retry storm, une mauvaise cle de comptage ou une integration qui concentre tout son trafic derriere une seule IP.

Le cas d’usage est une application exposee derriere Azure Application Gateway WAF ou Azure Front Door WAF avec une custom rule de rate limiting. Depuis un deploiement ou une campagne metier, une partie du trafic est bloquee. L’objectif du runbook n’est pas de trouver le seuil parfait dans l’urgence. Il est de decider si le blocage est attendu, si la cle de comptage est adaptee, si le trafic est legitime, si une exception ciblee suffit, ou s’il faut rollbacker la regle.

Figer le contrat de rate limiting

Commencez par decrire ce que la regle devait proteger. Un rate limit n’est pas seulement un nombre par minute. C’est un contrat entre un chemin applicatif, une population de clients, une cle de comptage, une fenetre temporelle et une action.

Regle observee
Surface: Application Gateway WAF ou Azure Front Door WAF
Policy: waf-prod-public-api
Regle: rl-login-submit
Hostname: api.example.com
Chemin: /auth/login
Fenetre: 1 minute
Seuil: 120 requetes
Cle de comptage attendue: client IP, IP + header, ou autre signal supporte
Action: Block ou Log

Questions avant changement
La regle protege-t-elle un endpoint sensible ou un parcours normal ?
Le seuil a-t-il ete calcule sur du trafic reel ou pose par prudence ?
Une passerelle, un proxy ou un NAT concentre-t-il plusieurs utilisateurs ?
Le blocage touche-t-il quelques clients, un pays, un tenant ou tout le trafic ?
Existe-t-il une version precedente de policy ou une bascule vers Detection ?

Sans ce contrat, l’equipe discute d’un seuil abstrait. Avec ce contrat, elle peut separer erreur de regle, pic legitime, abus et probleme applicatif.

Mesurer le blocage avant de toucher au seuil

Le premier paquet de preuves doit montrer le volume bloque, les chemins, les clients, la distribution temporelle et la regle exacte. La requete ci-dessous donne une base a adapter aux noms de champs disponibles dans vos diagnostics WAF.

let Window = 2h;
let Hostname = "api.example.com";
AzureDiagnostics
| where TimeGenerated > ago(Window)
| where Category == "ApplicationGatewayFirewallLog"
| extend hostname = tostring(host_s)
| extend uri = tostring(requestUri_s)
| extend action = tostring(action_s)
| extend ruleName = tostring(ruleName_s)
| extend ruleId = tostring(ruleId_s)
| extend clientIp = tostring(clientIp_s)
| extend transactionId = tostring(transactionId_g)
| where hostname == Hostname
| where action in ("Blocked", "Matched")
| where ruleName has "rate" or ruleId has "rate"
| summarize hits=count(), clients=dcount(clientIp), samples=make_set(uri, 8), firstSeen=min(TimeGenerated), lastSeen=max(TimeGenerated) by bin(TimeGenerated, 5m), ruleName, ruleId
| order by TimeGenerated asc

Si les logs ne montrent pas clairement la regle de rate limiting, ne modifiez pas encore le seuil. Il faut d’abord prouver que le blocage vient bien du WAF et pas d’une API gateway, d’APIM, d’une application, d’un CDN, d’un bot manager ou d’un composant amont.

Identifier qui consomme le quota

Un rate limit echoue souvent parce que la cle de comptage ne represente pas l’utilisateur reel. Une IP source peut cacher un NAT d’entreprise, un proxy mobile, un egress d’integration, un runner de test ou une fonction serverless. A l’inverse, un bot peut distribuer son trafic sur plusieurs adresses.

let Window = 2h;
AzureDiagnostics
| where TimeGenerated > ago(Window)
| where Category == "ApplicationGatewayFirewallLog"
| extend uri = tostring(requestUri_s)
| extend clientIp = tostring(clientIp_s)
| extend userAgent = tostring(userAgent_s)
| extend ruleName = tostring(ruleName_s)
| where ruleName has "rate"
| summarize hits=count(), uris=make_set(uri, 5), agents=make_set(userAgent, 5), firstSeen=min(TimeGenerated), lastSeen=max(TimeGenerated) by clientIp
| order by hits desc
| take 30

L’objectif n’est pas d’identifier une personne. Il est de comprendre si le quota est consomme par une population legitime, une integration mal regulee, un test, un incident de retry ou un trafic hostile.

Comparer trafic bloque et trafic accepte

Une regle trop stricte ne se voit pas seulement dans les blocs. Elle se lit en comparant les requetes bloquees aux requetes acceptees sur le meme parcours. Si le blocage arrive apres une serie de reponses applicatives lentes ou d’erreurs 5xx, le rate limit peut etre la consequence d’un retry storm.

let Window = 2h;
let PathPrefix = "/auth/login";
AzureDiagnostics
| where TimeGenerated > ago(Window)
| where Category in ("ApplicationGatewayAccessLog", "ApplicationGatewayFirewallLog")
| extend uri = tostring(requestUri_s)
| extend action = tostring(action_s)
| extend status = toint(httpStatus_d)
| where uri startswith PathPrefix
| summarize total=count(), blocked=countif(action == "Blocked"), errors=countif(status >= 500), slowSamples=countif(timeTaken_d > 3) by bin(TimeGenerated, 5m)
| order by TimeGenerated asc

Si les erreurs ou la latence augmentent avant les blocs, augmenter le seuil risque d’envoyer plus de trafic vers un backend deja degrade. La bonne action peut etre un rollback applicatif, une limitation cote client, un cache, ou une protection temporaire plus stricte sur une route precise.

Tester la regle en mode borne

Avant d’augmenter le seuil en production, preparez une validation bornable. Le meilleur test depend de votre surface : policy en Detection, environnement de preproduction avec trafic rejoue, custom rule plus specifique, exclusion limitee au chemin ou passage temporaire par une regle d’observation.

Validation avant changement
Rejouer un echantillon de trafic legitime avec correlation ID
Verifier que les requetes abusives restent bloquees
Mesurer le nombre de clients reels derriere les principales IP
Comparer p95/p99 applicatifs avant et apres la modification
Garder la fenetre de changement courte
Nommer le proprietaire de decision securite et applicatif

Changement acceptable
Seuil ajuste sur un chemin precis
Regle plus specifique au lieu d'un seuil global
Periode de Detection limitee dans le temps
Exemption temporaire pour une integration identifiee
Rollback de policy pret et teste

Une augmentation globale du seuil doit rester l’exception. Si le probleme vient d’une cle de comptage trop grossiere, le vrai correctif est de changer le design de la regle ou du chemin d’entree, pas seulement le nombre.

Decider augmenter, cibler ou rollbacker

La decision doit relier preuves WAF, metriques applicatives et risque securite. Elle doit dire quoi faire maintenant et ce qui sera recontrole apres le changement.

Augmenter le seuil
Trafic legitime prouve
Backend sain pendant la fenetre
Cle de comptage coherente
Aucun signal d'abus ou d'enumeration
Nouvelle valeur justifiee par une mesure
Surveillance post-change active

Cibler la regle
Quelques IP concentrent des utilisateurs legitimes
Un endpoint ou une integration porte le pic
Le seuil global protegerait moins bien le reste du site
Une condition sur host, path, method ou header reduit le risque

Bloquer le changement
Source du blocage non prouvee
Retry storm ou backend degrade
Trafic hostile probable
Pas de rollback de policy
Pas de validation applicative ni securite

Rollbacker
Hausse des erreurs backend apres modification
Blocages legitimes persistent
Contournement de protection observe
Alertes securite ou metriques WAF deviennent incoherentes

Le rollback doit restaurer la policy precedente, le mode de la regle, sa priorite et les conditions associees. Revenir seulement au seuil initial ne suffit pas si une exception ou une priorite a ete modifiee pendant l’incident.

Conclusion

Un rate limit WAF exploitable ne se pilote pas a l’intuition. Il se pilote avec un contrat clair, des logs lisibles, une comprehension de la cle de comptage, une comparaison avec l’etat applicatif et une decision reversible.

La bonne sortie n’est pas toujours d’augmenter le seuil. C’est parfois de cibler la regle, de corriger une integration trop bavarde, de traiter une latence backend, de passer temporairement en observation ou de rollbacker une policy trop large. Le seuil ne doit changer que lorsque l’equipe peut expliquer quel trafic sera libere, quel risque reste bloque et comment revenir en arriere.