- O autor mantém o Spigot, um gerador falso de hierarquia de páginas web, e expõe páginas geradas aleatoriamente contra rastreadores web agressivos
- Recentemente, percebeu que rastreadores de imagem estavam explorando o site intensivamente em busca de imagens jpg
- Para gerar imagens em tempo real com o mínimo de CPU, propõe usar como template apenas as partes estruturadas de arquivos JPEG reais e inserir dados aleatórios na parte comprimida
- Os testes mostraram que JPEGs criados dessa forma, apesar de terem erros, ainda podem ser exibidos pela maioria dos visualizadores de imagem e parecem suficientemente plausíveis para os rastreadores
- Esse método consome poucos recursos do servidor, sobrecarrega os rastreadores e foi aplicado a cerca de 60% das páginas do Spigot
Contexto do Spigot e da falsificação de JPEG
- O Spigot gera em tempo real uma hierarquia falsa de páginas web com base em Markov Chain, fornecendo dados sem sentido para rastreadores web agressivos
- Alguns rastreadores usam assinaturas de navegador aleatórias e IPs para esconder a identidade, revelando possível abuso ilegal de dispositivos via botnet
- Pela análise de tráfego, foi confirmado que um novo rastreador chamado "ImageSiftBot" solicitava intensivamente páginas do Spigot para coletar imagens
- O principal objetivo do Spigot é minimizar o uso de CPU do servidor e manter uma operação eficiente
Buscando uma forma barata de gerar imagens
- Gerar imagens dinamicamente consome muita CPU por causa da compressão, então era necessário um método eficiente
- A ideia surgiu da observação de que um arquivo JPEG é composto pela estrutura do arquivo (tamanho, cores etc.) e por uma área de dados de pixels comprimidos
- Foi criado um método que extrai apenas as informações estruturadas de cabeçalho de vários JPEGs e preenche a área de dados de pixels com dados aleatórios
- Assim, torna-se possível gerar imagens na hora sem precisar comprimi-las a cada vez, minimizando a carga no servidor
Estrutura do arquivo JPEG e implementação real
- Um arquivo JPEG é formado por vários chunks (com marcadores e comprimento)
- Os cabeçalhos/metadados são mantidos, registra-se apenas o comprimento dos dados de pixels comprimidos → e somente nessa área são inseridos dados aleatórios
- Ao usar 514 amostras de JPEG, o tamanho total das informações de cabeçalho e dos dados estruturados necessários ficou em apenas cerca de 500 KB, com impacto de memória insignificante
- Exemplo de código: as imagens são geradas preenchendo com números aleatórios o chunk de dados de pixels de cada template
Resultados em uso real e publicação como open source
- Visualizadores de imagem reais conseguem exibir a imagem até certo ponto mesmo quando a área de pixels é completamente aleatória
- Para os rastreadores web, é difícil identificar os erros, o que aumenta o custo da coleta de dados
- Com JPEGs de 1280x960 e tamanho entre 200 e 300 KB, foram geradas cerca de 900 imagens por segundo, sem dificuldade para processamento em tempo real
- O método foi aplicado a 60% de todas as páginas do Spigot, usando uma seed aleatória baseada na URL para retornar a mesma imagem em novas requisições
- Foi observado alto volume de requisições de ImageSiftBot, Meta, AmazonBot, GPTBot e outros
- O objetivo central é onerar os rastreadores com poucos recursos do servidor
Código Huffman e otimizações adicionais
- Os dados de pixels do JPEG usam codificação Huffman, então inserir números totalmente aleatórios pode causar erros em alguns visualizadores
- Foi adicionada uma técnica simples de mascaramento de bits (
0x6D) para evitar a ocorrência de três ou mais 1s consecutivos, reduzindo a probabilidade de códigos Huffman inválidos de 90% para menos de 4%
- Também seria possível criar um fluxo Huffman totalmente válido, mas o ganho seria pequeno em relação ao custo de recursos do servidor e ao tempo de desenvolvimento
Conclusão
- O método de geração de JPEG falso do Spigot economiza recursos do servidor com eficiência extrema e, ao mesmo tempo, induz confusão e desperdício de recursos nos rastreadores
- O código relacionado tem menos de 100 linhas e foi publicado no GitHub
- Trata-se de uma técnica simples, mas criativa, de defesa e dispersão de tráfego web
1 comentários
Comentários do Hacker News
Era esperado que o arquivo robots.txt bloqueasse o acesso de robôs à árvore /spigot/, mas descobriram que, mesmo removendo apenas /spigot/ da URL, ainda é possível acessar o Spigot; como o namespace /~auj não está bloqueado pelo robots.txt, até um crawler bem-intencionado pode acabar entrando nesse caminho por acaso e cair em um loop infinito de páginas, o que não é nada agradável link de referência do robots.txt
Em um comentário anterior, o autor havia dito que não configurou um robots.txt separado; sobre ter adotado uma medida tão extrema, afirmou que não gosta da ideia de que o operador de um site precise configurar algo de propósito para impedir DOS causado por crawlers, e que um crawler legítimo não deveria ficar raspando um site de forma contínua a mais de 15 vezes por segundo
Quanto ao fato de que até crawlers bem-intencionados podem cair em um loop infinito de páginas, há ceticismo sobre qual seria exatamente a obrigação de um operador de site de ser "gentil" com quem está raspando seu site; não está claro se isso realmente precisa ser assim
Se for possível identificar quando um crawler está ignorando o robots.txt, parece mais eficiente simplesmente ocupar a conexão de rede e deixá-lo pendurado, em vez de devolver informações "lixo"; não fica muito claro por que seria necessário fornecer lixo infinitamente em um endpoint
Surgiu a ideia de atrapalhar scrapers voltados para entrada de IA colocando legendas falsas em cada imagem; por exemplo, em uma imagem com um borrão verde escrever "um gato brincando com uma bola de catnip" e em uma imagem azul escrever "um tordo construindo um ninho"
O caso mais grave é o bot facebookexternalhit, operado pela Meta (Facebook); está até documentado oficialmente que esse bot ignora o robots.txt; o Facebook diz que isso serve para detectar links maliciosos, mas na prática, se um usuário malicioso continuar enviando ao Facebook apenas URLs de endpoints caros, o efeito é que o Facebook passa a bombardear o site com tráfego, então por vários dias por mês o site recebe mais de 10 r/s em um único dia
Ao ler o texto sobre o Spigot, veio à mente o Project Honeypot; há 20 anos, sempre era empolgante receber e-mails dizendo que o script do projeto e os registros MX doados ajudaram a capturar coletores de e-mail no meu site; por exemplo, avisos dizendo que, graças ao meu MX, foi pego um remetente de spam ainda não confirmado (IP: 172.180.164.102)
Forjar um JPEG exige muito menos CPU do que gerar um JPEG corretamente; além disso, o próprio processo também pode servir como uma espécie de fuzzing, causando crash no lado do malware do outro lado caso a decodificação de JPEG deles seja falha
O fato de o tráfego recente estar vindo de milhares de IPs residenciais não significa necessariamente um botnet típico; pode ser antes uma estrutura de "proxyware", em que muitas pessoas aderem a ferramentas de "VPN grátis" ou de "geração de renda passiva", e seus dispositivos viram nós de saída para o tráfego de outros usuários; nesse caso, a pessoa pode estar servindo de canal para tráfego de crawlers de IA sem saber material de referência relacionado
No fim das contas, esse tipo de proxyware também é uma variação de botnet na qual o usuário entrou voluntariamente; como é improvável que esses usuários descubram em lugares como o HN que seu IP é o problema, parece razoável pensar em redirecionar esses IPs para uma página de aviso dizendo "você faz parte de uma botnet"; na prática, porém, simplesmente bloquear tudo é o mais conveniente
Há a opinião de que isso também se enquadra plenamente na categoria de botnet
Gostei da forma como se fala sobre satisfazer os bots; foi um texto divertido, e o projeto parece interessante
A atitude de "fiquei com pena dos bots se esforçando na missão que receberam, então pensei em como entretê-los" pareceu bem original e divertida; é bem diferente das threads cheias de raiva e reclamação que costumam aparecer
Gostei do resultado (a imagem) neste link ver imagem, parece uma espécie de peça artística com mensagem
Para ter a verdadeira experiência Spigot, no Firefox dá para ir em F12 > Network > No Throttling e mudar para GPRS; no Chromium, em F12 > Network > criar um Custom profile de 20kbps para limitar a velocidade e sentir de forma mais realista
Fiquei curioso se também existe conteúdo relacionado a Shakespeare aqui