7 pontos por GN⁺ 2024-04-28 | 1 comentários | Compartilhar no WhatsApp
  • Mesmo só com AWS Lambda e Headless Chrome, foi possível coletar centenas de milhares de Google SERPs por semana, mas diante de sites fortemente protegidos uma arquitetura de bots baseada em nuvem esbarra facilmente em limites
  • Reinvocando Lambdas e usando várias regiões, foi possível usar cerca de 16 * 250 = 4000 IPs públicos ao mesmo tempo em 16 regiões, o que bastava para alvos mais permissivos
  • Empresas de antibot como DataDome, Akamai e Imperva rastreiam inconsistências de configuração do navegador, sinais de automação e informações de fingerprint; o desafio real é menos detectar em si e mais reduzir falsos positivos
  • Como arquitetura menos detectável, propõe-se usar dispositivos Android reais e IPs móveis em vez de Docker ou servidores em nuvem; IPs 4G/5G/LTE são compartilhados por muitos usuários legítimos em grandes cidades, o que dificulta o bloqueio
  • Uma fazenda de dispositivos reais exige compra de aparelhos, aluguel de espaço por cidade, manutenção local e tolerância a falhas de hardware; mesmo emuladores Android ainda mantêm risco de detecção de emulação

Arquitetura de scraping em larga escala com AWS Lambda

  • Quando operava um serviço de scraping no passado, o autor coletava até centenas de milhares de Google SERPs por semana, mas não usava provedores de proxy como Brightdata, Packetstream, Oxylabs
    • Considerava difícil confiar em outros clientes que compartilham a mesma largura de banda de proxy
    • Entendia que scraping não-DoS de informações públicas é aceitável, mas traçava uma linha clara em relação a fraude em anúncios, spam em redes sociais e ataques web como SQL injection automatizado e XSS
    • O custo dos serviços de proxy também pesava
  • A configuração real era uma função em AWS Lambda com Headless Chrome embutido, usando puppeteer-extra e chrome-aws-lambda para rodar o navegador por 300 segundos
  • O Google não bloqueia bots com tanta agressividade no próprio mecanismo de busca e aplica principalmente rate limiting por IP, então, olhando só para Google SERP, talvez até curl bastasse
  • No Lambda, após 3 invocações da função era obtido um novo IP público, e ao invocar 1000 funções simultaneamente chegava-se a cerca de 250 IPs públicos
    • Usando 16 regiões, calculava-se que era possível usar cerca de 4000 IPs públicos ao mesmo tempo
    • Eram IPs compartilhados de datacenter, mas suficientes para coletar centenas de milhares de Google SERPs por semana
  • Google Cloud Platform também foi testado, mas o Google bloqueava tráfego da própria infraestrutura de nuvem com mais força do que tráfego vindo da AWS
  • Essa experiência é baseada em 2019 e 2020, e a situação pode ter mudado depois

Por que bots em nuvem são bloqueados

Uma estrutura econômica que facilita a detecção

  • Desenvolvedores de bots que querem fazer scraping em larga escala muitas vezes colocam navegadores em contêineres Docker e usam Docker Swarm ou Kubernetes para orquestração
  • Esses bots frequentemente são hospedados em provedores de nuvem como Hetzner, AWS e DigitalOcean
  • Essa estrutura é muito diferente do ambiente de um usuário humano
    • Não é natural imaginar um usuário legítimo navegando no Instagram dentro de um contêiner Docker em um VPS da Hetzner
  • Duas regras são apresentadas para scraping bem-sucedido
    • A segunda regra mais importante: não minta sobre as configurações do navegador
    • A regra mais importante: só minta sobre as configurações do navegador quando não for ser pego

Fazenda de dispositivos Android reais

  • Como fazer engenharia reversa de bibliotecas ofuscadas de coleta de fingerprint antibot é difícil, propõe-se usar dispositivos reais para scraping
  • A arquitetura imaginada seria comprar 500 dispositivos Android baratos, misturando aparelhos de cerca de 5 fabricantes para dar diversidade de fingerprint
    • Dispositivos Android baratos começam em 58 dólares por unidade
    • Acredita-se que comprar 100 de uma vez permitiria um grande desconto
  • Cada aparelho receberia um plano de dados barato e seria controlado com DeviceFarmer/stf
  • A ideia é distribuir 100 aparelhos em cada uma de 5 grandes cidades, como London, Paris, Boston, Frankfurt e Los Angeles, alugando espaços de armazenamento baratos próximos a antenas celulares móveis
  • Nos dispositivos seria instalado um Android Go leve, removendo elementos desnecessários e mantendo-os conectados à energia
  • Ativando e desativando o modo avião a cada 5 minutos, seria possível obter um novo IP via 4G Carrier Grade NAT
  • Endereços IP móveis são compartilhados por até centenas de milhares de usuários legítimos em grandes cidades, o que torna o bloqueio difícil na prática
    • Como exemplo, considera-se improvável que o Instagram bloqueie 200 mil pessoas em LA por causa de alguns usuários de spam
    • Cita-se um documento da Ofcom segundo o qual, se um endereço IPv4 em CGN for bloqueado, isso pode afetar toda a base de assinantes
  • Em IPv6, o espaço de endereços é tão grande que a maioria das empresas antibot atribui pouca ou nenhuma reputação de IP a endereços IPv6

Pontos de detecção e custo operacional da estrutura com dispositivos reais

  • Se dispositivos reais forem deixados no chão o dia todo, continuarão sem rotação nem movimento, então eventos JavaScript deviceorientation e devicemotion precisariam ser falsificados no nível do kernel
    • Sites podem acessar dados de rotação e aceleração do Android sem pedir permissão
  • Tirando esse problema, não fica claro como sistemas de detecção de bots poderiam bloquear essa arquitetura
  • A carga operacional não é pequena
    • É preciso comprar 500 dispositivos Android
    • É preciso alugar espaço de armazenamento nas principais cidades, o que tem custo
    • É preciso ter alguém para corrigir problemas na fazenda de dispositivos em 5 cidades
    • É preciso lidar com hardware, e problemas podem surgir continuamente
  • Esse tipo de estrutura vira um grande projeto, e a manutenção pode custar milhares de dólares

Android Emulator como alternativa

  • Considera-se melhor usar Android Emulator em vez de dispositivos Android reais
  • O custo pode cair, mas empresas antibot podem detectar o ambiente de emulação
  • Há várias formas possíveis de detecção
    • Um red pill baseado em navegador pode revelar que o navegador está rodando em ambiente emulado
    • Com browser-based port scanning, é possível procurar portas ou serviços como adb que só rodam em dispositivos Android emulados
    • O Google pode definir um Advertising ID para todo dispositivo móvel, e a ausência desse ID ou um valor sempre igual pode ser sinal suspeito
    • Com Social Media Login Detection, pode-se verificar se há login em contas Gmail ou YouTube; em Android, ausência de login em conta Google pode ser suspeita
    • Além disso, podem existir muitas outras técnicas para detectar dispositivos Android emulados
  • Android Emulator provavelmente é imperfeito, e essa imperfeição pode aparecer por meio da enorme superfície de APIs JavaScript de navegadores móveis
  • Ainda assim, prefere-se a abordagem por emulação, propondo conectar dongles 4G a alguns servidores potentes
  • proxidize.com oferece proxies móveis 4G, mas proxies em si podem ser detectados, então a preferência é usar diretamente os dongles 4G no Android Emulator
  • A arquitetura final seria no formato de estações regionais de scraping
    • Instalar 1 servidor de scraping potente com 50 dongles 4G conectados em uma localização geográfica
    • Executar 50 a 100 dispositivos Android emulados em cada servidor
    • Distribuir essas estações em 5 grandes cidades
    • Um servidor simples de comando e controle orquestraria as 5 estações de scraping

1 comentários

 
GN⁺ 2024-04-28
Comentários do Hacker News
  • Como advogado que trabalha na área de web scraping, sempre dou risada quando vejo threads como esta. Praticamente todas as empresas que hoje vemos como monopólios no setor de tecnologia, ou suas afiliadas, usaram scraping no processo de expansão de seus negócios, e agora essas mesmas empresas proíbem startups e concorrentes de fazer scraping de dados
    Na maioria dos casos, esses dados nem são de fato “deles” em um sentido juridicamente reconhecível. Por isso, nem a ética do web scraping nem as questões jurídicas relacionadas são tão simples assim. Um texto que escrevi sobre isso no outono passado também chamou atenção por aqui: https://news.ycombinator.com/item?id=37264676
    • Com o Facebook e dados de identidade acontece algo parecido. Se não me falha a memória, o Facebook cresceu no início usando os contatos do Google, mas bloqueia agressivamente qualquer pessoa que tente armazenar por longo prazo os dados do grafo social do Facebook e usá-los fora do seu cercadinho
      No fim, é como se impedissem outros de usar as mesmas táticas que eles usaram para crescer
    • A ética do web scraping me parece, na verdade, bem simples. Algo como “você pode responder às minhas requisições HTTP como quiser, e eu posso interpretar essa resposta como quiser” já é suficiente
      Desde que a comunicação humana começou, as conversas não foram sempre assim? Já as questões jurídicas parecem um tecido costurado para proteger operadores estabelecidos com a ameaça de violência estatal; não são nada novas e são patéticas, embora previsíveis. De forma mais ampla, a tentativa de enquadrar isso como questão de propriedade intelectual e vinculá-la à proteção de artistas e criadores também é logicamente muito forçada, a ponto de causar incômodo
  • Eu já fui web scraper profissional e ainda acompanho as tendências do setor. Hoje em dia, não se ganha dinheiro com web scraping em si, mas vendendo serviços para web scrapers
    Há muitos SaaS de web scraping e serviços relacionados, além de dezenas de provedores de proxies residenciais. A maioria dos mecanismos antibot evolui tão rapidamente que, mesmo dentro de funções tradicionais de engenharia de software, dá para ganhar uma renda bem razoável trabalhando exclusivamente com técnicas para contornar antibots. Por causa desse ritmo de mudança, é mais estável trabalhar em uma empresa de web scraping do que fazer web scraping como profissão. Scrapers recebem por projeto e ficam instáveis no longo prazo; scraping avançado exige investimento operacional, como proxies residenciais e aluguel de servidores; e os trabalhos baratos pagam muito pouco. O simples fato de a Brightdata organizar uma conferência de web scraping já mostra como é lucrativa a venda de serviços de scraping em larga escala
    • Há muito tempo penso que proxies residenciais são essenciais para scraping ou para operar redes de bots em grande escala, mas nunca os usei pessoalmente, então não confirmei como são empregados em escala real
      Fico curioso se dispositivos IoT com segurança fraca ou hardware de consumidor infectado por malware são comumente usados para esse fim. A forma de obter IPs residenciais em cooperação com ISPs não parece lucrativa nem viável, então, se for um serviço de proxy residencial, me parece que só pode envolver métodos bem discretos
    • Se houver alguma conferência mais próxima de scraping em geral, gostaria de receber recomendações. Pelo que sei, quase não há conferências dedicadas a scraping nem comunidades fortes, e quero aprender e melhorar minhas habilidades
    • Venho escrevendo scrapers no Upwork há anos, mas cansei de trabalho baseado em projetos e gostaria de trabalhar em um SaaS de scraping ou começar um por conta própria. Gostaria de conselhos
    • No começo, sem saber que isso era tão fácil, publiquei o código como open source. Evitei o GitHub porque achei que lugares como a Akamai enviariam DMCA rapidamente, e aproveitei diferenças de jurisdição para colocá-lo no Gitee, algo parecido com um GitHub chinês
      Eu não tinha experiência nessa área, mas, juntando o que as empresas se gabavam de fazer, não foi difícil, e havia também um objetivo prático de automatizar apostas esportivas. Meu trabalho real também era próximo disso, e isso me ajudou a aprender programação rapidamente no fim dos meus 20 anos. Só que, quase imediatamente, comecei a receber uma enxurrada de pedidos de operadores chineses de bots de tênis e de pessoas que escreviam um inglês peculiar, como se não fossem falantes nativos. Tirei o código do ar não por ameaças legais, mas porque não queria fazer suporte ao cliente nem trabalhar para os outros; a maioria dos pedidos era do tipo “se você trabalhar, dividimos o lucro”, e é difícil acreditar que alguém aceite propostas assim. Como a internet é para sempre, talvez ainda circulem partes do código que imitava Cyberfed-Akamai 0.8~2.3. Se um código que subi em até 3 anos depois de aprender programação, já na metade dos meus 20 anos, funcionou, acho que empresas de cibersegurança que cobram caro por produtos desse tipo deveriam se envergonhar. Eu não estudava matemática desde o segundo ano do ensino médio e, por causa do TDAH, não conseguia acompanhar vídeos nem textos por muito tempo; tudo que fiz foi copiar de serviços parecidos com o GitHub e aprender até funcionar. Imagino que muita solução charlatã esteja sendo vendida nesse setor
    • Fico curioso: como você continua acompanhando as tendências do setor?
  • Tenho sentimentos conflitantes sobre esse problema. Tecnologias antibot estão se tornando um ponto de dor cada vez maior na pesquisa de segurança, e, trabalhando nessa área, preciso lidar com esses sistemas
    Atores de ameaça usam serviços como a Cloudflare para bloquear o acesso a payloads maliciosos. Para clientes que tentam encontrar e detectar falsificação de marca ou phishing de credenciais, isso é um grande problema, mas a Cloudflare não ajuda em nada e simplesmente não se importa
    • Concordo. Ficou fácil demais para atores de ameaça evitarem detecção criando uma conta gratuita da Cloudflare e escondendo um site de phishing em um domínio criado há 2 horas atrás de uma proteção apoiada por uma empresa de US$ 20 bilhões
      É curioso que quase não vemos phishing por trás da Akamai. Nós também trabalhamos nessa área, então temos interesse em continuar conseguindo detectar essas ameaças no futuro
    • Parece que, no fim, vamos chegar a algum tipo de mecanismo de micropagamentos para resolver esse problema
  • As expressões “desajustados” e “pessoas normais” são estranhas. O motivo para fazer esse tipo de trabalho é que ele é muito mais interessante e divertido do que construir pela vigésima vez um site corporativo chato em React
    É divertido porque você precisa resolver problemas do mundo real e encontrar novas maneiras de fazer as coisas. Desenvolvimento de exploits é a mesma coisa. Essas pessoas não são desajustadas; são pessoas normais fazendo algo pelo qual têm paixão. A mentalidade de “quem faz algo de que eu não gosto é desajustado” é que é completamente estranha
    • Aquele parágrafo inteiro é uma piada. É por isso que há uma piscadinha no final
  • Tecnologias antibot também parecem uma ameaça à segurança e uma ameaça à privacidade. Elas bloqueiam o acesso ao site se você usa uma máquina virtual, fazem varredura de portas ou realizam várias formas de fingerprinting
    • Gosto mais da abordagem de desafios algorítmicos, que fazem novos visitantes gastar computação de CPU
      O procedimento é claro, não há riscos de privacidade nem truques estranhos e, se falhar, falha de uma maneira que uma pessoa pelo menos consegue ver e reportar. É melhor do que parecer uma falha desconhecida
  • Isso também foi discutido na época: Scrape like the big boys - https://news.ycombinator.com/item?id=29117022 - novembro de 2021, 189 comentários
  • “Todos os sites conseguem acessar dados de rotação e velocidade do Android sem pedir permissão”? Isso é realmente absurdo
  • Interessante. Estou construindo agora um projeto que precisa de scraping em baixa frequência
    Eu estava pensando em como lidar com rejeições, e talvez um dispositivo Android barato consiga preencher essa lacuna