Quando boa parte da internet parou de funcionar durante boa parte da manhã e tarde de 18 de novembro, muita gente pensou em um ataque massivo. A própria Cloudflare, que está por trás de uma parcela enorme do tráfego mundial, também. Horas depois, veio a explicação oficial: não foi DDoS, foi um comando de banco de dados escrito do jeito errado.
O que aconteceu
Por volta das 11h20 UTC, a rede da Cloudflare começou a apresentar falhas intermitentes. Sites protegidos pelo serviço passaram a exibir páginas de erro informando problemas internos na infraestrutura da empresa.
Em um primeiro momento, a telemetria mostrava picos estranhos de tráfego e falhas espalhadas, o que levou as equipes a suspeitarem de um “hyper-scale DDoS attack”. Mas o culpado estava bem mais perto: uma mudança de permissões em um cluster do ClickHouse, o banco de dados usado para alimentar o sistema de Bot Management.
Esse sistema depende de um “feature file”, um arquivo distribuído para todos os servidores da rede que lista características usadas pelo modelo de detecção de bots. Ele é atualizado a cada poucos minutos para reagir rapidamente a novas formas de ataque automatizado.
Ao alterar as permissões no banco, a equipe também mudou o comportamento de uma consulta que gera esse arquivo. A query, que buscava metadados de uma tabela, passou a enxergar não só a base “default”, mas também as tabelas subjacentes de outro schema (“r0”). Com isso, ocorreram linhas duplicadas, mais recursos listados e um feature file que dobrou de tamanho.
O problema é que o software de proxy da Cloudflare (FL/FL2) tinha um limite rígido de quantos recursos poderiam ser carregados. Quando o arquivo estourou esse limite, o módulo de bots entrou em pânico.
Por que o comportamento foi tão confuso
Durante parte da manhã, o estrago parecia “ir e voltar”. Isso aconteceu porque o cluster de ClickHouse estava sendo atualizado gradualmente. Apenas os nós já migrados geravam a versão inflada do arquivo; os demais ainda produziam uma versão “boa”.
Como o feature file é regenerado a cada cinco minutos, o que se via era um sorteio:
- Se a geração caísse em nós antigos, tudo funcionava;
- Se caísse em nós já atualizados, o arquivo vinha grande demais e derrubava o proxy.
Esse vaivém dificultou o diagnóstico. Só mais tarde, quando todos os nós passaram a gerar o arquivo ruim, o sistema “estabilizou em modo falha”, com erros constantes, sem janelas de recuperação. A partir daí ficou claro que não se tratava de um ataque externo, e sim de um problema interno de configuração.
Serviços afetados
Como o módulo de bots faz parte do caminho crítico de requisições HTTP, a pane atingiu praticamente tudo que passa pela CDN da Cloudflare:
- Tráfego web comum: muitos sites exibiram páginas de erro 5xx para usuários no mundo todo;
- Workers KV e serviços que dependem dele: a camada de gateway falhou, devolvendo muitos erros e impactando também o Cloudflare Access;
- Turnstile e painel de controle: o captcha da própria empresa ficou indisponível em períodos do incidente, o que impediu novos logins no dashboard;
- Outros componentes, como filtros de e-mail e reputação, tiveram degradação temporária, mas sem impacto crítico.
Em paralelo, o próprio sistema de logs e debug começou a consumir mais CPU ao tentar enriquecer cada erro com informações adicionais, o que aumentou a latência percebida.
Como a Cloudflare resolveu
O caminho para a recuperação teve alguns passos:
- Bypass temporário
Alguns serviços internos foram configurados para contornar o novo proxy (FL2) e usar a versão anterior, que se comportava de forma menos problemática diante do arquivo inválido; - Travar a propagação do arquivo ruim
Assim que ficou claro que o feature file era o detonador, a equipe interrompeu a geração e a distribuição de novas versões; - Reinserir uma versão conhecida como boa
Um arquivo antigo e validado foi manualmente colocado na fila de distribuição, substituindo o arquivo corrompido em todos os servidores; - Reiniciar proxies e serviços dependentes
Com o arquivo correto no lugar, os proxies foram reiniciados em massa para voltar a ler a configuração certa; depois disso, começou o processo de “limpar a cauda longa” de serviços em estado ruim.
Por volta das 14h30 UTC, o tráfego principal já fluía quase normalmente. O restabelecimento completo, incluindo serviços secundários, foi declarado às 17h06.
Matthew Prince, CEO da Cloudflare, classificou o episódio como o pior desde 2019 e admitiu que “um outage desse porte é inaceitável”. Como correção de curto prazo e prevenção, a empresa prometeu tratar arquivos de configuração internos com o mesmo rigor que entradas de usuário, ampliar o número de “kill switches” globais para desligar códigos problemáticos com rapidez, impedir que core dumps e relatórios de erro esgotem recursos de sistema e revisar os modos de falha de todos os módulos do proxy, evitando panics não tratados.
No fim das contas, a queda revelou algo desconfortável: quando um componente central da infraestrutura da internet se derruba sozinho com uma implementação mal planejada, o impacto é quase tão grande quanto o de um ataque coordenado.
Fique por dentro das principais novidades da semana sobre tecnologia e Linux: receba nossa newsletter!