Ochrana proti DDoS aplikaci (vrstva 7)

Platí na: ✔️ Application Gateway V2 ✔️ Front Door Premium

Azure Web Application Firewall (WAF) obsahuje několik obranných mechanismů, které pomáhají předcházet útokům distribuovaného odmítnutí služby (DDoS). Útoky DDoS můžou cílit na síťovou vrstvu (L3/L4) i aplikační vrstvu (L7). Azure DDoS Protection vás chrání před rozsáhlými útoky na svazky vrstvy sítě. Azure WAF, fungující na vrstvě 7, chrání webové aplikace před útoky typu DDoS typu L7, jako jsou povodeň HTTP. Tyto obrany dohromady zabraňují útočníkům v přístupu k vaší aplikaci a ovlivnění její dostupnosti a výkonu.

Útoky na aplikační vrstvě jsou levné na spuštění a těžko odlišitelné od legitimního provozu: každý požadavek vypadá platně sám o sobě a pouze souhrnná rychlost, distribuce a mix klientů odhalují útok. Efektivní obrana na úrovni 7 proto méně spoléhá na jednotlivé ovládání a více na vrstvenou konfiguraci, která je již před zahájením útoku na místě.

Vyberte si obranné vrstvy

Při plánování ochrany proti DDoS L7 použijte následující model. Každá vrstva zachytává provoz, který vrstva nad ní ne.

Vrstva Jak funguje Kde ho nakonfigurovat
Ochrana platformy proti DDoS Pohlcuje L3/L4 volumetrické útoky na Azure edge a na vaše původní veřejné IP adresy Ve výchozím nastavení v Azure Front Door; vyžaduje Azure DDoS Network Protection pro veřejné IP adresy Application Gateway a veřejné IP adresy původu
Automatizované zmírnění L7 Naučí se běžný provoz a během přepětí zjišťuje plyn bez nouzového ladění HTTP DDoS ruleset (preview) on Azure Front Door Premium a Application Gateway WAF v2
Ověření klienta Odděluje lidi a legitimní klienty od automatizovaného útočného provozu před blokováním Pravidla Bot Manager,JavaScript challenge, CAPTCHA
Omezování rychlosti Omezuje počet požadavků, které může jakýkoli klient, geografický nebo koncový bod odeslat Vlastní pravidla pro omezení rychlosti na Front Door a Application Gateway
Cílená vlastní pravidla Blokuje známý útočný podpis během incidentu Přizpůsobte vlastní pravidla (geo, IP, ASN, otisk klienta, hlavička, URI)
Ochrana původu Zabraňuje tomu, aby se útokový provoz vůbec dostal k vašemu výpočetnímu prostoru Cache, uzamčení původu, automatické škálování

Kontrolní seznam základní konfigurace

Dokonči tyto kroky dřív, než tě napadnou. Upravte je tak, aby vyhovovaly požadavkům vaší žádosti.

  1. Deploy Azure WAF s Azure Front Door Premium nebo Application Gateway WAF v2 pro ochranu proti útokům L7 aplikační vrstvy.
  2. Přepněte politiku WAF do režimu prevence. Politika v režimu detekce pouze zaznamenává a neblokuje provoz. Nejprve ověřte a ladíte politiku proti produkčnímu provozu, abyste snížili falešně pozitivní výsledky, a pak zapněte prevenci.
  3. Přiřaďte HTTP DDoS pravidla (dostupná jak na Azure Front Door Premium, tak Application Gateway WAF v2), aby automatizovaná mitigace znamenala naučit se váš provoz dříve, než ho budete potřebovat.
  4. Povolte správci správců botů identifikovat a reagovat na známé špatné boty.
  5. Nakonfigurujte alespoň jedno univerzální pravidlo limitu sazeb (viz Omezení sazeb).
  6. Zvětšte počet původních instancí tak, aby bylo dostatek volné kapacity, a nastavte Application Gateway tak, aby automaticky škáloval, aniž byste museli vynucovat nízký maximální počet instancí.
  7. Zapněte caching na Azure Front Door, aby náhlý špičkový provoz byl absorbován na okraji místo u vašeho původního provozu.
  8. Kryjte expozici L3/L4, která se liší podle platformy. Viz Ochrana proti DDoS na platformě se liší podle platformy. Uzamkněte svůj origin tak, aby přijímal provoz pouze z Azure Front Door nebo Application Gateway.
  9. Zapněte diagnostické logování do Log Analytics a vytvořte dotazy v Analyze WAF a přístupové logypřed incidentem.

Ochrana proti DDoS na platformě se liší podle platformy

Obrany L7 jsou důležité pouze tehdy, pokud základní veřejné IP adresy přežijí objemový útok a obě platformy Azure WAF nezačínají ze stejného místa.

Azure Front Door má ve výchozím nastavení ochranu proti DDoS na platformě. Azure Front Door je globálně distribuovaná edge služba a její edge je chráněn infrastrukturní DDoS ochranou Azure bez dalších nákladů a bez konfigurace. Provoz končí na okraji Front Door místo na IP adrese, kterou vlastníte, takže neexistuje veřejná IP adresa, kterou by útočník mohl cílit na L3/L4. Tato ochrana je vlastní platformě, takže si nic nekupujete ani nepovolujete, abyste ji získali.

Application Gateway potřebuje Azure DDoS Network Protection. Aplikační brána je regionální zdroj s veřejnou IP adresou ve vaší vlastní virtuální síti. Výchozí ochrana na úrovni infrastruktury Azure chrání samotnou platformu Azure, ale neposkytuje vám pro tuto IP adresu naladěné zmírnění škod, telemetrii ani hlášení útoků. Pro ochranu veřejné IP brány proti L3/L4 volumetrickým útokům povolte Azure DDoS Network Protection na virtuální síti, která ji obsahuje. Jedná se o placenou, samostatně zakoupenou službu.

Praktické důsledky při výběru nebo návrhu nasazení:

  • Pokud jste za Azure Front Door, rozpočtěte si na L7 ovládání; ochrana L3/L4 edge už existuje.
  • Pokud používáte Application Gateway a nemáte zapnutou ochranu sítě proti DDoS, vaše WAF pravidla lze perfektně naladit a přesto je obejít volumetrickým útokem na veřejnou IP adresu brány. Povolte to.
  • V každém případě veřejné IP adresy Origin, které zpřístupníte, stále potřebují Azure DDoS síťovou ochranu plus lockdown, aby k nim mohla přistupovat pouze služba WAF. Chráněný přední konec před nechráněným, veřejně dostupným zdrojem není chráněn.

Pro více informací viz přehled Azure DDoS Protection a Chraňte svou aplikační bránu pomocí Azure DDoS Network Protection.

Automatizovaná ochrana pomocí HTTP DDoS pravidel (náhled)

Statické ovládací prvky jako IP filtry, geo-filtry a pevné rychlostní limity často nestíhají s distribuovanými botety: prahy jsou odhady, jsou vždy zapnuté a musíte je upravovat podle vývoje provozních vzorců. HTTP DDoS pravidla jsou prvním automatizovaným modelem ochrany na 7. vrstvě Azure WAF, který se učí, detekuje a brání s minimální uživatelskou konfigurací. Je dostupný v náhledu jak na Azure Front Door Premium, tak na Application Gateway WAF v2. Po přiřazení nepřetržitě nastavuje běžný provoz a když přepětí signalizují útok, selektivně blokuje útočné klienty bez nutnosti nouzového ladění.

Design je na obou platformách stejný v těch nejdůležitějších ohledech:

  • Dva prahy, vyhodnocené společně. Pravidlová sada se učí jak globální práh (pro profil Front Door, nebo pro aplikační bránu), tak pro jednotlivé prahové hodnoty založené na IP adresách. Prahy na základě IP jsou vynucovány až poté, co je globální práh překročen. Tento design zabraňuje tomu, aby soubor pravidel působil na špičkách z několika IP adres, pokud skutečně nepřekročí celkový provoz nad normu.
  • Zaměřeno na každý zdroj. Prahy se učí na globální úrovni zdrojů. Pokud přiřadíte jednu WAF politiku s pravidly k více profilům Front Door nebo více gatewayům, služba vypočítá prahové hodnoty zvlášť pro každou z nich.
  • Citlivost. Každé pravidlo nabízí tři úrovně citlivosti. Vyšší citlivost znamená nižší práh; nižší citlivost znamená vyšší práh. Střední je výchozí a doporučené nastavení.
  • Hodnotící pořadí. WAF nejprve vyhodnocuje HTTP DDoS pravidla, dokonce ještě před vlastními pravidly. Vlastní pravidlo s akcí Povolit obchází všechny ostatní inspekce WAF, ale neobchází HTTP DDoS pravidla.
  • Obcházení pravidel pro důvěryhodný provoz. Vlastní pravidlo s akcí Povolit zde nepomáhá – obchází všechna ostatní pravidla, ale ne HTTP DDoS pravidla. Použijte místo toho výjimky WAF , které můžete omezit na konkrétní pravidlo, skupinu pravidel nebo celou spravovanou sadu pravidel, včetně HTTP DDoS pravidel. Viz Vyjmutý důvěryhodný provoz s výjimkami.
  • Vyžaduje to trvalý provoz. Pravidla mohou jednat pouze poté, co se naučí spolehlivé základní hodnoty. Pokud zdroj během fáze učení nepřijme dostatečný provoz, soubor pravidel nebude detekovat ani chránit, dokud tak nebude. Podívejte se na tabulku nástupiště pro konkrétní požadavek.

Rozdíly mezi platformami

Characteristic Azure Front Door Premium WAF Application Gateway v2
Fáze učení Základní hodnoty se počítají v pohyblivém okně; Detekce začíná do 24–36 hodin u profilů, které byly zaznamenány alespoň 50% z posledních sedmi dnů Základní hodnoty se učí minimálně 24 hodin; Pravidla nedetekuje ani neblokuje, dokud nedokončí 24hodinovou fázi učení
Nedostatečná doprava Pokud profil přijímá provoz méně než 50% z posledních sedmi dnů, pravidla ji nezachytí ani nezablokuje, dokud nebude existovat dostatečný provoz pro spolehlivé základní hodnoty Pokud brána během 24hodinové fáze učení nepřijme dostatečný provoz k vytvoření spolehlivých základních hodnot, pravidlová sada útoky nedetekuje ani nezablokuje, dokud tak neudělá
Mitigation Porušení IP adres jsou umístěny do trestné schránky a blokovány po dobu trvání trestné schránky Porušení IP adres jsou umístěny do trestní schránky a blokovány na 15 minut
ID pravidel 500100 (klientská frekvence požadavků), 500110 (podezřelí boti) 500100 (klientská frekvence požadavků), 500110 (podezřelí boti)
Další metriky Web Application Firewall HTTPDDoSRuleset je aktivní Velikost trestného území, bloky trestného území

Pravidla pravidlového souboru

Pravidla v současnosti obsahují dvě pravidla. Každé pravidlo si udržuje vlastní základní provoz a je konfigurovatelné s vlastní citlivostí a akcí:

Pravidlo Description
500100: Zjištěna anomálie při vysoké frekvenci klientských požadavků Základní nastavení veškeré provozu na profilu Front Door nebo aplikační bráně, ke které je politika připojena. Když klient překročí naučený práh, spustí se nakonfigurovaná akce a pochybující IP adresa je umístěna do trestního boxu.
500110: Podezřelí boti posílající vysokou míru požadavků Udržuje oddělené, obecně mnohem přísnější základní limity pro provoz klasifikovaný jako boti podle Microsoft Threat Intelligence. Boti klasifikovaní jako vysoce rizikoví jsou okamžitě blokováni, jakmile je překročen globální práh.

Trestná skříňka

Obě nástupiště zmírňují škody prostřednictvím trestné lavice. Když provoz od klienta překročí práh pro jedno z pravidel sady, je tato IP adresa klienta umístěna do trestného boxu a zablokována WAF po dobu trvání penalty boxu, což je 15 minut na Application Gateway. Po skončení období IP adresa získá přístup zpět, pokud znovu nepřekročí prah, což ji vrátí zpět do trestné schránky.

Tento design je důležitý pro to, jak čtete telemetrii: zaznamenává se pouze počáteční zásah pravidla. Další blokované požadavky, když je IP adresa již v trestním boxu, nejsou na Front Door zaznamenány, takže počty založené na logu podhodnotí počet zablokovaných požadavků. Na Application Gateway použijte metriku bloků penalizačních políček pro skutečný počet bloků a velikost trestné krabice pro počet IP adres, které jsou aktuálně penalizovány.

Monitorování během náhledu

Když IP adresa překročí prah, záznam v logu je zaznamenán akcí Block pro HTTP DDoS pravidlovou sadu a pro metrické inkrementy WAF Managed Rule Match .

  • Front Door: použijte metriku počtu požadavků Web Application Firewall filtrovanou podle názvu pravidla pro počítání bloků a metriku Web Application Firewall HTTPDDoSRuleset Is Active, která hlásí1, kdy je učení dokončeno a pravidlová sada připravena reagovat na provoz, který překročí naučené prahy.
  • Application Gateway: každý následující blokovaný požadavek z penalizované IP adresy zvyšuje metriku Managed Rule Match a metriky velikosti penalty box a penalty box box přímo sledují tuto hranici.

Vyjměte důvěryhodný provoz s výjimkami

Zdravotní sondy, syntetické monitorování, zátěžové testy, integrace partnerů a interní dávkové úlohy generují provoz, který vypadá jako záplava, ale není to tak. Historicky neexistuje způsob, jak je vyjmout z DDoS pravidel, protože vlastní pravidlo Povolit obchází výchozí sadu pravidel, základní sadu pravidel a ochranu botů, ale záměrně neobchází HTTP DDoS pravidla.

Výjimky WAF tuto mezeru uzavírají . Výjimka obchází inspekci WAF pro požadavky odpovídající konkrétním atributům, zaměřené na jedno pravidlo, skupinu pravidel nebo celou spravovanou sadu pravidel. Výjimky můžete aplikovat na HTTP DDoS pravidla, stejně jako na DRS, CRS a ochranu botů.

Výjimky se shodují na:

  • Vzdálená IP adresa (Equals nebo IP Match), která je obvyklou volbou pro vyjmutí známých rozsahů z monitorování, zatěžování nebo partnerských zdrojů z DDoS pravidel
  • Požadavek URI
  • Název a hodnota hlavičky požadavku, přiřazené s Equals, Starts s, Ends by by nebo Contains

Pokyny pro používání výjimek v DDoS pravidlech:

  • Zaměřte se co nejužší. Preferuji výjimku podle pravidel před vyjmutím celého souboru pravidel. Široká výjimka dává útočníkovi zdokumentovanou cestu kolem vašeho automatizovaného mitigačního opatření. Pokud generátor zátěže potřebuje pouze úlevu od pravidla 500100, nevylučujte ho také z 500110.
  • Vyjmuté zdroje, ne cesty. IP výjimka pro známý testovací svazek je omezena. Výjimka založená na URI na veřejném koncovém bodu je otevřenou dverí pro každého, kdo ji najde.
  • Projděte si je podle plánu. Výjimky přidané pro jednorázový zátěžový test mohou být stále platné i po roce.
  • Dávejte pozor na limity. Každá politika WAF podporuje až 60 výjimek a každý Front Door podporuje celkem 60 výjimek napříč všemi příslušnými politikami. Jedna výjimka může obsahovat až 600 IP adres, 10 URI nebo 10 hlaviček požadavků.
  • Výjimky vyžadují novou generaci WAF enginu a spravovanou verzi pravidel DRS 2.1 nebo novější.

Použijte správný nástroj pro danou práci: výluky přeskočí kontrolu jednoho prvku požadavku (šumového cookie nebo hlavičky), zatímco zbytek stále kontrolují; Výjimky přeskakují konkrétní pravidla nebo sady pravidel pro požadavky na párování; vlastní pravidlo Povolit obchází vše kromě HTTP DDoS pravidel.

Important

Výjimky WAF a HTTP DDoS pravidla jsou v náhledu jak na Azure Front Door, tak Application Gateway WAF v2. Podívejte se na Dodatečné podmínky použití pro Microsoft Azure Previews.

Vyzvěte před blokováním

Blokování je hrubý nástroj během útoku L7: útočný provoz často přichází z IP adres a geografických oblastí, které také nesou skutečné uživatele. Výzvy vám umožňují oddělit automatizaci od lidí bez vedlejších škod v podobě přímého bloku a představují největší změnu v tom, jak Azure WAF řeší záplavy na úrovni L7 ve srovnání se strategií omezení tarifů pouze na bloky.

  • JavaScriptová výzva je neviditelná výzva, která nevyžaduje žádnou lidskou interakci. Pokud prohlížeč úspěšně vypočítá výzvu, WAF ověří klienta jako nebota a pokračuje ve vyhodnocování zbývajících pravidel; Požadavky, které selžou, jsou blokovány. Použijte to jako výchozí výzvu pro obecný webový provoz. Požadavky na koncový bod výzvy nejsou přeposílány na backend a nepočítají se do omezení rychlosti.
  • CAPTCHA je interaktivní výzva, která vyžaduje účast uživatele, nejlépe vyhrazenou pro vysoce hodnotné toky, jako je přihlášení, registrace a platba, kde je automatizované zneužívání drahé a pár sekund uživatelského tření je přijatelné. Platnost cookie výzvy je konfigurovatelná v nastavení politik mezi 5 a 1 440 minutami, s výchozím limitem 30 minut. CAPTCHA účtuje další poplatky založené na spotřebě.

Před nasazením si naplánujte omezení obou funkcí:

  • AJAX a API volání nejsou podporovány. Nekladěte výzvy před API trasy. Používejte tam místo toho omezení rychlosti a pravidla pro doladění.
  • Výzvy jsou navrženy pro HTML zdroje, nikoli pro vložené obrázky, CSS nebo JavaScript soubory.
  • Při prvním požadavku, který spustí výzvu, je tělo POST omezeno na 64 KB v Azure Front Door a 128 KB v Application Gateway.
  • Ani jedna funkce nepodporuje Internet Explorer; obě podporují aktuální verze Microsoft Edge, Chrome, Firefox a Safari.
  • JavaScriptová výzva je znovu vydávána při změně IP adresy klienta a u požadavků na křížové původy (CORS).
  • Na Application Gateway je JavaScript challenge v náhledu a není podporován pro vlastní pravidla rychlostních limitů. Application Gateway for Containers WAF to nepodporuje.

Omezování rychlosti

Minimálně vytvořte pravidlo limitu rychlosti, které blokuje vysokou míru požadavků od libovolného klienta. Nastavte toto pravidlo jako pravidlo s nejnižší prioritou (nejvyšší číselnou hodnotou), abyste nejprve vyhodnocovali konkrétnější limity nebo pravidla pro dorovnání.

Azure Front Door

  • Omezení rychlosti platí na každou IP adresu socketu, což je adresa klienta, který otevírá TCP spojení s Azure Front Door a může být spíše proxy než koncovým uživatelem.
  • Prahy jsou hodnoceny v pevném okně jedné až pěti minut. Jakmile je práh překročen, Azure Front Door zablokuje veškerý provoz, který odpovídá pravidlu po zbytek okna. Použijte pětiminutové okno pro zmírnění HTTP flood: útočník zablokovaný v první minutě zůstává blokován po zbývající čtyři minuty.
  • Větší okna s nejmenším přijatelným prahem jsou nejúčinnější konfigurací proti DDoS. Větší okna a vyšší prahové hodnoty také vynucují blíže nakonfigurovanému prahu. Při velmi nízkých prahových hodnotách (přibližně pod 200 požadavků za minutu) mohou některé požadavky nad touto hranicí projít, protože požadavky od jednoho klienta mohou dopadnout na servery Front Door, jejichž čítače ještě nejsou obnoveny.
  • Pravidla pro omezení rychlosti podporují pouze akce Log a Block ; Povolení není podporováno.
  • Aplikujte pravidlo na veškerý provoz tak, že se spojí na hlavičku Host s délkou větší než 0, protože každý platný požadavek na Azure Front Door má takovou hlavičku.

WAF Application Gateway v2

  • Omezení rychlosti používá algoritmus s posuvným oknem . Veškerý odpovídající provoz je ukončen během prvního okna, ve kterém je práh překročen. Od druhého okna je povolen provoz až do prahu, což způsobuje zpomalovací efekt místo úplného výpadku pro shodné klienty.

  • Pravidla vyžadují GroupByUserSession, který řídí, jak jsou požadavky počítány. Tato funkce vám umožní omezit rychlost něčím jiným než IP klientem:

    GroupByVariable Použijte ji, když
    ClientAddr (výchozí) Normální případ s nezávislými čítači na zdrojovou IP adresu
    ClientAddrXFFHeader Váš gateway je za CDN nebo proxy a skutečná IP adresa klienta je v X-Forwarded-For
    GeoLocation Chcete omezit provoz podle země/regionu během geograficky koncentrované povodně
    GeoLocationXFFHeader Stejné jako výše, s použitím IP adresy v X-Forwarded-For
    None Jeden sdílený čítač pro úzce srovnatelný vzor, například přihlašovací stránku nebo seznam podezřelých uživatelských agentů

  • Pravidla pro omezení rychlosti vyžadují nejnovější engine WAF (pro výchozí sadu pravidel vyberte CRS 3.2 nebo novější) a nejsou podporována v cloudech bez air-distance.

  • Application Gateway počítá prahy nezávisle pro každý koncový bod , ke kterému je politika připojena. Jediná politika na pět posluchačů udržuje pět sad čítačů.

  • Prahy nejsou přesně vynucovány, takže nepoužívejte omezení rychlosti pro detailní řízení provozu. Použijte ho k omezení anomálních rychlostí a udržení dostupnosti. Buďte obzvlášť opatrní u pravidel s širokým porovnáním, která používají GeoLocation nebo None; špatně zvolený práh může způsobit časté krátké výpadky u legitimního provozu.

Nastavte geograficky orientované prahy

Jeden globální práh musí být dostatečně štědrý pro vaši nejrušnější zemi, což ho činí příliš štědrým všude jinde. Většina aplikací má v době míru silně zkreslený geografický profil – několik zemí nebo regionů produkuje téměř veškerý legitimní provoz, zatímco ostatní produkují jen kapky. Útočný provoz tuto distribuci málokdy respektuje. Stanovení prahů velikosti podle geografie proměňuje tuto asymetrii jak v detekční signál, tak v kontrolu zmírnění.

Začněte měřením rozložení v době míru alespoň na celý týden, aby byly zastoupeny efekty ve všední dny, o víkendu a časových pásmech:

  • Na Azure Front Door rozdělte metriku počtu požadavků podle dimenze ClientCountry.

  • V Log Analytics odvozte zemi z IP adresy klienta v přístupovém logu:

    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

Poté výsledky seskupte do úrovní a nastavte pro každou z nich práh:

Úroveň Mírový podíl Doporučená léčba
Primární trhy Země, které tvoří většinu vašeho provozu Štědrý práh na klienta, zřízený z p99 dané země, takže skuteční uživatelé nejsou nikdy ovlivněni
Sekundární trhy Významná, ale skromná návštěvnost Přísnější práh na klienta, oproti p99 dané země místo globálního
Geografie dlouhých ocasů Malý proud legitimního provozu Agresivní práh, nebo výzva místo bloku
Geografické oblasti, které neobsluhujete Efektivně nula Blokujte přímo nebo přesměrujte na statickou stránku

Jak implementujete úrovně, závisí na platformě:

  • Application Gateway WAF v2 – použijte GroupByVariable: GeoLocation (nebo GeoLocationXFFHeader za CDN či proxy), aby veškerý provoz z jedné geografické oblasti sdílel čítač, a vytvořte jedno pravidlo rychlostního limitu na úroveň s vlastním prahem. Protože narušení působí proti každému klientovi v dané oblasti, dimenzujte tyto prahy konzervativně a nejprve je ověřujte v Log action: nesprávně nastavené pravidlo široké shody může způsobit časté krátké výpadky u legitimního provozu.
  • Azure Front Door – čítače jsou na každou IP adresu socketu, takže úrovně vytvářejte podle geo-match podmínek: jedno pravidlo rychlostního limitu na úroveň, odpovídající příslušným zemím, každé s vlastním prahem. Každý klient v dlouhoocasé geografii pak získává mnohem nižší strop než klienti na vašich primárních trzích, aniž by chování jednoho klienta ovlivňovalo ostatní.

Několik postupů, které to udržují udržitelné:

  • Seřaďte pravidla od nejkonkrétnějšího po nejmenší: pravidla primárního trhu s vyšší prioritou (nižší číselná hodnota), pak sekundární, nakonec dlouhocasá, přičemž globální univerzální pravidlo je vaším nejnižším prioritním limitem sazby.
  • Preferujte výzvu před blokem pro dlouhé úseky. Provoz ze země s malým legitimním objemem je v souhrnu podezřelý, ale stále obsahuje skutečné uživatele – cestující, uživatele VPN a vzdálené zaměstnance.
  • Znovu měřte po marketingových uvedení na trh, regionálních expanzích a velkých produktových událostech. Konfigurace s ohledem na geografii je tak dobrá, jak dobrá je základní úroveň, ze které byla dimenzována.
  • Během incidentu sledujte opačný signál: země, která normálně přispívá 1% dopravy, najednou přispívá 40% je jedním z nejrychlejších způsobů, jak potvrdit, že vidíte útok, nikoli organický růst.

Vyberte si prah ze svého vlastního provozu

Použijte následující dotaz Log Analytics pro určení velikosti pravidla catch-all. Pro Application Gateway nahraďte FrontdoorAccessLog za ApplicationGatewayAccessLog.

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

Pro určení výše popsaných prahů podle geografie přidejte zemi do stejného dotazu:

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

Nastavte práh nad 99. percentilem mírové dopravy, ne na maximum. Maximální je obvykle crawler nebo špatně nakonfigurovaný klient, a jeho velikost je příliš štědrá na to, aby pomohla při útoku.

Vlastní pravidla pro cílené zmírnění škod

Vytvořte vlastní WAF pravidla pro blokování nebo omezení HTTP a HTTPS útoků, které mají identifikovatelné podpisy, například konkrétní uživatelský agent, hlavičku, cookie, vzor dotazového řetězce, URI nebo jejich kombinaci. Kromě párování řetězců mohou Azure Front Door WAF vlastní pravidla párovat na:

  • Geolokace: Zablokujte provoz mimo oblast služby nebo jej přesměrujte na statickou stránku.
  • Klientské IP adresy (CIDR) a IP restrikce pro adresy a rozsahy, které jste identifikovali jako škodlivé.
  • AS Number (ASN): Omezte záplavy pocházející od poskytovatele hostingu nebo tranzitní sítě, ze které vaši legitimní uživatelé nepocházejí, aniž byste vyjmenovali IP rozsahy.
  • Otisk prstu klienta (JA4): Spojení na otisku prstu JA4, hash odvozený z TLS handshake a HTTP charakteristik klienta. Protože nástroje pro útoky a klienti botnetů vytvářejí konzistentní otisk bez ohledu na IP adresu, ze které odesílají, je JA4 jedním z nejodolnějších podpisů dostupných během distribuovaného útoku: rotace mezi tisíci zdrojových IP adres nemění otisk prstu a blokování nebo omezení rychlosti na něm odstraní celý botnet jedním pravidlem. Ověřte si otisk prstu ve svých mírových záznamech, než ho začnete vymáhat. Populární prohlížeče a běžné SDK sdílejí otisky prstů mezi obrovským počtem legitimních uživatelů, takže neověřený blok JA4 může být velmi široký. Nejprve nasadit akci v Logu , potvrdit, že otisk se objevuje pouze v útočném provozu, poté přepnout na Blokování nebo pravidlo rychlostního limitu.
  • Kombinujte JA4 s dalšími stavy pro chirurgické zmírnění během incidentu. Například limit rychlosti místo blokování konkrétního JA4 otisku prstu a ASN, ze kterého uživatelům neobsloužíte, nebo JA4 otisku prstu a požadavkového URI.
  • Omezeníservisního tagu a velikosti u komponent požadavků.

Dvě zásadní praktiky během incidentu:

  • Vytvořte pravidla Povolit shodu pro známý legitimní provoz, abyste snížili falešné poplachy, a dejte jim vyšší prioritu (nižší číselnou hodnotu) než vaše pravidla blokování a omezení rychlosti. Pamatujte, že pravidlo Povolit obchází jiné inspekce WAF, ale neobchází HTTP DDoS pravidla.
  • Vyhodnocení pravidla končí u jakékoli akce kromě logu a prioritní čísla musí být jedinečná. Rezervujte blok nízkoprioritních čísel pro nouzová pravidla, abyste mohli během útoku vložit jedno bez přečíslování.

Spravovaná pravidla nejsou zaměřena na obranu proti DDoS, ale chrání před jinými běžnými útoky a měla by zůstat aktivní. Viz Managed rules (Azure Front Door) nebo Managed rules (Application Gateway).

Chraňte původ

  • Uzamkněte přístup k veřejným IP adresám na původním místě a omezte příchozí provoz tak, aby k němu přistupoval pouze Azure Front Door nebo Application Gateway. Řiďte se pokyny pro zabezpečení provozu na Azure Front Door origins.
  • Ujistěte se, že ve virtuální síti Application Gateway nejsou žádné veřejně vystavené IP adresy.
  • Enable caching on Azure Front Door. Cacheované odpovědi absorbují špičkový objem na okraji a snižují frekvenci požadavků, která dosáhne vašeho výchozího místa, což často znamená rozdíl mezi zhoršeným výkonem a výpadkem.
  • Měřítko původu s headroomem. Automatizovaná i manuální opatření trvají čas, než se aktivují; Rezervní kapacita tuto mezeru pokrývá.

Reagujte na aktivní útok

  1. Potvrďte, že jde o útok, ne o organický růst. Zkontrolujte WAF a přístupové logy kvůli náhlé změně frekvence požadavků, počtu IP adres klienta, geografického složení, distribuce uživatelských agentů a požadovaných URI.
  2. Zkontrolujte, co už zmírňuje. Potvrďte, že HTTP DDoS pravidla jsou aktivní, a zkontrolujte jeho bloky podle názvu pravidla. Na Application Gateway zkontrolujte také metriky bloků pro penalizaci a bloky penalizačních boxů , protože v logech se objevuje pouze první blok na IP adresu. Recenzujte shody pravidel o limitu rychlosti.
  3. Porovnejte geografický mix s vaším výchozím stavem. Země, která obvykle přispívá malou částí dopravy a najednou ji ovládá, je rychlý, vysoce spolehlivý signál útoku. Také vám řekne, kterou úroveň pravidel sazeb zpřísnit jako první.
  4. Zvyšujte citlivost před psaním nových pravidel. Zvýšení citlivosti HTTP DDoS pravidel nebo snížení stávajícího limitu rychlosti je rychlejší a bezpečnější než vytváření nového pravidla pod tlakem.
  5. Místo toho, abyste blokovali místa, kde je provoz smíšený, se zpochybňujte. Aplikujte JavaScript challenge na postižené HTML trasy a CAPTCHA na citlivé toky.
  6. Cílové pravidlo napište až poté, co identifikujete trvalý podpis: ASN, otisk klienta, kombinaci hlavičky, geografii nebo vzor URI. Nejprve ho nasadit v Log action, pokud vzor odpovídá i skutečným uživatelům.
  7. Udržujte origin chráněný během ladění: ověřte, že je caching zapnutý, potvrďte uzamčení originu a škálujte dál.
  8. Po incidentu přeřaďte hranice rychlostních limitů na základě nových dopravních dat a ponechejte nouzová pravidla, která se osvědčila jako přesná, v režimu Log, pokud nechcete, aby byla neustále vynucována.

Analyzujte WAF a přístupové logy

Monitorujte provoz pomocí logů Azure WAF na anomálie a používejte je k identifikaci podezřelých IP adres, které odesílají neobvykle velké množství požadavků, neobvyklé řetězce uživatelských agentů nebo anomální vzory dotazovacích řetězců.

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Azure Application Gateway

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Top talkeři a top user agenti nad oknem útoku (zobrazen Azure Front Door; náhrada ApplicationGatewayAccessLog za Application Gateway):

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

Pro více informací viz Azure WAF with Azure Front Door a Azure WAF with Azure Application Gateway.

Související obsah

  • Last updated on