AWS WAF Bot Control: qué ve el cliente

Un grupo de reglas gestionado es un motor de decisión, y la pregunta útil no es si se activó sino qué recibió. BotBrowser proporciona un perfil declarado que mantiene coherentes entre sí las superficies que una página puede leer, y no cambia lo que un grupo de reglas decide en el perímetro. La estructura importa más que una puntuación: dos niveles de protección que inspeccionan cosas distintas, un mecanismo de etiquetas que permite que una regla alimente a la siguiente y un conjunto de acciones donde un bloqueo y un Challenge producen respuestas visiblemente distintas.

Resumen

• Bot Control es un solo grupo de reglas gestionado con dos niveles de protección, common y targeted, y activar solo el nivel common deja fuera las comprobaciones de comportamiento.
• El nivel common detecta los bots que se identifican a sí mismos mediante análisis estático de los datos de la solicitud; el nivel targeted incluye common y añade detección para los que no se identifican.
• Una regla coincidente puede adjuntar una etiqueta, y las reglas posteriores pueden coincidir con esa etiqueta, lo que hace que el lenguaje de reglas sea componible en lugar de una sola puntuación.
• Block y Challenge son acciones distintas: una termina la solicitud y la otra pide al cliente ejecutar un script y reintentar.
• Una solicitud medida sin user agent devolvió 403 con un cuerpo HTML de 919 bytes y sin script de desafío, lo que corresponde a un bloqueo y no a un Challenge.
• El mismo endpoint devolvió 200 con un user agent de navegador, así que la diferencia en esa medición estaba en la solicitud, no en la ruta.
• Las etiquetas son la parte que más equipos pasan por alto, porque un panel que muestra "bloqueado" no dice qué grupo de reglas ni qué etiqueta produjo la decisión.
• Un perfil del lado de la página puede mantener coherentes sus propias superficies y no puede hacer que una decisión del perímetro tenga éxito.

Contenido

• Un grupo de reglas, dos niveles de protección
• Las etiquetas son el lenguaje de reglas
• Un bloqueo medido y las acciones que separa
• Lo que el grupo de reglas no puede ver y la conclusión práctica

Un grupo de reglas, dos niveles de protección

Lo primero que conviene fijar es que Bot Control no es una sola cosa. Tiene dos niveles de protección dentro de un solo grupo de reglas gestionado: el nivel common se ejecuta por defecto, y el nivel targeted es una opción que añade detección para clientes que no se identifican. Un equipo que activa el más barato y lee su panel ha cubierto una parte real del problema, no el problema completo.

El nivel common detecta bots que se identifican a sí mismos mediante técnicas tradicionales como el análisis estático de los datos de la solicitud; en los términos de la documentación, etiqueta bots autoidentificados, verifica los deseables como los buscadores y detecta firmas de alta confianza. Son comprobaciones que pueden calcularse sin pedir nada al cliente, por eso se ejecutan primero y por eso atrapan la automatización menos cuidadosa.

El nivel targeted incluye las protecciones de common y añade detección para bots sofisticados que no se identifican, mitigando con limitación de tasa, CAPTCHA y desafíos de navegador en segundo plano, y usando interrogación del navegador, huellas y heurísticas de comportamiento. Esa diferencia es la práctica para un trabajo de datos: un cliente que satisface Common todavía puede fallar en Targeted, y ambos fallos se ven iguales en un código de estado.

Leer los dos juntos cambia lo que significa un número de "bloqueos". Un bloqueo atribuido a Common es una afirmación sobre la solicitud. Un bloqueo atribuido a Targeted es una afirmación sobre la sesión, lo que significa que la misma solicitud enviada una vez puede pasar y enviada repetidamente puede no pasar. Sin el nombre del grupo de reglas, un informe no distingue esas dos situaciones, y la respuesta a cada una es distinta.

Las etiquetas son el lenguaje de reglas

Esta es la diferencia estructural que separa AWS WAF de un producto basado en puntuaciones, y es la parte que recompensa el estudio. Cuando una regla coincide, puede adjuntar una etiqueta a la solicitud. Las reglas posteriores de la misma web ACL pueden coincidir con esa etiqueta como si fuera una entrada.

rule A matches   -> label aws:bot:category:http_library attached
                    (namespaced by the service, e.g. awswaf:managed:aws:bot-control:bot:category:http_library)
rule B reads     -> if label present, apply its own action
rule C reads     -> combine two labels into a narrower decision

Esa composición es lo que hace expresivo al lenguaje. Una puntuación reduce todas las observaciones a un número, y un número no puede decir qué dos comprobaciones coincidieron. Un conjunto de etiquetas sí puede, porque cada etiqueta conserva su nombre y su origen, y una regla que lee dos etiquetas enuncia una conjunción y no un corte.

La consecuencia operativa es que la etiqueta es la unidad que conviene registrar. Un panel que informa solo la acción final pierde el motivo, y un equipo que depura un falso positivo tiene que cambiar el cliente para averiguar qué regla se activó. Registrar las etiquetas presentes en una solicitud bloqueada responde esa pregunta directamente y cuesta una cabecera en el registro.

Las etiquetas también explican un comportamiento que parece inconsistente desde fuera. Dos solicitudes con la misma ruta y las mismas cabeceras pueden recibir acciones distintas cuando una regla anterior coincidió con algo que la segunda solicitud no llevaba, y la diferencia es una etiqueta y no un cambio en el endpoint.

El conjunto de acciones es donde una lectura del lado del cliente suele equivocarse, porque ambos resultados parecen "no funcionó" en un registro que solo guarda éxito o fallo.

Block      -> 403 by default; the client receives an error response
Challenge  -> 202; the client receives a script, runs it, retries with a token
CAPTCHA    -> 405; the client receives a page a person is expected to complete

Solo la acción intermedia espera que el cliente ejecute código. Un cliente que trata todo lo que no es 200 como un bloqueo reintentará un Challenge para siempre, porque el reintento nunca lleva el token que el Challenge pedía. Un cliente que trata todo lo que no es 200 como un Challenge ejecutará un script que no existe, porque el cuerpo es una página de error y no un Challenge.

La distinción se ve en la respuesta antes de cualquier análisis. Un Challenge lleva un script que el cliente debe ejecutar; un bloqueo lleva un documento de error. Buscar el script es una prueba más barata que comparar un código de estado, porque el código de estado de un Challenge y el de un bloqueo pueden ser el mismo.

Un bloqueo medido y las acciones que separa

La afirmación de que son distintos es fácil de sostener, así que se registró una solicitud. Un cliente HTTPS simple pidió una página de documentación sin cabecera user agent, y después el mismo cliente pidió la misma página con un user agent de navegador.

no_ua:        status=403 bytes=919  challenge_marker=false block_marker=true
              server=CloudFront content-type=text/html
browser_ua:   status=200 bytes=18804
              server=Server content-type=text/html

Tres cosas de esa salida merecen nombre. La primera es el estado, que es un error simple y no un intercambio de Challenge. La segunda es la longitud del cuerpo, suficientemente corta para ser un documento de error y demasiado corta para ser una página con la que un cliente deba interactuar. La tercera es el escaneo de marcadores, que no encontró ningún script de Challenge en la respuesta.

La cuarta cosa es la comparación. El mismo cliente, la misma ruta y el mismo segundo del día devolvieron una página completa cuando la solicitud llevaba un user agent de navegador. No es prueba de que se activara una regla, porque el endpoint podría estar haciendo algo completamente distinto; demuestra que la diferencia entre las dos solicitudes estaba en la solicitud, y que un cliente puede cambiar una y no la otra.

Un bloqueo tampoco dice al cliente qué regla lo produjo. Es intencional: la respuesta no lleva la identidad de la regla, el conjunto de etiquetas ni el grupo de reglas. La información existe en los registros del proveedor y en la consola, por eso el diagnóstico tiene que trasladarse allí en lugar de quedarse en el cliente.

El límite es el mismo que se aplica a toda decisión del perímetro, y conviene enunciarlo con los términos de este producto. Un grupo de reglas lee lo que llega: la línea de solicitud, las cabeceras, el origen, el patrón de solicitudes en el tiempo y los parámetros de conexión que el perímetro puede observar.

No lee el documento. Un valor que solo existe después de ejecutar JavaScript, como un hash de canvas, una cadena de renderizador WebGL o una medición de diseño calculada, no es una entrada para una regla que se ejecuta antes de enviar la respuesta. No es una limitación elegida por el proveedor; es el orden de las operaciones. El perímetro decide antes de que exista la página.

Ese orden tiene una consecuencia práctica para un trabajo de datos. Un cliente que produce un documento perfectamente coherente todavía tiene que satisfacer las comprobaciones anteriores, y esas comprobaciones se refieren a la solicitud y no al renderizado. A la inversa, un cliente que satisface todas las comprobaciones de solicitud no ha dicho nada sobre si su documento se vería coherente, porque el grupo de reglas nunca lo preguntó.

Las dos capas no son, por tanto, una sola puntuación con un corte. Son dos preguntas hechas en momentos distintos, y un informe que las fusiona no puede decir cuál se respondió. Registrar la acción del perímetro junto al resultado del lado de la página las mantiene separables, y eso es lo que hace posible una investigación posterior.

Una tercera medición afina la distinción entre bloqueo y Challenge, porque el mismo endpoint respondió a tres solicitudes con formas distintas de tres maneras diferentes:

clean_get:    status=200 bytes=18804 challenge_marker=false block_marker=false
no_ua:        status=403 bytes=919   challenge_marker=false block_marker=true
scripted_post: status=403 bytes=1053 challenge_marker=false block_marker=true

Dos de esas respuestas son bloqueos y una es un éxito, y los dos bloqueos difieren en longitud de cuerpo en ciento treinta y cuatro bytes. La diferencia es lo bastante pequeña para que un lector que solo registra el código de estado vea un evento, mientras que un lector que registra la longitud y el escaneo de marcadores ve dos. Ningún bloqueo llevaba un script de Challenge, lo que hace que ambos sean terminales: no hay nada que un cliente pueda ejecutar, así que reintentar la misma solicitud produce la misma respuesta.

El conjunto de cabeceras añade una segunda lectura. La respuesta correcta informó server=Server, y ambos bloqueos informaron server=CloudFront. No es una identidad de regla y no nombra el grupo de reglas, pero dice al lector qué capa respondió, y separa un bloqueo generado delante de la aplicación de una respuesta producida por la aplicación.

Lo que un lector no debe concluir es que el user agent sea la entrada decisiva. Fue la variable que cambió en la primera comparación, y bastó para mover un endpoint de un error a una página completa. Si basta en otro lugar es una pregunta sobre la configuración de ese endpoint, y la única forma honesta de responderla es registrar los mismos tres campos en el sitio en cuestión en lugar de generalizar desde este caso.

Hay una lección de segundo orden en los números. Una respuesta de 919 bytes y otra de 18804 bytes difieren en un factor de veinte, y una canalización que solo guarda el estado las trata como la misma clase de evento cuando una es un documento de error y la otra es una página. Guardar la longitud cuesta casi nada y separa ambas de inmediato, por eso pertenece al registro junto al estado y no a una sesión de depuración aparte.

El grupo de reglas también tiene una dimensión temporal que una sola solicitud no puede mostrar. Las comprobaciones de comportamiento observan varias solicitudes, así que un cliente que envía una y lee la respuesta ha medido la parte más barata del sistema. Un trabajo que envía miles ejercita la parte que se acumula, y un informe construido con solicitudes individuales no puede describirla. No es una laguna en la documentación del proveedor; es una laguna en lo que una observación puede sostener.

Lo que el grupo de reglas no puede ver y la conclusión práctica

Lee la acción antes de cambiar el cliente. Un 403 con un cuerpo corto es un Block y necesita la consola para explicarse; una respuesta con un script de Challenge es un Challenge y necesita un cliente capaz de ejecutarlo. Nombra el grupo de reglas en el registro, porque Common y Targeted fallan por motivos distintos y el mismo código de estado cubre ambos. Conserva las etiquetas, ya que son el único campo que dice qué regla coincidió con cuál otra, y un resumen basado en puntuaciones lo descarta. Para el proveedor que compone de otra manera, lee Cloudflare y DataDome: qué ve un scraper; para saber qué reglas necesitan un valor que nunca llega a la página, lee reglas de perímetro que un script de página no puede evaluar.

Un perfil declarado puede mantener coherentes entre sí los valores que una página expone, y no decide lo que devuelve un grupo de reglas gestionado. La decisión pertenece al endpoint, y el trabajo útil del lado del cliente es hacer el registro lo bastante preciso para explicar la decisión después.

El mecanismo de etiquetas merece otro párrafo, porque cambia lo que se puede pedir a un informe que demuestre. Una sola puntuación es un resumen: descarta las observaciones individuales y conserva un número, y un lector que discrepa del número no tiene nada más que examinar. Un conjunto de etiquetas conserva las observaciones, así que un lector puede preguntar qué etiquetas estaban presentes, qué regla emitió cada una y si la acción final necesitaba todas o solo una. Esa es la diferencia entre un veredicto y un registro, y por eso un lenguaje de reglas construido sobre etiquetas puede auditarse mientras que un solo número no.

Esa expresividad tiene un costo, y conviene nombrarlo para que un equipo lo planifique. Una web ACL con muchas reglas que leen etiquetas ajenas es más difícil de razonar que una sola puntuación, porque el orden de evaluación importa y una etiqueta presente en una ruta puede faltar en otra. Una regla que lee dos etiquetas se comporta de forma distinta a dos reglas que leen una cada una, y la diferencia es invisible en un panel que solo informa la acción final. Mantener la lista de etiquetas en el registro es lo que hace recuperable esa diferencia después, y es el mismo campo que responde una pregunta de falso positivo un mes más tarde.

Una nota sobre el alcance, porque es el tipo de tema donde un pequeño exceso vuelve inútil todo el registro. Nada de lo anterior afirma que un sitio concreto ejecute Bot Control, que un código de estado concreto provenga de un grupo de reglas gestionado o que una solicitud que pasó un día pase al siguiente. Las mediciones describen tres solicitudes a un endpoint de documentación y la estructura documentada del producto; no describen ninguna aplicación protegida, y los mismos tres campos registrados contra un objetivo real son lo que un lector necesitaría para afirmar algo sobre él.

La misma cautela se aplica al vocabulario de etiquetas. El ejemplo usa un nombre con forma de categoría para mostrar cómo funciona la composición, y un despliegue real verá los nombres que emiten sus propias reglas, incluido el prefijo de espacio de nombres que añade el servicio. Copiar una cadena de etiqueta de un tutorial a una regla que la lee es la forma más rápida de construir una regla que nunca coincide, y la solución es leer las etiquetas de una solicitud real en lugar de confiar en una muestra.

Por último, el conjunto de acciones tiene una asimetría que conviene recordar al escribir un informe. Un bloqueo es una decisión que puede explicarse después desde la consola, y un Challenge es una decisión que produjo una segunda solicitud. Contar solo la primera solicitud subestima a la mitad una ruta con Challenge, porque el reintento con el token es una entrada separada que puede tener éxito y no dejar rastro en un recuento de fallos. Un informe que quiera describir lo ocurrido tiene que decidir cuál de las dos cosas cuenta antes de imprimir un número.

Fuentes

• AWS WAF Bot Control
• Etiquetas de reglas de AWS WAF
• Acción Challenge de AWS WAF
• BotBrowser: coherencia de automatización