El error más común en la protección DDoS tradicional es aplicar el mismo umbral fijo a todos los servicios. Una regla simple como «bloquear por encima de 100 solicitudes por segundo» puede reaccionar demasiado lento para un servicio de bajo tráfico y producir bloqueos falsos en un sitio de e-commerce durante una campaña. Cada aplicación tiene su propio volumen de tráfico normal, distribución de rutas, perfil de clientes y comportamiento de conexiones.
Los ataques L7 DDoS no siempre llegan con altos conteos de paquetes o altas tasas de solicitudes. Los ataques al estilo Slowloris — tasa baja pero muchas conexiones abiertas — así como los floods de conexiones SSL, el aumento de tasas de error, el comportamiento de bots y la carga concentrada en endpoints específicos pueden todos burlar la lógica clásica de rate-limit. Tomar decisiones a partir de un único contador no es por tanto suficiente.
Otro problema es que las acciones de protección suelen ser iguales para todos. Si cada solicitud sospechosa se descarta inmediatamente, los usuarios legítimos se ven afectados; si se muestra un captcha en todos los casos, la experiencia del usuario se degrada. El drop silencioso es correcto en algunos escenarios, el redirect en otros, una página informativa en otros, y un captcha self-hosted en otros más.
El enfoque correcto es aprender el comportamiento del tráfico por servicio, evaluar conjuntamente las señales L4 y L7 y elegir la acción en función de las condiciones. Las reglas de lista blanca, el comportamiento de rutas, el conteo de conexiones, la tasa de solicitudes, la puntuación de bot y la IP reputation deberían participar todos en el mismo pipeline de decisión.
TR7 Aprendizaje Adaptivo DDoS ofrece este modelo: monitorea el tráfico del servicio, convierte el comportamiento aprendido en recomendaciones de política y aplica acciones de protección controladas con aprobación del operador.
TR7 aplica las decisiones DDoS mediante la recopilación de contadores, condiciones combinadas, líneas base aprendidas y un modelo de acción graduada.
TR7 rastrea el comportamiento de conexiones, solicitudes, errores y SSL usando contadores globales y por clave de seguimiento. Estas cifras forman las señales principales para las condiciones DDoS por servicio.
`ddosCond` permite combinar múltiples condiciones ACL con lógica AND, OR y NOT. Las decisiones pueden por tanto basarse no solo en la tasa de solicitudes sino también en el conteo de conexiones SSL, la tasa de errores, la puntuación de bot, la IP reputation o el comportamiento de rutas.
El comportamiento del servicio, rutas y solicitudes se analiza a partir de datos históricos de tráfico y logs. Los valores aprendidos se presentan al operador como recomendaciones y se convierten en una política aplicable una vez aprobados.
TR7 soporta acciones de deny, redirect, showContent y showCaptcha. Según la sensibilidad del servicio, el operador puede elegir drop silencioso, redirect, una página de respuesta personalizada o un captcha self-hosted.
El Aprendizaje Adaptivo DDoS combina señales de tráfico por servicio con comportamiento aprendido para ofrecer una protección L4/L7 más precisa.
TR7 usa un modelo de indicador que puede marcar el estado DDoS a nivel global. Cuando un servicio o condición de seguimiento activa un estado de ataque, esa información puede usarse como señal en otras decisiones de protección. El DDoS se trata por tanto como parte del comportamiento de todo el sistema, no solo como un evento de solicitud aislado. Los equipos de operaciones obtienen una visión más clara del modo de protección general durante un incidente.
Junto a la señal global, también está disponible un indicador DDoS por solicitud. Si una solicitud ha sido capturada por una condición DDoS puede determinarse a nivel de transacción. La acción se aplica por tanto solo al flujo relevante — no es necesario colocar todo el tráfico en el mismo bucket innecesariamente. El comportamiento de grano fino reduce el riesgo de falsos positivos.
TR7 puede rastrear diferentes claves como la tasa de solicitudes HTTP, la tasa de errores HTTP, la tasa de conexiones, el conteo de conexiones activas y el conteo de conexiones SSL. El comportamiento L7 es prominente para los servicios HTTP; las señales basadas en conexiones lideran para los servicios TCP. Esta distinción permite seleccionar el indicador DDoS correcto para cada tipo de servicio, de modo que las decisiones se basen en el conjunto de señales apropiado en lugar de un único contador.
Una ventana de seguimiento más corta captura las ráfagas de ataque rápidas más rápidamente; una ventana más larga hace visible el comportamiento lento y sostenido. TR7 hace esta duración configurable por necesidad de servicio. Las ventanas cortas predeterminadas son adecuadas para un inicio rápido, pero la política de producción debe ajustarse al perfil del servicio. Esta flexibilidad ayuda a distinguir los picos repentinos de tráfico de campaña del comportamiento DDoS lento.
`ddosWhitelistCond` puede eximir IPs específicas, ASNs, rutas o fuentes de tráfico de confianza de las acciones DDoS. Esto es especialmente importante para los bots de motores de búsqueda, las integraciones empresariales, los sistemas de monitoreo o el tráfico API de socios. La lista blanca no tiene que ser una lista estática; puede escribirse con lógica de condición para un control más fino. Los flujos críticos de negocio permanecen protegidos incluso cuando la protección se vuelve más agresiva.
TR7 soporta acciones de deny, redirect, showContent y showCaptcha. deny es el enfoque de drop silencioso más agresivo; redirect mueve el tráfico a otra ubicación; showContent devuelve una página personalizada con un código de estado específico; showCaptcha inicia la verificación del usuario. Esta variedad significa que no todos los ataques se encuentran con el mismo nivel de fuerza. El operador selecciona la respuesta correcta basándose en el valor del servicio y el riesgo de falsos positivos.
TR7 puede servir páginas de verificación multilingüe en escenarios de desafío DDoS. Estas páginas presentan el flujo de control a los usuarios sin depender de un servicio externo de terceros. El enfoque de desafío self-hosted es una ventaja en sectores con sensibilidad a la compartición de datos y al cumplimiento. En lugar de mostrar simplemente un error, los usuarios reciben una experiencia de verificación controlada.
TR7 puede derivar un perfil normal por servicio a partir de datos históricos de logs y tráfico. El tráfico esperado por ruta, la tasa de errores típica o el comportamiento de carga pueden presentarse al operador como recomendaciones. El operador las revisa y aprueba para convertirlas en condiciones DDoS. Este enfoque facilita construir políticas a partir del tráfico real observado en lugar de escribir umbrales a ciegas.
Las puntuaciones de protección de bots pueden usarse como señales auxiliares en las decisiones DDoS. Factores como IP de datacenter, salida Tor, baja IP reputation, análisis de user agent, huella de cabeceras y huella TLS pueden todos afectar a la puntuación de riesgo. Cuando la puntuación de bot supera un umbral configurado, puede activarse la acción de deny, redirect o captcha. La protección DDoS por tanto no mira solo el volumen sino también la calidad del cliente.
TR7 puede usar 13 categorías de IP reputation como señales de decisión: proxy abierto, bad bot, brute force, ataque a aplicaciones web, SQL injection, hacking, ataque DDoS, host comprometido, port scan, spam web, spam de correo, spam de blog y VPN IP. Estas categorías no necesitan ser definitivas por sí solas — contribuyen con peso de riesgo adicional dentro de una condición combinada. Las fuentes conocidas como malas se separan por tanto del tráfico normal de usuario más rápidamente, haciendo la política de protección más consciente del contexto.
TR7 puede derivar recomendaciones por servicio a partir de señales como la tasa de conexiones, las conexiones activas, la tasa de solicitudes, la tasa de errores y el comportamiento de rutas. El operador revisa estas recomendaciones en lugar de aplicarlas a ciegas. Los valores aprobados se convierten en condiciones DDoS y políticas de acción. Este modelo mantiene la automatización bajo control — el aprendizaje, la aprobación humana y la política aplicable trabajan juntos.
El equipo de operaciones también puede activar el estado DDoS manualmente durante un ataque. Esto es útil para tomar una acción de protección rápida sin esperar a que el aprendizaje automático o los disparadores de condición se activen. El modo manual proporciona una capa de defensa temporal especialmente durante el proceso de respuesta a incidentes. Las condiciones identificadas post-incidente pueden formalizarse en política permanente.
La protección DDoS adaptiva se opera junto con umbrales, composición de condiciones, selección de acciones, reglas de lista blanca, puntuación de bot y comportamiento de desafíos.
Cuando la puntuación de protección de bots alcanza un umbral configurado, pueden activarse acciones como deny, redirect o captcha. Este umbral debe aplicarse con cuidado basándose en la sensibilidad del servicio. Evaluarlo junto con el comportamiento de solicitudes y las condiciones de lista blanca — en lugar de depender solo de la puntuación de bot — produce resultados más fiables.
El modelo de seguimiento DDoS global puede mantener un contador para el estado de sistema único. Esta estructura ayuda a comprender el estado de ataque de todo el sistema junto con las condiciones por servicio. Durante un incidente, los equipos de operaciones monitorizan no solo una única solicitud sino también la señal de comportamiento agregado.
Cuando el indicador DDoS está activo, se aplica la acción de protección seleccionada. deny proporciona drop silencioso; redirect realiza la redirección; showContent sirve contenido personalizado; showCaptcha inicia el flujo de desafío. La selección de acción debe hacerse según el valor del servicio, la experiencia del usuario y la gravedad del ataque.
En la acción showContent, el código de estado, el tipo de contenido y el perfil de contenido son todos personalizables. Esto permite mostrar a los usuarios el mensaje propio de la organización en lugar de un error genérico. La funcionalidad es valiosa para ventanas de mantenimiento, comunicación de incidentes y mensajes de cumplimiento.
La acción showCaptcha puede invocar el propio módulo CAPTCHA de TR7, reduciendo la dependencia de un servicio de verificación externo de terceros. Este enfoque ofrece un flujo de verificación más controlado y compatible para organizaciones con sensibilidad a la protección de datos y regulatoria.
Múltiples señales pueden combinarse dentro de `ddosCond` usando lógica AND, OR y NOT. Por ejemplo, una tasa de solicitudes elevada puede evaluarse junto con una concentración de ruta específica y una categoría de IP reputation en lugar de de forma aislada. Esto reduce los falsos positivos mientras habilita una acción más específica.
Los equipos de e-commerce pueden usar condiciones DDoS por servicio para separar un aumento de tráfico durante una campaña de un ataque real. Los crawlers de confianza o las fuentes de socios se incluyen en la lista blanca mientras el comportamiento anormal de rutas y solicitudes se mapea a acciones de protección.
Las aplicaciones bancarias pueden monitorear conjuntamente la tasa de solicitudes HTTP, el conteo de conexiones SSL y la tasa de errores en el tráfico de login. Cuando se superan los umbrales, se aplican acciones de redirect, captcha o deny según la política del servicio.
Los portales públicos pueden usar sus propias páginas de desafío TR7 sin enviar datos a un servicio de verificación externo. El contenido multilingüe mantiene el flujo de verificación del usuario bajo control institucional.
Los ataques que generan un alto número de conexiones abiertas a pesar de una tasa de solicitudes baja pueden monitorearse a través del comportamiento de conteo y duración de conexiones. TR7 hace visibles los patrones de ataque lento que agotan conexiones — no solo los floods de alto PPS.
Recorra el aprendizaje de línea base, las condiciones combinadas y el modelo de acción graduada sobre sus propios servicios.