La mitigación DDoS clásica cae en uno de dos problemas. Primero: los servicios de scrubbing en la nube enrutan el tráfico a otra red. Esto añade latencia y expone sus datos a un tercero durante el análisis del ataque. Los cálculos de costes a menudo también cobran por el tráfico de ataque.
Segundo: los appliances DDoS on-prem dedicados necesitan ajuste por parte de un experto en DDoS para dar la respuesta correcta. Los umbrales se establecen manualmente; a medida que cambia la topología, los umbrales se quedan desactualizados; el equipo de operaciones tiene que seguir actualizándolos.
En el lado del atacante, los vectores cambian constantemente. Empieza un SYN flood, evoluciona a UDP flood en minutos, luego llega la amplificación DNS. Las campañas orquestadas usando botnets de IoT combinan diferentes vectores durante horas. Las defensas de vector único envejecen con cada nueva campaña.
El add-on L4 DDoS de TR7 aborda los tres juntos: el filtrado de paquetes a nivel de kernel maneja todos los vectores comunes en un motor, la línea base adaptiva elimina al operador del ajuste manual, y la mitigación permanece en su propio hardware.
El add-on L4 DDoS funciona sobre cuatro principios: rendimiento a nivel de kernel, cobertura multivector, aprendizaje adaptivo de línea base y granularidad por tabla de rutas.
La detección y el filtrado se aplican en la capa de paquetes — antes de la capa de aplicación. Los floods de alto volumen se descartan antes de alcanzar los hilos de aplicación; el consumo de recursos permanece mínimo.
SYN/UDP/ICMP/ACK flood, ataques de fragmentación, amplificación DNS/NTP/SSDP/Memcached — todos reconocidos en el mismo motor de filtrado. Los cambios de vector a mitad de campaña no interrumpen la mitigación.
El sistema observa el perfil normal de su tráfico, genera periódicamente una línea base y pregunta al operador «¿debo tratar por encima de este nivel como un ataque?». El operador aprueba; la línea base se activa y se ajusta con el tiempo.
El alcance de mitigación escala por tabla de rutas. El mismo ADC puede alojar diferentes perfiles de protección L4 para diferentes segmentos; los despliegues pequeños usan una tabla de rutas, las empresas multi-cliente o multi-segmento usan 25+.
El add-on L4 DDoS de TR7 maneja los vectores de capa de red más comunes de las campañas de ataque modernas en un único motor.
Un atacante usa cientos de miles de conexiones TCP semiabiertas para saturar el pool de conexiones del servidor. Los sistemas clásicos deben rechazar solicitudes legítimas una vez que el pool se llena. TR7 L4 DDoS evalúa los paquetes SYN contra la línea base; cuando se detecta diversidad anómala de origen o ratio SYN/ACK, entran en juego SYN cookies y el manejo agresivo de TIME_WAIT. Las conexiones legítimas no se ven afectadas.
La naturaleza sin conexión del UDP da al atacante un fácil acceso al flood. TR7 detecta los floods UDP mediante validación de dirección de origen, distribución del tamaño de paquetes y perfiles de densidad por puerto. El tráfico de alto volumen inesperado de fuentes inusuales se evalúa contra la línea base; una vez reconocido el ataque, se aplica un throttle específico del protocolo.
Los ping floods y la amplificación ICMP echo son vectores volumétricos clásicos. TR7 compara el tráfico ICMP con la línea base; el tráfico conforme al protocolo pero anómalamente voluminoso se descarta mediante rate-limit por origen. El tráfico de prueba de ingeniería de red no se ve afectado.
El atacante envía paquetes ACK aleatorios; el servidor se ve forzado a consultas de estado y se consume CPU. TR7 detecta los ACK floods mediante perfiles de densidad de consultas a la tabla de estado; los paquetes de ataque se rechazan a nivel de kernel.
Los paquetes fragmentados agotan el pool de reensamblado en el servidor objetivo. TR7 inspecciona el tráfico de fragmentos antes del reensamblado; los patrones de fragmentos faltantes o superpuestos se descartan al detectarse.
El atacante usa resolvers DNS mal configurados para convertir pequeñas consultas en respuestas grandes. TR7 compara el tráfico de respuestas DNS con el historial de consultas; los pares consulta-respuesta no coincidentes se reconocen como ataques de reflector y se descartan.
Más allá del DNS, los vectores de amplificación clásicos: NTP monlist, descubrimiento SSDP, UDP Memcached, getbulk SNMP. Cada uno tiene un perfil de tráfico específico del protocolo; las respuestas de alta amplificación inesperadas se filtran antes de llegar a la fuente.
Las campañas de ataque modernas cambian de vector a mitad de campaña. TR7 observa continuamente la mezcla de vectores activos; la política de mitigación se adapta automáticamente. No se requiere intervención del operador.
El perfil de tráfico se aprende a lo largo de ciclos horarios, diarios y semanales. El operador revisa primero la línea base, aprueba; después la línea base se ajusta sola. A medida que el tráfico crece, los umbrales se amplían; a medida que disminuye, se ajustan.
La mitigación se define por tabla de rutas. El mismo ADC protege diferentes segmentos de clientes, diferentes grupos de aplicaciones o diferentes topologías de red con perfiles de protección L4 separados. Niveles de capacidad — 1, 2, 5, 10, 25 tablas de rutas; las empresas obtienen Ilimitado.
El add-on L4 DDoS no es solo un filtro técnico — el aprendizaje de línea base, el flujo del operador, el escalado granular y los registros de auditoría juntos forman un modelo operacional completo.
El perfil de tráfico se observa a escala horaria, diaria y semanal. El sistema presenta al operador «¿debo tratar por encima de este nivel como un ataque?»; el operador revisa, aprueba o modifica. Tras la activación, si el perfil de tráfico evoluciona, el sistema presenta una nueva sugerencia de línea base.
Las nuevas líneas base o los cambios de política pasan por la aprobación del operador antes de activarse. La cadena de aprobación es configurable; los cambios de alto impacto pueden requerir aprobación dual.
Las reglas de mitigación se definen a nivel de tabla de rutas. Si el mismo ADC sirve múltiples segmentos, cada uno obtiene su propia línea base y perfil de mitigación independientes.
Por vector de ataque detectado, la acción se selecciona automáticamente: drop, rate-limit, lista negra de origen, throttle específico del protocolo. Los operadores pueden personalizar mediante política.
El tráfico de ataque volumétrico no aparece en su factura. Los proveedores clásicos contabilizan el tráfico de ataque bloqueado contra el ancho de banda; TR7 lo excluye desde el principio.
Cada vector de ataque detectado, acción de mitigación aplicada, geografía de origen y duración se escriben en el registro de auditoría y se transmiten al SIEM. Cadena de evidencia completa para investigación forense e informes de cumplimiento.
El tráfico de una infraestructura bancaria es alto durante el día y bajo por la noche. Un atacante lanza un SYN flood de noche; un umbral estático establecido para el día es demasiado grande para la noche, y uno establecido para la noche bloquea tráfico legítimo. La línea base adaptiva de TR7 conoce el perfil nocturno; el ataque se detecta en el momento en que supera la línea normal nocturna.
Un atacante usa 10.000+ resolvers DNS abiertos en todo el mundo para saturar el enlace WAN de la organización. El tráfico parece respuestas DNS «normales». La detección de reflectores de TR7 captura el tráfico que no coincide con una consulta previa; el ataque se detiene en el borde de red de la organización, no aguas arriba.
Un atacante ejecuta una campaña de varias horas con una botnet IoT: empieza con SYN flood, cambia a UDP flood, luego añade amplificación DNS. La defensa clásica de vector único necesita reajustarse en cada cambio. TR7 observa continuamente la mezcla de vectores; la política de mitigación se adapta automáticamente.
Un MSP quiere protección L4 para 25 clientes diferentes en el mismo ADC. El perfil de tráfico de cada cliente es diferente; la línea base de un cliente podría parecerse al ataque de otro cliente. TR7 ejecuta perfiles de línea base y mitigación independientes por cliente a nivel de tabla de rutas.
Veamos en vivo el flujo de aprendizaje de línea base, la confirmación del operador y la mitigación multivector en su entorno — una sesión de despliegue en una tabla de rutas piloto.