Meu servidor Git ficou instável por causa do crawler de IA da Amazon

 (xeiaso.net)
1 pontos por GN⁺ 2025-01-19 | 1 comentários | Compartilhar no WhatsApp
  • O servidor Gitea público git.xeserv.us ficou instável por causa de requisições do AmazonBot, e o operador pediu à equipe do AmazonBot que incluísse o domínio na lista de bloqueio
  • Embora robots.txt tenha sido configurado com Disallow: / para todos os bots, as requisições continuaram chegando, criando uma situação em que talvez fosse necessário abandonar a própria operação de um servidor Git público
  • Crawlers de IA dificultam o bloqueio ao trocar o user agent ou usar proxies de IP residencial
  • No nginx ingress, foi feito um bloqueio para retornar 418 a user agents com Amazon, mas as requisições continuaram vindo de outros IPs, e cerca de 10% delas nem tinham o user agent amazonbot
  • No fim, o servidor Gitea voltou a ficar atrás da VPN, e foi criado o Anubis, um proxy reverso que faz uma verificação de prova de trabalho antes das requisições

Requisições do AmazonBot e os limites do robots.txt

  • O operador pediu aos responsáveis pelo AmazonBot que adicionassem git.xeserv.us à lista de domínios bloqueados
  • Pediu também que entrassem em contato caso quisessem rastrear o servidor Git, para que ele pudesse pagar o custo de upgrade de hardware necessário para suportar o uso excessivo de recursos
  • Um robots.txt para bloquear todos os bots já havia sido configurado, mas isso não foi suficiente para bloquear as requisições na prática
User-agent: *
Disallow: /
  • Também resumiu por que é difícil bloquear bots de crawlers de IA
    • Os bots mentem
    • Eles trocam o user agent
    • Usam endereços IP residenciais como proxy
    • Também usam outros métodos

Bloqueio no nginx ingress e lançamento do Anubis

  • Em 2025-01-17 17:50 UTC, foi adicionado bloqueio por user agent na configuração do nginx ingress
nginx.ingress.kubernetes.io/configuration-snippet: |
  if ($http_user_agent ~* "(Amazon)" ){
    return 418;
  }
  • Mesmo depois dessa configuração, o bot continuou fazendo requisições sempre de IPs diferentes, e cerca de 10% das requisições não tinham o user agent amazonbot
  • Em 2025-01-18 19:00 UTC, o servidor Gitea foi movido novamente para atrás da VPN
  • Depois disso, começou a ser criado um proxy reverso que verifica uma prova de trabalho antes de permitir requisições na frente do servidor Gitea
  • Em 2025-01-18 23:50 UTC, esse proxy passou a estar disponível com o nome Anubis em https://git.xeserv.us/
  • Em 2025-03-26 14:27 UTC, o Anubis havia se tornado um projeto independente com um site de documentação

Leituras relacionadas

1 comentários

 
GN⁺ 2025-01-19
Opiniões no Hacker News

  • Agora é hora de enviar uma notificação extrajudicial em nome de um advogado. Pelas diretrizes de acusação da Computer Fraud and Abuse Act, o Departamento de Justiça dos EUA geralmente não considera acesso a servidores públicos que não seja um ataque evidente como “acesso não autorizado”, mas diz que, depois que o titular da autorização envia uma solicitação clara por escrito para parar e o réu a recebe e entende, a partir desse momento passa a ser não autorizado.
    Então basta pedir a um advogado para redigir uma carta clara de “cease and desist” e entregá-la à Amazon do modo que ele recomendar, por carta registrada ou por um oficial de entrega de intimações. Provavelmente é melhor fazer os dois e também enviar por e-mail.
    Depois é ver se a Amazon para; se não parar, dá para apresentar uma queixa criminal. Aí a Amazon vai passar a prestar atenção.
    https://www.justice.gov/jm/jm-9-48000-computer-fraud

    • “Ver se a Amazon para” só faz sentido se essas requisições estiverem mesmo vindo da Amazon. Pelos detalhes do texto — user agents rotativos, IPs residenciais e um comportamento que parece não interpretar o robots.txt — isso parece pouco provável.
      O bot da Amazon deveria vir de faixas de IP conhecidas da Amazon e obedecer ao robots.txt. Um engenheiro da Amazon também confirmou isso em outro comentário: https://news.ycombinator.com/item?id=42751729
      Se a única coisa que bate com a Amazon é a string de user agent “AmazonBot”, mas as faixas de IP e o comportamento não batem, enviar uma carta de advogado para a Amazon é parecido com queimar dinheiro.
    • Sinceramente, só o fato de isso ter chegado à primeira página do Hacker News já deve ser constrangedor o suficiente para que alguém do departamento de bom senso leia e responda ao e-mail educado que enviei dizendo “por favor, não raspe meu servidor git”. Se eu não tiver resposta até a próxima terça-feira, vou pedir a um advogado para redigir uma notificação formal para cessar a atividade.
    • Será que chegou a hora de precisarmos de uma lei dizendo que robôs devem obedecer ao robots.txt?
    • Fiquei curioso sobre o que exatamente process server significa aqui.

  • Gosto da solução deste comentário: https://news.ycombinator.com/item?id=42727510
    É a ideia de colocar em algum lugar do site um link que uma pessoa jamais visitaria, bloqueá-lo no robots.txt e, se algum IP visitar esse link, bloqueá-lo por 24 horas. Como dizem que o crawler da OpenAI em especial ignora wildcards, dá para colocá-lo sob um wildcard.

    • Já lidei com atividade de bots usando faixas amplas de endereços e usei uma abordagem parecida: quando as condições confirmavam que era bot, eu bloqueava o IP por 24 horas.
      Mas havia tantos IPs envolvidos que isso quase não afetava o tráfego.
      Recomendo olhar os cabeçalhos recebidos com bastante detalhe. O varnishlog é bem bom para isso e, se você passar tempo suficiente analisando, pode encontrar características compartilhadas por todas as requisições. Por exemplo, combinações peculiares de idioma declarado e localização geográfica, ou a mesma versão antiga de navegador.
    • Web crawlers são realmente um saco. Uns 8 anos atrás, no lugar onde eu trabalhava, um servidor de imagens de veículos caiu. O crawler problemático acessou links de imagens de veículos que existiam por causa da natureza do nosso trabalho e, combinando com a pior condição possível — as imagens não existiam de fato — acabou basicamente fazendo DoS no servidor de imagens de relatórios de status.
      Pior ainda: havia um bug no tratador de erros, então, quando essa condição ocorria, o processo do servidor era reiniciado e, nesse processo, invalidava também uma implementação de cache que era “bem decente para os padrões do .NET 2.0”.
      Por isso me lembro de termos começado a incluir uma técnica de canário como salvaguarda. Alguns canários simples ainda saíam mais barato do que adicionar outro servidor web. Claro, também corrigimos o problema do cache e adicionamos um modo de o serviço “gritar” quando recebesse requisições ruins demais.
    • Quando criei meu crawler para um mecanismo de busca, percebi que quase não há bibliotecas de crawler que funcionem direito no mundo real. Acabei tendo bastante trabalho para implementar por conta própria algo que respeitasse os arquivos robots bastante complexos e aninhados da Amazon e do Google, além dos períodos de espera solicitados.
      Só que os crawlers dessas próprias empresas não conseguiam parsear os manifests que elas mesmas criaram.

  • Também estamos vendo o mesmo comportamento em todos os bots de AI e SEO, então recomendo. Eles obedecem ao robots.txt só no limite do aceitável e são difíceis de bloquear. Quando fazem crawling, chegam em ondas como spam, aumentam muito a carga e derrubam muitos servidores de clientes.
    Se crawlers de AI querem acessar, precisam se comportar direito ou pagar. Caso contrário, o resultado será um bloqueio quase universal.

    • A solução é um tarpit global. Mesmo sem considerar crawlers de AI, faz sentido. Quando precisei implementar isso no passado, eu fazia de forma semimanual: parseava os logs de acesso e aplicava -j TARPIT no iptables para IPs que faziam em média mais de X requisições por segundo para /api.
      Não sei bem como implementar isso na nuvem. Ainda não precisei disso lá.
      https://gist.github.com/flaviovs/103a0dbf62c67ff371ff75fc62f...
    • Não sei como se faria um “bloqueio quase universal”. O problema não é justamente que isso é difícil? Se fosse possível, já estariam fazendo.
    • Fiquei curioso sobre o que quer dizer obedecer ao robots.txt “só no limite”. Isso não é binário? Quer dizer que obedecem a algumas diretivas e ignoram outras?
    • Não haveria um jeito de um site vender esses dados aos bots de AI como um arquivo zip grande? Parece melhor do que sofrer DDoS continuamente.
      Ou, no mínimo, que eles raspassem por educação durante a noite ou em horários de menor movimento.
    • De que adianta bloquear? A essa altura eles provavelmente já terão raspado todo o conteúdo.

  • Não vou presumir que isso seja realmente a Amazon. O autor está vendo requisições vindas de IPs residenciais em rotação e com a string de user agent também mudando.
    Fingir ser o crawler de uma grande empresa é uma técnica comum usada por quem não quer chamar atenção. O fato de as requisições virem de IPs residenciais é um grande sinal de alerta de que há outra coisa acontecendo.

    • Trabalho na Amazon, mas não lido diretamente com web crawling.
      Pelo que consegui verificar internamente, é muito improvável que isso seja realmente a Amazon. O Amazonbot deve respeitar o robots.txt e sempre deve vir de endereços IP pertencentes à Amazon. O procedimento de verificação está aqui: https://developer.amazon.com/en/amazonbot
      Encaminhei internamente para confirmar se existe algum time interno estranho que eu desconheça fazendo isso, mas o autor deveria tratar esse tráfego como malicioso e como alguém que falsifica o user agent.
    • Esse tipo de coisa é oferecido comercialmente como serviço[1]. Por causa de alguma biblioteca incluída em algum lugar, centenas de milhões de redes acabam sendo usadas como backdoor, virando crawlers/scrapers, e alguma redação ampla perdida nos termos de uso torna plausivelmente legal usar usuários como linha de frente para atividades entre o lícito e o ilícito.
      [1] https://brightdata.com/proxy-types/residential-proxies
    • Hoje em dia, se uma empresa faz crawling agressivo, é difícil garantir que ela não esteja usando uma rede de proxies.

  • Passei pelo mesmo problema recentemente. Minha instância do Forgejo começou a usar 100% da CPU do meu servidor doméstico, porque Claude e os amigos de IA da Meta e do Google estavam martelando, em alta velocidade, links praticamente infinitos.
    Consegui reduzir um pouco com robots.txt e uma lista de bloqueio por user agent no Caddy, mas não sei por quanto tempo isso vai funcionar.
    Para onde foi a etiqueta do scraping?

    • Para o dinheiro. As empresas de IA têm um incentivo financeiro para coletar o máximo de dados possível, o mais rápido possível, de qualquer lugar onde consigam obtê-los. Neste momento elas também têm tanto dinheiro para queimar que nem precisam se preocupar muito em fazer isso de forma eficiente.
    • Quando várias empresas receberam o sinal de que, pelo menos por enquanto, a janela de Overton sobre o que a IA pode consumir é imensamente ampla, elas vão tentar pegar o máximo possível antes que a regulação aperte.
      O risco maior é uma dessas empresas, até mesmo uma que se diga “Open”, atingir um tamanho em que passe a ser “grande demais para falir” do ponto de vista econômico ou de segurança nacional.
    • Aconteceu o mesmo que acontece com a etiqueta em todos os outros contextos. A etiqueta só existia nos contextos em que ignorá-la não dava dinheiro. No momento em que essa premissa desaparece, ela é descartada imediatamente.
    • Alguém pode compartilhar um bom robots.txt ou uma lista de user agents para bloquear crawlers de IA?
    • Quando será que a última pessoa no Hacker News vai perceber que Meta, OpenAI e todas as big techs vão acabar prejudicando todos nós por dinheiro rápido?
      O Facebook ficou famoso por facilitar a raspagem da lista de amigos do MySpace e, depois que cresceu, proibiu o mesmo comportamento no próprio site.
      Pelo amor de Deus, precisamos acordar.

  • Tem certeza de que isso não é um DDoS se passando pela Amazon?
    O fato de as requisições virem de IPs residenciais é realmente suspeito.
    A motivação para um DDoS assim poderia ser derrubar sites pequenos e fazer parecer culpa da Amazon, mirando a própria Amazon.
    Se for mesmo a Amazon, o ponto de partida é bloquear todos os intervalos de IP que ela publica. Mas parece que as requisições também vêm de fora desses intervalos.

    • Vale conferir sites como grass dot io. Não vou colocar link direto porque não quero mandar tráfego para eles.
      Esses serviços pagam pela banda dos usuários e depois a revendem a terceiros, então muito tráfego de bots parece vir de IPs residenciais.

  • Meu site, o Pinboard, também está sendo bombardeado por algo que parece ser crawlers de IA. No começo do verão, vinha de IPs da China e de Singapura, mas agora nem consigo mais bloquear por faixa de IP e preciso depender de CAPTCHA.
    O nível de tráfego é suficiente para matar o site imediatamente, e eu nem tenho textos interessantes para treinar, só links.
    Fico curioso para saber como o autor do post original descobriu que o crawler da Amazon era o culpado. Eu também queria encontrar alguém a quem atribuir a culpa.

  • Talvez a melhor forma de lutar contra isso não seja bloquear. Bloquear não causa nenhum dano à Amazon nem a outras empresas.
    E se, em vez disso, fosse possível alimentar os bots com conteúdo obviamente nocivo ou corruptor?
    Se isso acontecesse em uma escala maior e a Amazon descobrisse os dados envenenados, teria de gastar dinheiro para removê-los rapidamente e tentaria impedir que os bots consumissem esse tipo de dado.
    Claro que o maior problema é que ninguém quer manter esse tipo de coisa no próprio site.

    • A ideia de alimentar com “conteúdo nocivo” entende completamente errado o alcance do mau comportamento das empresas de IA.
      Esses scrapers já consomem sem hesitar CSAM e coisas terríveis equivalentes. Alguns dos terceirizados de marcação de dados da OpenAI no Quênia pediram demissão por causa disso. É uma matéria da Time de 2023.
      As empresas de IA hoje não se importam com qualidade dos dados, só com quantidade. A única maneira de prejudicá-las é entregar 0 byte.
      Uma pessoa comum iria direto para a cadeia por um décimo do que Sam Altman aprovou.
    • Já vi recomendarem este tarpit para esse fim. Quando o site é rastreado, ele cria aninhamentos infinitos de diretórios e conteúdo lixo infinito, deixando o bot preso por horas.
      https://zadzmo.org/code/nepenthes/
    • Se conteúdo nocivo significa conteúdo incorreto, há alguém em outro comentário desta thread que realmente faz isso: https://marcusb.org/hacks/quixotic.html
    • Empresas bilionárias continuam infringindo a lei sem punição; por que eu deveria me responsabilizar por mijar contra o vento?

  • Seria bom se dessem alguns créditos da AWS como gesto de boa vontade para compensar o excesso de tráfego de saída gerado pela Amazon e por outros bots. Ainda assim, a receita de anúncios deste texto provavelmente deve cobrir isso. Se eu desativar o bloqueador de anúncios, a conta fecha.

  • Antes de bloquear via Nginx, o Bytespider respondia por 59% e o Amazonbot por 21%; juntos, eles representavam 80% de todo o tráfego do nosso servidor Git
    Em um mês, o ClaudeBot enviou ao Redmine mais tráfego do que em todos os 5 anos anteriores à existência do ClaudeBot somados