Udostępnij przez

Dostosowywanie zapory 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 generować fałszywe alarmy.

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

Uwaga

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

Przeczytaj omówienie zapory aplikacji internetowej dla usługi Azure Front Door i dokumenty dotyczące zasad zapory aplikacji internetowej dla usługi Azure Front Door. Ponadto włącz monitorowanie i rejestrowanie dla zapory aplikacji internetowej (WAF). 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.

Zrozumienie 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 (WAF) blokuje żądanie, którego nie powinna (fałszywy alarm), możesz wykonać kilka czynności.

Najpierw zawęź i znajdź konkretne żądanie. Możesz skonfigurować niestandardowy komunikat odpowiedzi, aby uwzględnić pole trackingReference, co umożliwi łatwe zidentyfikowanie zdarzenia i wykonanie wyszukiwania w dzienniku dotyczącego 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 przepuścić przez zaporę sieciową aplikacji (WAF). 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

Jeśli spróbujesz wykonać żądanie, zapora aplikacji internetowej blokuje ruch zawierający ciąg 1=1 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 zablokowały lub odpowiadały.

W poniższym przykładzie przedstawiono wpis do dziennika, który został wygenerowany w wyniku dopasowania do 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'

W polu requestUri widać, że żądanie zostało złożone specjalnie do /api/Feedbacks/. 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 dokładnie zrozumieć, na co ta reguła jest dopasowana.

Następnie, sprawdzając pole action, zobaczysz, że ta reguła jest ustawiona na blokowanie żądań po dopasowaniu. Możesz potwierdzić, że żądanie zostało zablokowane przez WAF, ponieważ policyMode jest ustawione na 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\""
        }
    }
}

Sprawdzanie dzienników dostępu ma również wartość, gdy chcemy poszerzyć swoją wiedzę na temat danego zdarzenia WAF. Następnie przejrzyj dziennik wygenerowany jako odpowiedź na poprzednie zdarzenie.

Możesz zauważyć, że te dzienniki są powiązane, ponieważ wartość trackingReference jest taka sama. Wśród różnych pól, które zapewniają ogólne informacje, takie jak userAgent i clientIP, zwróć uwagę na pola httpStatusCode 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 oraz wiedzy, że reguła 942110 jest zgodna z ciągiem w przykładzie 1=1, możesz wykonać kilka czynności, aby uniemożliwić zablokowanie tego uzasadnionego żądanie.

Napiwek

Po wybraniu podejścia, które umożliwia przepuszczenie uzasadnionych żądań przez zaporę aplikacji internetowej, spróbuj wybrać 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 WAF, a nie jest ograniczone do 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 tej samej polityki WAF.

Jeśli warto używać różnych list wykluczeń dla różnych aplikacji, rozważ używanie różnych zasad zapory aplikacji internetowej dla każdej aplikacji i zastosowanie ich do interfejsu użytkownika 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żesz go użyć, aby dostosować zestaw zarządzanych reguł, opierając się na informacjach, które znajdziesz w dziennikach zapory aplikacji 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 nazwa parametrów posta w zasobie żądania zawierającą comment. Szczegóły zmiennej dopasowania są widoczne w logu 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 zdarzają się sytuacje, w których określone parametry są przekazywane do zapory aplikacji internetowej w sposób, który może wydawać się nieintuicyjny. 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 dodawany do listy wykluczeń zarówno dla RequestCookieNames i RequestBodyPostArgsNames.

Wykluczenia w nazwie pola (Selektor) oznaczają, że wartość nie będzie już oceniana przez WAF (Web Application Firewall). Sama nazwa pola ciągle podlega ocenie i w rzadkich przypadkach może być zgodna z regułą zapory sieciowej i wyzwolić akcję.

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

Zmień działania zapory aplikacji internetowej

Innym sposobem zarządzania zachowaniem reguł WAF jest wybranie akcji podejmowanej, gdy żądanie pasuje do warunków reguły. Dostępne akcje to Zezwalaj, Blokuj, Rejestruj i Przekierowuj.

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

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 Log zamiast Blok. 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 możesz zobaczyć dopasowanie innej reguły SQLI, które występuje milisekundy po przetworzeniu reguły o identyfikatorze 942110. To samo żądanie jest zgodne z identyfikatorem reguły 942310 i tym razem została wyzwolona domyślna akcja zablokowania.

Kolejną zaletą korzystania z działania Dziennik podczas dostrajania zapory aplikacji internetowej lub rozwiązywania problemów jest to, że można określić, czy wiele reguł w danej grupie reguł pasuje i blokuje dane żądanie. Następnie możesz utworzyć wykluczenia na odpowiednim poziomie, czyli na poziomie reguły lub grupy reguł.

Użyj reguł niestandardowych

Po zidentyfikowaniu przyczyn dopasowania reguły WAF możesz użyć reguł niestandardowych, aby dostosować sposób, w jaki WAF reaguje na to 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ą, silnik WAF 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.

Poniższy przykład pokazuje niestandardową regułę z dwoma warunkami. Pierwszy warunek sprawdza wartość comment w treści żądania. Drugi warunek szuka /api/Feedbacks/ wartości w identyfikatorze URI żądania.

Korzystając z reguły niestandardowej, możesz być najbardziej precyzyjny, co pozwala na precyzyjne dostosowanie reguł zapory aplikacji webowej i poradzić sobie z fałszywymi alarmami. W takim przypadku nie podejmujesz działań tylko na comment podstawie wartości treści żądania, która może istnieć w wielu witrynach lub aplikacjach w ramach tej samej polityki WAF.

Jeśli uwzględnisz inny warunek zgodny z określonym identyfikatorem URI żądania /api/Feedbacks/, możesz upewnić się, że ta reguła niestandardowa faktycznie stosuje się 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, nadal jest sprawdzany i blokowany przez mechanizm WAF.

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. W polu details_matches_s można zobaczyć szczegóły dopasowania obu warunków.

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ż przeanalizowałeś dzienniki WAF i zawęziłeś regułę do 942110, możesz ją wyłączyć w portalu Azure. 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 front-end skojarzonych z polityką zapory aplikacji internetowej. Jeśli zdecydujesz się wyłączyć regułę, możesz pozostawić luki w zabezpieczeniach narażone bez ochrony lub wykrywania dla innych hostów front-endowych skojarzonych z polityką 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 .

Napiwek

Dokumentuj wszelkie zmiany w zasadach zapory aplikacji internetowej. Dołącz przykładowe żądania, aby zilustrować wykrywanie fałszywych alarmów. 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ż zostać poddany audytowi lub musisz 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 WAF.

Znajdowanie nazw atrybutów żądania

W tym przykładzie pole, w którym wprowadzono ciąg 1=1, 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 dowiedzieć się, 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 pliku PT1H.json dla godziny, o której wystąpiło żądanie, które chcesz sprawdzić. Pliki PT1H.json są dostępne w kontenerach konta magazynu, gdzie są przechowywane dzienniki diagnostyczne FrontDoorWebApplicationFirewallLog i FrontDoorAccessLog.

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

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 posiadająca właściwość action: Block blokuje 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ć post args name treść żądania, która zawiera comment.

Znajdź nazwy 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. Możesz również użyć nagłówków żądań do ustalania wykluczeń i niestandardowych reguł w WAF.

Zrzut ekranu pokazują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 WAF.

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.

Przeszukaj inne wpisy dziennika WAF 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 aktywowane. Dostosuj każdą regułę, postępując zgodnie ze wskazówkami w tym artykule.

Ostrzeżenie

Podczas przypisywania nowego zarządzanego zestawu reguł do zasad zapory aplikacji internetowej wszystkie poprzednie dostosowania z istniejących zarządzanych zestawów reguł, obejmujące stan reguły, akcje reguły i wykluczenia na poziomie reguły, zostaną zresetowane do wartości domyślnych nowego zarządzanego zestawu reguł. Jednak wszelkie niestandardowe reguły i ustawienia zasad pozostaną nienaruszone podczas nowego przypisania zestawu reguł.

Następne kroki

  • Last updated on