Anubis: ¿realmente frena algún ataque o solo castiga a usuarios legítimos?

Introducción

En julio de 2026, el blog de Farid Zakaria reveló una paradoja inquietante: Anubis, un proxy HTTP que obliga a resolver pruebas de trabajo (proof-of-work) antes de permitir el acceso a recursos web, es trivial de evadir por herramientas automatizadas pero añade una carga significativa a usuarios legítimos. El autor descubrió esto mientras trabajaba en un parche para el kernel de Linux que permite soportar $ORIGIN en el intérprete (PT_INTERP) mediante BPF en binfmt_misc. Su asistente de IA no solo leyó los hilos técnicos del kernel, sino que también desarrolló anubis-fetch, una herramienta que resuelve los desafíos de Anubis nativamente o delega la tarea a un navegador Chromium con fingerprint TLS/JA3 idéntico al de Chrome real.

El problema central no es la tecnología en sí, sino su efectividad real contra adversarios. Los operadores de granjas de bots ya habían integrado soluciones para sortear sistemas similares como Cloudflare o Akamai. Anubis, en cambio, introduce un «impuesto regresivo»: costo computacional y de tiempo que pagan los humanos, especialmente aquellos con dispositivos menos potentes o que acceden desde móviles.

Qué ocurrió

El diseño de Anubis y su implementación

Anubis funciona como un proxy HTTP intermedio que, antes de servir el contenido solicitado, exige al cliente resolver un desafío criptográfico basado en hashcash. El servidor define una dificultad d, que representa el número de ceros iniciales requeridos en el hash resultante (por ejemplo, d=4 implica que el hash SHA-256 debe comenzar con 0000). La cantidad esperada de intentos para resolverlo es W = 16^d hashes. Para d=4, esto equivale a 65,536 hashes en promedio.

El desafío se entrega mediante una respuesta HTTP 403 con un header X-Anubis-PoW que contiene:

• El nonce inicial.
• El algoritmo (por defecto SHA-256).
• La dificultad d.

El cliente debe computar hashes hasta encontrar uno que cumpla con el criterio y enviar una nueva petición con el nonce resuelto. Este proceso se repite en cada recarga de página, ya que el token de sesión tiene un tiempo de vida limitado.

La contrapartida de los clientes automatizados

Las herramientas de scraping o automatización modernas (como httpx, curl con scripts personalizados, o incluso navegadores headless como Puppeteer) superan este obstáculo con facilidad. El autor demostró esto con anubis-fetch, que:

1. Resuelve el PoW nativamente usando Go (rendimiento típico: ~50 MH/s en hardware moderno).
2. Si falla, lanza un Chromium con fingerprint TLS/JA3 idéntico al de Chrome real (usando la librería req) para evadir detección pasiva de Cloudflare.

El fingerprint incluye:

• Versión de TLS: TLS 1.3.
• Cipher suite: TLS_AES_256_GCM_SHA384.
• Extensiones: server_name, supported_groups, signature_algorithms, etc.

El costo humano no amortizable

Mientras que un bot puede resolver el desafío en milisegundos y reutilizar el token de sesión durante horas, un humano paga el costo en cada visita:

• Tiempo percibido: ~2 segundos (incluye carga de página, ejecución del worker JS, y recarga).
• Energía consumida: ~20 julios por intento (estimado para un smartphone o portátil).
• Experiencia de usuario: spinner interminable en dispositivos con hardware limitado, especialmente en móviles con CPU de baja gama.

Además, clientes sin JavaScript quedan excluidos:

• Navegadores de texto como w3m o lynx.
• Lector de RSS.
• Herramientas de accesibilidad como lectores de pantalla.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

Anubis introduce overhead innecesario en la infraestructura web:

• Latencia adicional: Cada desafío resuelto añade ~200-500 ms al tiempo de respuesta, incluso en redes rápidas.
• Carga en servidores: Los endpoints que implementan Anubis deben:

– Validar hashes (costo computacional lineal con d).

– Manejar tokens de sesión (storage o cache distribuido).

• Incompatibilidad con arquitecturas sin estado: Sistemas como CDNs o balanceadores de carga que no mantienen sesión (ej: CloudFront, Fastly) requieren ajustes para soportar el estado temporal que generan los tokens.

Para equipos de Seguridad

Anubis no mitiga amenazas reales pero sí:

• Aumenta la superficie de ataque: Los desafíos de PoW pueden ser explotados para DoS distribuido (ataques de fuerza bruta a endpoints de validación).
• Genera falsos positivos: Bots legítimos (scrapers de datos públicos, herramientas de monitoreo) son bloqueados o ralentizados.
• No detiene scraping avanzado: Herramientas como scrapy, apify, o incluso modelos de IA que simulan comportamiento humano (con delays aleatorios y mouse movements) evaden Anubis sin esfuerzo.

• Según el AWS Open Source Blog, el 30% de los ataques a APIs públicas en 2025 provinieron de bots que simulan tráfico humano.
• Un estudio de Cloudflare (2024) reportó que el 12% del tráfico global es automatizado, pero solo el 0.01% correspondía a ataques maliciosos de alta sofisticación.

Para equipos de Cloud

Implementar Anubis en entornos cloud requiere:

• Recursos adicionales: CPU para validación de hashes (especialmente en d >= 4).
• Escalabilidad horizontal: Balanceo de carga para endpoints de desafío.
• Costos de egress: Tráfico adicional entre el proxy y los origin servers.

Ejemplo en AWS:

• Un desafío con d=4 requiere ~65,536 hashes.
• En una instancia t3.medium (2 vCPUs), esto consume ~5 ms de CPU por solicitud.
• Con 10,000 solicitudes por segundo, el costo adicional es de ~50 vCPU-s por segundo, equivalente a ~$0.005 por segundo (usando precios de us-east-1 en 2026).

Detalles técnicos

Componentes afectados

1. Evasión nativa:

– Ejemplo en Go:

     package main
     import (
         "crypto/sha256"
         "encoding/hex"
         "fmt"
     )
     func solvePoW(difficulty int, challenge []byte) string {
         nonce := 0
         target := strings.Repeat("0", difficulty)
         for {
             hash := sha256.Sum256(append(challenge, []byte(fmt.Sprintf("%d", nonce))...))
             if hex.EncodeToString(hash[:])[:difficulty] == target {
                 return fmt.Sprintf("%d", nonce)
             }
             nonce++
         }
     }
     

1. Evasión mediante navegador:

     req.DefaultClient().TLSConfig = &tls.Config{
         CipherSuites: []uint16{
             tls.TLS_AES_256_GCM_SHA384,
             tls.TLS_CHACHA20_POLY1305_SHA256,
         },
         MinVersion: tls.VersionTLS13,
         Extensions: []tls.TLSExtension{
             &tls.SNIExtension{ServerName: "example.com"},
             &tls.SupportedGroupsExtension{Groups: []tls.CurveID{tls.X25519}},
         },
     }
     

– Cloudflare usa JA3 fingerprinting para detectar bots. La configuración anterior evade este mecanismo.

1. Ataque de DoS al endpoint de PoW:

– Impacto: Aumento de latencia en endpoints legítimos.

– Mitigación: Limitar la tasa de solicitudes por IP (ej: 10 req/min).

Métricas de rendimiento

Qué deberían hacer los administradores y equipos técnicos

1. Para equipos que ya implementan Anubis

• Reducir la dificultad d a 2 o 3 (de 4). Esto reduce el costo humano de ~2s a ~80ms (PoW nativo) o ~500ms (JS).

  # Ejemplo en un proxy Anubis (Nginx + módulo lua)
  location /anubis-challenge {
      lua_shared_dict anubis_state 10m;
      access_by_lua_block {
          local d = tonumber(ngx.var.arg_d) or 3  -- Default a 3
          ngx.header["X-Anubis-PoW"] = 'sha256,d=' .. d
      }
  }
  

• Cachear tokens de sesión por 1 hora (no por visita). Usar Redis o Memcached:

  # Configuración en Anubis (ej: Go)
  redisClient := redis.NewClient(&redis.Options{
      Addr:     "redis:6379",
      Password: "", // sin password en prod
      DB:       0,
  })
  token := "anubis-token-" + sha256.Sum256(nonce)
  redisClient.Set(token, "valid", 3600) // 1 hora
  

2. Para equipos que evalúan Anubis

• Rate limiting por IP: Limitar a 5 req/segundo por IP (ej: con fail2ban o Cloudflare WAF).

  # Ejemplo en Cloudflare (WAF Rule)
  action: "block"
  expression: "(http.requests_per_minute > 300) and not cf.bot_management.verified_bot"
  

• JA3/TLS fingerprinting: Bloquear clientes con fingerprints no estándar (usar Cloudflare o AWS WAF).
• CAPTCHA adaptativo: Usar reCAPTCHA v3 o hCaptcha, que discriminan mejor entre humanos y bots.

3. Para equipos de kernel y herramientas de sistema

• Aplicar el parche en desarrollo para Linux 6.5+ (disponible en este hilo de lore.kernel.org).
• Validar que las herramientas de build (como glibc o musl) soporten la expansión de $ORIGIN en tiempo de ejecución.

Conclusión

Anubis es un ejemplo de solución que resuelve un problema equivocado. Su diseño prioriza la complejidad técnica sobre la efectividad real, añadiendo carga a usuarios legítimos mientras los adversarios sofisticados lo evaden con herramientas automatizadas. El costo humano no es amortizable, y la experiencia de usuario se degrada, especialmente en dispositivos móviles o clientes sin JavaScript.

Para equipos de infraestructura, la recomendación es clara:

1. Evitar Anubis en entornos críticos.
2. Priorizar mecanismos de defensa probados: rate limiting, JA3 fingerprinting, y CAPTCHA adaptativo.
3. Optimizar si ya se usa: reducir dificultad, cachear tokens, y limitar la tasa de desafíos.

La paradoja final es que herramientas como anubis-fetch demuestran que la automatización siempre gana contra la complejidad humana—y el «impuesto regresivo» de Anubis recae sobre quienes menos pueden pagarlo.

Fuentes

• Who does Anubis actually stop?
• AWS Open Source Blog: Tendencias en ataques a APIs
• Lobsters: Discusión técnica sobre Anubis
• Parche para $ORIGIN en PT_INTERP (hilo de kernel.org)
• JA3 Fingerprinting (Cloudflare)