Azure WAF : quand utiliser des custom rules avant les règles managées OWASP

Les règles managées OWASP/CRS ou DRS protègent contre de nombreuses classes d’attaques applicatives, mais elles ne portent pas toute la logique métier d’une exposition web. Parfois, le bon contrôle n’est pas une exclusion. C’est une custom rule qui bloque ou autorise un trafic très précis avant que la requête n’arrive au reste de l’analyse WAF.

Le scénario traité ici est celui d’une application publiée derrière Azure Application Gateway WAF. L’équipe voit des blocages, des faux positifs et du bruit. Elle doit décider quand ajuster une règle managée, quand créer une exclusion, et quand utiliser une custom rule pour exprimer une politique d’accès plus simple : pays, IP, header, méthode, chemin ou condition spécifique.

Cas fil rouge : /admin ne doit pas être public

Le même portail partenaire expose une zone /admin utilisée par l’équipe support. L’authentification applicative reste obligatoire, mais l’organisation veut réduire l’exposition : seuls les postes de support sortant par 198.51.100.0/24 doivent atteindre cette route. Les partenaires et Internet ne doivent jamais voir cet endpoint, même si leurs requêtes ne déclenchent aucune règle OWASP.

Ce n’est pas un faux positif WAF. Il n’y a donc aucune raison de créer une exclusion. Le besoin est une politique d’accès HTTP : bloquer /admin pour toute source qui n’appartient pas au réseau attendu. C’est typiquement un cas de custom rule.

Ne pas utiliser une exclusion pour faire du contrôle d’accès

Une exclusion retire une partie de la requête de l’inspection d’une règle ou d’un groupe de règles. Ce n’est pas un mécanisme de contrôle d’accès. Si le besoin est de bloquer une IP, de limiter une méthode HTTP ou de protéger un chemin d’administration, une custom rule est souvent plus lisible.

Besoin : le paramètre comment déclenche une règle SQLi à tort
Option probable : exclusion ciblée par règle

Besoin : /admin ne doit être accessible que depuis des IP internes
Option probable : custom rule de blocage ou d'autorisation selon IP et chemin

Besoin : bloquer les méthodes TRACE et OPTIONS sur Internet
Option probable : custom rule sur RequestMethod

Besoin : désactiver une règle OWASP entière pour tout le site
Option à éviter sauf justification forte et temporaire

Cette séparation clarifie la gouvernance. Les règles managées traitent les signatures d’attaque. Les custom rules expriment des contraintes de publication propres à l’application.

Comprendre l’ordre de traitement

Dans Azure WAF, les custom rules ont une priorité et sont évaluées avant les règles managées. Cela signifie qu’une règle de blocage peut arrêter une requête avant que les règles OWASP ne la voient. C’est puissant, mais cela peut aussi masquer des signaux si la règle est trop large.

Ordre logique
1. Custom rules selon priorité
2. Règles managées OWASP/CRS ou DRS
3. Décision finale selon policy et mode

Conséquence
Une custom rule trop large peut réduire la visibilité sur les règles managées
Une custom rule précise peut réduire le bruit et bloquer tôt un trafic non désiré

La priorité doit être documentée. Une règle de blocage IP globale n’a pas le même impact qu’une règle ciblée sur /admin.

Exemple de custom rule par chemin et IP

Un cas classique consiste à limiter un chemin d’administration à quelques sources. Le WAF ne remplace pas l’authentification de l’application, mais il peut réduire l’exposition réseau HTTP.

RG=rg-network-prod
POLICY=wafpol-app-prod

az network application-gateway waf-policy custom-rule create --resource-group $RG --policy-name $POLICY --name block-admin-outside-trusted --priority 100 --rule-type MatchRule --action Block --match-conditions '[
  {
    "matchVariables": [{"variableName": "RequestUri"}],
    "operator": "Contains",
    "matchValues": ["/admin"]
  },
  {
    "matchVariables": [{"variableName": "RemoteAddr"}],
    "operator": "IPMatch",
    "negationConditon": true,
    "matchValues": ["198.51.100.0/24"]
  }
]'

Le champ negationConditon est volontairement écrit comme dans le modèle Azure Application Gateway WAF. Cette faute de frappe historique dans l’API surprend souvent à la relecture ; la corriger en negationCondition peut casser l’exemple selon l’outil utilisé. En IaC, il faut suivre le schéma du provider réellement utilisé et éviter de traduire automatiquement ce nom de propriété.

Cet exemple illustre l’intention, pas un copier-coller universel. En production, il faut vérifier la syntaxe CLI exacte utilisée par l’équipe, préférer l’IaC si c’est le standard, et tester la règle sur un environnement non critique.

Surveiller l’effet dans les logs

Une custom rule doit être observable. Après création, il faut vérifier le volume de blocage, les chemins concernés et les sources. Si la règle bloque beaucoup plus que prévu, elle est trop large ou mal ordonnée.

AzureDiagnostics
| where TimeGenerated > ago(24h)
| where Category == "ApplicationGatewayFirewallLog"
| where ruleId_s has "block-admin-outside-trusted" or message_s has "block-admin-outside-trusted"
| summarize blocks=count(),
          clients=dcount(clientIp_s),
          sampleUri=any(requestUri_s)
by hostname_s, action_s
| order by blocks desc

Selon le format de log, le nom de custom rule peut apparaître dans des champs différents. L’important est d’avoir une requête de suivi avant de considérer le changement terminé. Sur une policy critique, cette requête doit être préparée avant le changement, avec une fenêtre de surveillance et un seuil de retour arrière.

Pour /admin, le test utile est double : une requête depuis 198.51.100.0/24 doit continuer jusqu’à l’authentification applicative, tandis qu’une requête depuis une IP externe doit être bloquée par la custom rule. Si les deux cas ne sont pas testés, la règle peut être soit inefficace, soit trop restrictive.

Garder les règles managées comme socle

Les custom rules ne doivent pas devenir un remplacement artisanal d’OWASP. Elles sont utiles pour exprimer une politique locale claire. Les règles managées restent le socle de protection contre les classes d’attaque générales. Quand une custom rule bloque trop tôt un trafic suspect, elle peut aussi empêcher de voir quelles règles OWASP auraient réagi. Ce n’est pas toujours un problème, mais il faut le savoir.

Questions de revue
La custom rule exprime-t-elle un besoin d'accès ou de publication ?
La priorité est-elle justifiée ?
La règle masque-t-elle des signaux OWASP utiles ?
Existe-t-il une requête KQL de suivi ?
Le retour arrière est-il documenté ?

Conclusion

Une custom rule Azure WAF est pertinente quand le besoin est d’exprimer une politique d’accès précise : bloquer un chemin, une méthode, une source ou une combinaison simple de conditions. Une exclusion est pertinente quand une règle managée inspecte trop agressivement une partie légitime de la requête.

Le bon design garde les responsabilités séparées. Les custom rules portent les contraintes propres à l’exposition. Les règles OWASP/CRS ou DRS restent le socle de détection. Les exclusions restent ciblées et justifiées. C’est cette séparation qui permet d’améliorer le WAF sans le rendre illisible.