Cloudflare Docs
Support
Cloudflare Docs
Support
GitHub icon
Visit Support on GitHub
Set theme to dark (⇧+D)

Comprendre les règles gérés du pare-feu applicatif web (WAF) – Centre d’assistance Cloudflare

Les règles gérées du pare-feu applicatif web (WAF) surveillent les requêtes web adressées à votre domaine et filtrent le trafic indésirable en fonction des ensembles de règles que vous définissez.

​​ Aperçu

Les règles gérées, fonction du pare-feu applicatif web (WAF) de Cloudflare, identifient et suppriment toute activité suspecte associée aux requêtes HTTP GET et POST.

Voici des exemples de contenus malveillants identifiés par les règles gérées :

  • Mots-clés courants utilisés dans les spams (XX, Rolex, Viagra, etc.),
  • Attaques Cross-Site Scripting (XSS) et
  • Injections SQL (SQLi).

Les règles gérées sont disponibles pour les offres Pro, Business et Enterprise pour tous les sous-domaines traités en proxy par Cloudflare. Vous pouvez contrôler les paramètres des règles gérées sous Security (Sécurité) > WAF > Managed rules (Règles gérées). Les règles gérées contiennent trois packages : 

  • Cloudflare Managed Ruleset 
  • Package : OWASP ModSecurity Core Rule Set
  • Customer Requested Rules 

Vous pouvez consulter les menaces bloquées dans le journal d’activité de Firewall Analytics, accessible via Security (Sécurité) > Overview (Vue d’ensemble).

​​ Considérations importantes

  • Les règles gérées ajoutent une latence limitée. 
  • La mise à jour dans le monde entier des modifications apportées au règles gérées du pare-feu WAF demande environ 30 secondes.
  • Cloudflare utilise des règles propriétaires pour filtrer le trafic.
  • Les serveurs WebSocket établis n’activent pas les règles gérées pour les requêtes suivantes.
  • Les règles gérées analysent les réponses JSON pour identifier les vulnérabilités ciblées des API. L’analyse des charges utiles JSON est limitée à 128 Ko.
  • Les règles gérées atténuent les techniques de remplissage. Voici nos recommandations :
    1. Activez la règle 100048. Cette règle protège désormais des attaques de type remplissage mais n’est pas déployée par défaut, car elle est à l’origine de faux positifs dans les environnements des clients. Il est toutefois important que les clients ajustent la configuration de leurs règles gérées. Cloudflare travaille à l’élaboration d’une meilleure solution sur le long terme.
    2. Créez une règle de pare-feu à l’aide d’Expression Editor en fonction de la nécessité de vérifier les en-têtes et/ou les corps pour bloquer des charges utiles plus importantes (> 128 Ko). Veillez à tester votre règle de pare-feu en mode Log (Journal) en premier lieu, car des faux positifs pourraient être générés.
      • http.request.body.truncated
      • http.request.headers.truncated
  • Cloudflare ne désactive pas certaines règles gérées spécifiques (WP0025B, 100043A et 100030, par exemple) même si l’option Managed rules (Règles gérées) est sur Off (Désactivé) dans le tableau de bord Cloudflare.

​​ Remarque relative aux faux positifs et aux faux négatifs

Par défaut, les règles gérées du pare-feu WAF sont entièrement gérées depuis le tableau de bord Cloudflare et sont compatibles avec la plupart des sites web et applications web. Cependant, des faux positifs et faux négatifs peuvent se produire, en raison de l’immensité d’Internet :

  • Faux positifs : les requêtes légitimes sont détectées et filtrées comme étant malveillantes.
  • Faux négatifs : les requêtes malveillantes ne sont pas filtrées.

​​ Résoudre les problèmes de faux positifs des règles gérées du pare-feu WAF

La définition des contenus suspects est subjective pour chaque site web.  Par exemple, la publication de code PHP sur votre site web est suspecte, sauf si votre site web enseigne le codage et invite les visiteurs à soumettre du code PHP.  Par conséquent, un site web comme celui-ci doit désactiver les règles gérées associées qui interfèrent avec le fonctionnement normal.

Pour tester les faux positifs, configurez les règles gérées du pare-feu WAF en mode Simulate (Simuler). Elles enregistreront alors la réponse à d’éventuelles attaques, sans vérification ni blocage. Utilisez également le journal d’activité de Firewall Analytics pour déterminer les règles gérées ayant généré les faux positifs.

En cas de faux positif dû à l’ ancien pare-feu WAF, plusieurs approches s’offrent à vous pour résoudre le problème :

  • Ajouter les adresses IP du client à la liste d’autorisation d’ IP Access Rules : Si le navigateur ou le client consulte le site depuis les mêmes adresses IP, il est recommandé de l’autoriser.
  • Désactiver la ou les règles gérées : Cette opération empêche le blocage ou le test des faux positifs, mais réduit la sécurisation générale du site. Une requête bloquée par l’ID de règle 981176 fait référence aux règles de l’OWASP. Réduisez la sensibilité OWASP pour résoudre le problème.
  • Contourner les règles du pare-feu WAF en établissant une règle de pare-feu : Créez une règle de pare-feu avec l’action bypass (contourner) pour désactiver des règles gérées du pare-feu WAF pour une combinaison spécifique de paramètres. Par exemple, contournez les règles gérées pour une URL spécifique et une adresse IP ou un agent utilisateur spécifique.
  • (Déconseillé) Désactivez les règles gérées du pare-feu WAF pour le trafic vers une URL : Réduit la sécurité sur le point de terminaison spécifique de l’URL.  Configuration via Page Rules.

En cas de faux positif dû au nouveau pare-feu WAF, plusieurs approches s’offrent à vous pour résoudre le problème :

  1. Ajouter une exception WAF : Vous pouvez définir des exceptions WAF dans le tableau de bord Cloudflare ou à l’aide de l’API Rulesets (Ensembles de règles).
  2. Désactiver la ou les règles gérées : Cette opération empêche le blocage ou le test des faux positifs, mais réduit la sécurisation générale du site. Une requête bloquée par l’ID de règle 949110 fait référence aux nouvelles règles de l’OWASP. Réduisez la sensibilité OWASP pour résoudre le problème.

Remarque : si vous contactez le support de Cloudflare pour vérifier si une règle gérée du pare-feu WAF se déclenche comme prévu, fournissez un fichier HAR capturé lors de l’envoi de la requête concernée.

Voici d’autres directives :

  • Si une règle spécifique provoque des faux positifs, définissez le paramètre Mode de la règle sur Disable (Désactiver), plutôt que de définir l’ensemble de la règle Group (Groupe) sur Off.
  • Pour les faux positifs avec le contenu administrateur de votre site web, créez une règle Page Rule pour l’option Disable Security (Désactiver la sécurité) pour la section admin des ressources de votre site, c’est-à-dire votresite.com/admin.

​​ Résoudre les problèmes de faux négatifs des règles gérées du pare-feu WAF

Pour identifier les faux négatifs, consultez les journaux HTTP de votre serveur web d’origine. Pour réduire les faux négatifs, utilisez la liste de contrôle suivante :

  • Les règles gérées du pare-feu WAF sont-elles activées sous Security (Sécurité) > WAF > Managed rules (Règles gérées) ?
  • Les règles gérées du pare-feu WAF sont-elles désactivées via Page Rules ?
  • Toutes les règles gérées ne sont pas activées par défaut, c’est pourquoi nous vous invitons à passer en revue les actions par défaut de chaque règle gérée.
    • Par exemple, Cloudflare autorise par défaut les requêtes avec des agents utilisateurs vides. Pour bloquer les requêtes avec un agent utilisateur vide, configurez le Mode de la règle sur Block (Bloquer).
    • Autre exemple : si vous cherchez à bloquer des attaques par injection SQL non atténuées, assurez-vous que les règles SQLi appropriées sont activées et attribuez la valeur Block (Bloquer) sous le groupe Cloudflare Specials.
  • Les enregistrements DNS qui servent le trafic HTTP sont-ils traités en proxy par Cloudflare ?
  • Une règle de pare-feu contourne-t-elle des règles gérées ? 
  • Un pays, un NSA, une plage d’adresses IP ou une adresse IP autorisés dans les règles d’accès IP ou les règles de pare-feu correspondent-ils au trafic de l’attaque ?
  • Le trafic malveillant est-il dirigé vers les adresses IP de votre serveur d’origine pour contourner la protection Cloudflare ? Bloquez tout le trafic à l’exception du trafic provenant des adresses IP de Cloudflare sur votre serveur web d’origine.

​​ Cloudflare Managed Ruleset

La suite de règles Cloudflare Managed Ruleset contient des règles de sécurité écrites et sélectionnées par Cloudflare. Cliquez sur le nom d’un ensemble de règles sous Group (Groupe) pour afficher les descriptions des règles.

Cloudflare Specials est un groupe qui offre un niveau fondamental de sécurité du pare-feu contre les attaques courantes.

 

Lors de l’affichage d’un ensemble de règles, Cloudflare présente les actions par défaut pour chaque règle répertoriée sous Default mode (Mode par défaut). Le Mode disponibles pour les règles individuelles dans un ensemble de règles Cloudflare Managed Ruleset particulier sont :

  • Default (Par défaut) – prend l’action par défaut indiquée sous Default mode (Mode par défaut) lors de l’affichage d’une règle spécifique.
  • Disable (Désactiver) – désactive la règle spécifique dans le groupe.
  • Block (Bloquer) – la requête est ignorée.
  • Legacy CAPTCHA (CAPTCHA hérité) - le visiteur doit résoudre un défi CAPTCHA.
  • Simulate (Simuler) – la demande est autorisée par l’intermédiaire du fichier journal d’activité.

Le journal des modifications du pare-feu WAF de Cloudflare permet aux clients de suivre les modifications apportées à l’ensemble de règles Cloudflare Managed Ruleset.

​​ Package : OWASP ModSecurity Core Rule Set

​​ Comprendre le package OWASP de Cloudflare

Package: OWASP ModSecurity Core Rule Set attribue un score à chaque requête en fonction du nombre de règles OWASP déclenchées. Certaines règles OWASP possèdent un score de sensibilité plus élevé que d’autres. Après l’évaluation d’une requête par OWASP, Cloudflare compare le score final à la valeur Sensitivity (Sensibilité) configurée pour le domaine. Si le score est supérieur à la valeur Sensitivity(Sensibilité), la requête est exécutée en fonction de l’Action configurée dans Package: OWASP ModSecurity Core Rule Set :

  • Block (Bloquer) – la requête est ignorée.
  • Challenge (Défi) – le visiteur doit résoudre un défi CAPTCHA.
  • Simulate (Simuler) – la demande est autorisée par l’intermédiaire du fichier journal d’activité.

Le score de sensibilité requis pour déclencher le pare-feu WAF pour une valeur Sensitivity (Sensibilité) spécifique est le suivant :

  • Low (Bas) – 60 et plus
  • Medium (Moyen) – 40 et plus
  • High (Élevé) – 25 et plus

Pour les requêtes Ajax, les scores suivants sont appliqués à la place :

  • Low (Bas) – 120 et plus
  • Medium (Moyen) – 80 et plus
  • High (Élevé) – 65 et plus

Consultez le fichier journal d’activité pour connaître le score final ainsi que les individuelles règles déclenchées.

​​ Contrôler le package OWASP de Cloudflare

Package: OWASP ModSecurity Core Rule Set contient plusieurs règles issues du projet OWASP. Cloudflare ne rédige pas et ne sélectionne pas les règles OWASP. Cliquez sur le nom d’un ensemble de règles sous Group (Groupe) pour afficher les descriptions des règles. Contrairement à l’ensemble de règles Cloudflare Managed Ruleset, les règles OWASP spécifiques sont définies sur On ou Off.

Pour gérer les seuils OWASP, définissez le paramètre Sensibilité sur Faible, Moyen ou Élevé sous Package : ensemble de règles principal ModSecurity de l’OWASP. Le réglage du paramètre Sensibilité sur Désactivée désactivera l’intégralité du package OWASP, notamment l’ensemble de ses règles. La définition appropriée du paramètre Sensibilité dépend de votre secteur et de votre activité. Par exemple, le réglage Faible convient particulièrement aux contextes suivants :

  • Certains secteurs d’activité plus susceptibles de déclencher le pare-feu WAF et
  • Les chargements de fichiers volumineux.

Dans un premier temps, Cloudflare recommande de définir la valeur Sensitivity (Sensibilité) sur Low (Bas) et d’examiner les faux positifs avant d’augmenter davantage la valeur Sensitivity (Sensibilité).

​​ Ressources associées