Share via

Azure Web Application Firewall für Azure Front Door optimieren

  • Artikel

Der von Microsoft verwaltete Standardregelsatz basiert auf dem OWASP Core-Regelsatz und enthält Regeln der Microsoft Threat Intelligence-Sammlung.

Häufig wird davon ausgegangen, dass Web Application Firewall-Regeln (WAF) entsprechend den spezifischen Anforderungen der Anwendung oder Organisation, die WAF verwendet, optimiert werden müssen. Organisationen erreichen die Optimierung in der Regel durch eine der folgenden Aktionen:

  • Definition von Regelausschlüssen.
  • Erstellung benutzerdefinierter Regeln.
  • Deaktivierung von Regeln, die Probleme oder False Positives verursachen können.

In diesem Artikel wird beschrieben, was Sie tun können, wenn Anforderungen, die ihre WAF durchlaufen sollen, blockiert werden.

Hinweis

Der von Microsoft verwaltete Regelsatz ist für die Standard-SKU von Azure Front Door nicht verfügbar. Weitere Informationen zu den SKUs der verschiedenen Ebenen finden Sie im Featurevergleich zwischen Ebenen.

Lesen Sie die Dokumente Übersicht über WAF für Azure Front Door und WAF-Richtlinie für Azure Front Door. Aktivieren Sie außerdem die WAF-Überwachung und -Protokollierung. In diesen Artikeln wird die Funktionsweise von WAF und WAF-Regelsätzen sowie der Zugriff auf WAF-Protokolle erläutert.

Grundlegendes zu WAF-Protokollen

Der Zweck von WAF-Protokollen ist es, jede Anforderung anzuzeigen, die von der WAF abgeglichen oder blockiert wird. Es handelt sich um eine Sammlung aller ausgewerteten Anforderungen, die abgeglichen oder blockiert werden. Wenn Sie feststellen, dass die WAF eine Anforderung blockiert, bei der das nicht geschehen sollte (ein falsch positives Ergebnis), stehen Ihnen einige Möglichkeiten zur Verfügung.

Nehmen Sie zunächst eine Eingrenzung vor, und suchen Sie nach der relevanten Anforderung. Sie können eine benutzerdefinierte Antwortnachricht so konfigurieren, dass sie das Feld trackingReference enthält, um das Ereignis einfach zu identifizieren und eine Protokollabfrage für den spezifischen Wert auszuführen. Durchsuchen Sie die Protokolle, um den jeweiligen URI, den Zeitstempel oder die Client-IP-Adresse der Anforderung zu ermitteln. Wenn Sie die zugehörigen Protokolleinträge gefunden haben, können Sie Maßnahmen für die False Positives ergreifen.

Angenommen, Sie haben einen berechtigten Datenverkehr, der die Zeichenfolge 1=1 enthält und die WAF durchlaufen soll. Die Anforderung sieht wie folgt aus:

POST http://afdwafdemosite.azurefd.net/api/Feedbacks HTTP/1.1
Host: afdwafdemosite.azurefd.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 55

UserId=20&captchaId=7&captchaId=15&comment="1=1"&rating=3

Beim Ausführen der Anforderung blockiert die WAF Datenverkehr, der die Zeichenfolge 1=1 in einem 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.

Das folgende Beispiel zeigt einen Protokolleintrag, der basierend auf einer Regelübereinstimmung generiert wurde. Sie können die folgende Log Analytics-Abfrage verwenden, um Anforderungen zu suchen, die innerhalb der letzten 24 Stunden blockiert wurden.

AzureDiagnostics
| where Category == 'FrontDoorWebApplicationFirewallLog'
| where TimeGenerated > ago(1d)
| where action_s == 'Block'

AzureDiagnostics
| where Category == 'FrontdoorWebApplicationFirewallLog'
| where TimeGenerated > ago(1d)
| where action_s == 'Block'

Im Feld requestUri können Sie sehen, dass die Anforderung für /api/Feedbacks/ spezifisch durchgeführt wurde. Ermitteln Sie weiter unten im Feld ruleName die Regel-ID 942110. Wenn Sie die Regel-ID kennen, können Sie im offiziellen Repository des OWASP ModSecurity-Kernregelsatzes nach dieser Regel-ID suchen, um den zugehörigen Code zu überprüfen und genau zu verstehen, worauf diese Regel zutrifft.

Wenn Sie dann das Feld action überprüfen, stellen Sie fest, dass diese Regel so definiert ist, dass Anforderungen beim Abgleich blockiert werden. Sie können bestätigen, dass die Anforderung von der WAF blockiert wurde, da die policyMode auf prevention festgelegt ist.

Prüfen Sie nun die Informationen im Feld details. In diesem Feld werden die Informationen zu matchVariableName und matchVariableValue angezeigt. Diese Regel wurde ausgelöst, da 1=1 im Feld comment der Web-App eingegeben wurde.

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Cdn/Profiles/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Network/FrontDoor/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

Es ist auch sinnvoll, die Zugriffsprotokolle zu überprüfen, um Ihr Wissen über ein bestimmtes WAF-Ereignis zu erweitern. Als nächstes überprüfen Sie das Protokoll, das als Reaktion auf das vorherige Ereignis generiert wurde.

Sie können sehen, dass diese Protokolle zusammenhängen, weil der Wert trackingReference derselbe ist. Bei den verschiedenen Feldern, die einen allgemeinen Einblick geben, wie z. B. userAgent und clientIP, beachten Sie die Felder httpStatusCode und httpStatusDetails. Hier sehen Sie, dass der Client eine HTTP 403-Antwort erhalten hat, wodurch sich bestätigt, dass diese Anforderung verweigert und blockiert wurde.

{
    "time": "2020-09-24T16:43:04.5430764Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorAccessLog",
    "operationName": "Microsoft.Cdn/Profiles/AccessLog/Write",
    "properties": {
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "httpMethod": "POST",
        "httpVersion": "1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "requestBytes": "2160",
        "responseBytes": "324",
        "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36",
        "clientIp": "1.1.1.1",
        "socketIp": "1.1.1.1",
        "clientPort": "53566",
        "timeToFirstByte": "0.01",
        "timeTaken": "0.011",
        "securityProtocol": "",
        "routingRuleName": "DemoBERoutingRule",
        "rulesEngineMatchNames": [],
        "backendHostname": "13.88.65.130:3000",
        "isReceivedFromClient": true,
        "httpStatusCode": "403",
        "httpStatusDetails": "403",
        "pop": "WST",
        "cacheStatus": "CONFIG_NOCACHE"
    }
}

{
    "time": "2020-09-24T16:43:04.5430764Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorAccessLog",
    "operationName": "Microsoft.Network/FrontDoor/AccessLog/Write",
    "properties": {
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "httpMethod": "POST",
        "httpVersion": "1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "requestBytes": "2160",
        "responseBytes": "324",
        "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36",
        "clientIp": "1.1.1.1",
        "socketIp": "1.1.1.1",
        "clientPort": "53566",
        "timeToFirstByte": "0.01",
        "timeTaken": "0.011",
        "securityProtocol": "",
        "routingRuleName": "DemoBERoutingRule",
        "rulesEngineMatchNames": [],
        "backendHostname": "13.88.65.130:3000",
        "isReceivedFromClient": true,
        "httpStatusCode": "403",
        "httpStatusDetails": "403",
        "pop": "WST",
        "cacheStatus": "CONFIG_NOCACHE"
    }
}

Auflösen von False Positives

Um eine fundierte Entscheidung zum Umgang mit False Positives zu treffen, müssen Sie sich mit den von Ihrer Anwendung verwendeten Technologien vertraut machen. Angenommen, es ist kein SQL-Server in Ihrem Technologiestapel vorhanden, und Sie erhalten falsch positive Ergebnisse im Zusammenhang mit diesen Regeln. Durch Deaktivieren dieser Regeln wird nicht unbedingt die Sicherheit geschwächt.

Mit diesen Informationen und dem Wissen, dass die Regel 942110 eine Übereinstimmung mit der Zeichenfolge 1=1 ergab, gibt es einige Möglichkeiten, um zu verhindern, dass diese legitime Anforderung blockiert wird:

Tipp

Wenn Sie einen Ansatz wählen, um legitime Anforderungen über WAF zuzulassen, versuchen Sie, diesen so eng wie möglich zu fassen. Beispielsweise ist es besser, eine Ausschlussliste zu verwenden, als eine Regel vollständig zu deaktivieren.

Verwenden von Ausschlusslisten

Ein Vorteil der Verwendung einer Ausschlussliste besteht darin, dass nur die Übereinstimmungsvariable, die ausgeschlossen werden soll, nicht mehr für die jeweilige Anforderung überprüft wird. Das heißt, Sie können zwischen spezifischen Anforderungsheadern, Anforderungscookies, Argumenten für Abfragezeichenfolgen oder POST-Argumenten für Anforderungstext wählen, die ausgeschlossen werden sollen, wenn eine bestimmte Bedingung erfüllt ist, anstatt die gesamte Anforderung von der Überprüfung auszuschließen. Die anderen nicht angegebenen Variablen der Anforderung werden weiterhin normal überprüft.

Ausschlüsse sind eine globale Einstellung. Der konfigurierte Ausschluss gilt für den gesamten Datenverkehr, der Ihre WAF durchläuft, nicht nur für eine bestimmte Web-App oder einen URI. Dies kann beispielsweise ein Problem sein, wenn 1=1 eine gültige Anforderung im Text für eine bestimmte Web-App ist, nicht aber für andere Web-Apps mit der gleichen WAF-Richtlinie.

Wenn es sinnvoll ist, unterschiedliche Ausschlusslisten für verschiedene Anwendungen zu verwenden, sollten Sie verschiedene WAF-Richtlinien für die einzelnen Anwendungen verwenden und auf das Front-End der jeweiligen Anwendung anwenden.

Wenn Sie Ausschlusslisten für verwaltete Regeln konfigurieren, können Sie folgendes ausschließen:

  • Alle Regeln innerhalb eines Regelsatzes.
  • Alle Regeln innerhalb einer Regelgruppe.
  • Eine einzelne Regel.

Sie können eine Ausschlussliste mit PowerShell, der Azure CLI, der REST-API, Bicep, Azure Resource Manager-Vorlagen oder dem Azure-Portal konfigurieren.

  • Ausschlüsse auf Regelebene: Das Anwenden von Ausschlüssen auf Regelebene bedeutet, dass die angegebenen Ausschlüsse nicht nur für diese einzelne Regel analysiert werden. Sie wird weiterhin von allen anderen Regeln im Regelsatz analysiert. Dies ist die präziseste Ebene für Ausschlüsse. Sie können damit den verwalteten Regelsatz auf der Grundlage der Informationen, die Sie bei der Fehlerbehebung eines Ereignisses in den WAF-Protokollen finden, optimieren.
  • Ausschlüsse auf Regelgruppenebene: Die Anwendung von Ausschlüssen auf Regelgruppenebene bedeutet, dass die angegebenen Ausschlüsse für die entsprechende Gruppe von Regeltypen nicht analysiert werden. Die Auswahl von SQLI als ausgeschlossene Regelgruppe bedeutet beispielsweise, dass die definierten Anforderungsausschlüsse durch keine der SQLI-spezifischen Regeln überprüft werden. Sie werden jedoch weiterhin von Regeln in anderen Gruppen wie PHP, RFI oder XSS überprüft. Diese Art des Ausschlusses kann nützlich sein, wenn Sie sicher sind, dass die Anwendung nicht anfällig für bestimmte Arten von Angriffen ist. Beispielsweise können bei einer Anwendung, die keine SQL-Datenbanken enthält, alle SQLI-Regeln ausgeschlossen werden, ohne dass dies die zugehörige Sicherheitsstufe beeinträchtigt.
  • Ausschlüsse auf Regelsatzebene: Die Anwendung von Ausschlüssen auf Regelsatzebene bedeutet, dass die angegebenen Ausschlüsse für keine der Sicherheitsregeln analysiert werden, die im entsprechenden Regelsatz verfügbar sind. Dieser Ausschluss ist umfassend, daher sollten Sie ihn mit Bedacht nutzen.

In diesem Beispiel führen durch Anwenden eines Ausschlusses auf eine einzelne Regel einen Ausschluss auf der präzisesten Ebene aus. Wir schließen die Übereinstimmungsvariable Request body post args name aus, die comment enthält. Sie sehen die Details der Übereinstimmungsvariablen im Firewallprotokoll: "matchVariableName": "PostParamValue:comment". Das Attribut ist comment. Es gibt auch andere Möglichkeiten zum Auffinden dieses Attributnamens. Weitere Informationen finden Sie unter Suchen von Anforderungsattributnamen.

Screenshot that shows exclusion rules.

Screenshot that shows rule exclusion for a specific rule.

Gelegentlich gibt es Fälle, in denen bestimmte Parameter auf eine möglicherweise nicht intuitive Weise an die WAF übergeben werden. Beispielsweise wird ein Token übergeben, wenn Sie sich mithilfe von Microsoft Entra ID authentifizieren. Das Token (__RequestVerificationToken) wird normalerweise als Anforderungscookie übergeben.

In Fällen, in denen Cookies deaktiviert sind, wird dieses Token auch als POST-Argument der Anforderung übergeben. Aus diesem Grund müssen Sie sicherstellen, dass __RequestVerificationToken für RequestCookieNames und für RequestBodyPostArgsNames in der Ausschlussliste hinzugefügt wird, um False Positives für Microsoft Entra-Token zu beheben.

Ausschlüsse für einen Feldnamen (Selektor) bedeuten, dass der Wert nicht mehr von WAF ausgewertet wird. Der Feldname selbst wird weiterhin ausgewertet. In seltenen Fällen kann er mit einer WAF-Regel übereinstimmen und eine Aktion auslösen.

Screenshot that shows rule exclusion for a rule set.

Ändern von WAF-Aktionen

Eine andere Möglichkeit, das Verhalten von WAF-Regeln anzupassen, besteht darin, die Aktion auszuwählen, die ausgeführt wird, wenn eine Anforderung den Bedingungen einer Regel entspricht. Die verfügbaren Aktionen lauten Allow, Block, Log und Redirect (Zulassen, Blockieren, Protokollieren und Umleiten).

In diesem Beispiel wurde die Standardaktion Block (Blockieren) für die Regel 942110 in die Aktion Log (Protokollieren) geändert. Durch diese Aktion wird die Anforderung von WAF protokolliert und die Auswertung der gleichen Anforderung für die verbleibenden Regeln mit niedrigerer Priorität fortgesetzt.

Screenshot that shows WAF actions.

Nachdem Sie dieselbe Anfrage durchgeführt haben, können Sie in den Protokollen sehen, dass diese Anfrage mit der Regel-ID 942110 übereinstimmt. Das Feld action_s zeigt jetzt Log anstelle von Block an. Die Protokollabfrage wurde danach erweitert, um die trackingReference_s-Informationen einzufügen und festzustellen, was mit der Anforderung sonst noch passiert ist.

Screenshot that shows a log showing multiple rule matches.

Jetzt sehen Sie eine andere SQLI-Regelübereinstimmung, die Millisekunden nach der Verarbeitung der Regel-ID 942110 auftritt. Dieselbe Anforderung entsprach der Regel-ID 942310, und dieses Mal wurde die Standardaktion Block (Blockieren) ausgelöst.

Ein weiterer Vorteil der Verwendung der Aktion Log (Protokollieren) während der WAF-Optimierung oder Problembehandlung besteht darin, dass Sie ermitteln können, ob mehrere Regeln in einer spezifischen Regelgruppe übereinstimmen und eine bestimmte Anforderung blockieren. Sie können dann die Ausschlüsse auf der entsprechenden Ebene erstellen, d. h. auf der Regel- oder Regelgruppenebene.

Verwenden benutzerdefinierter WAF-Regeln

Nachdem Sie ermittelt haben, wodurch eine WAF-Regelübereinstimmung verursacht wird, können Sie mithilfe von benutzerdefinierten Regeln die WAF-Reaktion an das Ereignis anpassen. Benutzerdefinierte Regeln werden vor verwalteten Regeln verarbeitet. Sie können mehrere Bedingungen enthalten, und die zugehörigen Aktionen können Allow, Deny, Log oder Redirect sein (Zulassen, Verweigern, Protokollieren oder Umleiten).

Warnung

Wenn eine Anforderung mit einer benutzerdefinierten Regel übereinstimmt, beendet die WAF-Engine die Verarbeitung der Anforderung. Verwaltete Regeln werden für diese Anforderung nicht verarbeitet, ebenso wie andere benutzerdefinierte Regeln mit einer niedrigeren Priorität.

Das folgende Beispiel zeigt eine benutzerdefinierte Regel mit zwei Bedingungen. Mit der ersten Bedingung wird der Wert comment im Anforderungstext gesucht. Mit der zweiten Bedingung wird der Wert /api/Feedbacks/ im Anforderungs-URI gesucht.

Durch die Verwendung einer benutzerdefinierten Regel können Sie am präzisesten sein, sodass Sie Ihre WAF-Regeln optimieren und False Positives verarbeiten können. In diesem Fall führen Sie keine Aktionen aus, die nur auf dem Wert comment des Anforderungstexts basieren, der in mehreren Sites oder Apps mit derselben WAF-Richtlinie vorhanden sein kann.

Wenn Sie eine weitere Bedingung für die Übereinstimmung mit einem bestimmten Anforderungs-URI (/api/Feedbacks/) einfügen, stellen Sie sicher, dass diese benutzerdefinierte Regel auch wirklich für den überprüften expliziten Anwendungsfall gilt. Dadurch wird sichergestellt, dass derselbe Angriff, wenn er unter verschiedenen Bedingungen ausgeführt wird, dennoch von der WAF-Engine überprüft und verhindert wird.

Screenshot that shows a log.

Beim Überprüfen des Protokolls können Sie sehen, dass das Feld ruleName_s den Namen der erstellten benutzerdefinierten Regel enthält: redirectcomment. Im Feld action_s sehen Sie, dass für dieses Ereignis die Aktion Redirect (Umleiten) ausgeführt wurde. Im Feld details_matches_s sehen Sie, dass die Details für beide Bedingungen übereinstimmen.

Deaktivieren von Regeln

Eine weitere Möglichkeit für den Umgang mit False Positives ist das Deaktivieren der Regel, die eine Übereinstimmung mit der Eingabe ergab, die von der WAF als schädlich angesehen wird. Da Sie die WAF-Protokolle analysiert und die Regel auf 942110 eingeschränkt haben, können Sie sie im Azure-Portal deaktivieren. Weitere Informationen finden Sie unter Anpassen von Azure Web Application Firewall-Regeln mit dem Azure-Portal.

Das Deaktivieren einer Regel ist von Vorteil, wenn Sie sicher sind, dass alle Anforderungen, die eine bestimmte Bedingung erfüllen, legitime Anforderungen sind, oder wenn Sie sicher sind, dass die Regel nicht für Ihre Umgebung gilt (z. B. das Deaktivieren einer SQL-Einschleusungsregel, da Sie keine SQL-Back-Ends verwenden).

Die Deaktivierung einer Regel ist eine globale Einstellung, die für alle Front-End-Hosts gilt, die der WAF-Richtlinie zugeordnet sind. Wenn Sie eine Regel deaktivieren, werden Sicherheitsrisiken möglicherweise ohne Schutz oder Erkennung für andere Front-End-Hosts offengelegt, die der WAF-Richtlinie zugeordnet sind.

Wenn Sie eine verwaltete Regel mithilfe von Azure PowerShell deaktivieren möchten, finden Sie weitere Informationen in der Dokumentation zum PSAzureManagedRuleOverride-Objekt. Wenn Sie die Azure-Befehlszeilenschnittstelle verwenden möchten, finden Sie weitere Informationen in der Dokumentation zu az network front-door waf-policy managed-rules override.

Screenshot that shows WAF rules.

Tipp

Dokumentieren Sie Änderungen, die Sie an ihrer WAF-Richtlinie vornehmen. Schließen Sie Beispielanforderungen ein, um die Erkennung von False Positives zu veranschaulichen. Erläutern Sie, warum Sie eine benutzerdefinierte Regel hinzugefügt, eine Regel oder einen Regelsatz deaktiviert oder eine Ausnahme hinzugefügt haben. Wenn Sie die Anwendung in Zukunft umgestalten, müssen Sie eventuell sicherstellen, dass Ihre Änderungen noch gültig sind. Vielleicht werden Sie auch einem Audit unterzogen oder müssen begründen, warum Sie die WAF-Richtlinie von ihren Standardeinstellungen abweichend neu konfiguriert haben.

Suchen von Anforderungsfeldern

Mithilfe eines Browserproxys wie Fiddler können Sie einzelne Anforderungen überprüfen und bestimmen, welche spezifischen Felder einer Webseite aufgerufen werden. Diese Methode ist nützlich, wenn Sie bestimmte Felder mithilfe von Ausschlusslisten in WAF von der Überprüfung ausschließen müssen.

Suchen von Anforderungsattributnamen

In diesem Beispiel hat das Feld, in dem die Zeichenfolge 1=1 eingegeben wurde, den Namen comment. Diese Daten wurden im Text einer POST-Anforderung übergeben.

Screenshot that shows the body of a Fiddler request.

Sie können dieses Feld ausschließen. 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:

Screenshot that shows an exclusion rule.

Sie können auch die Firewallprotokolle überprüfen, um Informationen dazu zu erhalten, was Sie der Ausschlussliste hinzufügen müssen. Informationen zum Aktivieren der Protokollierung finden Sie unter Überwachen von Metriken und Protokollen in Azure Front Door.

Überprüfen Sie das Firewallprotokoll, und sehen Sie sich die Datei PT1H.json für die Stunde an, in der die zu untersuchende Anforderung aufgetreten ist. Die PT1H.json-Dateien sind in den Speicherkontocontainern verfügbar, in denen die FrontDoorWebApplicationFirewallLog- und FrontDoorAccessLog-Diagnoseprotokolle gespeichert sind.

Überprüfen Sie das Firewallprotokoll, und sehen Sie sich die Datei PT1H.json für die Stunde an, in der die zu untersuchende Anforderung aufgetreten ist. Die PT1H.json-Dateien sind in den Speicherkontocontainern verfügbar, in denen die FrontdoorWebApplicationFirewallLog- und FrontdoorAccessLog-Diagnoseprotokolle gespeichert sind.

In diesem Beispiel können Sie die Regel sehen, die die Anforderung blockiert hat (mit dem gleichen Transaktionsverweis) und zur gleichen Zeit aufgetreten ist.

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Cdn/Profiles/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Network/FrontDoor/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

Mit Ihrem Wissen über die Funktionsweise der von Azure verwalteten Regelsätze wissen Sie, dass die Regel mit der Eigenschaft action: Block basierend auf den Daten, die im Anforderungstext übereinstimmen, für die Blockierung verantwortlich ist. (Weitere Informationen finden Sie unter Azure Web Application Firewall in Azure Front Door). Sie sehen in den Details, dass es mit einem Muster (1=1) übereinstimmt, und das Feld heißt comment. Führen Sie die gleichen Schritte wie zuvor aus, um „Request body post args name“ mit comment auszuschließen.

Anforderungsheadernamen finden

Fiddler ist ein nützliches Tool für die Suche nach Anforderungsheadernamen. Der folgende Screenshot zeigt die Header für diese GET-Anforderung, die Content-Type und User-Agent enthalten. Sie können auch mithilfe von Anforderungsheadern Ausschlüsse und benutzerdefinierte Regeln in WAF erstellen.

Screenshot that shows the header of a Fiddler request.

Eine weitere Möglichkeit zum Anzeigen von Anforderungs- und Antwortheadern bieten die Entwicklertools Ihres Browsers, z. B. Microsoft Edge oder Chrome. Sie können F12 drücken oder mit der rechten Maustaste auf Inspect>Developer Tools klicken. Wählen Sie die Registerkarte Network aus. Laden Sie eine Webseite, und wählen Sie die Anforderung aus, die Sie überprüfen möchten.

Screenshot that shows a Network inspector request.

Wenn die Anforderung Cookies enthält, wählen Sie die Registerkarte Cookies aus, um sie in Fiddler anzuzeigen. Auch Cookieinformationen können zum Erstellen von Ausschlüssen oder benutzerdefinierten Regeln in WAF verwendet werden.

Anomalie-Bewertungsregel

Wenn die Regel-ID 949110 während der Optimierung Ihrer WAF angezeigt wird, weist dies darauf hin, dass die Anforderung durch den Prozess Anomalie-Bewertung blockiert wurde.

Überprüfen Sie die anderen WAF-Protokolleinträge für dieselbe Anforderung, indem Sie nach den Protokolleinträgen mit derselben Nachverfolgungsreferenz suchen. Sehen Sie sich die einzelnen ausgelösten Regeln an. Optimieren Sie jede Regel, indem Sie die Anleitung in diesem Artikel befolgen.

Nächste Schritte