Como impedir que um bot da AWS envie 2 bilhões de requisições por mês?

• Na infraestrutura da AWS, surgiu um problema inesperado de grande volume de requisições web
• Foi relatado um aumento repentino no tráfego, de 200 milhões para 2 bilhões de requisições por mês
• A análise dos logs confirmou requisições repetidas de um User-Agent específico
• Houve contato com a equipe de suporte da AWS, mas a situação ficou sem uma solução clara
• Surgiu a necessidade de avaliar vários métodos de bloqueio, como regras de firewall, bloqueio por User-Agent e outros

---

Introdução ao problema

• Um usuário da AWS levantou a questão de um fenômeno em que 2B (2 bilhões) de requisições ocorreram em um servidor web ao longo de um mês
• Essas requisições vieram de bots que usam um User-Agent específico e representam tráfego anômalo, incompatível com padrões normais de uso
• O aumento repentino de tráfego traz o risco de elevação de custos e sobrecarga do sistema

Análise da causa

• A maior parte do enorme volume de requisições veio de faixas de IP suspeitas da AWS
• Pelos registros de acesso, foi identificado que a causa é um bot ou script específico
• Há um padrão comum no User-Agent, o que torna possível fazer filtragem

Resposta atual e limitações

• Houve contato com a equipe de suporte da AWS, mas não foi apresentada uma solução decisiva
• Um volume tão grande de requisições pode aumentar bastante a chance de indisponibilidade do serviço e custos adicionais

Direção da solução e pontos a considerar

• Está sendo avaliada a necessidade de várias políticas de bloqueio, como adição de regras de firewall, bloqueio de tráfego com base em User-Agent e aplicação de blacklist de IPs
• No longo prazo, surge também a necessidade de reforçar o sistema de monitoramento de tráfego e estruturar um mecanismo de detecção e bloqueio automático de acessos anômalos

[GN⁺]

Comentários do Hacker News

• Já tive experiência tentando redirecionamentos 30x, por exemplo usando uma resposta 301 para apontar para arquivos enormes hospedados por empresas de que eu não gosto; se você fizer uma instância da AWS dessa empresa baixar 70 mil ISOs do Windows ao mesmo tempo, com certeza eles vão perceber. Também dá para usar a chamada estratégia de “tar pit”, embora não seja fácil com Cloudflare: depois de receber a requisição, você envia a resposta um caractere por vez, com 30 segundos de atraso entre cada caractere. Com 700 requisições por segundo e um cabeçalho/resposta de 10 KB por requisição, vai parecer que o servidor está absurdamente lento.
  • Se você não gostar de uma empresa específica como alvo do redirecionamento 301, recomendo apontar para algo como a Amazon.
  • Acho que essa estratégia de receber a requisição e responder lentamente, um caractere por vez, é exatamente o oposto de um ataque DDoS Slow Loris. A explicação sobre o ataque Slow Loris pode ser vista na Cloudflare; ou seja, em vez de o ataque usar conexões lentas, é a defesa que responde com conexões lentas.
  • Como alternativa, também dá para pensar em redirecionar via 301 para o site oficial do governo de .sg e deixar que as autoridades locais lidem com isso.
  • Vale apontar que o tráfego de entrada na AWS é gratuito, então mesmo que o dono da instância receba um volume enorme de dados, isso não gera custo extra para a AWS.
• Uma forma é tornar a operação de bots claramente maliciosos cara do ponto de vista operacional. Isso funciona especialmente com algo como gzip bomb se o bot for vulnerável, mas mesmo só esperando uns 10 segundos antes de responder você já pode fazer o servidor do bot consumir cerca de 7.000 portas; a maioria dos processos Linux não aguenta isso e morre. É fácil de implementar com nginx + mod-http-echo.
  • Há pessoas que já implementaram essa estratégia na prática; dá para ver pela lista de user agents no código open source, e a implementação em si é muito simples. O código relacionado pode ser visto aqui.
  • Clientes da AWS pagam por tráfego de saída, mas também fiquei curioso se existe uma forma de fazer a AWS ou a Cloudflare enviarem tráfego pesado para nós ao contrário.
  • Passei por algo parecido: havia scraping malicioso repetido tentando coletar os preços do nosso site, e como o catálogo tinha milhões de produtos, calcular os preços dinamicamente consumia muitos recursos. Em picos repentinos de requisições, nossa infraestrutura quase entrou em colapso. Como defesa, tentamos separar o tráfego de spam com tags e fazer cache sem impactar clientes reais; também discutimos inserir valores de erro aleatórios nos preços para tornar os dados inúteis. No fim, acabamos trabalhando com a Cloudflare para bloquear rapidamente as requisições maliciosas, mas isso custou tempo e dinheiro. Suspeitávamos que o atacante fosse um serviço terceirizado de um concorrente, e era frustrante porque havia a possibilidade de oferecer uma API oficial e, ainda assim, eles não entraram em contato. Antigamente havia muito essa visão de que “se seu site não aguenta o tráfego, a culpa é sua”, mas hoje parece que a percepção mudou bastante.
  • Fico me perguntando se, fazendo isso, meu próprio servidor também não consumiria 7.000 portas.
  • A pergunta é se, usando essa técnica, meu servidor também não acabaria tendo o mesmo grande número de conexões.
• Sou o principal autor do Anubis. Descobri na prática que, se você configurar a Cloudflare para retornar HTTP 200, o bot para de insistir assim que recebe 200.
  • Só para constar, parece que o site principal está com algum problema agora.
  • Também já tentei simplesmente derrubar a conexão à força quando a detecção acontece na camada de aplicação; quando a configuração na Cloudflare é difícil, isso parece funcionar contra bots mais primitivos.
• Já passei por algo parecido no meu blog pessoal. Uns 7 ou 8 anos atrás, o tráfego disparou de repente e achei que o site tivesse viralizado, mas o padrão era mecânico demais e pareceu estranho. Investigando, descobri que algum bot/crawler estava raspando meu site como teste. Depois de meses pedindo educadamente várias vezes sem resultado, acabei redirecionando esse bot para sites pornôs aleatórios, e aí o crawling parou.
  • Na prática, isso é o melhor. Redirecione para algum lugar em que eles não queiram aparecer nos logs do crawler — para eles mesmos, para o provedor deles ou para conteúdo que eles não queiram.
• Uma forma de vingança até satisfatória é devolver 200 e incluir a string de teste EICAR no corpo para contaminar os dados. Veja a explicação do arquivo de teste EICAR.
  • Como uma espécie de oposto de um ataque SSRF, seria divertido redirecionar o bot para a API de metadados da nuvem e induzi-lo a chamar endpoints como <shutdown>. Também daria para incluir a string de teste EICAR na resposta de redirecionamento para acionar sistemas automáticos de detecção de segurança.
• Se você nunca precisa receber tráfego legítimo da AWS Singapore, uma alternativa é simplesmente mandar toda a faixa para blackhole.
  • Dá para usar o WAF para simplesmente descartar esses pacotes; a função "block" do Cloudflare WAF serve para isso.
  • Eu também já fiz isso antes: o bot Byte Spider, operado pela Byte Dance, raspou milhões de imagens, e no fim até pedi ao pessoal da Cloudinary que bloqueasse o user agent; no começo também bloqueei Singapore inteira. Fiquei realmente irritado com o quão maliciosamente empresas de scraping de IA operam seus bots. Ainda bem que usava um bom serviço como o Cloudinary para economizar custos, e hoje em dia resolvo isso bloqueando todos os bots de IA via Cloudflare.
  • Aliás, as faixas de IP por região da AWS podem ser consultadas aqui.
• Em 2018, passei por algo parecido em escala bem menor. Li a lista oficial em JSON de faixas de IP da AWS e cheguei a criar uma ferramenta para bloquear essas faixas no Windows Firewall. O post relacionado no blog pode ser consultado aqui, e o readme da ferramenta está neste link. Ela rodou por anos como tarefa agendada no servidor, mas não tenho certeza se ainda funciona hoje. Se houver interesse, eu poderia publicar o código ou passar para outra pessoa; mesmo implementando do zero, não é tão difícil. Boa sorte.
• O órgão regulador de telecomunicações de Singapura proíbe até a mera posse de pornografia, então a sugestão é responder ao bot malicioso com softcore e ao mesmo tempo denunciar por email ao órgão e à AWS.
  • Quando alguém causa dano repetidamente pela internet, usar a legislação do país dessa pessoa costuma ser a forma mais eficaz de responder; de outras autoridades geralmente não dá para esperar muita ação.
• Se você informar à Cloudflare que esse tráfego é malicioso, eles conseguem bloquear fora da sua conta, então isso pode ser tratado sem pesar nas suas métricas de tráfego.
• Tive uma experiência parecida com um caso em que ficavam pedindo em grande volume um instalador de software de 80 MB. Redirecionei as requisições problemáticas para um arquivo chamado "please-stop.txt" e, dentro do arquivo, expliquei a situação e pedi que parassem. E eles realmente pararam.