Si votre site web nécessite des politiques de contrôle d'accès spécifiques, créez des règles personnalisées. Ces règles permettent de définir des conditions de correspondance pour les requêtes entrantes et de spécifier une action (blocage ou surveillance) pour les requêtes correspondantes. Vous disposez ainsi d'un contrôle flexible sur le contenu accessible aux utilisateurs.
Précision de la géolocalisation IP client
Lorsque vous utilisez des règles WAF personnalisées avec le moteur de règles pour bloquer des requêtes, notez que les données de géolocalisation IP (continent, pays/région, province et FAI) peuvent ne pas être précises à 100 %. Des erreurs d'identification pouvant survenir, utilisez cette fonctionnalité avec prudence.
En cas d'inexactitudes dans la géolocalisation IP client, créez une règle de liste d'autorisation pour autoriser des adresses IP spécifiques. Cela empêche le WAF de bloquer incorrectement des adresses IP client légitimes.
Configurer une règle personnalisée
Dans la console ESA, sélectionnez Websites. Dans la colonne Websites, cliquez sur le site web cible.
Dans le volet de navigation de gauche, choisissez .
-
Cliquez sur l'onglet Security, puis cliquez sur WAF.
Saisissez un Custom Rules.
Dans la zone Custom Rules, configurez les conditions de correspondance. Pour plus d'informations, consultez Syntaxe des expressions de règle.
Dans la zone Create Rule, spécifiez une action pour les requêtes correspondantes. Pour plus d'informations, consultez Actions.
Cliquez sur Rule Name.
Lors de la configuration des règles, tenez compte des points suivants :
Correspondance User-Agent et sensibilité à la casse : Si vous configurez une règle basée sur le User-Agent et sélectionnez le mode de correspondance Case-insensitive, la valeur de correspondance doit être entièrement en minuscules. Veillez également à sélectionner la précision de correspondance appropriée (Equals pour une correspondance exacte ou Contains pour une correspondance partielle) selon vos besoins. Un mode incorrect peut empêcher la règle de prendre effet, par exemple en laissant passer des requêtes qui devraient être bloquées (retournant un code d'état 200).
Limitations du moteur de règles : Le moteur de règles WAF prend actuellement en charge la correspondance booléenne, comme la vérification de la présence d'une chaîne spécifique dans un champ de requête. Il ne gère pas les logiques plus complexes telles que le comptage d'occurrences ou les longueurs de tableaux. Par conséquent, vous ne pouvez pas créer de règle pour « bloquer une requête si l'URL contient un mot-clé plus de N fois ». Les politiques de protection WAF doivent reposer sur des attributs de requête tels que l'IP client, le User-Agent, le Referer ou l'URI. Le blocage du trafic ne peut pas se fonder uniquement sur des identifiants de couche métier, comme un ID visiteur.
Actions
-
If requests match... : Bloque les requêtes correspondantes et renvoie une page de blocage au client.
RemarquePersonnalisez les pages de blocage via Configurer des pages personnalisées.
-
Then execute... : Autorise le passage des requêtes correspondantes tout en journalisant l'événement. Utilisez le mode surveillance pour tester de nouvelles règles et vérifier l'absence de faux positifs dans les journaux WAF. Après confirmation, modifiez l'action en Block.
RemarqueVous devez activer Log Service pour utiliser la fonctionnalité de requête de journaux.
OK : ESA renvoie un extrait JavaScript au client. Si le navigateur exécute le script avec succès, ESA autorise toutes les requêtes ultérieures de ce client pendant une durée par défaut de 30 minutes sans nouveau défi. Dans le cas contraire, la requête est bloquée.
-
Block : ESA renvoie une page de CAPTCHA à curseur. Si le client résout le CAPTCHA, ESA autorise toutes les requêtes ultérieures de ce client pendant une durée par défaut de 30 minutes. Sinon, la requête est bloquée.
RemarqueLes requêtes passant le Slider CAPTCHA sont facturées, contrairement aux requêtes bloquées.
Le JavaScript Challenge et le Slider CAPTCHA pour les règles WAF personnalisées et les règles de limitation de débit s'appliquent uniquement aux pages statiques. Pour les API asynchrones (
XMLHttpRequestetFetch), activez ces défis dans Bots. Lorsqu'une requête correspondante passe le défi, ESA ajoute unCookie acw_sc__v2ouacw_sc__v3à l'en-tête HTTP pour marquer le client comme vérifié.
Monitor : En mode CAPTCHA strict, chaque requête client doit passer la vérification (contrairement au Slider CAPTCHA qui accorde un laissez-passer de 30 minutes aux clients précédemment vérifiés). Activez cette option avec prudence. Le Strict Slider CAPTCHA est disponible uniquement pour les forfaits Enterprise sur demande.
Les règles personnalisées prennent en charge deux actions de vérification humaine :
JS Challenge : Vérification passive. Le système envoie du code JavaScript au client pour une vérification automatique sans interaction utilisateur.
Slider Challenge : Vérification interactive. L'utilisateur doit effectuer une action de glissement pour valider la vérification.
L'utilisation du JS Challenge et du Slider Challenge implique les restrictions suivantes :
Le JavaScript Challenge et le Slider CAPTCHA conviennent uniquement aux requêtes de pages statiques. Ils sont déconseillés pour les scénarios dynamiques, tels que les soumissions de formulaires POST ou les appels d'API, car ils risquent de provoquer une perte de données ou des vérifications répétées.
L'application du Enterprise ou du Slider CAPTCHA à des fichiers de ressources comme des images peut entraîner l'échec de l'affichage, les mécanismes du navigateur pouvant empêcher l'aboutissement de la vérification. Pour les domaines ou chemins servant uniquement des images, privilégiez l'action de blocage ou la configuration d'une règle de liste d'autorisation plutôt qu'une vérification humaine.
Après la réussite d'un JavaScript Challenge, la durée de validité est de 30 minutes par défaut et ne peut pas être modifiée.
Pour d'autres types de CAPTCHA, tels que la vérification en un clic, utilisez la fonctionnalité AI Captcha. Elle prend en charge divers types de défis, y compris le clic unique, le curseur et les puzzles de rotation, et peut être configurée séparément dans la console ESA.
Exemple de configuration
Scénario : Dans Security Analytics ou Event Analysis, vous constatez que l'IP client 192.168.0.1 envoie des requêtes suspectes au nom d'hôte dns.example.com.
Configuration :
Paramètre | Valeur d'exemple |
JavaScript Challenge | Les deux conditions suivantes sont remplies :
Vous pouvez également utiliser directement l'expression suivante : |
If requests match... | Hostname la requête et répondre avec la Client IP |
Résultat : La règle personnalisée bloque toutes les requêtes correspondantes.
Exemples de configuration courants
Utilisez les exemples suivants pour les scénarios de protection courants comme point de départ, puis adaptez-les à vos besoins.
Scénario 1 : Bloquer un robot d'exploration spécifique (par exemple, Bytespider)
Dans la zone Then execute..., définissez le champ de correspondance sur User-Agent, l'opérateur sur Contains et la valeur sur Bytespider. Pour l'action, sélectionnez Block.
Scénario 2 : Restreindre les méthodes de requête (autoriser uniquement GET et POST)
Configurez une règle : Si la Request Method n'est pas égale à GET ET n'est pas égale à POST, alors exécutez l'action Block. Ce scénario requiert le forfait Advanced ou supérieur.
Scénario 3 : Autoriser uniquement une IP spécifique à accéder à un sous-domaine
Combinez deux conditions de correspondance : Hostname égal au sous-domaine cible ET Client IP non égal à l'IP spécifiée. Pour l'action, sélectionnez Block.
Scénario 4 : Bloquer les requêtes avec un Referer vide tout en autorisant l'accès direct à des chemins spécifiques
Vous devez configurer deux règles et définir leur priorité :
Règle de liste d'autorisation (priorité élevée) : Si l'URI de la requête correspond à un chemin accessible directement (comme la page d'accueil
/ou les pages d'articles), exécutez l'action Skip All Rules.Règle de blocage (priorité faible) : Si le Referer est vide, exécutez l'action Block.
La règle de liste d'autorisation doit avoir une priorité supérieure à celle de la règle de blocage afin de garantir que les chemins d'accès direct ne soient pas affectés.
Scénario 5 : Bloquer les requêtes anormales pour un chemin d'URL spécifique
Configurez des conditions combinées : URI contenant une chaîne spécifique ET Referer vide. Pour l'action, sélectionnez Block ou JS Challenge.
Disponibilité des fonctionnalités par forfait
|
Fonctionnalité |
Standard |
Advanced |
Enterprise |
Entrance |
|
Nombre de règles personnalisées |
5 |
20 |
100 |
100 |
Le forfait Free ne prend pas en charge les conditions de correspondance basées sur des champs tels que Ip.Geoip.Country. Si vous utilisez ce champ dans une règle personnalisée, le système renvoie une erreur Ip.Geoip.Country.NotSupport. Pour utiliser des conditions de correspondance basées sur la géolocalisation, vous devez passer au forfait Basic ou supérieur.
FAQ
Pourquoi les règles de blocage basées sur le pays/la région provoquent-elles des faux positifs ou échouent-elles à identifier les régions « Unknown » ?
Les données de géolocalisation IP (continent, pays/région, province, FAI) ne peuvent pas être précises à 100 %. De plus, les VPN ou services proxy peuvent modifier la géolocalisation IP apparente d'un client, ce qui risque de déclencher incorrectement les règles.
Les plages d'IP privées (telles que 100.64.0.0/10) et les IP proxy peuvent être identifiées comme une région Unknown. ESA ne prend pas en charge le blocage direct de la région Unknown.
Recommandations :
Combinez les conditions de géolocalisation avec d'autres attributs comme le User-Agent ou le Referer. Par exemple : pays/région absent de la liste cible ET User-Agent ne correspondant pas à une valeur spécifique. Cela réduit les faux positifs causés par le recours exclusif à la géolocalisation.
Si des faux positifs surviennent, configurez une règle de liste d'autorisation pour permettre le passage des adresses IP légitimes.
Comment gérer les rappels tiers (comme les notifications Alipay) bloqués par le WAF ?
Analysez les caractéristiques communes des requêtes de rappel (par exemple, le chemin URI contient /pay/notify/, un User-Agent spécifique et la méthode de requête est POST). Ensuite, créez une règle personnalisée agissant comme une liste d'autorisation : si une requête correspond à toutes ces caractéristiques, appliquez l'action Skip All Rules.
Si vous ne pouvez pas déterminer toutes les caractéristiques, commencez par configurer des règles de blocage pour les modèles d'attaque connus, puis testez de manière incrémentielle pour vous assurer que les rappels légitimes ne sont pas bloqués.
Documentation connexe
Les fonctionnalités liées aux règles varient en termes de priorité effective, de réentrance et de granularité d'application. Pour plus de détails, consultez Propriétés des fonctionnalités liées aux règles.