Résoudre les problèmes de Web Application Firewall (WAF) pour Azure Application Gateway

Résumé

Cet article vous aide à résoudre les problèmes de Web Application Firewall (WAF) pour Azure Application Gateway lorsque des demandes légitimes sont bloquées. Vous pouvez donc autoriser le trafic valide tout en conservant la protection.

Commencez par consulter la vue d’ensemble du WAF et la documentation de configuration waf , et vérifiez que la surveillance WAF est activée. Ces articles expliquent comment fonctionne le WAF, comment fonctionnent les ensembles de règles et comment accéder aux journaux WAF.

Les ensembles de règles OWASP sont conçus pour être stricts et adaptés aux besoins spécifiques de l’application ou de l’organisation à l’aide du WAF. Il est entièrement normal et attendu dans de nombreux cas, pour créer des exclusions, des règles personnalisées et même désactiver des règles susceptibles de provoquer des problèmes ou des faux positifs. Les stratégies par site et par URI autorisent ces modifications à affecter uniquement des sites ou DES URI spécifiques. Les modifications ne doivent donc pas affecter d’autres sites susceptibles de ne pas rencontrer les mêmes problèmes.

Comprendre les journaux WAF

L’objectif des journaux WAF est d’afficher chaque requête que le WAF correspond à 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 requête qu’il ne devrait pas bloquer (un faux positif), vous pouvez prendre quelques mesures. Tout d’abord, réduisez et recherchez la requête spécifique. Examinez les journaux pour rechercher l’URI, l’horodatage ou l’ID de transaction spécifique de la requête. Lorsque vous trouvez les entrées de journal associées, vous pouvez commencer à agir sur les faux positifs.

Par exemple, supposons que vous disposez d’un trafic légitime contenant la chaîne 1=1 que vous souhaitez transmettre via votre WAF. Si vous essayez la requête, le WAF bloque le trafic qui contient votre 1=1 chaîne 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 requête et les règles responsables du blocage ou de la mise en correspondance.

Dans l’exemple suivant, vous pouvez voir que quatre règles sont déclenchées pendant la même requête (à l’aide du champ TransactionId). Le premier indique qu’il correspond parce que l’utilisateur a utilisé une adresse IP numérique pour la requête, ce qui augmente le score d’anomalie par trois, car il s’agit d’un avertissement. La règle suivante qui correspond à 942130, c’est-à-dire celle que vous recherchez. Vous pouvez voir le 1=1 dans le champ details.data. Cela augmente encore le score d’anomalie par trois, car il s’agit également d’un avertissement. En règle générale, chaque règle ayant l’action Mise en correspondance augmente le score d’anomalie, et à ce stade, le score d’anomalie est de six. Pour plus d’informations, consultez le mode de scoring des anomalies.

Les deux dernières entrées de journal montrent que la requête a été bloquée, car le score d’anomalie était assez élevé. Ces entrées ont une action différente de celle des deux autres. Ils montrent qu’ils ont réellement bloqué la demande. Ces règles sont obligatoires et ne peuvent pas être désactivées. Ne considérez pas ces règles comme des règles, mais plutôt comme l’infrastructure de base du fonctionnement interne du WAF.

{ 
    "resourceId": "/SUBSCRIPTIONS/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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

Avec ces informations, et la connaissance que la règle 942130 est celle qui correspond à la 1=1 chaîne, vous pouvez effectuer quelques étapes pour empêcher cette règle de bloquer votre trafic :

  • Utilisez une liste d’exclusions. Pour plus d’informations sur les listes d’exclusion, consultez listes d’exclusion WAF.

  • Désactivez la règle.

Réduire les faux positifs du niveau de paranoïa 2

Dans OWASP CRS 3.2, les règles 942430d’injection SQL et 942440942450 appartiennent au Paranoia Level 2 (PL2). Si les journaux WAF indiquent qu’une demande d’authentification légitime correspond à l’une de ces règles, identifiez le champ de demande de contribution avant d’ajouter une exclusion. Vérifiez que la requête est légitime et identifiez son ID de règle et son ensemble de règles configurés. Pour obtenir des descriptions et des remplacements spécifiques à la version, consultez groupes de règles et règles WAF. N’activez pas une règle inactive ou modifiez les ensembles de règles simplement pour suivre cet exemple.

  1. Dans Log Analytics, utilisez la requête suivante si votre paramètre de diagnostics envoie les journaux de pare-feu vers la table AzureDiagnostics. Remplacez l’identifiant de ressource et la plage horaire par la passerelle et l’intervalle que vous analysez. Ces journaux peuvent contenir des données de requête sensibles ; ne partagez pas de valeurs de champ ou de jetons d’authentification.

Exécutez la requête suivante.

AzureDiagnostics
| where TimeGenerated > ago(1h)
| where _ResourceId =~ "<application-gateway-resource-id>"
| where Category == "ApplicationGatewayFirewallLog"
| where ruleId_s in ("942430", "942440", "942450")
| project TimeGenerated, transactionId_g, requestUri_s,
    ruleId_s, action_s, details_message_s, details_data_s
| order by TimeGenerated desc
  1. Recherchez la transaction correspondant à la requête en échec. Une règle contributive peut avoir l’action Matched, tandis qu’une règle distincte d’évaluation des anomalies bloque la transaction. Pour examiner toutes les correspondances pour cette transaction, remplacez le filtre rule-ID par un filtre sur transactionId_g. N’excluez pas une règle d’évaluation des anomalies à la place de la règle contributrice.
  2. Pour un faux positif confirmé, configurez une exclusion pour le champ concerné et uniquement pour les identifiants des règles contributrices. Les exclusions par règle nécessitent un jeu de règles de stratégie WAF pris en charge, comme OWASP CRS 3.2. Utilisez Equals le sélecteur de champ et conservez d’autres règles et paramètres de stratégie existants. Consultez la procédure CLI et PowerShell délimitée par une règle et les exemples d’exclusion par règle. Pour la découverte de règles, consultez le guide de personnalisation PowerShell et le guide de personnalisation de l’interface CLI.
  3. Relisez la stratégie pour confirmer que l’exclusion inclut la version prévue de l’ensemble de règles, le groupe, les ID de règle, la variable de mise en correspondance et le sélecteur. Une exclusion globale couvrant déjà ce champ s’applique toujours ; l’ajout d’une exclusion plus étroite ne le supprime pas. Passez en revue les exclusions générales existantes séparément plutôt que d’effacer toutes les exclusions.
  4. Répétez la même requête légitime et vérifiez sa réponse et les nouveaux journaux de transactions. Vérifiez que la règle sélectionnée ne correspond plus au champ exclu et examinez les autres règles de contribution si la demande reste bloquée. Une requête vide, sans reproduction du trafic ni collecte des diagnostics fonctionnelle, ne permet pas de conclure à une réussite. Vérifiez que les champs non liés restent inspectés dans un environnement de test contrôlé.

N’excluez pas automatiquement les trois ID ou tous les champs d’authentification. Conservez le WAF en mode Prévention pour cette modification ciblée. Si vous devez l’annuler, supprimez uniquement l’exclusion délimitée par la règle que vous avez ajoutée après avoir examiné la stratégie ; conservez les exclusions préexistantes.

Utiliser une liste d’exclusions

Pour prendre une décision éclairée sur la gestion d’un faux positif, familiarisez-vous avec les technologies utilisées par votre application. Par exemple, si votre pile technologique n’inclut pas de serveur SQL 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é.

Une exclusion omet un attribut de demande sélectionné de l’inspection. Une exclusion globale s’applique à toutes les règles gérées, tandis qu’une exclusion par règle s’applique uniquement aux règles sélectionnées dans un ensemble de règles pris en charge. Les deux s’appliquent partout où la stratégie WAF est associée. Vérifiez donc les applications et les chemins d’accès de la stratégie avant de le modifier. Par exemple, l’exclusion d’un champ peut créer un risque lorsque 1=1 est valide pour une application, mais pas pour une autre qui partage la stratégie. Préférez une exclusion ciblée plutôt que d’exclure l’ensemble de la requête.

Parfois, des paramètres spécifiques sont transmis dans le WAF d’une manière qui peut ne pas être intuitive. Par exemple, un jeton est transmis lors de l’authentification avec Microsoft Entra ID. __RequestVerificationToken est généralement transmis en tant que cookie de demande. Toutefois, dans certains cas où les cookies sont désactivés, ce jeton est également passé en tant qu’attribut de requête ou arg. Si cela se produit, vous devez vous assurer que __RequestVerificationToken est également ajouté à la liste d’exclusion en tant que nom d’attribut de requête .

Screenshot des paramètres de liste d’exclusion WAF dans le portail Azure portal.

Dans cet exemple, vous souhaitez exclure le nom de l’attribut Request qui est égal à text1. Ce nom d’attribut est évident, car vous pouvez voir le nom de l’attribut dans les journaux du pare-feu : data: Données correspondantes : 1=1 trouvé dans ARGS:text1: 1=1. L’attribut est text1. Vous pouvez également trouver ce nom d’attribut de plusieurs autres façons, consultez Recherche de noms d’attributs de requête.

Capture d’écran des options de configuration WAF pour les listes d’exclusion dans Application Gateway.

Vous pouvez créer des exclusions pour WAF dans Application Gateway à différents niveaux d’étendue. Pour plus d’informations, consultez Web Application Firewall listes d’exclusions.

Désactiver les règles

Une autre façon de gérer un faux positif consiste à désactiver la règle qui correspond à l’entrée que le WAF pensait malveillant. Étant donné que vous avez analysé les journaux WAF et réduit la règle à 942130, vous pouvez la désactiver dans le portail Azure. Consultez personnaliser les règles du pare-feu pour les applications web à l'aide du portail Azure.

Si vous savez que tout le trafic qui contient une certaine condition normalement bloquée est un trafic valide, vous pouvez désactiver cette règle pour l’ensemble du WAF. Toutefois, s’il s’agit uniquement d’un trafic valide dans un cas d’usage spécifique, vous ouvrez une vulnérabilité en désactivant cette règle pour l’ensemble du WAF, car il s’agit d’un paramètre global.

Pour utiliser Azure PowerShell, consultez Personnaliser les règles de pare-feu d’applications web via PowerShell. Pour utiliser Azure CLI, consultez Personnaliser les règles de pare-feu d’applications web via le 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.

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

  1. Appuyez sur F12 ou Ctrl+Maj+I pour ouvrir Edge Outils de développement. Vous pouvez également ouvrir les outils à partir du menu de la barre d’outils sous Autres outils>Outils de développement.

  2. Sous l’onglet Console , sélectionnez Effacer la console ou appuyez sur Ctrl+L.

Screenshot de l’onglet Console des outils de développement Microsoft Edge.

  1. Sélectionnez l’onglet Réseau .

  2. Sélectionnez Effacer le journal réseau ou appuyez sur Ctrl+L, puis sélectionnez le journal réseau d’enregistrement s’il n’est pas enregistré.

Screenshot de l’onglet Réseau des outils de développement Microsoft Edge.

  1. Chargez la page web protégée par votre WAF que vous souhaitez dépanner.

  2. Arrêtez l’enregistrement en sélectionnant Arrêter l’enregistrement du journal réseau.

  3. Sélectionnez Exporter HAR (désinfecté)... et enregistrez le fichier HAR.

Capture d'écran de l'option d'exportation HAR (désinfectée) dans les outils de développement de Microsoft Edge.

Rechercher des noms d’attributs de requête

Utilisez 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 vous 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 est appelé text1.

Capture d’écran du débogueur web Fiddler. Dans l’onglet Raw, 1=1 est visible après le nom 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 :

Capture d’écran d’une exclusion WAF configurée pour un attribut de requête spécifique.

Vous pouvez également examiner les journaux de pare-feu pour obtenir les informations nécessaires pour voir ce que vous devez ajouter à la liste d’exclusions. Pour activer la journalisation, consultez l’intégrité du back-end, les journaux de ressources et les métriques d'Application Gateway.

Examinez le journal du pare-feu et affichez le fichier PT1H.json pour l’heure pendant laquelle la demande que vous souhaitez inspecter s’est produite.

Dans cet exemple, vous voyez que vous avez quatre règles avec le même TransactionID et qu’elles se sont toutes produites en même temps :

{
    "resourceId": "/SUBSCRIPTIONS/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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"
    }
}

Avec vos connaissances sur le fonctionnement des ensembles de règles CRS, et que l’ensemble de règles CRS 3.0 fonctionne avec un système de scoring d’anomalies (voir Web Application Firewall pour Azure Application Gateway) vous savez que les deux règles inférieures avec la action : Bloqué sont bloquantes en fonction du score d’anomalie total. Les règles à mettre en avant sont les deux principales.

La première entrée est enregistrée, car l’utilisateur a utilisé une adresse IP numérique pour accéder à Application Gateway, que vous pouvez ignorer dans ce cas.

La deuxième entrée (règle 942130) est affichée dans les détails, car elle correspond à un modèle (1=1)et le champ est nommé text1. Suivez les mêmes étapes précédentes pour exclure le nom de l’attribut de requête qui est text1égal à .

Rechercher des noms d’en-tête de requête

Utilisez Fiddler pour rechercher les noms d’en-tête de requête. Dans la capture d’écran suivante, vous pouvez voir les en-têtes de cette requête GET, notamment Content-Type, User-Agent et d’autres en-têtes.

Capture d’écran du débogueur web Fiddler. L’onglet Brut affiche des détails de l'en-tête de requête, tels que la connexion, le type de contenu et le User-Agent.

Vous pouvez également utiliser les outils de développement dans Microsoft Edge ou Google Chrome pour afficher les en-têtes de demande et de réponse. Pour plus d’informations, consultez Enregistrer les fichiers HAR.

Si la requête contient des cookies, sélectionnez l’onglet Cookies pour les examiner dans Fiddler.

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

  • Désactiver l’analyse du contenu de la requête

    Lorsque vous définissez Inspect request body sur Désactivé, votre WAF n’évalue pas le corps des requêtes de votre trafic. Ce paramètre est utile si vous savez que les corps de requête ne sont pas malveillants 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 vous excluez des éléments individuels à l’aide de la fonctionnalité de liste d’exclusion.

  • Désactiver la limite maximale du corps de la requête

    Lorsque vous désactivez la limite maximale du corps de la requête, WAF peut traiter des corps de requêtes volumineux sans les rejeter pour dépasser la limite de taille. Ce paramètre est utile si vous avez régulièrement des requêtes volumineuses.

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

  • Désactiver les limites maximales de taille de fichier

    Lorsque vous désactivez les limites de taille de fichier pour votre WAF, les fichiers volumineux peuvent être chargés sans que votre WAF rejette ces chargements de fichiers. En autorisant le chargement de fichiers volumineux, le risque que votre back-end soit submergé augmente. Si vous connaissez la taille maximale qu’un chargement de fichier peut être, définissez une limite de taille pour les chargements de fichiers légèrement au-dessus de votre 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.

    Note

    Si vous savez que votre application n’a jamais besoin d’un chargement de fichier au-dessus d’une taille donnée, vous pouvez limiter cette taille en définissant une limite.

    Avertissement

    Lorsque vous affectez un nouveau jeu de règles managés à une stratégie WAF, toutes les personnalisations précédentes des ensembles de règles managés existants, tels que l’état des règles, les actions de règle et les exclusions au niveau de la règle, sont réinitialisées aux valeurs par défaut du nouveau jeu de règles managés. Toutefois, les règles personnalisées, les paramètres de la stratégie et les exclusions globales restent inchangés lors de l’attribution du nouveau jeu de règles.

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

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

  1. Nombre de requêtes bloquées par le pare-feu d’applications web Le nombre de requêtes bloquées.
  2. Web Application Firewall Nombre de règles bloquées toutes les règles qui correspondent et la requête est bloquée.
  3. Pare-feu d’application web Répartition totale des règles Toutes les règles qui correspondent lors de 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.

References