A web aberto se torna difícil de manter com ataques de scrapers de IA

• À medida que ataques de web scraping para coletar dados de treinamento para grandes modelos de linguagem e afins vêm aumentando há mais de um ano, a carga de tráfego cresceu a ponto de dificultar que sites independentes mantenham sua abertura
• Os atacantes usam proxies residenciais compostos por milhões de dispositivos comuns e móveis, fazem apenas algumas requisições por IP e mascaram o user-agent, tornando ineficazes os bloqueios tradicionais por IP
• Malware, dispositivos vulneráveis de streaming de mídia, VPNs gratuitas e SDKs de apps compõem essas redes de proxies; após a desarticulação da IPIDEA e da NetNut pelo Google, houve precedente de queda temporária no volume de ataques, seguida de novo aumento
• Sites respondem com proof of work do Anubis, CAPTCHA, barreiras de login e pagamento e ferramentas de contaminação de dados, mas a LWN se concentra em otimizar o site e conter custos durante ataques para não atrapalhar leitores reais, mecanismos de busca e o Internet Archive
• Com os custos de defesa contra scrapers e verificação de usuários sendo repassados para toda a web, se não surgir uma solução sustentável, sites independentes podem migrar para trás de barreiras defensivas e prejudicar a internet aberta

---

Ataques de scrapers continuam crescendo

• O problema da coleta de dados de treinamento para grandes modelos de linguagem e projetos relacionados, abordado no início de 2025, piorou mesmo mais de um ano depois
• As requisições enviadas a sites por agentes desconhecidos cresceram a níveis sem precedentes, e o tráfego excessivo torna cada vez mais difícil manter a web aberta

Proxies residenciais mobilizando milhões de IPs

• Os ataques enviam, por algumas horas, requisições coordenadas a partir de milhões de endereços IP únicos, com cada endereço acessando o site no máximo duas ou três vezes
• Informações controladas pelo atacante, como o user-agent, são fictícias, e cada requisição é disfarçada como o acesso de uma pessoa comum usando um navegador web
• Bots normalmente não buscam imagens nem CSS, o que dá pistas para diferenciá-los de humanos, mas, quando a identificação termina, aquele endereço já não é usado novamente; por isso, bloqueios de IP posteriores não são eficazes
• O tráfego vem principalmente de redes domésticas e móveis comandadas por um nó central de comando e controle
  • Software instalado em dispositivos comuns recebe comandos do nó de controle, busca páginas web e envia os dados de volta
  • Muitos operam sem o conhecimento ou consentimento do dono do dispositivo, e sistemas usados dessa forma são chamados de proxies residenciais

Redes de proxies criminosas e dispositivos infectados

• Um tipo envolve operadores criminosos que executam scrapers em sistemas tomados por malware
• No início do ano, o Google iniciou a desarticulação da botnet IPIDEA e divulgou informações sobre seu modo de operação
  • O momento da interrupção da IPIDEA coincidiu com uma grande queda no tráfego de scrapers da LWN
  • Houve alguns meses relativamente calmos, mas depois os ataques voltaram a crescer
• Recentemente, dispositivos de streaming de mídia foram identificados como um dos principais vetores de software malicioso de scraping
  • Alguns dispositivos já são infectados na etapa de fornecimento
  • Outros têm segurança fraca e são facilmente tomados depois da venda

Redes comerciais de proxies usando VPNs gratuitas e SDKs de apps

• Outro tipo se comporta como empresas em certa medida legítimas e vende endereços IP “obtidos eticamente”
• A Bright Data é uma empresa representativa que divulga sua capacidade de contornar controles de acesso e limites de tráfego de sites
  • Usuários de VPNs “gratuitas” precisam permitir que a Bright Data roteie tráfego por seus dispositivos
  • Celulares e outros dispositivos que usam essa VPN viram endpoints da rede de proxies residenciais da Bright Data e são mobilizados em ataques a sites
• Empresas semelhantes oferecem bibliotecas que desenvolvedores de apps podem conectar a seus produtos e, em troca de ceder a conexão de rede dos usuários, pagam os desenvolvedores
  • Uma dessas empresas perguntou se poderia veicular anúncios de seu SDK na LWN, mas a conversa terminou rapidamente
  • Os operadores variam entre os que tentam criar uma aparência legalista, alegando “conformidade com o GDPR” e afins, e os abertamente antiéticos
• Como esses operadores de proxies conseguem executar código que acessa recursos de uma rede com milhões de dispositivos conectados, não se pode presumir que essa permissão seja usada apenas para web scraping

Empresas de modelos e usuários de redes de proxies

• Empresas conhecidas cujo negócio central é o desenvolvimento de modelos também fazem web scraping por conta própria
  • O tráfego facilmente atribuível a essas empresas traz a identidade claramente indicada no user-agent
  • Em geral, respeita mecanismos de controle como robots.txt
  • Coleta repetidamente o site inteiro, como se verificasse se até textos escritos em 2003 foram alterados recentemente
  • Ainda assim, não envia tráfego insustentável a partir de milhões de sistemas, portanto não é o maior problema
• Não está claro quem paga para executar ataques por proxies residenciais
  • Não foi encontrada evidência de que as empresas de modelos de ponta usem essas redes
  • Essas empresas não revelam como alimentam seus modelos com dados nem a origem dos dados de treinamento, e também não demonstraram respeito por criadores de conteúdo ou por quem se preocupa com problemas operacionais
• Para cada modelo público, podem existir muitos modelos que não aparecem externamente
  • Muitas empresas podem estar criando seus próprios modelos na expectativa de obter enorme valorização se saírem à frente na corrida de IA
  • Órgãos governamentais sigilosos de vários países também podem querer obter seus próprios modelos e dados de treinamento
  • Grandes organizações criminosas também provavelmente querem seus próprios modelos
• À medida que ferramentas de IA passam a ser vistas como armas, ocorre uma corrida armamentista, e toda a internet está sendo arrastada para esse processo

Defesas para proteger a internet aberta

• Operadores de sites adotam várias proteções para bloquear ataques minimizando o impacto sobre usuários reais
• O Anubis é amplamente usado para bloquear scrapers ao exigir proof of work de quem acessa
• Serviços comerciais exibem botões para “provar que você é humano”, e outros sites exigem CAPTCHAs como escolher quadrados com semáforos ou encaixar peças de quebra-cabeça
• Alguns sites moveram recursos importantes para trás de login ou paywall, e contaminam ativamente os dados recebidos pelos scrapers com ferramentas como iocaine
• O custo de construir e manter defesas e o incômodo para usuários que precisam passar por elas são um fardo pesado imposto ao mundo todo pelos scrapers e por quem paga por eles

A abordagem defensiva da LWN e suas limitações

• A LWN sofreu recentemente o ataque de scrapers mais forte até agora, mas, graças às defesas implementadas, suportou o tráfego sem que a maioria dos leitores reais percebesse
• Divulgar medidas defensivas específicas poderia dar informações de resposta aos atacantes, por isso elas são mantidas em sigilo; também do lado da defesa, a corrida armamentista continua
• A prioridade é reduzir ao máximo o impacto sobre leitores reais
  • A LWN não usa o Anubis porque ele atrasa o acesso ao site e incomoda os leitores
  • É provável que os scrapers acabem contornando o Anubis, e já há sinais disso
  • Se é possível mobilizar milhões de dispositivos de terceiros, proof of work não é um obstáculo grande
• A LWN também tenta não bloquear o acesso de mecanismos de busca legítimos e de organizações como o Internet Archive
  • Uma lista explícita de permissões que só libera o acesso para mecanismos de busca dominantes reforça ainda mais a posição de monopolistas que já têm problemas de qualidade de serviço
  • Até agora, a LWN conseguiu manter acesso normal sem uma lista de permissões para mecanismos de busca específicos
• Partes do site são otimizadas de forma agressiva, e operações custosas são minimizadas durante ataques
  • Leitores anônimos podem ser afetados ocasionalmente por essas medidas, mas usuários logados não são
  • Em algumas situações de ataque com defesas ativas, o tempo de resposta fica até mais rápido que o normal
• A LWN não vê as medidas atuais como solução permanente e precisa avaliar as próximas respostas para quando elas deixarem de funcionar

Desarticulação da NetNut e calma temporária

• Em 2 de julho, o Google anunciou que, em cooperação com o FBI e outros órgãos, desarticulou a rede de proxies residenciais NetNut
• Após a ação, o nível de ataques de scrapers parece ter caído em alguma medida, mas, pela experiência anterior, é provável que essa calma não dure muito
• A Google Play Store pretende verificar apps infectados pela NetNut
• Os principais operadores de lojas de apps não respondem por que é tão fácil cadastrar apps com funcionalidade de proxy residencial

A internet sendo empurrada para trás de barreiras defensivas

• São necessárias soluções mais duradouras antes que toda a internet migre para trás de barreiras defensivas e desapareça a rede aberta que impulsionou a criatividade
• A indústria que provoca os ataques não se importa se sites independentes forem destruídos depois de ter seu conteúdo extraído, e a mesma atitude se estende ao planeta e à economia
• Até que padrões éticos mínimos sejam aplicados às empresas que operam grandes modelos de linguagem e tecnologias relacionadas, esse comportamento continuará, e operadores de sites serão obrigados a se defender por conta própria

[GN⁺]

Opiniões no Lobste.rs

• Entre todos os negócios descaradamente suspeitos que descobri recentemente, proxies residenciais foram os mais chocantes
  Li mais detalhes em https://spur.us/blog/smart-tv-apps-residential-proxy-sdks, e é difícil acreditar que isso seja legal. Deveriam ser classificados na mesma categoria de botnets e chamados de botnets legalizadas

  • É um negócio que realmente merece ser condenado. Dizem que usam apenas parceiros verificados e aprovados, mas não consigo pensar em um único uso legítimo para proxies residenciais. Existe mesmo algum?
  • É preciso ter cautela com a regulamentação de proxies residenciais. Se forem criadas regras mirando isso, muito mais coisas além de botnets de proxies residenciais serão afetadas

• Outra vítima são os verificadores de links. Ficou bem mais difícil checar se um site tem links quebrados
  Se eu tivesse tempo, acho que tentaria usar o projeto Common Crawl para verificar se o conteúdo ainda está no ar

  • As pré-visualizações de links que apps de chat geram do lado do remetente também sofrem. Fiquei feliz por ter contribuído com esse recurso para o gajim, um cliente XMPP, mas na prática é deprimente ver pedidos de pré-visualização de links serem bloqueados com tanta frequência por telas de “verificando se você é humano”

• No fim, todas as operações caras, como listar o histórico de um repositório no GitHub, vão ficar atrás de barreiras de autenticação, e o resto será transformado em conteúdo estático e servido por CDN

  • Como há preocupações com centralização e vigilância governamental, CDN deveria ser o último recurso, e primeiro deveríamos extrair mais desempenho do próprio servidor
    No nível da aplicação, certamente ajuda tornar mais conteúdo estático, reduzir consultas ao banco de dados e usar cache. Por muito tempo tivemos o luxo de não nos preocupar tanto com desempenho, mas agora até sites pequenos precisam prestar mais atenção nisso, e é muito melhor do que ver o “verificando o navegador” da Cloudflare em todo lugar
    Já tive problemas em um VPS pequeno por causa do modo tradicional em que o Apache faz fork de um processo separado para cada requisição. Cresci mexendo em servidores LAMP, então o Apache é familiar e confortável, mas ele não aproveita o hardware da forma mais eficiente, e no fim isso importa mais. Não tenho dados empíricos, mas acho que um servidor como o Caddy aguentaria melhor a carga, então pretendo migrar na próxima atualização do servidor
  • Meu servidor Forgejo também estava nessa situação. Tentei gerenciar o tráfego malicioso contínuo com o Anubis, mas não entendi completamente como ajustar a configuração para esse tráfego e também não gostei de eu mesmo ter de encarar desafios de autenticação lentos
    Também tentei usar fail2ban, mas quando a escala aumentou ele não conseguiu lidar bem. No fim, deixei a Cloudflare cuidar disso com as regras de segurança que descrevi em um post no blog. Eu relutava em depender da Cloudflare por muito tempo, mas mudei de ideia depois de ver o gráfico de uso de CPU mais abaixo no texto
  • Por outro lado, repositórios Git e crawlers combinam extremamente mal. Links gerados dinamicamente causam uma explosão combinatória e acabam criando armadilhas para crawlers improvisadas, por isso qualquer crawler minimamente decente evita ativamente URLs cujo caminho contenha strings hexadecimais longas
    Mesmo causando custos enormes para hosts Git, surpreendentemente muitos deles não configuram o robots.txt para impedir crawling profundo dentro dos repositórios

• A parte “houve pedidos para que eu explicasse as medidas tomadas para defender o site, mas, por motivos óbvios, não quero discutir detalhes. Mesmo nesse nível, há uma corrida armamentista” é dolorosa
  Eu também tive bastante sucesso nessa luta, mas por causa da tragédia dos comuns, se eu divulgar as medidas muito simples que usei, elas perdem eficácia. É um tema realmente interessante e tenho ideias originais que gostaria de escrever no blog, mas é uma pena não poder fazer isso