DDoS-skydd på applikationslagernivå (lager 7)

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 finjustera först policyn mot produktionstrafik för att minska falska positiveringar, och aktivera sedan förebyggande läge.
3. Tilldela HTTP DDoS-regeluppsättningen (tillgänglig i både Azure Front Door Premium och Application Gateway WAF v2) så att den automatiska begränsningen lär sig din normala trafiknivå 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. Aktivera diagnostisk loggning till Log Analytics och skapa frågorna i Analysera WAF- och åtkomstloggarinnan en incident inträffar.

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 behöver de offentliga IP-adresserna för ursprungen som du exponerar fortfarande Azure DDoS Network Protection, samt låsas ned 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 Översikt över Azure DDoS Protection och Skydda din programgateway med 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 har tilldelats upprättar den kontinuerligt en baslinje för normal trafik och, när trafiktoppar tyder på en attack, blockerar den selektivt klienter som orsakar angreppet utan att någon akut finjustering krävs.

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 regeluppsättningen reagerar på trafiktoppar från ett fåtal IP-adresser om de inte faktiskt får den totala trafiken att överstiga det normala.
• Omfattar varje 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ärderingsordning. 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 Undanta betrodd trafik med undantag.
• 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 hanterar detta med hjälp av en penalty box. 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 tidsperioden löper ut återfår IP-adressen åtkomst, såvida den inte överskrider tröskeln igen, vilket gör att den hamnar i straffboxen på nytt.

Denna design är viktig för hur du läser din telemetri: endast den initiala regelträffen loggas. Ytterligare blockerade förfrågningar när IP-adressen redan är i straffboxen loggas inte i Front Door, så loggbaserade antal underskattar antalet blockerade förfrågningar. I Application Gateway använder du måttet Penalty box blocks för det faktiska antalet blockeringar och Penalty box size för hur många IP-adresser som för närvarande är föremål för sanktioner.

Övervakning under förhandsvisning

När en IP-adress överskrider ett tröskelvärde registreras en loggpost med en Block-åtgärd för HTTP DDoS-regeluppsättningen och WAF-måttet Managed Rule Match ökar.

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

Undanta 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 mot:

• 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ärans headernamn och -värde, som matchar Är lika med, Börjar med, Slutar med eller Innehåller

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 förbi din automatiska skyddsåtgärd. Om en lastgenerator bara behöver lättnad från regel 500100, undanta den inte från 500110 också.
• Undanta källor, inte sökvä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

Att blockera är ett trubbigt verktyg vid en L7-attack: attacktrafik kommer ofta från IP-adresser och geografiska områden som också används av verkliga 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

• Som standard gäller hastighetsbegränsningar 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. På Azure Front Door Premium kan du välja en annan gruppera efter-variabel för varje regel (förhandsversion):

  Gruppera efter	Använd den när
  SocketAddr (standardinställning)	Normalt fall med oberoende räknare per socket-IP-adress
  GeoLocation	Du vill begränsa trafiken per land/region under en geografiskt koncentrerad översvämning
  Asn	Du vill sätta ett tak för trafiken per nätverk, till exempel en hostingleverantör där ett botnät körs
  Ja4	Ett distribuerat angrepp roterar genom många IP-adresser men återanvänder samma klientprogramvara
  None	En enda delad räknare för ett snävt matchat mönster, som en inloggningssida

  AsngrupperingarnaGeoLocation använder socketens IP-adress. För mer information, se Trafik för grupphastighetsgräns (förhandsversion).

• Trösklar utvärderas under ett fast fönster på en eller fem minuter. När tröskeln överskrids blockerar Azure Front Door all trafik som matchar regeln under återstoden av tidsfö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.

• Reglerna för frekvensbegränsning stöder inte åtgärden Tillåt. Förutom Log och Block kan du använda JavaScript challenge eller CAPTCHA, så att klienter över tröskeln utmanas istället för att blockeras.

• Tillämpa en regel på all trafik genom att matcha mot ett Host-sidhuvud med en längd som är större än 0, eftersom varje giltig begäran till Azure Front Door innehåller ett.

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. Angreppstrafik följer 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:

• I Azure Front Door delar du måttet antal begäranden efter dimensionen ClientCountry.

• 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 – som standard är räknarna per socket-IP-adress, så bygg nivåerna med geo-matchningsvillkor: en hastighetsgränsregel per nivå, matchad mot relevanta länder eller regioner, var och en med sin egen tröskel per klient. Varje kund i en geografi med få kunder får då ett betydligt lägre tak än kunder på dina huvudmarknader, utan att en kunds beteende påverkar de andra. På Azure Front Door Premium kan du också gruppera regeln för en nivå efter GeoLocation (förhandsvisning) så att all trafik från varje land/region delar en räknare, som på Application Gateway. Samma försiktighet gäller: sätt dessa tröskelvärden konservativt och validera dem först med Logg-åtgärden.

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

• Ordna reglerna från de mest specifika till de minst specifika: regler för primärmarknaden med högre prioritet (lägre numeriskt värde), därefter regler för sekundärmarknaden, sedan long tail-regler, med den globala uppsamlingsregeln som regel för hastighetsbegränsning med lägst prioritet.
• 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 ett tröskelvärde baserat på 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å. Det högsta värdet utgörs vanligtvis av en crawler eller en felkonfigurerad klient, och att dimensionera efter det gör regeln alltför generös för att vara till hjälp under en attack.

Anpassade regler för riktade åtgärder

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 matcha mot:

• 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 loggar från fredstid innan du tillämpar 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. Distribuera först i åtgärden Logg, bekräfta att fingeravtrycket bara förekommer i attacktrafik och byt sedan till Blockera eller en regel för hastighetsbegränsning. På Azure Front Door Premium finns en rate limit-regel grupperad efter Ja4 (förhandsvisning) som automatiskt sätter ett tak för varje fingeravtryck, utan att du behöver identifiera attackfingeravtrycket först.
• 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 Tillåt-matchningsregler för känd legitim trafik för att minska antalet falska positiva resultat, och ge dem högre prioritet (lägre numeriskt värde) än dina blockerings- och frekvensbegränsningsregler. 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. Cachelagrade svar hanterar toppbelastningar i edge-lagret och minskar antalet förfrågningar som når din ursprungsserver, vilket ofta är skillnaden mellan försämrad prestanda och ett driftstopp.
• Skala ursprung med marginal. 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. Kontrollera vad som redan motverkar. Bekräfta att HTTP DDoS-regelsystemet är aktivt och granska dess block efter regelnamn. I Application Gateway bör du även kontrollera måtten Penalty box size och Penalty box blocks, eftersom endast det första blocket per IP-adress visas i loggarna. Gå igenom matcher med reglerna för hastighetsgränser.
3. Jämför geografiska blandningen med din baslinje. Ett land som normalt står för en liten andel av trafiken men plötsligt dominerar den är ett snabbt, tydligt tecken på en attack med hög säkerhet. 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-regeluppsättning: Azure Front Door WAF | Application Gateway WAF
• WAF-undantagslista: Azure Front Door WAF | Application Gateway WAF
• Hastighetsbegränsning: Azure Front Door WAF | Application Gateway WAF
• WAF setup: Azure Front Door | Application Gateway
• Azure WAF JavaScript-utmaning
• Azure Front Door WAF CAPTCHA
• DDoS-skydd i Azure Front Door
• Referensarkitekturer för Azure DDoS Protection
• Översikt över Azure DDoS Protection