Como um arquivo de computador derrubou acidentalmente 20% da Internet ontem

Ontem interrupção mostrou como a web moderna depende de alguns provedores de infraestrutura básica.

Na verdade, é tão dependente que um único erro de configuração tornou grande parte da Internet totalmente inacessível por várias horas.

Muitos de nós trabalhamos com criptografia porque entendemos os perigos da centralização nas finanças, mas os acontecimentos de ontem foram um claro lembrete de que a centralização no núcleo da Internet é um problema igualmente urgente de resolver.

Os gigantes óbvios como Amazon, Google e Microsoft administram enormes pedaços de infraestrutura em nuvem.

Mas igualmente críticas são empresas como Cloudflare, Fastly, Akamai, DigitalOcean e CDN (servidores que entregam websites mais rapidamente em todo o mundo) ou fornecedores de DNS (o “livro de endereços” da Internet), como UltraDNS e Dyn.

A maioria das pessoas mal sabe seus nomes, mas as interrupções podem ser tão incapacitantes quanto vimos ontem.

Para começar, aqui está uma lista de empresas das quais você talvez nunca tenha ouvido falar e que são essenciais para manter a Internet funcionando conforme o esperado.

O que aconteceu ontem

O culpado de ontem foi a Cloudflare, empresa que direciona quase 20% de todo o tráfego da web.

Agora diz que a interrupção começou com uma pequena alteração na configuração do banco de dados que acidentalmente fez com que um arquivo de detecção de bot incluísse itens duplicados.

Esse arquivo de repente cresceu além de um limite de tamanho estrito. Quando os servidores da Cloudflare tentaram carregá-lo, eles falharam e muitos sites que usam a Cloudflare começaram a retornar erros HTTP 5xx (códigos de erro que os usuários veem quando um servidor quebra).

Aqui está a cadeia simples:

Um pequeno ajuste no banco de dados desencadeia uma grande reação em cadeia.

O problema começou às 11h05 UTC, quando uma atualização de permissões fez com que o sistema extraísse informações extras e duplicadas durante a construção do arquivo usado para pontuar bots.

Esse arquivo normalmente inclui cerca de sessenta itens. As duplicatas ultrapassaram o limite máximo de 200. Quando as máquinas na rede carregaram o arquivo superdimensionado, o componente do bot falhou ao iniciar e os servidores retornaram erros.

De acordo com a Cloudflare, os caminhos dos servidores atuais e mais antigos foram afetados. Um retornou erros 5xx. O outro atribuiu uma pontuação de bot zero, o que poderia ter sinalizado falsamente o tráfego para clientes que bloqueiam com base na pontuação do bot (bot da Cloudflare versus detecção humana).

O diagnóstico era complicado porque o arquivo inválido era reconstruído a cada cinco minutos a partir de um cluster de banco de dados sendo atualizado peça por peça.

Se o sistema extraiu de uma peça atualizada, o arquivo estava danificado. Se não, foi bom. A rede se recuperaria e falharia novamente à medida que as versões fossem trocadas.

De acordo com a Cloudflare, esse padrão liga-desliga inicialmente parecia um possível DDoS, especialmente porque uma página de status de terceiros também falhou na mesma época. O foco mudou quando as equipes vincularam os erros à configuração de detecção de bots.

Às 13h05 UTC, a Cloudflare aplicou um desvio para Workers KV (verificações de login) e Cloudflare Access (sistema de autenticação), contornando o comportamento de falha para reduzir o impacto.

A principal correção ocorreu quando as equipes pararam de gerar e distribuir novos arquivos de bot, enviaram um arquivo conhecido e reiniciaram os servidores principais.

A Cloudflare diz que o tráfego principal começou a fluir às 14h30 e todos os serviços downstream foram recuperados às 17h06.

A falha destaca algumas compensações de design.

Os sistemas da Cloudflare impõem limites rígidos para manter o desempenho previsível. Isso ajuda a evitar o uso descontrolado de recursos, mas também significa que um arquivo interno malformado pode desencadear uma parada brusca em vez de um retorno normal.

Como a detecção de bot fica no caminho principal para muitos serviços, a falha de um módulo se espalhou para o CDN, recursos de segurança, catraca (alternativa CAPTCHA), Workers KV, acesso e logins do painel. A Cloudflare também notou latência extra à medida que as ferramentas de depuração consumiam CPU ao adicionar contexto aos erros.

No lado do banco de dados, um ajuste restrito nas permissões teve amplos efeitos.

A mudança fez o sistema “ver” mais tabelas do que antes. O trabalho que cria o arquivo de detecção de bot não filtrou com precisão suficiente, então ele pegou nomes de colunas duplicados e expandiu o arquivo além do limite de 200 itens.

O erro de carregamento desencadeou falhas no servidor e respostas 5xx nos caminhos afetados.

O impacto variou de acordo com o produto. O CDN principal e os serviços de segurança geraram erros no servidor.

A Workers KV obteve taxas 5xx elevadas porque as solicitações para seu gateway passaram pelo caminho com falha. O Cloudflare Access teve falhas de autenticação até o desvio das 13h05, e os logins do painel foram interrompidos quando o Turnstile não pôde ser carregado.

O Cloudflare Email Security perdeu temporariamente uma fonte de reputação de IP, reduzindo a precisão da detecção de spam por um período, embora a empresa tenha afirmado que não houve impacto crítico no cliente. Depois que o arquivo bom foi restaurado, um acúmulo de tentativas de login sobrecarregou brevemente as APIs internas antes de normalizar.

O cronograma é direto.

A alteração do banco de dados ocorreu às 11h05 UTC. Os primeiros erros enfrentados pelo cliente apareceram por volta das 11h20 às 11h28.

As equipes abriram um incidente às 11h35, aplicaram o Workers KV e o desvio de acesso às 13h05, pararam de criar e espalhar novos arquivos por volta das 14h24, enviaram um arquivo conhecido e tiveram recuperação global às 14h30 e marcaram a restauração completa às 17h06.

De acordo com a Cloudflare, os testes automatizados sinalizaram anomalias às 11h31, e a investigação manual começou às 11h32, o que explica a mudança da suspeita de ataque para a reversão da configuração em duas horas.

Os números explicam a causa e a contenção.

Um ciclo de reconstrução de cinco minutos reintroduziu repetidamente arquivos defeituosos à medida que diferentes partes do banco de dados eram atualizadas.

Um limite de 200 itens protege o uso da memória, e uma contagem típica próxima a sessenta deixa um espaço confortável até que as entradas duplicadas cheguem.

O limite funcionou conforme planejado, mas a falta de uma “carga segura” tolerante para arquivos internos transformou uma configuração incorreta em um travamento, em vez de uma falha leve com um modelo substituto. De acordo com a Cloudflare, essa é uma área importante a ser reforçada.

A Cloudflare afirma que irá fortalecer a forma como a configuração interna é validada, adicionar mais kill switches globais para pipelines de recursos, impedir que relatórios de erros consumam grande CPU durante incidentes, revisar o tratamento de erros entre módulos e melhorar a forma como a configuração é distribuída.

A empresa chamou isso de pior incidente desde 2019 e pediu desculpas pelo impacto. Segundo a Cloudflare, não houve ataque; a recuperação veio da interrupção do arquivo inválido, da restauração de um arquivo conhecido e da reinicialização dos processos do servidor.