El 1 de septiembre de 2026 se lanzó CrowdSec 1.8, y en el WAF de código abierto, que se instala en su servidor con un solo helm install, llegaron dos cosas a la vez: el fingerprinting del navegador y el proof-of-work. Hasta ahora, el muro de PoW se había encontrado principalmente en forjas de git y archivos de listas de correo. Ahora, tal capa puede estar en cualquier sitio con quinientos visitantes al día.
Analicemos qué ha cambiado exactamente, por qué la detección se ha ido hacia el "paga con tu procesador", y — lo más importante — por qué el hash en esta construcción es el menor de los problemas.
Qué sucedió: PoW bajó de las forjas de git a sitios comunes
CrowdSec es un sistema autoalojado: el agente lee los registros, el WAF está frente a la aplicación, y los "bounceers" bloquean. En la versión 1.8, el equipo añadió al WAF un mecanismo que no responde a la pregunta "¿es esta IP mala?", sino a la pregunta "¿es este realmente un navegador con una persona o un bot que se hace pasar por uno?". La respuesta se recopila del fingerprint (características del navegador y firma TLS) y del proof-of-work — una tarea computacional que el cliente debe resolver antes de que el backend vea la solicitud.
La motivación que los autores plantean sin diplomacia: el bot promedio de 2026 llega con un Chrome real, un fingerprint TLS consistente, una IP residente — y tiene más paciencia que un ingeniero de guardia. Este reconocimiento por parte de la detección vale más que cualquier análisis: la dirección residente y un TLS limpio han dejado de ser un signo diferenciador. Como el bot ya no se diferencia de una persona por la reputación de la IP y el apretón de manos, la protección busca un signo que sea barato para el navegador y caro para el parque de máquinas.
Paralelamente, en Hacker News, en esos mismos días apareció POWBlock — "un microservicio de proof-of-work para cualquier servidor". Un lanzamiento puede atribuirse a una coincidencia, pero dos señales independientes en una semana ya son una dirección.
Cómo está estructurado el muro de PoW con el ejemplo de Anubis
El estándar del género es Anubis: un proxy inverso en Go bajo licencia MIT, escrito por Xe Iaso bajo la marca Techaro desde enero de 2025. La idea proviene directamente del hashcash de Adam Back de 1997: el cliente prueba valores hasta que SHA-256 da un hash con el número requerido de ceros a la izquierda. Si lo resuelve, obtiene una cookie JWT firmada (techaro.lol-anubis-auth) y acceso temporal. Si no lo resuelve, el backend no sabrá de ti.
La dificultad es establecida por el administrador. Por defecto, Anubis desafía todo lo que parece un navegador, es decir, todo lo que tiene en el User-Agent la cadena Mozilla. Lo que cuesta cada nivel se muestra en las mediciones:
- Dificultad 1 — menos de 100 ms.
- Dificultad 4 (por defecto) — alrededor de 1,35 s en un Intel Core Ultra 7 165H, esto es aproximadamente 87,600 hashes por segundo en el navegador.
- Dificultad 8 — alrededor de 11 s.
- Dificultad 10 — alrededor de 114 s.
La diferencia entre el cuarto y el décimo nivel es aproximadamente 84 veces. La lista de quienes lo han implementado es impresionante: el archivo de la lista de correo del núcleo de Linux y el servidor git del núcleo, sourcehut, FFmpeg, GitLab del proyecto GNOME, Wine, sourceware.org, FreeCAD, ScummVM, Enlightenment, UNESCO. En la universidad de Duke, un piloto en junio de 2025 bloqueó más de 4 millones de solicitudes HTTP no deseadas al día — alrededor del 90% del tráfico basura — y en una semana, 12 personas se quejaron de problemas.
Estos muros no aparecieron por malicia. En Read the Docs, un solo crawler descargó 73 TB en un mes; después del bloqueo, el tráfico diario cayó de 800 GB a 200 GB, ahorrando alrededor de 1500 dólares al mes. Drew DeVolt describió que la lucha contra los crawlers le consumía entre el 20 y el 100 por ciento de algunas semanas. En el contexto de un aumento del tráfico automatizado del 23.51% para 2025 y casi un aumento de tres veces en el tráfico de IA dentro del año, los administradores comenzaron a trabajar en lo que funciona rápido.
Giro: contra el scraping industrial, PoW casi no funciona
Y ahora la parte incómoda, que rara vez se menciona en los comunicados de prensa. El proof-of-work se basa en la asimetría "barato de verificar, caro de resolver". En la web, esta asimetría está invertida.
Un visitante honesto considera los hashes como un JavaScript lento en el navegador. Quien viene por datos, los considera como código nativo. Tavis Ormandy escribió un solucionador en 25 líneas de C: una tarea de dificultad 5 se resuelve en aproximadamente 0.017 segundos — esto es aproximadamente 200 veces más rápido que el SubtleCrypto del navegador. En GPU, la brecha es aún mayor, del orden de cien veces o más. La conclusión aritmética es simple: para un gran vendedor, eludir todos los sitios de Anubis cuesta casi nada.
No es teoría. Codeberg ya en agosto de 2025 informó que muchos bots scraper aprendieron a resolver los desafíos de Anubis. El muro, sin embargo, no se volvió inútil — durante varios meses bloqueó la mayor parte — pero como barrera para aquellos dispuestos a invertir una noche en un solucionador nativo, no se sostiene.
Como siempre, el que paga la cuenta es el usuario real. La dificultad 5 significa alrededor de 2 segundos en un MacBook nuevo, decenas de segundos en un viejo portátil y hasta dos minutos en un teléfono. En GitLab GNOME se registró un caso de media hora de bloqueo en Firefox — un caso extremo, pero significativo. Además, hay excepciones estrictas: por defecto, Anubis requiere JavaScript, por lo que lectores RSS, curl, wget y Lynx simplemente no funcionan. El proyecto está corrigiendo esto — en la versión 1.20.0 se introdujo un camino sin JS a través de meta-refresh, — pero en la 1.22.0 llegó Proof of React, que, por el contrario, aumentó los requisitos para el navegador.
También es importante conocer la sostenibilidad del proyecto mismo: alrededor de la mitad del código es comprometido por una sola persona, y entre más de 80 contribuyentes, solo un desarrollador más ha superado la decena de commits. Además, Anubis integra el servicio de pago Thoth para filtrado GeoIP y BGP — es decir, el proyecto abierto tiene un vecino comercial.
Dónde PoW realmente muerde: la versión comercial está estructurada de manera diferente
Aquí es donde se esconde la principal confusión de conceptos. Kasada, hCaptcha y Cloudflare Turnstile también utilizan proof-of-work — pero de una manera muy diferente a Anubis.
En Anubis, el rompecabezas es el muro: ejecutaste JS, calculaste el hash — pasaste. Una señal, una barrera. En los sistemas comerciales, PoW funciona como certificación. En Kasada, la tarea toma un par de milisegundos — tan poco que como barrera es inútil. El sentido está en otra parte: para resolverla, el cliente debe ejecutar una máquina virtual ofuscada, dentro de la cual ocurre la verdadera detección. Si calculas el hash sin realizar todo lo demás, no obtendrás nada. hCaptcha superpone PoW sobre el veredicto de las imágenes, aumentando el costo computacional para los clientes sospechosos, Turnstile considera PoW como una señal entre muchas pruebas del entorno.
La diferencia es fundamental. Un muro abierto es vulnerado por un solucionador nativo barato. Un muro comercial es vulnerado no por el hash, sino por la necesidad de ejecutar honestamente el código ofuscado ajeno y no ser descubierto en el entorno — y esto es caro, porque la ofuscación se rota regularmente. CrowdSec 1.8 es interesante precisamente porque lleva un híbrido de esta lógica (fingerprint junto a PoW) al mundo autoalojado, donde antes solo existía un límite de tasa por IP.
Qué cambia en la práctica
Si recopilas datos legalmente — monitoreas precios, sigues tu marca, realizas investigaciones — las conclusiones son bastante concretas.
- El problema no está en el hash, sino en la capa del navegador. El hash se calcula de forma nativa en milisegundos. No se calcula el fingerprint, la VM ofuscada y el entorno correcto. El cambio práctico: donde antes bastaba un cliente HTTP, ahora se necesita un motor de navegador real. Esto es más caro en CPU y memoria, y hay que planificar desde el principio para esto.
- La economía se traslada del tráfico al tiempo y al procesador. Antes, el costo se calculaba en IP y gigabytes. Ahora, se suman segundos por página y carga de núcleos. Hay que medir no el precio por gigabyte, sino la costo de un registro exitoso — con el muro de PoW, estas dos métricas se separan especialmente.
- La sesión se convierte en un activo. Anubis emite una cookie JWT por tiempo. Si cambias de IP después de cada solicitud, pagas el impuesto de PoW de nuevo en cada página. Las sesiones pegajosas en proxies residenciales aquí ofrecen una ventaja no en "anonimato", sino directamente en cálculos: una solución de tarea se amortiza en decenas de páginas. La rotación agresiva en el mundo de PoW se convierte de buena práctica en sobreconsumo.
- El solucionador no reemplaza el comportamiento. La misma lógica por la cual los solucionadores de captcha dejaron de resolver el problema: resuelves la tarea visible, pero el veredicto se emite por señales invisibles a su alrededor.
- Reduce la frecuencia — es más barato que cualquier muro. La ola de PoW surgió de historias como 73 TB en un mes de un solo crawler. Cache, solicitudes condicionales, intervalos razonables y respeto por robots.txt te sacan del radar antes de que se active el desafío. Direcciones de centro de datos baratas más headless a la máxima frecuencia — ese es el perfil por el cual se instalan los muros.
Conclusión
CrowdSec 1.8 no es el "fin del scraping", y Anubis tampoco lo es: un solucionador nativo cierra una tarea de dificultad 5 en 0.017 segundos, mientras que un ser humano en un viejo teléfono espera hasta dos minutos. La verdadera noticia es otra. Primero, la detección ha reconocido en voz alta que la IP residente y un TLS limpio ya no demuestran nada. En segundo lugar, la capa "demuestra que eres un navegador" ha dejado de ser un privilegio de grandes plataformas con presupuesto para Kasada y se ha trasladado al open-source, que se instala en sitios comunes.
Hay que prepararse no para una batalla con hashes, sino para que el esquema barato "muchas IP más un cliente HTTP rápido" se desmorone en objetivos cada vez más pequeños. Gana la configuración opuesta: menos solicitudes, un navegador real, sesiones largas y direcciones de calidad donde se necesita un paso confiable, no mil intentos baratos.