Sito sotto attacco DDoS? Cosa fare subito

Se il tuo sito è improvvisamente lento o irraggiungibile e il server registra molte più richieste del solito, potresti essere sotto attacco DDoS. La cosa più efficace che puoi fare adesso è mettere un filtro davanti al server, perché un server già sovraccarico non è in grado di difendersi da solo. Questa guida ti accompagna nel riconoscere un attacco, nella prima ora di intervento e nella configurazione che rende il prossimo attacco molto meno doloroso.

Come capire se è un attacco DDoS

Un attacco DDoS (distributed denial of service) inonda il sito di traffico proveniente da molte fonti contemporaneamente, così i visitatori reali non riescono più a passare. Non ogni picco di traffico è un attacco, però. Una newsletter, una citazione in TV o una promozione possono sembrare simili a prima vista. Cerca questi segnali:

• Il picco non ha un motivo di business. Nessuna campagna, nessun articolo di stampa, nessun lancio, eppure le richieste salgono di colpo.
• Le richieste colpiscono sempre gli stessi pochi URL. Spesso la homepage, una pagina di ricerca, una pagina di login o un URL con query string casuali (/?x=83729) pensate per aggirare le cache.
• Provenienze strane. Tante richieste da paesi in cui non hai clienti, da intervalli IP di provider di hosting, oppure con user agent identici o vuoti.
• Nessuna conversione. Il traffico cresce mentre vendite, iscrizioni e tempo sulla pagina restano fermi.
• Il server è al limite. CPU, worker PHP o connessioni al database sono al massimo, e il log degli errori si riempie di timeout ed errori 502/503/504.

Controlla l'access log

Se hai accesso alla shell, un'occhiata veloce all'access log dice molto. Questi comandi mostrano gli IP più attivi e i percorsi più richiesti (adatta il percorso del log al tuo server):

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Pochi IP che inviano migliaia di richieste indicano un attacco piccolo che puoi bloccare direttamente. Migliaia di IP che inviano ciascuno una quantità moderata di richieste indicano una botnet, molto più difficile da fermare a livello di server.

Tipi di attacco che potresti subire

Conoscere a grandi linee il tipo di attacco ti aiuta a scegliere la risposta giusta.

La maggior parte degli attacchi contro siti di piccole e medie imprese sono HTTP flood di livello 7. Non servono enormi quantità di banda, perché ogni richiesta costringe il server a un lavoro costoso: generare una pagina, eseguire una ricerca, interrogare il database. Qualche centinaio di richieste non in cache al secondo può bastare a mettere fuori uso un tipico negozio online o CMS.

Cosa fare nella prima ora

Mantieni la calma e procedi in quest'ordine. Annota cosa fai e quando, perché ti servirà più avanti.

1. Conferma e comunica

Assicurati che non si tratti di un deploy andato male, di un plugin difettoso o di un picco legittimo. Poi avvisa chi deve saperlo: il tuo team, la tua agenzia e il tuo provider di hosting. Spesso l'hosting vede l'attacco nel proprio monitoraggio di rete e potrebbe già filtrare il traffico o, in alcuni casi, mettere in null route il tuo IP per proteggere gli altri clienti.

2. Contatta l'hosting

Chiedi direttamente al tuo hosting: cosa vedono, che protezione hanno e se possono filtrare a livello di rete. Alcuni hosting includono una protezione DDoS di base, altri no. Se il tuo server è in null route, ti serve un livello di filtraggio davanti prima che torni online.

3. Blocca ciò che riesci a identificare

Se l'attacco arriva da un numero ridotto di IP o intervalli, bloccali nel firewall o nella configurazione del web server. Se colpisce un URL costoso, come un endpoint di ricerca, limitane temporaneamente le richieste o disattivalo. Se arriva soprattutto da paesi che non servi, un blocco geografico temporaneo o una verifica possono farti guadagnare tempo. Sono tamponi, non una strategia.

4. Metti un livello di filtraggio davanti al server

La vera soluzione è fermare il traffico dannoso prima che raggiunga la tua origine. Un reverse proxy o un CDN con protezione DDoS assorbe e filtra le richieste sull'edge, e il tuo server vede solo ciò che passa. L'attivazione di solito richiede di cambiare i nameserver del dominio, cosa che ha effetto man mano che scadono le cache DNS. Se lo fai durante un attacco, segui una checklist per non perdere la posta o altri record. La nostra guida su come cambiare i nameserver senza downtime tratta proprio questo.

5. Riduci il lavoro causato da ogni richiesta

Mentre l'attacco è in corso, rendi ogni richiesta più economica. Servi pagine dalla cache ovunque possibile, spegni le funzioni pesanti di cui puoi fare a meno per un giorno (ricerca live, widget dei prodotti correlati, chiamate ad API esterne) e assicurati che la cache non venga aggirata da query string casuali.

Errori da evitare durante un attacco

• Non limitarti a potenziare il server. Più CPU aiuta per poco, ma di solito gli attaccanti riescono a crescere più in fretta del tuo budget di hosting. E comunque non ferma gli attacchi volumetrici sulla banda.
• Non pagare riscatti. Alcuni attacchi arrivano insieme a una richiesta di denaro. Pagare non garantisce nulla e ti segnala come bersaglio disposto a pagare. Denuncia l'estorsione alla polizia.
• Non bloccare in modo troppo ampio. Bloccare interi paesi o tutti i bot può tagliare fuori clienti e crawler dei motori di ricerca. Quando non sei sicuro, preferisci le verifiche ai blocchi totali, e rimuovi le regole temporanee quando l'attacco finisce.
• Non dimenticare le altre superfici d'attacco. A volte un DDoS serve da diversivo. Dopo, controlla login, account amministrativi e modifiche recenti. Lo ricorda anche la panoramica della CISA sugli attacchi denial of service (in inglese).

Dopo l'attacco: rafforza la configurazione

Quando la situazione si calma, sfrutta quello che hai imparato. L'obiettivo è che il prossimo attacco colpisca un filtro, non il tuo server.

Tieni un proxy davanti in modo permanente

Il filtraggio sull'edge funziona meglio quando è già attivo. Aggiungerlo durante un attacco ti fa perdere tempo mentre le modifiche DNS si propagano. Se non sei sicuro di cosa faccia davvero un CDN per te oltre alla velocità, leggi cos'è un CDN e se il tuo sito ne ha bisogno.

Metti in cache tutto ciò che puoi in sicurezza

Ogni pagina servita da una cache è una richiesta che il tuo server non vede mai. Le pagine pubbliche come homepage, categorie, pagine prodotto e articoli del blog dovrebbero stare in cache. Le pagine personali come carrello, checkout e account devono restare dinamiche. Un cache hit ratio alto lascia inoltre al server più margine per i visitatori reali, e anche un'origine veloce aiuta: leggi come ridurre il TTFB.

Blinda l'origine

Consenti il traffico HTTP e HTTPS verso il server solo dagli intervalli IP del tuo proxy. Tieni l'IP dell'origine fuori dai record DNS pubblici, dagli header delle email e dai vecchi sottodomini, perché sono le vie abituali con cui gli attaccanti lo trovano.

Imposta limiti di richieste e avvisi

I limiti di richieste su login, ricerca e API fermano sia i flood sia i tentativi di forza bruta. Gli avvisi sui picchi di traffico e sui tassi di errore fanno sì che tu venga a sapere del prossimo attacco da una notifica, non da un cliente.

Scrivi un breve piano d'intervento

Basta una pagina: chi chiamare presso l'hosting, chi ha accesso al DNS e alla dashboard del proxy, quali regole attivare e come informare i clienti. Nel mezzo di un attacco nessuno vuole mettersi a cercare password.

Come ti aiuta fast.site

fast.site si mette davanti al tuo hosting attuale. Mantieni il tuo provider e punti i nameserver del dominio su fast.site. Da quel momento il traffico raggiunge prima la rete edge e viene filtrato lì, prima che qualcosa venga passato alla tua origine.

Il rilevamento degli attacchi DDoS di livello 7 è attivo automaticamente su tutti i domini, senza alcuna configurazione. In più puoi bloccare IP e intervalli CIDR, bloccare interi paesi o sottoporli a una verifica CAPTCHA, creare regole di verifica personalizzate e impostare limiti di richieste per IP. I set di regole gestiti proteggono da SQL injection, XSS e bot dannosi. Trovi i dettagli nella documentazione sulla sicurezza.

La cache riduce ulteriormente il carico. Le pagine pubbliche servite dall'edge mostrano fs-cache: HIT e non toccano mai il tuo server, mentre carrelli, checkout e sessioni degli utenti loggati mostrano BYPASS e arrivano alla tua origine come sempre. Le statistiche mostrano richieste, tassi di errore e banda dall'origine, e gli avvisi sulle anomalie ti segnalano i picchi di traffico.

Se sei sotto attacco in questo momento, vai alla pagina per siti sotto attacco: è la strada più rapida. Altrimenti puoi configurare la protezione con calma e verificare il risultato sul tuo sito. Per iniziare c'è una prova gratuita di 7 giorni, senza carta di credito. Piani e traffico incluso sono nella pagina dei prezzi.

Domande frequenti

Quanto dura un attacco DDoS?

Varia molto. Alcuni attacchi durano pochi minuti, altri arrivano a ondate per giorni. Le raffiche brevi sono frequenti, spesso come test prima di un attacco più grande o insieme a una richiesta di riscatto. Per questo una protezione sempre attiva è più utile di qualcosa che accendi durante l'attacco.

Un attacco DDoS può danneggiare la SEO?

Un'interruzione breve di solito non ha effetti duraturi. Se il sito resta irraggiungibile o restituisce errori per un periodo più lungo, i motori di ricerca possono scansionarlo meno e togliere temporaneamente alcune pagine. Rimettere online il sito in fretta e restituire codici di stato corretti limita i danni.

Un attacco DDoS è illegale?

Sì, nella maggior parte dei paesi lanciare un attacco DDoS è un reato. Conserva log, orari ed eventuali messaggi di riscatto, e denuncia l'attacco alla polizia o all'unità nazionale per i crimini informatici. È particolarmente importante quando ti viene chiesto del denaro.

Un plugin di sicurezza per WordPress può fermare un attacco DDoS?

Non davvero. Un plugin gira dentro WordPress, quindi ogni richiesta raggiunge comunque il server, avvia PHP e spesso interroga il database prima che il plugin possa bloccarla. È proprio il carico su cui punta un DDoS. I plugin sono utili contro gli attacchi al login e il malware, ma il filtraggio DDoS deve avvenire davanti al server.

Perché il sito è lento anche se il traffico sembra normale?

Allora probabilmente non è un DDoS. Le cause più comuni sono un hosting lento, plugin pesanti, pagine non in cache o immagini grandi. L'articolo di supporto su un sito lento è un buon punto di partenza.