Down Cloudflare: ecco cos’è accaduto il 18 novembre

Il down informatico che il 18 novembre scorso ha impedito a milioni di utenti di raggiungere numerosi siti dal proprio smartphone, tablet o computer, affonda le sue radici in un errore interno a Cloudflare, descritto dal cofondatore Matthew Prince come la più grave interruzione degli ultimi anni. Non si è trattato di un attacco esterno, ma di un’anomalia nata da una modifica alle autorizzazioni di uno dei database utilizzati dal sistema che contrasta il traffico automatizzato, cioè quei software noti come “bot” che possono simulare il comportamento umano online.

Cloudflare, come molti di voi sapranno già, opera come rete globale di server progettata per accelerare i siti, proteggerli e ridurre la probabilità che vadano offline. Una quota enorme del Web (parliamo di circa un quinto dei siti) si affida almeno a una parte della sua infrastruttura a Cloudflare. Proprio per questo un singolo intoppo può avere conseguenze diffuse su una fetta importante del Web.

La modifica errata ha portato il database a produrre righe duplicate in un file di configurazione usato dal sistema di gestione dei bot per distinguere i visitatori reali dal traffico automatizzato. Questo file, improvvisamente cresciuto a dismisura, è stato distribuito in modo automatico a tutti i server della rete. Da qui è derivato l’errore: il software incaricato di instradare il traffico non è progettato per digerire file così pesanti e, superato il limite previsto, ha iniziato a bloccarsi. Il risultato è stata l’interruzione dei servizi che dipendono dal modulo anti-bot.

Credit: Cloudflare.

Poiché la piattaforma aggiorna quel file ogni pochi minuti, le varie istanze di rete hanno cominciato a scambiarsi versioni sane e versioni corrotte, generando una sequenza irregolare di errori 5xx che ha complicato l’analisi iniziale. L’instabilità è diventata totale quando tutte le copie hanno iniziato a propagare soltanto configurazioni danneggiate. Per ripristinare la normalità, Cloudflare ha sospeso la distribuzione dei file difettosi, reinserito una versione precedente e riavviato in modo coordinato i proxy.

Il CTO Dane Knecht ha riconosciuto l’impatto negativo sui clienti e sull’intero ecosistema Internet. L’azienda ha già indicato quattro azioni per limitare futuri rischi: rafforzare i controlli sui file generati internamente, introdurre interruttori globali più granulari per bloccare rapidamente configurazioni problematiche, evitare che errori e core dump saturino le risorse e rivedere in profondità i comportamenti di fallimento dei moduli principali dell’infrastruttura.