Quando o filtro de bots bloqueou o IP do próprio escritório

Numa manhã, perto do meio-dia, o escritório perdeu o acesso ao próprio painel de administração. Não foi um cliente que fez isso, nem o sistema de outra empresa que saiu do ar fora do nosso alcance. Fomos nós mesmos, e ficamos trancados para fora justamente da ferramenta de que precisávamos para consertar o que nos trancou.

A causa foi uma ferramenta interna rodando totalmente dentro do prédio. Ela fazia verificações de rotina nas páginas dos nossos próprios sites e foi rápida o bastante para passar de mil e quinhentas requisições em um dia a partir de um único endereço. Esse endereço era o do próprio escritório. O filtro automático que vigia scrapers e tentativas de credential stuffing (bots que testam senhas em massa) viu exatamente o padrão para o qual foi feito, volume alto vindo de uma única origem, e bloqueou o endereço.

Mil e quinhentas requisições rápidas por dia vindas de um mesmo endereço são um sinal razoável de que “isso pode ser um bot”. A regra disparou do jeito certo, com a lógica certa, contra o alvo errado. Ela só sabia medir uma coisa: quanto tráfego vinha de onde. Não tinha uma segunda pergunta a fazer, como “esse endereço já é conhecido e de confiança?”, que separasse uma ferramenta interna legítima de um invasor repetindo o mesmo padrão.

Achar a resposta demorou mais do que deveria

Havia uma migração sem relação com o problema acontecendo na mesma época, então primeiro foi preciso descartá-la como possível causa. A resposta estava num banco de dados, não num arquivo de log. Para chegar até ela, consultamos diretamente os registros de bloqueio do próprio filtro e confirmamos que o motivo do disparo e o horário batiam com a atividade da ferramenta interna.

Com isso confirmado, a correção foi adicionar o endereço do escritório a uma allowlist (uma lista de endereços que o filtro nunca pode bloquear) dentro desse mesmo banco de dados. Não diminuímos o ritmo da ferramenta interna. Ela fazia um trabalho legítimo, e limitá-la seria punir o lado errado do problema.

A mesma armadilha continua aberta

O que ficou na nossa cabeça depois foi que a mesma armadilha continuava aberta para a próxima ferramenta interna. Qualquer ferramenta futura que aumente o próprio tráfego contra os sites da empresa, por um bom motivo, vai acionar a mesma regra, porque a regra ainda só conhece volume. Consertar esse bloqueio não ensinou nada ao filtro sobre em que mais ele já deveria confiar.

Se os seus sistemas têm algum bloqueio ou limite automático, descubra qual é o número único que essa regra observa: taxa de requisições, logins que falharam, quantidade de erros, o que for. Depois verifique se alguma coisa que você já usa internamente, uma ferramenta de monitoramento, um script de QA, uma tarefa em lote, poderia chegar a esse mesmo número num dia normal. Se a regra não tem como distinguir a sua própria infraestrutura de um estranho fazendo a mesma coisa, ela está esperando o dia em que as suas próprias ferramentas vão acioná-la.