Fehlerbehebung für die Web Application Firewall (WAF) des Azure Application Gateway.

Zusammenfassung

Dieser Artikel hilft Ihnen dabei, Probleme mit der Web Application Firewall (WAF) beim Azure Application Gateway zu beheben, wenn legitime Anforderungen blockiert werden, sodass Sie gültigen Datenverkehr zulassen können, während der Schutz erhalten bleibt.

Überprüfen Sie zunächst die WAF-Übersicht und die WAF-Konfigurationsdokumentation , und stellen Sie sicher, dass die WAF-Überwachung aktiviert ist. In diesen Artikeln wird erläutert, wie das WAF funktioniert, wie die Regelsätze funktionieren und wie auf WAF-Protokolle zugegriffen wird.

Die OWASP-Regelsätze sind so konzipiert, dass sie sofort einsatzbereit sind und entsprechend den spezifischen Anforderungen der Anwendung oder Organisation mit WAF abgestimmt werden. Es ist ganz normal und wird in vielen Fällen erwartet, Ausschlüsse, benutzerdefinierte Regeln zu erstellen und sogar Regeln zu deaktivieren, die Probleme oder falsch positive Ergebnisse verursachen können. Richtlinien pro Standort und URI ermöglichen es diesen Änderungen nur, bestimmte Websites oder URIs zu beeinflussen. Daher sollten sich Änderungen nicht auf andere Websites auswirken, die möglicherweise nicht dieselben Probleme haben.

Verstehen von WAF-Protokollen

Der Zweck von WAF-Protokollen besteht darin, jede Anforderung anzuzeigen, die die WAF erfüllt oder blockiert. Es handelt sich um ein Protokoll aller ausgewerteten Anfragen, die zugeordnet oder blockiert werden. Wenn Sie feststellen, dass die WAF eine Anfrage blockiert, die sie nicht blockieren sollte (ein False Positive), können Sie einige Schritte unternehmen. Zunächst eingrenzen und die spezifische Anfrage finden. Durchsuchen Sie die Protokolle, um den spezifischen URI, den Zeitstempel oder die Transaktions-ID der Anforderung zu finden. Wenn Sie die zugehörigen Protokolleinträge finden, können Sie beginnen, auf die falsch positiven Ergebnisse zu reagieren.

Angenommen, Sie haben einen legitimen Datenverkehr, der die Zeichenfolge 1=1 enthält, die Sie durch Ihre WAF übergeben möchten. Wenn Sie die Anforderung testen, blockiert der WAF Datenverkehr, der Ihre 1=1 Zeichenfolge in einem beliebigen Parameter oder Feld enthält. Diese Zeichenfolge steht häufig mit einem Angriff durch Einschleusung von SQL-Befehlen in Verbindung. Sie können die Protokolle durchsuchen und den Zeitstempel der Anforderung sowie die Regeln, die eine Blockierung oder Übereinstimmung ergaben, ermitteln.

Im folgenden Beispiel können Sie sehen, dass vier Regeln während derselben Anforderung ausgelöst werden (mithilfe des Felds "TransactionId"). Die erste besagt, dass sie übereinstimmte, weil der Benutzer eine numerische IP-Adresse für die Anforderung verwendet hat, wodurch die Anomaliebewertung um drei erhöht wird, da es sich um eine Warnung handelt. Die nächste übereinstimmende Regel ist 942130, d. h. die gesuchte Regel. Sie können das 1=1 im details.data-Feld sehen. Dies erhöht die Anomaliebewertung wieder um drei, da es ebenfalls eine Warnung ist. Im Allgemeinen erhöht jede Regel mit der Aktion "Übereinstimmung" den Anomaliewert, und an diesem Punkt beträgt die Anomaliebewertung sechs. Weitere Informationen finden Sie im Anomaliebewertungsmodus.

Die letzten beiden Protokolleinträge zeigen an, dass die Anforderung blockiert wurde, da die Anomaliebewertung hoch genug war. Diese Einträge haben eine andere Funktion als die anderen beiden. Sie zeigen, dass sie die Anforderung tatsächlich blockiert haben . Diese Regeln sind obligatorisch und können nicht deaktiviert werden. Betrachten Sie diese Regeln nicht als Regeln, sondern eher als grundlegende Infrastruktur der WAF-Interna.

{ 
    "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" 
    }
}

Falschpositive beheben

Mit diesen Informationen und dem Wissen, dass Regel 942130 der Zeichenfolge entspricht 1=1 , können Sie einige Schritte ausführen, um zu verhindern, dass Ihr Datenverkehr blockiert wird:

Verwenden Sie eine Ausschlussliste. Weitere Informationen zu Ausschlusslisten finden Sie unter WAF-Ausschlusslisten.
Deaktivieren Sie die Regel.

Fehlalarme auf Paranoia-Level 2 verringern

In OWASP CRS 3.2 gehören die SQL-Injection-Regeln 942430, 942440 und 942450 zu Paranoia Level 2 (PL2). Wenn WAF-Protokolle zeigen, dass eine legitime Authentifizierungsanforderung mit einer dieser Regeln übereinstimmt, identifizieren Sie das Feld für die beitragende Anforderung, bevor Sie einen Ausschluss hinzufügen. Bestätigen Sie, dass die Anforderung legitim ist, und identifizieren Sie die Regel-ID und den konfigurierten Regelsatz. Beschreibungen und versionsspezifische Ersetzungen finden Sie unter WAF-Regelgruppen und -regeln. Aktivieren Sie keine inaktive Regel und ändern Sie keine Regelsätze, nur um diesem Beispiel zu folgen.

Verwenden Sie in Log Analytics die folgende Abfrage, wenn Ihre Diagnoseeinstellung Firewallprotokolle an die AzureDiagnostics Tabelle sendet. Ersetzen Sie die Ressourcen-ID und den Zeitraum durch das Gateway und das Intervall, das Sie untersuchen. Diese Protokolle können vertrauliche Anforderungsdaten enthalten; Geben Sie feldwerte oder Authentifizierungstoken nicht gemeinsam.

Führen Sie die folgende Abfrage aus.

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

Suchen Sie die Transaktion für die fehlgeschlagene Anfrage. Eine beitragende Regel kann eine Aktion Matchedaufweisen, während eine separate Anomaliebewertungsregel die Transaktion blockiert. Um alle Übereinstimmungen für diese Transaktion zu prüfen, ersetzen Sie den Regel-ID-Filter durch einen Filter für transactionId_g. Schließen Sie nicht die Anomaliebewertungsregel anstelle der beitragenden Regel aus.
Konfigurieren Sie für ein bestätigt falsch positives Ergebnis einen Ausschluss für das bestimmte Feld und nur die beitragenden Regel-IDs. Für Ausschlüsse pro Regel ist ein unterstützter WAF-Richtlinienregelsatz erforderlich, wie z. B. der OWASP CRS 3.2. Verwenden Sie Equals für die Feldauswahl, und behalten Sie andere Regeln und vorhandene Richtlinieneinstellungen bei. Weitere Informationen finden Sie in der regelbezogenen CLI- und PowerShell-Prozedur und den regelspezifischen Ausschlussbeispielen. Informationen zur Regelermittlung finden Sie im PowerShell-Anpassungshandbuch und im CLI-Anpassungshandbuch.
Lesen Sie die Richtlinie zurück, um zu bestätigen, dass der Ausschluss die beabsichtigte Regelsatzversion, Gruppe, Regel-IDs, Übereinstimmungsvariablen und Selektor enthält. Ein globaler Ausschluss, der dieses Feld bereits abdeckt, gilt noch; Das Hinzufügen eines schmaleren Ausschlusses entfernt ihn nicht. Überprüfen Sie alle vorhandenen allgemeinen Ausschlüsse separat, anstatt alle Ausschlüsse zu löschen.
Wiederholen Sie dieselbe legitime Anforderung, und überprüfen Sie ihre Antwort und neue Transaktionsprotokolle. Bestätigen Sie, dass die ausgewählte Regel nicht mehr mit dem ausgeschlossenen Feld übereinstimmt, und untersuchen Sie andere beitragende Regeln, wenn die Anforderung blockiert bleibt. Eine leere Abfrage ohne reproduzierten Datenverkehr und funktionierende Diagnosesammlung stellt keinen Erfolg fest. Validieren Sie, dass nicht zugehörige Felder in einer kontrollierten Testumgebung weiterhin geprüft werden.

Schließen Sie nicht automatisch alle drei IDs oder alle Authentifizierungsfelder aus. Behalten Sie den WAF im Präventionsmodus für diese gezielte Änderung bei. Wenn Sie ihn rückgängig machen müssen, entfernen Sie nur den regelbezogenen Ausschluss, den Sie nach der Überprüfung der Richtlinie hinzugefügt haben. vorhandene Ausschlüsse beibehalten.

Verwenden einer Ausschlussliste

Um eine fundierte Entscheidung über die Behandlung eines falsch positiven Ergebnisses zu treffen, machen Sie sich mit den technologien vertraut, die Ihre Anwendung verwendet. Wenn Ihr Technologiestapel z. B. keinen SQL-Server enthält und Sie falsch positive Ergebnisse im Zusammenhang mit diesen Regeln erhalten, schwächt das Deaktivieren dieser Regeln Ihre Sicherheit nicht unbedingt.

Ein Ausschluss lässt ein ausgewähltes Anforderungsattribut aus der Überprüfung aus. Ein globaler Ausschluss gilt für alle verwalteten Regeln, während ein Ausschluss pro Regel nur für die ausgewählten Regeln in einem unterstützten Regelsatz gilt. Beide gelten unabhängig davon, wo die WAF-Richtlinie zugeordnet ist, und überprüfen Sie daher die Anwendungen und Pfade der Richtlinie, bevor Sie sie ändern. Beispielsweise kann das Ausschließen eines Felds ein Risiko erstellen, wenn 1=1 für eine Anwendung gültig ist, aber nicht für eine andere, die die Richtlinie teilt. Bevorzugen Sie einen eng gefassten Ausschluss, statt die gesamte Anfrage auszuschließen.

Gelegentlich werden bestimmte Parameter auf eine Art und Weise an den WAF übergeben, die möglicherweise nicht intuitiv ist. Beispielsweise gibt es ein Token, das bei der Authentifizierung mithilfe von Microsoft Entra ID übergeben wird. __RequestVerificationToken wird in der Regel als Anfrage-Cookie übergeben. In einigen Fällen, in denen Cookies deaktiviert sind, wird dieses Token jedoch auch als Anforderungsattribut oder argübergeben. In diesem Fall müssen Sie sicherstellen, dass __RequestVerificationToken auch als Anforderungsattributnamen zur Ausschlussliste hinzugefügt wird.

In diesem Beispiel möchten Sie den Namen des Request-Attributs ausschließen, das text1 entspricht. Dieser Attributname wird angezeigt, da der Attributname in den Firewallprotokollen angezeigt wird : Daten: Übereinstimmende Daten: 1=1 in ARGS:text1: 1=1. Das Attribut ist Text1. Sie können diesen Attributnamen auch auf einige andere Arten finden, siehe Suchen von Attributnamen für Anforderungsattribute.

Sie können Ausschlüsse für WAF im Anwendungsgateway auf unterschiedlichen Bereichsebenen erstellen. Weitere Informationen finden Sie unter Web Application Firewall Ausschlusslisten.

Regeln deaktivieren

Eine weitere Möglichkeit, ein falsch positives Ergebnis zu behandeln, besteht darin, die Regel zu deaktivieren, die mit der Eingabe übereinstimmt, die der WAF-Gedanken als bösartig angesehen hat. Da Sie die WAF-Protokolle analysiert und die Regel auf 942130 beschränkt haben, können Sie sie im Azure-Portal deaktivieren. Weitere Informationen finden Sie unter Customize web application firewall rules through the Azure portal.

Wenn Sie wissen, dass der gesamte Datenverkehr, der eine bestimmte Bedingung enthält, die normalerweise blockiert ist, gültigen Datenverkehr ist, können Sie diese Regel für die gesamte WAF deaktivieren. Wenn es jedoch nur gültiger Datenverkehr in einem bestimmten Anwendungsfall ist, öffnen Sie eine Sicherheitsanfälligkeit, indem Sie diese Regel für die gesamte WAF deaktivieren, da es sich um eine globale Einstellung handelt.

Informationen zur Verwendung von Azure PowerShell finden Sie unter Anpassen von Firewallregeln für Webanwendungen über PowerShell. Informationen zur Verwendung von Azure CLI finden Sie unter Anpassen von Firewallregeln für Webanwendungen über die Azure CLI.

Aufzeichnen von HAR-Dateien

Sie können Ihren Browser oder ein externes Tool wie Fiddler verwenden, um HAR-Dateien (HTTP Archive) aufzuzeichnen. HAR-Dateien enthalten Informationen zu den Anforderungen und Antworten, die Ihr Browser beim Laden einer Webseite vorgibt. Diese Informationen können für die Problembehandlung von WAF-Problemen hilfreich sein.

Tipp

Es empfiehlt sich, die HAR-Datei bereit zu haben, wenn Sie sich an den Support wenden. Das Supportteam kann die HAR-Datei verwenden, um das Problem zu diagnostizieren.

Edge
Chrome

Führen Sie die folgenden Schritte aus, um eine HAR-Datei in Microsoft Edge aufzuzeichnen und zu speichern:

Drücken Sie F12 oder STRG+UMSCHALT+I, um Edge Entwicklungstools zu öffnen. Sie können die Tools auch über das Menü der Symbolleiste unter Weitere Tools>Entwicklertools öffnen.
Wählen Sie auf der Registerkarte "Konsole " die Option "Konsole löschen" aus, oder drücken Sie STRG+L.

Wählen Sie die Registerkarte "Netzwerk " aus.
Wählen Sie "Netzwerkprotokoll löschen" aus, oder drücken Sie STRG+L, und wählen Sie dann das Netzwerkprotokoll aufzeichnen aus, wenn es nicht aufgezeichnet wird.

Laden Sie die Webseite, die von Ihrer WAF geschützt wird und deren Probleme Sie untersuchen möchten.
Beenden Sie die Aufzeichnung, indem Sie das Netzwerkprotokoll "Aufzeichnung beenden" auswählen.
Wählen Sie "HAR exportieren" (sanitiert) aus, und speichern Sie die HAR-Datei.

Namen von Anforderungsattributen suchen

Verwenden Sie Fiddler, um einzelne Anforderungen zu prüfen und zu bestimmen, welche spezifischen Felder einer Webseite aufgerufen werden. Mithilfe dieser Informationen können Sie bestimmte Felder mithilfe von Ausschlusslisten aus der Prüfung ausschließen.

In diesem Beispiel können Sie sehen, dass das Feld, in das die Zeichenfolge 1=1 eingegeben wurde, als Text1 bezeichnet wird.

Dies ist ein Feld, das Sie ausschließen können. Weitere Informationen zu Ausschlusslisten finden Sie unter Web Application Firewall-Ausschlusslisten. Sie können die Auswertung in diesem Fall ausschließen, indem Sie den folgenden Ausschluss konfigurieren:

Sie können auch die Firewallprotokolle untersuchen, um die Informationen abzurufen, um zu sehen, was Sie zur Ausschlussliste hinzufügen müssen. Informationen zum Aktivieren der Protokollierung finden Sie unter Back-End-Integrität, Ressourcenprotokolle und Metriken für das Anwendungsgateway.

Überprüfen Sie das Firewallprotokoll, und zeigen Sie die PT1H.json Datei für die Stunde an, zu der die Anforderung, die Sie überprüfen möchten, aufgetreten ist.

In diesem Beispiel sehen Sie, dass Sie vier Regeln mit derselben TransactionID haben und dass sie alle gleichzeitig aufgetreten sind:

{
    "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"
    }
}

Mit Ihrem Wissen darüber, wie die CRS-Regelsätze funktionieren und dass das CRS-Regelsatz 3.0 mit einem Anomaliebewertungssystem arbeitet (siehe Web Application Firewall für Azure Application Gateway), wissen Sie, dass die beiden untersten Regeln mit der Aktion: Blockiert-Eigenschaft basierend auf der Gesamtanomaliebewertung blockiert werden. Die Regeln, auf die sich konzentrieren soll, sind die beiden obersten.

Der erste Eintrag wird protokolliert, da der Benutzer eine numerische IP-Adresse verwendet hat, um zum Anwendungsgateway zu navigieren, das Sie in diesem Fall ignorieren können.

Der zweite Eintrag (Regel 942130) wird in den Details angezeigt, da er mit einem Muster (1=1)übereinstimmt, und das Feld heißt "text1". Führen Sie die gleichen vorherigen Schritte aus, um den Anforderungsattributnamen auszuschließen, der gleich ist text1.

Anforderungsheadernamen finden

Verwenden Sie Fiddler, um Anforderungsheadernamen zu finden. Im folgenden Screenshot können Sie die Kopfzeilen für diese GET-Anforderung sehen, die Inhaltstyp, Benutzer-Agent und andere Kopfzeilen enthalten.

Sie können auch die Entwicklertools in Microsoft Edge oder Google Chrome verwenden, um Anforderungs- und Antwortheader anzuzeigen. Weitere Informationen finden Sie unter "Har-Dateien aufzeichnen".

Wenn die Anforderung Cookies enthält, wählen Sie die Registerkarte Cookies aus, um sie in Fiddler anzuzeigen.

Beschränken globaler Parameter zur Vermeidung falsch positiver Ergebnisse

Anforderungskörper-Überprüfung deaktivieren

Wenn Sie Inspect request body deaktivieren, wertet Ihre WAF die Anfrageinhalte Ihres Datenverkehrs nicht aus. Diese Einstellung ist nützlich, wenn Sie wissen, dass die Anforderungstexte für Ihre Anwendung nicht schädlich sind.

Wenn Sie diese Option deaktivieren, wird nur die Überprüfung des Anforderungstexts umgangen. Die Header und Cookies werden weiterhin überprüft, es sei denn, Sie schließen einzelne davon über die Ausschlusslistenfunktion aus.
Maximale Anforderungskörpergrenze deaktivieren

Wenn Sie die maximale Anforderungstextgrenze deaktivieren, kann WAF große Anforderungstexte verarbeiten, ohne sie für die Überschreitung des Größenlimits abzulehnen. Diese Einstellung ist nützlich, wenn Sie regelmäßig große Anfragen bearbeiten.

Wenn Sie diese Option deaktivieren, wird der Anforderungstext nur bis zur maximalen Anforderungsstellenüberprüfungsgrenze überprüft. Wenn die Anfrage schädliche Inhalte enthält, die über die maximale Inspektionsgrenze für den Anfragetext hinausgehen, erkennt die WAF sie nicht.
Maximale Dateigrößenbeschränkungen deaktivieren

Wenn Sie die Dateigrößenbeschränkungen für Ihre WAF deaktivieren, können große Dateien hochgeladen werden, ohne dass Ihre WAF diese Dateiuploads ablehnt. Durch die Möglichkeit, große Dateien hochzuladen, erhöht sich das Risiko, dass Ihr Back-End überfordert wird. Wenn Sie wissen, dass die maximale Größe eines Dateiuploads möglich ist, legen Sie einen Größengrenzwert für Dateiuploads fest, der etwas über der erwarteten maximalen Größe liegt. Das Einschränken der Dateigröße auf einen normalen Anwendungsfall für Ihre Anwendung ist eine weitere Möglichkeit, Angriffe zu verhindern. Wenn Ihre Dateiuploads jedoch regelmäßig über das maximal erzwingbare Dateigrößenlimit hinausgehen, müssen Sie möglicherweise die Dateigrößenbeschränkungen für Dateiuploads vollständig deaktivieren, um falsch positive Ergebnisse zu vermeiden.

Hinweis

Wenn Sie wissen, dass Ihre App niemals einen Dateiupload über einer bestimmten Größe benötigt, können Sie diese Größe einschränken, indem Sie einen Grenzwert festlegen.

Warnung

Wenn Sie einer WAF-Richtlinie ein neues verwaltetes Regelet zuweisen, werden alle vorherigen Anpassungen aus den vorhandenen verwalteten Regelets wie Regelzustand, Regelaktionen und Ausschlüsse auf Regelebene auf die Standardwerte des neuen verwalteten Regelets zurückgesetzt. Alle benutzerdefinierten Regeln, Richtlinieneinstellungen und globalen Ausschlüsse bleiben jedoch während der neuen Regelsatzzuweisung nicht betroffen.

Firewallmetriken (nur WAF v1)

Für V1-Webanwendungsfirewalls stellt das Portal jetzt die folgenden Metriken bereit:

Web Application Firewall Anzahl blockierter Anforderungen Die Anzahl der blockierten Anforderungen.
Web Application Firewall Anzahl der blockierten Regeln Alle Regeln, die zutreffen und bei denen die Anfrage blockiert wird.
Web Application Firewall Gesamtregelverteilung alle Regeln, die während der Auswertung übereinstimmen.

Um Metriken zu aktivieren, wählen Sie die Registerkarte "Metriken " im Portal aus, und wählen Sie eine der drei Metriken aus.

References

Konfigurieren Sie die Webanwendungs-Firewall für das Anwendungsgateway

Feedback

War diese Seite hilfreich?

Zuletzt aktualisiert um 2026-09-17