Il DDoS non è un unico problema. Volume in rete e richieste HTTP 'legali' ma tossiche si affrontano su piani diversi. L'hosting copre il primo. Il secondo è tuo.
Un DDoS non è un unico problema. C'è il volume che satura la rete, e c'è la richiesta HTTP "legale" che satura l'applicazione. L'hosting, la CDN, l'anycast, lo scrubbing lavorano sul primo. Rate-limit, WAF, endpoint costosi, code: sul secondo. Confondere i due piani produce la frase sbagliata: "abbiamo la protezione DDoS" mentre il login, la ricerca o il checkout cadono sotto un flood di GET.
In breve: Attacco volumetrico e attacco applicativo si mitigano in posti diversi. Un SYN flood colpisce la pila TCP. Un HTTP flood colpisce l'origine con richieste che sembrano traffico vero. Per il volume servono rete, anycast, CDN, scrubbing. Per il layer applicativo servono WAF, rate-limit e un'app che non esplode su un path. L'ENISA Threat Landscape 2024 include il DDoS tra le minacce documentate. Qui non si citano cifre in Tbps: cambiano, e non spostano il metodo.
Cosa trovi in questo articolo
Due piani: volume e applicazione
Il volumetrico mira al tubo e agli apparati: UDP flood, amplification, traffico che riempie l'uplink prima che l'HTTP esista. L'applicazione non fa in tempo a dire 200 o 429: i pacchetti non arrivano, o arrivano già morti. Mitigare qui è un problema di capacità, di distribuzione geografica, di centri di scrubbing. Non si risolve con un plugin nel CMS.
L'applicativo (layer 7) arriva con TCP e TLS già stabiliti. GET e POST sembrano utenti. Colpiscono /search, /login, una scheda con query pesante, un add-to-cart. L'uplink è vuoto, la CPU e il database no. Un WAF e un rate-limit lavorano qui. La documentazione Cloudflare su DDoS Protection distingue esplicitamente protezione di rete e protezione applicativa: non è marketing, è il taglio giusto.
Nel cluster Infrastruttura il DDoS sta accanto a DNS, hosting, CDN. Non sta al posto del codice. Un sito lento di suo, sotto un flood applicativo, cade prima. Un sito sano, sotto un volumetrico che riempie l'uplink, cade lo stesso se nessuno pulisce il traffico prima dell'origine.
SYN flood e HTTP flood
Il SYN flood è un attacco alla pila TCP: molti SYN, pochi handshake completati, tabelle delle connessioni piene. Il server è occupato a ricordare connessioni che non esisteranno. Si mitiga in rete e sul bordo (SYN cookies, filtri, anycast), non con un rewrite di PHP. Se il tuo unico strumento è "riavvia Apache", stai trattando un problema di protocollo come un problema di processo.
L'HTTP flood è un'altra specie. Le connessioni si completano. Le richieste sono coerenti con l'API del sito. Spesso ruotano IP, user-agent, path. Un rate-limit rozzo per IP colpisce anche un NAT aziendale o un mobile carrier. Un WAF con regole su pattern noti aiuta; un flood su un endpoint lecito e costoso (ricerca full-text, report, checkout) passa. Qui il mestiere è dell'applicazione: costo per richiesta, cache, coda, autenticazione, captcha dove ha senso, non a tappeto sulla home.
In mezzo restano varianti lente (connessioni tenute aperte, header a spizzichi) e attacchi misti. Non serve un catalogo. Serve sapere su quale piano stai combattendo: pacchetti o richieste. I log e il monitoring lo dicono, se li hai. Il "sembra lento" no.
Cosa può fare l'hosting (e la rete davanti)
Un provider può mettere capacità di rete, filtri volumetrici, anycast, una CDN, uno scrubbing che devia il traffico, lo pulisce, lo rimanda all'origine. Può assorbire picchi che un singolo VPS non vedrà mai arrivare interi. Può tenere su DNS e bordo mentre l'origine è piccola. Questo è il piano su cui si giocano i servizi hosting di Servereasy quando il problema è volume e rete, non la query del catalogo.
Cosa non può fare, da solo. Non può sapere quale POST di checkout è un utente e quale è un bot che clona il form. Non può rendere economica una ricerca non indicizzata. Non può sostituire un rate-limit applicativo su /wp-login.php o su un'API senza autenticazione. La CDN aiuta se il contenuto è cachabile; su HTML privato e su POST l'origine resta il bersaglio. La mappa DNS / origine / CDN è in DNS, hosting, CDN: davanti al volumetrico quella mappa conta, davanti a un flood su un endpoint dinamico conta meno.
Chi vende "protezione DDoS inclusa" senza dire se è L3/L4, L7, o un null-route quando il volume sale, sta vendendo una frase. Null-route significa: il tuo IP sparisce, il traffico tossico e quello buono insieme. A volte è l'ultima ratio della rete. Non è disponibilità. Va detto prima, in contratto, non durante l'attacco.
Cosa resta a te
Endpoint costosi: ricerca, filtri, export, report, webhook, login, reset password, add-to-cart, pagamento. Ognuno è un moltiplicatore. Un flood su questi path è traffico "valido" per il WAF generico. Serve rate-limit per credenziale, per IP, per sessione, per token; lockout; code; timeout; circuit breaker verso il database. Il WAF è un filtro HTTP, non una toppa sul costo di una query.
Autenticazione e bot. Un form di login senza ritardo, senza blocco, senza evidenza nei log, è un invito. Un'API pubblica senza quota anche. Il WAF può tagliare pattern noti e reputazione. Il resto è prodotto: cosa è anonimo, cosa richiede un account, cosa si può cachare.
Capacità dell'origine. Se l'app serve ogni HTML dal database, senza cache, un HTTP flood piccolo basta. Se gli statici passano dalla CDN e l'HTML pubblico ha una policy seria, l'origine vede meno. La protezione applicativa comincia da quanto lavoro fai per request, non dal nome commerciale del "DDoS protection". Nel cluster Sicurezza questo pezzo sta accanto alle patch: superficie piccola, costi per request piccoli, filtri dove servono.
Picco vero, attacco, origine lenta
Un lancio, una campagna, un articolo che gira: traffico vero, path noti, conversioni, referer coerenti. Un attacco volumetrico: banda satura, poco HTTP utile, metriche di rete prima di quelle applicative. Un HTTP flood: tante richieste su pochi path costosi, 5xx, CPU e DB alti, banda tranquilla. Un'origine lenta senza attacco: gli stessi 5xx, ma volumi normali e query evidenti. Si guarda rete e applicazione insieme. Uno solo dei due mente.
Prima dell'incidente: sapere chi si chiama (hosting, CDN, registrar, chi può cambiare DNS), quale IP è origin, cosa succede se si "abilita la protezione", se esiste un null-route. Durante: non riscrivere il CMS. Si alza il filtro, si cachano i GET pubblici, si chiudono gli endpoint che non servono, si parla con chi ha la rete. Dopo: si scrive cosa ha tenuto e cosa no. Un DDoS è anche un test di runbook. Se il runbook è una chat, il prossimo flood ricomincia da zero.
Errori da evitare
Comprare "anti-DDoS" e non sapere se è volumetrico, applicativo, o un null-route. Tre prodotti, tre esiti.
Puntare un WAF contro un uplink saturo. Il WAF non vede i pacchetti che non arrivano.
Puntare una CDN contro un flood di POST sul checkout. L'origine resta il bersaglio.
Rate-limit solo per IP. Carrier, VPN, uffici dietro NAT: falsi positivi e buchi.
Scoprire in attacco chi può toccare il DNS. I recapiti si raccolgono prima.
Citare terabit come se fossero un piano. Il metodo non cambia con la cifra del comunicato stampa.
In sintesi
Volume in rete, richieste in applicazione: due piani, due proprietari. L'hosting e il bordo (anycast, CDN, scrubbing) tengono il tubo. WAF, rate-limit e costo per request tengono il prodotto. SYN flood e HTTP flood non si combattono con lo stesso tasto. ENISA elenca il DDoS tra le minacce del landscape; Cloudflare documenta la spaccatura L3/L4 e L7. Il resto è sapere, prima del picco, chi mitiga cosa, e non chiamare "protezione" un null-route. Meno rumore, più metodo.
Fonti
ENISA, ENISA Threat Landscape 2024.
Cloudflare Docs, DDoS Protection.
Cloudflare Learning, What is a DDoS attack?.
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
