Aplikacja (warstwa 7) ochrony DDoS

Dotyczy do: ✔️ Application Gateway v2 ✔️ Front Door Premium

Azure Web Application Firewall (WAF) zawiera kilka mechanizmów obronnych, które pomagają zapobiegać atakom DDoS (DDoS). Ataki DDoS mogą dotyczyć zarówno warstwy sieciowej (L3/L4), jak i warstwy aplikacji (L7). Azure DDoS Protection chroni Cię przed dużymi wolumetrycznymi atakami na warstwę sieciową. Azure WAF, działający na poziomie warstwy 7, chroni aplikacje internetowe przed atakami DDoS warstwy L7, takimi jak zalewanie żądaniami HTTP. Te zabezpieczenia razem zapobiegają atakującym dotarciu do Twojej aplikacji i wpływaniu na jej dostępność oraz wydajność.

Ataki na warstwę aplikacji są tanie w uruchomieniu i trudne do odróżnienia od legalnego ruchu: każde żądanie wygląda na ważne samo w sobie, a tylko łączna szybkość, dystrybucja i skład klientów ujawniają atak. Skuteczna obrona L7 opiera się więc mniej na pojedynczej kontroli, a bardziej na warstwowej konfiguracji już istniejącej przed rozpoczęciem ataku.

Wybierz warstwy obronne

Użyj poniższego modelu podczas planowania ochrony przed atakami DDoS warstwy 7. Każda warstwa obsługuje ruch, którego nie obsługuje warstwa znajdująca się nad nią.

Lista kontrolna konfiguracji bazowej

Wykonaj te kroki, zanim zostaniesz zaatakowany. Dostosuj je do wymagań aplikacji.

1. Wdróż usługę Azure WAF za pomocą Azure Front Door Premium lub Application Gateway WAF v2, aby zapewnić ochronę przed atakami na warstwę aplikacji L7.
2. Przełącz politykę WAF na tryb zapobiegania. Polityka w trybie detekcji rejestruje tylko ruch i nie blokuje ruchu. Najpierw zweryfikuj i dostrój politykę względem ruchu produkcyjnego, aby ograniczyć liczbę wyników fałszywie dodatnich, a następnie włącz tryb zapobiegania.
3. Przypisz zestaw reguł HTTP DDoS (dostępny zarówno w Azure Front Door Premium, jak i Application Gateway WAF v2), tak aby automatyczne ograniczanie działań polegało na poznawaniu bazowego poziomu ruchu zanim go potrzebujesz.
4. Włącz zarządzany przez Bot Manager zestaw reguł do identyfikowania i reagowania na znane złe boty.
5. Skonfiguruj co najmniej jedną regułę limitu stawek obejmującą wszystkie (zobacz Ograniczenie stawek).
6. Zwiększ liczbę instancji początkowych, aby mieć wystarczającą wolną pojemność, i ustaw Application Gateway na automatyczne skalowanie bez konieczności niskiego maksymalnego limitu instancji.
7. Włącz buforowanie w Azure Front Door, aby nagły ruch szczytowy był pochłaniany na krawędzi, a nie na początku.
8. Uwzględnij zakres L3/L4, który różni się w zależności od platformy. Zobacz Ochrona przed DDoS na platformie różni się w zależności od platformy. Zablokuj swój origin tak, aby przyjmował ruch tylko z Azure Front Door lub Application Gateway.
9. Włącz rejestrowanie diagnostyczne w usłudze Log Analytics i utwórz zapytania w obszarze Analizowanie dzienników WAF i dostępuprzed wystąpieniem incydentu.

Ochrona przed DDoS na platformie różni się w zależności od platformy

Obrona L7 ma znaczenie tylko wtedy, gdy podstawowe publiczne adresy IP przetrwają atak wolumetryczny, a obie platformy Azure WAF nie zaczynają się z tego samego miejsca.

Azure Front Door ma domyślną ochronę przed DDoS na platformie. Azure Front Door to globalnie rozproszona usługa brzegowa, a jej brzeg jest chroniony przez infrastrukturalną ochronę DDoS Azure bez dodatkowych kosztów i bez konfiguracji. Ruch jest kończony na brzegu usługi Front Door, a nie na należącym do Ciebie adresie IP, więc nie ma publicznego adresu IP, który atakujący mógłby obrać za cel na poziomie L3/L4. Ta ochrona jest nieodłączna dla platformy, więc nie kupujesz ani nie włączasz niczego, by ją zdobyć.

Application Gateway wymaga Azure DDoS Network Protection. Brama aplikacyjna to zasób regionalny z publicznym adresem IP w Twojej własnej sieci wirtualnej. Domyślna ochrona platformy Azure na poziomie infrastruktury zabezpiecza samą platformę Azure, ale nie zapewnia dostosowanych dla poszczególnych zasobów mechanizmów ograniczania skutków, danych telemetrycznych ani raportowania ataków dla tego adresu IP. Aby chronić publiczny adres IP bramy przed atakami wolumetrycznymi L3/L4, włącz ochronę sieci Azure DDoS w wirtualnej sieci, która ją zawiera. To płatna, osobno zakupiona usługa.

Praktyczne konsekwencje przy wyborze lub projektowaniu wdrożenia:

• Jeśli korzystasz z Azure Front Door, uwzględnij w budżecie mechanizmy kontrolne L7; brzegowa ochrona na poziomie L3/L4 jest już zapewniona.
• Jeśli używasz usługi Application Gateway i nie włączyłeś ochrony DDoS Network Protection, reguły WAF mogą być idealnie dostrojone, a mimo to zostać ominięte przez atak wolumetryczny wymierzony w publiczny adres IP bramy. Włącz to.
• W obu przypadkach udostępniane źródłowe publiczne adresy IP nadal wymagają ochrony Azure DDoS Network Protection oraz ograniczenia dostępu tak, aby tylko usługa WAF mogła się z nimi komunikować. Chroniony front-end umieszczony przed niechronionym, publicznie dostępnym źródłem nie jest chroniony.

Aby uzyskać więcej informacji, zobacz Omówienie usługi Azure DDoS Protection oraz Ochrona bramy aplikacji przy użyciu usługi Azure DDoS Network Protection.

Automatyczna ochrona za pomocą zestawu reguł HTTP DDoS (podgląd)

Statyczne kontrole, takie jak filtry IP, geo-filtry i stałe limity prędkości, często nie nadążają za rozproszonymi botnetami: progi to przypuszczenia, są zawsze włączone i trzeba je dostosowywać w miarę ewolucji wzorców ruchu. Zestaw reguł HTTP DDoS to pierwszy zautomatyzowany model ochrony warstwy 7 w Azure WAF, który uczy się, wykrywa i broni przy minimalnej konfiguracji użytkownika. Jest dostępny w wersji podglądowej zarówno na Azure Front Door Premium, jak i Application Gateway WAF v2. Po przypisaniu rozwiązanie stale ustala bazowy profil normalnego ruchu, a gdy nagłe wzrosty wskazują na atak, selektywnie blokuje klientów powodujących problem, bez konieczności awaryjnego dostrajania.

Projekt jest taki sam na obu platformach w najważniejszych aspektach:

• Dwa progi, ocenione razem. Zestaw reguł uczy się zarówno globalnego progu (dla profilu Front Door lub dla każdej bramki aplikacji), jak i indywidualnych progów opartych na IP. Progi oparte na IP są egzekwowane dopiero po przekroczeniu globalnego progu. Taka konstrukcja zapobiega reagowaniu zestawu reguł na skoki pochodzące z kilku adresów IP, chyba że faktycznie powodują one, że całkowity ruch przekracza normę.
• Oddzielnie dla każdego zasobu. Progi są ustalane na poziomie zasobu globalnego. Jeśli przypiszesz jedną politykę WAF z zestawem reguł do wielu profili Front Door lub wielu bram, usługa oblicza progi osobno dla każdego z nich.
• Wrażliwość. Każda reguła oferuje trzy poziomy czułości. Wyższa czułość powoduje niższy próg; Niższa czułość powoduje wyższy próg. Średni to domyślne i zalecane ustawienie.
• Zlecenie oceny. WAF najpierw ocenia zestaw reguł HTTP DDoS, nawet przed niestandardowymi regułami. Niestandardowa reguła z akcją Allow omija wszystkie inne inspekcje WAF, ale nie omija zestawu zasad HTTP DDoS.
• Pomijanie zestawu reguł dla zaufanego ruchu. Niestandardowa reguła z akcją Allow tu nie pomaga – omija wszystkie inne zestawy reguł, ale nie zestaw HTTP DDoS. Zamiast tego używaj wyjątków WAF , które możesz obejmować na konkretną regułę, grupę reguł lub cały zarządzany zestaw reguł, w tym zestaw reguł HTTP DDoS. Zobacz Wykluczanie zaufanego ruchu za pomocą wyjątków.
• Wymaga to stałego ruchu. Zestaw reguł może działać tylko wtedy, gdy nauczy się wiarygodnych punktów wyjściowych. Jeśli zasób nie otrzyma wystarczającego ruchu podczas fazy uczenia się, zestaw reguł nie wykryje ani nie ochroni, dopóki tego nie zrobi. Zobacz tabelę platform, aby poznać konkretne wymaganie.

Różnice między platformami

Reguły zestawu reguł

Obecnie zestaw zasad zawiera dwie reguły. Każda reguła utrzymuje własne poziomy bazowe ruchu i można ją skonfigurować z własnym poziomem czułości i własnym działaniem:

Pole karne

Obie platformy łagodzą kary przez ławkę karną. Gdy ruch od klienta przekroczy próg określony dla jednej z reguł w zestawie reguł, adres IP tego klienta zostaje objęty okresową blokadą i zablokowany przez usługę WAF na czas jej trwania, który w usłudze Application Gateway wynosi 15 minut. Po zakończeniu okresu adres IP odzyskuje dostęp, chyba że ponownie przekroczy próg, co przenosi go do strefy karnej.

To rozwiązanie ma znaczenie dla sposobu interpretowania telemetrii: rejestrowane jest tylko pierwsze trafienie reguły. Dodatkowe zablokowane żądania, gdy adres IP znajduje się już w polu karnym, nie są rejestrowane w usłudze Front Door, więc liczby oparte na dziennikach zaniżają liczbę zablokowanych żądań. W usłudze Application Gateway użyj metryki Penalty box blocks do określenia rzeczywistej liczby blokad oraz Penalty box size do sprawdzenia, ile adresów IP jest obecnie objętych ograniczeniem.

Monitorowanie podczas podglądu

Gdy adres IP przekroczy wartość progową, w dzienniku zostanie zapisany wpis z akcją Block dla zestawu reguł HTTP DDoS, a wartość metryki WAF Managed Rule Match wzrośnie.

• Front Door: używaj metryki Web Application Firewall Request count filtrowanej według nazwy reguły do zliczania blokad oraz metryki Web Application Firewall HTTPDDoSRuleset Is Active, która raportuje 1, gdy proces uczenia się zostanie zakończony, a zestaw reguł będzie gotowy do stosowania wobec ruchu, który przekracza wyuczone progi.
• Application Gateway: każde kolejne zablokowane żądanie z adresu IP objętego karą zwiększa metrykę Managed Rule Match, a metryki Penalty box size i Penalty box blocks bezpośrednio monitorują penalty box.

Wyklucz zaufany ruch za pomocą wyjątków

Sondy zdrowotne, syntetyczne monitorowanie, testy obciążenia, integracje z partnerami i wewnętrzne zadania wsadowe generują ruch, który wygląda jak powódź, ale tak nie jest. Historycznie nie ma możliwości wyłączenia ich z zestawu reguł DDoS, ponieważ niestandardowa reguła Allow omija domyślny zestaw reguł, podstawowy zestaw reguł i ochronę botów, ale celowo nie omija zestawu HTTP DDoS.

Wyjątki WAF niwelują tę lukę. Wyjątek omija inspekcję WAF dla żądań pasujących do określonych atrybutów, przypisanych do jednej reguły, grupy reguł lub całego zarządzanego zestawu reguł. Możesz stosować wyjątki do zestawu reguł HTTP DDoS, a także do DRS, CRS i ochrony botów.

Wyjątki pasują na:

• Zdalny adres IP (Equals lub IP Match), który jest standardowym wyborem do wyłączania znanych zakresów monitorowania, testowania obciążenia lub partnera z zestawu reguł DDoS
• URI żądania
• Nazwa i wartość nagłówka żądania, dopasowane za pomocą opcji Równa się, Zaczyna się od, Kończy się na lub Zawiera

Wytyczne dotyczące korzystania z wyjątków w zasadach DDoS:

• Ogranicz zakres do minimum. Wolę wyjątek za każdą regułę niż wyłączanie całego zestawu zasad. Szeroki wyjątek daje atakującemu udokumentowany sposób obejścia automatycznych mechanizmów łagodzących. Jeśli generator obciążenia potrzebuje jedynie wyłączenia z reguły 500100, nie wyłączaj go również z reguły 500110.
• Wyłącz ze sprawdzania źródła, a nie ścieżki. Wyjątek oparty na adresie IP dla znanego środowiska testowego jest ograniczony. Wyjątek oparty na URI na publicznym punkcie końcowym to otwarte drzwi dla każdego, kto go znajdzie.
• Przeglądaj je według harmonogramu. Wyjątki dodane dla jednorazowego testu obciążeniowego mogą obowiązywać nawet rok później.
• Uważaj na granice. Każda polityka WAF obsługuje do 60 wyjątków, a każda usługa Front Door obsługuje łącznie do 60 wyjątków we wszystkich skojarzonych z nią politykach. Pojedynczy wyjątek może zawierać do 600 adresów IP, 10 URI lub 10 nagłówków żądań.
• Wyjątki wymagają nowej generacji silnika WAF oraz zarządzanego zestawu reguł DRS 2.1 lub nowszego.

Użyj odpowiedniego narzędzia do zadania: wykluczenia pomijają inspekcję jednego elementu żądania (hałaśliwego ciasteczka lub nagłówka), a resztę nadal kontrolują; wyjątki pomijają konkretne reguły lub zestawy reguł dla dopasowywania żądań; niestandardowa reguła Allow omija wszystko oprócz zestawu zasad HTTP DDoS.

Wyzwanie przed zablokowaniem

Blokowanie to toporne narzędzie podczas ataku L7: ruch związany z atakiem często pochodzi z adresów IP i regionów geograficznych, z których korzystają również prawdziwi użytkownicy. Wyzwania pozwalają oddzielić automatyzację od ludzi bez szkód ubocznych wynikających z bezpośredniego blokowania, a są największą zmianą w sposobie, w jaki Azure WAF radzi sobie z powodziami L7 w porównaniu do strategii ograniczającej tylko blok na limitach stawek.

• Wyzwanie JavaScript to niewidzialne wyzwanie, które nie wymaga żadnej interakcji człowieka. Jeśli przeglądarka pomyślnie obliczy wyzwanie, WAF weryfikuje klienta jako niebota i kontynuuje analizę pozostałych reguł; Nieudane żądania są blokowane. Traktuj go jako domyślne wyzwanie dla ogólnego ruchu w sieci. Żądania do punktu końcowego wyzwania nie są przekazywane do backendu i nie liczą się do limitu szybkości.
• CAPTCHA to interaktywne wyzwanie wymagające udziału użytkownika, najlepiej zarezerwowane dla kluczowych etapów, takich jak logowanie, rejestracja czy finalizacja zakupu, w których zautomatyzowane nadużycia są kosztowne, a kilka sekund dodatkowego utrudnienia dla użytkownika jest akceptowalne. Ważność cookie wyzwania jest konfigurowalna w ustawieniach polityki od 5 do 1 440 minut, z domyślnym czasem 30 minut. CAPTCHA ponosi dodatkowe opłaty związane z użytkowaniem.

Zaplanuj ograniczenia obu funkcji przed ich wdrożeniem:

• Nie są obsługiwane wywołania AJAX i API. Nie stawiaj wyzwań przed trasami API. Zamiast tego używaj tam ograniczania szybkości i reguł dopasowania.
• Wyzwania są przeznaczone dla zasobów HTML, a nie dla osadzonych obrazów, CSS czy plików JavaScript.
• Przy pierwszym żądaniu, które wywołuje wyzwanie, treść POST jest ograniczona do 64 KB w Azure Front Door i 128 KB w Application Gateway.
• Żadna z funkcji nie obsługuje Internet Explorer; obie obsługują aktualne wersje Microsoft Edge, Chrome, Firefox i Safari.
• Wyzwanie JavaScript jest ponownie wyświetlane, gdy zmienia się adres IP klienta oraz w przypadku żądań między źródłami (CORS).
• W usłudze Application Gateway mechanizm testu JavaScript jest dostępny w wersji zapoznawczej i nie jest obsługiwany w przypadku niestandardowych reguł ograniczania szybkości. Application Gateway for Containers WAF tego nie obsługuje.

Ograniczanie szybkości

Co najmniej stworzyć regułę limitu szybkości, która blokuje wysokie tempo żądań od dowolnego pojedynczego klienta. Ustaw tę regułę jako regułę o najniższym priorytecie (najwyższej wartości liczbowej) dla ograniczania liczby żądań, aby bardziej szczegółowe reguły ograniczania liczby żądań lub reguły dopasowania były oceniane najpierw.

Azure Front Door

• Limity prędkości obowiązują dla każdego adresu IP gniazda, czyli adresu klienta, który otwiera połączenie TCP z Azure Front Door i może być proxy, a nie użytkownikiem końcowym.
• Progi są oceniane w stałym oknie wynoszącym jedną lub pięć minut. Po przekroczeniu progu Azure Front Door blokuje cały ruch pasujący do reguły przez pozostałą część okna czasowego. Wykorzystaj pięciominutowe okno do łagodzenia powodzi HTTP: atakujący zablokowany w pierwszej minucie pozostaje zablokowany przez pozostałe cztery.
• Większe okna o najmniejszym dopuszczalnym progu są najskuteczniejszą konfiguracją anty-DDoS. Większe okna i większe wartości progowe również wymuszają zbliżenie się do skonfigurowanego progu. Przy bardzo niskich progach (poniżej około 200 żądań na minutę) niektóre żądania powyżej progu mogą się przedostać, ponieważ żądania jednego klienta mogą trafić na serwery Front Door, których liczniki nie zostały jeszcze odświeżone.
• Reguły ograniczania szybkości obsługują tylko akcje Log i Block; akcja Allow nie jest obsługiwana.
• Zastosuj regułę do całego ruchu, dopasowując na podstawie nagłówka Host o długości większej od 0, ponieważ każde prawidłowe żądanie do usługi Azure Front Door zawiera taki nagłówek.

Zapora sieciowa WAF usługi Application Gateway w wersji 2

• Ograniczenie szybkości wykorzystuje algorytm okna przesuwnego . Cały odpowiadający mu ruch jest odrzucany w pierwszym oknie czasowym, w którym próg zostaje przekroczony. Począwszy od drugiego okna, ruch do wartości progowej jest dozwolony, co skutkuje ograniczaniem przepustowości zamiast całkowitej niedostępności dla pasujących klientów.

• Reguły wymagają GroupByUserSession, który kontroluje sposób liczenia żądań. Ta funkcja pozwala ograniczać liczbę żądań na podstawie czegoś innego niż adres IP klienta:

  GroupByVariable (Grupowanie według zmiennej)	Użyj go, gdy
  ClientAddr (ustawienie domyślne)	Tryb normalny z niezależnymi licznikami dla każdego źródłowego adresu IP
  ClientAddrXFFHeader	Brama znajduje się za CDN lub serwerem proxy, a rzeczywisty adres IP klienta znajduje się w X-Forwarded-For
  GeoLocation	Chcesz ograniczyć ruch w poszczególnych krajach/regionach podczas powodzi geograficznie skoncentrowanej
  GeoLocationXFFHeader	Tak samo jak wyżej, używając adresu IP w X-Forwarded-For
  None	Pojedynczy współdzielony licznik dla wąsko dopasowanego wzorca, na przykład strony logowania lub listy podejrzanych agentów użytkowników

• Reguły ograniczania liczby żądań wymagają najnowszej wersji silnika WAF (dla domyślnego zestawu reguł wybierz CRS 3.2 lub nowszy) i nie są obsługiwane w chmurach odizolowanych od sieci.

• Application Gateway liczy progi niezależnie dla każdego punktu końcowego, do którego polityka jest przypisana. Jedna polityka dla pięciu słuchaczy utrzymuje pięć zestawów liczników.

• Progi nie są egzekwowane dokładnie, więc nie stosuj ograniczeń prędkości do precyzyjnej kontroli ruchu. Wykorzystaj go, aby zminimalizować nietypowe wskaźniki i utrzymać dostępność. Zachowaj szczególną ostrożność w przypadku reguł szerokiego dopasowania, które używają GeoLocation lub None; źle dobrany próg może powodować częste krótkie przerwy w obsłudze prawidłowego ruchu.

Ustal progi uwzględniające geografię

Jeden globalny próg musi być wystarczająco hojny dla najbardziej ruchliwego kraju, co czyni go zbyt hojnym wszędzie indziej. Większość aplikacji ma w czasie pokoju wyraźnie nierównomierny rozkład geograficzny — garstka krajów lub regionów generuje niemal cały uprawniony ruch, a cała reszta jedynie śladowe ilości. Ruch atakowy rzadko respektuje ten rozkład. Ustalanie progów dla poszczególnych regionów zmienia tę asymetrię zarówno w sygnał wykrywania, jak i w mechanizm ograniczający.

Zacznij od zmierzenia rozkładu obciążenia w normalnych warunkach przez co najmniej pełny tydzień, tak aby uwzględnić wpływ dni roboczych, weekendów i stref czasowych:

• Na Azure Front Door podziel metrykę liczby żądań według wymiaru ClientCountry.

• W Log Analytics wyprowadzmy kraj z adresu IP klienta w logu dostępu:

  AzureDiagnostics
  | where Category == "FrontdoorAccessLog"
  | where TimeGenerated > ago(7d)
  | extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
  | summarize Requests = count(), Clients = dcount(clientIp_s) by Country
  | extend ShareOfTraffic = round(100.0 * Requests / toscalar(
        AzureDiagnostics
        | where Category == "FrontdoorAccessLog" and TimeGenerated > ago(7d)
        | count), 2)
  | order by Requests desc
  

Następnie grupuj wyniki w poziomy i ustaw próg dla każdego:

Sposób implementacji poziomów zależy od platformy:

• Application Gateway WAF v2 — używaj GroupByVariable: GeoLocation (lub GeoLocationXFFHeader za siecią CDN albo serwerem proxy), aby cały ruch z jednego regionu geograficznego korzystał z jednego licznika, i utwórz jedną regułę ograniczania szybkości dla każdego poziomu z własnym progiem. Ponieważ naruszenie reguły ma wpływ na każdego klienta w danym obszarze geograficznym, progi te należy ustawiać konserwatywnie i najpierw sprawdzić je przy akcji Log: nieprawidłowo skonfigurowana reguła geolokalizacyjna o szerokim dopasowaniu może powodować częste, krótkie przerwy w prawidłowym ruchu.
• Azure Front Door – liczniki są naliczane na adres IP gniazda, więc zamiast tego utwórz warstwy na podstawie warunków dopasowania geograficznego: jedna reguła ograniczania szybkości na warstwę, dopasowana do odpowiednich krajów, każda z własnym progiem. Każdy klient na rynkach peryferyjnych otrzymuje wtedy znacznie niższy limit niż klienci na Twoich głównych rynkach, przy czym zachowanie jednego klienta nie wpływa na pozostałych.

Kilka praktyk, które pozwalają to utrzymać:

• Uporządkuj reguły od najbardziej szczegółowych do najmniejszych: reguły rynku pierwotnego o wyższym priorytecie (niższa wartość liczbowa), potem drugorzędne, a następnie długoogonie, z globalną regułą uniwersalną jako najniższym limitem stopy priorytetowej.
• Preferuj akcję weryfikacji zamiast blokady w regionach niszowych. Ruch z kraju o niewielkim legalnym wolumenie jest podejrzany w sumie, ale nadal zawiera prawdziwych użytkowników – podróżnych, użytkowników VPN i pracowników zdalnych.
• Ponownie mierzyć po premierach marketingowych, ekspansji regionalnych i dużych wydarzeniach produktowych. Konfiguracja uwzględniająca geografię jest tak dobra, jak dobra jest linia wyjściowa, z której została dobrana.
• Zwracaj uwagę na odwrotny sygnał podczas incydentu: kraj, który normalnie odpowiada za 1% ruchu, nagle dodaje 40% to jeden z najszybszych sposobów, by potwierdzić, że widzisz atak, a nie organiczny wzrost.

Wybierz próg na podstawie własnego ruchu

Użyj poniższego zapytania usługi Log Analytics, aby określić rozmiar reguły typu catch-all. Dla Application Gateway zastąp FrontdoorAccessLog go na ApplicationGatewayAccessLog.

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| summarize count() by bin(TimeGenerated, 5m), clientIp_s
| summarize max(count_), percentile(count_, 99), percentile(count_, 95)

Aby określić progi dla poszczególnych obszarów geografii opisane wcześniej, należy dodać kraj do tego samego zapytania:

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize count() by bin(TimeGenerated, 5m), clientIp_s, Country
| summarize max(count_), percentile(count_, 99), percentile(count_, 95) by Country
| order by percentile_count__99 desc

Ustaw próg powyżej 99. percentyla ruchu w normalnych warunkach, a nie na wartości maksymalnej. Maksimum to zwykle robot indeksujący lub błędnie skonfigurowany klient, a ustawienie limitu na tym poziomie sprawia, że reguła jest zbyt pobłażliwa, by pomóc podczas ataku.

Niestandardowe reguły ukierunkowanego ograniczania skutków

Stwórz niestandardowe reguły WAF blokujące lub ograniczające szybkość ataków HTTP i HTTPS, które mają identyfikowalne sygnatury, takie jak konkretny agent użytkownika, nagłówek, ciasteczko, wzór ciągów zapytań, URI lub ich kombinację. Poza dopasowaniem ciągów znaków niestandardowe reguły usługi Azure Front Door WAF mogą uwzględniać również:

• Geolokalizacja: Zablokuj ruch spoza obszaru obsługi lub przekieruj go na statyczną stronę.
• Adresy IP klienta (CIDR) oraz listy ograniczeń IP dla adresów i zakresów, które zidentyfikowałeś jako złośliwe.
• Numer AS (ASN): Ograniczaj powodzie pochodzące od dostawcy hostingu lub sieci tranzytowej, z których nie pochodzą prawdziwi użytkownicy, bez wyliczania zakresów IP.
• Odcisk palca klienta (JA4): Dopasowanie na podstawie odcisku palca JA4, skrótu wyprowadzonego z uzgadniania TLS klienta oraz cech HTTP. Ponieważ narzędzia atakujące i klienci botnetów generują spójny odcisk palca niezależnie od adresu IP, z którego wysyłają, JA4 jest jednym z najbardziej trwałych podpisów dostępnych podczas rozproszonego ataku: rotacja między tysiącami źródłowymi adresami IP nie zmienia odcisku palca, a blokowanie lub ograniczenie szybkości usuwa cały botnet jedną regułą. Sprawdź odcisk palca w swoich dziennikach z czasów pokoju, zanim go egzekwujesz. Popularne przeglądarki i popularne SDK dzielą się śladami wśród ogromnej liczby legalnych użytkowników, więc niezweryfikowany blok JA4 może być bardzo szeroki. Najpierw wdroż akcję Log, upewnij się, że sygnatura pojawia się tylko w ruchu związanym z atakiem, a następnie przełącz na akcję Block lub regułę ograniczania szybkości.
• Łącz JA4 z innymi schorzeniami w celu łagodzenia działań chirurgicznych podczas incydentu. Na przykład, ograniczenie szybkości zamiast blokowania konkretnego odcisku palca JA4 i ASN, z którego nie obsługujesz użytkowników, albo odcisk JA4 i URI żądania.
• Ograniczenia dotyczące tagów usługowych i rozmiaru komponentów żądań.

Dwie praktyki, które mają znaczenie podczas incydentu:

• Utwórz reguły dopasowania Zezwalaj dla znanego, prawidłowego ruchu, aby ograniczyć liczbę fałszywych wyników pozytywnych, i nadaj im wyższy priorytet (niższą wartość liczbową) niż regułom blokowania i ograniczania szybkości. Pamiętaj, że reguła Allow omija inne inspekcje WAF, ale nie omija zestawu zasad HTTP DDoS.
• Ocena reguły zatrzymuje się przy dowolnej akcji z wyjątkiem Log, a numery priorytetów muszą być unikalne. Zarezerwuj blok numerów o niższym priorytecie dla reguł awaryjnych, aby podczas ataku móc wstawić jedną z nich bez konieczności zmiany numeracji.

Zarządzane reguły nie są skierowane do obrony przed DDoS, ale chronią przed innymi powszechnymi atakami i powinny pozostać włączone. Zobacz Managed rules (Azure Front Door) lub Managed rules (Application Gateway).

Chroń źródło

• Zabezpiecz dostęp do publicznych adresów IP na miejscu początkowym i ogranicz ruch przychodzący, aby tylko Azure Front Door lub Application Gateway mogły do niego dotrzeć. Stosuj się do wskazówek dotyczących zabezpieczania ruchu do Azure Front Door Origins.
• Upewnij się, że w wirtualnej sieci bramki aplikacyjnej nie ma publicznie ujawnionych adresów IP.
• Włącz buforowanie w usłudze Azure Front Door. Odpowiedzi z pamięci podręcznej przejmują szczytowy ruch na brzegu sieci i zmniejszają liczbę żądań docierających do Twojego serwera źródłowego, co często stanowi różnicę między spadkiem wydajności a awarią.
• Skala pochodzi z headroomu. Automatyczne i ręczne działania łagodzące wymagają czasu; Zapasowe możliwości wypełniają tę lukę.

Odpowiedz na aktywny atak

1. Potwierdź, że to atak, a nie organiczny wzrost. Sprawdź dzienniki WAF i dzienniki dostępu pod kątem nagłej zmiany tempa żądań, liczby adresów IP klientów, struktury geograficznej, rozkładu identyfikatorów User-Agent oraz żądanych adresów URI.
2. Sprawdź, co już łagodzi skutki. Potwierdź, że zestaw reguł DDoS HTTP jest aktywny, i przejrzyj zablokowane żądania według nazwy reguły. W usłudze Application Gateway sprawdź także metryki Penalty box size i Penalty box blocks, ponieważ w logach pojawia się tylko pierwsza blokada dla danego adresu IP. Recenzja zgodności z limitem stawki.
3. Porównaj mieszankę geograficzną z twoim wynikiem wyjściowym. Kraj, który zwykle odpowiada za niewielką część ruchu, a nagle zaczyna go dominować, to szybki i bardzo wiarygodny sygnał ataku. Informuje też, którą warstwę limitów stawek należy najpierw zaostrzić.
4. Podnieś wrażliwość przed pisaniem nowych zasad. Zwiększenie czułości zestawu reguł HTTP DDoS lub obniżenie istniejącego progu limitu szybkości jest szybsze i bezpieczniejsze niż tworzenie nowej reguły pod presją.
5. Wyzwanie, a nie blokowanie miejsc, gdzie ruch jest mieszany. Zastosuj mechanizm weryfikacji JavaScript do tras HTML, których dotyczy problem, oraz CAPTCHA do wrażliwych procesów.
6. Przepisz regułę docelową dopiero wtedy, gdy zidentyfikowasz trwały podpis: ASN, odcisk palca klienta, kombinację nagłówka, geografię lub wzór URI. Najpierw wdroż go w akcji Log, jeśli wzór pasuje też do rzeczywistych użytkowników.
7. Chroń serwer źródłowy podczas dostrajania: sprawdź, czy buforowanie jest włączone, potwierdź, że dostęp do serwera źródłowego jest ograniczony, i skaluj horyzontalnie.
8. Po incydencie dostosuj progi limitu stawek na podstawie nowych danych o ruchu i zachowaj zasady awaryjne, które okazały się aktualne, w trybie Log, jeśli nie chcesz, by były ciągłe egzekwowane.

Analizuj WAF i logi dostępu

Monitoruj ruch za pomocą logów Azure WAF pod kątem anomalii i używaj ich do identyfikacji podejrzanych adresów IP, które wysyłają wyjątkowo dużą liczbę żądań, nietypowe ciągi łańcuchów agentów użytkownika lub anomaliowe wzorce ciągów zapytań.

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Azure Application Gateway

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Najaktywniejsze źródła ruchu i najczęstsze agenty użytkownika w okresie ataku (pokazano Azure Front Door; w przypadku Application Gateway zastąp elementem ApplicationGatewayAccessLog):

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by clientIp_s
| top 20 by Requests desc

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by userAgent_s, requestUri_s
| top 20 by Requests desc

Dla więcej informacji zobacz Azure WAF with Azure Front Door oraz Azure WAF with Azure Application Gateway.

Treści powiązane

• HTTP DDoS ruleset: Azure Front Door WAF | Application Gateway WAF
• Lista wyjątków WAF: Azure Front Door WAF | Application Gateway WAF
• Ograniczanie szybkości: Azure Front Door WAF | Application Gateway WAF
• WAF setup: Azure Front Door | Application Gateway
• Wyzwanie JavaScript usługi Azure WAF
• Azure Front Door WAF CAPTCHA
• Ochrona przed atakami DDoS w usłudze Azure Front Door
• Azure DDoS Protection — architektury referencyjne
• Omówienie usługi Azure DDoS Protection