Attacchi DDoS: tipi, sintomi e mitigazione

17 febbraio 2026 • 8 min read

Il DDoS non è un fenomeno nuovo, ma è diventato molto più semplice, economico e scalabile. In passato bastavano pochi server configurati male o un piccolo botnet per interrompere un servizio. Oggi vediamo regolarmente attacchi in grado di saturare link in frazioni di secondo, sovraccaricare firewall o mettere in ginocchio applicazioni con richieste che sembrano “normali”.

Questo articolo non vuole creare allarmismo. Serve a dare contesto: che cos’è davvero un DDoS, quali classi di attacco contano nella pratica, come riconoscerle in produzione e quali contromisure valgono il tempo investito.

Che cos’è (D)DoS?

In un attacco di Denial-of-Service (DoS), un attaccante cerca di rendere un servizio inutilizzabile non rubando dati, ma sovraccaricandolo o esaurendo le sue risorse. Il bersaglio è la disponibilità: il sito non carica più, l’API va in timeout, il gateway VPN smette di accettare sessioni o i resolver DNS non tengono il passo.

La “D” di Distributed significa che il traffico non arriva da una sola fonte, ma da molte. Può essere un botnet di dispositivi compromessi, infrastruttura legittima (reflection/amplification) o un mix delle due cose. Per te, come operatore, il risultato è simile: non stai affrontando un singolo attaccante, ma un’inondazione distribuita.

Motivazioni: perché vengono lanciati attacchi DDoS?

Le motivazioni sono spesso poco glamour, ma efficaci:

Estorsione: “Paga, o ti buttiamo giù di nuovo”.
Attivismo/politica: visibilità, messaggi, interruzione.
Distrazione: un DDoS può impegnare il team mentre qualcos’altro avviene in parallelo.
Concorrenza/sabotaggio: in momenti critici (ticketing, release, lanci), anche un down breve fa male.
Pressione sui costi: non tutti gli attacchi puntano a un outage totale; a volte l’obiettivo è aumentare spesa cloud, carico sul supporto o stress operativo.

I layer importanti (e perché contano)

Il DDoS viene spesso descritto per layer, perché il layer ti dice quali segnali guardare e quali difese sono possibili.

Layer 3 (IP): da dove arriva e dove deve andare.
Layer 4 (TCP/UDP): porte, connessioni, handshake, stato.
Layer 7 (Applicazione): richieste HTTP(S), API, endpoint di business.
“Layer 8” (logica di business): non ufficiale, ma reale: logica costosa nell’applicazione che può essere abusata.

Il punto chiave: una difesa perfetta su Layer 3/4 può comunque fallire contro attacchi di Layer 7, perché le richieste possono sembrare legittime e diventare costose solo quando arrivano all’applicazione.

Classe di attacco 1: volume e amplificazione (spesso UDP)

Gli attacchi volumetrici puntano a sovraccaricare banda o packet processing (pps). Un amplificatore classico è la reflection/amplification:

L’attaccante invia piccole richieste verso server pubblicamente raggiungibili (per esempio resolver DNS aperti).
Fa spoofing dell’indirizzo sorgente e imposta l’IP della vittima come “source”.
Quei server rispondono con risposte molto più grandi verso la vittima.

Se una richiesta da 100 byte genera una risposta da 1.000 byte, hai già un fattore 10. A seconda del protocollo e del payload, il fattore può essere molto più alto. La parte spiacevole: dal punto di vista della vittima, il traffico arriva da servizi “normali” che non vuoi bloccare.

Punto importante: l’amplificazione si basa spesso sullo spoofing dell’IP sorgente. Ecco perché il filtraggio in ingresso (BCP 38) è così importante. Se i provider bloccano in modo consistente gli indirizzi sorgente falsificati all’edge, questo vettore diventa molto più difficile.

Classe di attacco 2: esaurimento di protocollo e stato (TCP/Layer 4)

Non tutti i DDoS puntano alla massima banda. Spesso è più efficiente creare stato sul target finché tabelle o risorse si riempiono.

Un esempio classico è un SYN flood contro TCP:

Normalmente TCP stabilisce una connessione tramite three-way handshake (SYN -> SYN/ACK -> ACK).
In un SYN flood l’attaccante invia enormi quantità di pacchetti SYN, ma l’ACK finale non arriva mai.
Il server mantiene molte connessioni mezze aperte (state) e ritenta finché scattano i timeout.

Questo consuma memoria e CPU e può impattare anche la banda in uscita. E anche con tanta banda: quando il session tracking è pieno, il “down” è vicino.

Una categoria correlata sono gli attacchi low and slow: l’attaccante apre connessioni reali e le mantiene aperte con traffico minimo finché il web server o il load balancer raggiungono i limiti di connessione. Questo può essere molto meno visibile di un grande spike di banda.

Classe di attacco 3: Layer 7 e “Layer 8” (HTTP, API, endpoint costosi)

Gli attacchi di Layer 7 sono spesso i più fastidiosi, perché è più difficile distinguerli dal traffico legittimo. Esempi:

HTTP flood: molte richieste verso pagine dinamiche, endpoint di ricerca o flussi di login.
Slowloris/slow header: connessioni mantenute aperte inviando header o body molto lentamente.
Logica di business “costosa”: endpoint che attivano query DB, chiamate a API esterne, generazione di PDF, crittografia o persino workflow di AI/agent.

Il trucco non è necessariamente “più traffico”, ma più lavoro per richiesta. Una piccola quantità di traffico ben scelto può essere più costosa di una grande ondata di GET statici in cache.

Come rilevare un DDoS in produzione?

Se guardi solo CPU e RAM, vedrai alcuni attacchi troppo tardi. In pratica, baseline più alcune metriche robuste aiutano molto:

Traffico: bps e pps all’edge (router, firewall, load balancer).
Metriche di connessione: nuove connessioni/s, sessioni aperte, SYN backlog, handshake TLS/s.
Metriche HTTP: RPS, latenza (p95/p99), ratio 4xx/5xx, timeout.
Sintomi upstream: packet loss, RTT in aumento, link saturi, eventi BGP.
Segnali da log e WAF: path insoliti, header invalidi, molte richieste incomplete, user agent/pattern sospetti.

La parte più importante è semplice: serve una baseline. Senza baseline, tutto sembra “tanto”. Con una baseline, vedi subito che, ad esempio, “pacchetti piccoli” o “richieste incomplete” deviano molto dal normale.

Mitigazione: cosa funziona davvero nella pratica

Ci sono due approcci: make (costruire da soli) o buy (usare un servizio). Per la maggior parte dei team, “buy” è più realistico, perché la mitigazione DDoS diventa rapidamente un problema che non puoi gestire come progetto secondario.

1) Mettere qualcosa davanti all’app: CDN/WAF/provider anti-DDoS

Per siti web e API è spesso la misura più efficace:

Le reti Anycast distribuiscono il traffico su molte location.
Regole WAF filtrano pattern evidenti di Layer 7.
Bot management, rate limit e challenge/response riducono attacchi “economici”.

Importante: non tutti gli attacchi sono HTTP. Se esponi servizi come VPN, VoIP, game server o altri protocolli basati su UDP, ti serviranno altri livelli di protezione in base al setup.

2) Impostare correttamente rate limiting e timeout

Semplice, ma efficace se fatto bene:

ICMP/“ping”: limita, non vietare completamente (serve per troubleshooting).
HTTP: limita per IP/token/route, soprattutto per gli endpoint costosi.
Richieste lente: timeout rigidi per header/body incompleti.

Esempio (Nginx, molto semplificato) di limiti su una route:

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

Non è una bacchetta magica, ma cambia l’economia: gli attacchi “economici” diventano più difficili.

3) Architettura: disaccoppiare il lavoro costoso

Un DDoS di Layer 7 spesso non colpisce la banda. Colpisce le parti dove una singola richiesta è sproporzionatamente costosa. E nei setup aziendali normali ce ne sono tante: login, ricerca, export PDF, report, upload, query complesse, chiamate a API esterne.

Esempio tipico: un portale clienti ha un pulsante di export (“fattura in PDF”, “genera report”, “scarica tutto come ZIP”). In condizioni normali, qualcuno lo usa ogni pochi minuti. Durante un attacco, lo stesso endpoint viene invocato centinaia o migliaia di volte al minuto. La banda non è il problema; lo sono la CPU (rendering), il database (query) e i worker pool (thread/connessioni). Da fuori sembra solo “il sito è lento”. Dentro vedi timeout, code e un database che non regge più.

La buona notizia: non serve rifare tutto. Spesso bastano alcune scelte architetturali per separare la parte costosa dal path della richiesta e aggiungere un freno:

Caching (incluse pagine di errore), TTL sensati, edge caching.
Elaborazione asincrona (queue) per job costosi: invece di “PDF subito”, avviare un job e consegnare dopo.
Validazione rigorosa e abort precoce: limitare complessità, limiti rigidi per richiesta.
Protezione separata per login, ricerca, upload, export: rate limit e timeout dedicati e, se serve, worker pool dedicati.
“Degraded mode” (feature flag): disabilitare temporaneamente funzioni senza stress da deploy.

4) Opzioni upstream: filtering, scrubbing, piani di emergenza

Se diventa davvero grande, devi filtrare il traffico prima che raggiunga la tua connessione:

Filtering lato provider / scrubbing center
Regole temporanee (per esempio: “perché arriva UDP al mio web server?”)
Routing di emergenza (per esempio: spostare il traffico su un IP “protetto”)

Questo funziona solo se ne hai parlato con il provider in anticipo. Iniziare “ad hoc” nel mezzo di un incidente è costoso e lento.

Una checklist pragmatica (per team senza specialisti DDoS)

Inventario: quali servizi sono pubblici? HTTP, DNS, VPN, mail, gaming, VoIP?
Single point of failure: DNS provider, reverse proxy, load balancer, una sola regione?
Osservabilità: bps/pps, RPS, latenze, errori, connessioni, alert con baseline.
Harden defaults: timeout, limiti, dimensione max header, limiti connessioni, backpressure.
Piano con il provider: chi scruba, chi può filtrare, percorsi di escalation.
Runbook: “se succede X, allora Y”, con contatti, soglie e switch (feature flag).
Esercitarsi: load test controllati e incident drill (legali e coordinati).

Infine: testare, ma in modo legale e utile

Testare DDoS è un argomento delicato. Qualsiasi cosa tocchi internet pubblico, sistemi di terzi o infrastrutture senza permesso esplicito è off limits. Cosa puoi e dovresti fare:

Load test nel tuo staging (per esempio per endpoint costosi).
Chaos test sulle dipendenze (cache giù, DB lenta, rate limit più stretti).
Esercitare il processo di risposta: alert, comunicazioni, escalation al provider, misure di emergenza.

Fonti e approfondimenti

Alla prossima, Joe