Azure WAF : encadrer une règle custom d’urgence sans perdre la preuve

Une règle custom Azure WAF est souvent créée dans un moment de pression : une attaque visible, un partenaire bloqué, un chemin d’administration exposé, une règle managée trop bruyante pendant une mise en production. Le danger n’est pas seulement de se tromper de condition. Le vrai risque est de poser une règle large, prioritaire, puis de ne plus savoir quelles requêtes elle masque, quels signaux OWASP disparaissent et quand elle doit être retirée.

Le cas d’usage traité ici est celui d’une équipe qui doit ajouter rapidement une custom rule sur une policy Application Gateway WAF. L’objectif n’est pas d’interdire les changements urgents. Il est de les rendre exploitables : périmètre clair, priorité justifiée, preuve avant/après, fenêtre de validité, seuil de rollback et trace dans le runbook.

Partir d’un symptôme précis

Une custom rule doit répondre à un symptôme observable. “Renforcer le WAF” est trop vague. “Bloquer temporairement les requêtes POST vers /login depuis une plage IP qui génère l’essentiel des échecs” est exploitable. “Autoriser tout /api/import parce qu’une règle CRS gêne un client” est probablement trop large.

Avant de modifier la policy, il faut capturer une fiche courte :

• URI, hostname, méthode, client ou pays concerné
• fenêtre temporelle observée
• règles WAF ou erreurs applicatives visibles
• décision attendue : bloquer, autoriser ou journaliser
• exemple de requête qui doit matcher
• exemple de requête qui ne doit pas matcher
• critère de rollback

Cette fiche courte évite de transformer une réaction d’incident en configuration permanente. Elle force aussi l’équipe à distinguer blocage, autorisation et simple observation.

Comprendre l’impact de la priorité

Sur Application Gateway WAF, les custom rules sont évaluées avant les règles managées. Une règle Block peut arrêter un trafic avant que les règles OWASP/CRS ou DRS ne produisent leurs signaux. Une règle Allow trop large peut laisser passer une requête qui aurait autrement été bloquée plus loin. La priorité n’est donc pas un détail de tri visuel : c’est une décision de diagnostic.

Avant publication, cinq points doivent être revus :

• la priorité est-elle plus haute que nécessaire ?
• la condition limite-t-elle le hostname, le chemin, la méthode ou la source ?
• l’action Allow est-elle vraiment indispensable ?
• la règle masque-t-elle une règle managée utile pour l’analyse ?
• une règle Log suffit-elle pendant quelques minutes pour mesurer le périmètre ?

Un bon réflexe consiste à commencer par une lecture KQL ou une action de journalisation quand l’urgence le permet. Si la règle doit bloquer immédiatement, son périmètre doit être plus strict que le symptôme observé, pas plus large.

Exemple : bloquer temporairement un bruit d’attaque

Imaginons une application publiée derrière Application Gateway WAF. Pendant une fenêtre courte, /login reçoit un volume anormal de POST depuis une plage source connue. Le login légitime doit rester ouvert pour les utilisateurs normaux. Une custom rule peut bloquer cette source sur ce chemin précis, avec une priorité documentée et une expiration opérationnelle.

La définition de règle doit rester explicite :

• policy : wafpol-app-prod
• nom de règle : block-login-noise-20260605
• action : Block
• priorité : 120
• condition de chemin : /login
• condition de méthode : POST
• condition de source : uniquement la plage confirmée

Cet exemple ne remplace pas une analyse sécurité complète. Il illustre une règle bornée : chemin, méthode, source et nom daté. Le nom daté est volontaire. Il rend la règle plus facile à retrouver pendant la revue et rappelle qu’elle n’a pas vocation à rester invisible dans la policy.

Préparer la preuve KQL avant le changement

Une règle urgente doit être observée dès sa création. La requête de suivi doit répondre à trois questions : la règle matche-t-elle ? Le volume est-il cohérent avec le symptôme ? Des chemins non prévus sont-ils touchés ?

La requête de suivi doit filtrer les logs firewall Application Gateway sur une fenêtre courte, isoler le nom de la règle temporaire, puis résumer les hits par tranche de temps, hostname et action. Elle doit être conservée dans le runbook avec le vrai nom de table utilisé dans l’environnement.

Selon le mode d’ingestion, les champs peuvent différer entre AzureDiagnostics et les tables dédiées comme AGWFirewallLogs. Le runbook doit donc préciser la table réellement utilisée par l’environnement, pas seulement la requête idéale.

Définir le rollback avant d’appuyer sur entrée

Le rollback d’une custom rule WAF ne doit pas être improvisé après les premiers retours utilisateurs. Il faut savoir comment désactiver la règle, quel signal déclenche ce retour arrière et qui valide la décision.

La procédure de rollback doit inclure :

• le nom exact de la règle
• la commande ou le chemin portail utilisé pour la désactiver
• le signal qui déclenche le retour arrière
• la personne ou l’équipe qui valide la décision
• la preuve à conserver après rollback

Le seuil peut être simple : augmentation d’erreurs applicatives sur /login, blocage de sources attendues, absence de baisse du bruit, ou impossibilité de relier les logs à la règle. Une règle qui ne produit pas de preuve exploitable doit être revue rapidement.

Ne pas transformer l’urgence en dette permanente

Après stabilisation, trois options existent. La règle peut être supprimée si le trafic disparaît. Elle peut être transformée en contrôle permanent si elle exprime une vraie politique de publication. Elle peut aussi être remplacée par une exclusion ciblée si le problème initial était un faux positif de règle managée.

La règle doit être revue après 24 ou 48 heures :

• la règle a-t-elle encore des hits ?
• les hits correspondent-ils au périmètre prévu ?
• les règles managées restent-elles utiles et visibles ?
• l’action Block, Allow ou Log est-elle toujours justifiée ?
• la règle doit-elle être supprimée, documentée ou migrée en IaC ?

Cette revue est importante pour la lisibilité de la policy. Une accumulation de règles custom datées, jamais retirées, rend le WAF difficile à expliquer pendant le prochain incident.

Conclusion

Une custom rule Azure WAF d’urgence est acceptable si elle reste bornée et prouvable. Le changement doit partir d’un symptôme précis, limiter le périmètre, documenter la priorité, surveiller l’effet en KQL et prévoir un rollback explicite.

La question à poser n’est pas seulement “est-ce que la règle bloque ?”. C’est “est-ce que nous savons ce qu’elle bloque, ce qu’elle masque, quand la retirer et comment prouver que le trafic légitime reste protégé ?”. C’est cette discipline qui transforme une réaction rapide en opération maîtrisée.