1 de setembro de 2026, foi lançado o CrowdSec 1.8 — e no WAF open-source, que é instalado no seu servidor com um único helm install, chegaram duas novidades de uma vez: o fingerprinting de navegador e o proof-of-work. Até agora, a parede de PoW era encontrada principalmente em git-forges e arquivos de mailing lists. Agora, essa camada pode estar em qualquer site com quinhentos visitantes por dia.
Vamos entender o que exatamente mudou, por que a detecção foi na direção de "pague com o processador" e — o mais importante — por que o hash nesta construção é o menor dos problemas.
O que aconteceu: PoW desceu dos git-forges para sites comuns
CrowdSec é um sistema self-hosted: o agente lê logs, o WAF fica na frente da aplicação, e os "bouncers" bloqueiam. No lançamento 1.8, a equipe adicionou ao WAF um mecanismo que não responde à pergunta "este IP é ruim?", mas sim à pergunta "este é realmente um navegador com uma pessoa ou um bot que está se passando por um?". A resposta é coletada a partir do fingerprint (características do navegador e assinatura TLS) e do proof-of-work — uma tarefa computacional que o cliente deve resolver antes que o backend veja a solicitação.
A motivação dos autores é clara: o bot médio de 2026 vem com um Chrome verdadeiro, um fingerprint TLS consistente, um IP residente — e sua paciência é maior do que a de um engenheiro de plantão. Este reconhecimento por parte da detecção é mais valioso do que qualquer análise: o endereço residente e um TLS cuidadoso deixaram de ser um sinal distintivo. Como, por reputação de IP e handshake, o bot não se diferencia mais de uma pessoa, a proteção busca um sinal que seja barato para o navegador e caro para o parque de máquinas.
Paralelamente, no Hacker News, surgiram notícias sobre o POWBlock — "proof-of-work microserviço para qualquer servidor". Um lançamento pode ser considerado uma coincidência, mas dois sinais independentes em uma semana já indicam uma tendência.
Como funciona a parede de PoW pelo exemplo do Anubis
O padrão do gênero é o Anubis: um reverse proxy em Go sob licença MIT, escrito por Xe Iaso sob a marca Techaro desde janeiro de 2025. A ideia vem diretamente do hashcash de Adam Back de 1997: o cliente tenta diferentes valores até que o SHA-256 produza um hash com o número necessário de zeros à frente. Se resolver — recebe um cookie JWT assinado (techaro.lol-anubis-auth) e acesso temporário. Se não resolver — o backend não saberá sobre você.
A dificuldade é definida pelo administrador. Por padrão, o Anubis desafia tudo que parece um navegador — ou seja, tudo que tem a string Mozilla no User-Agent. O que cada nível custa é mostrado nas medições:
- Dificuldade 1 — menos de 100 ms.
- Dificuldade 4 (padrão) — cerca de 1,35 s em um Intel Core Ultra 7 165H, isso é aproximadamente 87.600 hashes por segundo no navegador.
- Dificuldade 8 — cerca de 11 s.
- Dificuldade 10 — cerca de 114 s.
A diferença entre o quarto e o décimo nível é de cerca de 84 vezes. A lista de implementações é impressionante: arquivo de mailing list do núcleo Linux e servidor git do núcleo, sourcehut, FFmpeg, GitLab do projeto GNOME, Wine, sourceware.org, FreeCAD, ScummVM, Enlightenment, UNESCO. Na Universidade Duke, um piloto em junho de 2025 bloqueou mais de 4 milhões de solicitações HTTP indesejadas por dia — cerca de 90% do tráfego lixo — e em uma semana, 12 pessoas reclamaram de problemas.
Essas paredes não surgiram por maldade. No Read the Docs, um único crawler baixou 73 TB em um mês; após o bloqueio, o tráfego diário caiu de 800 GB para 200 GB, economizando cerca de 1500 dólares por mês. Drew DeVolt descreveu que a luta contra crawlers consumia de 20 a 100 por cento de algumas semanas. Com o aumento do tráfego automatizado em 23,51% em 2025 e quase um aumento de três vezes no tráfego de IA dentro do ano, os administradores começaram a focar no que funciona rapidamente.
Reviravolta: contra parsing industrial, PoW quase não funciona
E agora a parte desconfortável, que raramente é mencionada em comunicados de imprensa. O proof-of-work depende da assimetria "barato para verificar, caro para resolver". Na web, essa assimetria está invertida.
Um visitante honesto considera hashes como um JavaScript lento no navegador. Aquele que veio em busca de dados os considera como código nativo. Tavis Ormandy escreveu um solucionador em 25 linhas de C: uma tarefa de dificuldade 5 é resolvida em cerca de 0,017 segundos — isso é cerca de 200 vezes mais rápido que o SubtleCrypto do navegador. No GPU, a diferença é ainda maior, cerca de cem vezes ou mais. O resultado da aritmética é simples: para um grande fornecedor, contornar todos os sites Anubis custa quase nada.
Isso não é teoria. O Codeberg já em agosto de 2025 relatou que muitos bots scraper aprenderam a resolver os desafios do Anubis. A parede, no entanto, não se tornou inútil — por vários meses, ela bloqueou a maior parte — mas como barreira para quem está disposto a investir uma noite em um solucionador nativo, ela não se sustenta.
Quem paga a conta, como sempre, é o usuário real. Dificuldade 5 — isso é cerca de 2 segundos em um MacBook novo, dezenas de segundos em um laptop antigo e até dois minutos em um telefone. No GitLab GNOME, foi registrado um caso de meia hora de travamento no Firefox — um desvio, mas indicativo. Além disso, há exceções rigorosas: por padrão, o Anubis exige JavaScript, portanto, leitores de RSS, curl, wget e Lynx simplesmente não funcionam. O projeto está corrigindo isso — na versão 1.20.0, foi adicionado um caminho sem JS através de meta-refresh — mas na 1.22.0 chegou o Proof of React, que, por outro lado, aumentou os requisitos para o navegador.
É importante saber também sobre a sustentabilidade do próprio projeto: cerca de metade do código é comitado por uma única pessoa, e entre os mais de 80 contribuidores, apenas um outro desenvolvedor ultrapassou uma dezena de commits. Além disso, o Anubis integra o serviço pago Thoth para filtragem GeoIP e BGP — ou seja, o projeto open-source tem um vizinho comercial.
Onde PoW realmente dói: a versão comercial é diferente
Aqui se esconde a principal troca de conceitos. Kasada, hCaptcha e Cloudflare Turnstile também usam proof-of-work — mas de maneira bem diferente do Anubis.
No Anubis, o quebra-cabeça é a parede: executou JS, calculou o hash — passou. Um sinal, uma barreira. Nos sistemas comerciais, o PoW funciona como atestado. No Kasada, a tarefa leva alguns milissegundos — tão pouco que como barreira é sem sentido. O sentido está em outra coisa: para resolvê-la, o cliente deve executar uma máquina virtual ofuscada, dentro da qual ocorre a verdadeira detecção. Se calcular o hash sem executar todo o resto — não receberá nada. O hCaptcha sobrepõe o PoW ao veredicto das imagens, aumentando o custo computacional para clientes suspeitos, enquanto o Turnstile considera o PoW como um sinal entre muitos outros sinais do ambiente.
A diferença é fundamental. A parede aberta é quebrada por um solucionador nativo barato. A comercial é quebrada não pelo hash, mas pela necessidade de executar honestamente o código ofuscado de outra pessoa e não ser descoberto no ambiente — e isso é caro, porque a ofuscação é rotacionada regularmente. O CrowdSec 1.8 é interessante exatamente porque traz essa lógica híbrida (fingerprint ao lado do PoW) para o mundo self-hosted, onde antes havia apenas um limite de taxa por IP.
O que isso muda na prática
Se você está coletando dados legalmente — monitorando preços, cuidando da sua marca, realizando pesquisas — as conclusões são bastante concretas.
- O problema não está no hash, mas na camada do navegador. O hash é calculado nativamente em milissegundos. O fingerprint, a VM ofuscada e o ambiente correto não são. A mudança prática: onde antes bastava um cliente HTTP, agora é necessário um verdadeiro motor de navegador. Isso é mais caro em CPU e memória, e deve-se planejar para isso desde o início.
- A economia está mudando de tráfego para tempo e processador. Antes, o custo era calculado em IPs e gigabytes. Agora, adicionam-se segundos por página e carga dos núcleos. É preciso medir não o custo por gigabyte, mas o custo de um registro bem-sucedido — com a parede PoW, essas duas métricas se separam especialmente.
- A sessão se torna um ativo. O Anubis emite um cookie JWT por um tempo. Se você mudar de IP após cada solicitação, estará pagando o imposto PoW novamente em cada página. Sessões persistentes em proxies residenciais oferecem uma vantagem não em "anonimato", mas diretamente em cálculos: uma solução de tarefa se amortiza em dezenas de páginas. A rotação agressiva no mundo PoW se transforma de uma boa prática em um desperdício.
- O solucionador não substitui o comportamento. A mesma lógica pela qual solucionadores de captcha deixaram de resolver a questão: você resolve a tarefa visível, mas o veredicto é baseado em sinais invisíveis ao redor dela.
- Reduza a frequência — isso é mais barato do que qualquer parede. A onda PoW cresceu a partir de histórias como 73 TB em um mês de um único crawler. Cache, solicitações condicionais, intervalos razoáveis e respeito ao robots.txt tiram você do radar antes que o desafio comece. Endereços de data center baratos mais headless na frequência máxima — esse é exatamente o perfil para o qual as paredes são implementadas.
Conclusão
O CrowdSec 1.8 não é o "fim do scraping", e o Anubis também não se tornou isso: um solucionador nativo resolve a tarefa de dificuldade 5 em 0,017 segundos, enquanto uma pessoa real em um telefone antigo espera até dois minutos. A verdadeira novidade é outra. Primeiro, a detecção reconheceu em voz alta que um IP residente e um TLS limpo não provam mais nada. Em segundo lugar, a camada "prove que você é um navegador" deixou de ser um privilégio de grandes plataformas com orçamento para Kasada e se mudou para o open-source, que é instalado em sites comuns.
Deve-se preparar não para uma batalha com hashes, mas para o fato de que o esquema barato "muitos IPs mais um cliente HTTP rápido" irá falhar em alvos cada vez menores. A configuração oposta vence: menos solicitações, um verdadeiro navegador, sessões longas e endereços de qualidade onde é necessário um único acesso confiável, e não mil tentativas baratas.