Attacco DDoS grave: che cosa fare adesso

Un attacco che finisce dopo dieci minuti è una seccatura. Uno che da giorni torna ogni sera alla stessa ora è tutt'altra cosa: il tuo server non è più un bersaglio casuale. Questo articolo mostra che cosa fare adesso, che cosa puoi mettere in sicurezza da solo senza costi aggiuntivi e dove finiscono queste misure.

Tutti i comandi si riferiscono a Debian 12, Debian 13, Ubuntu 22.04 LTS e Ubuntu 24.04 LTS e sono scritti per root; se lavori come utente normale, anteponi sudo. Che cosa sia tecnicamente un attacco DDoS lo spiega l'articolo Che cos'è un attacco DDoS?.

Finché l'attacco è in corso: niente riavvii e niente rifacimenti di mezza configurazione. Un riavvio cancella proprio i contatori che ti servono per la segnalazione al tuo provider, e subito dopo l'attacco torna identico a prima.

Perché proprio il tuo server viene attaccato con tanta insistenza

I server presi di mira per settimane hanno quasi sempre le stesse tre caratteristiche. Primo, pubblicano da soli il proprio indirizzo: in una lista dei server, su un Discord, con un record DNS. Secondo, il loro utilizzo è legato a orari fissi, quindi un'interruzione alle 20 si vede al massimo grado. Terzo, c'è qualcuno per cui quell'interruzione vale qualcosa: un progetto concorrente, un giocatore bannato, un cliente scontento.

Sul piano tecnico si aggiunge che molti dei servizi colpiti girano su UDP. UDP non prevede nessuna apertura di connessione da pretendere e gli indirizzi mittente si possono falsificare. Per generare carico, quindi, chi attacca non deve né entrare nel tuo servizio né interrogarlo correttamente. Nei servizi TCP, invece, sono le connessioni semiaperte a occupare risorse senza venire mai completate.

Le porte di cui si tratta davvero

Un attacco non colpisce "il server", colpisce una porta. Lo schema seguente elenca le porte standard dei servizi più bersagliati ed è al tempo stesso la tua lista di controllo: tutto ciò che qui non compare ed è comunque aperto va chiuso.

Un secondo gruppo non compare come bersaglio, ma come sorgente: 53 (DNS), 123 (NTP), 389 (CLDAP), 1900 (SSDP), 11211 (memcached) e di nuovo 27015. Se prevalgono queste porte sorgente, si tratta di un attacco di riflessione e amplificazione. I mittenti sono allora server estranei e mal configurati, ed è per questo che bloccare i singoli indirizzi non porta a nulla.

Che cosa puoi fare da solo prima di spendere soldi

Questa sezione è la più lunga, e lo è di proposito: un server configurato bene regge con le sue forze gli attacchi piccoli e medi e, nei casi seri, fornisce i valori misurati per il livello successivo.

1. I primi minuti: misurare invece di mettere mano alla configurazione

Prima di cambiare qualcosa, metti per iscritto che cosa sta succedendo. Bastano quattro valori: la frequenza dei pacchetti in ingresso, la distribuzione degli stati delle connessioni, i messaggi del kernel e la risposta alla domanda se il servizio risponda ancora in locale.

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) pacchetti/s in ingresso su $IF"
ss -Htan | awk '{print $1}' | sort | uniq -c | sort -rn
dmesg -T | tail -50
curl -o /dev/null -s -w '%{time_total}\n' http://127.0.0.1/

Il nome dell'interfaccia arriva dalla rotta di default, perché su molti server KVM eth0 non esiste proprio (lì si chiama ens3 oppure enp1s0) e un nome scritto male riporta imperturbabile zero pacchetti. Un blocco grande in SYN-RECV è lo schema tipico di un SYN flood. Se il servizio risponde in fretta su 127.0.0.1 mentre dall'esterno non è raggiungibile, il problema sta nella rete. E attenzione: sul server misuri soltanto ciò che è passato, dietro a un filtraggio vedi solo una frazione del volume. Il metodo sistematico è descritto in Riconoscere un attacco DDoS.

Se via SSH non passi più, non è un motivo per riavviare, ma la conseguenza di una linea satura. L'accesso passa allora dalla console VNC nell'area clienti, che funziona indipendentemente dal collegamento di rete.

2. Inventario: che cosa è in ascolto verso l'esterno?

ss -lntup
nmap -Pn -p- --min-rate 1000 IP.DEL.TUO.SERVER

Il primo comando mostra il tuo punto di vista, il secondo, lanciato da un'altra macchina, quello di chi attacca. Decisivo è l'indirizzo locale: 0.0.0.0:3306 significa "raggiungibile da tutta internet", 127.0.0.1:3306 significa "solo in locale" e non ha bisogno di nessuna regola firewall. Lungo la strada saltano fuori con regolarità servizi dimenticati: un'istanza di prova, un pannello di amministrazione, un database senza binding locale.

3. Lascia aperto solo ciò di cui il servizio ha davvero bisogno

L'ordine conta, altrimenti ti blocchi fuori da solo: prima le autorizzazioni, poi la policy di default, e solo alla fine l'attivazione.

ufw allow 22/tcp comment 'SSH'
ufw allow 80,443/tcp comment 'Web'
ufw allow 25565/tcp comment 'Porta di gioco'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Verifica poi, con una seconda sessione appena aperta, se riesci ancora a entrare: le connessioni già stabilite sopravvivono all'attivazione anche quando manca la regola corrispondente. La guida completa, con la via di fuga, è in Configurare il firewall UFW senza bloccarsi fuori.

Il database non ha niente a che fare con la rete aperta: in /etc/mysql/mariadb.conf.d/50-server.cnf deve comparire bind-address = 127.0.0.1. Lo stesso vale per le interfacce di amministrazione: se non hai un indirizzo IP fisso da autorizzare in modo mirato, lascia la porta chiusa e raggiungila con un tunnel SSH.

ssh -N -L 8443:127.0.0.1:8443 root@IP.DEL.TUO.SERVER

Le porte dei container pubblicate scavalcano le catene di UFW. Vincolale al locale, quindi -p 127.0.0.1:8080:80 al posto di -p 8080:80, e fai passare l'accesso da un reverse proxy.

4. Mettere in sicurezza la porta di query senza chiuderla

Molti servizi hanno, oltre alla porta vera e propria, una seconda porta che fornisce informazioni di stato: 27015 UDP nei giochi basati su Steam, la porta di query in Minecraft, l'interfaccia ServerQuery sulla 10011 TCP in TeamSpeak. Rispondono senza accesso e la risposta è più grande della richiesta, quindi si prestano all'amplificazione contro terzi. Chiuderle di solito non è un'opzione, perché il tuo server sparirebbe dalla lista dei server. Limitale piuttosto per indirizzo sorgente:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Dieci query al secondo per indirizzo bastano ai giocatori veri e al tuo monitoraggio, ma scartano una sorgente con migliaia di richieste al secondo. In Minecraft enable-query=false nel file server.properties disattiva del tutto la porta di query senza che il server sparisca dalla lista. enable-status=false sopprime in più la risposta al ping della lista, ma allora il tuo server compare come offline. L'interfaccia ServerQuery di TeamSpeak la vincoli a 127.0.0.1.

5. Limitare la frequenza di connessioni e pacchetti

iptables -I INPUT -p tcp --dport 443 --syn -m connlimit --connlimit-above 40 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name game_udp --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

La prima regola scarta le nuove connessioni TCP non appena un indirizzo ne ha più di quaranta aperte contemporaneamente, la seconda scarta i pacchetti UDP oltre i 600 pacchetti al secondo sostenuti dalla stessa sorgente. Entrambi i valori sono punti di partenza, non verità assolute: chi stringe troppo butta fuori i propri utenti. Verifica con iptables -L INPUT -n -v se i contatori dei match salgono. Se restano a zero, la regola non viene proprio raggiunta.

Le regole iptables aggiunte a mano spariscono dopo un riavvio, per conservarle servono apt-get install -y iptables-persistent e netfilter-persistent save. Con UFW vanno in /etc/ufw/before.rules, altrimenti svaniscono al prossimo ufw reload. E poi c'è il limite di fondo: i limiti per indirizzo sorgente funzionano solo finché esistono sorgenti che si distinguono. Se ciascuno dei 200.000 indirizzi coinvolti manda esattamente un pacchetto, nessuno salta all'occhio.

6. Preparare il kernel a molti pacchetti piccoli

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.core.somaxconn=4096
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

I SYN cookie rispondono alla richiesta di connessione senza occupare memoria e sono attivi già di serie. Quando i tentativi di connessione simultanei si moltiplicano, le due code sono le prime a traboccare. Per renderli permanenti, valori di questo tipo vanno in un file sotto /etc/sysctl.d/ e si applicano con sysctl --system. L'ultima riga mostra il connection tracking, che esiste solo con un firewall attivo: se la sua tabella si riempie, il server scarta anche i pacchetti legittimi e segnala nf_conntrack: table full, dropping packet.

7. Livello applicativo: rate limit, whitelist, plugin e anti-cheat

Gli attacchi che non saturano la linea ma sovraccaricano l'applicazione hanno un aspetto diverso: pochi pacchetti, però costosi. Un HTTP flood sulla funzione di ricerca di uno shop non ha bisogno di un gigabit. Sul webserver, quindi, la misura più efficace è un limite per indirizzo, in nginx nel blocco http e poi nel blocco server oppure location:

limit_req_zone $binary_remote_addr zone=web:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=webconn:10m;

limit_req zone=web burst=20 nodelay;
limit_conn webconn 20;

Contro i tentativi di accesso ripetuti Fail2ban è un'aggiunta sensata, la configurazione è descritta in Configurare Fail2ban. Sui game server tre cose funzionano contro tutto ciò che passa dalla normale via di ingresso: una whitelist (in Minecraft whitelist=true insieme a enforce-whitelist=true), un tetto realistico per i giocatori simultanei ed eventi di rete verificati lato server.

Va detto con altrettanta chiarezza che cosa plugin e sistemi anti-cheat non sanno fare: entrambi girano nello stesso processo del gioco e controllano solo nel momento in cui un pacchetto viene già elaborato. Se il processo si blocca, con lui si blocca la logica di protezione. Lo stesso vale per la whitelist, perché chi inonda il tuo server non ha nessuna intenzione di entrarci.

8. Lista dei server, DNS e il proprio indirizzo IP

Qui conviene l'onestà al posto dei buoni propositi: il tuo indirizzo IP non si può tenere segreto. Lo conosce chiunque si sia collegato anche una sola volta, e una voce in una lista lo pubblica comunque. Due abitudini aiutano lo stesso: non pubblicare mai tu l'indirizzo nudo, nemmeno in un canale Discord o tramite un bot di stato, e far collegare gli utenti attraverso un hostname, così un cambio di indirizzo non rompe tutti i riferimenti.

Al momento del cambio, i vecchi record DNS sono il classico intoppo: un record A dimenticato, un sottodominio preso da una pagina di stato, un record MX che punta allo stesso server. E anche allora cambiare indirizzo fa guadagnare tempo, non risolve.

9. Documentare finché l'incidente è in corso

Senza un valore di confronto, dopo non puoi dire se 40.000 pacchetti al secondo fossero tanti oppure semplicemente il solito martedì sera. Con apt-get install -y vnstat sysstat la misurazione gira in permanenza. Durante l'incidente raccogli:

mkdir -p /root/incidente && cd /root/incidente
date -u > 01-ora.txt
ss -s > 02-sockets.txt
ip -s link > 03-interfacce.txt
sar -n DEV 1 10 > 04-frequenza-pacchetti.txt
dmesg -T | tail -100 > 05-kernel.txt
tcpdump -ni "$IF" -s 96 -c 500 -q > 06-campione.txt

Limita tcpdump sempre con -c, perché una cattura senza limiti su una linea satura carica ulteriormente il server. Nel ticket vanno poi l'orario con il fuso orario, l'indirizzo IP interessato con la porta, la frequenza dei pacchetti misurata con l'indicazione della direzione, la distribuzione dei protocolli e le porte sorgente anomale. Con questi dati una segnalazione viene lavorata subito, con "il server era lento" arrivano invece le domande di chiarimento.

Dove queste misure si fermano

Adesso la parte che nessun file di configurazione risolve. Tutte le misure viste finora agiscono all'estremità della linea. Una regola firewall decide su un pacchetto che ha già percorso il cavo: puoi scartarlo, ma non puoi farlo tornare non inviato.

Facciamo due conti. Un collegamento da 1 Gbit/s trasporta 125 megabyte al secondo ed è saturo non appena qualcuno ne manda di più. Con i pacchetti più piccoli possibili corrisponde a circa 1,49 milioni di pacchetti al secondo, a 10 Gbit/s a circa 14,9 milioni. A seconda della CPU e della scheda di rete, il kernel di un server ne elabora qualche centinaio di migliaia prima di iniziare a scartare. Un attacco che non riempie nemmeno un terzo della tua linea, quindi, ti mette comunque fuori gioco, perché il tempo di calcolo se ne va nello scarto dei pacchetti.

Per inquadrare gli ordini di grandezza reali: sui server KernelHost sono stati filtrati in tempo reale, tra gli altri, un attacco da oltre 473,4 Gbit/s con oltre 41,5 milioni di pacchetti al secondo contro un server voice (9987 UDP) e un UDP flood da oltre 112,2 Gbit/s contro un game server (7777 UDP). Il primo caso è circa 473 volte quello che una linea da 1 Gbit/s riesce a trasportare. Gli attacchi volumetrici devono finire nella rete davanti al server, altrimenti finiscono nella tua linea.

Che cosa mette in campo KernelHost

La protezione permanente inclusa in ogni server

La protezione DDoS di KernelHost è costruita su due livelli ed è permanentemente attiva, senza che tu debba ordinare, attivare o configurare niente:

• Livello 1: 17 Tbps di capacità di mitigazione nella rete di scrubbing globale. Gli attacchi volumetrici vengono ripuliti vicino alla loro origine, prima che raggiungano il datacenter.
• Livello 2: filtraggio Arbor in tempo reale da 3,2 Tbps in loco a Francoforte sul Meno. Subito davanti al server gli schemi specifici di protocollo vengono riconosciuti e scartati, pacchetto per pacchetto.

Nei casi seri due caratteristiche fanno la differenza. La protezione è sempre attiva e non deve prima reagire a un attacco, quindi non esistono quei primi minuti in cui il server sparisce. E non viene usato il null-routing: il tuo indirizzo IP resta in rete, vengono scartati soltanto i pacchetti dannosi. Se invece un provider toglie dalla rete l'indirizzo attaccato, per te il risultato è identico a un attacco riuscito. Il datacenter è maincubes a Francoforte sul Meno, in Germania, l'operatore è KernelHost GmbH con sede a Vienna, in Austria. La protezione è inclusa in ogni pacchetto server senza sovrapprezzo, dal server root KVM al server dedicato.

Advanced DDoS Protection per progetti sotto attacco continuo

Certi progetti non vengono colpiti ogni tanto, ma in modo mirato e per settimane. Per questi casi c'è la Advanced DDoS Protection a partire da 50,00 € al mese, PrePaid e senza durata minima. La differenza non sta in una capacità maggiore, ma nel controllo:

• IP di protezione dedicato dal core di Francoforte, sul quale il tuo server viene spostato all'interno della nostra rete. Dalla tua parte non serve alcuna modifica.
• Regole di protezione gestibili da te per porta e protocollo nell'area clienti, senza ticket: la porta di gioco riceve regole diverse dalla porta di query.
• Le modifiche hanno effetto in tempo reale, quindi puoi correggere il tiro anche nel bel mezzo di un attacco in corso.
• Profilo di protezione adatto al singolo gioco, oltre a profili per applicazioni proprie e modificate su porte TCP o UDP a piacere.

I due livelli a confronto

Per la maggior parte dei progetti basta la protezione permanente inclusa, insieme a una configurazione pulita del server. La Advanced DDoS Protection è la risposta al caso in cui qualcuno se la prenda sul personale.

Errori frequenti e soluzioni

"Ho riavviato il server e subito dopo per un po' è tornato a funzionare": era l'attacco che procede a ondate, non il riavvio. I riavvii cancellano i contatori che ti sarebbero serviti per la segnalazione.

"Ho cambiato indirizzo IP e due ore dopo ero di nuovo offline": il nuovo indirizzo è arrivato dalla stessa fonte del vecchio, di solito una voce in una lista dei server, un bot di stato o un vecchio record DNS.

"Blocco gli indirizzi anomali, ma ne arrivano sempre di nuovi": in un attacco distribuito sono decine di migliaia e, negli attacchi di riflessione, stai comunque bloccando soltanto terzi estranei.

"Le mie regole firewall non funzionano": tre cause sono frequenti: le regole stanno dopo le catene di UFW, oppure sono sparite con l'ultimo riavvio, oppure l'attacco è volumetrico e la regola lavora correttamente su una linea che è già satura.

"Il carico era basso, eppure il servizio era irraggiungibile": il tipico attacco basato sulla frequenza dei pacchetti. La banda sembra innocua, il numero di pacchetti no. Misura i pacchetti al secondo, non i megabit.

"In tcpdump non vedo nulla di anomalo": se il traffico viene filtrato nella rete a monte, sul server come previsto non arriva nulla. Se invece la linea è satura, può darsi che non ti raggiunga nemmeno la sessione SSH. In quel caso usa la console VNC nell'area clienti.

In breve

Prima misura, solo dopo metti mano alla configurazione. Chiudi tutto ciò che il servizio non usa, limita porta di query, connessioni e frequenza dei pacchetti per indirizzo sorgente e raccogli i valori misurati finché l'incidente è in corso. Così sei attrezzato contro tutto ciò che non ha bisogno di banda degna di nota. Oltre quella soglia decide soltanto la rete davanti al server.

Se il tuo progetto gira già su KernelHost, il filtraggio è attivo senza che tu debba fare nulla. Se noti comunque delle anomalie, apri un ticket di supporto, così le regole di filtraggio per il tuo indirizzo IP vengono affinate. Durante un attacco in corso ci raggiungi anche tramite la chat WhatsApp di emergenza al numero +43 650 8209883.