Mobilizando várias ferramentas pequenas para bloquear bots

• O crawling e scraping indiscriminados de grandes empresas de IA/busca estão afetando gravemente servidores e serviços pessoais, causando continuamente consumo de recursos e instabilidade no serviço
• Após detectar tráfego anômalo com monitoramento baseado em Zabbix e Loki, foram usados ferramentas de análise de logs (lnav, goaccess) e consultas baseadas em SQL para identificar em detalhe padrões de atacantes, IPs e User Agents
• Com a configuração do Nginx, bloqueio 403 por User Agent, rate limiting e integração com Fail2Ban, foi construída uma defesa em várias camadas, bloqueando centenas de IPs maliciosos e estabilizando o servidor
• O principal problema eram bots tentando baixar em massa todo o repositório do Gitea como tarball, e o tráfego com objetivo de "coleta de dados para IA/treinamento de modelos" aumentou rapidamente, não sendo apenas consumo simples de conteúdo
• No longo prazo, o autor está pensando em exceções para serviços legítimos (como archive.org) e em uma estratégia para manter a exposição em mecanismos de busca, mas resistir à enshittification da IA

---

Introdução: o tráfego de bots que caiu sobre meu pequeno servidor

• Recentemente, houve um aumento repentino de grandes volumes de tráfego desconhecido no blog lambdacreate e em vários outros serviços operados pessoalmente
• Serviços legítimos como Archive.org são bem-vindos, mas o crawling de dados sem critério por grandes empresas como Amazon, Facebook e OpenAI está prejudicando o site
• Com a alta da demanda por coleta de dados para treinamento de modelos de IA, esse fenômeno está ficando ainda mais grave
• Nessa situação, em vez de leitores reais (humanos), o serviço passou a sofrer principalmente com grandes volumes de tráfego de bots

Confirmando o problema: diagnóstico da explosão de tráfego com ferramentas de monitoramento

• Ferramentas de monitoramento como Zabbix e Loki foram usadas para analisar o consumo de recursos do servidor
• A instância do Gitea apresentou aumento de dados de 20~30GB por dia, além de vários alertas de CPU/memória
• Pela análise do tráfego do nginx, a média mensal de 8req/s disparou momentaneamente para mais de 20req/s
• O tráfego não era gigantesco, mas aumentou quase 10 vezes em relação ao normal, provocando esgotamento de recursos

Análise da causa do ataque: investigação profunda dos arquivos de log

• Os logs de acesso do nginx foram analisados em SQL com lnav e goaccess
  • Identificação de padrões como IP de visitante, UserAgent, Referrer etc.
• Como resultado, não se tratava de tráfego vindo de um serviço ou comunidade específica, mas de crawling em massa a partir de determinadas faixas de IP
• Foram encontrados muitos valores explícitos ou falsificados no UserAgent, como Amazonbot, OpenAI, Applebot e Facebook
• Como isso passou a prejudicar o uso real do serviço, ficou clara a necessidade de uma política de bloqueio mais forte

Solução: aplicação combinada de várias camadas de defesa com Nginx, Fail2Ban etc.

• Com Nginx map, User Agents maliciosos passam a receber 403 imediatamente, além da adoção de rate limiting (limitação de taxa de acesso)
• Mesmo bots novos ou ainda não detectados tiveram a frequência das requisições reduzida, minimizando a carga no servidor
• Com base nos logs de ocorrências de 403, goaccess e lnav foram usados para detectar novos IPs e User Agents maliciosos
• A ferramenta de segurança automatizada Fail2Ban bloqueia automaticamente por 24 horas os IPs que geram respostas 403 em excesso
  • Mais de 735 registros de banimento automático
• O uso real de recursos voltou de forma significativa à normalidade
• No futuro, a ideia é aplicar regras de exceção para serviços legítimos como archive.org, permitir a indexação por mecanismos de busca, mas continuar bloqueando o crawling indiscriminado para treinamento de IA

Conclusão: o poder da combinação de ferramentas e a necessidade de segurança em serviços pessoais

• Ao aplicar essa série de medidas de defesa em múltiplas camadas, foi possível restaurar a operação fluida do blog pessoal e a acessibilidade dos serviços
• Ficou comprovado que o uso de várias pequenas ferramentas de administração e automação é eficaz para a segurança de servidores pessoais
• Em um ambiente em que até servidores pessoais estão sendo rastreados indiscriminadamente por causa da crescente demanda por treinamento de IA, bloqueio ativo e automação da gestão se tornam essenciais

[GN⁺]

Opiniões do Hacker News

• Vejo com frequência muitos rastreadores sem escrúpulos apenas fingindo ser grandes mecanismos de busca; tem gente que diz que não vale a pena confiar no User-Agent, mas uma das minhas abordagens favoritas é colocar informação suspeita no robots.txt (por exemplo, uma gzip bomb) e configurar para que qualquer crawler que toque nisso seja bloqueado a partir da próxima requisição; dá para implementar isso de forma simples com Caddy, e assim normalmente você pega os infratores mais graves; não vou defender o comportamento desses bots, mas se alguns poucos desses bots derrubam o seu site, isso também é prova de que o site é muito vulnerável a um atacante malicioso

  • Senti que o último comentário acertou em cheio; talvez eu seja de outra geração, mas não entendo por que hoje em dia tanta gente que escreve fica tão obcecada em economizar recursos mínimos; parece meus avós fazendo escândalo por apagar lâmpada de LED ou dirigindo 24 km para economizar 5 centavos de combustível; 20 requisições por segundo realmente não são nada, mesmo que o conteúdo seja gerado dinamicamente (e por que seria? nesse tempo seria muito melhor configurar cache); hoje em dia está na moda texto no estilo “fuck the bots”, mas isso não tem nada de novo; existem maneiras bem mais produtivas de lidar com isso sem perder tempo

  • Queria ouvir mais detalhes sobre como fazer uma gzip bomb via robots.txt; pelo que sei, a maioria das IAs ignora robots.txt, então fico na dúvida se no fim isso não pega só alguns crawlers ingênuos; não estou discordando de ninguém, só queria entender melhor como implementar isso sem prejudicar o lado bom

  • Administro uma das maiores wikis do meu setor, e é quase impossível convencer o resto da equipe de desenvolvimento a usar gzip bomb; insistem que o risco é grande demais (com aquela mentalidade de “por causa da regulamentação da UE”) e que não vale a pena levar isso adiante; queria saber se alguém realmente usa esse método em sites públicos de verdade

• Hoje em dia os bots simplesmente não respeitam mais o arquivo robots.txt, e isso me irrita de verdade; acho extremamente egoísta da parte de quem criou isso; se a pessoa faz um bot assim, então que lide com as consequências

  • Se você colocar armadilhas (honeypots) no arquivo robots, isso ajuda a filtrar bots que vêm deliberadamente para causar problema, mesmo que não pegue os que ignoram tudo por completo

  • Dá para dizer algo parecido também para quem usa chatbots, mecanismos de busca e comparadores de preço; na prática, esses usuários são os principais responsáveis por criar o incentivo econômico para os scrapers

• Entendo o ponto do autor quando diz que “não liga mais”, mas vi que entre os IPs banidos estavam Google, ripe.net e Semrush; quanto aos outros, tudo bem, mas eu realmente não bloquearia o Google; se você quer divulgar o site, também acho que não precisa bloquear Semrush nem ripe.net; mesmo que meu conteúdo seja raspado por IA ou por gente esquisita, se o site já é público desde o início, é preciso aceitar que ele será usado até certo ponto; é como convidar clientes para um motel com a placa apagada

  • A Semrush foi seriamente inconveniente em vários níveis por muito tempo, a ponto de eu deixar até um recado incomum no robots.txt ao longo dos últimos 8 anos; no fim, só consegui que eles recuassem depois de envolver o jurídico; na minha visão, não há valor em permitir que uma empresa de “SEO” raspe o site de forma agressiva enquanto expulsa visitantes reais; concorrentes da Semrush também foram igualmente ruins; os scrapers de IA atuais também são tão ruins que já precisei enviar repetidas reclamações formais até para grandes investidores e departamentos de PR; só consegui normalizar a situação combinando medidas técnicas e legais

  • O problema real é que bots ocupam tráfego em massa (largura de banda, memória, CPU, recursos de disco); o texto introdutório também menciona esse comportamento como algo sem cabimento; não vejo por que fornecer esse tráfego de graça para scrapers; o Google também opera scrapers de IA, então talvez seja isso que apareceu na lista de bloqueio

  • Existem bots realmente maliciosos que se passam pelo Google; antigamente o Google fazia scraping de forma relativamente mais educada, mas se ele já está conseguindo o tráfego de que precisa, independentemente de o autor bloquear ou não, então talvez não haja motivo para se importar

  • Fico me perguntando se as pessoas ainda não perceberam, ao longo dos últimos 10 anos, que não se deve usar Google; especialmente agora que surgem situações em que o Google censura sites independentes com IA, inclusive com um comentário relacionado linkado aqui; neste ponto, o Google já me parece mais um risco do que um ativo

• Os bots fizeram meus arquivos de log do servidor crescerem tanto que acabei desligando o logging por completo; eles raspam APIs, formulários e até áreas do site acessíveis só por clique; Anthropic, openAI e Facebook continuam raspando meus sites até hoje

  • No caso de APIs acessíveis só por clique, fiquei curioso: como os bots conseguem chegar até elas?

  • Queria entender melhor essa questão das APIs: você quer dizer partes da UI ou áreas destinadas apenas a uso humano, ou realmente não existe outro caminho de acesso? Hoje em dia, agentes de IA já imitam padrões de comportamento de usuários reais, então estamos chegando a um ponto em que distinguir humanos de bots se torna quase impossível

• Eu achava bom que os bots crawler de IA ao menos preenchessem honestamente o cabeçalho User-Agent, mas fiquei surpreso ao ver que esse nível de tráfego era causado por isso; a maioria dos sites nem precisa que os dados sejam atualizados com tanta frequência, e ainda assim o volume é enorme; para um blog de desenvolvedor, faz menos sentido ainda

  • A maioria dos crawlers de IA respeita robots.txt, mas houve casos em que, ao serem bloqueados, mudaram imediatamente para um User-Agent de navegador e tentaram rastrear de novo a partir de IPs residenciais; ainda assim, como há muita falsificação se passando por OpenAI/Amazon/Facebook, é preciso bastante cuidado para distinguir os casos reais

• Sou o criador do tirreno; nossa plataforma é otimizada para usuários logados em tempo real, mas também funciona bem para detectar e bloquear bots; usamos um método que anonimiza o IP substituindo o último octeto por asterisco (*), agrupando a mesma sub-rede como uma única conta; dá para fazer com que o sistema gere blacklist automática para anomalias de tráfego (erros 500/404, tentativas de login por força bruta, IPs de datacenter etc.); com a API de blacklist do tirreno, é possível redirecionar tráfego indesejado para páginas de erro; também oferecemos um dashboard de monitoramento para ajudar na gestão e evitar falsos positivos
  tirreno Github, demo do painel admin

  • Hoje em dia muitos ISPs migraram para estruturas com CGNAT, então como vocês lidam com o problema de um único IP representar centenas de usuários reais?

  • Também estou desenvolvendo bloqueio de bots com base em faixas públicas de IP; se alguém tiver ideias de melhoria, são bem-vindas

  • Com esse esquema de substituir o último octeto do IP, eu acabo agrupado como um único usuário junto com vizinhos de endereços que não têm nada a ver comigo; também não dá para ignorar os falsos positivos causados por IPs de datacenter; na prática, se algo não estiver bloqueado, eu tenho que clicar em 87 semáforos para conseguir passar; no fim, isso parece mais uma justificativa para dizer que não estão coletando meus dados pessoais sem consentimento, mesmo durante a etapa de evitar falsos positivos; espero que vocês tenham alguma estrutura de feedback que faça o cliente perceber imediatamente quando está perdendo usuários pagantes de verdade

• Tem uma coisa em que penso há tempos: será que não daria para fazer “page knocking”, isto é, abrir páginas em uma sequência específica para ganhar permissão de entrada? Por exemplo, exigir acesso prévio a uma URL privada definida para que as demais páginas abram normalmente em vez de retornarem 404

  • Esse tipo de arquitetura não combina com casos em que você quer permitir que usuários comuns encontrem o projeto via mecanismo de busca e comecem a usar imediatamente, sem criar conta nem passar por autenticação separada

  • Em termos de usabilidade, por melhor que seja o desenho, isso inevitavelmente causaria incômodo; daria problema tanto com favoritos quanto ao enviar links para amigos, porque a pessoa ficaria recebendo 404 o tempo todo

• Meu servidor pequeno está rodando bem, então fazia tempo que eu não olhava o estado do fail2ban
  Comparação do resultado do comando:

  sshd-ddos:      0
  postfix:       583
  dovecot:     9690
  postfix-sasl: 4227
  nginx-botsearch: 1421
  nginx-http-auth: 0
  postfix-botnet:  5425
  sshd:         202157
  

Fiquei um pouco chocado ao descobrir que mais de 220 mil IPs estavam bloqueados

• Um bot que estamos rastreando, chamado DotBot/1.2, deixou mais de 220 mil requisições nas últimas duas semanas; o padrão é pedir nomes aleatórios de arquivos e pastas do servidor web; por curiosidade, estou deixando sem bloqueio de propósito para ver até onde ele vai

• Acho que a estrutura centralizada de indexação para IA ou mecanismos de busca talvez já devesse migrar para um modelo de push ou submissão; se eu puder compartilhar diretamente só quando quiser, acho que isso reduziria bastante o problema de scraping

• Quando eu era criança, nos anos 90, já recebi uma ligação do ISP avisando que meu computador tinha sido comprometido por uma botnet e que iam cortar meu acesso à internet; talvez devêssemos voltar para aqueles tempos e simplesmente bloquear o ASN inteiro dos ISPs que permitem esse tipo de atividade

  • Proxies residenciais não são fornecidos diretamente pelo ISP, mas surgem quando usuários, no mundo todo, instalam malware de propósito ou sem saber e acabam cedendo seus computadores como proxy; há pouco tempo saiu uma boa matéria sobre isso no HN

  • Configurei regras de firewall para disparar alertas sempre que algum dispositivo da minha rede tenta fazer conexão de saída para portas associadas a malware; a lista de portas precisa ser atualizada periodicamente porque os alvos do malware vivem mudando; é uma medida pequena, mas ainda assim é mais uma camada de defesa