Configuration de Cloudflare WAF : un déploiement sûr et testable

Un web application firewall est plus efficace lorsqu'il est exploité comme un contrôle mesuré et non comme un interrupteur ponctuel. Commencez par le chemin de trafic protégé, établissez une baseline, déployez un changement étroit, observez le trafic mitigé comme légitime et conservez un chemin de rollback rapide. C'est particulièrement important pour les API et les clients non navigateurs, pour lesquels un challenge interactif peut être une interruption de service plutôt qu'un contrôle de sécurité.

Cloudflare WAF évalue les requêtes web et API entrantes à l'aide de rulesets. Ses Managed Rules fournissent une couverture de détection maintenue, tandis que les Custom Rules permettent à une équipe d'exprimer des conditions et actions propres à l'application. Ni les uns ni les autres ne remplacent un code applicatif sécurisé, l'authentification, les contrôles de débit ou un firewall d'origine qui rejette le trafic direct.

Prérequis

• Un hostname Cloudflare proxifié et une politique d'accès à l'origine confirmée qui autorise Cloudflare tout en refusant le trafic direct non fiable.
• Un accès à la zone adapté à la modification et à la revue de la configuration WAF, ainsi qu'un responsable de rollback désigné.
• Un inventaire des pages navigateur, API, clients mobiles, webhooks, intégrations partenaires, contrôles de disponibilité et routes administratives.
• Un hostname de staging ou un périmètre canari de production avec un endpoint de test inoffensif et des identifiants client représentatifs.
• Un accès à Cloudflare Security Events, aux logs origine/application et aux enregistrements de déploiement avec des horodatages synchronisés.

Avant de modifier la politique, capturez une courte baseline pour les parcours navigateur et machine critiques. Pour un endpoint de santé non sensible, une simple requête peut confirmer le statut et les en-têtes de réponse :

curl -sS -D - -o /dev/null https://api.example.com/health

Pour les API authentifiées, utilisez un principal de test approuvé et un endpoint hors production ou canari. Ne placez pas de bearer tokens, cookies, URL signées, corps de requête ou identifiants client dans l'historique shell, des terminaux partagés, des captures d'écran ou des tickets de support.

Comprendre les couches et l'ordre des règles

Utilisez chaque couche pour sa fonction :

L'ordre des règles modifie le comportement. Cloudflare évalue les Custom Rules dans l'ordre de la liste, et une action terminale telle que Block ou Managed Challenge peut empêcher l'exécution des Custom Rules suivantes. Cloudflare indique que les Custom Rules s'exécutent avant les WAF Managed Rules ; une action terminale dans une phase de sécurité antérieure peut donc empêcher les Managed Rules d'évaluer cette requête. Dans les exceptions de managed rules, un skip ne s'applique qu'aux managed rules exécutées après cette exception, donc l'emplacement est important.

Établissez une carte d'ordre avant le déploiement. Pour chaque règle proposée, écrivez sa correspondance, son action, le type de client attendu, les dépendances, les règles terminales antérieures possibles, les contrôles ultérieurs qu'elle peut empêcher et la commande ou modification de configuration de rollback. Revérifiez la documentation Cloudflare sur l'interopérabilité des fonctionnalités de sécurité actuelle avant de vous appuyer sur une séquence d'exécution, car les phases et intégrations du produit évoluent.

Étape 1 : déployer les Managed Rules avec un plan d'observation

Les managed rulesets sont des protections préconfigurées que Cloudflare met à jour pour traiter les techniques d'attaque et vulnérabilités courantes. Commencez par examiner les rulesets actuellement disponibles, leurs valeurs par défaut et la disponibilité selon le plan dans la documentation Managed Rules. Notez qu'une mise à jour de managed ruleset peut affecter le trafic de production après le déploiement initial ; la responsabilité et la surveillance continue font partie de la configuration.

Pour le déploiement initial :

1. Définissez les hosts protégés et les routes à forte valeur, notamment les chemins de connexion, d'administration, d'upload et d'API.
2. Confirmez que chaque client critique peut être testé : navigateur, application mobile, client API server-to-server, expéditeur de webhook et moniteur synthétique.
3. Commencez en staging ou dans un périmètre de production contraint lorsque la conception du service le permet.
4. Observez les événements de sécurité et les erreurs applicatives sur une fenêtre de trafic représentative avant d'ajouter des exceptions ou de modifier des actions.
5. Examinez une règle correspondante avec le contexte de requête et les éléments de preuve de l'origine ; ne supprimez pas une règle sur le seul nombre d'alertes.

Les managed rules inspectent le contenu des requêtes uniquement dans les limites documentées, qui varient selon le plan et la configuration. Les uploads volumineux et formes de requêtes inhabituelles nécessitent donc des tests explicites. Cloudflare met aussi à jour ses managed rulesets et leur couverture ; confirmez donc le comportement actuel dans la documentation liée plutôt que de traiter un ID de règle historique, une action par défaut ou une limite de corps comme permanent.

Étape 2 : ajouter les Custom Rules une par une

Créez une Custom Rule uniquement pour un besoin applicatif précis et observé : par exemple, un motif d'exploitation étroit contre un endpoint public, du trafic qui ne devrait jamais atteindre un chemin administratif ou un contrôle d'incident temporaire avec une revue d'expiration. Préférez des propriétés de requête stables telles que le host, le chemin, la méthode et une identité de service validée aux correspondances larges sur User-Agent, la géographie ou l'IP.

Utilisez une règle de test canari qui ne peut correspondre qu'à un host de test dédié et à un en-tête de test aléatoire. Son expression et son action exactes doivent être examinées dans votre workflow habituel de configuration. Utilisez ensuite une requête telle que :

curl -sS -D - -o /dev/null \
  -H 'X-WAF-Test: replace-with-a-random-test-value' \
  https://staging.example.com/__waf-test

Confirmez l'action attendue dans Cloudflare Security Events, la réponse HTTP attendue côté client et l'absence ou présence attendue d'une requête d'origine. Supprimez la règle canari une fois le modèle de déploiement démontré. Ne testez pas un WAF de production en envoyant de véritables payloads d'exploitation, des requêtes destructrices ou du trafic de scan tiers vers une infrastructure partagée.

Cloudflare Custom Rules utilise le Rules language et les évalue dans l'ordre. La référence Custom Rules actuelle fait autorité pour les champs, actions, quotas et disponibilités selon le plan pris en charge. Utilisez ses instructions dashboard, API ou Terraform selon le système de configuration que votre équipe peut examiner et annuler ; évitez de recopier des libellés dashboard ou une syntaxe de règle depuis un ancien runbook sans vérifier la documentation actuelle.

Étape 3 : rendre explicite le comportement des API et non-navigateurs

Un challenge navigateur peut être utile pour un parcours navigateur interactif, mais il est souvent incompatible avec les API JSON, SDK mobiles, webhooks, callbacks de paiement, clients en ligne de commande et contrôles de disponibilité. Pour chaque route protégée, documentez le client attendu et le contrat d'échec :

• Les routes navigateur peuvent avoir une politique de challenge, avec un chemin de récupération et de support accessible.
• Les API machine-to-machine doivent recevoir une réponse de refus prévisible et lisible par machine, et utiliser une authentification, autorisation, validation de schéma et des contrôles de débit robustes.
• Les endpoints webhook et partenaires doivent authentifier cryptographiquement l'expéditeur lorsque cela est pris en charge ; ne vous appuyez pas sur un contrôle orienté navigateur.
• Les intégrations de monitoring et de déploiement nécessitent des conditions d'accès délibérément ciblées et expirantes. Une allowlist IP permanente large ou un skip global est un chemin d'attaque, pas une stratégie d'exception.

Exécutez des tests client approuvés après chaque changement de règle. Vérifiez un parcours navigateur autorisé, une requête API valide, une requête invalide attendue, un test webhook lorsque disponible et une sonde de monitoring. Incluez le code de statut, le type de contenu de réponse, la latence, le résultat applicatif et si la requête a atteint l'origine. Une page 403 ou de challenge n'est pas nécessairement un échec API correct ; le contrat du consommateur détermine ce qui est correct.

Étape 4 : examiner les logs sans créer de fuite de données

Cloudflare Security Events aide à identifier les requêtes sur lesquelles Cloudflare a agi ou qu'il a signalées, et peut être filtré par règle, action, host, chemin et autres dimensions. Utilisez-le pour corréler un changement de règle candidat avec les erreurs applicatives et les rapports client. Toutefois, Cloudflare documente que Security Events peut utiliser des données échantillonnées ; c'est un élément utile pour l'investigation, pas un enregistrement complet de chaque requête. Conservez et corrélez la télémétrie origine, application et SIEM appropriée pour les services critiques.

Traitez les exports d'événements de sécurité, fichiers HAR, logs d'origine et identifiants de trace comme des données opérationnelles sensibles. Ils peuvent contenir des URL avec paramètres de requête, adresses IP client, identifiants, en-têtes ou détails de payload. Appliquez un accès de moindre privilège et des limites de rétention ; masquez tokens, cookies, en-têtes d'autorisation, URL signées, données personnelles et corps de requête avant de partager les éléments de preuve. Utilisez un canal d'incident sécurisé plutôt que de coller des événements bruts dans des tickets ou un chat.

Pendant l'investigation, ne collectez que le minimum nécessaire : plage horaire UTC, hostname, modèle de route plutôt qu'une URL personnelle brute, action, identité de règle ou ruleset, catégorie de client, ID de corrélation de requête lorsque disponible et résultat applicatif assaini. La documentation Security Events de Cloudflare explique les limites de filtrage, d'échantillonnage, de rétention et d'export.

Étape 5 : utiliser des exceptions ciblées, pas des contournements larges

Un faux positif est un élément à examiner, pas une raison automatique de désactiver une protection. Identifiez d'abord la managed rule précise et le plus petit ensemble de requêtes légitimes qui entre en conflit avec elle. Cloudflare recommande une exception ou un ajustement de règle précis plutôt que de désactiver un ruleset entier lorsqu'une seule règle est responsable.

Une exception doit être aussi étroite que les preuves le permettent :

• Faites correspondre le hostname et le chemin exacts, et incluez la méthode HTTP lorsqu'elle distingue la requête.
• Limitez-la au client authentifié ou à la condition d'intégration vérifiée uniquement lorsque ce signal est fiable.
• Ignorez uniquement la managed rule ou le composant de ruleset impliqué, et non tous les produits de sécurité, lorsqu'un périmètre plus étroit est pris en charge.
• Documentez la raison métier, le responsable, la date de création, la date de revue, le cas de test et la condition de suppression.
• Retestez la requête légitime comme une route protégée non liée après avoir placé l'exception dans l'ordre requis.

N'utilisez jamais une exception large pour masquer une intégration défaillante. Corrigez si possible l'encodage de requête, la validation applicative, l'authentification client ou la conception de route sous-jacente. Consultez les conseils Cloudflare de dépannage des managed rules et les conseils sur les exceptions WAF pour le comportement actuel des exceptions et overrides.

Rollback

1. Identifiez la règle, l'override de managed rule ou l'exception nouvelle exacte dans l'enregistrement de changement ; conservez d'abord les éléments d'événement pertinents et assainis.
2. Désactivez ou supprimez uniquement ce changement récent en utilisant le même chemin de configuration examiné que celui qui l'a déployé.
3. Réexécutez les contrôles navigateur, API, webhook et monitoring concernés par le changement, ainsi que la requête canari dédiée si elle reste disponible.
4. Confirmez dans les événements de sécurité et la télémétrie d'origine que le trafic légitime se rétablit et que le rollback n'a pas ouvert un contournement large non voulu.
5. Si une exception de managed rule a causé le problème, restaurez l'ordre et le périmètre antérieurs de l'exception avant d'effectuer un autre changement.

Ne résolvez pas une interruption en désactivant globalement toutes les managed rules ou en créant un skip non restreint, sauf si le responsable d'incident accepte explicitement ce risque temporaire. Si une mitigation d'urgence large est inévitable, limitez-la dans le temps, consignez l'exposition, exigez un second relecteur et créez une tâche de suppression suivie avant de clore l'incident.

Pièges fréquents et réserves de précision

• Supposer que le WAF couvre le trafic direct vers l'origine : seules les requêtes proxifiées sont évaluées ; appliquez séparément le contrôle d'accès réseau de l'origine.
• S'appuyer sur les challenges navigateur pour les API : les clients non navigateurs ne peuvent généralement pas terminer un flux interactif ; testez donc leur contrat d'échec explicite.
• Ignorer l'ordre des règles : une Custom Rule terminale antérieure peut empêcher les Managed Rules d'inspecter une requête, et une exception mal ordonnée peut ne pas ignorer la managed rule voulue.
• Créer des exceptions larges permanentes : ciblez et faites expirer chaque contournement ; validez-le contre le trafic d'attaque comme contre l'intégration légitime.
• Traiter les événements échantillonnés comme des logs complets : utilisez-les pour l'investigation, mais préservez la télémétrie indépendante nécessaire à l'audit et à l'analyse d'incident.
• Exposer des logs de sécurité bruts : des informations de requête sensibles peuvent passer dans les tickets, exports et chats si la rédaction et les contrôles d'accès ne sont pas délibérés.
• Copier des hypothèses fixes de plan ou d'UI : les fonctionnalités, actions, rétentions, limites, managed rules et la navigation dashboard de Cloudflare peuvent varier selon le plan et évoluer. Vérifiez la documentation liée actuelle et testez la zone réelle avant le déploiement.

Références faisant autorité

• Cloudflare WAF overview
• Cloudflare Managed Rules
• Cloudflare Custom Rules
• Cloudflare Security Events
• Cloudflare managed-rule troubleshooting
• Cloudflare WAF feature interoperability
• Cloudflare Rules language