Résoudre les problèmes liés au pare-feu d’applications web (WAF) pour Azure Application Gateway

Si votre pare-feu d’applications Web (WAF) bloque les demandes qui devraient être autorisées, vous pouvez prendre quelques mesures.

Commencez par consulter la présentation du WAF et la documentation de configuration du WAF , puis assurez-vous que la surveillance du WAF est activée. Ces articles expliquent le fonctionnement du WAF, le fonctionnement des ensembles de règles et l’accès aux journaux WAF.

Les ensembles de règles OWASP sont conçus pour être stricts dès le départ et pour être adaptés aux besoins spécifiques de l’application ou de l’organisation utilisant WAF. Il est tout à fait normal, et attendu dans de nombreux cas, de créer des exclusions, des règles personnalisées, et même de désactiver des règles qui peuvent causer des problèmes ou des faux positifs. Les stratégies par site et par URI permettent que ces changements n’affectent que des sites/URI spécifiques. Ainsi, les modifications ne devraient pas avoir à affecter d’autres sites qui ne rencontrent peut-être pas les mêmes problèmes.

Comprendre les journaux du WAF

L’objectif des journaux du WAF est de répertorier chaque demande que le WAF met en correspondance ou bloque. Il s’agit d’un registre de toutes les demandes évaluées qui sont mises en correspondance ou bloquées. Si vous remarquez que le WAF bloque une demande à tort (faux positif), vous pouvez agir de différentes manières. Tout d’abord, recherchez la demande en question par élimination. Parcourez les journaux pour trouver l’URI, l’horodatage ou l’ID de transaction de la demande qui vous intéresse. Une fois que vous avez trouvé les entrées de journal associées, vous pouvez commencer à agir sur les faux positifs.

Par exemple, supposez que avez un trafic légitime contenant la chaîne 1=1 que vous voulez faire transiter par votre WAF. Si vous tentez la demande, le WAF bloque le trafic qui contient votre chaîne 1=1 dans n’importe quel paramètre ou champ. Il s’agit d’une chaîne souvent associée à une attaque par injection de code SQL. Vous pouvez parcourir les journaux et trouver l’horodatage de la demande et les règles responsables du blocage/mise en correspondance.

Dans l’exemple suivant, vous pouvez constater que quatre règles sont déclenchées dans la même demande (voir le champ TransactionId). La première indique qu’elle a été mise en correspondance, car l’utilisateur a utilisé une URL numérique/IP pour la demande, ce qui augmente le score d’anomalie de trois puisqu’il s’agit d’un avertissement. La règle suivante à avoir eu une correspondance est la règle 942130, qui est celle que vous recherchez. Vous pouvez consulter 1=1 le champ details.data. Cela augmente encore le score d’anomalie de trois, car il s’agit aussi d’un avertissement. En règle générale, chaque règle qui contient l’action Matched augmente le score d’anomalie. À ce stade le score d’anomalie est égal à six. Pour plus d’informations, consultez Mode de calcul du score d’anomalie.

Les deux dernières entrées de journal montrent que la demande a été bloquée, car le score d’anomalie était suffisamment élevé. Ces entrées présentent une action différente des deux autres. Elles montrent qu’elles ont bel et bien bloqué la demande. Ces règles sont obligatoires et ne peuvent pas être désactivées. Elles ne devraient pas être considérées comme des règles, mais plutôt comme l’infrastructure de base des éléments internes du WAF.

{ 
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": { 
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "OWASP_CRS",
        "ruleSetVersion": "3.0.0",
        "ruleId": "920350",
        "message": "Host header is a numeric IP address",
        "action": "Matched",
        "site": "Global",
        "details": { 
            "message": "Warning. Pattern match \\\"^[\\\\\\\\d.:]+$\\\" at REQUEST_HEADERS:Host. ",
            "data": "40.90.218.160",
            "file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf\\\"",
            "line": "791" 
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt" 
    } 
} 
{ 
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": { 
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "OWASP_CRS",
        "ruleSetVersion": "3.0.0",
        "ruleId": "942130",
        "message": "SQL Injection Attack: SQL Tautology Detected.",
        "action": "Matched",
        "site": "Global",
        "details": { 
            "message": "Warning. Pattern match \\\"(?i:([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)([\\\\\\\\d\\\\\\\\w]++)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)(?:(?:=|\\u003c=\\u003e|r?like|sounds\\\\\\\\s+like|regexp)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)\\\\\\\\2|(?:!=|\\u003c=|\\u003e=|\\u003c\\u003e|\\u003c|\\u003e|\\\\\\\\^|is\\\\\\\\s+not|not\\\\\\\\s+like|not\\\\\\\\s+regexp)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)(?!\\\\\\\\2)([\\\\\\\\d\\\\\\\\w]+)))\\\" at ARGS:text1. ",
            "data": "Matched Data: 1=1 found within ARGS:text1: 1=1",
            "file": "rules\/REQUEST-942-APPLICATION-ATTACK-SQLI.conf\\\"",
            "line": "554" 
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt" 
    } 
} 
{ 
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": { 
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "",
        "ruleSetVersion": "",
        "ruleId": "0",
        "message": "Mandatory rule. Cannot be disabled. Inbound Anomaly Score Exceeded (Total Score: 8)",
        "action": "Blocked",
        "site": "Global",
        "details": { 
            "message": "Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. ",
            "data": "",
            "file": "rules\/REQUEST-949-BLOCKING-EVALUATION.conf\\\"",
            "line": "57" 
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt" 
    } 
} 
{ 
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": { 
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "",
        "ruleSetVersion": "",
        "ruleId": "0",
        "message": "Mandatory rule. Cannot be disabled. Inbound Anomaly Score Exceeded (Total Inbound Score: 8 - SQLI=5,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): SQL Injection Attack: SQL Tautology Detected.",
        "action": "Blocked",
        "site": "Global",
        "details": { 
            "message": "Warning. Operator GE matched 5 at TX:inbound_anomaly_score. ",
            "data": "",
            "file": "rules\/RESPONSE-980-CORRELATION.conf\\\"",
            "line": "73" 
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt" 
    }
}

Corriger les faux positifs

Compte tenu de ces éléments et de ce que la mise en correspondance de la chaîne 1=1 a été faite par la règle 942130, vous pouvez prendre quelques mesures pour empêcher le blocage du trafic :

Utilisez une liste d’exclusion. Pour plus d’informations sur les listes d’exclusion, consultez Listes d’exclusions WAF.
Désactiver la règle.

Utiliser une liste d’exclusion

Pour prendre une décision avisée sur le traitement d’un faux positif, il est important de se familiariser avec les technologies qu’utilise votre application. Par exemple, supposons que votre pile de technologies ne comporte pas de serveur SQL Server et que vous obtenez des faux positifs liés à ces règles. La désactivation de ces règles n’affaiblit pas nécessairement votre sécurité.

Un des avantages d’utiliser une liste d’exclusion est que seule une partie d’une demande est désactivée. Cependant, cela signifie qu’une exclusion spécifique est applicable à l’ensemble du trafic transitant par votre WAF, car il s’agit d’un paramètre global. Cela peut par exemple causer un problème si 1=1 est une demande valide dans le corps pour une application donnée, mais pas pour les autres. Un autre avantage est que vous pouvez choisir entre exclure le corps, les en-têtes et les cookies si une certaine condition est remplie, au lieu d’exclure la demande dans son intégralité.

À certaines occasions, il peut arriver que certains paramètres spécifiques soient transmis au WAF de manière peu intuitive. Par exemple, un jeton est transmis quand l’authentification repose sur Microsoft Entra ID. __RequestVerificationToken est généralement transmis sous la forme d’un cookie de demande. Cependant, dans certains cas où les cookies sont désactivés, ce jeton est aussi transmis comme attribut de demande ou arg. Si cela se produit, vous devez veiller à ce que __RequestVerificationToken soit également ajouté à la liste d’exclusion comme nom d’attribut de la demande.

Dans cet exemple, vous souhaitez exclure le nom d’attribut de la demande correspondant à text1. Cela est visible dans les journaux du pare-feu où figure le nom de l’attribut : data: Matched Data: 1=1 found within ARGS:text1: 1=1. L’attribut est text1. Il existe d’autres façons de rechercher ce nom d’attribut ; consultez Rechercher les noms d’attributs d’une demande.

Vous pouvez créer des exclusions pour WAF dans Application Gateway à différents niveaux d’étendue. Pour plus d’informations, consultez l’article Liste d'exclusions pare-feu d’applications web.

Désactiver les règles

Une autre façon de contourner un faux positif est de désactiver la règle qui a mis en correspondance l’entrée considérée malveillante par le WAF. Comme vous avez analysé les journaux du WAF et identifié la règle 942130, vous pouvez le désactiver sur le portail Azure. Consultez Personnaliser les règles de pare-feu d’applications web via le portail Azure.

La désactivation d’une règle présente notamment l’avantage suivant : si vous savez que l’ensemble du trafic contenant une certaine condition susceptible de le bloquer est du trafic valide, vous pouvez désactiver cette règle pour le WAF tout entier. Cependant, si le trafic n’est valide que dans un cas d’usage précis, vous créez une vulnérabilité en désactivant cette règle pour le pare-feu WAF entier, car il s’agit d’un paramètre global.

Si vous voulez utiliser Azure PowerShell, consultez Personnaliser les règles de pare-feu d’applications web par le biais de PowerShell. Si vous voulez utiliser Azure CLI, consultez Personnaliser les règles de pare-feu d’applications web par le biais d’Azure CLI.

Enregistrer des fichiers HAR

Vous pouvez utiliser votre navigateur ou un outil externe comme Fiddler pour enregistrer des fichiers HTTP Archive (HAR). Les fichiers HAR contiennent des informations sur les demandes et les réponses que votre navigateur effectue lors du chargement d’une page web. Ces informations peuvent être utiles pour résoudre les problèmes de WAF.

Conseil / Astuce

Il est recommandé d’avoir le fichier HAR prêt lorsque vous contactez le support technique. L’équipe de support technique peut utiliser le fichier HAR pour diagnostiquer le problème.

Bord
Chrome

Pour enregistrer et enregistrer un fichier HAR dans Microsoft Edge, procédez comme suit :

Appuyez sur F12 ou Ctrl+Maj+I pour lancer les outils de développement Edge. Vous pouvez également lancer les outils à partir du menu de la barre d’outils sous Plus d’outils > de développement.
Sous l’onglet Console , sélectionnez Effacer la console ou appuyez sur Ctrl+L.
Sélectionnez l’onglet Réseau.
Sélectionnez Effacer le journal réseau ou appuyez sur Ctrl+L, puis sélectionnez Enregistrer le journal réseau s'il n'est pas en cours d'enregistrement.
Chargez la page web protégée par votre WAF pour laquelle vous souhaitez résoudre les problèmes.
Arrêtez l’enregistrement en sélectionnant Arrêter l’enregistrement du journal réseau.
Sélectionnez Exporter HAR (désinfecté)... et enregistrez le fichier HAR.

Rechercher les noms d’attributs d’une requête

Vous pouvez utiliser Fiddler pour inspecter les requêtes individuelles et déterminer quels champs spécifiques d’une page web sont appelés. L’utilisation de ces informations permet d’exclure certains champs de l’inspection à l’aide de listes d’exclusions.

Dans cet exemple, vous pouvez voir que le champ dans lequel la chaîne 1=1 a été entrée s’appelle text1.

Il s’agit d’un champ que vous pouvez exclure. Pour en savoir plus sur les listes d’exclusions, consultez Listes d’exclusions du pare-feu d’applications web. Vous pouvez exclure l’évaluation dans ce cas en configurant l’exclusion suivante :

L’examen des journaux du pare-feu peut vous renseigner sur les éléments que vous devez ajouter à la liste d’exclusion. Pour activer la journalisation, consultez Intégrité du serveur principal, journaux de ressources et métriques pour la passerelle Application Gateway.

Examinez le journal du pare-feu et consultez le fichier PT1H.json correspondant à l’heure à laquelle s’est produite la demande que vous voulez inspecter.

Dans cet exemple, vous pouvez constater la présence de quatre règles avec le même TransactionID et qu’elles sont toutes intervenues exactement au même moment :

{
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": {
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "OWASP_CRS",
        "ruleSetVersion": "3.0.0",
        "ruleId": "920350",
        "message": "Host header is a numeric IP address",
        "action": "Matched",
        "site": "Global",
        "details": {
            "message": "Warning. Pattern match \\\"^[\\\\\\\\d.:]+$\\\" at REQUEST_HEADERS:Host. ",
            "data": "40.90.218.160",
            "file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf\\\"",
            "line": "791"
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt"
    }
}
{
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": {
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "OWASP_CRS",
        "ruleSetVersion": "3.0.0",
        "ruleId": "942130",
        "message": "SQL Injection Attack: SQL Tautology Detected.",
        "action": "Matched",
        "site": "Global",
        "details": {
            "message": "Warning. Pattern match \\\"(?i:([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)([\\\\\\\\d\\\\\\\\w]++)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)(?:(?:=|\\u003c=\\u003e|r?like|sounds\\\\\\\\s+like|regexp)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)\\\\\\\\2|(?:!=|\\u003c=|\\u003e=|\\u003c\\u003e|\\u003c|\\u003e|\\\\\\\\^|is\\\\\\\\s+not|not\\\\\\\\s+like|not\\\\\\\\s+regexp)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)(?!\\\\\\\\2)([\\\\\\\\d\\\\\\\\w]+)))\\\" at ARGS:text1. ",
            "data": "Matched Data: 1=1 found within ARGS:text1: 1=1",
            "file": "rules\/REQUEST-942-APPLICATION-ATTACK-SQLI.conf\\\"",
            "line": "554"
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt"
    }
}
{
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": {
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "",
        "ruleSetVersion": "",
        "ruleId": "0",
        "message": "Mandatory rule. Cannot be disabled. Inbound Anomaly Score Exceeded (Total Score: 8)",
        "action": "Blocked",
        "site": "Global",
        "details": {
            "message": "Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. ",
            "data": "",
            "file": "rules\/REQUEST-949-BLOCKING-EVALUATION.conf\\\"",
            "line": "57"
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt"
    }
}
{
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": {
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "",
        "ruleSetVersion": "",
        "ruleId": "0",
        "message": "Mandatory rule. Cannot be disabled. Inbound Anomaly Score Exceeded (Total Inbound Score: 8 - SQLI=5,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): SQL Injection Attack: SQL Tautology Detected.",
        "action": "Blocked",
        "site": "Global",
        "details": {
            "message": "Warning. Operator GE matched 5 at TX:inbound_anomaly_score. ",
            "data": "",
            "file": "rules\/RESPONSE-980-CORRELATION.conf\\\"",
            "line": "73"
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt"
    }
}

Compte tenu du fonctionnement des ensembles de règles CRS et sachant que l’ensemble de règles CRS 3.0 utilise un système de calcul de score d’anomalie (voir Pare-feu d’applications web pour Azure Application Gateway), vous savez que les deux règles du bas avec la propriété action: Blocked bloquent en fonction du score total d’anomalie. Les règles à examiner plus particulièrement sont les deux du haut.

La première entrée est journalisée, car l’utilisateur a utilisé une adresse IP numérique pour accéder à Application Gateway, ce qui peut être ignoré dans ce cas.

La deuxième (règle 942130) est celle qui nous intéresse. En y regardant de plus près, vous pouvez voir qu’elle a été mise en correspondance avec un modèle (1=1) et que le champ est nommé text1. Suivez les mêmes étapes que précédemment pour exclure le Nom d’attribut de demande qui correspond à 1=1.

Rechercher les noms d’en-tête d’une requête

Vous pouvez utiliser Fiddler pour rechercher les noms d’en-tête de requête. Dans la capture d’écran suivante figurent les en-têtes de la demande GET, à savoir Content-Type, User-Agent, etc.

Une autre façon d’afficher les en-têtes de demande et de réponse consiste à utiliser les outils de développement de Microsoft Edge ou google Chrome. Pour plus d’informations, consultez Enregistrer les fichiers HAR.

Si la demande contient des cookies, l’onglet Cookies peut être sélectionné pour les examiner dans Fiddler.

Restreindre les paramètres globaux pour éliminer les faux positifs

Désactiver l’inspection du corps de la demande

En définissant Inspecter le corps de la demande à désactiver, les corps de requête de votre trafic ne sont pas évalués par votre WAF. Cela peut être utile si vous savez que le corps des demandes n’est pas malveillant pour votre application.

Lorsque vous désactivez cette option, seul le corps de la demande contourne l’inspection. Les en-têtes et les cookies sont toujours inspectés, sauf si des individus sont exclus à l’aide de la fonctionnalité de liste d’exclusions.
Désactiver la limite maximale du corps de la requête

En désactivant la limite maximale du corps de demande, le WAF peut traiter les corps de demande volumineux sans les rejeter pour dépassement de la limite de taille. Ce paramètre est utile si vous avez régulièrement des demandes volumineuses.

Lorsque vous désactivez cette option, le corps de la demande n’est inspecté que jusqu’à la limite maximale d’inspection du corps de requête. S’il existe du contenu malveillant dans la requête au-delà de la limite d’inspection maximale du corps de la demande, le WAF ne le détecte pas.
Désactiver les limites maximales de taille de fichier

En désactivant les limites de taille de fichier pour votre WAF, les fichiers volumineux peuvent être chargés sans que votre WAF refuse ces chargements de fichiers. En autorisant le chargement de fichiers volumineux, vous augmentez le risque de saturation de votre back-end. Si vous connaissez la taille maximale qu’un chargement de fichier peut être, vous pouvez définir une limite de taille pour les chargements de fichiers légèrement au-dessus de la taille maximale attendue. Limiter la taille du fichier à un cas d’usage normal pour votre application est une autre façon d’empêcher les attaques. Toutefois, si vos chargements de fichiers dépassent régulièrement la limite maximale de taille de chargement de fichiers pouvant être appliquée, vous devrez peut-être désactiver entièrement les limites de taille de chargement de fichier pour éviter les faux positifs.

Remarque

Si vous savez que votre application n’aura jamais besoin de charger des fichiers au-delà d’une taille donnée, vous pouvez ajouter une restriction en définissant une limite.

Avertissement

Lors de l’attribution d’un nouvel ensemble de règles gérées à une stratégie WAF, toutes les personnalisations précédentes des ensembles de règles gérés existants, telles que l’état des règles, les actions de règle et les exclusions au niveau de la règle, seront réinitialisées aux valeurs par défaut du nouvel ensemble de règles gérées. Toutefois, toutes les règles personnalisées, les paramètres de stratégie et les exclusions globales resteront inchangés lors de l’attribution du nouvel ensemble de règles.

Métriques de pare-feu (WAF v1 uniquement)

Pour les pare-feu d’applications web v1, les métriques suivantes sont désormais disponibles dans le portail :

Nombre de requêtes bloquées par le pare-feu d’applications web : nombre de requêtes qui ont été bloquées
Nombre de règles bloquées par le pare-feu d’applications web : toutes les règles qui correspondaient et la requête ont été bloquées
Distribution totale des règles de pare-feu d’applications web : toutes les règles qui correspondaient pendant l’évaluation

Pour activer les métriques, sélectionnez l’onglet Métriques dans le portail, puis sélectionnez l’une des trois métriques.

Étape suivante

Configurer le pare-feu d’applications web sur Application Gateway

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-06-13