Applicazione (livello 7) Protezione DDoS

Applicabile 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 il traffico che il livello superiore non intercetta.

Livello Funzionamento Dove configurarlo
Protezione DDoS della piattaforma Assorbe gli attacchi volumetrici L3/L4 all'edge di Azure e sugli IP pubblici dei tuoi server di origine Integrato di default su Frontdoor di Azure; richiede la protezione di rete DDoS di Azure per gli IP pubblici di Application Gateway e gli IP pubblici di origine
Mitigazione automatica di L7 Apprende il normale traffico e limita i client problematici durante un picco, senza necessità di tarature di emergenza Set di regole HTTP DDoS (anteprima) su Frontdoor di Azure Premium e Application Gateway WAF v2
Verifica del cliente Distingue gli esseri umani e i clienti legittimi dal traffico di attacco automatizzato prima di bloccarlo Regolamento Bot Manager, sfida JavaScript, CAPTCHA
Limitazione del tasso Limita il numero di richieste che ogni client, geografia o endpoint può inviare Regole personalizzate del limite di velocità su Front Door e Application Gateway
Regole personalizzate mirate Blocca una firma di attacco nota durante un incidente Abbina regole personalizzate (geo, IP, ASN, fingerprint del client, header, URI)
Protezione dell'origine Impedisce al traffico dannoso di raggiungere del tutto le tue risorse di calcolo Caching, blocco dell'origine, scalabilità automatica

Lista di controllo della configurazione di base

Completa questi passaggi prima di essere attaccato. Adattali ai requisiti della tua applicazione.

  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 ottimizza prima la politica sul traffico di produzione per ridurre i falsi positivi, poi abilita la prevenzione.
  3. Assegna il set di regole HTTP DDoS (disponibile sia in Frontdoor di Azure Premium sia in Application Gateway WAF v2) in modo che la mitigazione automatica apprenda il profilo di base del tuo traffico prima che te ne serva.
  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 nell'edge di Front Door anziché in corrispondenza di un indirizzo IP di tua proprietà, quindi non esiste alcun tuo IP pubblico che un utente malintenzionato possa prendere di mira a livello 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 applicazione è 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, prevedi nel budget i controlli L7; la protezione edge L3/L4 è già presente.
  • 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 set di regole apprende sia una soglia globale (per ogni profilo Front Door o per ogni gateway applicativo) sia soglie individuali 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.
  • Con ambito 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 il set di regole per il traffico affidabile. Una regola personalizzata con un'azione Consenti non aiuta in questo caso: bypassare tutti le altre regole ma non quella HTTP DDoS. Usa invece le eccezioni WAF, che puoi applicare a una regola specifica, a un gruppo di regole o a un intero set di regole gestite, incluso il set di regole HTTP DDoS. Vedi Esentare il traffico attendibile con eccezioni.
  • Richiede traffico costante. Il set di regole può agire solo dopo aver appreso valori di riferimento 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

Caratteristica Frontdoor di Azure Premium Gateway delle applicazioni WAF v2
Fase di apprendimento I valori di riferimento vengono calcolati su una finestra mobile; il rilevamento inizia entro 24–36 ore per i profili che hanno ricevuto traffico per almeno il 50% degli ultimi sette giorni Le baseline vengono definite per un minimo di 24 ore; il set di regole non esegue il rilevamento né il blocco fino al completamento della fase di apprendimento di 24 ore
Traffico insufficiente Se un profilo ha ricevuto traffico per meno di 50% degli ultimi sette giorni, il regolamento non rileverà né bloccherà finché non esiste abbastanza traffico per una base affidabile Se il gateway non riceve abbastanza traffico durante la fase di apprendimento di 24 ore per stabilire basi affidabili, il regolamento non rileverà né bloccherà gli attacchi finché non lo farà
Mitigation Gli indirizzi IP responsabili vengono inseriti in una lista di penalizzazione e bloccati per la durata della penalizzazione Gli indirizzi IP problematici vengono messi in una casella penale e bloccati per 15 minuti
ID delle regole 500100 (tasso di richieste del cliente), 500110 (bot sospetti) 500100 (tasso di richieste del cliente), 500110 (bot sospetti)
Metriche aggiuntive Web application firewall HTTPDDoSRuleset è attivo Dimensione del riquadro di penalità, blocchi del riquadro di penalità

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:

Rule Description
500100: Anomalia rilevata su alto tasso di richieste dei clienti Definisce una baseline di riferimento per tutto il traffico del profilo Front Door o del gateway applicazione a cui è associato il criterio. Quando un client supera la soglia appresa, l'azione configurata si attiva e l'indirizzo IP incriminato viene inserito nella casella di penalità.
500110: Bot sospetti che inviano alte richieste Mantiene basi separate, generalmente molto più rigide, per il traffico classificato come bot da Microsoft Threat Intelligence. I bot classificati come ad alto rischio vengono bloccati immediatamente non appena la soglia globale viene superata.

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 riottiene l'accesso, a meno che non superi di nuovo la soglia, nel qual caso torna nel periodo di penalizzazione.

Questa impostazione è importante ai fini dell’interpretazione dei dati di telemetria: viene registrata solo la prima attivazione 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 oltrepassa una soglia, viene registrata una voce di log con un'azione Block per il set di regole HTTP DDoS e la metrica WAF Managed Rule Match viene incrementata.

  • Front Door: utilizzare la metrica Web application firewall Request count, filtrata in base al nome della regola, per conteggiare i blocchi, e la metrica Web application firewall HTTPDDoSRuleset Is Active, che restituisce 1 una volta completato l'apprendimento e il set di regole è 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 in base a:

  • 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
  • Richiedere l'URI
  • Nome e valore dell'header della richiesta, corrispondenti a Uguale a, Inizia con, Finisce con o Contiene

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

  • Definisci l'ambito nel modo più ristretto possibile. Preferisci un'eccezione per ogni regola piuttosto che esentare l'intero regolamento di regole. Un'eccezione ampia fornisce a un attaccante una modalità documentata per aggirare la tua misura di mitigazione automatizzata. Se un generatore di carico ha bisogno solo di essere sollevato dalla regola 500100, non esentarlo anche dalla 500110.
  • Origini esenti, non percorsi. Un'eccezione basata su IP per un ambiente di test noto è delimitata. Un'eccezione basata su URI su un endpoint pubblico è una porta aperta per chiunque la trovi.
  • Rivedili regolarmente. 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.

Importante

Le eccezioni WAF e il regolamento HTTP DDoS sono in anteprima sia su Frontdoor di Azure che su Application Gateway WAF v2. Vedere le Condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure.

Richiedi conferma 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 inserire ostacoli sulle route API. Usa invece lì le regole di limitazione della frequenza e le regole di corrispondenza.
  • 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 emessa nuovamente quando l'indirizzo IP di un client cambia e per le 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 regola con priorità più bassa per la limitazione della frequenza (valore numerico più alto), in modo che le regole di limitazione della frequenza o di corrispondenza più specifiche vengano valutate per prime.

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 limitazione della frequenza supportano solo le azioni Log e Block; Allow non è supportata.
  • Applica una regola a tutto il traffico in base a un'intestazione Host di lunghezza superiore a 0, perché ogni richiesta valida a Frontdoor di Azure ne include una.

Gateway delle applicazioni WAF v2

  • Il limite di velocità utilizza un algoritmo a finestra scorrevole . Tutto il traffico corrispondente viene scartato nella 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 limitazione della frequenza richiedono l’ultima versione del motore WAF (seleziona CRS 3.2 o versioni successive per il set di regole predefinito) e non sono supportate nei cloud isolati.

  • Application Gateway conta indipendentemente le soglie per ogni endpoint a cui la policy è collegata. Una singola policy associata a cinque listener mantiene cinque serie 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 le regole di corrispondenza ampia che utilizzano GeoLocation o None; una soglia scelta male può causare frequenti brevi interruzioni del 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:

  • In Frontdoor di Azure, suddividi la metrica Numero di richieste in base alla 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:

Tier Condivisione a tempo ritmato Trattamento raccomandato
Mercati primari I paesi che producono la maggior parte del tuo traffico Soglia generosa per cliente, dimensionata a partire dal p99 di quel paese così che gli utenti reali non siano mai influenzati
Mercati secondari Traffico significativo ma modesto Soglia per cliente più stretta, dimensionata dal p99 di quel paese piuttosto che da quella globale
Geografie a coda lunga Un flusso di traffico legittimo Soglia aggressiva, o un'azione di sfida invece di un blocco
Aree geografiche non servite Praticamente zero Blocca completamente, oppure reindirizza a una pagina statica

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é il superamento di una soglia si applica a tutti i client in quell’area geografica, imposta queste soglie in modo conservativo e convalidale prima in modalità Log: una regola geografica con corrispondenza ampia configurata in modo errato può causare frequenti brevi interruzioni del servizio per il traffico legittimo.
  • Frontdoor di Azure - i contatori sono per indirizzo IP del socket, quindi configurare i livelli con condizioni di corrispondenza geografica: una regola di limitazione della frequenza per livello, applicata ai paesi pertinenti, ognuna 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.
  • Preferire 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 in base al tuo traffico

Usa la seguente query di Log Analytics per determinare le dimensioni della regola catch-all. 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 valore massimo è solitamente un crawler o un client configurato in modo errato, e basarsi su di esso per il dimensionamento rende la regola troppo permissiva 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 alla corrispondenza delle stringhe, le regole personalizzate di Frontdoor di Azure WAF possono corrispondere in base a:

  • 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): Mitiga gli attacchi flood provenienti da un provider di hosting o da una rete di transito da cui non proviene il traffico dei tuoi utenti legittimi, senza dover elencare gli intervalli IP.
  • Impronta del client (JA4): Corrispondenza in base all'impronta JA4, un hash derivato dall'handshake TLS del client e dalle caratteristiche HTTP. 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. Verificare l'impronta digitale con i log a tempo ritmato 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.
  • Tag di servizio e vincoli di dimensione nei componenti della richiesta.

Due pratiche che contano durante un incidente:

  • Crea regole di corrispondenza Consenti per il traffico legittimo noto per ridurre i falsi positivi e assegna loro una priorità più alta (valore numerico inferiore) rispetto alle regole di blocco e di limitazione della frequenza. Ricorda che una regola Allow aggira le altre ispezioni del WAF, ma non aggira il set di regole 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 memorizzate nella cache assorbono i picchi di traffico sull’edge e riducono il tasso di richieste che raggiunge il tuo server di origine, facendo spesso la differenza tra un degrado delle prestazioni e un’interruzione del servizio.
  • Origine di scalabilità con capacità aggiuntiva. Le mitigazioni automatiche e manuali richiedono tempo per entrare in funzione; la capacità di riserva copre quel divario.

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. Verifica cosa sta già mitigando. Conferma che il set di regole HTTP DDoS sia attivo e verifica i blocchi in base al 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 protetta l'origine durante l'ottimizzazione: verifica che la cache sia attiva, conferma la protezione dell'origine ed effettua lo scale-out.
  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"

Principali origini del traffico e principali agenti utente durante la finestra di attacco (Frontdoor di Azure mostrato; sostituire ApplicationGatewayAccessLog per il gateway applicazione):

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

  • Ultimo aggiornamento: