Come proteggere il sito dagli attacchi DDoS

Un attacco di tipo distributed denial of service non prova a rubare i dati: prova a impedire ai clienti di entrare. Ci riesce saturando la risorsa che si esaurisce per prima, cioè la banda, la tabella delle connessioni, la CPU o il pool di connessioni verso il database.

Per questo nessun prodotto isolato risolve il problema: ogni famiglia di attacco consuma una risorsa diversa e ogni strato di difesa copre un guasto specifico. Quello che segue è l'ordine reale con cui gli strati fermano un attacco, più la sequenza da seguire quando è già in corso.

Cosa esaurisce davvero un attacco DDoS

Famiglia	Esempi	Cosa satura	Dove va bloccata
Volumetrico	Flood UDP, amplificazione DNS e NTP, scansione di interi range	Il collegamento di rete	A monte, presso il provider o in una rete di scrubbing
Protocollo	SYN flood, ACK flood, flood di connessioni	Tabelle di connessione di server e bilanciatori	Limiti al bordo, tuning del kernel, SYN cookie
Livello applicativo (L7)	Flood HTTP, cache busting, slowloris, abuso di API	CPU, processi e connessioni al database	CDN e WAF, cache e limiti per rotta

La conseguenza è scomoda: se l'attacco supera la capienza del vostro collegamento, nulla di ciò che configurate sul server conta. I pacchetti hanno già vinto prima che una regola locale li veda, quindi la mitigazione volumetrica deve stare a monte. Il resto potete invece irrigidirlo voi.

Perché le piccole imprese sono bersagli redditizi

Il bersaglio naturale è stato a lungo la grande azienda. Oggi il calcolo dell'attaccante è diverso: affittare capacità di attacco costa poco e non richiede competenze di rete. I pannelli di stress test vengono venduti come test di carico, fatturati a ore, così il costo di un tentativo è irrisorio.

Una piccola impresa riunisce esattamente ciò che quel mercato cerca. Nessuno di turno: un attacco lanciato il venerdì sera ha dodici ore di vantaggio. Nessun margine per improvvisare: lo stesso fornitore ospita sito, posta e fatturazione, quindi se cade il collegamento cade l'intera operatività. E urgenza commerciale: un negozio fermo da tre giorni accetta discorsi che un'azienda con data center propri non ascolterebbe nemmeno.

C'è poi un fattore tecnico che quasi nessuno considera: nell'hosting condiviso il vicino attaccato trascina anche voi. Molte scansioni massive non scelgono nessuno in particolare, percorrono interi range di indirizzi e chi capita in elenco quel giorno perde la mattinata. I dati del panorama annuale della cybersicurezza vanno nella stessa direzione: meno barriere all'ingresso, più incidenti di piccola scala.

Strato 1: mitigazione a monte con CDN e anycast

Ogni difesa seria parte da capacità che non possedete. Una rete di pulizia distribuisce il traffico d'attacco su decine di sedi, lo filtra e inoltra al vostro server solo le richieste legittime.

• Mettete il traffico pubblico dietro una CDN o un reverse proxy con mitigazione inclusa (Cloudflare, CloudFront con Shield, Azure Front Door, Gcore, Bunny o Fastly).
• Chiedete al provider quanta capacità di mitigazione c'è davanti al vostro IP e se è sempre attiva o si accende solo al rilevamento. La protezione on demand lascia un buco proprio nel minuto in cui inizia il problema.
• Preferite l'anycast: diluisce i flood volumetrici su base geografica invece di chiedere a un solo data center di assorbirli.

L'errore tipico è credere che la CDN basti. È il primo strato, non l'unico.

Strato 2: chiudere l'IP di origine

È il passaggio che quasi tutti saltano, e annulla in silenzio il precedente. Se l'attaccante scopre l'indirizzo reale del server, aggira la CDN e colpisce direttamente l'origine: la tecnica si chiama direct-to-origin e non richiede strumenti sofisticati.

L'IP di origine trapela per vie prevedibili: la cronologia DNS, con i vecchi record A di prima del passaggio dietro il proxy; i log di trasparenza dei certificati, che conservano i certificati emessi per il nome di origine; i sottodomini come mail., vpn., ftp. o dev., che spesso risolvono sulla stessa macchina; le intestazioni della posta, dove l'IP compare nelle righe Received:; e i record ereditati MX, SPF o TXT che puntano a infrastrutture fuori dalla CDN.

Cosa fare: ruotate l'IP di origine quando la CDN è in produzione, limitate il firewall ai range pubblicati dalla CDN sulle porte 80 e 443 e ricontrollate la vostra esposizione ogni trimestre. Dieci minuti di verifica valgono più di qualsiasi regola nuova.

Strato 3: WAF e limiti di richiesta

Un firewall di rete vede una connessione TCP valida e la lascia passare. Un WAF legge la richiesta HTTP, dove vive l'attacco applicativo: richieste malformate, tentativi di exploit e ondate di bot contro il modulo di accesso o il motore di ricerca interno.

Attivate prima i set di regole gestiti — OWASP più le informazioni del fornitore — e aggiungete poi regole vostre: bloccare i corpi sovradimensionati sulle rotte di caricamento, chiedere una verifica sulle aree amministrative e limitare per singolo endpoint invece che per sito intero.

Il limite di richieste è il controllo più conveniente che avete e quello configurato peggio. Un tetto applicato solo sul server web non serve contro traffico che prima satura la rete, e un tetto basato solo sull'IP fa poco contro una botnet con migliaia di indirizzi. Distribuite i limiti: al bordo, per IP, per ASN e, quando ha senso, per paese; nell'applicazione, per sessione, per chiave API e per utente autenticato; per rotta, con tetti stretti su accesso, recupero password, ricerca e pagamento. Usate token bucket o finestre scorrevoli invece di tetti fissi al secondo e restituite 429 con Retry-After, così il client legittimo si ritira invece di insistere.

Strato 4: cache, capacità contrattuale e contatti presso il fornitore

Una richiesta servita dalla cache non arriva mai all'origine, quindi non consuma né processi né connessioni al database. Tutto ciò che può essere statico dovrebbe esserlo: immagini, CSS, JavaScript e HTML per i visitatori anonimi.

Due dettagli contano durante l'attacco. Il cache busting è una tecnica offensiva: stringhe di query casuali costringono ogni richiesta a tornare all'origine, quindi impostate la CDN per ignorare i parametri irrilevanti sulle rotte memorizzabili. E il tasso di successo della cache è una metrica di sicurezza: se scende dall'85% al 20% in piena emergenza, state pagando costo di origine per traffico d'attacco.

La capacità, invece, si compra con un contratto e non con l'ottimismo. Se ogni ora di fermo vi costa denaro, chiedete uno SLA di scrubbing, una soglia dichiarata, contatti di escalation con nome e cognome e un livello di supporto che risponda durante l'attacco; tenete il numero di account dove chi è di turno lo trova senza cercarlo. E se l'attacco gioca sullo stato, tornate alle regolazioni noiose: SYN cookie attivi, tcp_max_syn_backlog e somaxconn calibrati sulla concorrenza reale, tetto di connessioni per sorgente al bordo.

Come si riconosce un attacco nei log

Non si difende ciò che non si vede. Prima dell'incidente annotate com'è la normalità: richieste al secondo, byte in entrata e in uscita, quota di 4xx e 5xx, latenza p95, connessioni aperte e URL più richieste. Poi mettete in allarme lo scostamento, non il valore assoluto: un picco a cinque volte il traffico abituale con errori stabili somiglia a una campagna marketing che funziona, mentre un volume piatto con latenza e connessioni in salita sa di esaurimento di stato.

I segnali che tornano quasi sempre:

• Una sola URL che concentra una quota anomala di traffico: ricerca, accesso o un endpoint di API.
• Migliaia di indirizzi diversi con la stessa firma di user agent, o con nessuna.
• Latenza in crescita mentre gli utenti unici non si muovono.
• Traffico in ingresso molto superiore a quello che il server dichiara di aver servito.
• Errori 499, 502 e 504 sul bilanciatore e timeout sul database.

Sono gli stessi schemi descritti tra le tattiche e tecniche degli attaccanti in qualsiasi rapporto di incidente.

Sequenza di incidente: rilevare, contenere, comunicare, rivedere

Rilevare. Confermate che sia un attacco e non una campagna che funziona. Guardate la composizione del traffico prima di bloccare qualsiasi cosa.

Contenere. Aprite subito un ticket con il provider o con il supporto della CDN: la mitigazione a monte richiede tempo per attivarsi. Poi accendete la modalità under attack, le regole gestite, limiti più stretti e una verifica JavaScript sulle rotte più colpite, e controllate che l'origine accetti solo il traffico della CDN.

Comunicare. Prima la pagina di stato, poi i canali di assistenza. Il silenzio fa più danni dell'attacco: un cliente informato aspetta, uno lasciato senza notizie se ne va.

Rivedere. A freddo ricostruite la cronologia, individuate quale strato ha ceduto per primo e quanto è costata davvero l'ora di fermo. Aggiornate il runbook e conservate log, catture dei pacchetti e marche temporali: servono al fornitore, all'assicurazione e a qualsiasi contestazione successiva.

Checklist prima dell'attacco

Controllo	Stato atteso	Come verificarlo
Mitigazione a monte	CDN o scrubbing davanti a tutto il traffico pubblico	Risoluzione DNS da fuori la rete aziendale
IP di origine	Ruotato e con firewall limitato ai range della CDN	Scansione esterna e cronologia DNS
WAF	Regole gestite più regole proprie su accesso e amministrazione	Test controllato su una rotta protetta
Limiti	Bordo, applicazione e rotte costose	Prova di carico con soglia nota
Visibilità	Avvisi su RPS, errori, latenza e connessioni	Simulazione di allarme
Runbook	Una pagina, aggiornata, con responsabili nominativi	Lettura ad alta voce di chi non l'ha scritta

Ogni casella vuota è una crepa concreta. Se preferite non improvvisare la prossima, parliamo della vostra situazione e verifichiamo l'esposizione prima del prossimo picco.

Denuncia e obblighi di legge in Italia

Un attacco DDoS non è uno scherzo: è un reato. L'articolo 635-bis del Codice penale punisce chi danneggia informazioni, dati o programmi informatici altrui, e l'articolo 635-ter prevede pene più severe quando il danneggiamento riguarda dati o programmi usati dallo Stato, da enti pubblici o comunque di pubblica utilità. La via penale esiste, ma chiede documentazione più che indignazione.

L'ordine corretto è sempre lo stesso: prima si conservano le prove — log con marche temporali, catture dei pacchetti, copia del messaggio di estorsione se c'è — poi si notifica. Se il servizio tratta dati personali, il GDPR impone di valutare la notifica al Garante per la protezione dei dati personali entro 72 ore dalla conoscenza della violazione. In parallelo, il CSIRT Italia, costituito in seno all'Agenzia per la cybersicurezza nazionale, gestisce e coordina gli incidenti segnalati da aziende e cittadini, mentre la querela si presenta alla Polizia postale o ai Carabinieri, meglio se accompagnata dai log.

Nessuna di queste attività ferma l'attacco da sola. Però trasforma l'incidente in un fascicolo: serve all'assicurazione, al rapporto con il fornitore e a spiegare a un cliente che cosa è successo e quando.

Domande frequenti

Un attacco DDoS si può evitare del tutto?

No. Chiunque può inviare traffico verso un servizio pubblico e questa asimmetria non si chiude. L'obiettivo realistico è assorbirlo e filtrarlo senza far cadere gli utenti legittimi.

Basta una CDN per fermare un attacco DDoS?

Assorbe i flood volumetrici e buona parte dell'abuso applicativo, ma non corregge l'esposizione dell'origine né l'esaurimento di stato. È uno strato, non la soluzione.

Come distinguo un attacco da un picco legittimo?

Guardate la composizione, non il volume. Un picco concentrato su un'area geografica o su una sola URL, con user agent strani, latenza in salita e conversione piatta, è un attacco; un picco distribuito sulle fonti abituali è spesso una campagna che funziona.

Da cosa deve partire una piccola impresa?

Dal mettere il traffico dietro una CDN con mitigazione, chiudere l'IP di origine, attivare le regole gestite del WAF e scrivere un runbook di una pagina.

Serve un provider di mitigazione dedicato?

Solo se l'ora di fermo costa più del contratto. Partite dal livello CDN, misurate l'esposizione reale e salite quando i numeri lo giustificano.

Letture correlate

• Ransomware as a service: perché le PMI sono nel mirino
• Valutazione delle vulnerabilità e penetration test
• Dieci segnali che l'azienda è compromessa
• Red team, blue team e purple team

Se volete che qualcuno riveda la configurazione di bordo, i limiti e il runbook prima del prossimo incidente, parliamo della vostra situazione.