Entre los bots en Black Friday, el que más le cuesta a una tienda rara vez es el que intenta tumbar el sitio. Es el que compra el inventario de la oferta antes que el cliente, prueba contraseñas filtradas en el login y tarjetas robadas en el checkout y recopila precios para un competidor, mientras el cliente real encuentra el producto agotado o un checkout más lento de lo que debería.
Proteger el e-commerce de bots de este tipo depende de tres decisiones, que son puntuar la automatización en las rutas donde causa pérdidas, darle una salida a quien fue clasificado por error y calibrar la protección antes del pico, con el tráfico de la propia tienda, en lugar de ajustarla en medio del evento. A continuación, mira cómo armar esta protección en Azion, del login a las API de la app, y cómo medir si funcionó. El mismo plan sirve para cualquier pico de ventas, como Cyber Monday, Navidad y lanzamientos de producto.
¿Qué cambia en el tráfico de bots en Black Friday?
En los días de ofertas, el inventario disputado, las cuentas con saldo y los precios promocionales valen más para quien opera bots, y es hacia ellos que se dirige la automatización.
Este tráfico se concentra en tres tipos de ataque, cada uno en un punto distinto de la tienda:
- Scalping y hoarding, en los que los bots compran o reservan en el carrito el inventario de las ofertas más disputadas, ya sea para revenderlo o solo para sacarlo de circulación.
- Credential stuffing y prueba de tarjetas, en los que los bots prueban en el login listas de contraseñas filtradas en otros servicios y, en el checkout, números de tarjeta robados, para descubrir cuáles todavía funcionan.
- Scraping de precios e inventario, en el que competidores y revendedores recopilan las páginas y las API de la tienda para seguir precios y disponibilidad.
No siempre la pérdida llega con volumen, ya que un script que prueba tarjetas puede pasar desapercibido en los gráficos de tráfico y aun así generar contracargos, y por eso la protección empieza por las rutas donde cada solicitud vale más.
¿Por qué el login, el registro y el checkout requieren un tratamiento distinto?
No toda página de la tienda merece el mismo rigor. Un bot de búsqueda en el catálogo es bienvenido, mientras que un intento automatizado de login puede terminar en una cuenta comprometida, y por eso el caso de uso Bloquear account takeover en flujos de login y checkout aplica Bot Manager solo en el login, el registro y el checkout, con una respuesta diferente para cada uno.
En el login y el registro, quien alcanza el límite de score definido por el equipo, el threshold, es redirigido a un desafío, ALTCHA, una alternativa open source a CAPTCHA que se ejecuta como función en el firewall, y una persona que lo resuelve sigue sin que se le vuelva a desafiar. En el checkout, la respuesta es el bloqueo con 403, porque un script de prueba de tarjetas no resuelve desafíos y un cliente con el pago en curso no debe ser interrumpido por uno.
El WAF (Web Application Firewall) cubre las mismas tres rutas y busca payloads de ataque, como una inyección en un campo de formulario, que Bot Manager no inspecciona.
En la arquitectura de prevención de fraude online, la solicitud pasa por el firewall en este orden: primero la regla de ALTCHA, que reconoce a quien ya resolvió el desafío, después el WAF y, por último, una instancia de Bot Manager por tipo de ruta.
Solo lo que queda por debajo del threshold llega a la aplicación y, desde allí, al sistema de identidad o al medio de pago, y cada decisión se convierte en una línea de reporte que va a Real-Time Events y, a través de Data Stream, a las herramientas del equipo de fraude.
Cómo funciona la gestión de bots en Bot Manager
Bot Manager, la solución de gestión de bots de Azion, no toma una decisión de sí o no. Cada regla que activa la solicitud suma puntos a un score, y las reglas se dividen en seis clases, que son firmas de bots maliciosos, bots con script, comportamiento malicioso del navegador, intención maliciosa, inteligencia de reputación y proveedores de nube, como explica la página de puntuación de bots. La acción solo se dispara cuando el score llega al threshold que definió tu equipo, y lo que queda por debajo sigue hacia la aplicación.
Cada solicitud recibe además un veredicto, que puede ser tráfico legítimo, bot bueno, bot malicioso o en evaluación, y un cliente visto por primera vez queda en evaluación hasta por 15 minutos en lugar de ser rechazado por ser nuevo, lo que importa en un día en que mucha gente entra a la tienda por primera vez.
Cuando el score llega al threshold o lo supera, Bot Manager ejecuta una de siete acciones, listadas en la página de argumentos:
| Acción | Qué hace |
|---|---|
allow | Deja que la solicitud siga, sea cual sea el score |
deny | Responde con 403 |
drop | Termina la solicitud sin respuesta |
redirect | Redirige a una URL, como la del desafío ALTCHA |
custom_html | Responde con un HTML y un status definidos por ti |
random_delay | Espera de 1 a 10 segundos, elegidos al azar, y deja que la solicitud siga |
hold_connection | Mantiene la conexión abierta durante 1 minuto y después la descarta |
Las dos últimas son las más útiles contra el scalping. Un bot que disputa inventario depende de la velocidad, y random_delay le quita esa ventaja sin rechazar la solicitud, de modo que un cliente clasificado por error todavía completa la compra, solo que unos segundos más lento.
hold_connection va más allá y retiene la conexión durante un minuto antes de descartarla, lo que encarece cada intento de quien dispara miles de ellos, pero también tumba la solicitud de quien fue clasificado por error, así que reserva esta acción para los scores más altos.
El scalping ocurre antes del checkout, cuando el bot agrega el producto al carrito, y por eso requiere una instancia propia de Bot Manager en la ruta de agregar al carrito, con random_delay, separada de la instancia del checkout, que sigue con deny. El scraping del catálogo y de las páginas de producto no es el foco de esta guía, pero una instancia en esas rutas con la acción allow ayuda a medir cuánto existe antes de decidir cómo responder.
¿Cómo preparar la protección para cualquier pico de ventas?
El threshold que funciona para una tienda no necesariamente funciona para otra, porque el score del tráfico legítimo depende del público, de los navegadores y de los integradores de cada operación. Por eso, la preparación se hace en cuatro fases, con el tráfico real de la tienda, y cada fase termina cuando cumple un criterio, y no cuando llega una fecha en el calendario. Antes de empezar, verifica que el firewall esté asociado al workload de la tienda, con los módulos WAF y Functions activos, y que ALTCHA esté instalado desde Marketplace. También conviene reunir a seguridad, fraude y e-commerce para definir las rutas críticas y cuántos desafíos a clientes reales acepta el negocio, ya que es el equipo de e-commerce el que siente el falso positivo en la conversión.
Fase 1: observar
Pon Bot Manager en modo de observación en las rutas críticas, con la acción allow, que puntúa y registra cada solicitud sin rechazar ninguna, y con un threshold inicial explícito, ya que en la edición completa de Bot Manager el valor predeterminado es infinito y, sin un valor definido, ninguna solicitud llega a él. Aplica también el WAF en las mismas rutas en modo de registro (Logging), que señala lo que se bloquearía sin bloquearlo, con una excepción, ya que incluso en Logging el WAF rechaza las solicitudes POST con formato inválido.
La observación tiene que cubrir al menos un pico de tráfico real, como una campaña menor o una preventa, y sirve también para identificar el tráfico legítimo que no es cliente, como monitoreo, socios, integradores, respuestas del medio de pago y bots de búsqueda. Mantén el threshold fijo durante toda la fase, porque el veredicto depende del threshold vigente y cambiarlo a mitad de camino reclasifica el tráfico observado. La fase termina cuando ese tráfico está mapeado y sabes dónde está el score de tus clientes.
Fase 2: calibrar
Lee el reporte de Bot Manager y la pestaña Tuning del WAF, separa los scores del tráfico que reconoces de los scores del tráfico que no reconoces y elige el threshold en el intervalo entre ambos. Las reglas que insisten en puntuar tráfico legítimo pueden desactivarse en la instancia, lo que aplica a todos los clientes de esa ruta, y cuando la regla solo molesta a clientes en una ruta específica, restringir las rutas de la instancia suele ser la mejor salida.
En el WAF, los registros de falsos positivos se convierten en excepciones. Como Tuning lee como máximo los últimos 3 días, la revisión tiene que ser semanal, y la fase termina cuando dos revisiones seguidas no traen ningún falso positivo nuevo.
Fase 3: aplicar de forma gradual
Activa el bloqueo ruta por ruta, empezando por el login. El modo del WAF se define en la regla del firewall que lo invoca, y cada instancia de Bot Manager tiene su propia acción, así que puedes bloquear en /login y mantener /checkout solo registrando hasta que sus datos también estén limpios.
Una ruta está lista cuando la proporción de desafíos resueltos se mantiene estable, señal de que el threshold no entró en el rango de score de tus clientes. En esta fase, crea también la regla que bloquea las direcciones de una network list de bloqueo temporal, todavía vacía, y acuerda quién puede agregar direcciones a ella durante el pico.
Fase 4: operar y revisar
Durante el pico, monitorea en lugar de reconfigurar. Los reportes de Bot Manager y los eventos del WAF llegan al SIEM (Security Information and Event Management) a través de Data Stream, donde el equipo de seguridad y el de fraude cruzan las decisiones con sus propias señales, y las líneas de reporte de Bot Manager salen por la fuente de datos de Functions, que requiere la suscripción a Functions. Si aparece una dirección abusiva, la persona acordada en la fase anterior usa el bloqueo temporal y agrega la IP a la lista con una fecha de vencimiento en UTC, en el formato 198.51.100.7 --LTAAAA-MM-DDTHH:MM:SSZ #abuso en login.
Como la regla ya existe, la acción modifica solo la lista y no la política del firewall, pero el vencimiento no elimina la entrada por sí solo, porque Azion solo descarta las entradas vencidas la próxima vez que se guarda la lista. Después del pico, revisa los scores, los desafíos resueltos y las direcciones bloqueadas, y usa esos datos como punto de partida de la observación del próximo evento.
Para Black Friday, empieza al menos tres semanas antes, porque cada fase necesita al menos una revisión semanal. Si el evento está más cerca, el plan sigue siendo válido, solo que comprimido, y el paso que no puedes saltarte es la observación, porque es la que muestra dónde está el score de tus clientes.
¿Y en la app móvil y las API?
La app y las API de inventario y precios son blanco de scraping y de hoarding y no llevan la cookie de sesión que Bot Manager usa para evaluar navegadores. Por eso, el caso de uso Proteger API públicas contra abuso arma un perímetro con cuatro reglas en el firewall, en este orden:
- WAF en la ruta de la API, que, en modo de bloqueo, rechaza patrones de ataque, cuerpos demasiado grandes y JSON que no se puede leer.
- Validación de JWT (JSON Web Token), una integración de Marketplace que se ejecuta en Functions y rechaza con
400o401a quien llega sin un token válido. - Bot Manager en modo
api, que deja de lado las verificaciones de cookie de sesión, pensadas para navegadores. En esta ruta, configura la accióndenyen lugar deredirect, porque un cliente de API no resuelve desafíos. - Rate limit por IP, en la última regla, que responde con
429a las solicitudes simultáneas por encima del límite.
El rate limit debe partir de la IP legítima más pesada que aparece en los logs, para no bloquear la propia app, ya que en redes móviles muchos clientes pueden salir por la misma IP del operador. La respuesta 429 tampoco indica cuándo volver a intentar, así que acuerda con el equipo de la app cómo manejarla. El modo api está documentado para la edición completa de Bot Manager, y la edición Lite lo ignora.
¿Cómo saber si la protección funcionó?
El caso de uso de account takeover propone tres medidas, y todas deben leerse con el threshold anotado al lado, porque el veredicto cambia junto con él:
| Qué medir | Dónde leerlo | Señal de que está funcionando |
|---|---|---|
| Intentos automatizados bloqueados | Top Bot Action en el panel de Bot Manager, en Real-Time Metrics | deny y redirect concentran el tráfico automatizado en las tres rutas |
| Falsos positivos en clientes reales | Desafíos resueltos en el mismo panel y el campo challenge_solved del reporte | Una proporción estable de desafíos resueltos, ya que cada uno es una persona que Bot Manager señaló |
| Ataque que todavía llega al origen | Líneas del reporte con acción allow, leídas junto con el score | Ningún grupo de clientes automatizados detenido justo por debajo del threshold |
Los mismos datos pueden consultarse a través de la API de GraphQL de Real-Time Metrics. El dataset botManagerMetrics, disponible para cuentas con Bot Manager, guarda durante dos años las solicitudes agrupadas por acción, veredicto y resultado del desafío, lo que permite seguir cada medida a lo largo del evento.
Para los falsos positivos, sigue la proporción de desafíos resueltos y desconfía cuando sube de un día para otro, señal de que el threshold entró en el rango de score de tus clientes. Por su parte, el dataset botManagerBreakdownMetrics muestra las URL y las IP que más visitaron los bots y ayuda a encontrar una ruta que quedó fuera de la protección.
Checklist por fase
| Fase | Qué hacer | Dónde |
|---|---|---|
| Observar | Bot Manager con allow, threshold explícito e internal_logs: 2 en login, registro, carrito, checkout y API | Firewall, instancias de función |
| Observar | WAF en Logging en las mismas rutas | Firewall, regla con Set WAF |
| Observar | Data Stream enviando los reportes al SIEM | Data Stream |
| Observar | Tráfico legítimo que no es cliente mapeado, como monitoreo, socios, medio de pago y bots de búsqueda | Reporte de Bot Manager |
| Calibrar | Threshold definido a partir del score de los clientes y reglas ruidosas desactivadas | Reporte de Bot Manager |
| Calibrar, cada semana | Falsos positivos del WAF convertidos en excepciones | Pestaña Tuning del WAF |
| Aplicar de forma gradual | Bloqueo activado ruta por ruta, empezando por el login | Firewall |
| Aplicar de forma gradual | random_delay en la ruta de agregar al carrito, en una instancia propia | Instancias de Bot Manager |
| Aplicar de forma gradual | Regla de bloqueo de la network list temporal creada, con la lista vacía y un responsable definido | Firewall, network lists |
| Operar y revisar | Monitorear las métricas y usar el bloqueo temporal para IP abusivas | Real-Time Metrics, network lists |
| Operar y revisar | Datos del pico revisados como punto de partida del próximo evento | Reporte de Bot Manager, SIEM |
Como Bot Manager se ejecuta en el mismo firewall y en las mismas reglas que el WAF, esta protección no requiere un segundo proveedor de bots, con otra consola y otro contrato, y cada decisión llega a las mismas herramientas que el equipo de seguridad ya usa.
HeroSpark, plataforma de educación digital, usa esta combinación, y el CTO de la empresa resume el resultado en el caso de éxito: “Cuando enfrentamos ataques, el WAF, Bot Manager y DDoS Protection nos permitieron mitigar amenazas sin interrupciones.”
Para llegar a Black Friday con la protección calibrada, habla con un especialista de Azion y descubre cómo poner Bot Manager en observación en el login y el checkout de tu tienda, para definir el threshold a partir del tráfico real de tus clientes. Si prefieres empezar por tu cuenta, instala Bot Manager Lite desde Marketplace, disponible en cualquier plan de Azion, y pasa a la edición completa de Bot Manager cuando necesites el modo api y el score dinámico.
Para otros frentes de la preparación, consulta también qué tan rápido reacciona tu tienda ante las amenazas, seguridad de API más allá del WAF y la diferencia entre los bots de IA de búsqueda, de agente y de entrenamiento, que no deben tratarse de la misma forma que un bot de scalping.
Preguntas frecuentes
¿Cómo saber si mi e-commerce está siendo atacado por bots?
Las señales más comunes son picos de login fallidos, típicos del credential stuffing, muchas compras rechazadas por el adquirente en secuencia, ofertas agotadas en segundos y accesos en volumen a las API de precios e inventario. Para confirmarlo, pon Bot Manager en modo de observación en esas rutas y lee el score de cada solicitud.
¿Qué es el scalping?
El scalping es el uso de bots para comprar o reservar el inventario de productos disputados antes que los clientes, generalmente para revenderlo a un precio más alto. En Black Friday, afecta a las ofertas con inventario limitado. random_delay reduce la ventaja de velocidad del bot sin rechazar la solicitud, y hold_connection retiene la conexión durante un minuto antes de descartarla.
¿Bloquear bots puede afectar a clientes reales?
Sí, si el threshold se define sin mirar el tráfico de la tienda. Por eso, la protección empieza en observación, el threshold se elige a partir del score de los clientes reales, y el login usa la redirección a un desafío en lugar del bloqueo, lo que le da a quien fue clasificado por error una forma de continuar.
¿Con cuánta anticipación a Black Friday debo configurar la protección contra bots?
Para Black Friday, empieza al menos tres semanas antes, para que haya tiempo de observar, calibrar y activar el bloqueo ruta por ruta, con una revisión por semana. Como Tuning del WAF lee solo los últimos 3 días, la revisión de los falsos positivos tiene que repetirse cada semana hasta el evento, y el mismo plan sirve para cualquier otro pico de ventas.
¿Cómo proteger la app móvil de bots?
Como la app no lleva la cookie de sesión que se usa para navegadores, usa Bot Manager en modo api, con la acción deny, junto con la validación de JWT, el rate limit por IP en la ruta de la API y el WAF.
