Mobilizando pequenas ferramentas para bloquear bots

(lambdacreate.com)

4 pontos por GN⁺ 2025-06-02 | Ainda não há comentários. | Compartilhar no WhatsApp

O Gitea e o blog de um servidor pessoal ficaram sobrecarregados por tráfego de scraping, gerando alertas contínuos de disco, CPU e memória, e o operador partiu para a defesa combinando análise de logs, Nginx e Fail2Ban
Segundo o Zabbix, o tráfego disparou muito acima do normal; a média mensal no Nginx era de 8 requisições por segundo, e no pior período chegou a 20+ requisições por segundo
A causa não foi um pico isolado vindo de Reddit ou Hacker News, mas algo mais próximo de um scraping distribuído, com vários blocos de IP vasculhando URLs de www.lambdacreate.com e krei.lambdacreate.com
No Nginx, user agents maliciosos conhecidos passaram a receber 403, com limite de requisições por IP; clientes que geravam 403 em excesso eram bloqueados por 24 horas via Fail2Ban
No momento da escrita, a lista de bloqueios já havia chegado a 735 bans, e pedidos para gerar tarballs de todos os commits dos repositórios públicos do Gitea aumentavam especialmente a carga no servidor

Tráfego de scraping pressionando um servidor pessoal

Um volume repentino de tráfego indesejado de bots caiu sobre um espaço pessoal na internet, afetando até os serviços que os leitores reais precisavam acessar
Serviços que indexam sites com objetivo de preservação, como o Archive.org, entram na categoria permitida, mas Amazon, Facebook, OpenAI e vários bots aleatórios são tratados como agentes que consomem conteúdo para seus próprios fins
A ampla coleta de dados da internet por grandes empresas e a demanda por dados para treinar modelos de IA parecem ter aumentado ainda mais a pressão de scraping
Esse tráfego não era de consumidores reais do Lambdacreate, mas um elemento de interferência que reduzia a acessibilidade para leitores humanos

Quem primeiro alertou sobre o problema foi o Zabbix, com um aviso de que o disco usado pelos contêineres havia enchido
Em um ambiente baseado em LXD, o autor expandiu um arquivo sparse do ZFS e tirou o site do ar temporariamente antes de recolocá-lo online, mas a causa raiz continuou
Depois disso, a instância do Gitea passou a consumir todo o disco todos os dias, gerando 20 a 30 GB de dados por dia
No início, a suspeita era de um problema no fato de o Gitea não habilitar por padrão a limpeza de arquivos de repositório, então foi configurada uma limpeza agressiva
Logo em seguida vieram também alertas de CPU e memória; no Gitea, git pull e git push ficaram difíceis, e até o cliente weechat não conseguia manter a conexão

Graças a um monitoramento out-of-band para comparar métricas antigas com o estado atual, foi possível confirmar um padrão anormal
No painel do Zabbix, os indicadores principais eram a quantidade de requisições do Nginx e os gráficos de throughput de rede
Na média mensal, o Nginx normalmente ficava em cerca de 8 requisições por segundo
Nos piores momentos, chegaram 20+ requisições por segundo; para um grande serviço isso pode parecer pouco, mas para um servidor pessoal representava algo como 10 vezes o normal e teve impacto significativo
Mais do que o volume simples de requisições, o aumento conjunto no uso de disco e CPU ligado ao Gitea ampliou a carga operacional do servidor

Para manter o servidor vivo por tempo suficiente para verificar os logs, os contêineres e o Nginx foram desligados temporariamente e a análise começou
As ferramentas usadas foram lnav e goaccess
O lnav mostra arquivos de log em uma TUI colorida e oferece uma camada de abstração sobre formatos comuns de log, permitindo consultá-los com SQL
No access.log, a análise se concentrou nas seguintes perguntas
- Quantos IPs visitantes existiam no total
- Se havia algum padrão nos endereços IP
- Se o tráfego vinha de algum referrer específico
- Quais user agents estavam sendo usados
- Quais IPs estavam associados a quais user agents
O resultado mostrou que não era um “hug of death” vindo de um único referrer, mas vários blocos de IP raspando URLs do site inteiro

A primeira resposta foi listar no Nginx os user agents problemáticos e devolver 403 para eles
O exemplo de configuração usa map $http_user_agent $badagent para marcar agents como AdsBot-Google, Amazonbot e Amazonbot/0.1
A configuração padrão do Nginx passou a incluir regras para user agents e também limite de taxa por IP
Na configuração do host virtual, entraram os seguintes comportamentos
- limit_req zone=krei burst=20 nodelay; para aplicar limitação de requisições
- Se $badagent fosse verdadeiro, return 403; para bloquear o acesso ao conteúdo
Esse método ajuda a reduzir o processamento no backend, mas o servidor ainda precisa receber a requisição HTTP e responder com 403, então em grandes volumes simultâneos a carga continua existindo

Depois que os logs de 403 começaram a se acumular, foi possível usar o lnav para verificar os IPs únicos que receberam 403
O goaccess foi usado para analisar juntos logs antigos e atuais e ver quantas requisições entraram no servidor e quais endpoints foram mais visados
Para proteger o servidor de fato, foi adicionado o Fail2Ban
A regra do Fail2Ban era simples: capturar no access log do Nginx os IPs que geravam respostas 403 em excesso
O tempo de bloqueio foi configurado em 86400 segundos, ou seja, 24 horas
No momento da escrita, o resultado de fail2ban-client status nginx-forbidden era o seguinte
- Falhas atuais: 13
- Falhas totais: 57135
- Bloqueios atuais: 38
- Bloqueios totais: 735

No fim, os leitores voltaram a conseguir acessar o blog e outros serviços do Lambdacreate
Quando é preciso bloquear tráfego de robôs, fica difícil até escrever posts no blog
O tráfego problemático não estava mirando o scraping do blog, mas a geração de tarballs de todos os commits em cada repositório público da instância do Gitea
No longo prazo, a ideia é expandir a lista de bloqueio ou criar exceções para serviços legítimos como o Archive.org
A posição do autor é que ele não quer que seu conteúdo desapareça dos mecanismos de busca, mas também não quer deixá-lo servir de combustível para o agravamento da IA na internet