Applikationsskydd (lager 7) DDoS

Gäller för: ✔️ Application Gateway V2 ✔️ Front Door Premium

Azure Web Application Firewall (WAF) inkluderar flera försvarsmekanismer som hjälper till att förhindra distribuerade överbelastningsattacker (DDoS). DDoS-attacker kan riktas mot både nätverksskiktet (L3/L4) och programskiktet (L7). Azure DDoS Protection skyddar dig mot volymtriska attacker på stora nätverksnivå. Azure WAF, som körs på layer 7, skyddar webbprogram mot L7 DDoS-attacker, till exempel HTTP-översvämningar. Tillsammans förhindrar dessa försvar att angripare når din applikation och påverkar dess tillgänglighet och prestanda.

Attacker på applikationslagret är billiga att starta och svåra att skilja från legitim trafik: varje begäran ser giltig ut i sig, och det är endast den aggregerade hastigheten, distributionen och klientmixen som avslöjar attacken. Effektivt L7-försvar bygger därför mindre på en enskild kontroll och mer på en lager-på-lager-konfiguration som redan finns på plats innan en attack startar.

Välj dina försvarsskikt

Använd följande modell när du planerar L7 DDoS-skydd. Varje lager fångar trafik som lagret ovanför inte gör.

Checklista för baslinjekonfiguration

Slutför dessa steg innan du blir attackerad. Justera dem efter dina ansökningskrav.

1. Distribuera Azure WAF med Azure Front Door Premium eller Application Gateway WAF v2 för att skydda mot L7-applikationslagsattacker.
2. Byt WAF-policyn till förebyggande läge. En policy i detekteringsläge loggar endast och blockerar inte trafiken. Verifiera och justera policyn mot produktionstrafik först för att minska falska positiva, och slå sedan på förebyggande.
3. Tilldela HTTP DDoS-regeluppsättningen (tillgänglig både i Azure Front Door Premium och Application Gateway WAF v2) så att automatiserad mitigation lär sig din trafikbaslinje innan du behöver den.
4. Aktivera Bot Manager-hanterade regeluppsättningen för att identifiera och agera på kända dåliga botar.
5. Konfigurera minst en allomfattande hastighetsgränsregel (se Hastighetsbegränsning).
6. Skala upp ditt ursprungsantal instanser så att det finns tillräckligt med ledig kapacitet, och ställ in Application Gateway på autoskalering utan att kräva ett lågt maxantal instanser.
7. Aktivera caching på Azure Front Door så att plötslig topptrafik absorberas vid kanten istället för vid din ursprungsplats.
8. Täck din L3/L4-exponering, som skiljer sig mellan plattformar. Se Plattform DDoS-skyddet skiljer sig mellan plattformar. Lås din origin så att den endast accepterar trafik från Azure Front Door eller Application Gateway.
9. Slå på diagnostisk loggning till Log Analytics och bygg frågorna i Analyze WAF och åtkomstloggarinnan en incident.

Plattformens DDoS-skydd skiljer sig mellan plattformar

L7-försvar spelar bara roll om de underliggande publika IP-adresserna överlever en volymetrisk attack, och de två Azure WAF-plattformarna inte startar från samma plats.

Azure Front Door har plattformsskydd för DDoS som standard. Azure Front Door är en globalt distribuerad edge-tjänst, och dess edge skyddas av Azure:s infrastruktur DDoS-skydd utan extra kostnad och utan konfiguration. Trafiken avslutas vid Front Door-kanten istället för vid en IP-adress du äger, så det finns ingen publik IP för en angripare att rikta in sig på vid L3/L4. Det skyddet är inneboende i plattformen, så du köper eller aktiverar inget för att få det.

Application Gateway behöver Azure DDoS Network Protection. En applikationsgateway är en regional resurs med en publik IP-adress i ditt eget virtuella nätverk. Azure:s standardskydd på infrastrukturnivå skyddar Azure-plattformen, men ger dig inte justerad, resursbaserad mitigation, telemetri eller attackrapportering för den IP:n. För att skydda gatewayens publika IP mot L3/L4-volymetriska attacker, aktivera Azure DDoS Network Protection på det virtuella nätverk som innehåller den. Detta är en betald, separat inköpt tjänst.

Praktiska konsekvenser när du väljer eller utformar en utplacering:

• Om du är bakom Azure Front Door, budgetera för L7-kontroller; L3/L4-kantskyddet finns redan där.
• Om du använder Application Gateway och inte har aktiverat DDoS Network Protection kan dina WAF-regler vara perfekt justerade och ändå kringgås av en volymetrisk attack mot gatewayens publika IP. Aktivera det.
• I båda fallen kräver Origins publika IP-adresser du exponerar fortfarande Azure DDoS Network Protection, plus låsning så att endast WAF-tjänsten kan nå dem. En skyddad frontend framför en oskyddad, offentligt tillgänglig plats är inte skyddad.

För mer information, se Azure DDoS Protection översikt och Protect your application gateway with Azure DDoS Network Protection.

Automatiserat skydd med HTTP DDoS-regelverket (förhandsvisning)

Statiska kontroller som IP-filter, geofilter och fasta hastighetsgränser kan ofta inte hänga med i distribuerade botnät: trösklarna är gissningar, de är alltid påslagna och du måste justera dem i takt med trafikmönstren. HTTP DDoS-regelverket är Azure WAF:s första automatiserade lager 7-skyddsmodell som lär sig, upptäcker och försvarar med minimal användarkonfiguration. Det finns tillgängligt i förhandsversion på både Azure Front Door Premium och Application Gateway WAF v2. När den väl är tilldelad baseline den kontinuerligt normal trafik och, när överspänningar indikerar en attack, blockerar den selektivt angripande klienter utan behov av nödjustering.

Designen är densamma på båda plattformarna i de saker som är viktigast:

• Två trösklar, utvärderade tillsammans. Regelverket lär sig både en global tröskel (per Front Door-profil eller per applikationsgateway) och individuella IP-baserade tröskelvärden. IP-baserade tröskelvärden tillämpas endast efter att den globala tröskeln har överskridits. Denna design förhindrar att regelsystemet verkar på toppar från några IP-adresser om de inte faktiskt pressar total trafik över normen.
• Scoped per resurs. Trösklar lärs ut på global resursnivå. Om du tilldelar en WAF-policy med regeluppsättningen till flera Front Door-profiler eller flera gateways, beräknar tjänsten trösklar separat för var och en.
• Känslighet. Varje regel erbjuder tre känslighetsnivåer. Högre känslighet ger en lägre tröskel; Lägre känslighet ger en högre tröskel. Medium är standard- och rekommenderad inställning.
• Utvärderingsorder. WAF utvärderar HTTP DDoS-regelverket först, även innan anpassade regler. En anpassad regel med en Tillåt-åtgärd kringgår all annan WAF-inspektion, men den kringgår inte HTTP DDoS-regelsystemet.
• Kringgår regelsystemet för betrodd trafik. En anpassad regel med en Tillåt-åtgärd hjälper inte här – den kringgår alla andra regeluppsättningar men inte HTTP DDoS-regelsystemet. Använd istället WAF-undantag, som du kan anpassa till en specifik regel, regelgrupp eller ett helt hanterat regelset, inklusive HTTP DDoS-regelsystemet. Se Exempt trusted traffic with exception.
• Kräver uthållig trafik. Regelverket kan bara agera när det lär sig pålitliga baslinjer. Om en resurs inte får tillräckligt med trafik under inlärningsfasen kommer regelsystemet inte att upptäcka eller skydda förrän det är gjort. Se plattformstabellen för det specifika kravet.

Plattformsskillnader

Regler för regeluppsättning

Regelverket innehåller för närvarande två regler. Varje regel upprätthåller sina egna trafikbaslinjer och kan konfigureras med sin egen känslighet och handling:

Utvisningsbåset

Båda plattformarna mildrar genom en straffbox. När trafik från en klient överskrider tröskeln för en av regelsettets regler, placeras klientens IP-adress i straffboxen och blockeras av WAF under straffboxens varaktighet, vilket är 15 minuter på Application Gateway. När perioden är slut återfår IP-adressen åtkomst om den inte överskrider tröskeln igen, vilket återlämnar den till straffboxen.

Denna design är viktig för hur du läser din telemetri: endast den initiala regelträffen loggas. Ytterligare blockerade förfrågningar medan IP-adressen redan finns i straffboxen loggas inte på Front Door, så loggbaserade räkningar underskattar antalet blockerade förfrågningar. På Application Gateway använder du Penalty box blocks-metriken för det verkliga blockantalet och Penalty box-storleken för hur många IP-adresser som för närvarande straffas.

Övervakning under förhandsvisning

När en IP-adress överskrider en tröskel registreras en loggpost med en Block-åtgärd för HTTP DDoS-regelverket och WAF Managed Rule Match-metriken ökar i intervaller.

• Front Door: använd Web Application Firewall Request count-metrik filtrerad efter regelnamn för att räkna block, och Web Application Firewall HTTPDDoSRuleset Is Active-metriken, som rapporterar 1 när inlärningen är klar och regelsystemet är redo att agera på trafik som bryter mot de inlärda tröskelvärdena.
• Application Gateway: varje efterföljande blockerad begäran från en straffad IP-adress ökar Managed Rule Match-metriken, och Penalty box-storleken och Penalty box block-måtten spårar straffboxen direkt.

Undantag för betrodd trafik med undantag

Hälsoprober, syntetisk övervakning, belastningstester, partnerintegrationer och interna batchjobb genererar trafik som ser ut som en flod men inte är det. Historiskt sett finns det inget sätt att undanta dem från DDoS-regelsystemet, eftersom en anpassad Tillåt-regel kringgår Standardregeluppsättningen, Kärnregeluppsättningen och Bot Protection-regeluppsättningen men medvetet inte kringgår HTTP DDoS-regeluppsättningen.

WAF-undantag minskar det gapet. Ett undantag kringgår WAF-inspektion för förfrågningar som matchar specifika attribut, begränsade till en enda regel, en regelgrupp eller ett helt hanterat regelset. Du kan tillämpa undantag på HTTP DDoS-regelverket samt på DRS, CRS och botskydd.

Undantag matchar på:

• Fjärr-IP-adress (Equals eller IP Match), vilket är det vanliga valet för att undanta kända övervaknings-, lasttest- eller partnerkällsintervall från DDoS-regelverket
• Begär URI
• Begär headernamn och värde, matchat med Equals, Starts with, Ends with eller Contains

Vägledning för att använda undantag i DDoS-regelsystemet:

• Begränsa så snävt som möjligt. Föredra ett undantag per regel framför att undanta hela regelsystemet. Ett brett undantag ger en angripare en dokumenterad väg runt din automatiserade åtgärd. Om en lastgenerator bara behöver lättnad från regel 500100, undanta den inte från 500110 också.
• Undantagna källor, inte vägar. Ett IP-baserat undantag för en känd testhärva är begränsad. Ett URI-baserat undantag på en offentlig endpoint är en öppen dörr för alla som hittar det.
• Gå igenom dem enligt ett schema. Undantag som lagts till för ett engångstest kan fortfarande gälla ett år senare.
• Var uppmärksam på gränserna. Varje WAF-policy stöder upp till 60 undantag, och varje Front Door stöder totalt 60 över alla tillhörande policyer. Ett enda undantag kan innehålla upp till 600 IP-adresser, 10 URI:er eller 10 begäransökningshuvuden.
• Undantag kräver nästa generations WAF-motor och managed ruleset-versionen DRS 2.1 eller senare.

Använd rätt verktyg för jobbet: undantag hoppar över inspektion av ett element i en förfrågan (en brusig cookie eller header) samtidigt som resten fortfarande inspekteras; undantag hoppar över specifika regler eller regeluppsättningar för matchningsförfrågningar; en anpassad Tillåt-regel kringgår allt utom HTTP DDoS-regelsystemet.

Utmana innan du blockerar

Blockering är ett trubbigt verktyg under en L7-attack: attacktrafik anländer ofta från IP-adresser och geografier som också bär riktiga användare. Utmaningar låter dig separera automatisering från människor utan den kollaterala skadan av en total blockering, och de är den största förändringen i hur Azure WAF hanterar L7-översvämningar jämfört med en blockbaserad hastighetsbegränsning.

• JavaScript-utmaningen är en osynlig utmaning som inte kräver någon mänsklig interaktion. Om webbläsaren beräknar utmaningen framgångsrikt validerar WAF klienten som icke-bot och fortsätter att utvärdera de återstående reglerna; Förfrågningar som misslyckas blockeras. Använd det som standardutmaning för allmän webbtrafik. Förfrågningar till utmaningsändpunkten vidarebefordras inte till din backend och räknas inte mot hastighetsbegränsning.
• CAPTCHA är en interaktiv utmaning som kräver användarmedverkan och är bäst anpassad för högvärdiga flöden som inloggning, registrering och utcheckning, där automatiserat missbruk är dyrt och några sekunders användarfriktion är acceptabelt. Valideringen av utmaningscookien kan konfigureras i policyinställningar mellan 5 och 1 440 minuter, med en standardtid på 30 minuter. CAPTCHA medför ytterligare användningsbaserade avgifter.

Planera utifrån begränsningarna i båda funktionerna innan du implementerar dem:

• AJAX- och API-anrop stöds inte. Placera inte utmaningar framför API-rutter. Använd regler för hastighetsbegränsning och matchning där istället.
• Utmaningar är utformade för HTML-resurser, inte för inbäddade bilder, CSS eller JavaScript-filer.
• Vid den första förfrågan som utlöser en utmaning är POST-kroppen begränsad till 64 KB på Azure Front Door och 128 KB på Application Gateway.
• Ingen av funktionerna stöder Internet Explorer; båda stöder nuvarande versioner av Microsoft Edge, Chrome, Firefox och Safari.
• JavaScript-utmaningen återutfärdas när en klients IP-adress ändras och för cross-origin (CORS)-förfrågningar.
• På Application Gateway är JavaScript-utmaningen i förhandsvisning och stöds inte för anpassade hastighetsbegränsningar. Application Gateway for Containers WAF stöder det inte.

Begränsning av hastighet

Som minimum, skapa en hastighetsgränsregel som blockerar en hög hastighet av förfrågningar från en enskild klient. Sätt denna regel som din lägsta prioritet (högsta numeriska värde) hastighetsgränsregel, så att mer specifika regler för hastighetsgräns eller matchning utvärderas först.

Azure Front Door-tjänsten

• Hastighetsbegränsningar gäller per socket-IP-adress, vilket är adressen till klienten som öppnar TCP-anslutningen till Azure Front Door och kan vara en proxy snarare än slutanvändaren.
• Trösklar utvärderas under ett fast fönster på en eller fem minuter. När tröskeln har passerats blockerar Azure Front Door all trafik som matchar regeln för resten av fönstret. Använd femminutersfönstret för HTTP-översvämningsskydd: en angripare som blockeras under den första minuten förblir blockerad under de återstående fyra.
• Större fönster med den lägsta acceptabla tröskeln är den mest effektiva anti-DDoS-konfigurationen. Större fönster och högre tröskelvärden gör också att det ligger närmare den konfigurerade tröskeln. Vid mycket låga tröskelvärden (under ungefär 200 förfrågningar per minut) kan vissa förfrågningar över tröskeln komma igenom, eftersom förfrågningar från en klient kan hamna på Front Door-servrar vars räknare ännu inte är uppdaterade.
• Regler för hastighetsgränser stödjer endast Logg- och Blockåtgärder ; Allow stöds inte.
• Tillämpa en regel på all trafik genom att matcha på en Host header med längd större än 0 eftersom varje giltig förfrågan till Azure Front Door har en.

Application Gateway WAF v2

• Hastighetsbegränsning använder en glidande fönsteralgoritm . All matchande trafik släpps under det första fönstret då tröskeln bryts. Från det andra fönstret och framåt tillåts trafik upp till tröskeln, vilket skapar en strypeffekt snarare än ett totalt avbrott för att matcha klienter.

• Regler kräver en GroupByUserSession, som styr hur förfrågningar räknas. Denna funktion låter dig begränsa hastigheten med något annat än klient-IP:

  GroupByVariable	Använd den när
  ClientAddr (standardinställning)	Normalt fall med oberoende räknare per käll-IP
  ClientAddrXFFHeader	Din gateway sitter bakom ett CDN eller en proxy och den riktiga klient-IP:n finns i X-Forwarded-For
  GeoLocation	Du vill begränsa trafiken per land/region under en geografiskt koncentrerad översvämning
  GeoLocationXFFHeader	Samma som ovan, med IP-adressen i X-Forwarded-For
  None	En enda delad räknare för ett snävt matchat mönster, såsom en inloggningssida eller en lista över misstänkta användaragenter

• Regler för hastighetsbegränsningar kräver den senaste WAF-motorn (välj CRS 3.2 eller senare som standardregeluppsättning) och stöds inte i moln med luftgap.

• Application Gateway räknar tröskelvärden oberoende för varje endpoint som policyn är kopplad till. En enda policy med fem lyssnare upprätthåller fem uppsättningar räknare.

• Trösklar upprätthålls inte exakt, så använd inte hastighetsbegränsning för finjusterad trafikkontroll. Använd det för att mildra avvikande hastigheter och upprätthålla tillgängligheten. Var särskilt försiktig med regler för bred matchning som använder GeoLocation eller None; en dåligt vald tröskel kan orsaka frekventa korta avbrott för legitim trafik.

Sätt geografimedvetna trösklar

En enda global tröskel måste vara tillräckligt generös för ditt mest trafikerade land, vilket gör den alldeles för generös överallt annars. De flesta applikationer har en starkt snedvriden geografisk profil i fredstid – ett fåtal länder eller regioner producerar nästan all legitim trafik, och resten ger en liten ström. Attacktrafik respekterar sällan den fördelningen. Storlekströskelvärden per geografi omvandlar den asymmetrin till både en detektionssignal och en åtgärdskontroll.

Börja med att mäta din fredstidsfördelning över minst en hel vecka, så att veckodags-, helg- och tidszonseffekter representeras:

• På Azure Front Door, dela upp Request count-metriken efter ClientCountry-dimensionen.

• I Log Analytics, härled landet från klientens IP-adress i åtkomstloggen:

  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
  

Gruppera sedan resultaten i nivåer och sätt en tröskel för varje:

Hur du implementerar nivåerna beror på plattformen:

• Application Gateway WAF v2 – använd GroupByVariable: GeoLocation (eller GeoLocationXFFHeader bakom ett CDN eller proxy) så att all trafik från en geografisk del delar en räknare, och skapa en hastighetsgränsregel per nivå med egen tröskel. Eftersom ett intrång påverkar alla klienter i den geografin, skala dessa trösklar konservativt och validera dem först i Logg-åtgärden: en felaktigt konfigurerad bred geografisk regel kan orsaka frekventa korta avbrott för legitim trafik.
• Azure Front Door – räknare är per socket-IP-adress, så bygg nivåerna med geo-match-villkor istället: en hastighetsgränsregel per nivå, matchad i relevanta länder, varje med sin egen tröskel. Varje kund i en long-tail-geografi får då en mycket lägre takhöjd än kunder på dina primära marknader, utan att en klients beteende påverkar de andra.

Några metoder som håller detta hållbart:

• Ordna reglerna från mest specifika till minst: primärmarknadsregler med högre prioritet (lägre numeriskt värde), sedan sekundära, sedan långsvans, med den globala catch-all som din lägsta prioritetsgräns.
• Föredra en utmaningsåtgärd framför ett block för långsvansgeografier. Trafik från ett land med liten legitim volym är misstänkt i hög grad men innehåller ändå riktiga användare – resenärer, VPN-användare och distansanställda.
• Mät om efter marknadsföringslanseringar, regionala expansioner och stora produktevenemang. En geografiskt medveten konfiguration är bara så bra som den baslinje den dimensionerades från.
• Var uppmärksam på den omvända signalen under en incident: ett land som normalt bidrar med 1% trafik och plötsligt bidrar med 40% är ett av de snabbaste sätten att bekräfta att du ser en attack snarare än organisk tillväxt.

Välj en tröskel från din egen trafik

Använd följande Log Analytics-fråga för att dimensionera catch-all-regeln. För Application Gateway, ersätt med FrontdoorAccessLogApplicationGatewayAccessLog.

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

För att dimensionera de tidigare beskrivna gränsvärdena per geografi, lägg till landet i samma fråga:

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

Sätt tröskeln över 99:e percentilen för fredstidstrafik, inte på maxnivå. Maximalt är vanligtvis en crawler eller en felkonfigurerad klient, och att dimensionera den gör regeln för generös för att hjälpa under en attack.

Anpassade regler för riktad militering

Skapa egna WAF-regler för att blockera eller begränsa hastighetsbegränsningar på HTTP- och HTTPS-attacker som har identifierbara signaturer, såsom en specifik användaragent, header, cookie, frågesträngsmönster, URI eller en kombination av dessa. Utöver strängmatchning kan Azure Front Door WAF:s anpassade regler matchas på:

• Geolokalisering: Blockera trafik utanför ditt tjänsteområde, eller omdirigera den till en statisk sida.
• Klient-IP-adress (CIDR) och IP-begränsningar listar adresser och intervall du identifierat som skadliga.
• AS-nummer (ASN): Minska översvämningar som kommer från en hostingleverantör eller transitnätverk som dina legitima användare inte kommer ifrån, utan att ange IP-intervall.
• Klientfingeravtryck (JA4): Matchning på JA4-fingeravtrycket, en hash härledd från klientens TLS-handshake och HTTP-egenskaper. Eftersom attackverktyg och botnetklienter producerar ett konsekvent fingeravtryck oavsett IP-adress de skickar från, är JA4 en av de mest hållbara signaturerna som finns tillgängliga under en distribuerad attack: att rotera genom tusentals käll-IP-adresser ändrar inte fingeravtrycket, och blockering eller hastighetsbegränsning tar bort hela botnätet med en enda regel. Verifiera fingeravtrycket mot dina fredstidsloggar innan du upprätthåller det. Populära webbläsare och vanliga SDK:er delar fingeravtryck mellan enorma mängder legitima användare, så ett ovaliderat JA4-block kan vara extremt brett. Placera in i Logg-åtgärden först, bekräfta att fingeravtrycket bara visas i attacktrafik, och byt sedan till Blockera eller en hastighetsbegränsningsregel.
• Kombinera JA4 med andra tillstånd för kirurgisk kompensation under en incident. Till exempel, hastighetsgräns istället för att blockera ett specifikt JA4-fingeravtryck och ett ASN som du inte levererar användare från, eller ett JA4-fingeravtryck och en begäran om URI.
• Tjänstetagg och storleksbegränsningar på förfrågningskomponenter.

Två metoder som är viktiga under en incident:

• Skapa regler för tillåtelse av matchning för känd legitim trafik för att minska falska positiva och ge dem högre prioritet (lägre numeriskt värde) än dina block- och hastighetsgränsregler. Kom ihåg att en tillåt-regel kringgår andra WAF-inspektioner men inte kringgår HTTP DDoS-regelsystemet.
• Regelutvärdering stannar vid alla åtgärder utom Log, och prioritetsnumren måste vara unika. Reservera ett block med lågprioriterade nummer för nödregler så att du kan lägga in ett under en attack utan att behöva byta numrering.

Managed rules är inte inriktade på DDoS-försvar, men de skyddar mot andra vanliga attacker och bör förbli aktiverade. Se Managed rules (Azure Front Door) eller Managed rules (Application Gateway).

Skydda ursprunget

• Lås åtkomsten till publika IP-adresser på ursprungsadressen och begränsa inkommande trafik så att endast Azure Front Door eller Application Gateway kan nå den. Följ vägledningen för att säkra trafik till Azure Front Door origins.
• Säkerställ att inga offentligt exponerade IP-adresser finns i Application Gateways virtuella nätverk.
• Aktivera caching på Azure Front Door. Cachade svar absorberar toppvolym vid kanten och minskar förfrågningsfrekvensen som når din ursprungskanal, vilket ofta är skillnaden mellan försämrad prestanda och ett avbrott.
• Skalursprung med headroom. Automatiserade och manuella åtgärder tar tid att genomföra; Reservkapacitet täcker det gapet.

Svara på en aktiv attack

1. Bekräfta att det är en attack, inte organisk tillväxt. Kontrollera WAF- och åtkomstloggarna för en plötslig förändring i begäransökningsfrekvens, klient-IP-antal, geografisk mix, distribution av användaragenter och begärda URI:er.
2. Kolla vad som redan är mildrare. Bekräfta att HTTP DDoS-regelsystemet är aktivt och granska dess block efter regelnamn. På Application Gateway, kontrollera även måtten på Penalty box och Penalty box blocks , eftersom endast det första blocket per IP-adress finns i loggarna. Gå igenom matcher med reglerna för hastighetsgränser.
3. Jämför geografiska blandningen med din baslinje. Ett land som normalt bidrar med en liten andel av trafiken som plötsligt dominerar är en snabb, högkonfidensiell attacksignal. Den berättar också vilken nivå av gränsregler du ska skärpa först.
4. Öka känsligheten innan du skriver nya regler. Att öka känsligheten för HTTP DDoS-regelset eller sänka en befintlig hastighetsgräns är snabbare och säkrare än att skapa en ny regel under press.
5. Utmana snarare än blockera där trafiken är blandad. Applicera JavaScript-utmaning på berörda HTML-rutter och CAPTCHA på känsliga flöden.
6. Skriv en riktad regel först när du har identifierat en hållbar signatur: ASN, klientfingeravtryck, header-kombination, geografi eller URI-mönster. Distribuera det först i Logg-åtgärden om mönstret också matchar verkliga användare.
7. Håll originet skyddat medan du trimmar: kontrollera att caching är på, bekräfta att origin är låst och skala ut.
8. Efter incidenten, justera dina tröskelvärden för prisgränser mot den nya trafikdatan och behåll de nödregler som visat sig vara korrekta i loggläge om du inte vill att de ska tillämpas kontinuerligt.

Analysera WAF- och åtkomstloggar

Övervaka trafiken med Azure WAF-loggar för avvikelser och använd dem för att identifiera misstänkta IP-adresser som skickar ovanligt många förfrågningar, ovanliga användaragentsträngar eller avvikande frågesträngsmönster.

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Azure Application Gateway

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Topppratare och toppanvändaragenter över attackfönstret (Azure Front Door visas; ersättning ApplicationGatewayAccessLog för 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

För mer information, se Azure WAF med Azure Front Door och Azure WAF med Azure Application Gateway.

Relaterat innehåll

• HTTP DDoS regelset: Azure Front Door WAF | Application Gateway WAF
• WAF exceptions list: Azure Front Door WAF | Application Gateway WAF
• Rate limiting: Azure Front Door WAF | Application Gateway WAF
• WAF setup: Azure Front Door | Application Gateway
• Azure WAF JavaScript-utmaning
• Azure Front Door WAF CAPTCHA
• DDoS protection on Azure Front Door
• Azure DDoS Protection reference architectures
• Översikt över Azure DDoS Protection