Attacchi di livello 3, livello 4 e livello 7
Gli attacchi di livello 3 prendono di mira il livello di rete (IP, ICMP) — esempi sono ICMP flood e attacchi di frammentazione IP. Gli attacchi di livello 4 prendono di mira il livello di trasporto (TCP, UDP) — esempi sono SYN flood, amplificazione UDP e amplificazione DNS. Gli attacchi di livello 7 prendono di mira il livello applicativo (HTTP, HTTPS) — esempi sono HTTP GET/POST flood e Slowloris. Ogni livello richiede una mitigazione diversa.
Gli attacchi volumetrici ai livelli 3 e 4 cercano di saturare la pipe di rete stessa. I più grandi attacchi divulgati pubblicamente hanno superato la soglia di multi-terabit-al-secondo — Cloudflare ha riportato di aver mitigato un attacco di 7,3 Tbps a maggio 2025, e AWS Shield ha riportato un attacco di 2,3 Tbps già a febbraio 2020. Questi attacchi funzionano perché i protocolli di amplificazione (DNS, NTP, memcached, CLDAP) consentono a una piccola query falsificata di innescare una risposta molto più grande inviata alla vittima — fattori di amplificazione di 50x per DNS, 200x per NTP e 50.000x per memcached sono stati documentati. Gli attacchi di protocollo al livello 4 — SYN flood, ACK flood, attacchi di pacchetti frammentati — esauriscono lo stato di connection-tracking sui firewall e bilanciatori di carico piuttosto che saturare la banda. Gli attacchi di livello 7 sono i più piccoli per byte ma i più difficili da filtrare: un HTTP flood da una botnet di 100.000 nodi sembra bit per bit come utenti reali, e solo una logica consapevole dell'applicazione può distinguerli.
BGP blackhole e remote-triggered black hole (RTBH)
Il BGP blackholing è la mitigazione brutale ma efficace di ultima istanza: l'operatore di rete annuncia una rotta /32 per l'IP attaccato in una community BGP 'blackhole' speciale, dicendo a tutti i peer upstream di scartare completamente il traffico verso quell'IP. L'obiettivo rimane offline, ma il resto della rete rimane attivo. RTBH è standardizzato in RFC 5635 e supportato da ogni operatore Tier 1.
RTBH è documentato in RFC 5635 (agosto 2009) e funziona taggando una rotta con un attributo community che i peer upstream interpretano come 'scarta tutto il traffico destinato a questo prefisso'. La mitigazione è totale — l'IP protetto diventa irraggiungibile dall'intera internet, anche dagli utenti legittimi — ma protegge il resto della flotta clienti dai danni collaterali. A causa di quanto è netto, RTBH è appropriato quando un singolo IP è saturato da un attacco di multi-centinaia-di-gigabit e il costo di un'interruzione più ampia supera il mantenere quell'unico IP online. Molti piani VPS 'protetti DDoS' di basso livello significano esattamente questo: il fornitore null-routerà il Suo IP sotto attacco per mantenere il resto della loro flotta al sicuro. È mitigazione del denial-of-service per definizione, ma la risorsa protetta è la rete del fornitore, non la Sua.
Scrubbing center e diversione del traffico
Uno scrubbing center è un sito di rete rinforzato dove il traffico di attacco viene filtrato e il traffico pulito viene inoltrato all'origine. Il traffico viene deviato lì tramite annuncio BGP (sempre attivo o on-demand) o puntamento DNS. La capacità di scrubbing per Tbps è la metrica principale — i più grandi fornitori operano oltre 200 Tbps di scrubbing aggregato, mentre i fornitori di hosting specialistici tipicamente pubblicizzano 1-10 Tbps.
Gli scrubbing center eseguono apparecchiature specializzate — Arbor TMS, Radware DefensePro, A10 Thunder, NSFOCUS ADS, o pipeline Linux/DPDK personalizzate su larga scala — che ispezionano ogni pacchetto, classificano i pattern benigni rispetto a quelli malevoli, e inoltrano solo la frazione pulita all'origine. La diversione viene solitamente fatta tramite BGP: il prefisso del cliente viene annunciato dalla rete anycast del fornitore di scrubbing durante un attacco, attirando tutto il traffico verso il sito di scrubbing più vicino. Dopo la pulizia, il traffico viene tunnelato (GRE, IPSec, cross-connect dedicato o peering diretto) di nuovo al server di origine. La latenza di scrubbing è tipicamente 1-3 ms in regione, più qualsiasi percorso aggiuntivo che la diversione aggiunge. Lo scrubbing sempre attivo mantiene la diversione permanente, eliminando il tempo di avvio della mitigazione al costo di una tassa di latenza costante. Lo scrubbing on-demand devia solo durante gli attacchi rilevati, il che è più economico ma introduce una finestra di attivazione di 30-180 secondi durante la quale l'attacco arriva.
Mitigazione sempre attiva vs on-demand
La mitigazione sempre attiva instrada tutto il traffico attraverso il livello di scrubbing 24/7 — zero ritardo di attivazione, ma ogni pacchetto paga una piccola tassa di latenza (1-5 ms tipica). La mitigazione on-demand si attiva solo quando viene rilevato un attacco, eliminando la latenza in stato stazionario ma esponendo l'origine durante la finestra di attivazione (tipicamente 30-180 secondi). Le configurazioni ibride combinano entrambe: sempre attiva per HTTP/HTTPS, on-demand per traffico IP grezzo.
Scegliere tra sempre attiva e on-demand è un compromesso tra latenza in stato stazionario e vulnerabilità nella finestra di attacco. I servizi sensibili alla latenza — server di gioco multiplayer, trading a bassa latenza, voce/video — generalmente scelgono on-demand e accettano il gap di attivazione perché ogni millisecondo di RTT in stato stazionario costa loro. I servizi web pubblici, le API e le app SaaS generalmente scelgono sempre attiva o una topologia completamente proxata in stile CDN dove l'IP di origine non è nemmeno noto pubblicamente, eliminando completamente la finestra di attacco. I fornitori cloud-edge moderni (Cloudflare, Fastly, AWS Shield Advanced, Google Cloud Armor) preferiscono sempre attiva per impostazione predefinita perché la loro rete termina già il traffico in centinaia di sedi edge e il 'detour' è essenzialmente zero.
Rate limiting, WAF e difesa a livello applicativo
Il rate limiting limita le richieste per IP sorgente, per sessione o per URL, smussando i flood di livello 7 senza influenzare il traffico legittimo. Un Web Application Firewall (WAF) ispeziona le richieste HTTP rispetto a regole — protezioni OWASP Top 10, regole di rate personalizzate, geo-blocking, sfide JS e CAPTCHA. Insieme gestiscono gli attacchi di livello 7 che lo scrubbing volumetrico da solo non può.
Lo scrubbing volumetrico si ferma al confine IP-e-porta. Per fermare un HTTP flood che sembra traffico Chrome reale, ha bisogno di regole che operano su URL, header, cookie e comportamento. Il rate limiting è il controllo di livello 7 più semplice ed efficace: limita un singolo IP a, diciamo, 60 richieste al minuto su /login, scarta il resto. Un WAF va oltre con regole consapevoli del contenuto: blocca richieste con pattern di SQL-injection, user agent anomali, referrer mancanti, origini geografiche al di fuori della Sua area di servizio, o dimensioni del payload molto al di fuori dell'intervallo legittimo. I WAF moderni (AWS WAF, Cloudflare WAF, Fastly Next-Gen WAF, ModSecurity con OWASP Core Rule Set) eseguono anche sfide JavaScript, hCaptcha ed euristiche di bot-fingerprint che riducono il tasso di successo di una botnet del 99%+ senza disturbare i browser reali.
Cosa i fornitori di hosting tipicamente includono vs addebitano extra
I livelli gratuiti o inclusi di solito coprono attacchi volumetrici di livello 3-4 fino a un limite fisso in gigabit-al-secondo (spesso 10-100 Gbps) utilizzando rate limiting di base e BGP blackhole. I componenti aggiuntivi a pagamento tipicamente includono scrubbing sempre attivo, WAF, mitigazione di livello 7, creazione di regole personalizzate e garanzie di mitigazione coperte da SLA. Legga il contratto — 'protezione DDoS illimitata' spesso significa 'La null-routeremo sopra X Gbps'.
Il marketing DDoS dei fornitori di hosting varia ampiamente. La protezione genuinamente utile include tre cose: (1) una capacità dichiarata chiara in Gbps o Tbps, (2) copertura dal livello 3 al livello 7 inclusa la mitigazione HTTP-flood, e (3) un SLA scritto con tempo di inizio della mitigazione e impegni di perdita di traffico. La protezione meno utile è un singolo badge 'protetto DDoS' senza numero di capacità, che di solito significa solo BGP blackhole — il Suo IP viene null-routed sotto attacco e Lei è offline per tutta la durata. Quando valuta, chieda: qual è la capacità dichiarata per IP? È sempre attiva o on-demand? Copre il livello 7? Qual è l'SLA del tempo di attivazione della mitigazione? Cosa succede dopo che l'attacco supera il limite del Suo livello? Le risposte rivelano se sta acquistando vera protezione o un'etichetta di marketing.