Brincando com bots de scraping

• Aborda o problema de bots de scraping que fazem solicitações excessivas a sites públicos e acabam agindo como um DDoS, e apresenta uma abordagem experimental para virar o jogo e fazê-los perder tempo
• Foi criado um gerador de texto baseado em cadeias de Markov para gerar dados falsos que parecem arquivos .php, induzindo bots maliciosos a baixá-los
• Depois, foi montado um servidor de conteúdo estático que fornece aleatoriamente parágrafos do romance Frankenstein, com uma estrutura de links projetada para fazer os crawlers se espalharem de forma explosiva
• Todas as páginas receberam os atributos noindex, nofollow e um contador de requisições, excluindo mecanismos de busca legítimos e capturando apenas bots que ignoram as regras
• Os resultados do experimento foram interessantes, mas, por conta do risco de falso positivo com o Googlebot, ele não foi aplicado em serviço real e segue apenas como projeto de estudo e experimentação

---

O problema dos bots de scraping e uma ideia de resposta

• Scrapers acabam causando, sem querer, carga em nível de DDoS em sites pequenos
• Alguns administradores perguntaram sobre formas de proteção, mas este texto foca em “contra-atacar em vez de defender”
• Depois de ver outro desenvolvedor enganando bots com dados falsos infinitos gerados por cadeias de Markov, o autor resolveu fazer seu próprio experimento

Gerador falso de PHP baseado em cadeias de Markov

• Foi implementado em Rust um treinador de cadeias de Markov para gerar conteúdo realista a partir de dados de texto arbitrários
• Mirando bots maliciosos que procuram caminhos vulneráveis como .env, .aws e .php, o sistema entrega código PHP falso que parece real, mas não significa nada
• O tamanho dos arquivos foi ampliado de 2 KB até 10 MB para forçar desperdício de recursos dos bots
• A saída de exemplo assume a forma de código PHP falso convincente, misturando nomes de funções do WordPress e comentários
• O objetivo é desperdiçar tempo e recursos dos bots, além de fazer atacantes perderem tempo procurando vulnerabilidades reais

Eficiência e experimento com entrega de dados estáticos

• Ao servir arquivos acima de 1 MB em uma VPS, surgiram aumento de latência e maior carga no servidor
• Para resolver isso, foi criado um “garbage server” em formato de site estático
  • O romance completo Frankenstein é carregado em memória, e a cada requisição são retornados 4 parágrafos aleatórios
  • No rodapé de cada página são adicionados 5 links para induzir uma expansão explosiva do crawling (crescimento de 5x)
• O resultado pode ser visto em https://herm.app/babbler/

Detalhes de projeto e modo de operação

• O romance escolhido está em domínio público e foi usado tanto por ter sido um trabalho feito na época do Halloween quanto pela semelhança entre IA e Frankenstein
• Todas as páginas recebem a diretiva noindex,nofollow para capturar apenas bots que ignoram as regras
• No rodapé de cada página há um contador de número de requisições, que é reiniciado a cada nova implantação por ser mantido em memória
• Também foi configurado um servidor separado para requisições .php, que fornece aleatoriamente arquivos PHP reais a partir da memória
• O projeto é resumido pela frase: “Garbage for the garbage king!”

Riscos e limitações

• Esse sistema traz risco de falso positivo com mecanismos de busca se for aplicado em um serviço real
  • Se o Googlebot rastrear endpoints errados, o site pode ser classificado como spam
  • Isso pode levar à queda de visibilidade em buscas ou até avisos no Chrome
• Por isso, não é recomendado para sites que dependem de busca, sendo mantido apenas como projeto experimental
• O babbler para .php não é HTML, então não há impacto sobre o Googlebot, atingindo apenas bots maliciosos

Encerramento e conclusão pessoal

• Para atrair scrapers maliciosos, foram adicionados ao blog links ocultos (rel="nofollow")
• Se a franquia de tráfego da VPS estourar, o uso do cache da Cloudflare será considerado
• O projeto serviu para aprender sobre cadeias de Markov e o funcionamento dos bots, em um experimento movido por diversão e frustração ao mesmo tempo
• Em resumo, nem toda tentativa precisa ser prática; às vezes, se for divertido, já basta

[GN⁺]

Opiniões do Hacker News

• O mundo muda, mas no fim acabamos enfrentando problemas parecidos
  Há 10~15 anos eu estava brigando com serviços de monitoramento de redes sociais. Grandes marcas pagavam esses serviços para monitorar o sentimento em fóruns, e eles raspavam sem permissão a comunidade gratuita que eu mantinha, causando carga no servidor
  Mesmo bloqueando os bots, eles voltavam trocando IP e UA, então criei um filtro que inseria nomes de marcas aleatórios nas postagens para arruinar a qualidade dos dados deles. Dois dias depois de ativar isso, o scraping parou completamente

  • Tive uma experiência parecida. Havia bots usando o formulário de doação do meu site para testar cartões de crédito, tentando sem parar enquanto trocavam de IP. Então, em vez de bloquear, passei a devolver mensagens aleatórias de sucesso/erro, e os dados deles ficaram contaminados; em poucos dias desistiram
  • A parte sobre analisar headers foi muito útil. No meu servidor Fediverse, também descobri bots usando UA antiga do Chrome sem enviar nenhum header Accept-Language. Configurei o nginx para retornar 403, e o tráfego começou a cair
  • Como no filme The Imitation Game, se você reagir imediatamente a toda requisição, o outro lado percebe. Se só processar algumas requisições ou devolver códigos de erro aleatórios, fica mais difícil detectar e o debug deles se torna muito mais complicado
  • A maioria dos bots ainda não consegue imitar direito um conjunto de headers HTTP. Em 2025, acabei filtrando do mesmo jeito, e os bots continuam evoluindo no mesmo padrão
  • Fiquei curioso sobre por que inserir nomes de empresas fez os bots sumirem. Queria perguntar se foi porque o sinal dos dados ficou contaminado no processo de procurar menções às marcas

• Esses bots não estão realmente fazendo parse de arquivos PHP; eles criam uma impressão digital (fingerprinting) para detectar vulnerabilidades com base na existência deles. Olham o código de resposta e descartam logo em seguida

  • Exato, nesses casos ferramentas como fail2ban ou crowdsec são mais eficazes. Quando usei crowdsec, percebi que até em servidores com pouco tráfego há um número enorme de tentativas de sondagem de vulnerabilidades
  • Nesse caso, talvez desse para adotar de propósito uma estratégia de expor vulnerabilidades falsas para atrair os bots. Por exemplo, conduzir bots automatizados para um honeypot (honeybot) e observar como funcionam por dentro. Referência: The Cuckoo’s Egg
  • Se scrapers de LLM estiverem usando essas respostas como dados de treinamento, o risco de envenenamento de dados (poisoning) pode aumentar bastante. Um artigo recente dizia que até poucos pontos de dados já podem estragar um modelo

• Recentemente ouvi falar de tarpits para AI e scrapers. A ideia é não encerrar a conexão e ficar enviando dados infinitos bem devagar. A ferramenta Nepenthes parece interessante e queria testar

• Antigamente, no HN, se você bloqueasse scrapers era criticado. A lógica era: “não importa como eu acesso”

  • Mas agora é diferente. Uma pessoa acessando por conta própria e uma empresa de AI enviando em massa requisições em nível de DDoS são coisas completamente distintas. A segunda está claramente empurrando o custo para os outros
  • Eu também acho scraping legítimo aceitável. Basta se identificar no UA e respeitar o robots.txt. Mas, como está agora, mandar dezenas de requisições por segundo fingindo ser uma versão antiga do Chrome é inaceitável
  • Eu raspo sites de vagas uma vez por dia para um projeto acadêmico. Isso é um uso razoável. Já raspar conteúdo a cada poucos minutos ou procurar vulnerabilidades é um problema totalmente diferente
  • O mais deprimente é que a chegada da AI está enfraquecendo o próprio senso ético. Gente que antes valorizava liberdade agora pede endurecimento de copyright ou fim do anonimato. A tecnologia está piorando as pessoas

• Se você administra diretamente um servidor Apache, pode bloquear requisições PHP na hora com RewriteEngine

  RewriteEngine On
  RewriteCond %{REQUEST_URI} (\.php|%2ephp|%2e%70%68%70) [NC,OR]
  RewriteCond %{QUERY_STRING} \.php [NC,OR]
  RewriteCond %{THE_REQUEST} \.php [NC]
  RewriteRule .* - [F,L]
  

  No meu servidor não existe PHP, então esse tipo de requisição é totalmente malicioso

  • No nginx também dá para configurar algo parecido. Para requisições PHP ou ASPX, retorno HTTP 418 “I’m a teapot”

    location ~* \.(?:php|aspx?|jsp|dll|sql|bak)$ { return 418; }
    error_page 418 /418.html;
    

    Isso facilita filtrar os logs. Exemplo: FreeSolitaire.win/wp-login.php

• A maioria dos scrapers agressivos mira em vulnerabilidades do WordPress. Eles querem o resultado de saída mais do que o arquivo PHP em si. Esse tipo de configuração fica mais para um honeypot, mas se o bot não se comportar como o script espera, ele simplesmente vai embora

  • Provavelmente eles procuram na saída, com expressões regulares, um padrão de login de administrador. Se não houver, pulam na hora. Ou seja, uma linha de regex é muito mais eficiente do que gerar um PHP falso de 4 KB

• Uma vez publiquei no HN a estratégia do zipbomb, e o tráfego explodiu para 100 mil acessos por dia. Um VPS de US$ 6 não aguentava. Hoje respondo com zipbomb só aos bots mais agressivos, e para o resto devolvo 403. A nova estratégia funciona bem, mas ainda penso se devo torná-la pública de novo. Referência: post anterior

• Antes eu usava só fail2ban, mas queria montar uma defesa mais divertida
  No .htaccess, redirecionei caminhos suspeitos (/.git, /wp-login) para decoy.php e forcei o download de um decoy.zip de 10 GB.
  O decoy.php parece o arquivo sensível solicitado, mas na prática faz streaming infinito de logs falsos e dados SQL falsos para manter o bot ocupado

• Esses bots não estão raspando arquivos PHP; estão procurando vulnerabilidades de framework. Se você devolver uma resposta inesperada, eles desistem na hora e passam para outro alvo

• Às vezes penso nisso — será que não daria para fazer os bots minerarem criptomoedas com os recursos que desperdiçam?

  • Para tentar isso, seria preciso induzir a execução de JavaScript, mas a maioria dos bots provavelmente já tem contramedidas para bloquear esse tipo de tentativa