Por que nosso próprio firewall não conseguiu barrar o enxame de bots às 2h da manhã

O telefone tocou no meio da noite, e a gente já sabia o que ia encontrar ao abrir o notebook. O site estaria se arrastando como se estivesse preso na lama. Pessoas que pagavam para usá-lo estariam esperando por páginas que não carregavam. Em algum lugar, um grande grupo de visitantes automatizados estaria batendo na porta sem parar.

As ligações vieram quase todos os dias durante uma temporada daquela primavera. Elas não chegavam como e-mails educados que podíamos ler com um café. Vinham na hora em que o tráfego aparecia. Às vezes estávamos diante do teclado às 2h da manhã, tentando consertar um problema ao vivo, enquanto aquilo que precisávamos consertar já mal conseguia se manter de pé.

Os visitantes eram bots, ou seja, programas de computador visitando um site no lugar de pessoas. Alguns bots são úteis. Os mecanismos de busca usam bots para encontrar páginas. Os que apareceram aqui não eram úteis. Chegavam em enxames, mudavam de comportamento rápido e dificultavam a passagem dos clientes normais.

Já tínhamos proteções. Não tínhamos deixado a porta da frente escancarada para depois fingir surpresa quando uma multidão entrasse. Ao longo dos anos, adicionamos camadas para barrar tráfego ruim, e elas deram conta dos problemas anteriores. Mesmo assim, essa nova onda passou por elas.

Ficando mais rápidos na correria

Por tempo demais, tentamos ficar mais rápidos na correria. Guardamos exemplos de regras que podíamos reaproveitar. Melhoramos em identificar um padrão. Reforçamos as proteções que já existiam no site. Cada vez que o telefone tocava, entrávamos no servidor de produção, o computador que faz o trabalho para os clientes, e escrevíamos mais uma regra lá.

Isso não resolveu. Quando a regra ficava pronta, o enxame muitas vezes já tinha trocado de endereços ou de cartão de visita. Bloqueávamos o que tínhamos acabado de ver e, algumas horas depois, a multidão chegava com outro casaco. Perdemos sono. Os clientes perderam tempo e paciência porque as páginas não carregavam. E cada correção de madrugada se apoiava na mesma ideia ruim: estávamos tentando reforçar uma porta enquanto a multidão já a empurrava para fora das dobradiças.

O tipo de regra que não parávamos de escrever pertence a algo chamado firewall. É simplesmente um porteiro que decide quem passa. O problema era onde nosso porteiro morava. Ele ficava dentro da mesma máquina que a multidão estava sufocando.

Isso significava que cada visitante indesejado ainda chegava perto o bastante para tirar alguma coisa antes que o porteiro pudesse dizer não. Cada um usava uma conexão e um pouco da atenção do computador. Um visitante nunca era o problema. Uma multidão deles era. Nem uma regra perfeita conseguiria devolver as peças que já tinham sido gastas.

Mudando o portão de lugar

A mudança foi tirar o portão de lá.

Colocamos um serviço chamado Cloudflare na frente do site. Pense nele como um posto de controle externo, bem longe da loja em si. Quando o tráfego chega, o posto de controle pode decidir se deixa ele continuar antes que alcance o computador que faz o trabalho para os clientes. Se uma multidão indesejada aparece, a máquina sobrecarregada não precisa mais receber cada pessoa na porta primeiro.

Esse novo lugar mudou a sensação de um incidente. Antes, barrar um enxame significava entrar na máquina ferida. Depois, significava fazer uma mudança a partir de um notebook saudável. A nova instrução chega aos postos de controle externos em menos de um minuto, sem gastar nem um segundo desse minuto pedindo ao site sobrecarregado que trabalhe mais.

Hoje podemos descrever o padrão que estamos vendo para um agente de IA. Ele transforma essa descrição em uma instrução proposta, envia para o posto de controle externo e confirma que o bloqueio entrou em vigor. É uma velocidade útil, principalmente no meio da noite. Mas a decisão importante continua sendo nossa. Precisamos ter certeza de que estamos diante de um padrão nocivo e não de um cliente comum ou de um rastreador de busca verificado (Ler em inglês). Ajuda rápida só ajuda quando a pessoa que a usa sabe o que não deve ser barrado.

Ainda não terminou

Isso não está concluído. Milhares de endereços de clientes mais antigos ainda precisam passar para trás desse posto de controle externo. Até lá, nem todo site tem a mesma proteção. Quando o telefone toca, ainda conferimos uma lista para ver de que lado da mudança aquele site está.

O que mudou foi o lugar onde o portão fica. Barrar um enxame costumava significar entrar no servidor de produção que a multidão estava sufocando para escrever mais uma regra. Agora um bloqueio chega aos postos de controle da Cloudflare em menos de um minuto, a partir de um notebook saudável, e costuma dar poucos minutos de trabalho que podemos esquecer até de manhã.

Nosso firewall rodava na mesma máquina que a multidão estava sufocando, então cada visitante indesejado gastava parte da conexão e da atenção dela antes de poder ser barrado. Se você mantém um site, descubra onde roda a sua primeira linha de defesa e quais dos seus sites já estão atrás de um posto de controle externo e quais não estão.