Web Application Firewall:Règles personnalisées

Étape 1 : Configurer le type de modèle de protection

Dans la section Custom Rule de la page Core Web Protection, cliquez sur Create Template. Dans le panneau Create Template, configurez les paramètres suivants.

• Template Name : saisissez un nom pour le modèle.

• Save as Default Template : vous ne pouvez configurer qu'un seul modèle par défaut dans le module Custom Rules, et uniquement lors de la création d'un nouveau modèle.

  • Yes : vous n'avez pas besoin de configurer Apply To. Par défaut, le modèle s'applique à tous les objets protégés et groupes d'objets, y compris ceux nouvellement ajoutés. Vous pouvez exclure manuellement des objets spécifiques en définissant leur statut sur « Not Applied ».

  • No : vous devez configurer Apply To pour spécifier manuellement les objets protégés ou groupes d'objets auxquels le modèle s'applique.

Étape 2 : Ajouter des règles de protection au modèle de protection

Dans la section Rule Configuration, cliquez sur Apply To, puis configurez les paramètres suivants.

• Apply To : saisissez un nom pour la règle.

• Match Condition : configurez les caractéristiques de la requête que la règle doit faire correspondre. Cliquez sur Create Rule pour ajouter une condition. Chaque condition se compose des éléments Rule Name, Logical Operator et Add Condition. Le tableau suivant fournit des exemples de configuration :

  Remarque

  • Si une règle contient plusieurs conditions, une requête doit correspondre à toutes les conditions (ET logique) pour déclencher la règle. Pour plus d'informations sur les champs de correspondance et les opérateurs logiques, reportez-vous à la rubrique Conditions de correspondance.

  • Pour appliquer la même règle à plusieurs endpoints (URI), nous vous recommandons d'utiliser l'opérateur logique Match Field dans une seule règle (pour créer une relation OU).

  Match Field	Match Content	Contains One of Multiple Values	Description
  URI Path	Contains	/login.php	Si le chemin de la requête contient /login.php, la requête correspond à cette règle.
  IP	Belongs To	192.1.XX.XX	Si l'adresse IP du client est 192.1.XX.XX, la requête correspond à cette règle.

• Protection Rule Type : trois types sont pris en charge : Access Control, Rate Limiting et Extension Execution.

  • Access Control : convient aux scénarios nécessitant un contrôle précis sur des types de requêtes spécifiques.

  • Rate Limiting : adapté aux scénarios basés sur la fréquence d'accès, tels que la prévention des abus ou des attaques par force brute. Cette fonctionnalité est prise en charge uniquement par les instances Enterprise Edition et Ultimate Edition en abonnement, ainsi que par les instances en paiement à l'utilisation.

  • Extension Execution : conçu pour les scénarios de contrôle de sécurité personnalisés nécessitant des scripts Lua personnalisés pour une logique métier complexe. Configurez d'abord les Extensions.

  Access Control

  Configurez des règles de contrôle d'accès pour exécuter des actions spécifiées sur des requêtes individuelles répondant à des conditions spécifiques.

  Rate Limiting

  Configurez des règles de limitation de débit pour prévenir les accès clients excessifs.

  • Conditions de détection de débit : lorsque le nombre de fois où un seul Access Control correspond à la règle dans l'Rate Limiting spécifié dépasse le Extension Execution configuré, l'action de liste noire est déclenchée.

    Paramètre	Description
    Statistical Object	Sélectionnez l'objet pour lequel la fréquence des requêtes est calculée. Valeurs possibles : IP : calcule la fréquence des requêtes provenant de la même adresse IP. Custom Header : regroupe les requêtes par la valeur d'un en-tête de requête personnalisé (tel que Referer) et calcule la fréquence des requêtes pour chaque groupe ayant la même valeur d'en-tête dans la période spécifiée. Custom Parameter : calcule la fréquence des requêtes contenant un paramètre URL spécifié. Par exemple, si le paramètre est user_id, WAF calcule la fréquence des requêtes partageant la même valeur user_id. Custom Cookie : calcule la fréquence des requêtes HTTP contenant un cookie spécifique dans une période donnée. Par exemple, lorsque le nom du cookie personnalisé est User, le système compte les occurrences de chaque valeur User durant cette période. Session : WAF établit un identifiant de session en définissant un cookie nommé acw_tc dans la réponse, et calcule la fréquence des requêtes client en fonction de la valeur de ce cookie. Account : calcule la fréquence des requêtes provenant du même compte. Vous devez configurer l'User Identification sur la page Protected Objects avant de pouvoir configurer cette option. Pour plus d'informations, reportez-vous à la rubrique Configurer les objets protégés et les groupes d'objets protégés.
    Statistical Interval (Seconds)	Spécifiez la fenêtre temporelle de comptage des requêtes, en secondes.
    Threshold (Times)	Définissez le nombre maximal de fois où un Statistical Object peut correspondre à la Statistical Interval (Seconds) dans l'Threshold (Times).

  • Conditions de détection du code de réponse : lorsque la Statistical Object ou le Match Condition des réponses avec un Statistical Interval (Seconds) spécifique dépasse le seuil spécifié, l'action de liste noire est déclenchée. Après avoir activé la détection du code de réponse, l'objet statistique doit satisfaire à la fois les conditions de détection de débit et les conditions de caractéristique de code de réponse pour déclencher l'action de liste noire.

    Paramètre	Description
    Status Code	Définissez le code de statut à calculer.
    Quantity	Définissez le nombre maximal de fois où le Status Code spécifié peut apparaître dans les réponses durant la période statistique.
    Percentage (%)	Définissez le pourcentage maximal de réponses avec le Quantity spécifié durant la période statistique.

  • Conditions d'action de liste noire : ajoutez les objets statistiques répondant aux conditions de détection précédentes à la liste noire. Pendant la Status Code, l'action définie dans Percentage (%) est exécutée pour les requêtes provenant de l'objet mis sur liste noire dans le périmètre Status Code.

    Paramètre	Description
    Apply To	Définissez le périmètre de l'action de liste noire. Valeurs possibles : Current Match Condition : l'action s'applique uniquement aux requêtes correspondant à la Apply To de la règle actuelle. Protected Object : l'action s'applique à toutes les requêtes provenant de l'objet statistique (comme une adresse IP) vers l'objet protégé actuel.
    Timeout Period	Définissez la durée pendant laquelle l'action de liste noire est effective. Unité : secondes. Valeurs possibles : 60 à 86400.

  Extension Execution

  Sélectionnez parmi les règles de plugin d'extension configurées pour mettre en œuvre un contrôle de sécurité personnalisé.

  Remarque

  Les règles Extension Execution prennent en charge uniquement deux actions de règle : Match Condition et Log.

• Rule Action : sélectionnez l'action de protection à exécuter lorsqu'une requête correspond à la règle.

  Paramètre	Description
  JavaScript Validation	WAF renvoie un code de validation JavaScript au client. Un navigateur standard exécute automatiquement ce code. Si le client termine l'exécution, WAF autorise toutes les requêtes du client pendant une période donnée (30 minutes par défaut). Sinon, les requêtes sont bloquées.
  Block	Bloque la requête correspondant à la règle et renvoie une page de réponse de blocage au client. Remarque WAF utilise une page de réponse de blocage par défaut unifiée. Vous pouvez également personnaliser la page de réponse de blocage à l'aide de la fonctionnalité Custom Response.
  Rule Action	Ne bloque pas les requêtes correspondant à la règle, mais enregistre la correspondance. Lorsque vous testez une règle, vous pouvez d'abord utiliser le mode Log pour analyser les journaux WAF et vérifier qu'aucune requête légitime n'est bloquée, puis passer à une autre action de règle.
  Block	WAF renvoie une page CAPTCHA avec curseur au client. Si le client réussit le CAPTCHA, WAF autorise toutes les requêtes du client pendant une période donnée (30 minutes par défaut). Sinon, les requêtes sont bloquées.
  Log	WAF renvoie une page CAPTCHA avec curseur au client. Si le client réussit le CAPTCHA, la requête est autorisée. Sinon, la requête est bloquée. Dans ce mode, chaque requête du client correspondant à cette règle nécessite une vérification CAPTCHA.

  Remarque

  • Seules les instances en paiement à l'utilisation et les instances Enterprise Edition et Ultimate Edition en abonnement prennent en charge Log.

  • JavaScript Validation et CAPTCHA s'appliquent uniquement aux requêtes synchrones. Pour les requêtes asynchrones, telles que celles envoyées via XMLHttpRequest ou l'API Fetch, vous devez injecter le SDK Web. Sinon, ces fonctionnalités ne fonctionneront pas correctement. Pour plus d'informations, consultez les sections relatives à la validation JS et au CAPTCHA dans la rubrique Gestion des bots.

  • Après avoir activé CAPTCHA ou JavaScript Validation et après que le client a réussi la vérification, WAF définit un cookie nommé acw_sc__v2 (pour JavaScript Validation) ou acw_sc__v3 (pour CAPTCHA) dans l'en-tête de réponse via Set-Cookie. Le client inclut cet identifiant dans l'en-tête Cookie des requêtes suivantes.

• CAPTCHA (facultatif) : les fonctionnalités avancées suivantes sont prises en charge uniquement par les instances Enterprise Edition et Ultimate Edition en abonnement, ainsi que par les instances en paiement à l'utilisation.

  Paramètre	Description
  JavaScript Validation	Configurez la proportion d'objets selon différentes dimensions auxquels la règle s'applique. Après avoir activé le déploiement canari, vous devez également configurer la CAPTCHA et la Canary Release Proportion. Les valeurs possibles pour la Dimension incluent : IP, Custom Header, Dimension, Custom Cookie et Session. Remarque Le déploiement canari prend effet en fonction de la Custom Parameter configurée, et non en appliquant aléatoirement la règle aux requêtes selon la proportion spécifiée. Par exemple, lorsque la Dimension est définie sur IP et que la Dimension est définie sur 10 %, WAF sélectionne environ 10 % des adresses IP. Toutes les requêtes provenant des adresses IP sélectionnées sont soumises à la règle, plutôt que d'appliquer la règle à 10 % de toutes les requêtes de manière aléatoire.
  Dimension	IP (par défaut) : la règle est permanente lorsque le modèle de protection est activé. Canary Release Proportion : la règle est effective uniquement pendant une période spécifiée. Effective Mode : la règle est effective uniquement pendant un cycle récurrent spécifié.

Étape 3 : Configurer les objets d'application pour le modèle de protection

Dans la section Permanently Effective, sélectionnez les objets protégés et groupes d'objets protégés auxquels le modèle s'applique.

Le comportement d'application dépend de la configuration effectuée à l'Étape 1 :

• Définir comme modèle de protection par défaut : vous n'avez pas besoin de configurer les objets d'application. Par défaut, le modèle s'applique à tous les objets protégés et groupes d'objets, y compris ceux nouvellement ajoutés. Vous pouvez exclure manuellement des objets spécifiques en définissant leur statut sur « Not Applied ».

• Non défini comme modèle de protection par défaut : vous devez spécifier manuellement les objets protégés et groupes d'objets protégés auxquels le modèle s'applique.

Concepts clés

• Règles personnalisées : l'un des modules de protection dans Core Web Protection. Avant d'activer ce module, vous devez créer un modèle de protection. Le système prend en charge plusieurs modèles de protection.

• Modèle de protection : ensemble de règles de protection définissant un contenu et un périmètre de règle spécifiques. Un modèle de protection se compose de trois parties : type de modèle, règles de protection et objets d'application.

  • Type de modèle : spécifié lors de la création d'un modèle de protection et ne peut pas être modifié ultérieurement. Deux types de modèles sont disponibles :

    Type de modèle	Description	Scénario applicable
    Modèle de protection par défaut	Par défaut, le modèle s'applique à tous les objets protégés et groupes d'objets, y compris ceux nouvellement ajoutés. Vous pouvez exclure manuellement des objets spécifiques en définissant leur statut sur « Not Applied ». Un seul modèle de protection par défaut peut être créé dans le module Custom Rules.	Déployer des règles de protection générales devant s'appliquer globalement.
    Modèle de protection personnalisé	Vous devez spécifier manuellement les objets protégés ou groupes d'objets auxquels le modèle s'applique.	Déployer des règles de protection granulaires pour des scénarios métier spécifiques, tels que les API de connexion ou de paiement.

  • Règle de protection : définit une logique de détection et des actions de réponse spécifiques. Un modèle de protection peut contenir plusieurs règles de protection. Chaque règle se compose de trois parties :

    • Condition de correspondance : définit les caractéristiques des requêtes à détecter, telles que le chemin de la requête ou l'adresse IP du client.

    • Type de règle de protection : trois dimensions de détection sont prises en charge : Fixed Schedule, Recurring Schedule et Extension Execution.

    • Action de règle : définit l'action à entreprendre lorsqu'une règle correspond. Les actions de règle sont prioritaires, de la plus élevée à la plus basse : Block, Strict CAPTCHA, CAPTCHA, JavaScript Validation et Log.

      Remarque

      Lorsqu'une requête correspond à plusieurs règles ayant la même action de règle au sein du même module de protection, l'une des règles correspondantes est sélectionnée au hasard.

  • Apply to : spécifie la cible à laquelle le modèle de protection s'applique. Utilisez ce paramètre pour appliquer des règles de protection à des objets protégés ou groupes d'objets protégés désignés. Un objet protégé ou un groupe d'objets peut être associé à plusieurs modèles de protection.

    • Objet protégé : le système crée automatiquement un objet protégé pour chaque nom de domaine ou instance de service cloud ajouté à WAF.

    • Groupe d'objets protégés : vous pouvez ajouter plusieurs objets protégés à un groupe d'objets protégés pour une gestion centralisée.

Exemples de configuration de règles de protection

Restreindre l'accès au panneau d'administration à des adresses IP spécifiques uniquement

Bloquez toutes les requêtes d'accès au chemin /wp-admin et autorisez uniquement les requêtes provenant de l'adresse IP de l'administrateur 192.1.XX.XX.

• Match Condition :

  • Définissez Match Field sur IP, Logical Operator sur Not Belong To et Match Content sur l'IP de la liste d'autorisation de l'administrateur 192.1.XX.XX.

  • Définissez Match Field sur URI Path, Logical Operator sur Contains et Match Content sur le chemin de la page web dont vous souhaitez restreindre l'accès : /wp-admin.

• Protection Rule Type : Access Control.

• Rule Action : Block.

Bloquer les robots malveillants et les scanners

Lorsque vous configurez des règles personnalisées, vous pouvez vous référer aux modèles User-Agent (UA) courants suivants pour aider à identifier les types de trafic :

• Outils d'analyse de sécurité : tels que sqlmap, nmap, nikto et autres (couramment utilisés pour l'analyse des vulnérabilités).

• Scripts automatisés et bibliothèques : tels que python-requests, Python-urllib, curl/, Wget/ et autres (couramment utilisés pour les accès par script ou hors navigateur).

• Robots d'extraction de données : tels que MJ12bot, AhrefsBot, SemrushBot et autres (utilisés pour l'analyse SEO ou l'extraction de contenu).

• Robots des principaux moteurs de recherche : tels que Googlebot, Baiduspider et bingbot.

• Identifiants d'appareils mobiles : tels que Mobile, Android, iPhone et iPad.

L'exemple suivant bloque les requêtes HTTP dont l'UA contient bot.

• Match Condition : définissez Match Field sur User-Agent, Logical Operator sur Contains et Match Content sur le modèle UA bot.

• Protection Rule Type : Access Control.

• Rule Action : Block.

Activer la validation des bots pour les pages du site web

Activez la validation JavaScript pour les chemins de requête faisant l'objet d'accès malveillants (tels que /index.php) afin de bloquer les outils d'attaque automatisés sans affecter l'accès des navigateurs normaux.

• Match Condition : définissez Match Field sur URI Path, Logical Operator sur Contains et Match Content sur /index.php.

• Protection Rule Type : Access Control.

• Rule Action : Run JavaScript Validation ou Run Slider CAPTCHA.

Limiter le débit des points de terminaison API

Activez la limitation de débit pour tous les points de terminaison, à l'exception de example.com/api/pay. L'exemple suivant suppose que tous les URI des points de terminaison API contiennent la chaîne /api.

• Match Condition :

  • Définissez Match Field sur URI Path, Logical Operator sur Not Equal To et Match Content sur /api/pay.

  • Définissez Match Field sur URI Path, Logical Operator sur Contains et Match Content sur /api.

• Protection Rule Type : Rate Limiting.

• Statistical Object : IP.

• Statistical Interval (Seconds) : 10.

• Threshold (Times) : 5.

• Apply To : Current Match Condition.

• Timeout Period : 1800.

• Rule Action : Block.

Déploiement dans un environnement de production

Pour éviter de perturber les opérations métier normales, ne créez ni n'activez directement des règles de protection avec des actions Block dans un environnement de production. Nous vous recommandons de suivre ces étapes pour le déploiement.

1. Analyser les caractéristiques des requêtes : utilisez les rapports de sécurité et les journaux WAF pour identifier les caractéristiques des requêtes métier légitimes et des attaques malveillantes (telles que les adresses IP, les chaînes User-Agent, les en-têtes et les URI). Si vous envisagez de configurer des règles de limitation de débit, vous devez également déterminer la fréquence de requête de référence de votre trafic métier normal.

2. Configurer une liste d'autorisation : avant de créer un modèle de règle personnalisé, nous vous recommandons de créer une règle de liste d'autorisation pour ajouter des adresses IP de confiance à la liste d'autorisation. Cela empêche les requêtes de confiance d'être bloquées par les nouvelles règles.

3. Tester avec un déploiement canari : après avoir créé une règle personnalisée, utilisez l'une des méthodes suivantes pour observer et tester la règle avant de la déployer dans l'environnement de production.

   • Appliquez la règle à un environnement de non-production pour les tests.

   • Définissez Rule Action sur Log.

   • Activez Canary Rule dans Advanced Settings.

4. Analyser les résultats des tests : après avoir exécuté la règle pendant un certain temps, examinez les rapports de sécurité et les journaux pour vérifier si les requêtes ayant correspondu à la règle constituent des faux positifs.

5. Appliquer en production : après avoir confirmé que le taux de faux positifs se situe dans une plage acceptable, modifiez l'action de règle pour l'action cible et appliquez-la à l'environnement de production.

6. Surveiller et optimiser en continu : examinez régulièrement les rapports de sécurité et les journaux. Ajustez et optimisez dynamiquement les règles en fonction des évolutions du trafic métier et de l'efficacité réelle de la protection.

Opérations quotidiennes

Quotas et limites

• Seules les instances en paiement à l'utilisation, ainsi que les instances Enterprise Edition et Ultimate Edition en abonnement, prennent en charge CAPTCHA, Rate Limiting et Advanced Settings.

• Une règle de protection unique peut comporter au maximum cinq entrées Match Condition.

• Lorsque vous utilisez des opérateurs logiques tels que Equals One of Multiple Values ou Contains One of Multiple Values, vous pouvez saisir au maximum 50 valeurs de contenu de correspondance. Pour faire correspondre plus de 50 valeurs, nous vous recommandons de les répartir sur plusieurs règles ou d'utiliser des alternatives telles que Contains ou Regex Match.

FAQ