WAF en mode journal : comment activer progressivement la protection sans bloquer le trafic légitime

Il existe une hypothèse courante selon laquelle l’activation de WAF est une décision binaire : cela bloque ou non. Les équipes qui commencent à partir de ce point activent les ensembles de règles gérés en mode Bloc directement en production, supposent que les règles sont suffisamment conservatrices, puis découvrent que le formulaire de téléchargement de contrat a cessé de fonctionner, que l'intégration avec passerelle de paiement renvoie 403 et que l'équipe d'assistance reçoit des plaintes de clients qui ne peuvent pas se connecter. Le WAF n'avait pas tort, mais il ne connaissait pas non plus l'application.

Que fait le mode Journal et pourquoi il existe

Cloudflare WAF propose trois actions possibles pour chaque règle : Bloquer, qui renvoie 403 et met fin à la requête ; Challenge, qui présente un défi au client ; et Log, qui enregistre l'événement sans interférer avec le flux. Le mode journal est le seul qui permet d'observer le comportement des règles par rapport au trafic réel sans conséquences pour les utilisateurs.

Lorsqu'un ensemble de règles est configuré avec une action de journalisation, toutes les règles se déclenchent normalement (évaluent les en-têtes, l'URI, le corps, la chaîne de requête) mais au lieu de bloquer, elles enregistrent simplement l'événement. Les événements de pare-feu dans le tableau de bord Cloudflare capturent chaque déclencheur : l'adresse IP d'origine, l'URI complet, l'ID de règle spécifique et le contenu exact à l'origine de la correspondance. La requête atteint le serveur d'origine intacte. L'utilisateur ne remarque rien.

La séquence de déploiement qui évite les incidents

Le processus commence par l'activation de tous les ensembles de règles gérés avec l'action définie sur Journaliser. Le niveau de paranoïa de l'OWASP doit être réglé sur 1 dès le début : ce niveau capture les schémas d'attaque les plus évidents avec le plus faible volume de faux positifs. Monter au niveau 2 ou 3 dès la première activation garantit presque un bruit excessif qui rend difficile la distinction des attaques réelles du trafic légitime et malformaté.

Avec les ensembles de règles dans le journal, le tableau de bord des événements du pare-feu doit être examiné quotidiennement. L'objectif est d'identifier les règles qui se déclenchent de manière cohérente sur des requêtes légitimes : le même URI, le même modèle de requête, la même règle. Un tir isolé peut être du bruit ; le même déclencheur sur des milliers de requêtes provenant d'utilisateurs réels est un faux positif qui bloquera le trafic lorsque l'action passe à Bloquer.

Lorsqu'un faux positif est identifié, la réponse consiste à créer une règle Skip : une règle de pare-feu qui demande au WAF d'ignorer les ensembles de règles ou les règles spécifiques lorsque des critères tels que l'URI et la méthode HTTP correspondent. Un point de terminaison /api/upload qui déclenche la règle 100035 car il accepte les fichiers avec une extension .php dans son nom reçoit une règle Skip qui exclut ce chemin de l'inspection par cette règle. L'exclusion est chirurgicale : tous les autres trafics continuent d'être évalués.

Après une à deux semaines avec les ensembles de règles dans le journal, les faux positifs traités avec les règles Ignorer et aucun nouveau déclencheur sur le trafic légitime, l'action devient Bloquer. Le critère est la stabilité et non le temps écoulé.

Lire avec précision les événements du pare-feu

Le tableau de bord Événements du pare-feu affiche chaque événement avec suffisamment de détails pour prendre une décision. En plus de l'IP et de l'URI, l'événement affiche l'ID de règle qui s'est déclenché (un identifiant tel que 949110 ou 100035 consultable dans la documentation Cloudflare) et les données correspondantes, la partie spécifique de la requête qui a provoqué la correspondance.

Ce champ de données apparié transforme l’enquête d’un faux positif de spéculation en un diagnostic concret. Si la règle 100035 s'est déclenchée sur POST /api/upload et que les données correspondantes affichent filename=relatorio.php, il est clair que la règle réagit au nom du fichier, et non au contenu malveillant dans le corps. La règle Skip résultante est précise : elle ignore la règle 100035 pour ce chemin uniquement. Tout autre point final qui reçoit un .php véritablement suspect continue d’être évalué.

Les alertes de notification pour les nouveaux événements WAF ferment la boucle de détection continue. Lorsque Cloudflare ajoute une nouvelle signature à un CVE en circulation, l'alerte en informe l'équipe et les événements de pare-feu indiquent si la nouvelle règle touche le trafic légitime avant qu'il ne soit trop tard.

WAF Analytics et intégration SIEM

Pour les équipes ayant des opérations de sécurité établies, les données des événements de pare-feu peuvent être exportées via Logpush. Logpush envoie les événements WAF à R2, S3, Datadog ou Splunk avec l'ensemble complet des champs : horodatage, IP, pays, URI, méthode, ID de règle, action entreprise et données correspondantes. Pour une équipe disposant d'un SOC actif, ces données alimentent des corrélations que le tableau de bord Cloudflare ne fournit pas : modèle d'attaque distribué par plusieurs IP contre le même point de terminaison au fil des heures, variations de charge utile testant quelle règle peut être contournée.

WAF Analytics regroupe ces événements dans une série chronologique au sein de Cloudflare. Lorsque l'action passe de Consigner à Bloquer, une augmentation inattendue du nombre de réponses 403 dans le trafic normal indique un faux positif qui a échappé à la phase d'observation - et l'ID de règle de l'événement vous indique exactement quoi gérer.

Créer des habitudes opérationnelles

WAF n'est pas une configuration unique. Les applications changent : de nouveaux points de terminaison sont ajoutés, les intégrations tierces introduisent des modèles de requêtes que WAF n'a jamais vus et Cloudflare met régulièrement à jour les ensembles de règles gérés.

Ce qui fonctionne, c'est l'attribution d'une responsabilité explicite : un membre de la plateforme ou de l'équipe de sécurité examine chaque semaine les événements du pare-feu. L’examen recherche de nouveaux modèles : des règles se déclenchant en grand nombre qui n’apparaissaient pas auparavant, une augmentation des confinements aux heures de pointe. Lorsqu'un nouveau point de terminaison entre en production, la séquence d'observation recommence pour ce chemin : journaliser d'abord, ignorer les règles pour les faux positifs, bloquer plus tard.