AWS Builder Center

Builder Center

Un token que cambió de red: la etiqueta de procedencia de AWS WAF Bot Control no hace nada hasta que la conectas

Un bot resuelve el desafío de JavaScript desde un servidor en un centro de datos, obtiene un token válido y lo reparte entre cientos de direcciones residenciales. Cada solicitud llega con un token aceptado, desde una IP que parece de una persona.

vtjean

Desde el 15 de octubre de 2026, AWS WAF Bot Control puede marcar ese salto. Lo que no hace es detenerlo: la etiqueta se agrega a la solicitud, aparece en las métricas y en los logs, y la solicitud sigue su camino. Si el mismo token se reparte entre muchas direcciones, las reglas de reutilización de token del nivel targeted, como  TGT_TokenReuseIpHigh , ya actúan por su cuenta. La etiqueta de procedencia cubre otro caso, el del token que cambia de categoría de red.
Este artículo sigue el hilo de la serie: entender qué señal nueva existe y bajo qué condiciones aparece, medirla antes de actuar, decidir qué acción tiene sentido para cada nivel y dejar un runbook para conectarla sin bloquear a usuarios legítimos.

Qué agregó la versión 7.0

El registro de cambios de AWS Managed Rules para AWS WAF documenta la versión estática 7.0 del grupo de reglas Bot Control (AWSManagedRulesBotControlRuleSet) con fecha 15 de octubre de 2026. Esa versión agrega, en el nivel de protección targeted, etiquetas de procedencia del token y etiquetas de identificador de dispositivo.
La etiqueta de procedencia tiene esta forma, con tres niveles:
  •  awswaf:managed:aws:bot-control:token_provenance:ip_category_mismatch:high , para cambios que los clientes legítimos rara vez hacen. El ejemplo de la documentación es un token obtenido desde una IP de centro de datos, proxy o VPN y presentado desde una IP residencial o móvil.
  •  awswaf:managed:aws:bot-control:token_provenance:ip_category_mismatch:medium  y la variante low, para cambios con causas legítimas comunes, como un cliente residencial que activa una VPN o un proxy.
Lo que la etiqueta compara, según la documentación, es la categoría de la dirección IP entre la solicitud que obtuvo el token y la solicitud que lo presenta. Por esa definición, un cambio de dirección dentro de la misma categoría, como pasar de una red residencial a otra, no debería producir la etiqueta.
La etiqueta de identificador de dispositivo,  device_id , depende de que el token se haya obtenido con el SDK de AWS WAF para Android en la versión 2.1.0 o posterior. La documentación aclara que esa versión del SDK todavía no está disponible, así que por ahora ningún token lleva esa señal y AWS WAF no agrega la etiqueta. Este artículo se concentra en la procedencia.

Tres condiciones para que la etiqueta exista

La documentación pone tres condiciones, y si falta una, la etiqueta no aparece y nada lo avisa:
  1. El grupo de reglas tiene que estar en el nivel de inspección targeted. El nivel common no la produce.
  1. La web ACL tiene que usar la versión 7.0 o posterior del grupo de reglas.
  1. La solicitud tiene que presentar un token. Además, AWS WAF no evalúa la procedencia para las solicitudes etiquetadas como bot verificado.
La segunda condición merece atención. Si la regla de Bot Control en tu web ACL no fija una versión, AWS WAF usa la versión predeterminada del proveedor y la sigue cuando el proveedor la cambia. La versión predeterminada es la que AWS recomienda en ese momento, que no siempre es la última publicada. Si fijaste una versión estática anterior a la 7.0, la etiqueta tampoco existe para ti hasta que la actualices.
Para saber cuál es la versión predeterminada hoy:
aws wafv2 list-available-managed-rule-group-versions --vendor-name AWS --name AWSManagedRulesBotControlRuleSet --scope CLOUDFRONT --region us-east-1 --query CurrentDefaultVersion
Para ver qué versión y qué nivel usa tu web ACL:
aws wafv2 get-web-acl --name NOMBRE_DE_LA_WEB_ACL --id ID_DE_LA_WEB_ACL --scope CLOUDFRONT --region us-east-1 --query "WebACL.Rules[?Statement.ManagedRuleGroupStatement.Name=='AWSManagedRulesBotControlRuleSet'].{Prioridad:Priority,Version:Statement.ManagedRuleGroupStatement.Version,Config:Statement.ManagedRuleGroupStatement.ManagedRuleGroupConfigs}"
Si Version viene vacío, la regla usa la predeterminada. Si la predeterminada no es 7.0 o posterior y quieres la etiqueta, tienes que fijar la versión de forma explícita. Para una web ACL regional, cambia CLOUDFRONT por REGIONAL y usa la Región del recurso.

Por qué la etiqueta no detiene nada

La documentación lo dice directamente: ninguna regla del grupo Bot Control actúa sobre estas etiquetas. Para bloquear o desafiar las solicitudes que las llevan, hay que agregar a la web ACL una regla de coincidencia de etiqueta que se ejecute después de Bot Control.
La palabra que importa es después. Una sentencia de coincidencia de etiqueta solo ve las etiquetas que agregaron reglas evaluadas antes en la misma web ACL, y las etiquetas no salen de esa evaluación. Si tu regla tiene un número de prioridad menor que la regla de Bot Control, se evalúa antes y nunca va a ver la etiqueta.
No es un caso aislado. Bot Control en el nivel targeted tampoco bloquea una solicitud individual que llega sin token válido: desafía al cliente después de cinco solicitudes sin un token aceptado. Para cerrar ese hueco, la documentación recomienda una regla justo después del grupo administrado que capture las etiquetas de token ausente o rechazado. La etiqueta de procedencia sigue el mismo patrón: el grupo administrado produce la señal y la decisión queda en tus manos.

La señal: medir antes de decidir

AWS WAF publica métricas de Amazon CloudWatch para las etiquetas que agregan tus reglas y los grupos administrados, con las dimensiones LabelNamespace y Label, entre otras. Las métricas reportan la acción final aplicada a la solicitud, como AllowedRequests o BlockedRequests. Para una web ACL asociada a Amazon CloudFront, las métricas están en la Región US East (N. Virginia). Un detalle: AWS WAF guarda métricas de a lo sumo 100 etiquetas por solicitud.
Antes de escribir una regla, confirma que la etiqueta ya está llegando:
aws cloudwatch list-metrics --namespace AWS/WAFV2 --region us-east-1 --query "Metrics[?Dimensions[?Name=='LabelNamespace' && contains(Value, 'token_provenance')]]"
Si la lista sale vacía, revisa las tres condiciones de la sección anterior antes de concluir que no hay tráfico con ese patrón. Una lista vacía también es lo que ves cuando la versión no es la correcta.
Los logs de AWS WAF incluyen las etiquetas de cada solicitud en el campo labels. Si envías los logs a Amazon CloudWatch Logs, en un grupo cuyo nombre empieza con aws-waf-logs-, puedes ver a qué rutas llegan las solicitudes de nivel high, y desde qué países, con CloudWatch Logs Insights:
filter @message like /token_provenance:ip_category_mismatch:high/ | stats count(*) as solicitudes by httpRequest.uri, httpRequest.country | sort solicitudes desc | limit 20
Para ver también las direcciones de origen, agrega httpRequest.clientIp después de httpRequest.country en el stats.
Lo que buscas en esa salida es concentración. Un nivel high repartido en pocas rutas sensibles, como el inicio de sesión, el carrito o una API de precios, cuenta una historia distinta que el mismo volumen repartido en todo el sitio.

Conectar la señal, primero en Count

Agrega una regla de coincidencia de etiqueta con acción Count y un número de prioridad mayor que el de la regla de Bot Control. Esta es la regla para el nivel high:
{ "Name": "procedencia-token-alta", "Priority": 20, "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:bot-control:token_provenance:ip_category_mismatch:high" } }, "Action": { "Count": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "procedencia-token-alta" } }
Para observar los tres niveles con una sola regla, usa el alcance de espacio de nombres. La clave termina con dos puntos:
{ "Name": "procedencia-token-todas", "Priority": 21, "Statement": { "LabelMatchStatement": { "Scope": "NAMESPACE", "Key": "awswaf:managed:aws:bot-control:token_provenance:ip_category_mismatch:" } }, "Action": { "Count": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "procedencia-token-todas" } }
Los valores de prioridad 20 y 21 son ejemplos: lo que importa es que sean mayores que el de Bot Control y que no choquen con otras reglas. Las etiquetas distinguen mayúsculas de minúsculas, así que copia la clave tal como aparece en la documentación.

El objetivo: qué acción tiene sentido para cada nivel

Con unos días de datos en Count, la decisión deja de ser una apuesta.
Nivel high. Es el candidato natural para una acción que detenga la solicitud. Si después del periodo de observación las solicitudes de nivel high se concentran en rutas sensibles y no corresponden a clientes conocidos, como tus propias pruebas sintéticas o un socio que integra desde la nube, pasar la regla a Block es una decisión defendible. Antes de hacerlo, agrega excepciones para el tráfico propio que identificaste en los logs.
Niveles medium y low. La documentación los describe como cambios con causas legítimas comunes. Bloquearlos castiga a usuarios con VPN corporativa o personal. Lo razonable es dejarlos en Count, usarlos como contexto en tus investigaciones o combinarlos con otras etiquetas de Bot Control en una regla más específica.
Una advertencia sobre Challenge. Según la referencia de la API de AWS WAF, si la solicitud trae un token de desafío válido y no vencido, la acción Challenge se comporta como Count y la evaluación continúa. La etiqueta de procedencia, por definición, aparece en solicitudes que presentan un token, y el escenario que describe es un token válido usado desde otra red. De ahí se deduce que una regla con Challenge sobre esta etiqueta probablemente no desafíe a nadie mientras el token siga dentro de su tiempo de inmunidad, que tiene un mínimo de 300 segundos para Challenge. Esto es una inferencia a partir de la documentación de la acción, no algo que la documentación de la etiqueta diga. Pruébalo en Count y con una regla de Challenge en una web ACL de prueba antes de contar con ese comportamiento.
CAPTCHA funciona con su propia marca de tiempo dentro del token, con un mínimo de 60 segundos de inmunidad. Un token obtenido solo con un desafío silencioso no trae una resolución de CAPTCHA, así que la acción CAPTCHA sí debería presentar el rompecabezas. Es una opción con fricción para el usuario, útil en rutas puntuales como el inicio de sesión, y también conviene validarla en pruebas.

Runbook: conectar la etiqueta de procedencia

  1. Confirma que la regla de Bot Control usa el nivel targeted.
  1. Consulta la versión predeterminada y la versión de tu web ACL. Si no es 7.0 o posterior, decide si fijas la versión, después de revisar el resto de cambios de esa versión en el registro de cambios.
  1. Confirma que la etiqueta aparece en las métricas de CloudWatch. Si no aparece, vuelve al paso 1 antes de concluir que no hay tráfico.
  1. Agrega la regla de coincidencia de etiqueta en Count, con prioridad mayor que la de Bot Control.
  1. Durante unos días, revisa en los logs las rutas, países y direcciones de las solicitudes de nivel high, y separa el tráfico propio o de socios conocidos.
  1. Pasa el nivel high a Block, o a CAPTCHA en rutas puntuales, con excepciones para el tráfico propio.
  1. Deja medium y low en Count y úsalos como contexto.
  1. Crea una alarma de CloudWatch sobre la métrica de tu regla. Un salto brusco de solicitudes de nivel high es una señal que vale la pena mirar, aunque la regla ya esté bloqueando.

Limitaciones

  • La documentación no explica cómo AWS WAF clasifica una dirección IP en una categoría, ni publica la lista completa de categorías. Solo menciona ejemplos: centro de datos, proxy, VPN, residencial y móvil.
  • La diferencia entre medium y low no está documentada más allá de que ambos niveles tienen causas legítimas comunes.
  • El comportamiento de Challenge y CAPTCHA sobre esta etiqueta es una inferencia a partir de la referencia de la API de cada acción. La documentación de la etiqueta no lo trata.
  • La documentación no dice qué versión es hoy la predeterminada para Bot Control. Por eso el runbook pide consultarla.
  • La etiqueta de identificador de dispositivo depende de una versión del SDK de Android que todavía no está disponible. El SDK de iOS y los navegadores no la producen.
  • El nivel targeted de Bot Control tiene un costo adicional. Revisa los precios de AWS WAF antes de activarlo solo para obtener esta etiqueta.
  • La procedencia se evalúa solo cuando la solicitud presenta un token. Las solicitudes sin token siguen dependiendo de las reglas de token ausente o rechazado.

Recursos

  •  ChallengeAction  - Comportamiento de Challenge cuando la solicitud ya trae un token válido
  •  CaptchaAction  - Comportamiento de CAPTCHA según la marca de tiempo del token
# aws-waf# amazon-cloudfront# amazon-cloudwatch# security# cloud-security
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article