Indice dei contenuti dell'articolo:
Il 18 novembre migliaia di siti web protetti da Cloudflare hanno subito interruzioni gravi e diffuse, dando l’impressione che “mezza Internet” fosse fuori uso. In apparenza poteva sembrare un attacco informatico o un problema infrastrutturale globale, ma la realtà è stata molto più sorprendente: una modifica ai permessi di un database ha innescato un effetto domino che ha portato al crash ripetuto di uno dei servizi più critici di Cloudflare. Il database in questione è ClickHouse, un database colonnare ad alte prestazioni utilizzato per analisi in tempo reale, scelto per la sua capacità di eseguire query complesse su grandi volumi di dati in tempi estremamente ridotti. Una tecnologia potentissima, ma che – come tutte le componenti globali e condivise – può trasformarsi in un punto di fragilità se qualcosa cambia in modo imprevedibile.
Che cosa è successo esattamente
Cloudflare Bot Management si basa su un modello di machine learning che analizza ogni richiesta HTTP valutando un insieme di caratteristiche (feature) raccolte dai sistemi interni. Queste feature vengono estratte tramite una query su ClickHouse e vengono poi incluse in un file aggiornato ogni 5 minuti e distribuito in tutta la rete globale Cloudflare. Si tratta quindi di un meccanismo altamente dinamico e distribuito: qualsiasi errore nello step di generazione o distribuzione si propaga in pochi minuti.
La modifica ai permessi del database
Il team Cloudflare stava effettuando un miglioramento interno dei processi di sicurezza: l’abbandono di account condivisi a favore di account utente dedicati e autorizzazioni esplicite. Questo passaggio comportava l’aggiornamento dei permessi sul database ClickHouse utilizzato da Bot Management. L’operazione sembrava del tutto innocua. Nessuno avrebbe immaginato che una variazione negli accessi potesse modificare il comportamento di una query consolidata da anni. E invece è accaduto esattamente questo.
L’effetto collaterale nascosto: dati duplicati
Prima della modifica, la query restituiva circa 60 feature dal database predefinito. Dopo la modifica ai permessi, ClickHouse ha iniziato a leggere i dati non solo dal database “default”, ma anche dal database “r0”. Il risultato è stato un output superiore alle 200 feature. Il modulo Bot Management aveva un limite hard-coded a 200 elementi. Quando la lista superava la soglia, il servizio non gestiva la situazione, non registrava alcun errore, non attivava fallback o degradazioni controllate: si limitava a mandare tutto in crash. Una condizione teoricamente improbabile, mai vista in precedenza, diventava improvvisamente riproducibile ogni cinque minuti, a seconda del nodo che generava il file delle feature.
Perché sembrava un attacco DDoS
Il file di configurazione veniva rigenerato e ridistribuito ogni cinque minuti. Questo significava che alcune istanze della rete Cloudflare ricevevano un file corretto, altre un file corrotto. La conseguenza era un comportamento intermittente e irregolare: servizi che cadevano e si rialzavano, nodi che entravano e uscivano dalla condizione di errore in modo asincrono. Un pattern del genere è tipico anche di un attacco DDoS distribuito, soprattutto quando colpisce più region indipendenti tra loro. A peggiorare ulteriormente la situazione, proprio durante l’incidente è andata offline anche la pagina di stato di Cloudflare, per un problema completamente non correlato. Una coincidenza micidiale, che ha portato gli ingegneri sulla pista sbagliata per oltre due ore.
La diagnosi e la risoluzione
Solo verso le 14:30 il team ha identificato l’origine del problema: il file di configurazione contenente più di 200 feature, generato da query modificate in seguito alla revisione dei permessi di ClickHouse. Una volta individuata la causa, gli ingegneri hanno fermato la propagazione del file difettoso e distribuito una versione nota come corretta. Il recupero completo si è concluso alle 17:06, circa due ore e mezza dopo l’intervento correttivo.
Le lezioni tecniche: ciò che gli ingegneri devono portarsi a casa
1. Unwrap() uccide i sistemi
Il problema più grave non è stato il numero di feature, ma il modo in cui il software reagiva all’anomalia. Il modulo incriminato utilizzava .unwrap() in Rust: una scelta comoda nello sviluppo rapido, ma estremamente pericolosa in sistemi critici. Unwrap() assume che l’operazione vada sempre a buon fine. Se qualcosa va storto, provoca un panic che interrompe l’intero servizio, senza log, senza contromisure, senza diagnosi. Se il sistema avesse registrato un semplice messaggio di errore invece di cadere, il problema sarebbe stato individuato in pochi minuti. Un singolo .unwrap() in una pipeline globale può causare un incidente internazionale.
2. Le modifiche globali al database sono granate a frammentazione
Un cambiamento di permessi è sembrato innocuo. In un sistema complesso e distribuito, però, anche ciò che sembra impossibile può generare effetti collaterali in sottosistemi che non avevano alcun legame diretto con la modifica. Gli ambienti di staging non replicano mai perfettamente un’infrastruttura globale. L’idea che un semplice cambiamento potesse provocare una duplicazione dei risultati di una query non era tra i rischi previsti. Eppure è esattamente ciò che è successo. La lezione è semplice: qualsiasi modifica globale può generare comportamenti emergenti inattesi.
3. Le coincidenze sono più fuorvianti dei bug
Quando due problemi non correlati avvengono nello stesso momento, la mente crea connessioni inesistenti. Il crash di Bot Management e la pagina di stato offline hanno reso credibile l’ipotesi di un attacco esterno. Cloudflare è bombardata quotidianamente da tentativi di attacco: partire da quella ipotesi è naturale. È costato però 2,5 ore di indagini su un problema inesistente. La lezione: i dati battono sempre la narrativa.
4. Le CDN sono veri single point of failure
L’incidente ha evidenziato un fatto difficile da accettare: Internet dipende in modo massiccio da pochi attori globali. Quando un CDN della portata di Cloudflare ha un problema, gran parte del web ne subisce immediatamente le conseguenze. La maggior parte delle aziende non ha un secondo CDN pronto, né un’infrastruttura autonoma per assorbire il traffico. La ridondanza multi-CDN esiste, ma è costosa, complessa e spesso impraticabile. La dipendenza è reale, e l’incidente del 18 novembre lo ha reso di nuovo evidente.
Conclusione
L’interruzione del 18 novembre è stata un caso da manuale che mostra come nei sistemi globali alcuni dettagli apparentemente irrilevanti possano produrre effetti enormi. Un cambiamento ai permessi del database ha modificato il comportamento di una singola query. L’output inatteso ha superato un limite rigido. Un modulo critico si è basato su .unwrap() e ha reagito con un panic totale invece che con un errore gestito. La distribuzione globale del file difettoso ogni cinque minuti ha amplificato l’impatto. Una coincidenza esterna ha portato a un’errata diagnosi prolungata. E così, da un singolo dettaglio tecnico, decine di milioni di siti web sono andati offline. Ed è per questo che, in architetture complesse, non sono gli attacchi a far più paura: sono i piccoli cambiamenti non previsti. O peggio ancora, sono i .unwrap() nascosti nel codice.
