Applicatie (laag 7) DDoS-bescherming

Van toepassing op: ✔️ Application Gateway V2 ✔️ Front Door Premium

Azure Web Application Firewall (WAF) bevat verschillende verdedigingsmechanismen die helpen om gedistribueerde denial of service (DDoS)-aanvallen te voorkomen. DDoS-aanvallen kunnen zowel de netwerklaag (L3/L4) als de toepassingslaag (L7) targeten. Azure DDoS Protection beschermt u tegen grote volumetrische aanvallen op de netwerklaag. Azure WAF, die op laag 7 werkt, beschermt webtoepassingen tegen L7 DDoS-aanvallen, zoals HTTP-overstromingen. Samen voorkomen deze verdedigingen dat aanvallers je applicatie bereiken en zo de beschikbaarheid en prestaties ervan beïnvloeden.

Aanvallen op applicatielaag zijn goedkoop te starten en moeilijk te onderscheiden van legitiem verkeer: elk verzoek lijkt op zichzelf geldig te zijn, en alleen de totale snelheid, distributie en clientmix onthullen de aanval. Effectieve L7-verdediging berust daarom minder op één enkele controle en meer op een gelaagde configuratie die al aanwezig is voordat een aanval begint.

Kies je verdedigingslagen

Gebruik het volgende model wanneer je L7 DDoS-bescherming plant. Elke laag vangt verkeer op wat de bovenliggende laag niet doet.

Laag Wat het doet Waar u deze kunt configureren
Platform DDoS-bescherming Absorbeert L3/L4 volumetrische aanvallen op de Azure edge en op je origin-publieke IP's Standaard ingebouwd in Azure Front Door; vereist Azure DDoS Network Protection voor Application Gateway publieke IP's en oorsprong publieke IP's
Geautomatiseerde L7-mitigatie Leert je normale verkeer en gaskleppen bij lastige klanten tijdens een piek, zonder noodafstelling HTTP DDoS ruleset (preview) on Azure Front Door Premium and Application Gateway WAF v2
Klantverificatie Scheidt mensen en legitieme clients van geautomatiseerd aanvalverkeer voordat het wordt geblokkeerd Bot Manager regelset, JavaScript-uitdaging, CAPTCHA
Snelheidsbeperking Beperkt hoeveel verzoeken een client, geografie of eindpunt kan versturen Tarieflimiet custom regels op Front Door en Application Gateway
Gerichte aangepaste regels Blokkeert een bekende aanvalsignatuur tijdens een incident Match aangepaste regels (geo, IP, ASN, client fingerprint, header, URI)
Oorsprongsbescherming Voorkomt dat aanvalsverkeer je compute bereikt Caching, origin lock-down, autoscale

Checklist voor basisconfiguraties

Voltooi deze stappen voordat je wordt aangevallen. Pas ze aan om aan je aanvraagvereisten te voldoen.

  1. Deploy Azure WAF met Azure Front Door Premium of Application Gateway WAF v2 om te beschermen tegen L7 application layer-aanvallen.
  2. Zet het WAF-beleid op preventiemodus. Een beleid in detectiemodus registreert alleen en blokkeert geen verkeer. Controleer en stel het beleid eerst af tegen productieverkeer om valse positieven te verminderen, en zet daarna preventie in.
  3. Wijs de HTTP DDoS-regelset toe (beschikbaar op zowel Azure Front Door Premium als Application Gateway WAF v2), zodat geautomatiseerde mitigatie je verkeersbasis leert voordat je het nodig hebt.
  4. Schakel de door Bot Manager beheerde regelsset in om bekende slechte bots te identificeren en erop te reageren.
  5. Configureer ten minste één catch-all tarieflimietregel (zie Snelheidslimiet).
  6. Schaal je origin-instantieaantal op zodat er voldoende reservecapaciteit is, en stel Application Gateway in om automatisch te schalen zonder een laag maximaal aantal instanties af te dwingen.
  7. Schakel caching in op Azure Front Door in zodat plotselinge piekverkeer aan de rand wordt opgenomen in plaats van bij je oorsprong.
  8. Dek je L3/L4-belichting, die per platform verschilt. Zie Platform DDoS-bescherming verschilt per platform. Sluit je oorsprong zodat het alleen verkeer van Azure Front Door of Application Gateway accepteert.
  9. Zet diagnostische logging in bij Log Analytics en bouw de queries in Analyze WAF en toegangslogsvóór een incident.

Platform DDoS-bescherming verschilt per platform

L7-verdedigingen zijn alleen van belang als de onderliggende publieke IP-adressen een volumetrische aanval overleven, en de twee Azure WAF-platforms niet vanaf dezelfde plek beginnen.

Azure Front Door heeft standaard platform DDoS-bescherming. Azure Front Door is een wereldwijd gedistribueerde edge-service, en de edge wordt beschermd door Azure's infrastructuur DDoS-bescherming zonder extra kosten en zonder configuratie. Het verkeer eindigt bij de Front Door edge in plaats van bij een IP-adres dat jij bezit, dus er is geen openbaar IP van jou dat een aanvaller kan targeten op L3/L4. Die bescherming is inherent aan het platform, dus je koopt of schakelt niets in om het te krijgen.

Application Gateway heeft Azure DDoS Network Protection nodig. Een applicatiegateway is een regionale bron met een openbaar IP-adres in je eigen virtuele netwerk. Azure's standaard infrastructuurbescherming beschermt het Azure-platform zelf, maar geeft je geen afgestemde, per resource mitigatie, telemetrie of aanvalrapportage voor dat IP. Om het publieke IP van de gateway te beschermen tegen L3/L4 volumetrische aanvallen, schakel Azure DDoS Network Protection in op het virtuele netwerk dat het bevat. Dit is een betaalde, los gekochte dienst.

Praktische gevolgen bij het kiezen of ontwerpen van een implementatie:

  • Als je achter Azure Front Door staat, budget dan voor L7-controles; de L3/L4 edge-bescherming is er al.
  • Als je Application Gateway gebruikt en DDoS Network Protection niet hebt ingeschakeld, kunnen je WAF-regels perfect worden afgestemd en toch worden omzeild door een volumetrische aanval op het publieke IP van de gateway. Schakel het in.
  • In beide gevallen hebben de publieke IP's die je ontbloot van oorsprong nog steeds Azure DDoS Network Protection nodig, plus lockdown zodat alleen de WAF-dienst ze kan bereiken. Een beschermde voorkant voor een onbeschermde, publiek toegankelijke oorsprong is niet beschermd.

Voor meer informatie, zie Azure DDoS Protection overzicht en Protect your application gateway with Azure DDoS Network Protection.

Geautomatiseerde bescherming met de HTTP DDoS-regelset (preview)

Statische controles zoals IP-filters, geofilters en vaste snelheidslimieten kunnen vaak niet gelijke tred houden met gedistribueerde botnets: de drempels zijn gok, ze staan altijd aan en je moet ze aanpassen naarmate het verkeer zich ontwikkelt. De HTTP DDoS-regelset is Azure WAF's eerste geautomatiseerde laag 7-beschermingsmodel dat leert, detecteert en verdedigt met minimale gebruikersconfiguratie. Het is beschikbaar in preview op zowel Azure Front Door Premium als Application Gateway WAF v2. Eenmaal toegewezen, baseline het continu het normale verkeer en, wanneer pieken een aanval aangeven, blokkeert het selectief aanvallende clients zonder noodafstemming.

Het ontwerp is op beide platforms hetzelfde op de punten die het meest tellen:

  • Twee drempels, samen geëvalueerd. De regelset leert zowel een globale drempel (per Front Door-profiel of per applicatiegateway) als individuele IP-gebaseerde drempels. IP-gebaseerde drempels worden pas gehandhaafd nadat de wereldwijde drempel is overschreden. Dit ontwerp voorkomt dat de regelsset werkt op pieken van een paar IP-adressen, tenzij ze daadwerkelijk het totale verkeer boven de norm drijven.
  • Scoped per bron. Drempels worden geleerd op het wereldwijde resourceniveau. Als je één WAF-beleid met de regelset toewijst aan meerdere Front Door-profielen of meerdere gateways, berekent de dienst drempels afzonderlijk voor elke gateway.
  • Gevoeligheid. Elke regel biedt drie gevoeligheidsniveaus. Hogere gevoeligheid zorgt voor een lagere drempel; Lagere gevoeligheid zorgt voor een hogere drempel. Medium is de standaard en aanbevolen instelling.
  • Beoordelingsvolgorde. De WAF evalueert eerst de HTTP DDoS-regelset, zelfs vóór de aangepaste regels. Een aangepaste regel met een Toelaat-actie omzeilt alle andere WAF-inspecties, maar omzeilt de HTTP DDoS-regelset niet.
  • Het omzeilen van de regelset voor vertrouwd verkeer. Een aangepaste regel met een Toelaat-actie helpt hier niet – het omzeilt alle andere regels, maar niet de HTTP DDoS-regels. Gebruik in plaats daarvan WAF-uitzonderingen , die je kunt scopen naar een specifieke regel, regelgroep of een hele beheerde regelset, inclusief de HTTP DDoS-regelset. Zie Vrijgesteld vertrouwd verkeer met uitzonderingen.
  • Vereist aanhoudend verkeer. De regelset kan pas handelen zodra het betrouwbare basislijnen leert. Als een bron tijdens de leerfase niet genoeg verkeer ontvangt, zal de regelset pas detecteren of beschermen als dat wel gebeurt. Zie de platformtabel voor de specifieke vereiste.

Platformverschillen

Characteristic Azure Front Door Premium Application Gateway WAF v2
Leerfase Baselines worden berekend over een rollend venster; De detectie begint binnen 24–36 uur voor profielen die minstens 50% van de afgelopen zeven dagen verkeer hebben ontvangen Baselines worden minimaal 24 uur geleerd; De regelset detecteert of blokkeert pas nadat de 24-uurs leerfase is afgerond
Onvoldoende verkeer Als een profiel minder dan 50% van de afgelopen zeven dagen verkeer heeft ontvangen, zal de regelset pas detecteren of blokkeren als er genoeg verkeer is voor betrouwbare baselines. Als de gateway tijdens de 24-uurs leerfase niet genoeg verkeer ontvangt om betrouwbare baselines op te zetten, zal de regelset aanvallen niet detecteren of blokkeren totdat dat wel gebeurt
Mitigation Aanstootgevende IP-adressen worden in een strafhok geplaatst en geblokkeerd gedurende de duur van de strafbank Aanstootgevende IP-adressen worden in een strafbank geplaatst en 15 minuten geblokkeerd
Regel-ID's 500100 (klantverzoekpercentage), 500110 (vermoedelijke bots) 500100 (klantverzoekpercentage), 500110 (vermoedelijke bots)
Aanvullende metrische gegevens Web Application Firewall HTTPDDoSRuleset is actief Strafboxgrootte, blokkades van strafboxen

Regels voor regelsets

De regelsset bevat momenteel twee regels. Elke regel onderhoudt zijn eigen verkeersbaselines en is configureerbaar met zijn eigen gevoeligheid en actie:

Regel Description
500100: Anomalie gedetecteerd bij een hoog aantal clientverzoeken Baselines al het verkeer op het Front Door-profiel of applicatiegateway waaraan het beleid is gekoppeld. Wanneer een client de geleerde drempel overschrijdt, wordt de geconfigureerde actie geactiveerd en wordt het betreffende IP-adres in de strafbox geplaatst.
500110: Vermoedelijke bots die hoge aanvragen sturen Handhaaft aparte, over het algemeen veel striktere basislijnen voor verkeer dat door Microsoft Threat Intelligence als bots wordt geclassificeerd. Bots die als hoog risico zijn geclassificeerd, worden onmiddellijk geblokkeerd zodra de wereldwijde drempel wordt overschreden.

Het strafvak

Beide platforms beperken via een strafbox. Wanneer het verkeer van een client de drempel voor een van de regels overschrijdt, wordt dat cliënt-IP-adres in de penaltybox geplaatst en door de WAF geblokkeerd voor de duur van de penaltybox, die 15 minuten is op Application Gateway. Wanneer de periode eindigt, krijgt het IP-adres weer toegang tenzij het de drempel opnieuw overschrijdt, waarna het terugstuurt naar de strafbox.

Dit ontwerp is belangrijk voor hoe je je telemetrie leest: alleen de initiële regelhit wordt geregistreerd. Extra geblokkeerde verzoeken terwijl het IP-adres al in de penaltybox staat, worden niet geregistreerd op Front Door, dus log-gebaseerde tellingen onderschatten het aantal geblokkeerde verzoeken. Op Application Gateway gebruik je de Penalty box blocks metric voor het werkelijke aantal blokken en de Penalty box grootte voor hoeveel IP-adressen momenteel worden bestraft.

Monitoring tijdens de preview

Wanneer een IP-adres een drempel overschrijdt, wordt een logboekvermelding geregistreerd met een Block-actie voor de HTTP DDoS-regelset en de WAF Managed Rule Match-metriek wordt gecreëerd.

  • Front Door: gebruik de Web Application Firewall Request count-metriek gefilterd op regelnaam om blokken te tellen, en de Web Application Firewall HTTPDDoSRuleset Is Active metric, die rapporteert 1 zodra het leren is voltooid en de regelset klaar is om te reageren op verkeer dat de geleerde drempels overschrijdt.
  • Application Gateway: elke volgende geblokkeerde aanvraag van een bestraft IP-adres verhoogt de Managed Rule Match-metriek, en de Penalty box-grootte en Penalty box blocks-metrics volgen de penaltybox direct.

Excempt trusted traffic met uitzonderingen

Health probes, synthetische monitoring, belastingtests, partnerintegraties en interne batchjobs genereren allemaal verkeer dat eruitziet als een overvloed, maar dat niet is. Historisch gezien is er geen manier om ze uit te sluiten van de DDoS-regelset, omdat een aangepaste Toelaat-regel de Default Rule Set, Core Rule Set en Bot Protection regelset omzeilt, maar bewust niet de HTTP DDoS-regelset omzeilt.

WAF-uitzonderingen dichten dat gat dicht. Een uitzondering omzeilt WAF-inspectie voor verzoeken die overeenkomen met specifieke attributen, beperkt tot één enkele regel, een regelgroep of een volledige beheerde regelset. Je kunt uitzonderingen toepassen op de HTTP DDoS-regelset, evenals op DRS, CRS en Bot Protection.

Uitzonderingen komen overeen op:

  • Remote IP-adres (Equals of IP Match), wat de gebruikelijke keuze is om bekende monitoring-, load-testing- of partnerbronbereiken uit te sluiten van de DDoS-regelset
  • aanvraag URI
  • Verzoek-headernaam en -waarde, gekoppeld aan Gelijk, Begint met, Eindigt met of Bevat

Richtlijnen voor het gebruik van uitzonderingen in de DDoS-regels:

  • Beperk het zo smal mogelijk. Geef de voorkeur aan een uitzondering per regel boven het uitsluiten van de hele regels. Een brede uitzondering geeft een aanvaller een gedocumenteerd pad om jouw geautomatiseerde mitigatie heen. Als een belastinggenerator alleen verlichting nodig heeft van regel 500100, sluit die dan niet ook uit van 500110.
  • Vrijgestelde bronnen, geen paden. Een IP-gebaseerde uitzondering voor een bekende test-kabel is begrensd. Een URI-gebaseerde uitzondering op een openbaar eindpunt is een open deur voor iedereen die het tegenkomt.
  • Bekijk ze op een schema. Uitzonderingen voor een eenmalige belastingtest kunnen een jaar later nog steeds van kracht zijn.
  • Let op de grenzen. Elk WAF-beleid ondersteunt tot 60 uitzonderingen, en elke Front Door ondersteunt er in totaal 60 over alle bijbehorende beleidsmaatregelen. Een enkele uitzondering kan tot 600 IP-adressen, 10 URI's of 10 requestheaders bevatten.
  • Uitzonderingen vereisen de next-generation WAF-engine en beheerde regelsetversie DRS 2.1 of later.

Gebruik het juiste hulpmiddel voor de taak: uitzonderingen slaan inspectie van één element van een verzoek (een ruiserige cookie of header) over terwijl de rest wordt geïnspecteerd; uitzonderingen slaan specifieke regels of regelsets voor matchverzoeken over; een aangepaste Toelaat-regel omzeilt alles behalve de HTTP DDoS-regelset.

Important

WAF-uitzonderingen en de HTTP DDoS-regelset zijn in preview op zowel Azure Front Door als Application Gateway WAF v2. Zie de aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews.

Daag uit voordat je blokkeert

Blokkeren is een bot instrument tijdens een L7-aanval: aanvalverkeer arriveert vaak vanaf IP-adressen en geografische gebieden die ook echte gebruikers dragen. Challenges stellen je in staat automatisering van mensen te scheiden zonder de nevenschade van een volledige blokkade, en ze zijn de grootste verandering in hoe Azure WAF L7-floods afhandelt ten opzichte van een block-only ratelimit-strategie.

  • JavaScript-uitdaging is een onzichtbare uitdaging die geen menselijke interactie vereist. Als de browser de uitdaging succesvol berekent, valideert WAF de client als niet-bot en blijft het de resterende regels evalueren; Verzoeken die mislukken worden geblokkeerd. Gebruik het als standaarduitdaging voor algemeen webverkeer. Verzoeken naar het challenge-eindpunt worden niet doorgestuurd naar je backend en tellen niet mee voor de rate limiting.
  • CAPTCHA is een interactieve uitdaging die gebruikersparticipatie vereist, het beste gereserveerd voor hoogwaardige processen zoals inloggen, aanmelden en afrekenen, waar geautomatiseerd misbruik duur is en een paar seconden gebruikerswrijving acceptabel is. De geldigheid van de challenge cookie is configureerbaar in beleidsinstellingen tussen 5 en 1.440 minuten, met een standaard van 30 minuten. CAPTCHA brengt extra gebruiksgebaseerde kosten met zich mee.

Plan rond de beperkingen van beide functies voordat je ze uitrolt:

  • AJAX- en API-aanroepen worden niet ondersteund. Zet uitdagingen niet voor API-routes. Gebruik daar in plaats daarvan rate limiting en match-regels.
  • Challenges zijn ontworpen voor HTML-bronnen, niet voor ingebedde afbeeldingen, CSS of JavaScript-bestanden.
  • Bij het eerste verzoek dat een uitdaging veroorzaakt, is de POST-body beperkt tot 64 KB op Azure Front Door en 128 KB op Application Gateway.
  • Geen van beide functies ondersteunt Internet Explorer; beide ondersteunen de huidige versies van Microsoft Edge, Chrome, Firefox en Safari.
  • JavaScript-uitdaging wordt opnieuw uitgegeven wanneer het IP-adres van een client verandert en voor cross-origin (CORS) verzoeken.
  • Op Application Gateway is JavaScript-uitdaging in preview en wordt het niet ondersteund voor custom rates limits. Application Gateway for Containers WAF ondersteunt het niet.

Snelheidsbeperking

Op zijn minst maak je een snelheidslimietregel die een hoog aantal verzoeken van elke enkele client blokkeert. Stel deze regel in als je laagste prioriteit (hoogste numerieke waarde) tarieflimietregel, zodat meer specifieke limiet- of matchregels eerst worden geëvalueerd.

Azure Front Door (een cloudgebaseerde dienst voor netwerkbeveiliging en contentlevering)

  • Er gelden snelheidslimieten per socket IP-adres, dat is het adres van de client die de TCP-verbinding met Azure Front Door opent en mogelijk een proxy is in plaats van de eindgebruiker.
  • Drempels worden geëvalueerd over een vast venster van één of vijf minuten. Zodra de drempel wordt overschreden, blokkeert Azure Front Door al het verkeer dat overeenkomt met de regel voor de rest van het venster. Gebruik het vijfminutenvenster voor HTTP-overstromingsmitigatie: een aanvaller die in de eerste minuut wordt geblokkeerd, blijft de resterende vier minuten geblokkeerd.
  • Grotere ramen met de laagst acceptabele drempel zijn de meest effectieve anti-DDoS-configuratie. Grotere vensters en hogere drempelwaarden zorgen ook dichter bij de geconfigureerde drempel. Bij zeer lage drempels (onder ongeveer 200 verzoeken per minuut) kunnen sommige verzoeken boven de drempel doorkomen, omdat verzoeken van één client op Front Door-servers terechtkomen waarvan de tellers nog niet zijn ververst.
  • Snelheidslimietregels ondersteunen alleen Log- en Block-acties ; Toestaan wordt niet ondersteund.
  • Pas een regel toe op al het verkeer door te matchen op een Host header met een lengte groter dan 0, omdat elk geldig verzoek aan Azure Front Door er een heeft.

Application Gateway WAF v2

  • Snelheidslimiet gebruikt een sliding window-algoritme . Al het overeenkomstige verkeer wordt verwijderd tijdens het eerste venster waarin de drempel wordt overschreden. Vanaf het tweede venster is verkeer tot aan de drempel toegestaan, wat een throttling-effect veroorzaakt in plaats van een volledige storing voor het matchen van klanten.

  • Regels vereisen een GroupByUserSession, die bepaalt hoe verzoeken worden geteld. Met deze functie kun je de snelheid beperken door iets anders dan het client-IP:

    GroupByVariable Gebruik deze wanneer
    ClientAddr (standaard) Normaal geval met onafhankelijke tellers per bron-IP
    ClientAddrXFFHeader Je gateway zit achter een CDN of proxy en het echte client-IP staat in X-Forwarded-For
    GeoLocation Je wilt het verkeer per land/regio beperken tijdens een geografisch geconcentreerde overstroming
    GeoLocationXFFHeader Hetzelfde als hierboven, met het IP-adres in X-Forwarded-For
    None Een enkele gedeelde teller voor een nauw overeenkomend patroon, zoals een inlogpagina of een lijst van verdachte gebruikersagenten

  • Snelheidslimietregels vereisen de nieuwste WAF-engine (selecteer CRS 3.2 of hoger voor de standaardregelset) en worden niet ondersteund in air-gapped clouds.

  • Application Gateway telt onafhankelijk drempels voor elk eindpunt waaraan het beleid is gekoppeld. Een enkel beleid met vijf luisteraars handhaaft vijf sets tellers.

  • Drempels worden niet exact gehandhaafd, dus gebruik geen snelheidsbeperking voor fijnmazige verkeersregeling. Gebruik het om afwijkende tarieven te beperken en beschikbaarheid te behouden. Wees bijzonder voorzichtig met breed-matching regels die gebruikmaken GeoLocation van of None; een slecht gekozen drempel kan leiden tot frequente korte storingen voor legitiem verkeer.

Stel geografie-bewuste drempels in

Een enkele wereldwijde drempel moet ruim genoeg zijn voor je drukste land, waardoor het overal elders veel te royaal is. De meeste applicaties hebben in vredestijd een sterk scheef geografisch profiel – een handvol landen of regio's produceert bijna al het legitieme verkeer, de rest levert een druppel. Aanvalsverkeer respecteert die distributie zelden. Dimensioneringsdrempels per geografie veranderen die asymmetrie in zowel een detectiesignaal als een mitigatiecontrole.

Begin met het meten van je vredestijdverdeling over minstens een hele week, zodat de effecten van doordeweekse, weekend- en tijdzone-effecten worden weergegeven:

  • Op Azure Front Door, splits de Request Count metric met de ClientCountry-dimensie.

  • In Log Analytics leidt u het land af van het client IP-adres in het toegangslogboek:

    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

Groepeer vervolgens de resultaten in tiers en stel een drempel in voor elk:

Laag Vredestijdaandeel Aanbevolen behandeling
Primaire markten De landen produceren het grootste deel van je verkeer Ruime drempel per klant, gestort vanuit de eigen p99 van dat land zodat echte gebruikers nooit worden beïnvloed
Secundaire markten Betekenisvol maar bescheiden verkeer Strakkere drempel per klant, gecreëerd vanuit de p99 van dat land in plaats van de wereldwijde
Lange staartgeografieën Een druppel legitiem verkeer Agressieve drempel, of een uitdagingsactie in plaats van een blok
Geografieën die je niet bedient Effectief nul Blokkeer het helemaal, of stuur het door naar een statische pagina

Hoe je de lagen implementeert hangt af van het platform:

  • Application Gateway WAF v2 - gebruik GroupByVariable: GeoLocation (of GeoLocationXFFHeader achter een CDN of proxy) zodat al het verkeer van één geografie een teller deelt, en maak per laag één snelheidslimietregel met een eigen drempel. Omdat een inbreuk tegen elke client in dat gebied werkt, moet je deze drempels conservatief dimensioneren en eerst in Log-actie valideren: een verkeerd geconfigureerde breed-matching geo-regel kan frequente korte storingen veroorzaken voor legitiem verkeer.
  • Azure Front Door - tellers zijn per socket IP-adres, dus bouw de tiers met geo-match voorwaarden: één tarieflimietregel per tier, gematcht in de relevante landen, elk met zijn eigen drempel. Elke klant in een long-tail regio krijgt dan een veel lager plafond dan klanten in je primaire markten, zonder dat het gedrag van de ene klant de andere beïnvloedt.

Enkele praktijken die dit houdbaar houden:

  • Orden de regels van meest specifiek naar minst: primaire marktregels met hogere prioriteit (lagere numerieke waarde), dan secundair, dan longtail, met de globale catch-all als je laagste prioriteitslimietregel.
  • Geef de voorkeur aan een uitdagingsactie boven een blok voor long-tail geografieën. Verkeer uit een land met weinig legitiem volume is in totaal verdacht, maar bevat nog steeds echte gebruikers - reizigers, VPN-gebruikers en externe medewerkers.
  • Meet opnieuw na marketinglanceringen, regionale uitbreidingen en grote productevenementen. Een geografiebewuste configuratie is slechts zo goed als de basislijn waarop hij is gedimensioneerd.
  • Let op het omgekeerde signaal tijdens een incident: een land dat normaal gesproken 1% verkeer levert en plotseling 40% bijdraagt, is een van de snelste manieren om te bevestigen dat je een aanval ziet in plaats van organische groei.

Kies een drempel uit je eigen verkeer

Gebruik de volgende Log Analytics-query om de catch-all-regel te vergroten. Voor Application Gateway vervang FrontdoorAccessLog door ApplicationGatewayAccessLog.

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

Om de eerder beschreven drempels per geografie te bepalen, voeg je het land toe aan dezelfde zoekopdracht:

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

Stel de drempel boven het 99e percentiel van vredestijdverkeer in, niet op het maximum. Het maximum is meestal een crawler of een verkeerd geconfigureerde client, en het aanpassen daarvan maakt de regel te royaal om te helpen tijdens een aanval.

Aangepaste regels voor gerichte mitigatie

Maak aangepaste WAF-regels om HTTP- en HTTPS-aanvallen met identificeerbare signaturen te blokkeren of te beperken, zoals een specifieke user agent, header, cookie, querystringpatroon, URI of een combinatie daarvan. Naast stringmatching kunnen Azure Front Door WAF custom regels matchen op:

  • Geolocatie: Blokkeer verkeer van buiten je serviceregio, of leid het om naar een statische pagina.
  • Client IP-adres (CIDR) en IP-beperkingen geven adressen en bereiken die je als kwaadaardig hebt geïdentificeerd.
  • AS-nummer (ASN): Beperk overstromingen afkomstig van een hostingprovider of transitnetwerk waar je legitieme gebruikers niet vandaan komen, zonder IP-bereiken op te sommen.
  • Client vingerafdruk (JA4): Match op de JA4-vingerafdruk, een hash afgeleid van de TLS-handshake en HTTP-kenmerken van de client. Omdat aanvalstools en botnetclients een consistente vingerafdruk produceren ongeacht het IP-adres waar ze vanaf verzenden, is JA4 een van de meest duurzame handtekeningen die beschikbaar zijn tijdens een gedistribueerde aanval: het roteren door duizenden bron-IP-adressen verandert de vingerafdruk niet, en blokkeren of snelheidslimieten ervan schakelt het hele botnet uit met één regel. Controleer de vingerafdruk met je vredestijdlogboeken voordat je deze aanvraagt. Populaire browsers en gangbare SDK's delen vingerafdrukken tussen enorme aantallen legitieme gebruikers, dus een niet-gevalideerd JA4-blok kan extreem breed zijn. Zet eerst in de Log-actie , bevestig dat de vingerafdruk alleen verschijnt in aanvalsverkeer, en schakel dan over naar Blokkeren of een snelheidslimietregel.
  • Combineer JA4 met andere aandoeningen voor chirurgische mitigatie tijdens een incident. Bijvoorbeeld, een rate-limit in plaats van een specifieke JA4-vingerafdruk en een ASN te blokkeren waarvan je gebruikers niet kunt bedienen, of een JA4-vingerafdruk en een verzoek-URI.
  • Servicetag- en groottebeperkingen op verzoekcomponenten.

Twee praktijken die tijdens een incident van belang zijn:

  • Maak Allow match-regels aan voor bekend legitiem verkeer om vals-positieven te verminderen, en geef ze een hogere prioriteit (lagere numerieke waarde) dan je block- en rate limit-regels. Onthoud dat een Toelaat-regel andere WAF-inspecties omzeilt, maar niet de HTTP DDoS-regelset.
  • Regelevaluatie stopt bij elke actie behalve Log, en prioriteitsnummers moeten uniek zijn. Reserveer een blok met nummers met lage prioriteit voor noodregels zodat je er een kunt invoegen tijdens een aanval zonder te hernummeren.

Beheerde regels zijn niet gericht op DDoS-verdediging, maar beschermen tegen andere veelvoorkomende aanvallen en zouden ingeschakeld moeten blijven. Zie Managed rules (Azure Front Door) of Managed rules (Application Gateway).

Bescherm de oorsprong

  • Sluit de toegang tot publieke IP's op de oorsprong af en beperk inkomend verkeer zodat alleen Azure Front Door of Application Gateway er bij kan komen. Volg de richtlijnen voor het beveiligen van verkeer naar Azure Front Door Origins.
  • Zorg ervoor dat er geen openbaar blootgestelde IP-adressen zijn in het virtuele netwerk van de Application Gateway.
  • Schakel caching in op Azure Front Door in. Gecachte antwoorden absorberen het piekvolume aan de rand en verminderen de verzoeksnelheid die je oorsprong bereikt, wat vaak het verschil is tussen verslechterde prestaties en een storing.
  • Schaal oorsprong met headroom. Geautomatiseerde en handmatige mitigaties kosten tijd om te realiseren; Reserve capaciteit vult dat gap.

Reageer op een actieve aanval

  1. Bevestig dat het een aanval is, geen organische groei. Controleer de WAF- en toegangslogboeken op een plotselinge verandering in aanvraagsnelheid, het aantal cliënt-IP's, geografische mix, user agent-distributie en gevraagde URI's.
  2. Controleer wat al mitigeerend is. Bevestig dat de HTTP DDoS-regelset actief is en bekijk de blokken op regelnaam. Controleer op Application Gateway ook de Penalty box grootte en Penalty box blokken metrics, aangezien alleen het eerste blok per IP-adres in de logs verschijnt. Bekijk wedstrijden met de limietlimietregels.
  3. Vergelijk de geografische mix met je basislijn. Een land dat normaal gesproken een klein aandeel van het verkeer inlevert en plotseling domineert is een snel, hoogvertrouwend aanvalssignaal. Het vertelt je ook welke grensregels je eerst moet aanscherpen.
  4. Verhoog de gevoeligheid voordat je nieuwe regels schrijft. Het verhogen van de gevoeligheid van HTTP DDoS-regelsets of het verlagen van een bestaande snelheidslimietdrempel is sneller en veiliger dan het opstellen van een nieuwe regel onder druk.
  5. Daag uit in plaats van te blokkeren waar het verkeer gemengd is. Pas JavaScript-uitdaging toe op getroffen HTML-routes, en CAPTCHA op gevoelige flows.
  6. Schrijf pas een gerichte regel als je een duurzame handtekening hebt geïdentificeerd: ASN, klantvingerafdruk, headercombinatie, geografie of URI-patroon. Zet het eerst in in de Log-actie als het patroon ook overeenkomt met echte gebruikers.
  7. Houd de origin beschermd tijdens het afstellen: controleer of caching aan staat, bevestig de origin lockdown en schaal uit.
  8. Na het incident baseline je limietlimieten opnieuw aan de hand van de nieuwe verkeersgegevens en houd de noodregels die correct bleken in Log-modus als je niet wilt dat ze continu worden gehandhaafd.

Analyseer WAF- en toegangslogboeken

Monitor het verkeer met behulp van Azure WAF-logs op anomalieën en gebruik deze om verdachte IP-adressen te identificeren die ongewoon veel verzoeken, ongebruikelijke user agent-strings of anomalistische querystringpatronen sturen.

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Azure Application Gateway

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Top talkers en top user agents over het aanvalvenster (Azure Front Door getoond; vervang ApplicationGatewayAccessLog 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

Voor meer informatie, zie Azure WAF met Azure Front Door en Azure WAF met Azure Application Gateway.

Verwante onderwerpen

  • Last updated on