Applicazione (livello 7) Protezione DDoS

Vale a: ✔️ Application Gateway V2 ✔️ Front Door Premium

Web application firewall di Azure (WAF) include diversi meccanismi di difesa che aiutano a prevenire attacchi DDoS (distributed denial of service). Gli attacchi DDoS possono colpire sia il livello di rete (L3/L4) che il livello applicazione (L7). Azure DDoS Protection protegge dagli attacchi volumetrici di grandi dimensioni a livello di rete. Azure WAF, che opera al livello 7, protegge le applicazioni Web dagli attacchi DDoS L7, ad esempio inondazioni HTTP. Insieme, queste difese impediscono agli attaccanti di raggiungere la tua applicazione e di influenzarne la disponibilità e le prestazioni.

Gli attacchi a livello applicativo sono economici da lanciare e difficili da distinguere dal traffico legittimo: ogni richiesta appare valida da sola, e solo il tasso aggregato, la distribuzione e la composizione dei client rivelano l'attacco. La difesa efficace di livello 7 quindi si basa meno su un singolo controllo e più su una configurazione stratificata già in atto prima dell'inizio dell'attacco.

Scegli i tuoi livelli di difesa

Usa il seguente modello quando pianifichi la protezione DDoS L7. Ogni livello cattura traffico che quello sopra no.

Lista di controllo della configurazione di base

Completa questi passaggi prima di essere attaccato. Adattali per adattarli ai requisiti della tua domanda.

1. Distribuisci Azure WAF con Frontdoor di Azure Premium o Application Gateway WAF v2 per proteggerti dagli attacchi al livello applicativo L7.
2. Passa la politica WAF in modalità prevenzione. Una policy in modalità rilevamento registra solo il traffico e non blocca. Verifica e regola prima la politica contro il traffico di produzione per ridurre i falsi positivi, poi attiva la prevenzione.
3. Assegna il regolamento HTTP DDoS (disponibile sia su Frontdoor di Azure Premium che su Application Gateway WAF v2) così la mitigazione automatica è imparare la tua base di traffico prima che tu ne abbia bisogno.
4. Abilita il sistema di regole gestito dal Bot Manager per identificare e agire contro i bot noti.
5. Configurare almeno una regola generale del limite di velocità (vedi Limitazione del tasso).
6. Aumenta il numero di istanze di origine in modo che ci sia abbastanza capacità disponibile e imposta Application Gateway per scalare automaticamente senza imporre un basso numero massimo di istanza.
7. Abilita la cache su Frontdoor di Azure così il traffico di picco improvviso viene assorbito al bordo invece che all'origine.
8. Copri la tua esposizione L3/L4, che varia a seconda della piattaforma. Vedi la protezione DDoS della piattaforma varia da piattaforma a piattaforma. Blocca il tuo origin in modo che accetti traffico solo da Frontdoor di Azure o Application Gateway.
9. Attiva la registrazione diagnostica su Log Analytics e compila le query in Analizza WAF e accedi ai logprima di un incidente.

La protezione DDoS della piattaforma varia da piattaforma a piattaforma

Le difese L7 contano solo se gli indirizzi IP pubblici sottostanti sopravvivono a un attacco volumetrico e le due piattaforme WAF di Azure non partono dallo stesso punto.

Frontdoor di Azure ha di default la protezione DDoS della piattaforma. Frontdoor di Azure è un servizio edge distribuito globalmente, e il suo edge è protetto dalla protezione DDoS dell'infrastruttura di Azure senza costi aggiuntivi e senza configurazione. Il traffico termina al bordo della Porta Frontale invece che a un indirizzo IP che possiedi, quindi non c'è un tuo IP pubblico da colpire da un attaccante a L3/L4. Questa protezione è intrinseca alla piattaforma, quindi non acquisti né abiliti nulla per ottenerla.

Application Gateway necessita della protezione di rete DDoS di Azure. Un gateway applicativo è una risorsa regionale con un indirizzo IP pubblico nella propria rete virtuale. La protezione predefinita a livello di infrastruttura di Azure protegge la piattaforma Azure stessa, ma non fornisce mitigazione ottimizzata per risorsa, telemetria o report di attacco per quell'IP. Per proteggere l'IP pubblico del gateway dagli attacchi volumetrici L3/L4, abilita Azure DDoS Network Protection sulla rete virtuale che lo contiene. Si tratta di un servizio a pagamento, acquistato separatamente.

Conseguenze pratiche quando si sceglie o si progetta una distribuzione:

• Se sei dietro Frontdoor di Azure, budget per i controlli L7; la protezione dei bordi L3/L4 è già lì.
• Se stai usando Application Gateway e non hai attivato la protezione di rete DDoS, le tue regole WAF possono essere perfettamente regolate e comunque bypassate da un attacco volumetrico all'IP pubblico del gateway. Abilitalo.
• In entrambi i casi, gli IP pubblici di origine che esposti richiedono comunque la protezione di rete DDoS di Azure, oltre al lockdown in modo che solo il servizio WAF possa raggiungerli. Un front-end protetto davanti a un'origine non protetta e accessibile al pubblico non è protetto.

Per maggiori informazioni, consulta la panoramica di Azure DDoS Protection e Proteggi il tuo gateway applicativo con Azure DDoS Network Protection.

Protezione automatica con il regolamento HTTP DDoS (anteprima)

Controlli statici come filtri IP, geo-filtri e limiti di velocità fissi spesso non riescono a tenere il passo con le botnet distribuite: le soglie sono supposizioni, sono sempre attive e devi ri-metterle a sintonia man mano che i modelli di traffico si evolvono. Il regolamento HTTP DDoS è il primo modello automatizzato di protezione di livello 7 di Azure WAF che apprende, rileva e difende con una configurazione minima per l'utente. È disponibile in anteprima sia su Frontdoor di Azure Premium che su Application Gateway WAF v2. Una volta assegnato, traccia continuamente il traffico normale e, quando i picchi indicano un attacco, blocca selettivamente i client offensivi senza bisogno di una sintonia d'emergenza.

Il design è lo stesso su entrambe le piattaforme negli aspetti che contano di più:

• Due soglie, valutate insieme. Il regolamento apprende sia una soglia globale (per ogni profilo Front Door o per gateway applicativo) sia singole soglie basate su IP. Le soglie basate su IP vengono applicate solo dopo che la soglia globale è stata superata. Questo design impedisce al regolamento di agire su picchi provenienti da pochi indirizzi IP, a meno che non spingano effettivamente il traffico totale oltre la norma.
• Definito per risorsa. Le soglie si apprendono a livello globale di risorse. Se assegni una policy WAF con il set di regole a più profili Front Door o più gateway, il servizio calcola separatamente le soglie per ciascuno.
• Sensibilità. Ogni regola offre tre livelli di sensibilità. Una sensibilità più alta applica una soglia più bassa; una sensibilità più bassa applica una soglia più alta. La modalità media è l'impostazione predefinita e consigliata.
• Ordine di valutazione. Il WAF valuta prima il set di regole HTTP DDoS, anche prima delle regole personalizzate. Una regola personalizzata con un'azione Allow bypassa tutte le altre ispezioni WAF, ma non bypassa il regolamento HTTP DDoS.
• Bypassare le regole per il traffico affidabile. Una regola personalizzata con un'azione Allow non aiuta qui: bypassa tutti gli altri regole ma non quello HTTP DDoS. Usa invece eccezioni WAF , che puoi scalare a una regola specifica, a un gruppo di regole o a un intero set di regole gestito, incluso il regolamento HTTP DDoS. Vedi Esente traffico affidabile con eccezioni.
• Richiede traffico costante. Il regolamento può agire solo una volta che apprende basi affidabili. Se una risorsa non riceve abbastanza traffico durante la fase di apprendimento, il regolamento non rileverà né proteggerà finché non lo riceve. Consulta la tabella della piattaforma per il requisito specifico.

Differenze tra le piattaforme

Regole del set

Il regolamento attualmente contiene due regole. Ogni regola mantiene le proprie linee di riferimento del traffico ed è configurabile con la propria sensibilità e azione:

Casella di penalità

Entrambe le piattaforme mitigano tramite una casella di penalità. Quando il traffico da un client supera la soglia di una delle regole del regolamento, quell'indirizzo IP del client viene inserito nella casella di penalità e bloccato dal WAF per la durata della casella di penalità, che è di 15 minuti su Application Gateway. Quando il periodo termina, l'indirizzo IP riacquista l'accesso a meno che non superi nuovamente la soglia, il che lo restituisce alla penalità.

Questo design conta per come leggi la tua telemetria: viene registrato solo il colpo iniziale della regola. Le richieste bloccate aggiuntive mentre l'indirizzo IP è già nella penalità non vengono registrate su Front Door, quindi i conteggi basati su log sottostimano il numero di richieste bloccate. Su Application Gateway, usa la metrica dei blocchi della scatola di penalità per il conteggio reale dei blocchi e la dimensione della casella di penalità per quanti indirizzi IP sono attualmente penalizzati.

Monitoraggio durante l'anteprima

Quando un indirizzo IP supera una soglia, viene registrato un registro con un'azione Block per il regolamento HTTP DDoS e gli incrementi della metrica WAF Managed Rule Match .

• Front Door: usa la metrica di conteggio Web application firewall Request filtrata per nome di regola per contare i blocchi, e la metrica Web application firewall HTTPDDoSRuleset Is Active, che riporta 1 una volta completato l'apprendimento e il regolamento è pronto ad agire sul traffico che supera le soglie apprese.
• Application Gateway: ogni successiva richiesta bloccata da un indirizzo IP penalizzato incrementa la metrica Managed Rule Match, e le metriche Dimensione della casella di penalità e dei blocchi della casella di penalità tracciano direttamente la casella di penalità.

Esentare il traffico affidabile con eccezioni

I sonde di salute, il monitoraggio sintetico, i test di carico, le integrazioni con partner e i lavori batch interni generano tutti traffico che sembra un'inondazione ma non lo è. Storicamente, non c'è modo di esentarli dal regolamento DDoS, perché una regola Allow personalizzata bypassa il set di regole Default, il Core Rule Set e il Bot Protection ma deliberatamente non bypassa il regolamento HTTP DDoS.

Le eccezioni WAF colmano questo divario. Un'eccezione bypassa l'ispezione WAF per richieste che corrispondono a attributi specifici, con ambito di applicazione a una singola regola, un gruppo di regole o un intero set di regole gestite. Puoi applicare eccezioni al regolamento HTTP DDoS così come a DRS, CRS e Bot Protection.

Le eccezioni corrispondono su:

• Indirizzo IP remoto (Equals o IP Match), che è la scelta usuale per esentare intervalli di monitoraggio noti, test di carico o sorgente partner dal regolamento DDoS
• URI della richiesta
• Richiedi nome e valore dell'intestazione abbinati a Uguali, Inizia con, Finisce con o Contiene

Guida per l'uso delle eccezioni con il regolamento DDoS:

• Rientra nel modo più ristretto possibile. Preferisci un'eccezione per ogni regola piuttosto che esentare l'intero regolamento di regole. Un'eccezione ampia offre all'attaccante un percorso documentato attorno alla tua mitigazione automatica. Se un generatore di carico ha bisogno solo di essere sollevato dalla regola 500100, non esentarlo anche dalla 500110.
• Fonti esente, non percorsi. Un'eccezione basata su IP per un harness di test noto è limitata. Un'eccezione basata su URI su un endpoint pubblico è una porta aperta per chiunque la trovi.
• Rivedili secondo un programma. Le eccezioni aggiunte per un test di carico una tantum potrebbero essere ancora in vigore un anno dopo.
• Attento ai limiti. Ogni policy WAF supporta fino a 60 eccezioni, e ogni Front Door ne supporta 60 in totale su tutte le politiche associate. Una singola eccezione può contenere fino a 600 indirizzi IP, 10 URI o 10 intestazioni di richiesta.
• Le eccezioni richiedono il motore WAF di nuova generazione e il sistema di regole gestito DRS 2.1 o successiva.

Usa lo strumento giusto per il lavoro: le esclusioni saltano l'ispezione di un elemento di una richiesta (un cookie rumoroso o un header) pur esaminando il resto; le eccezioni saltano regole o set di regole specifiche per richieste corrispondenti; una regola personalizzata di Allow bypassa tutto tranne il regolamento HTTP DDoS.

Sfida prima di bloccare

Il blocco è uno strumento contundente durante un attacco L7: il traffico di attacco arriva frequentemente da indirizzi IP e geografie che trasportano anche utenti reali. Le sfide permettono di separare l'automazione dagli umani senza il danno collaterale di un blocco totale, e rappresentano il cambiamento più grande nel modo in cui Azure WAF gestisce gli flood L7 rispetto a una strategia di limite di velocità basata solo su blocchi.

• La sfida JavaScript è una sfida invisibile che non richiede interazione umana. Se il browser calcola con successo la sfida, WAF valida il client come nonbot e continua a valutare le regole rimanenti; Le richieste che falliscono vengono bloccate. Usalo come sfida predefinita per il traffico web generale. Le richieste all'endpoint challenge non vengono inoltrate al tuo backend e non contano per il limite di velocità.
• CAPTCHA è una sfida interattiva che richiede la partecipazione degli utenti, meglio riservata per flussi di alto valore come l'accesso, l'iscrizione e il checkout, dove l'abuso automatico è costoso e pochi secondi di attrito per l'utente sono accettabili. La validità del cookie di contestazione è configurabile nelle impostazioni della policy tra 5 e 1.440 minuti, con un valore predefinito di 30 minuti. Il CAPTCHA comporta costi aggiuntivi basati sull'uso.

Pianifica in base alle limitazioni di entrambe le funzionalità prima di implementarle:

• Le chiamate AJAX e API non sono supportate. Non mettere sfide davanti alle rotte API. Usa invece le regole di limite di velocità e di match.
• Le sfide sono progettate per le risorse HTML, non per immagini incorporate, CSS o file JavaScript.
• Alla prima richiesta che attiva una contestazione, il corpo POST è limitato a 64 KB su Frontdoor di Azure e 128 KB su Application Gateway.
• Nessuna delle due funzionalità supporta Internet Explorer; entrambe supportano le versioni attuali di Microsoft Edge, Chrome, Firefox e Safari.
• La sfida JavaScript viene ripubblicata quando l'indirizzo IP di un client cambia e per richieste cross-origin (CORS).
• Su Application Gateway, la sfida JavaScript è in anteprima e non supportata per regole personalizzate a limite di velocità. Application Gateway for Containers WAF non lo supporta.

Limitazione del tasso

Al minimo, crea una regola di limite di velocità che blocchi un alto tasso di richieste da parte di un singolo client. Imposta questa regola come la tua regola di limite di tasso di priorità più bassa (valore numerico più alto), così da valutare prima regole di limite di tasso o di corrispondenza più specifiche.

Frontdoor di Azure

• I limiti di velocità si applicano per ogni indirizzo IP del socket, che è l'indirizzo del client che apre la connessione TCP ad Frontdoor di Azure e potrebbe essere un proxy piuttosto che l'utente finale.
• Le soglie vengono valutate in una finestra fissa di uno o cinque minuti. Una volta superata la soglia, Frontdoor di Azure blocca tutto il traffico che corrisponde alla regola per il resto della finestra. Usa la finestra di cinque minuti per la mitigazione del flood HTTP: un attaccante bloccato nel primo minuto rimane bloccato per i restanti quattro.
• Le finestre più grandi con la soglia accettabile più bassa sono la configurazione anti-DDoS più efficace. Finestre più grandi e valori di soglia più elevati impongono anche una soglia più vicina alla soglia configurata. A soglie molto basse (sotto circa 200 richieste al minuto), alcune richieste sopra la soglia possono passare, perché le richieste di un client possono arrivare su server Front Door i cui contatori non sono ancora stati aggiornati.
• Le regole di limite di velocità supportano solo azioni di Log e Blocco ; Il permesso non è supportato.
• Applica una regola a tutto il traffico abbinando su un'intestazione Host con lunghezza maggiore di 0 perché ogni richiesta valida ad Frontdoor di Azure ne ha una.

Gateway delle applicazioni WAF v2

• Il limite di velocità utilizza un algoritmo a finestra scorrevole . Tutto il traffico corrispondente viene eliminato durante la prima finestra in cui la soglia viene superata. Dalla seconda finestra in poi, il traffico fino alla soglia è consentito, generando un effetto di limitazione piuttosto che un'interruzione totale per i clienti abbinati.

• Le regole richiedono un GroupByUserSession, che controlla come vengono conteggiate le richieste. Questa funzione ti permette di limitare la velocità con qualcosa di diverso dall'IP del client:

  GroupByVariable	Usarlo quando
  ClientAddr (impostazione predefinita)	Caso normale con contatori indipendenti per IP sorgente
  ClientAddrXFFHeader	Il tuo gateway si trova dietro una CDN o proxy e il vero IP del client è in X-Forwarded-For
  GeoLocation	Vuoi limitare il traffico per paese/regione durante un'alluvione geograficamente concentrata
  GeoLocationXFFHeader	Come sopra, usando l'indirizzo IP in X-Forwarded-For
  None	Un singolo contatore condiviso per un pattern strettamente corrispondente, come una pagina di accesso o una lista di user agent sospetti

• Le regole di limite di velocità richiedono l'ultimo motore WAF (seleziona CRS 3.2 o successivo come regolamento predefinito) e non sono supportate in cloud con spazio aereo.

• Application Gateway conta indipendentemente le soglie per ogni endpoint a cui la policy è collegata. Una singola politica su cinque ascoltatori mantiene cinque set di contatori.

• Le soglie non sono applicate esattamente, quindi non usare il limite di velocità per un controllo dettagliato del traffico. Usalo per mitigare i tassi anomali e mantenere la disponibilità. Usa particolare cautela con regole di ampiezza che utilizzano GeoLocation o None; una soglia mal scelta può causare frequenti interruzioni brevi per traffico legittimo.

Stabilire soglie consapevoli della geografia

Una singola soglia globale deve essere abbastanza generosa per il paese più attivo, il che la rende troppo generosa ovunque altrove. La maggior parte delle applicazioni ha un profilo geografico fortemente distorto in tempo di pace: una manciata di paesi o regioni produce quasi tutto il traffico legittimo, mentre il resto produce un flusso a filo. Il traffico di attacco raramente rispetta questa distribuzione. Dimensionare le soglie per geografia trasforma quell'asimmetria sia in un segnale di rilevamento che in un controllo di mitigazione.

Inizia misurando la tua distribuzione in tempo di pace per almeno una settimana intera, così che gli effetti nei giorni feriali, nei fine settimana e nei fusi orari siano rappresentati:

• Su Frontdoor di Azure, suddividi la metrica del conteggio richieste per la dimensione ClientCountry.

• In Log Analytics, si deduce il paese dall'indirizzo IP del client nel log di accesso:

  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
  

Poi raggruppa i risultati in livelli e imposta una soglia per ciascuno:

Come implementare i livelli dipende dalla piattaforma:

• Application Gateway WAF v2 - usa GroupByVariable: GeoLocation (o GeoLocationXFFHeader dietro una CDN o proxy) in modo che tutto il traffico proveniente da una sola area condivida un contatore, e crea una regola di limite di velocità per livello con una propria soglia. Poiché una violazione agisce contro ogni client in quella zona, misura queste soglie in modo conservativo e validale prima in azione Log: una regola geografica a corrispondenza ampia configurata in modo errato può causare frequenti interruzioni brevi per traffico legittimo.
• Frontdoor di Azure - i contatori sono per indirizzo IP per socket, quindi costruire i livelli con condizioni di geo-matching: una regola di limite di velocità per livello, abbinata nei paesi rilevanti, ciascuno con la propria soglia. Ogni cliente in una geografia a coda lunga ottiene quindi un tetto molto più basso rispetto ai clienti nei tuoi mercati principali, senza che il comportamento di un cliente influenzi gli altri.

Alcune pratiche che mantengono questo sistema sostenibile:

• Ordina le regole dal più specifico al minimo: regole del mercato primario a priorità più alta (valore numerico inferiore), poi secondarie, poi a coda lunga, con il limite globale globale come limite di priorità più bassa.
• Preferisci un'azione di sfida rispetto a un blocco per le geografie a coda lunga. Il traffico da un paese con poco volume legittimo è sospetto nel complesso ma contiene comunque utenti reali - viaggiatori, utenti VPN e dipendenti da remoto.
• Rimisura dopo i lanci di marketing, le espansioni regionali e i principali eventi di prodotto. Una configurazione consapevole della geografia è valida solo quanto la base di riferimento da cui è stata dimensionata.
• Fai attenzione al segnale inverso durante un incidente: un paese che normalmente contribuisce con 1% di traffico che improvvisamente contribuisce con 40% è uno dei modi più rapidi per confermare che stai assistendo a un attacco piuttosto che a una crescita organica.

Scegli una soglia dal tuo traffico

Usa la seguente query Log Analytics per dimensionare la regola generale. Per Application Gateway, sostituisci FrontdoorAccessLog con ApplicationGatewayAccessLog.

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

Per dimensionare le soglie per geografia descritte in precedenza, aggiungi il paese alla stessa richiesta:

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

Imposta la soglia sopra il 99° percentile del traffico in tempo di pace, non al massimo. Il massimo è solitamente un crawler o un client configurato male, e dimensionarlo rende la regola troppo generosa per essere utile durante un attacco.

Regole personalizzate per la mitigazione mirata

Crea regole WAF personalizzate per bloccare o limitare la velocità degli attacchi HTTP e HTTPS che abbiano firme identificabili, come un utente agente, un'intestazione specifica, un cookie, un pattern di query string, URI o una combinazione di essi. Oltre al matching delle stringhe, le regole personalizzate WAF di Frontdoor di Azure possono abbinarsi su:

• Geolocalizzazione: blocca il traffico proveniente da fuori dalla tua regione di servizio, oppure reindirizzalo a una pagina statica.
• Indirizzi IP client (CIDR) e liste di restrizioni IP per indirizzi e intervalli che hai identificato come dannosi.
• Numero AS (ASN): Mitigare le inondazioni provenienti da un provider di hosting o da una rete di transito da cui i tuoi utenti legittimi non provengono davvero, senza enumerare le fasce IP.
• Impronta cliente (JA4): Corrispondenza sull'impronta digitale JA4, un hash derivato dalle caratteristiche di handshake TLS e HTTP del cliente. Poiché gli strumenti di attacco e i client botnet producono un'impronta digitale coerente indipendentemente dall'indirizzo IP da cui inviano, JA4 è una delle firme più durevoli disponibili durante un attacco distribuito: ruotare tra migliaia di indirizzi IP sorgente non cambia l'impronta digitale, e bloccare o limitare la velocità su di essa elimina l'intera botnet con una sola regola. Verifica l'impronta digitale con i tuoi registri di pace prima di applicarla. I browser popolari e gli SDK comuni condividono impronte digitali su un numero enorme di utenti legittimi, quindi un blocco JA4 non validato può essere estremamente ampio. Implementa prima l'azione Log , conferma che l'impronta appare solo nel traffico d'attacco, poi passa a Blocca o a una regola di limite di velocità.
• Combinare JA4 con altre condizioni per la mitigazione chirurgica durante un incidente. Ad esempio, limita la velocità invece di bloccare un'impronta digitale JA4 specifica e un ASN da cui non servisci gli utenti, oppure un'impronta digitale JA4 e un URI di richiesta.
• Vincoli di tag di servizio e dimensione sui componenti delle richieste.

Due pratiche che contano durante un incidente:

• Crea regole di Permesso corrispondenza per traffico legittimo noto per ridurre i falsi positivi e assegna loro una priorità più alta (valore numerico inferiore) rispetto alle tue regole di blocco e limite di tasso. Ricorda che una regola Allow bypassa altre ispezioni WAF ma non bypassa il regolamento HTTP DDoS.
• La valutazione delle regole si interrompe su qualsiasi azione tranne Log, e i numeri di priorità devono essere unici. Riserva un blocco di numeri a bassa priorità per le regole di emergenza così puoi inserirne uno durante un attacco senza rinumerare.

Le regole gestite non sono mirate alla difesa DDoS, ma proteggono da altri attacchi comuni e dovrebbero rimanere attivate. Vedi regole gestite (Frontdoor di Azure) o regole gestite (Application Gateway).

Proteggi l'origine

• Blocca l'accesso agli IP pubblici sull'origine e limita il traffico in entrata in modo che solo Frontdoor di Azure o Application Gateway possano raggiungerlo. Segui le indicazioni per proteggere il traffico verso Frontdoor di Azure origins.
• Assicurarsi che non ci siano indirizzi IP pubblicamente esposti nella rete virtuale del Gateway di Applicazione.
• Abilita la cache su Frontdoor di Azure. Le risposte in cache assorbono il volume massimo al bordo e riducono la frequenza di richiesta che raggiunge la tua origine, che spesso è la differenza tra prestazioni degradate e un'interruzione.
• Origine della scala con headroom. Le mitigazioni automatiche e manuali richiedono tempo per essere attivate; La capacità di sobra copre quella lacuna.

Rispondere a un attacco attivo

1. Conferma che sia un attacco, non una crescita organica. Controlla i WAF e i log di accesso per eventuali cambiamenti improvvisi nel tasso di richiesta, nel conteggio degli IP dei client, nella distribuzione geografica, nella distribuzione degli user agent e negli URI richiesti.
2. Controlla cosa sta già attenuando. Conferma che il regolamento HTTP DDoS sia attivo e rivedi i suoi blocchi per nome della regola. Su Application Gateway, controlla anche la dimensione della casella di penalità e le metriche dei blocchi della casella di penalità , poiché solo il primo blocco per indirizzo IP appare nei log. Rivedi le corrispondenze delle regole dei limiti di tasso.
3. Confronta la composizione geografica con la tua base di riferimento. Un paese che normalmente contribuisce con una piccola quota di traffico dominandolo improvvisamente è un segnale d'attacco veloce e ad alta fiducia. Ti dice anche quale livello di regole di limite di tasso inasprire per primo.
4. Aumenta la sensibilità prima di scrivere nuove regole. Aumentare la sensibilità del set di regole HTTP DDoS o abbassare una soglia di limite di velocità esistente è più veloce e sicuro che creare una nuova regola sotto pressione.
5. Sfidare invece di bloccare dove il traffico è misto. Applica la sfida JavaScript alle rotte HTML interessate e CAPTCHA ai flussi sensibili.
6. Scrivi una regola mirata solo dopo aver identificato una firma duratura: ASN, impronta digitale del cliente, combinazione di header, geografia o pattern URI. Distribuiscilo prima in Log action se il pattern corrisponde anche agli utenti reali.
7. Mantieni l'origine protetta mentre la sintonizzi: verifica che la cache sia attiva, conferma il blocco dell'origine e scala la scala.
8. Dopo l'incidente, ristabilisci le soglie del limite di tariffa rispetto ai nuovi dati di traffico e mantieni le regole di emergenza che si sono rivelate accurate in modalità Log se non vuoi che vengano applicate continuamente.

Analizza i WAF e i log di accesso

Monitorare il traffico utilizzando i log WAF di Azure per individuare anomalie e usarli per identificare indirizzi IP sospetti che inviano numeri insolitamente elevati di richieste, stringhe di user agent insolite o pattern di query anomali.

Frontdoor di Azure

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

gateway applicazione di Azure

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Top talker e top user agent sulla finestra d'attacco (Frontdoor di Azure mostrato; sostituto ApplicationGatewayAccessLog di 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

Per maggiori informazioni, consulta Azure WAF con Frontdoor di Azure e Azure WAF con gateway applicazione di Azure.

Contenuti correlati

• Regolamento HTTP DDoS: Frontdoor di Azure WAF | Application Gateway WAF
• WAF exceptions list: Frontdoor di Azure WAF | Application Gateway WAF
• Rate limiting: Frontdoor di Azure WAF | Application Gateway WAF
• Configurazione WAF: Frontdoor di Azure | Application Gateway
• Azure sfida JavaScript WAF
• Frontdoor di Azure WAF CAPTCHA
• Protezione DDoS su Frontdoor di Azure
• Architetture di riferimento Azure DDoS Protection
• Panoramica della protezione DDoS di Azure