Sopravvivere a un attacco DDoS sul tuo VPS

Ci sono due momenti in cui si scopre come funziona davvero la mitigazione DDoS. Il primo è tranquillo, al momento dell'acquisto, leggendo un elenco di funzionalità che dice «protezione DDoS inclusa» e dando per scontato, senza pensarci troppo, che quella frase copra tutto. Il secondo è alle tre di notte, quando il sito è giù, i grafici sembrano sbagliati in un modo che non ha senso, e quella protezione inclusa non sta facendo — correttamente, e per progettazione — assolutamente nulla.

Entrambi i momenti riguardano lo stesso prodotto e la stessa verità: un provider di hosting filtra gli attacchi che arrivano come puro volume, perché possiede la pipe lungo cui viaggiano quei pacchetti e tu no. Non può filtrare gli attacchi che arrivano come richieste dall'aspetto ordinario, perché dal punto di vista della rete sono, appunto, richieste dall'aspetto ordinario. Quella linea di confine — tra il flood che il tuo host assorbe e il flood a cui devi sopravvivere da solo — è l'intero argomento di questa guida. Tutto ciò che segue serve a capire da che parte di quella linea ti trovi, e cosa fare in ciascun caso.

Due attacchi diversi che condividono un nome

«DDoS» è una sola parola che copre due problemi che non hanno quasi nulla in comune, a parte l'esito. Vengono fermati in luoghi diversi, da persone diverse, con strumenti diversi, e confonderli è il motivo per cui tanto sforzo di mitigazione finisce nel livello sbagliato.

Rileggi le ultime due righe, perché contengono il punto pratico. Se l'interfaccia è satura, niente di ciò che digiti nel server aiuterà: i pacchetti hanno già consumato la porta, e l'unico soggetto in grado di scartarli è chi possiede il router a monte. Se l'interfaccia è tranquilla ma il sito è comunque giù, vale l'opposto — il tuo host non vede nulla di sbagliato perché, al suo livello, nulla è sbagliato, e la correzione è interamente tua.

Cosa compra davvero la «protezione DDoS inclusa»

La protezione a livello di rete è reale, preziosa, e quasi sempre fraintesa. Quando un provider pubblicizza il filtraggio L3/L4, intende dire che la sua rete monitora il traffico diretto al tuo indirizzo, e quando viene rilevato un flood il traffico viene deviato attraverso hardware di filtraggio che scarta la parte malevola e inoltra ciò che sembra legittimo. Succede senza un ticket di assistenza e di solito senza che tu noti altro che un breve sussulto.

Quell'unica frase fa un gran lavoro, quindi vale la pena scomporre cosa include e cosa no:

• Copre gli attacchi a cui non potresti sopravvivere da solo. Un flood di amplificazione da 200 Gbps contro un server con una porta da 1 Gbps non è un problema di configurazione. È aritmetica. Il filtraggio a monte è l'unica risposta che esiste.
• È stateless rispetto alla tua applicazione. Il filtro non sa quali dei tuoi URL sono costosi, quali visitatori sono autenticati, o che una richiesta al tuo endpoint di ricerca costa quattrocento volte una richiesta al tuo logo.
• Reagisce a una soglia, non alla tua sofferenza. Il rilevamento scatta sul volume di traffico. Un attacco che non supera mai quella soglia non lo attiva mai, non importa quanto a fondo abbia messo giù il tuo sito.
• Nei casi estremi, può null-routare brevemente il tuo indirizzo. Ogni rete ha un tetto. Se un attacco minaccia l'infrastruttura condivisa, l'indirizzo può restare irraggiungibile per un periodo — è prassi standard e universale, ed è meglio saperlo prima che accada, non mentre accade.

Prima di tutto: capire se è davvero un attacco

Una quota impressionante degli incidenti sospettati di essere DDoS è in realtà qualcos'altro travestito da tale, e i rimedi non sono intercambiabili. Prima di applicare un rate limit a qualsiasi cosa, dedica due minuti a escludere gli impostori — una diagnosi sbagliata qui ti costa un'ora e, a volte, i tuoi utenti veri.

• Sei diventato popolare. Un link su un grande aggregatore produce una forma di traffico che sembra esattamente un flood di livello 7, se non fosse che i referrer sono reali e le richieste riguardano pagine che una persona vorrebbe vedere. È un problema di capacità con una causa felice; applicargli un rate limit è autolesionismo.
• Un crawler ha perso le buone maniere. Scraper aggressivi e bot di addestramento per l'IA possono superare banalmente un piccolo server. Lo user-agent di solito si autodenuncia, e il rimedio è robots.txt più un limite mirato, non uno generale.
• Hai rotto qualcosa tu stesso. Un deployment che ha disabilitato la cache, un cron job impazzito, un database che ha perso un indice — tutti si presentano come «carico improvviso, senza causa evidente». Se la tempistica coincide con una modifica che hai fatto, credi alla modifica.
• Il flood sei tu stesso, con il tuo monitoraggio. Raro, imbarazzante, e molto più comune di quanto chiunque ammetta. Un loop di health-check che ritenta senza backoff può generare un tasso di richieste genuinamente impressionante.

La domanda che fa la differenza è semplice: il traffico vuole qualcosa? Il carico reale — anche quando ha un aspetto ostile — ha una forma. Colpisce pagine che esistono, segue i link, carica gli asset, e proviene da una distribuzione plausibile di reti diverse. Un attacco di solito non si prende questo disturbo.

Leggere l'attacco direttamente dal server

Non serve una dashboard per classificare cosa sta succedendo. Quattro comandi, eseguiti in ordine, ti dicono in meno di un minuto contro quale livello stai combattendo — e saperlo determina tutto ciò che fai dopo.

La pipe è piena? Osserva i contatori dell'interfaccia. Se il throughput è inchiodato vicino al tetto della porta, sei dentro un attacco volumetrico e il tuo compito è aprire un ticket, non modificare una configurazione:

• vnstat -tr 10 — throughput medio negli ultimi dieci secondi, la lettura onesta più rapida sulla saturazione.
• cat /proc/net/dev due volte, a un secondo di distanza — delta di pacchetti e byte per interfaccia, senza bisogno di alcun tool.

È un SYN flood? Le connessioni semi-aperte si accumulano in SYN-RECV. Una manciata è normale; migliaia no:

• ss -s — la riga di riepilogo, il conteggio delle connessioni per stato a colpo d'occhio.
• ss -tn state syn-recv | wc -l — il numero specifico che conta davvero.

È livello 7? Se la banda è nella norma ma tutto è lento, conta le richieste per client nel tuo access log. Un singolo indirizzo con decine di migliaia di richieste è un dilettante; centomila indirizzi con tre richieste ciascuno sono la cosa vera:

• tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30
• Sostituisci $1 con $7 per classificare invece i percorsi richiesti. Se un singolo endpoint costoso domina, hai trovato il bersaglio e metà del rimedio.

Cosa si è davvero esaurito? Il load average da solo ti dice poco. Cerca il tetto specifico che hai raggiunto: i processi di PHP-FPM tutti occupati, le connessioni al database al loro limite, i descrittori di file esauriti, o i worker bloccati nello stato D in attesa del disco. È quel tetto — non il traffico — ad aver messo giù il sito, e alzarlo è spesso più veloce che filtrare qualsiasi cosa.

I primi dieci minuti

Sotto pressione, si tende ad afferrare la leva più grande disponibile, e la leva più grande di solito è quella sbagliata. Questo è l'ordine che limita il danno, all'incirca dal più rapido e sicuro in poi:

1. Classifica prima di agire. Interfaccia satura significa volumetrico; interfaccia tranquilla con worker occupati significa livello 7. Trenta secondi spesi qui ti risparmiano un'ora passata a correggere il livello sbagliato.
2. Se è volumetrico, apri subito un ticket e includi l'indirizzo di destinazione, l'orario di inizio e i tuoi contatori di interfaccia. Poi smetti di digitare nel server — non puoi risolverlo dall'interno.
3. Se è livello 7, occupati prima della cache. Attivare un caching aggressivo a pagina intera per i visitatori anonimi è il modo singolarmente più rapido per trasformare un'interruzione in una scrollata di spalle, ed è anche l'unica misura che aiuta allo stesso modo contro il traffico reale.
4. Poi applica un rate limit — prima l'endpoint preso di mira, tutto il resto dopo. Parti prudente. Un limite che mette fuori gioco i tuoi stessi utenti è una continuazione autoinflitta dell'attacco.
5. Blocca solo ciò che è inequivocabile. Una dozzina di indirizzi con centomila richieste ciascuno, uno user-agent palesemente falso, un paese in cui non hai utenti. Resisti alla tentazione di scrivere regole elaborate mentre sei sotto attacco; il mese prossimo non te le ricorderai.
6. Se necessario, scarica il carico deliberatamente. Servire una pagina statica «in manutenzione» ai visitatori non autenticati mantiene viva la macchina, mantiene attiva la tua API, e ti compra tempo per pensare. Decidere tu cosa sacrificare è meglio che farselo decidere da altri.
7. Annota cosa hai fatto. Ogni regola temporanea che aggiungi è una mina vagante per il te del futuro. Le regole che hanno aiutato diventano permanenti; il resto salta fuori domani.

Rate limit che tengono, e l'errore che fanno tutti

Il rate limiting è lo strumento principale per il livello 7, e nginx lo fa bene con due direttive che risolvono due problemi genuinamente diversi. limit_req limita il tasso di richieste — quanto spesso un client può fare una richiesta. limit_conn limita la concorrenza — quante connessioni un client può tenere aperte contemporaneamente. I flood hanno bisogno del primo; gli attacchi Slowloris, che tengono aperte migliaia di connessioni quasi inattive per esaurire il tuo pool di worker, hanno bisogno del secondo. Distribuiscine solo uno e sei coperto solo per metà del problema.

Tre dettagli separano un limite che funziona da uno puramente decorativo:

• Usa un burst, e usa nodelay. I browser reali sono a scoppi — una singola visualizzazione di pagina scatena una dozzina di richieste di asset quasi simultanee. Un limite senza margine strozza i visitatori genuini, mentre un attaccante che si tiene appena sotto la soglia passa liscio.
• Limita separatamente gli endpoint costosi. La tua pagina di ricerca, il form di login, il reset della password e qualunque endpoint che scrive sul database meritano un budget molto più stretto rispetto ai tuoi asset statici. Gli attaccanti li trovano senza nemmeno provarci, perché sono quelli che fanno male.
• Restituisci 429, non 503. Il codice di stato è un segnale, per i client ben educati e per i motori di ricerca, che si tratta di throttling e non di un guasto — e questo evita che un brutto pomeriggio si trasformi anche in un problema di posizionamento.

Il caching è la mitigazione più economica che distribuirai mai

Un rate limit rifiuta il lavoro. Una cache fa sì che il lavoro non esista. Per tutto ciò che un visitatore anonimo vede, il caching a pagina intera cambia l'economia dell'intero attacco: una richiesta che sarebbe costata un round-trip al database, il rendering di un template e un worker PHP diventa una lettura da file misurata in microsecondi. Lo stesso server che crollava a quattrocento richieste dinamiche al secondo servirà decine di migliaia di richieste dalla cache senza nemmeno accorgersene.

Le cose che contano quando lo attivi con l'acqua alla gola:

• Metti in cache solo per i visitatori anonimi. Bypassa in presenza di un cookie di sessione. Servire la pagina di un utente autenticato a un altro è un incidente molto peggiore dell'interruzione che stavi cercando di risolvere.
• Servi contenuto scaduto di proposito. La direttiva proxy_cache_use_stale di nginx, insieme a updating error timeout, fa sì che quando il tuo backend è in difficoltà i visitatori ricevano una pagina leggermente vecchia invece di un errore. Durante un attacco questa è la differenza tra un sito che sembra a posto e uno che sembra morto.
• Accorpa i miss duplicati. proxy_cache_lock garantisce che mille richieste simultanee per la stessa pagina non in cache producano una sola richiesta al backend, non mille. Senza di esso, un attacco che invalida la cache la attraversa dritto e si abbatte sul tuo database a piena forza.
• Neutralizza le query string che invalidano la cache. Il trucco standard è aggiungere ? e un valore casuale, così ogni richiesta diventa una chiave unica e va sempre in miss. Normalizza la tua chiave di cache per ignorare i parametri di query che la tua applicazione non usa realmente.

C'è qui un'asimmetria piacevole che vale la pena interiorizzare: ogni ora che dedichi al caching rende il sito anche più veloce nel suo giorno migliore, più economico da gestire, e più capace di sopravvivere al successo. Quasi nessun'altra linea di difesa paga un dividendo quando non c'è nulla che non va.

I tetti che decidono se il sito va giù

La maggior parte dei server non muore perché ha esaurito la CPU. Muore perché urta contro un tetto invisibile che nessuno ha impostato deliberatamente — un default di dieci anni fa che aveva senso su hardware che ormai non usa più nessuno. Sotto attacco, sono queste le cose che in realtà si rompono per prime:

• I worker dell'applicazione. Il pm.max_children di PHP-FPM, il numero di worker Python, la dimensione del tuo cluster Node. È questo il vero limite di concorrenza del tuo sito. Quando sono tutti occupati, ogni visitatore in più va in coda, e il sito è giù indipendentemente da quanto la CPU sembri inattiva. Alzalo solo per quanto lo consente la memoria — andare in swap è peggio che mettere in coda.
• La coda di accettazione. net.core.somaxconn e il tuo backlog di ascolto decidono quante connessioni possono aspettare di essere accettate. Un backlog piccolo trasforma un picco sopravvivibile in connessioni rifiutate.
• I SYN cookie. net.ipv4.tcp_syncookies permette al kernel di rispondere a un SYN flood senza allocare stato per connessioni che non si completeranno mai. I kernel moderni lo attivano di default; verificalo invece di darlo per scontato, perché non costa nulla e ti salva dal flood più comune che esista.
• I descrittori di file. Ogni connessione è un descrittore. Il limite predefinito di nofile è spesso più basso del numero di connessioni che stai cercando di servire, e la modalità di guasto — gli accept che falliscono mentre tutto sembra sano — è genuinamente sconcertante alle tre di notte.
• Le connessioni al database. Alzare il numero di worker senza alzare il pool di connessioni sposta semplicemente la coda in un punto più difficile da vedere. Questi due numeri vanno regolati insieme.

Regola questi valori in un giorno tranquillo, non durante un incidente. Il punto di conoscerli è che quando il sito va giù, puoi dare un nome al tetto che ha urtato invece di indovinare — e un tetto con un nome è un tetto che puoi sistemare.

Mettere qualcosa davanti all'origine

Tutto quanto sopra avviene sul server. Il passo successivo è decidere se il server debba essere davvero la cosa che riceve il traffico. Ci sono tre opzioni oneste, e la risposta giusta dipende molto più da cosa ospiti che da quanto puoi permetterti.

Il front node self-hosted merita più attenzione di quanta ne riceva di solito, in particolare per chi ha scelto l'hosting offshore per ragioni verso cui una grande CDN potrebbe non essere comprensiva. Lo schema non ha nulla di affascinante: nodi proxy economici davanti, origine blindata per accettare connessioni solo da quei nodi, DNS che punta ai front. Se un front viene attaccato, lo sostituisci con un nuovo indirizzo in pochi minuti e l'origine non se ne accorge nemmeno. La versione completa di questa architettura — inclusi i sei modi in cui un indirizzo di origine trapela comunque — è l'argomento della nostra guida su come nascondere l'IP del server di origine.

Un'origine nascosta vale più di qualunque filtro

Vale la pena dirlo senza mezzi termini, perché ribalta la solita priorità: la mitigazione DDoS più economica a tua disposizione è un indirizzo che l'attaccante non possiede. Il filtraggio è quello che fai quando questo è già fallito.

La cosa conta più di quanto sembri, perché gli indirizzi di origine trapelano di continuo e in silenzio. I record DNS storici da prima che tu mettessi un proxy davanti sopravvivono al cambiamento per anni. La posta inviata direttamente dall'applicazione porta l'indirizzo nelle sue intestazioni. Un certificato TLS emesso sull'indirizzo grezzo viene pubblicato in modo permanente nei log di certificate transparency. Una pagina di errore, un redirect, o un sottodominio poco noto che non è mai stato messo dietro proxy: tutti quanti lo rivelano. Se hai messo una CDN davanti a un server che prima era esposto, dai per scontato che il vecchio indirizzo sia noto finché non lo cambi.

Scegliere hardware e location perché gli attacchi restino noiosi

Una parte di tutto questo si decide prima ancora che avvenga un attacco, nel momento in cui scegli un piano. Tre proprietà contano molto più di quanto suggerisca la scheda tecnica:

• Banda illimitata. Su un piano a consumo, un attacco non è solo un'interruzione — è anche una fattura. Il traffico che non hai mai richiesto e non hai potuto rifiutare conta comunque contro una soglia. Il trasferimento illimitato converte un rischio finanziario in uno puramente tecnico, che è una classe di problema molto migliore.
• Se la porta è tutta tua. Su un host virtualizzato condiviso, un vicino sotto attacco può degradare anche te, e il tuo stesso tetto di protezione è condiviso. L'hardware dedicato con una porta propria elimina entrambi gli effetti. Per un progetto che si aspetta attenzioni ostili, questa è la ragione più chiara per passare da un VPS a qualcosa di superiore — più dei core o della RAM.
• Dove si trova la rete. Una rete europea ben connessa, con vera capacità di transito, assorbe un flood che una rete con scarso peering non reggerebbe, e la giurisdizione che hai scelto per ragioni legali ha anch'essa delle caratteristiche di rete. Vale la pena controllare entrambe le cose quando scegli tra le location disponibili.

C'è anche un argomento di scala che favorisce silenziosamente la semplicità. Un sito statico dietro una cache su un server modesto è straordinariamente difficile da abbattere; lo stesso contenuto su un CMS pesante con un endpoint di ricerca non in cache può essere spezzato da una sola persona determinata con uno script. Ridurre ciò che è dinamico è una mitigazione, ed è gratuita. Se il tuo progetto vive genuinamente sotto un carico sostenuto, le nostre note sull'hosting per traffico elevato coprono il lato dimensionamento della stessa questione.

Cinque cose da non fare

Le modalità di fallimento qui sono abbastanza ricorrenti da poterle elencare, e ognuna è costata a qualcuno un intero weekend:

• Non null-routare te stesso. Il blackholing del tuo stesso indirizzo pone fine all'attacco nel modo più letterale possibile — nessuno può raggiungerti, utenti compresi. È uno strumento a cui il tuo provider ricorre come ultima risorsa, non un'azione che compi volontariamente.
• Non trattare fail2ban come protezione DDoS. È un ottimo strumento contro tentativi di forza bruta da poche fonti. Contro un flood distribuito reagisce in minuti a qualcosa che arriva in secondi, e una regola che banna migliaia di indirizzi può costare in elaborazione del firewall più di quanto ti sia costato l'attacco stesso.
• Non pagare un riscatto. La stragrande maggioranza delle email di estorsione che minacciano un attacco devastante arriva da persone senza alcuna reale capacità, che inviano migliaia di messaggi identici. La piccola minoranza che è davvero in grado di agire tornerà, perché hai dimostrato di pagare.
• Non reagire con una ritorsione. Oltre a essere illegale praticamente ovunque, le fonti sono terze parti compromesse. Staresti attaccando delle vittime, per giunta da un indirizzo che è inequivocabilmente tuo.
• Non migrare nel panico. Cambiare host a metà attacco significa che il nuovo indirizzo diventa pubblico nel giro di minuti e che non hai una configurazione funzionante. Prima stabilizza, poi trasferisciti con calma — e se decidi di migrare, la nostra guida su come migrare senza downtime esiste proprio perché il trasloco non diventi un secondo incidente.

La versione breve

Spogliato del ragionamento, il modello operativo sta in otto righe:

1. Classifica per prima cosa. Interfaccia satura significa volumetrico, ed è compito del tuo host. Interfaccia tranquilla con worker esauriti significa livello 7, ed è compito tuo.
2. Per il volumetrico, apri un ticket con l'indirizzo, l'orario e i tuoi contatori — poi smetti di toccare il server.
3. Metti in cache in modo aggressivo per i visitatori anonimi, servi contenuto scaduto sotto stress, e accorpa i miss duplicati. È la modifica con la leva più alta che puoi fare.
4. Applica un rate limit sia per tasso di richieste sia per concorrenza, il più stretto possibile sugli endpoint che costano di più, e restituisci 429.
5. Sistema la tua configurazione del real IP prima di ogni altra cosa, altrimenti ogni limite per client dietro un proxy è o inutile o catastrofico.
6. Conosci i tuoi tetti — worker, backlog, descrittori, connessioni al database — e alzali deliberatamente in un giorno tranquillo.
7. Tieni l'indirizzo di origine segreto e blindato verso i tuoi front node. Questo vale più di tutti i filtri messi insieme.
8. Compra banda illimitata, così il traffico che non hai chiesto non diventa mai anche una fattura.

Niente di tutto questo ti rende immune, e chiunque venda l'immunità sta vendendo qualcos'altro. Quello che fa è spostarti fuori dalla popolazione che finisce offline per colpa di un adolescente annoiato, e dentro quella che richiede risorse genuine e intenzioni genuine per essere disturbata — il che, per la stragrande maggioranza dei progetti, è indistinguibile dall'essere al sicuro. Il resto è lo stesso lavoro poco appariscente che rende un server valido in tutto il resto: messo in sicurezza fin dal primo giorno, ripristinabile in quello peggiore, e ospitato in un posto che tratta il tuo traffico come affari tuoi.