Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : ✔️ Front Door Premium
Le Azure Front Door Web Application Firewall (WAF) permet de protéger vos applications web contre les menaces et les attaques courantes. Cet article explique comment configurer des listes d’exceptions WAF dans une stratégie WAF associée à votre Azure Front Door.
Pour obtenir une vue d’ensemble des stratégies WAF, consultez Azure Web Application Firewall sur Azure Front Door et les paramètres de stratégie WAF.
Dans certains cas, waf peut bloquer les requêtes qui sont sécurisées et attendues pour votre application. Les listes d’exceptions vous permettent de contourner l’inspection WAF pour des demandes spécifiques. Vous pouvez configurer des exceptions au niveau de la règle, du groupe de règles ou du jeu de règles managé.
Seule la prochaine génération du moteur WAF prend en charge les exceptions, et vous ne pouvez les utiliser que si votre version de l’ensemble de règles managés est DRS 2.1 ou ultérieure. Pour plus d’informations, consultez groupes de règles et règles DRS.
Important
Les exceptions dans Azure Front Door Web Application Firewall (WAF) sont actuellement en préversion. Consultez les Conditions d’utilisation supplémentaires pour les préversions Microsoft Azure pour les conditions légales qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale.
Définir des attributs de requête
Lorsque vous créez une exception, spécifiez les attributs de requête qui identifient le trafic qui doit contourner l’évaluation waf. Les attributs pris en charge sont les suivants :
- URI de la requête
- Adresse IP distante
- Nom et valeur de l’en-tête de requête
Mettre en correspondance des attributs exactement ou partiellement à l’aide des opérateurs suivants :
Égale: Correspond à la valeur exacte. Exemple: Pour sélectionner le porteur d’en-têteToken, utilisez l’opérateur Equals avec bearerToken comme sélecteur.
Commence par : Correspond aux valeurs commençant par le sélecteur spécifié.
Se termine par : Correspond aux valeurs se terminant par le sélecteur spécifié.
Contient: Correspond aux valeurs contenant le sélecteur spécifié.
Correspondance d’adresse IP : Correspond à une ou plusieurs adresses IP.
Définir l’étendue de l’exception
Exceptions de portée pour :
Une règle spécifique
Un groupe de règles
Un jeu de règles géré complet
Lorsque vous définissez une exception :
Spécifiez les règles, le groupe de règles ou le jeu de règles managé auquel il s’applique.
Définissez l’attribut de requête qui identifie le trafic à exclure.
Pour exclure un groupe de règles entier, fournissez le
ruleGroupNameparamètre. Utilisez lerulesparamètre uniquement lorsque vous limitez l’exception à des règles spécifiques au sein de ce groupe.
Tip
Toujours rendre les exceptions aussi étroites que possible. Les exceptions étendues peuvent exposer involontairement votre application aux attaques. Dans la mesure du possible, utilisez des exceptions par règle.
Appliquer une exception à votre stratégie WAF
Supposons que vous ne souhaitiez pas que WAF inspecte les requêtes adressées à /login.php et à /logout.php lorsqu’il évalue les règles relatives aux injections SQL. Configurez les exceptions comme suit :
Accédez à la stratégie WAF dans laquelle vous souhaitez ajouter des exceptions.
Sous Paramètres, sélectionnez Règles managées.
Sous l’onglet Exceptions , sélectionnez Ajouter des exceptions.
Dans S’applique à, sélectionnez l’ensemble de règles DRS auquel appliquer l’exception, par exemple Microsoft_DefaultRuleSet_2.1, puis sélectionnez l’étendue (ensemble de règles, groupe derègles ou règles spécifiques).
Sélectionnez Ajouter une exception et configurer la variable de correspondance, l’opérateur de correspondance de valeur et les valeurs.
Sélectionnez Ajouter , puis Enregistrer pour appliquer la nouvelle exception.
Accédez à l’onglet Exceptions pour afficher la nouvelle exception.
Limitations
Les limitations suivantes s’appliquent aux exceptions WAF :
Chaque Azure stratégie WAF prend en charge jusqu’à 60 exceptions.
Chaque Azure Front Door prend en charge jusqu’à 60 exceptions au total, calculée comme la somme de toutes les exceptions dans les stratégies WAF associées à cette passerelle.
Dans une exception unique, vous pouvez configurer jusqu’à :
600 adresses IP ou
10 URI, ou
10 en-têtes de requête.
Options permettant d’autoriser le trafic via Azure WAF
Azure Web Application Firewall (WAF) fournit plusieurs mécanismes pour autoriser en toute sécurité le trafic en cas de besoin tout en conservant la protection. Selon que vous souhaitez ignorer l’inspection d’une partie d’une demande ou de l’ensemble de la requête, utilisez exclusions, exceptions ou règles personnalisées.
Autoriser des parties spécifiques d’une requête à l’aide d’exclusions
Utilisez les exclusions lorsque vous souhaitez que waf ignore l’inspection d’un élément spécifique au sein d’une demande, par exemple un en-tête, un paramètre de requête ou un cookie, tout en appliquant une inspection au reste de la demande.
Exemple: Si une application légitime envoie un cookie de session avec des caractères aléatoires qui déclenchent fréquemment des faux positifs d’injection SQL, vous pouvez configurer une exclusion pour ce cookie. Le WAF n’inspecte pas la valeur du cookie, mais continue d’appliquer les protections au reste de la requête.
Autoriser des requêtes entières à l’aide de règles et d’exceptions personnalisées
Pour permettre à une requête entière d’ignorer l’inspection du WAF, utilisez l’une des options suivantes :
Règle personnalisée avec une action Autoriser
Lorsque vous configurez une règle personnalisée avec l’action Autoriser , la demande contourne l’inspection par le jeu de règles par défaut (DRS), l’ensemble de règles principal (CRS) et l’ensemble de règles Bot Protection.
Important
Ce contournement est absolu pour ces ensembles de règles et ne peut pas être modifié ou appliqué de manière sélective. Une fois l’action Autoriser déclenchée, aucun de ces ensembles de règles n’évalue la requête. Toutefois, l’ensemble de règles de protection HTTP DDoS traite toujours la requête. Cet ensemble de règles garantit que les requêtes sont vérifiées afin de détecter des attaques volumétriques ou par saturation, même si tous les autres ensembles de règles sont ignorés.
Utilisez cette configuration uniquement lorsque vous approuvez entièrement la source ou l’application du trafic, car elle désactive efficacement la détection des signatures et des anomalies.
Exemple: Si vous disposez d’une API partenaire approuvée qui déclenche fréquemment des règles DRS en raison de son format de charge utile, vous pouvez créer une règle d’autorisation personnalisée pour le trafic provenant de la plage d’adresses IP du partenaire. Cette configuration garantit que le trafic n’est jamais bloqué par DRS, CRS ou Bot Protection, tout en bénéficiant toujours de protections HTTP DDoS.
Exceptions (contrôle plus granulaire)
En revanche, les exceptions vous permettent de contourner l’inspection uniquement pour des règles spécifiques, des groupes de règles ou des ensembles de règles entiers plutôt que de les désactiver simultanément.
Vous pouvez appliquer des exceptions à DRS, CRS, Bot Protection et même à l’ensemble de règles HTTP DDoS.
Cette approche fournit un contrôle affiné. Vous pouvez donc désactiver l’inspection d’une règle problématique tout en conservant le reste des protections actives.
Exemple : Si une seule règle DRS (par exemple Restreindre l’en-tête de type de contenu) bloque les demandes d’application mobile valides, vous pouvez créer une exception pour cette règle uniquement. Toutes les autres règles DRS, la protection contre les bots et les protections DDoS continuent de s’appliquer au trafic.