Cloudflare: uma regex esgota a CPU

01 · CONTEXTO

Uma regra nova no WAF, enviada ao mundo todo

No post-mortem oficial, a Cloudflare conta que implantou uma regra nova nas Managed Rules do WAF, o firewall de aplicações web que inspeciona requisições HTTP. A regra continha uma expressão regular que fez o processamento retroceder enormemente e esgotou a CPU usada para servir HTTP e HTTPS. O efeito foi a CPU dos servidores da rede chegar perto do limite em todo lugar, e os clientes (e os clientes deles) viram uma página de erro 502 ao visitar qualquer domínio da empresa.

1. Em operação normal, cada requisição chega a um servidor de borda e passa pelo WAF antes de seguir adiante.

2. Com a regra nova, o WAF passa a consumir CPU demais em cada servidor de borda, e as requisições terminam em erro.

02 · A REGEX

Backtracking: quando casar texto custa tempo demais

O post descreve a causa como uma expressão regular mal escrita, que criou retrocesso excessivo (backtracking). A parte crítica citada é um trecho em que se combina, de forma gulosa, zero ou mais caracteres seguidos de outro zero ou mais caracteres e de um sinal de igual. Gulosa significa casar o máximo possível. Esse é um exemplo clássico de antipadrão de desempenho: o custo de uma operação aparentemente simples depende do formato da entrada.

1. Cada requisição é comparada com as regras, incluindo a expressão regular nova.

2. O motor de regex tenta muitas combinações antes de decidir, e o trabalho recai sobre a CPU do servidor.

3. A CPU fica saturada e não sobra capacidade para atender o tráfego legítimo.

03 · PUBLICAÇÃO

Um caminho de mudança que pulava o rollout em etapas

A regex ruim só virou incidente global por causa de como foi publicada. O procedimento padrão para mudança de regra permitia, segundo o post, que ela fosse enviada globalmente, e deixou uma mudança não emergencial entrar em produção no mundo todo sem rollout em etapas. O WAF não usa o processo em etapas por projeto, devido à necessidade de responder rapidamente a ameaças. Além disso, o conjunto de testes não tinha como identificar consumo excessivo de CPU, e a regra passou por ele sem sinal de problema. Faltou aqui uma prática de padrões de disponibilidade muito comum: limitar o raio de impacto de uma mudança antes de ela alcançar toda a frota.

1. O engenheiro publica a regra e o mecanismo de distribuição a envia a toda a frota de servidores de uma vez.

2. Sem etapa intermediária para observar o efeito, todos os servidores recebem a regra ao mesmo tempo.

04 · RECUPERAÇÃO

Desligar o componente em vez de consertá-lo

Segundo o post, a mudança foi feita às 13:42, e o primeiro alerta do PagerDuty indicando falha no WAF saiu três minutos depois. Nos primeiros momentos houve especulação de um ataque de um tipo nunca visto, o que mostra como um sintoma de CPU saturada pode ser confundido com agressão externa. A saída foi um mecanismo já existente para desativar um único componente no mundo todo: um membro da equipe executou o desligamento global do WAF às 14:07, e às 14:09 tráfego e CPU estavam normais em toda parte. A empresa resume o episódio como 27 minutos fora do ar. Esse tipo de interruptor de emergência é uma forma de monitoramento e observabilidade levada à ação: o alerta aponta o componente suspeito, e o desligamento limita o dano.

1. O alerta aponta falha no WAF e a equipe começa a investigar, considerando inclusive um ataque.

2. A equipe aciona o interruptor global que desativa o WAF em toda a rede.

3. Sem o WAF consumindo CPU, a frota volta ao comportamento esperado.

05 · LIÇÕES

O que levar para o seu projeto

Entre as ações de remediação listadas no post estão reintroduzir a proteção contra uso excessivo de CPU que havia sido removida, incluir perfilamento de desempenho de todas as regras na suíte de testes e mudar o procedimento para que as regras passem por rollout em etapas, como o restante do software da empresa. Pelo ângulo de engenharia do caos, vale perguntar que falhas do seu próprio caminho de publicação você já ensaiou.