Dostrajanie usługi Azure Web Application Firewall dla usługi Azure Front Door

Domyślny zestaw reguł zarządzanych przez firmę Microsoft jest oparty na zestawie reguł OWASP Core i zawiera reguły zbierania danych analizy zagrożeń firmy Microsoft.

Często oczekuje się, że reguły zapory aplikacji internetowej (WAF) muszą być dostosowane do określonych potrzeb aplikacji lub organizacji korzystających z zapory aplikacji internetowej. Organizacje często osiągają dostrajanie, wykonując jedną z następujących czynności:

  • Definiowanie wykluczeń reguł.
  • Tworzenie reguł niestandardowych.
  • Wyłączanie reguł, które mogą powodować problemy lub fałszywie dodatnie.

W tym artykule opisano, co można zrobić, jeśli żądania, które powinny zostać przekazane przez zaporę aplikacji internetowej, są blokowane.

Uwaga

Zestaw reguł zarządzanych przez firmę Microsoft nie jest dostępny dla jednostki SKU usługi Azure Front Door w warstwie Standardowa. Aby uzyskać więcej informacji na temat różnych jednostek SKU warstwy, zobacz Porównanie funkcji między warstwami.

Przeczytaj omówienie zapory aplikacji internetowej usługi Azure Front Door i zasady zapory aplikacji internetowej dla dokumentów usługi Azure Front Door. Ponadto włącz monitorowanie i rejestrowanie zapory aplikacji internetowej. W tych artykułach wyjaśniono, jak działają funkcje zapory aplikacji internetowej, jak działają zestawy reguł zapory aplikacji internetowej oraz jak uzyskiwać dostęp do dzienników zapory aplikacji internetowej.

Omówienie dzienników zapory aplikacji internetowej

Celem dzienników zapory aplikacji internetowej jest wyświetlenie każdego żądania zgodnego lub zablokowanego przez zaporę aplikacji internetowej. Jest to kolekcja wszystkich ocenianych żądań, które są zgodne lub zablokowane. Jeśli zauważysz, że zapora aplikacji internetowej blokuje żądanie, którego nie powinno (wynik fałszywie dodatni), możesz wykonać kilka czynności.

Najpierw zawęź i znajdź konkretne żądanie. Możesz skonfigurować niestandardowy komunikat odpowiedzi, aby uwzględnić trackingReference pole, aby łatwo zidentyfikować zdarzenie i wykonać zapytanie dziennika dotyczące tej konkretnej wartości. Przejrzyj dzienniki, aby znaleźć określony identyfikator URI, znacznik czasu lub adres IP klienta żądania. Po znalezieniu powiązanych wpisów dziennika można wykonywać działania w przypadku wyników fałszywie dodatnich.

Załóżmy na przykład, że masz legalny ruch zawierający ciąg 1=1 , który chcesz przekazać za pośrednictwem zapory aplikacji internetowej. Oto jak wygląda żądanie:

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

W przypadku próby żądania zapora aplikacji internetowej blokuje ruch zawierający 1=1 ciąg w dowolnym parametrze lub polu. Ten ciąg jest często skojarzony z atakiem polegającym na wstrzyknięciu kodu SQL. Możesz przejrzeć dzienniki i zobaczyć znacznik czasu żądania oraz reguły, które zostały zablokowane lub dopasowane.

W poniższym przykładzie przedstawiono wpis dziennika, który został wygenerowany na podstawie dopasowania reguły. Następujące zapytanie usługi Log Analytics służy do znajdowania żądań, które zostały zablokowane w ciągu ostatnich 24 godzin.

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

requestUri W polu widać, że żądanie zostało złożone /api/Feedbacks/ specjalnie. Dalej znajdź identyfikator 942110 reguły w ruleName polu. Znając identyfikator reguły, możesz przejść do oficjalnego repozytorium zestawu reguł OWASP ModSecurity Core i wyszukać według tego identyfikatora reguły, aby przejrzeć jego kod i zrozumieć dokładnie, co ta reguła pasuje.

Następnie sprawdzając action pole, możesz zobaczyć, że ta reguła jest ustawiona na blokowanie żądań po dopasowaniu. Możesz potwierdzić, że żądanie zostało zablokowane przez zaporę aplikacji internetowej, ponieważ policyMode ustawiono wartość prevention.

Teraz sprawdź informacje w details polu. To pole umożliwia wyświetlanie matchVariableName informacji i matchVariableValue . Ta reguła została wyzwolona, ponieważ ktoś wprowadza dane wejściowe 1=1 w comment polu aplikacji internetowej.

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

Istnieje również wartość sprawdzania dzienników dostępu, aby rozwinąć swoją wiedzę na temat danego zdarzenia zapory aplikacji internetowej. Następnie przejrzyj dziennik wygenerowany jako odpowiedź na poprzednie zdarzenie.

Te dzienniki są powiązane, ponieważ trackingReference wartość jest taka sama. Wśród różnych pól, które zapewniają ogólne informacje, takie jak userAgent i clientIP, zwróć uwagę na httpStatusCode pola i httpStatusDetails . W tym miejscu widać, że klient otrzymał odpowiedź HTTP 403, która potwierdza, że to żądanie zostało odrzucone i zablokowane.

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

Rozpoznawanie wyników fałszywie dodatnich

Aby podjąć świadomą decyzję o obsłudze wyników fałszywie dodatnich, ważne jest zapoznanie się z technologiami używanymi przez aplikację. Załóżmy na przykład, że nie ma serwera SQL w stosie technologii i otrzymujesz fałszywie dodatnie wyniki związane z tymi regułami. Wyłączenie tych reguł niekoniecznie osłabia bezpieczeństwo.

Dzięki tym informacjom i wiedzy, że reguła 942110 jest zgodna 1=1 z ciągiem w przykładzie, możesz wykonać kilka czynności, aby uniemożliwić zablokowanie tego uzasadnionego żądania:

Napiwek

Po wybraniu podejścia do zezwalania na uzasadnione żądania za pośrednictwem zapory aplikacji internetowej spróbuj ustawić je tak wąskie, jak to możliwe. Na przykład lepiej użyć listy wykluczeń niż całkowicie wyłączyć regułę.

Korzystanie z list wykluczeń

Jedną z zalet korzystania z listy wykluczeń jest to, że tylko zmienna dopasowania wybrana do wykluczenia nie będzie już sprawdzana dla danego żądania. Oznacza to, że można wybrać między określonymi nagłówkami żądań, plikami cookie żądania, argumentami ciągu zapytania lub argumentami treści żądania, które mają zostać wykluczone, jeśli zostanie spełniony określony warunek, w przeciwieństwie do wykluczenia całego żądania z inspekcji. Pozostałe nieokreślone zmienne żądania są zwykle sprawdzane.

Wykluczenia są ustawieniem globalnym. Skonfigurowane wykluczenie dotyczy całego ruchu przechodzącego przez zaporę aplikacji internetowej, a nie tylko określonej aplikacji internetowej lub identyfikatora URI. Na przykład może to być problemem, jeśli 1=1 jest prawidłowym żądaniem w treści określonej aplikacji internetowej, ale nie dla innych w ramach tych samych zasad zapory aplikacji internetowej.

Jeśli warto używać różnych list wykluczeń dla różnych aplikacji, rozważ użycie różnych zasad zapory aplikacji internetowej dla każdej aplikacji i zastosowanie ich do frontonu każdej aplikacji.

Podczas konfigurowania list wykluczeń dla reguł zarządzanych można wykluczyć:

  • Wszystkie reguły w zestawie reguł.
  • Wszystkie reguły w grupie reguł.
  • Pojedyncza reguła.

Listę wykluczeń można skonfigurować przy użyciu programu PowerShell, interfejsu wiersza polecenia platformy Azure, interfejsu API REST, szablonów Bicep, usługi Azure Resource Manager lub witryny Azure Portal.

  • Wykluczenia na poziomie reguły: stosowanie wykluczeń na poziomie reguły oznacza, że określone wykluczenia nie będą analizowane tylko względem tej pojedynczej reguły. Będzie ona nadal analizowana przez wszystkie inne reguły w zestawie reguł. Jest to najbardziej szczegółowy poziom wykluczeń. Można go użyć, aby dostosować zestaw reguł zarządzanych na podstawie informacji, które można znaleźć w dziennikach zapory aplikacji internetowej podczas rozwiązywania problemów ze zdarzeniem.
  • Wykluczenia na poziomie grupy reguł: stosowanie wykluczeń na poziomie grupy reguł oznacza, że określone wykluczenia nie będą analizowane względem tego określonego zestawu typów reguł. Na przykład wybranie interfejsu SQLI jako wykluczonej grupy reguł oznacza, że zdefiniowane wykluczenia żądań nie będą sprawdzane przez żadną regułę specyficzną dla języka SQLI. Nadal będzie on sprawdzany przez reguły w innych grupach, takich jak PHP, RFI lub XSS. Ten typ wykluczenia może być przydatny, gdy masz pewność, że aplikacja nie jest podatna na określone typy ataków. Na przykład aplikacja, która nie ma żadnych baz danych SQL, może wykluczyć wszystkie reguły SQLI bez szkodliwego wpływu na jej poziom zabezpieczeń.
  • Wykluczenia na poziomie zestawu reguł: stosowanie wykluczeń na poziomie zestawu reguł oznacza, że określone wykluczenia nie będą analizowane względem żadnych reguł zabezpieczeń dostępnych w tym zestawie reguł. To wykluczenie jest kompleksowe, dlatego należy go dokładnie użyć.

W tym przykładzie wykonasz wykluczenie na najbardziej szczegółowym poziomie, stosując wykluczenie do pojedynczej reguły. Chcesz wykluczyć zmienną dopasowania Treść żądania, publikując nazwę args zawierającą commentelement . Szczegóły zmiennej dopasowania są widoczne w dzienniku zapory: "matchVariableName": "PostParamValue:comment". Atrybut to comment. Możesz również znaleźć tę nazwę atrybutu na kilka innych sposobów. Aby uzyskać więcej informacji, zobacz Znajdowanie nazw atrybutów żądania.

Zrzut ekranu przedstawiający reguły wykluczania.

Zrzut ekranu przedstawiający wykluczenie reguły dla określonej reguły.

Czasami istnieją przypadki, w których określone parametry są przekazywane do zapory aplikacji internetowej w sposób, który może nie być intuicyjny. Na przykład token jest przekazywany podczas uwierzytelniania przy użyciu identyfikatora Entra firmy Microsoft. Token __RequestVerificationToken jest zwykle przekazywany jako plik cookie żądania.

W niektórych przypadkach, gdy pliki cookie są wyłączone, token jest również przekazywany jako argument post żądania. Z tego powodu, aby rozwiązać problem z fałszywie dodatnimi tokenami firmy Microsoft Entra, należy upewnić się, że __RequestVerificationToken jest on dodawany do listy wykluczeń dla elementów RequestCookieNames i RequestBodyPostArgsNames.

Wykluczenia w nazwie pola (Selektor) oznaczają, że wartość nie będzie już obliczana przez zaporę aplikacji internetowej. Sama nazwa pola jest nadal oceniana i w rzadkich przypadkach może być zgodna z regułą zapory aplikacji internetowej i wyzwolić akcję.

Zrzut ekranu przedstawiający wykluczenie reguły dla zestawu reguł.

Zmienianie akcji zapory aplikacji internetowej

Innym sposobem obsługi zachowania reguł zapory aplikacji internetowej jest wybranie akcji, która jest wykonywana, gdy żądanie pasuje do warunków reguły. Dostępne akcje to Zezwalaj, Blokuj, Dzienniki i Przekierowywanie.

W tym przykładzie domyślna akcja Blokuj została zmieniona na akcję Dziennik dla reguły 942110. Ta akcja powoduje, że zapora aplikacji internetowej rejestruje żądanie i kontynuuje ocenianie tego samego żądania względem pozostałych reguł o niższym priorytcie.

Zrzut ekranu przedstawiający akcje zapory aplikacji internetowej.

Po wykonaniu tego samego żądania można odwołać się z powrotem do dzienników i sprawdzić, czy to żądanie było zgodne z identyfikatorem reguły 942110. Pole action_s wskazuje teraz wartość Log zamiast Blokuj. Zapytanie dziennika zostało następnie rozwinięte, aby uwzględnić informacje, trackingReference_s aby zobaczyć, co jeszcze się stało z tym żądaniem.

Zrzut ekranu przedstawiający dziennik przedstawiający wiele dopasowań reguł.

Teraz po przetworzeniu identyfikatora reguły 942110 jest widoczna inna reguła SQLI zgodna z milisekundami. To samo żądanie jest zgodne z identyfikatorem reguły 942310 i tym razem został wyzwolony domyślny blok akcji.

Kolejną zaletą korzystania z akcji Dziennik podczas dostrajania zapory aplikacji internetowej lub rozwiązywania problemów jest możliwość określenia, czy wiele reguł w określonej grupie reguł jest pasujących i blokujących określone żądanie. Następnie możesz utworzyć wykluczenia na odpowiednim poziomie, czyli na poziomie reguły lub grupy reguł.

Używanie reguł niestandardowych

Po zidentyfikowaniu przyczyn dopasowania reguły zapory aplikacji internetowej możesz użyć reguł niestandardowych, aby dostosować sposób reagowania zapory aplikacji internetowej na zdarzenie. Reguły niestandardowe są przetwarzane przed regułami zarządzanymi. Mogą zawierać więcej niż jeden warunek, a ich akcje mogą być dozwolone, odmowy, dziennika lub przekierowania.

Ostrzeżenie

Gdy żądanie jest zgodne z regułą niestandardową, aparat zapory aplikacji internetowej przestaje przetwarzać żądanie. Reguły zarządzane nie będą przetwarzane dla tego żądania i żadne inne reguły niestandardowe o niższym priorytcie nie będą przetwarzane.

W poniższym przykładzie przedstawiono regułę niestandardową z dwoma warunkami. Pierwszy warunek wyszukuje comment wartość w treści żądania. Drugi warunek szuka /api/Feedbacks/ wartości w identyfikatorze URI żądania.

Korzystając z reguły niestandardowej, można być najbardziej szczegółowymi, dzięki czemu można dostosować reguły zapory aplikacji internetowej i poradzić sobie z fałszywie dodatnimi. W takim przypadku nie podejmujesz akcji tylko na comment podstawie wartości treści żądania, która może istnieć w wielu witrynach lub aplikacjach w ramach tych samych zasad zapory aplikacji internetowej.

Jeśli uwzględnisz inny warunek, który będzie również zgodny z określonym identyfikatorem URI /api/Feedbacks/żądania, upewnij się, że ta reguła niestandardowa jest naprawdę stosowana do tego jawnego przypadku użycia, który został zweryfikowany. W ten sposób ten sam atak, jeśli jest wykonywany w różnych warunkach, jest nadal sprawdzany i blokowany przez aparat zapory aplikacji internetowej.

Zrzut ekranu przedstawiający dziennik.

Podczas eksplorowania dziennika widać, że ruleName_s pole zawiera nazwę nadaną regule redirectcommentniestandardowej . action_s W polu widać, że akcja Przekierowanie została podjęta dla tego zdarzenia. details_matches_s W polu można zobaczyć szczegóły dotyczące obu warunków, które zostały dopasowane.

Wyłączanie reguł

Innym sposobem obejścia wyników fałszywie dodatnich jest wyłączenie reguły zgodnej z danymi wejściowymi, które zapora aplikacji internetowej uważała za złośliwą. Ponieważ przeanalizowano dzienniki zapory aplikacji internetowej i zawęziono regułę do 942110, możesz ją wyłączyć w witrynie Azure Portal. Aby uzyskać więcej informacji, zobacz Dostosowywanie reguł zapory aplikacji internetowej platformy Azure przy użyciu witryny Azure Portal.

Wyłączenie reguły jest korzyścią, jeśli masz pewność, że wszystkie żądania spełniające ten konkretny warunek są uzasadnionymi żądaniami lub gdy masz pewność, że reguła nie ma zastosowania do środowiska (np. wyłączenie reguły iniekcji SQL, ponieważ masz zaplecza inne niż SQL).

Wyłączenie reguły jest ustawieniem globalnym, które ma zastosowanie do wszystkich hostów frontonu skojarzonych z zasadami zapory aplikacji internetowej. Jeśli zdecydujesz się wyłączyć regułę, możesz pozostawić luki w zabezpieczeniach ujawnione bez ochrony lub wykrywania dla innych hostów frontonu skojarzonych z zasadami zapory aplikacji internetowej.

Jeśli chcesz użyć programu Azure PowerShell do wyłączenia reguły zarządzanej, zapoznaj się z dokumentacją PSAzureManagedRuleOverride obiektu. Jeśli chcesz użyć interfejsu wiersza polecenia platformy Azure, zapoznaj się z dokumentacją az network front-door waf-policy managed-rules override .

Zrzut ekranu przedstawiający reguły zapory aplikacji internetowej.

Napiwek

Dokumentowanie wszelkich zmian w zasadach zapory aplikacji internetowej. Dołącz przykładowe żądania, aby zilustrować wykrywanie fałszywie dodatnie. Wyjaśnij, dlaczego dodano regułę niestandardową, wyłączono regułę lub zestaw reguł albo dodano wyjątek. Jeśli przeprojektujesz aplikację w przyszłości, może być konieczne sprawdzenie, czy zmiany są nadal prawidłowe. Możesz też przeprowadzić inspekcję lub uzasadnić, dlaczego ponownie skonfigurowano zasady zapory aplikacji internetowej z ustawień domyślnych.

Znajdowanie pól żądań

Korzystając z serwera proxy przeglądarki, takiego jak Fiddler, można sprawdzić poszczególne żądania i określić, jakie konkretne pola strony internetowej są wywoływane. Ta technika jest przydatna, gdy trzeba wykluczyć niektóre pola z inspekcji przy użyciu list wykluczeń w zaporze aplikacji internetowej.

Znajdowanie nazw atrybutów żądania

W tym przykładzie pole, w którym 1=1 wprowadzono ciąg, nosi nazwę comment. Te dane zostały przekazane w treści żądania POST.

Zrzut ekranu przedstawiający treść żądania Fiddler.

To pole można wykluczyć. Aby dowiedzieć się więcej na temat list wykluczeń, zobacz Listy wykluczeń zapory aplikacji internetowej. W tym przypadku można wykluczyć ocenę, konfigurując następujące wykluczenie:

Zrzut ekranu przedstawiający regułę wykluczania.

Możesz również sprawdzić dzienniki zapory, aby uzyskać informacje, aby zobaczyć, co należy dodać do listy wykluczeń. Aby włączyć rejestrowanie, zobacz Monitorowanie metryk i dzienników w usłudze Azure Front Door.

Sprawdź dziennik zapory w PT1H.json pliku o godzinie, w której wystąpiło żądanie, które chcesz sprawdzić. Pliki PT1H.json są dostępne w kontenerach konta magazynu, w których FrontDoorWebApplicationFirewallLog są przechowywane dzienniki diagnostyczne i FrontDoorAccessLog .

Sprawdź dziennik zapory w PT1H.json pliku o godzinie, w której wystąpiło żądanie, które chcesz sprawdzić. Pliki PT1H.json są dostępne w kontenerach konta magazynu, w których FrontdoorWebApplicationFirewallLog są przechowywane dzienniki diagnostyczne i FrontdoorAccessLog .

W tym przykładzie można zobaczyć regułę, która zablokowała żądanie (z tym samym odwołaniem do transakcji) i które wystąpiły w tym samym czasie.

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

Mając wiedzę na temat działania zestawów reguł zarządzanych przez platformę Azure, wiesz, że reguła z action: Block właściwością blokuje się na podstawie danych dopasowanych w treści żądania. (Aby uzyskać więcej informacji, zobacz Usługa Azure Web Application Firewall w usłudze Azure Front Door). Możesz zobaczyć w szczegółach, że pasuje do wzorca (1=1), a pole ma nazwę comment. Wykonaj te same poprzednie kroki, aby wykluczyć treść żądania, publikując nazwę args zawierającą commentelement .

Znajdowanie nazw nagłówków żądania

Fiddler to przydatne narzędzie do znajdowania nazw nagłówków żądań. Poniższy zrzut ekranu przedstawia nagłówki dla tego żądania GET, które obejmują Content-Type i User-Agent. Nagłówki żądań umożliwiają również tworzenie wykluczeń i reguł niestandardowych w zaporze aplikacji internetowej.

Zrzut ekranu przedstawiający nagłówek żądania Fiddler.

Innym sposobem wyświetlania nagłówków żądań i odpowiedzi jest zapoznanie się z narzędziami deweloperów przeglądarki, takimi jak Microsoft Edge lub Chrome. Możesz wybrać F12 lub kliknąć prawym przyciskiem myszy pozycję Sprawdź>narzędzia deweloperskie. Wybierz kartę Sieć. Załaduj stronę internetową i wybierz żądanie, które chcesz sprawdzić.

Zrzut ekranu przedstawiający żądanie inspektora sieci.

Jeśli żądanie zawiera pliki cookie, wybierz kartę Pliki cookie , aby wyświetlić je w programie Fiddler. Informacje o plikach cookie mogą również służyć do tworzenia wykluczeń lub reguł niestandardowych w zaporze aplikacji internetowej.

Reguła oceniania anomalii

Jeśli podczas procesu dostrajania zapory aplikacji internetowej zobaczysz identyfikator reguły 949110, jego obecność wskazuje, że żądanie zostało zablokowane przez proces oceniania anomalii.

Przejrzyj inne wpisy dziennika zapory aplikacji internetowej dla tego samego żądania, wyszukując wpisy dziennika z tym samym odwołaniem do śledzenia. Przyjrzyj się poszczególnym regułom, które zostały wyzwolone. Dostosuj każdą regułę, postępując zgodnie ze wskazówkami w tym artykule.

Następne kroki