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 openbare IP-adressen van Application Gateway en openbare IP-adressen van origins
Geautomatiseerde L7-mitigatie Leert uw normale verkeerspatroon en beperkt storende clients tijdens een piek, zonder noodaanpassingen HTTP DDoS-regelset (preview) op Azure Front Door Premium en 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 Aangepaste regels voor snelheidsbeperking op Front Door en Application Gateway
Aangepaste gerichte regels Blokkeert een bekende aanvalsignatuur tijdens een incident Match aangepaste regels (geo, IP, ASN, client fingerprint, header, URI)
Oorsprongsbescherming Voorkomt dat aanvalsverkeer je compute-omgeving überhaupt bereikt Caching, oorsprongsbeveiliging, automatisch schalen

Controlelijst voor basisconfiguratie

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 stem het beleid eerst af op productieverkeer om valse positieven te verminderen, en schakel 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, zodat plotseling piekverkeer wordt opgevangen via edge-locaties in plaats van door je bronserver.
  8. Dek je L3/L4-blootstelling af, die per platform verschilt. Zie Platform DDoS-bescherming verschilt per platform. Scherm je bron af zodat deze alleen verkeer accepteert van Azure Front Door of Application Gateway.
  9. Schakel diagnostische logboekregistratie in in Log Analytics en stel de query's op in WAF- en toegangslogboeken analyserenvóó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 zit, houd dan rekening met budget voor L7-controles; de L3/L4-randbeveiliging 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 openbare IP-adressen van de origin die je blootstelt nog steeds Azure DDoS Network Protection nodig en moeten ze zodanig worden afgeschermd dat alleen de WAF-service deze kan bereiken. Een beschermd front-end vóór een onbeschermde, openbaar bereikbare bronserver is niet beschermd.

Raadpleeg voor meer informatie Overzicht van Azure DDoS Protection en Uw application gateway beveiligen met 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. Zodra het is toegewezen, stelt het continu een basislijn vast voor normaal verkeer en, wanneer pieken op een aanval duiden, blokkeert het selectief problematische clients zonder dat noodaanpassingen nodig zijn.

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.
  • Van toepassing per resource. Drempels worden aangeleerd op het niveau van de globale resource. 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 Vertrouwd verkeer uitsluiten 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 Overtredende IP-adressen worden in een strafvak geplaatst en gedurende 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 Stelt een basislijn op voor al het verkeer op het Front Door-profiel of de toepassingsgateway 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 termijn eindigt, krijgt het IP-adres opnieuw toegang, tenzij het de drempel opnieuw overschrijdt, waardoor het weer in het strafvak terechtkomt.

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.

Bewaking tijdens de voorbeeldweergave

Wanneer een IP-adres een drempel overschrijdt, wordt een logvermelding vastgelegd met de actie Block voor de HTTP DDoS-regelset en wordt de WAF-Managed Rule Match-metriek verhoogd.

  • 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: elk volgend geblokkeerd verzoek van een IP-adres waarvoor een sanctie geldt, verhoogt de metriek Managed Rule Match, en de metriek Grootte van het sanctievak en Sanctievakblokkeringen houden het sanctievak rechtstreeks bij.

Stel vertrouwd verkeer vrij via uitzonderingen

Health probes, synthetische monitoring, belastingstests, partnerintegraties en interne batchjobs genereren allemaal verkeer dat op een stortvloed lijkt, terwijl dat niet zo 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 belastingsgenerator alleen vrijstelling van regel 500100 nodig heeft, geef deze dan niet ook vrijstelling van regel 500110.
  • Vrijgestelde bronnen, geen paden. Een IP-gebaseerde uitzondering voor een bekend testharnas is afgebakend. Een URI-gebaseerde uitzondering op een openbaar eindpunt is een open deur voor iedereen die het tegenkomt.
  • Bekijk ze volgens een schema. Uitzonderingen die zijn toegevoegd voor een eenmalige loadtest, kunnen een jaar later nog steeds bestaan.
  • Houd rekening met de beperkingen. 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 aanvraagheaders bevatten.
  • Uitzonderingen vereisen de WAF-engine van de volgende generatie en versie DRS 2.1 of hoger van de beheerde regelset.

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 grof middel bij een L7-aanval: aanvalsverkeer komt vaak van IP-adressen en regio’s waar zich ook echte gebruikers bevinden. 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.
  • De JavaScript-uitdaging wordt opnieuw opgelegd wanneer het IP-adres van een client verandert en voor cross-originverzoeken (CORS).
  • In Application Gateway is de JavaScript-challenge beschikbaar als preview en wordt deze niet ondersteund voor aangepaste regels voor snelheidslimieten. 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 er ook voor dat deze dichter bij de geconfigureerde drempel blijven. 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.
  • Regels voor snelheidsbeperking ondersteunen alleen de acties Log en Block; Allow wordt niet ondersteund.
  • Pas een regel toe op al het verkeer door te zoeken naar een Host-header met een lengte van meer dan 0, omdat elk geldig verzoek naar Azure Front Door zo'n header bevat.

Application Gateway WAF v2

  • Snelheidslimiet gebruikt een sliding window-algoritme . Al het overeenkomende verkeer wordt geblokkeerd in het eerste tijdvenster waarin de drempelwaarde wordt overschreden. Vanaf het tweede tijdsvenster is verkeer tot de drempel toegestaan, wat voor overeenkomende clients een beperkend effect veroorzaakt in plaats van volledige uitval.

  • Voor regels is een GroupByUserSession vereist, waarmee wordt bepaald 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

  • Regels voor snelheidsbeperking vereisen de meest recente WAF-engine (selecteer CRS 3.2 of later voor de standaardregelset) en worden niet ondersteund in geïsoleerde 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 regels met brede overeenkomst die gebruikmaken van GeoLocation of None; een slecht gekozen drempel kan leiden tot frequente korte onderbrekingen van 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 scheefgetrokken geografisch profiel – een handvol landen of regio's genereert bijna al het legitieme verkeer, en de rest slechts mondjesmaat. 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 metriek Aantal aanvragen op basis van de dimensie ClientCountry.

  • 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, afgestemd op de eigen p99-waarde van dat land zodat echte gebruikers er nooit hinder van ondervinden
Secundaire markten Betekenisvol maar bescheiden verkeer Strengere drempel per klant, gebaseerd op de p99-waarde van dat land in plaats van op de wereldwijde p99-waarde
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 - de telling gebeurt per socket-IP-adres, dus bouw de niveaus in plaats daarvan op met geo-matchvoorwaarden: één rate-limitingregel per niveau, afgestemd op de relevante landen, elk niveau met een 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.
  • Gebruik bij voorkeur een challenge in plaats van een blokkering voor regio’s in de long tail. 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 maar zo goed als de uitgangssituatie waarvan de dimensionering is afgeleid.
  • 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 op basis van 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. De maximale waarde is meestal afkomstig van een crawler of een onjuist geconfigureerde client, en de regel daarop afstemmen maakt die te ruim om tijdens een aanval te helpen.

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 tekenreeksvergelijking kunnen aangepaste regels van Azure Front Door WAF ook overeenkomen met:

  • Geolocatie: Blokkeer verkeer van buiten je serviceregio, of leid het om naar een statische pagina.
  • Client-IP-adreslijsten (CIDR) en IP-beperkingslijsten voor adressen en adresbereiken die je als kwaadwillig 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.
  • Clientvingerafdruk (JA4): Overeenkomst op basis van de JA4-vingerafdruk, een hash die is 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 aan de hand van je logboeken uit vredestijd voordat je op basis daarvan handhaaft. Populaire browsers en gangbare SDK's delen vingerafdrukken tussen enorme aantallen legitieme gebruikers, dus een niet-gevalideerd JA4-blok kan extreem breed zijn. Zet dit eerst in de actie Log, bevestig dat de vingerafdruk alleen voorkomt in aanvalsverkeer en schakel daarna over naar Blokkeren of een regel voor snelheidsbeperking.
  • Combineer JA4 met andere aandoeningen voor chirurgische mitigatie tijdens een incident. Bijvoorbeeld: beperk liever het aantal aanvragen voor een specifieke JA4-vingerafdruk en een ASN van waaruit je geen gebruikers bedient, in plaats van die te blokkeren, of voor een JA4-vingerafdruk en een aanvraag-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 Beheerde regels (Azure Front Door) of Beheerde regels (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 voor Azure Front Door. Gecachete responses vangen piekbelasting op aan de edge en verminderen de verzoekfrequentie die je origin-server bereikt, wat vaak het verschil maakt tussen verminderde prestaties en uitval.
  • Schaal oorsprongen op met extra capaciteit. Geautomatiseerde en handmatige tegenmaatregelen hebben tijd nodig om effect te hebben; reservecapaciteit overbrugt die periode.

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 in Application Gateway ook de metrische waarden Penalty box size en Penalty box blocks, aangezien alleen de eerste blokkering per IP-adres in de logboeken wordt weergegeven. Bekijk wedstrijden met de limietlimietregels.
  3. Vergelijk de geografische mix met je basislijn. Een land dat normaal gesproken slechts een klein aandeel van het verkeer voor zijn rekening neemt, maar dit plotseling domineert, is een snelle en zeer betrouwbare aanwijzing voor een aanval. Het vertelt je ook welk niveau van de rate-limitregels je als eerste 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. Controleer in plaats van te blokkeren waar sprake is van gemengd verkeer. 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 bronserver beveiligd terwijl je optimaliseert: controleer of caching is ingeschakeld, bevestig de toegangsbeperking van de bronserver en schaal op.
  8. Breng na het incident je rate limit-drempelwaarden opnieuw in lijn met de nieuwe verkeersgegevens en behoud de noodregels die in de Log-modus nauwkeurig bleken, als je niet wilt dat ze continu worden afgedwongen.

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"

Belangrijkste bronnen en belangrijkste user-agents tijdens het aanvalsvenster (Azure Front Door weergegeven; vervang Application Gateway door ApplicationGatewayAccessLog):

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

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

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

Verwante onderwerpen

  • Last updated on