Le pare-feu d’applications web (WAF, Web Application Firewall) de Cloudflare surveille les requêtes web adressées à votre domaine et filtre le trafic indésirable en fonction des ensembles de règles que vous définissez.
Aperçu
Cloudflare Web Application Firewall (WAF) identifie et supprimé toute activité suspecte associée aux requêtes HTTP GET et POST.
Voici des exemples de contenus malveillants identifiés par le pare-feu WAF :
- Mots-clés courants utilisés dans les spams (XX, Rolex, Viagra, etc.),
- Attaques Cross-Site Scripting (XSS) et
- Injections SQL (SQLi).
Le pare-feu WAF est disponible pour les offres Pro, Business et Enterprise pour tous les sous-domaines traités en proxy par Cloudflare. Vous pouvez configurer les paramètres du pare-feu WAF via l’application Cloudflare Firewall, sous l’onglet Managed Rules. Le pare-feu Cloudflare WAF contient trois packages :
- Cloudflare Managed Ruleset
- Package : OWASP ModSecurity Core Rule Set
- Customer Requested Rules
Vous pouvez consulter les menaces bloquées dans le fichier journal de Firewall Analytics, accessible depuis l’application Cloudflare Firewall, sur l’onglet Overview (Aperçu).
Considérations importantes
- Le pare-feu Cloudflare WAF ajoute une latence limitée.
- La mise à jour dans le monde entier des modifications apportées au 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 le pare-feu WAF pour les requêtes suivantes.
- Cloudflare WAF analyse les réponses JSON pour identifier les vulnérabilités ciblées des API. Le pare-feu WAF limite l’analyse des charges utiles JSON à 128 Ko.
- Il existe un petit nombre de règles du pare-feu WAF que Cloudflare ne désactive pas, même si Web Application Firewall est entièrement désactivé, à l’image des règles avec les ID WP0025B, 100043A, et 100030.
Une remarque concernant les faux positifs et les faux négatifs du pare-feu WAF
Par défaut, Cloudflare Web Application Firewall (WAF) est entièrement géré depuis le tableau de bord Cloudflare et est compatible 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ésolution des faux positifs 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 WAF associées qui interfèrent avec le fonctionnement normal.
Pour tester les faux positifs, configurez le pare-feu WAF en mode Simulate (Simuler). Il enregistrera alors la réponse à d’éventuelles attaques, sans défi, ni vérification. Utilisez également le fichier journal d’activité de Firewall Analytics pour déterminer les règles du pare-feu WAF ayant généré les faux positifs.
En cas de faux positif, 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 du pare-feu WAF :
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 WAF 981176 fait référence aux règles de l'OWASP. Réduisez la sensibilité OWASP pour résoudre le problème.
- Une requête bloquée par l'ID de règle WAF 949110 fait référence aux règles de l'OWASP. Réduisez la sensibilité OWASP pour résoudre le problème.
- Contourner le pare-feu WAF en établissant une règle Firewall Rule : Créez une règle Firewall Rule avec l’action bypass pour désactiver le pare-feu WAF pour une combinaison spécifique de paramètres. Par exemple, contournez le pare-feu WAF pour une URL spécifique et une adresse IP ou un agent utilisateur spécifique.
- (déconseillé) Désactivez le 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.
Remarque : si vous contactez le support de Cloudflare pour vérifier si une règle de 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ésolution des faux négatifs 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 :
- Le paramètre Web Application Firewall est-il configuré sur On dans l’application Firewall, sous Managed Rules ?
- Le paramètre Web Application Firewall est-il configuré sur Off via Managed RulesPage Rules ?
- Toutes les règles de pare-feu WAF 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 de pare-feu WAF. Par exemple, Cloudflare autorise par défaut les requêtes avec des agents utilisateurs vides. Pour bloquer les demandes avec un agent utilisateur vide, configurez la règle WAF Mode en Block (Bloquer).
- Les enregistrements DNS qui servent le trafic HTTP sont-ils traités en proxy par Cloudflare ?
- Une règle Firewall Rule passe-t-elle outre les règles Managed Rules de Cloudflare ?
- Un pays, un ASN, une plage d’adresses IP ou une adresse IP autorisée dans IP Access Rules ou Firewall Rules correspond-elle 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 WAF 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.
- 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 fichier 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é) du pare-feu WAF sur Low (Bas) et d’examiner les faux positifs avant d’augmenter davantage la valeur Sensitivity (Sensibilité).