Set di regole HTTP DDoS in Frontdoor di Azure WAF

Si applica a: ✔️ Frontdoor Premium

Gli attacchi flood a livello HTTP rimangono la causa più frequente di incidenti di disponibilità delle applicazioni, e i controlli statici come filtri IP e geo o limiti di frequenza fissi spesso non riescono a tenere il passo con i botnet distribuiti. Il set di regole HTTP DDoS è il modello di protezione automatico di livello 7 di Web application firewall di Azure (WAF) che apprende, rileva e difende con una configurazione minima per l'utente. Una volta assegnato, il set di regole definisce continuamente una baseline del traffico normale per ogni profilo Frontdoor di Azure e, quando i picchi indicano un attacco, mitiga selettivamente il traffico incriminato senza richiedere una regolazione d'emergenza.

Funzionamento del set di regole DDoS HTTP

Una volta applicato il set di regole HTTP DDoS a una policy collegata a un profilo Frontdoor di Azure Premium, le linee di riferimento del traffico vengono calcolate utilizzando una finestra a rotazione. Per i profili che hanno ricevuto traffico per almeno il 50% degli ultimi sette giorni, il set di regole calcola i punti di riferimento e inizia a rilevare picchi entro 24-36 ore. Se il profilo Front Door non ha ricevuto traffico sufficiente (meno del 50% degli ultimi sette giorni), il set di regole non rileverà né mitigherà gli attacchi finché non sarà presente abbastanza traffico per stabilire basi affidabili.

Le soglie delle richieste vengono apprese a livello di profilo globale. Se un singolo criterio di Web application firewall configurato con il set di regole DDoS HTTP viene assegnato a più profili di Frontdoor di Azure, le soglie di traffico vengono calcolate separatamente per ogni profilo a cui è associato il criterio.

Il set di regole utilizza una struttura a due fasi. Determina una soglia globale del profilo, più soglie più ristrette per i singoli indirizzi IP dei client e, con le regole geografiche, per ogni paese/regione. Finché la soglia del profilo per le richieste non viene superata, le soglie più ristrette non vengono applicate. Questo approccio impedisce al set di regole di agire sui picchi di traffico di pochi client, a meno che non facciano superare la velocità totale di richiesta sul profilo.

Ogni regola nel set di regole DDoS HTTP offre tre livelli di riservatezza, ognuno corrispondente a una soglia diversa. Un'impostazione di riservatezza più elevata applica una soglia inferiore per tale regola, mentre un'impostazione di riservatezza inferiore applica una soglia superiore. L'impostazione predefinita e consigliata è una riservatezza media.

Quando assegni il set di regole, le sue regole sono abilitate con l'azione Log e sensibilità media per impostazione predefinita. Rivedi i log e poi imposta l'azione di ogni regola in modo che si adatti alla tua applicazione.

Il set di regole DDoS HTTP è il primo set di regole valutato da Web application firewall di Azure, anche prima delle regole personalizzate.

Importante

Qualsiasi regola personalizzata configurata con l'azione Allow non bypasserà il set di regole HTTP DDoS, ma bypasserà tutte le altre ispezioni WAF. Per esentare il traffico affidabile dal set di regole HTTP DDoS, si usano eccezioni.

Casella di penalità

Una volta superata la soglia del profilo, qualsiasi indirizzo IP client che supera la soglia per la regola 500100 o 500110 viene inserito in una lista di penalità. Mentre l'indirizzo IP è nell'area di penalità, il WAF applica l'azione configurata della regola alle sue richieste. Quando il periodo di penalizzazione termina, l'indirizzo IP viene nuovamente valutato normalmente e torna nel periodo di penalizzazione se supera nuovamente la sua soglia.

Regole del set

Il set di regole HTTP DDoS appare come Microsoft_HTTPDDoSRuleSet_1.0 nelle regole gestite della tua policy WAF e ha quattro regole. Ogni regola mantiene linee di base separate per il traffico che corrispondono ai suoi criteri, e ciascuna è configurabile con la propria sensibilità e azione.

ID Regola Rule Che cosa definisce come baseline Status
500100 Anomalia rilevata a causa dell’elevato tasso di richieste dei client Richieste da ciascun indirizzo IP client Generalmente disponibile
500110 Bot sospettati che inviano un alto tasso di richieste Richieste da indirizzi IP che la Microsoft Threat Intelligence classifica come bot Generalmente disponibile
500310 Anomalia rilevata: tasso elevato di richieste da aree geografiche di origine ad alto volume Richieste da ogni paese/regione ad alto volume Anteprima
500320 Anomalia rilevata su un alto tasso di richieste da geo sorgente a basso volume Richieste combinate da ogni altro paese/area geografica Anteprima

Regola 500100: Anomalia rilevata su un alto tasso di richieste dei client: Questa regola traccia e stabilisce una baseline per tutto il traffico sul profilo a cui è collegata una policy. Quando un client supera la soglia stabilita, viene attivata l'azione configurata corrispondente.

Regola 500110: Bot sospettati che inviano un alto tasso di richieste: Questa regola permette di impostare diversi livelli di sensibilità in base al traffico classificato come bot da Microsoft Threat Intelligence. La soglia predefinita per i bot sospetti è più restrittiva rispetto alla soglia predefinita per tutti gli altri indirizzi IP. I bot classificati come a rischio elevato vengono bloccati immediatamente da questa regola quando viene superata la soglia per il profilo globale.

Le regole 500310 e 500320 sono le regole geo, descritte nella sezione successiva.

Regole geografiche (anteprima)

Importante

Le regole geo nel set di regole HTTP DDoS, regole 500310 e 500320, sono attualmente in anteprima. Il resto del set di regole HTTP DDoS è generalmente disponibile. Vedere le condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale.

Le soglie per IP funzionano bene contro attacchi in cui ogni client invia un grande volume di richieste. Sono meno efficaci contro attacchi altamente distribuiti, in cui una botnet distribuisce il suo traffico su così tanti indirizzi IP che ognuno rimane sotto la propria soglia. Le regole geografiche aggiungono un secondo livello di difesa che stabilisce una baseline del traffico per paese/regione invece che per cliente.

Come funzionano le regole geo

La maggior parte delle applicazioni riceve la maggior parte del traffico legittimo da un piccolo numero di paesi o regioni ad alto volume. Le regole geo usano questo schema:

  • La regola 500310 apprende una soglia separata per ogni paese o regione ad alto volume.
  • La Regola 500320 apprende una soglia combinata per ogni altro paese o regione. Le richieste da tutte queste fonti a basso volume contano insieme per questa singola soglia.

Ad esempio, supponiamo che la maggior parte del traffico di un profilo provenga dagli Stati Uniti, dall'Australia e dalla Francia. La regola 500310 determina una soglia per ciascuna di queste tre, e la regola 500320 determina una soglia per il traffico combinato proveniente da tutte le altre origini. Durante un attacco, un picco dagli Stati Uniti viene misurato rispetto alla soglia USA, mentre un attacco diffuso in molte altre località viene misurato rispetto alla soglia combinata.

Le regole geografiche seguono lo stesso design a due stadi del resto del set di regole: agiscono solo dopo che il tasso complessivo di richieste del profilo supera la soglia appresa. Quando ciò accade e la frequenza delle richieste da un paese o regione ad alto volume supera la sua soglia, la regola 500310 applica la sua azione alle richieste provenienti da quel paese o regione. Quando la tariffa combinata di richieste da ogni altro paese o regione supera la sua soglia, la regola 500320 applica la sua azione alle richieste provenienti da tutte queste fonti a basso volume.

Tieni a mente i seguenti comportamenti:

  • Le regole geo apprendono le loro linee di base da circa sette giorni di traffico e le ricalcolano periodicamente, così da seguire i cambiamenti nel tempo del traffico.
  • Le soglie riflettono il traffico di picco piuttosto che la media, quindi i picchi giornalieri normali restano al di sotto di essi.
  • Le richieste da indirizzi IP che non sono mappate a un paese o regione sono raggruppate come paese o regione sconosciuta (ZZ) e incluse nella baseline come qualsiasi altro paese o regione.
  • Se un profilo non ha abbastanza storia del traffico per stabilire valori di riferimento affidabili, le regole geografiche non agiscono per quel profilo.
  • Le regole geo vengono valutate dopo la regola 500100. I client che superano le proprie soglie per IP sono gestiti prima dalla regola per IP, e le regole geografiche agiscono poi sul traffico distribuito che rimane sotto le soglie per IP.

Scegli azioni e sensibilità per le regole geo

Una georegola agisce sul traffico proveniente da un paese o regione nel suo complesso, non su singoli clienti. Quando una regola geografica trova corrispondenza, la sua azione si applica agli utenti legittimi di quel paese o regione così come al traffico di attacco. Pianifica questo prima di cambiare l'azione predefinita:

  • Inizia con l'azione Log. Le regole geo sono abilitate di default con l'azione Log. Controlla i log nei periodi di traffico normale e durante eventuali picchi prima di attivarle.
  • Scegli una sfida invece di un blocco. Un controllo JavaScript permette ai browser legittimi di passare bloccando la maggior parte dei client scriptati, limitando così l'effetto sugli utenti reali nel paese o nella regione interessata.
  • Ridurre la sensibilità ai picchi regionali attesi. Se ti aspetti un aumento legittimo da un particolare paese o regione, ad esempio durante una campagna regionale o un lancio di un prodotto, abbassa la sensibilità della regola interessata prima dell'evento.

Esentare il traffico affidabile dal set di regole

Una regola personalizzata con un'azione Allow non bypassa il set di regole HTTP DDoS. Per consentire al traffico noto e affidabile, come sonde di integrità, monitoraggio sintetico, test di carico o integrazioni con partner, di bypassare il set di regole, utilizzare le eccezioni WAF. Puoi limitare un'eccezione a una regola specifica nel set di regole HTTP DDoS o all'intero set di regole, e fare corrispondenza in base all'indirizzo IP remoto, all'URI della richiesta o a un'intestazione della richiesta.

Limitare le eccezioni nel modo più ristretto possibile. Ad esempio, se uno strumento di test di carico ha bisogno solo di una deroga alla regola 500100, non esentarlo dalle altre regole del set di regole.

Monitorare il set di regole DDoS HTTP

Le seguenti opzioni di monitoraggio sono disponibili per il set di regole HTTP DDoS:

  • Quando un indirizzo IP supera per la prima volta una soglia per la regola 500100 o 500110, viene registrata una voce di log per quell'indirizzo IP con l'azione della regola, e la metrica Match della regola gestita da WAF viene incrementata.
  • Puoi monitorare le corrispondenze delle regole utilizzando la metrica di conteggio richieste Web application firewall e filtrando per nome della regola. Le corrispondenze delle regole Geo sono registrate con gli ID regole 500310 e 500320.
  • La metrica Web application firewall HTTPDDoSRuleset Is Active ha un valore di 1 una volta che il set di regole ha completato l'apprendimento ed è pronto ad agire sul traffico che supera le soglie apprese.

Contenuti correlati

  • Ultimo aggiornamento: