Puntuación de riesgo de VerifyNuevo

La puntuación de riesgo mira cada reto que emite el borde, en la página del reto de navegador, en el modo bajo ataque y en el widget Verify, y le da una puntuación de 0 a 100. La puntuación sale de señales que la petición ya trae: la red de la que viene, si el navegador que dice ser cuadra y cómo se resolvió la prueba de trabajo. Sin huellas extra ni terceros: consulta Datos tratados.

La puntuación elige un nivel: la prueba de trabajo sola, una más dura, un paso de un clic «Verifica que eres humano» o un bloqueo. En el modo por defecto, log, los niveles solo se cuentan, así que ves en la analítica lo que harían antes de aplicarlos.

La puntuación de riesgo encarece la automatización; no demuestra que el visitante sea humano. Lee los límites antes de confiar en ella.

#Niveles

La puntuación es la suma de los pesos de las señales que saltaron, siempre entre 0 y 100. Cada zona tiene tres umbrales; el nivel es el más alto que alcanza la puntuación.

Cuándo se aplica cada nivel:

• Página del reto. La puntuación se calcula al emitir la página, y ahí se aplican harder, interactive y block. Cuando la solución llega a /__waf/verify se puntúa otra vez con las señales de la resolución; un nivel block responde entonces 403 con {"ok":false,"error":"blocked"} en lugar del pase. Una resolución que solo llega a interactive no se convierte en un clic en ese momento: marca la red, y su siguiente reto empieza con más puntuación.
• Widget Verify. En /start (cuando la caja pide su reto), harder añade trabajo y block lo rechaza. Al comprobar la solución, interactive escala un widget managed al clic (salvo que el visitante ya interactuara con la página) y block la rechaza.

Un umbral 0 desactiva ese nivel. Los umbrales distintos de cero tienen que crecer en el orden harder < interactive < block, y al menos uno tiene que estar activado.

#Señales

Cada señal tiene un peso fijo. Las señales de emisión se evalúan al emitir el reto; las de resolución, al comprobar su solución, junto con las de emisión del mismo reto.

Las señales de tiempo no miran los retos que piden un clic, porque entonces el tiempo lo marca el ritmo del visitante. Los contadores por red y por ASN se guardan en cada nodo de borde unos 10 minutos y no se comparten entre nodos.

Las comprobaciones del navegador se ejecutan en la página del reto y en el widget; cada una es un sí o un no que no sale de la página de ninguna otra forma. Su respuesta se codifica distinta en cada reto, así que una respuesta grabada no vale para otro, y las funciones que inspeccionan cambian de un reto a otro. Su total se limita al umbral interactivo salvo que también salte una señal del servidor: por sí solas pueden pedir un clic, nunca bloquear. El nombre cdp_input está reservado y nunca salta.

#Pilas TLS

El borde calcula la huella JA4 (enlace externo) de cada conexión TLS que termina, a partir del ClientHello. JA4 cambia con cada versión del navegador, así que tls_mismatch no compara cadenas JA4 exactas. Comprueba que el ClientHello ofrece TLS 1.3 con h2 como primer valor de ALPN y que tiene los rasgos estables del navegador que nombra el User-Agent:

Los navegadores más antiguos mantienen una comprobación más gruesa: TLS 1.3 y h2 (Chromium 70+, Firefox 70+, Safari 14+), y GREASE para Chromium 70–99.

Por ejemplo, Chrome 156 envía t13d1518h2_8daaf6152771_e2d80978ab2e, curl envía t13d4907h2_… y requests de Python envía t13d1712h1_…. Así se detecta un Chromium automatizado cuyo User-Agent dice ser Safari o Firefox, y un script que copia el User-Agent de un navegador. Una herramienta de automatización basada en Firefox con User-Agent de Firefox tiene el TLS de Firefox, así que no salta.

#Private Access Tokens

Un Private Access Token (RFC 9577 (enlace externo)) permite a un dispositivo demostrar que pasó las comprobaciones de su fabricante (en los de Apple, un dispositivo auténtico con una cuenta iniciada) sin decir quién es. Con el scoring de riesgo activo y al menos un emisor de tokens de confianza, la página del reto y el widget piden al borde un reto de token ligado a ese reto y al host del sitio. Un dispositivo compatible responde con un token, que el borde comprueba sin conexión con la clave pública del emisor. Un token válido suma pat_valid al resolver el reto.

El token no lleva identidad y no se puede relacionar con otras visitas del visitante; el borde lo comprueba y lo descarta, y la analítica solo cuenta pat_valid como señal. Los dispositivos sin tokens no pierden nada: su puntuación es la misma que sin esta función.

Estado: no activado. No hay ningún emisor configurado, porque emitir tokens que los dispositivos de Apple acepten para OpenWAF necesita un acuerdo con uno de esos emisores. Hasta entonces el borde nunca pide un token y pat_valid nunca salta.

#Modo y umbrales

La puntuación de riesgo es el objeto challenge.risk de la zona. Se aplica a todos los nombres de la zona; un nombre no puede cambiarla (hosts.<name>.challenge.risk se rechaza).

Los campos se fusionan uno a uno: los umbrales que no envías conservan su valor, y "risk": null vuelve a los valores por defecto. GET …/edge muestra siempre el objeto efectivo. Cada cambio queda versionado, necesita un motivo y se puede revertir.

openwaf-cloud ctl zones set example.com challenge.risk.mode=enforce challenge.risk.thresholds.block=95 \
  --reason "Aplicar la puntuación de riesgo"
openwaf-cloud ctl zones set example.com challenge.risk:=null --reason "Puntuación de riesgo por defecto"

curl -s -X PATCH https://dash.openwaf.dev/v1/orgs/$ORG/zones/$ZONE/edge \
  -H "Authorization: Bearer $OPENWAF_TOKEN" \
  -H "Content-Type: application/json" \
  -H "X-Change-Reason: Aplicar la puntuación de riesgo" \
  -d '{"challenge": {"risk": {"mode": "enforce", "thresholds": {"block": 95}}}}'

#De log a enforce

1. Déjala en modo log (el de por defecto) unos días de tráfico normal, y durante un ataque si puedes.
2. Lee el informe (abajo): cuántos retos caerían en cada nivel, la distribución de puntuaciones y las señales que más saltan. Fíjate en la parte de interactive y block: esos visitantes recibirían un clic o un 403.
3. Ajusta los umbrales si una señal que provocan tus visitantes reales (por ejemplo asn_hosting en un público B2B con VPN corporativas o escritorios en la nube) sube a demasiados. Subir un umbral, o poner harder o interactive a 0, es más seguro que desactivar la puntuación.
4. Pasa a enforce y sigue mirando el informe: en modo enforce, escalated y blocked cuentan lo aplicado.

#Analítica

Dominio → Seguridad → Verificación muestra, en la sección Riesgo de la actividad, el modo y los umbrales, los retos puntuados, el reparto por nivel, la distribución de puntuaciones, cuántos tuvieron que hacer clic tras resolver y cuántos se bloquearon, y las señales que más saltaron. En modo log indica que solo se registra y no se aplica nada, y los recuentos son lo que habría hecho enforce.

Los mismos datos están en el objeto risk de GET /v1/orgs/{org}/zones/{zone}/challenge/analytics?days=7, de openwaf-cloud ctl challenge report example.com --days 7 (líneas Riesgo, Niveles, un histograma de puntuaciones y Señales) y de la herramienta MCP challenge_report:

"risk": {
  "mode": "log",
  "thresholds": {"harder": 30, "interactive": 60, "block": 90},
  "evaluated": 1230,
  "levels": {"pass": 1100, "harder": 90, "interactive": 32, "block": 8},
  "scores": [900, 120, 80, 50, 30, 20, 15, 7, 0, 5, 3],
  "top_signals": [{"signal": "asn_hosting", "count": 140}, {"signal": "headers_missing", "count": 60}],
  "escalated": 4,
  "blocked": 8
}

Cada fila de la tabla por origen (gate, rate_rule, under_attack, cada widget…) lleva sus propios risk_levels. La analítica conserva los agregados 30 días.

#Lo que nunca se puntúa

La puntuación de riesgo solo puntúa retos que el borde iba a emitir de todos modos; nunca reta una petición por sí misma. Las peticiones que se saltan el reto se saltan también la puntuación:

• direcciones y redes con una regla allow de IP o ASN;
• rastreadores verificados (verificación de bots);
• las exempt_paths del modo bajo ataque y las rutas /__waf/ del propio borde;
• las peticiones que no son navegaciones del navegador: reciben la respuesta habitual, no un reto;
• los visitantes que ya tienen un pase válido.

El modo bajo ataque se puntúa como cualquier otro reto. Su propio clic (interactive, activado por defecto) no depende de la puntuación; en modo enforce una puntuación alta puede igualmente endurecer el trabajo o bloquear.

#Datos tratados

Lo que lee el motor de riesgo, todo ello ya presente en la petición o en la resolución:

• La dirección del cliente, para buscar su ASN, las listas de amenazas y la reputación, en la memoria del nodo de borde.
• La huella JA4 del ClientHello TLS de la conexión (ver Pilas TLS). El borde lee el ClientHello una vez para calcularla y descarta los bytes originales.
• Cabeceras de baja entropía que envía todo navegador: User-Agent, Accept-Language, Sec-Fetch-Mode, Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform.
• Un Private Access Token, solo si el dispositivo lo ofrece y la función está activada (aún no lo está). Se comprueba y se descarta.
• navigator.webdriver, que el widget Verify ya enviaba.
• La respuesta de las comprobaciones del navegador: un sí o un no por comprobación, codificado para el reto. La página compara, sin enviarlos: si el runtime de JavaScript se está serializando para un depurador, si unas pocas funciones propias del navegador siguen siendo las suyas, los tamaños de la ventana y de la pantalla, el user agent, la plataforma, los idiomas y los núcleos del Web Worker frente a los de la página y, en la casilla, en qué punto cayó la pulsación y cuánto tiempo se mantuvo la tecla.
• El tiempo de la prueba de trabajo: cuándo se emitió el reto, cuándo llegó la solución y el trabajo que supone.

Lo que guarda: contadores por red (con un hash de la /24 IPv4 o la /64 IPv6 como clave) y por ASN, unos 10 minutos en la memoria del nodo de borde. La analítica recibe solo niveles, tramos de puntuación y nombres de señal, por sitio y por minuto, sin ninguna dirección IP; se conservan 30 días. Los eventos de seguridad de una petición guardan su cadena JA4 en tls_fingerprint (vacía cuando otro proxy terminó TLS, o en HTTP sin cifrar), nunca el ClientHello original.

Lo que nunca recoge: huellas de canvas, WebGL, audio o fuentes, plugins ni client hints de alta entropía. El borde nunca envía Accept-CH para pedir más hints.

Todo lo que trata Verify, cuánto tiempo y dónde, los papeles según el contrato de encargo y un párrafo para tu política de privacidad: Datos que trata OpenWAF Verify (enlace externo) (borrador pendiente de revisión legal).

#Límites

• Coste, no prueba. La puntuación de riesgo hace la automatización más lenta y más cara. Una automatización que maneja un navegador real a través del sistema operativo o del protocolo DevTools, desde direcciones residenciales o móviles, envía las mismas cabeceras y el mismo TLS que una persona y puede pasar igual. Las comprobaciones del navegador cazan el comportamiento por defecto de los frameworks habituales; uno ajustado para imitar la entrada de una persona, o la entrada inyectada por el sistema operativo, las pasa.
• Las comprobaciones del navegador son pistas. Un visitante con las DevTools abiertas, o que usa control por voz o acceso por interruptor que pulsa en el centro exacto de la casilla, puede hacer saltar una; por eso nunca bloquean solas.
• Comprobación TLS. tls_mismatch usa la huella JA4 y rasgos estables de la pila TLS de cada navegador, no una lista de huellas exactas, así que una herramienta que reproduce exactamente el TLS de un navegador la pasa. No se evalúa cuando hay otro proxy que termina TLS delante del borde, porque entonces el handshake es del proxy.
• Hosting o no. La lista de ASN solo distingue redes de hosting y centros de datos del resto; no hay clasificación de redes móviles ni residenciales.
• Memoria por nodo. Los contadores por red y por ASN viven en cada nodo de borde unos 10 minutos, así que el tráfico repartido entre varios nodos los acumula más despacio.
• Sin clic tras la resolución de la página. En la página del reto, interactive se aplica al emitirla; la puntuación de la resolución solo puede bloquear o marcar la red para su siguiente reto.
• Siteverify sin cambios. Siteverify sigue respondiendo metadata.risk como low, o high cuando se pidió interacción; no lleva la puntuación ni las señales.
• El modo log no aplica nada. En modo log los niveles solo aparecen en la analítica.