Se houver problema, bloqueie no nível de IP
(boston.conman.org)- Ao analisar recentemente o tráfego web, foi descoberto que um web bot chamado Thinkbot gerava o maior volume de tráfego
- Esse bot ignora o
robots.txte sua mensagem de apresentação é extremamente displicente, basicamente dizendo algo como “se houver problema, bloqueie o IP” - Durante um mês, ele usou 74 IPs diferentes, distribuídos por 41 blocos de rede
- A investigação mostrou que todos esses blocos de rede pertenciam à Tencent, o que levantou a suspeita de uma possível transferência de custos da Great Firewall
- No fim, foi adicionada uma regra de bloqueio massiva, cobrindo cerca de mais de 470 mil IPs
A aparição do Thinkbot
- Ao analisar o tráfego web, foi notado que um web bot chamado Thinkbot ocupava uma fatia relevante do tráfego
- A string de User-Agent era a seguinte e bastante displicente
“Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In_the_test_phase,_if_the_Thinkbot_brings_you_trouble,_please_block_its_IP_address._Thank_you.)”.
- Além da frase “se causar problemas na fase de testes, por favor bloqueie o IP”, não havia nem mesmo uma URL de referência
- Ele fazia crawling sem respeitar de forma alguma o arquivo
robots.txt - Mesmo que o administrador do site tentasse bloqueá-lo, ele não usava um único IP, mas sim 74 endereços IP
- Ao rastrear isso de volta e consultar os ASNs, foi constatado que o tráfego vinha de 41 blocos de rede
- Isso significa que não era possível se defender com um simples bloqueio de um único IP
Relação com a Tencent
- Esses 41 blocos de rede pertenciam todos à Tencent
- O autor suspeita que o governo chinês possa tolerar ou até incentivar isso, e interpreta a situação como uma tentativa de repassar ao mundo exterior os custos da Great Firewall
- Dentro da China, a coleta de conteúdo é permitida e, mesmo que seja bloqueada do lado de fora, isso não seria um problema do ponto de vista do CCP; porém, para outros países e sites que tentam bloquear, isso se torna um ônus
Medidas de bloqueio no firewall
- O autor adicionou diretamente os blocos de rede da Tencent às regras de firewall do badbots
- Exemplos:
43.130.0.0/18,101.32.0.0/20,150.109.96.0/19etc. - Foram adicionados mais de 40 blocos de rede e, embora isso não cubra todos os IPs de propriedade da Tencent, inclui mais de 476.590 IPs únicos
Conclusão e metáfora
- O autor descreve essa situação como a realidade de que “na internet, não dá mais para ter coisas boas”
- Mais do que apenas bloquear tráfego de bots, este é um caso que mostra a queda de confiança em todo o ecossistema da internet e a inevitabilidade de respostas defensivas
6 comentários
Na verdade, a tese da ameaça chinesa já se tornou realidade em outras áreas há bastante tempo, e agora a China começou até a ameaçar a própria sobrevivência geral do ecossistema da internet.
Isso não é algo dito simplesmente com base em sentimentos de aversão ou viés político; muita gente precisa perceber que isso está realmente se tornando realidade.
Por que sempre que esses incidentes e acidentes são investigados, no fim é o CCP..
Uau... isso é realmente incrível...
Muito bom..
É a China de novo.
Comentários do Hacker News
Ao desenvolver um crawler web, tentei torná-lo o mais amigável possível. Verifico rigorosamente o
robots.txt, rastreio devagar, me identifico claramente na string de User-Agent e uso um único endereço IP. Mesmo assim, acabei encontrando vários truques anti-bot aplicados ao próprio arquivorobots.txt. Recentemente, orobots.txtestava baixando de forma extremamente lenta, como num ataque slow loris, então acabei tratando por engano como 404 e continuei rastreando. Depois dessa experiência, mudei o código para tratar timeout comoDisallow /. Ironicamente, mesmo tentando seguir bem as regras, acabei tendo que escrever código para detectar ferramentas anti-botAcho que é como esconder a campainha para impedir ladrões
Assim como em aplicações de servidor, no cliente também encerro silenciosamente a conexão TCP quando o outro lado se comporta de forma maliciosa ou incorreta. A outra parte precisa desperdiçar recursos por um tempo até perceber sozinha o que está acontecendo
Acho bem provável que isso não seja intencional. Bots maliciosos que não respeitam
robots.txtnem baixam o arquivo para começo de conversa, então pode ser mais erro ou incompetência do que má-féAcho que sanções que punem apenas quem tenta seguir as regras acabam tendo efeito contrário
Valorizo o esforço de tentar seguir as regras corretamente. Limitar o
robots.txtpode ser um erro, mas como alguns crawlers usam orobots.txtpara encontrar páginas mais interessantes, atrasá-lo pode ajudar a evitar problemas rapidamente. No fim, esse tipo de abordagem bloqueia informações do bot e reduz sua velocidade, e do ponto de vista do operador do site, como os bots maliciosos causam prejuízo, acaba sendo difícil se importar muito em distinguir bots honestos dos desonestosFico curioso sobre que características em comum têm os sites que sofrem seriamente por causa de bots. Eu mantive por vários anos um servidor web em casa com TLD
.com, tinha boa posição no Google para palavras-chave relacionadas e não tinha nenhuma configuração especial de bloqueio de bots no roteador ou no servidor. Já contei requisições de bots por curiosidade, mas a maioria só faz varredura de portas ou pega a página de índice, e quase nunca segue links carregados dinamicamente. Tanto na época do Apache 2 quanto agora, operando vários sites com Axum, não notei impacto visível causado por bots. Fico imaginando se isso tem a ver com listagem de diretórios, e gostaria de ouvir uma explicaçãoTenho a sensação de que muita gente inteligente está obcecada demais com a questão do web scraping. A menos que a atividade dos bots realmente esteja causando carga enorme ou problemas reais no site — claro, há exceções — na maioria dos casos isso não passa de um jogo inútil de “capture a bandeira”. A diferença é que aqui você nunca encontra a bandeira do adversário, só perde tempo. Acho que a melhor resposta é construir um produto web rápido e bem projetado, capaz de lidar com participantes distribuídos e difíceis de identificar mesmo quando eles geram carga. Na prática, essa abordagem também melhora muito a satisfação dos usuários humanos de verdade
Pela minha experiência, acho que você talvez não saiba o quão sério esse problema pode ser. Num emprego anterior, eu cuidava da performance de aplicação de um web app, e uma parte dos usuários era extremamente rápida, mas a maioria era lenta. Ao analisar os logs de desempenho, vimos que 60% de todas as requisições vinham de bots conhecidos, sem contar os bots esquisitos. Algumas empresas chegaram a causar ataques de DoS ao serviço, e o site caiu por causa disso. O problema é que os bots quase sempre pegam apenas respostas em cache, então as interações reais dos usuários ficam sendo expulsas do cache LRU. Alguns bots reescrapeavam todas as páginas visitadas a cada poucos minutos, outros aumentavam o throughput até o serviço começar a ficar lento. Às vezes até tentavam executar JavaScript e enviar formulários. O Googlebot era o único que se comportava de forma educada. Em alguns casos, 40% do tráfego real de entrada se concentrava em uma única URL, então o ganho trazido pelos bots também era quase nulo. Só percebi mais tarde que muitos desses bots eram usados para coleta de dados por empresas de IA em estágio inicial
Um amigo meu opera uma instância pequena e pública do gitea usada só entre amigos. Mesmo assim, chegam milhares de requisições de bots por hora. Mesmo quando isso não afeta diretamente o serviço, no mínimo parece assédio
Eu pago caro para obter dados e construir produtos web rápidos. Então, ao bloquear essas entidades, isso não é perda de tempo: eu realmente economizo banda e custo de servidor. Graças a isso, os clientes de verdade continuam recebendo o mesmo benefício sem nenhum inconveniente, mesmo que o conteúdo não seja raspado. Não entendo a lógica de achar que alguém está sendo explorado
Acho que isso se parece mais com um jogo de acertar o alvo em movimento do que com “capture the flag”. Pela minha experiência pessoal, em fóruns que tentam identificar e bloquear “bots ruins”, sempre aparecem mais bots e isso nunca acaba
Há muitos de nós que são inteligentes, mas também temos tendência a nos fixar demais em problemas técnicos. Se não fizermos nada, isso continua incomodando; se ao menos bloqueamos alguma coisa, a irritação diminui
Sempre me surpreende quanta gente no Hacker News leva
robots.txta sério. É realmente impressionante ver tanta boa vontade. Masrobots.txtnão é uma solução prática de verdade. As pessoas precisam saber querobots.txtexiste e precisam adicionar código de verificação derobots.txtao crawler, o que traz complexidade. Fico curioso se existe alguma outra solução prática. Coisas como “micropagamentos” ou “uma grande árvore de Merkle para verificação de identidade real” são mencionadas há muito tempo, mas nunca foram implementadas de fatoAcho difícil que exista desenvolvedor de bot que não conheça
robots.txt. O que existe são pessoas que acham que o projeto delas é um caso especial que pode ignorar as regras de todo mundorobots.txtnão tem força legalTambém vemos esse padrão de bots nos nossos logs. É bem irritante, mas pelo menos eles se identificam como bots e o tráfego real não é muito alto. A maior parte do tráfego vem de bots fingindo ser navegadores reais, ou de vários IPs do Brasil e da Ásia. Passei a última semana tentando todo tipo de coisa para bloquear bots, então compartilho algumas experiências que talvez ajudem.
As requisições vêm de centenas de IPs, mas apenas algumas vezes por dia em cada um, todos fingindo ser UAs reais
Quase nunca enviam URL de referrer, mas o bot da Huawei Cloud envia referrer às vezes (embora o tráfego seja baixo)
Minha principal tentativa foi limitar a banda de URLs com
id=para1Kb/s, esperando que desistissem ao ficar lento, mas os bots simplesmente não ligaram e continuaram requisitandoEles também se adaptaram a conexões keep-alive, então desativei keep-alive por completo em
/cgit/, mas mesmo assim continuaram ocupando todas as conexõesO método atual é permitir URLs com
id=apenas quando existe a query stringnotbot; se não houver referrer, mostro uma mensagem 403 orientando que, se for um usuário legítimo, adicione o parâmetronotbot. Isso reduziu a carga e melhorou as conexões dos usuários legítimos, mas os bots continuam requisitando e só recebem 403 repetidamenteNo fim das contas, parece que só existem duas opções: usar métodos ad hoc específicos para cada site ou delegar isso a alguém com recursos suficientes, como a Cloudflare. Soluções padronizadas de bloqueio de bots têm limite, porque quem tem muitos recursos consegue contorná-las ou bancar o custo
Também dá para bloquear preventivamente com 403 substrings raras de UA, como
MSIE 3.0ouHP-UX. Depois você junta os logs de 403 e vai bloqueando separadamente apenas os ASNs problemáticos, repetindo esse jogo de acertar o alvo em movimentoEu uso software da família Bernstein publicfile, da djbwares. Também adicionei ferramentas static GEMINI UCSPI-SSL e, com base numa ideia tirada da especificação GEMINI, proíbo totalmente fragmentos e parâmetros de query na URL da requisição. A lógica é a mesma que no GEMINI e pode ser aplicada a serviços HTTP estáticos. Pela configuração do servidor, para lidar direito com parâmetros de query eu teria que criar vários nomes de arquivo estranhos separadamente, o que não é realista. Graças a essa ideia, tentativas de explorar vulnerabilidades em CGI ou PHP nem chegam ao sistema de arquivos, porque são filtradas na etapa de decomposição da requisição. Para quem opera sites estáticos, recomendo bloquear parâmetros de query como no GEMINI. Claro, se você realmente quiser usar parâmetros de query num site estático, aí é exceção
Em algum momento comecei a me perguntar se seria viável, na prática, usar whitelist de faixas de IP. Também imaginei uma abordagem mantida pela comunidade, como listas de adblock
Infelizmente, quanto mais bem-comportado o bot, mais estável tende a ser o IP, enquanto agentes maliciosos podem usar proxies residenciais a qualquer momento. Se você bloquear IPs de proxies residenciais, acaba prejudicando usuários reais, e o agente malicioso simplesmente muda para outro lugar. Pela minha experiência lidando com milhares de IPs reais, não dá para decidir só com informação de IP; é preciso informação adicional
A empresa do Pokémon Go também tentou isso logo após o lançamento para impedir scraping. Eles dividiram em três categorias de IP: blacklist (Google Cloud, AWS etc.), IPs não confiáveis (residenciais) e whitelist (IPv4s normais e confiáveis). No começo isso filtrou os principais scrapers, mas o maior scraper de todos contornou a medida operando uma fazenda de terminais de modem. Como resultado, usuários comuns desistiam do jogo sem mapa, enquanto jogadores hardcore acabavam pagando ainda mais para usar scrapers. No fim, isso trouxe carga ainda maior aos servidores. Considero isso uma das muitas decisões ruins tomadas pelo Pokémon Go
Muitas empresas americanas já fazem isso. O problema é que, quando você está no exterior, às vezes continuam cobrando sem oferecer sequer um meio de cancelar o serviço, o que é absurdo
Whitelist e blacklist não precisam ser escolhidas de forma estritamente binária. A maior parte do tráfego existe numa zona cinzenta. Se você colocou certo IP em whitelist e depois detecta comportamento suspeito, precisa removê-lo da whitelist, avisar, receber comunicação, coordenar mutuamente a resolução e assim por diante, o que é extremamente complexo na prática. Whitelist só funciona bem entre parceiros com relação de confiança. Blacklist é útil para bloquear endereços problemáticos ou coisas como CIA, Rússia, China e provedores de nuvem. Uma abordagem realista é deixar em whitelist apenas hosts internos corporativos e outros ambientes com mecanismos robustos contra abuso
Estou criando uma whitelist positiva de bots por meio do projeto open source GoodBots. PRs são muito bem-vindos
Eu uso um método em que todas as requisições precisam incluir um cabeçalho customizado; todo o resto é bloqueado
Externamente uso proxy da Cloudflare e, internamente, deixo o Crowdsec e o Modsecurity CRS na frente do Traefik. Depois de ajustar para reduzir falsos positivos, isso está funcionando de forma muito estável. Envio os IPs temporariamente bloqueados e os IPs reportados para o Crowdsec, e publico os logs num canal do Discord. Em média, bloqueio dezenas de IPs diferentes por dia. Pela minha percepção, tentativas de acessar recursos privados ou explorar CVEs vêm muito mais de IPs dos EUA do que da China. Não me preocupo com scraping de conteúdo público; todo o resto só pode ser acessado por SSO ou intranet. Em vez de bloquear países específicos, é mais eficaz bloquear as tentativas de exploit ou flooding em si
Abordagens como a do Crowdsec são atraentes, mas acho um grande risco entregar todo o tráfego do servidor a uma empresa com fins lucrativos
Tentativas de ataque realmente sérias provavelmente já seriam barradas em algo como o WAF da Cloudflare
Muitos prédios residenciais só conseguem sair para a internet por alguns poucos endereços IP (Carrier-grade NAT)
Mais da metade do meu tráfego vem de bots do Bing, Claude e Facebook. Eles não são os principais contribuintes de tráfego, mas consomem recursos do servidor e são uma causa importante de lentidão no site (IA, Microsoft e Facebook muitas vezes ignoram até o bom senso). China e outros lugares são apenas parte do tráfego malicioso; o verdadeiro problema são empresas americanas que ignoram
robots.txtou limite de taxa em DNS