Optimieren von Azure Web Application Firewall für Azure Front Door

Gilt für: ✔️ Front Door Standard/Premium ✔️ Front Door (klassisch)

Der Microsoft verwaltete Standardregelsatz basiert auf dem OWASP Core Rule Set und enthält Microsoft Threat Intelligence-Auflistungsregeln.

Oft müssen Sie die Web Application Firewall (WAF)-Regeln so abstimmen, dass sie den spezifischen Bedürfnissen Ihrer Anwendung oder Organisation entsprechen. Häufige Abstimmungsmaßnahmen sind:

  • Definition von Regelausschlüssen.
  • Erstellung benutzerdefinierter Regeln.
  • Regeln deaktivieren, die Probleme verursachen oder Fehlalarme verursachen.

Dieser Artikel beschreibt, was Sie tun können, wenn die WAF Anfragen blockiert, die durchgelassen werden sollten.

Hinweis

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

Lesen Sie die WAF-Übersicht von Azure Front Door und die Artikel zur WAF-Richtlinie für Azure Front Door. Aktivieren Sie außerdem die WAF-Überwachung und -Protokollierung. In diesen Artikeln wird erläutert, wie die WAF funktioniert, wie die WAF-Regelsätze funktionieren und wie der Zugriff auf die WAF-Protokolle erfolgt.

Machen Sie sich vor der Optimierung mit den Auswirkungen des Geltungsbereichs der Richtlinie vertraut.

Bevor Sie Regeln, Ausschlüsse oder Aktionen anpassen, ermitteln Sie den Bereich, dem Sie die Richtlinie zugeordnet haben:

  • Profilebene: Änderungen können den gesamten geschützten Datenverkehr im Profil beeinflussen.
  • Domänenniveau: Änderungen beeinflussen den Datenverkehr für die ausgewählten Domain-Assoziationen.
  • Routenniveau: Änderungen betreffen nur passende Routen und sind die am stärksten gezielte Option.

Wenn für eine Anfrage mehrere Geltungsbereiche gelten, hat die Richtlinie auf Routenebene Vorrang vor der Richtlinie auf Domänenebene, und die Richtlinie auf Domänenebene hat Vorrang vor der Richtlinie auf Profilebene.

Für die meisten Bereitstellungen beginnen Sie mit der grundlegenden Optimierung auf Profilebene und verlagern Ausnahmen auf Domänen- oder Routenekbene, um den operativen Auswirkungsbereich zu verringern.

Grundlegendes zu WAF-Protokollen

Der Zweck der WAF-Logs besteht darin, jede Anfrage anzuzeigen, die von der WAF erkannt oder blockiert wird. Die Protokolle sammeln alle bewerteten Anfragen, die die WAF abgleicht oder blockiert. Wenn du bemerkst, dass die WAF eine Anfrage blockiert, obwohl sie nicht blockiert werden sollte (ein False Positive), kannst du mehrere Maßnahmen ergreifen.

Nehmen Sie zunächst eine Eingrenzung vor, und suchen Sie nach der relevanten Anforderung. Du kannst eine benutzerdefinierte Antwortnachricht konfigurieren , die das Feld trackingReference einschließt, sodass du das Ereignis leicht identifizieren und eine Logabfrage für diesen spezifischen Wert durchführen kannst. 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 die false positives beheben.

Angenommen, du hast legitimen Datenverkehr, der den String 1=1 enthält, den du durch dein WAF schicken möchtest. 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 Anfragen zu finden, die die WAF in den letzten 24 Stunden blockiert hat.

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 942110 die Regel-ID ruleName. Wenn du die Regel-ID kennst, kannst du in das offizielle OWASP ModSecurity Core Rule Set Repository gehen und nach dieser Regel-ID suchen, um den Code zu überprüfen und genau zu verstehen, worauf diese Regel passt.

Wenn Sie das Feld action überprüfen, sehen Sie, dass diese Regel so eingestellt ist, dass Anfragen beim Matching 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. 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.

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 ist, dass die WAF die Match-Variable, die Sie für den Ausschluss auswählen, für diese Anforderung nicht mehr überprüft. Sie können spezifische Anfrage-Header, Anfragecookies, Abfragestring-Argumente oder Request-Body-Post-Argumente wählen, um auszuschließen, wenn eine bestimmte Bedingung erfüllt ist, anstatt die gesamte Anfrage von der Inspektion 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. Zum Beispiel könnte diese Bedingung ein Problem sein, wenn 1=1 es sich um eine gültige Anfrage im Body für eine bestimmte Webanwendung handelt, aber nicht für andere unter derselben 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 mithilfe von PowerShell, der Azure CLI, der REST-API, Bicep, Azure Resource Manager Vorlagen oder dem Azure Portal konfigurieren.

  • Ausschlüsse auf Regelebene: Die Anwendung von Ausschlüssen auf Regelebene bedeutet, dass die angegebenen Ausschlüsse nicht für diese einzelne Regel gelten. Alle anderen Regeln im Regelwerk analysieren die Anfrage weiterhin. Diese Ebene bietet die größte Granularität für Ausschlüsse. Verwenden Sie diese Informationen, um den verwalteten Regelsatz anhand der Informationen aus den WAF-Protokollen gezielt anzupassen, wenn Sie ein Ereignis untersuchen.
  • Ausschlüsse auf Regelgruppenebene: Die Anwendung von Ausschlüssen auf Regelgruppenebene bedeutet, dass die angegebenen Ausschlüsse nicht für diese spezifische Menge von Regeltypen gelten. Zum Beispiel zeigt die Auswahl von SQLI als ausgeschlossene Regelgruppe, dass die definierten Anfrageausschlüsse von keiner der SQLI-spezifischen Regeln überprüft werden. Regeln in anderen Gruppen, wie PHP,RFI oder XSS, überprüfen die Anfrage weiterhin. 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 auf keine der in diesem Regelsatz verfügbaren Sicherheitsregeln gelten. Dieser Ausschluss ist umfassend, daher sollten Sie ihn mit Bedacht nutzen.

In diesem Beispiel wenden Sie einen Ausschluss auf die präziseste Ebene an, indem Sie ihn auf eine einzelne Regel anwenden. 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 mit Ausschlussregeln.

Screenshot, der den Ausschluss für eine bestimmte Regel zeigt.

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 einigen Fällen, in denen Cookies deaktiviert sind, wird dieses Token auch als POST-Anfrage-Argument ü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 bei einem Feldnamen (Selector) bedeuten, dass der Wert nicht mehr vom 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, der den Ausschluss einer Regel aus einem Regelsatz zeigt.

WAF-Aktionen ändern

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 in die Aktion Log bei Regel 942110 geändert. Durch diese Aktion wird die Anforderung von der WAF protokolliert, und die gleiche Anforderung wird weiterhin gegenüber den verbleibenden Regeln mit niedrigerer Priorität ausgewertet.

Screenshot mit WAF-Aktionen.

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 mit einem Protokoll, das mehrere Regelübereinstimmungen anzeigt.

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 Sie benutzerdefinierte WAF-Regeln

Nachdem du erkannt hast, was ein WAF-Regelmatch verursacht, verwende benutzerdefinierte Regeln, um anzupassen, wie das WAF auf das Ereignis reagiert. 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 die höchstmögliche Genauigkeit erreichen, 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, der ein Protokoll zeigt.

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 beschränkt haben, können Sie sie im Azure-Portal deaktivieren. Weitere Informationen finden Sie unter Anpassen von Azure Web Application Firewall-Regeln mithilfe des Azure-Portals.

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).

Das Deaktivieren einer Regel betrifft den gesamten Datenverkehr, der innerhalb des Geltungsbereichs dieser Richtlinienzuordnung ausgewertet wird. Wenn Sie eine Regel deaktivieren, könnten Sie Schwachstellen offen lassen, ohne Schutz oder Erkennung für anderen Verkehr, der unter denselben Umfang fällt.

Wenn Sie Azure PowerShell zum Deaktivieren einer verwalteten Regel verwenden möchten, lesen Sie die Dokumentation zum PSAzureManagedRuleOverride-Objekt. Wenn Sie die Azure CLI verwenden möchten, lesen Sie die Dokumentation az network front-door waf-policy managed-rules override.

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.

Finden Sie Anforderungsattributnamen

In diesem Beispiel heißt das Feld, auf dem Sie die Zeichenkette 1=1 eingegeben haben comment. Diese Daten kommen in den Kern einer POST-Anfrage.

Screenshot, der den Inhalt einer Fiddler-Anforderung zeigt.

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 mit einer Ausschlussregel.

Sie können auch die Firewall-Protokolle prüfen, um die Informationen zu erhalten, die Sie zur Ausschlussliste hinzufügen müssen. Informationen zum Aktivieren der Protokollierung finden Sie unter Monitor-Metriken und -Protokolle in Azure Front Door.

Überprüfen Sie das Firewallprotokoll in der Datei PT1H.json für die Stunde, in der die zu überprüfende 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 in der Datei PT1H.json für die Stunde, in der die zu überprüfende 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 deinem Wissen darüber, wie die von Azure verwalteten Regelsätze funktionieren, weißt du, dass die Regel mit den action: Block Eigenschaftsblöcken basierend auf den Daten im Request-Body übereinstimmt. (Weitere Informationen finden Sie unter Azure Web Application Firewall in Azure Front Door.) Sie sehen in den Details, dass es einem Muster (1=1) entspricht und das Feld heißt comment. Führen Sie die gleichen Schritte wie zuvor aus, um den „Request body post args name“, der comment enthält, auszuschließen.

Anforderungsheadernamen finden

Fiddler ist ein nützliches Tool, um Headernamen von Anfragen zu finden. 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, der den Header einer Fiddler-Anforderung zeigt.

Eine weitere Möglichkeit zum Anzeigen von Anforderungs- und Antwortheadern besteht darin, in den Entwicklertools Ihres Browsers zu suchen, 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 mit einer Anforderung zum Untersuchen des Netzwerks.

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.

Beim Optimieren von Anfragen in Bereitstellungen mit gemischtem Geltungsbereich erfassen Sie den effektiven Richtlinienbereich in Ihren Incident-Notizen (Profil, Domäne oder Route). Dies hilft, zukünftige Rückschritte zu verhindern, wenn Teams Assoziationen hinzufügen oder verändern.

Warnung

Beim Zuweisen eines neuen verwalteten Regelsets zu einer WAF-Richtlinie werden alle vorherigen Anpassungen der bestehenden verwalteten Regelsätze wie Regelzustand, Regelaktionen und Regellevel-Ausschlüsse auf die Standardwerte des neuen verwalteten Regelsets zurückgesetzt. Allerdings bleiben alle benutzerdefinierten Regeln und Richtlinieneinstellungen während der neuen Regelsatzzuweisung unverändert.

Verwandte Inhalte

Nächste Schritte

  • Last updated on