Una empresa de videojuegos casi despide a su proveedor. El sistema de protección DDoS no fue suficiente.

Un caso real sobre la diferencia entre poseer un dispositivo de mitigación y operar un servicio contra ataques DDoS.

‍

‍

Una empresa de juegos móviles contrató tránsito IP con protección DDoS a un importante operador de telecomunicaciones en Asia. El operador había implementado un sistema de mitigación de tráfico líder en el mercado. El servicio se vendió como protegido, el equipo de mitigación estaba instalado y todos tenían motivos para creer que el riesgo estaba cubierto.

‍

Entonces, más de 10 Gbps de tráfico de ataque se filtraron, saturaron el enlace de la empresa de juegos e interrumpieron su servicio. El cliente amenazó con cancelar el servicio de tránsito protegido del operador.

‍

‍El operador tenía protección DDoS. Lo que no tenía, en el momento crucial, era una protección que funcionara.

‍

Vendemos protección DDoS, así que lea el resto con el escepticismo necesario. Esta no es una historia sobre un proveedor incapaz de mitigar y otro infalible. Es una historia sobre un error que nuestra industria sigue cometiendo: tratar un dispositivo DDoS como si fuera un servicio DDoS completo.

‍

Ningún ingeniero serio promete que nunca nada saldrá mal

El "100% de tiempo de actividad" queda bien en una presentación. Los ingenieros que operan redes reales saben lo frágil que se vuelve esa promesa cuando se enfrenta a cambios de enrutamiento, defectos de software, errores de configuración, patrones de ataque nunca vistos y decisiones humanas tomadas bajo presión.

‍

La protección DDoS tiene el mismo problema. No puede significar honestamente que todo ataque será bloqueado a la perfección siempre, que el tráfico legítimo nunca se verá afectado o que la primera política de mitigación será correcta para siempre. Los ataques cambian. El tráfico del cliente cambia. A veces, la propia mitigación genera un problema.

‍

Un estándar más honesto
¿Está preparado para detectar el ataque, gestionarlo, recuperarse cuando algo sale mal, adaptar los controles y mitigar el próximo evento con mayor eficacia?

‍

Eso es menos reconfortante que una promesa del 100%, pero se acerca más a cómo se construyen realmente los sistemas fiables. Este incidente es un buen ejemplo, ya que ninguna de las partes sale bien parada.

‍

El cliente compró un resultado, no un dispositivo de mitigación.

El operador era uno de los tres proveedores de telecomunicaciones tradicionales del país. Su cliente final gestionaba servicios de juegos móviles, donde una interrupción no es un evento abstracto de SLA. Los jugadores notan la latencia y las desconexiones de inmediato, y no les importa qué logotipo de proveedor aparezca en el diagrama de red del operador.

‍

El servicio de tránsito protegido existente dependía de una plataforma DDoS líder en el mercado y muy conocida. Según el ingeniero de preventa de Nexusguard involucrado en la cuenta, la implementación se encontró con tres limitaciones prácticas.

‍

‍

Estas fueron limitaciones encontradas en esta implementación, no una afirmación de que cada instalación del proveedor mencionado se comporte de forma idéntica. El "blackholing" puede proteger al resto de una red, pero "protege" al objetivo dejándolo inaccesible. Eso puede ser un control de emergencia válido, pero no es el resultado que una empresa de juegos espera obtener cuando paga por un tránsito protegido.

‍

Un producto sólido puede convertirse en un servicio débil cuando nadie se hace responsable del resultado.

‍

Nosotros tampoco acertamos en todo al primer intento.

Nexusguard propuso una prueba de concepto en producción real de dos semanas. No se trató de una demostración de laboratorio con tráfico generado y condiciones de éxito cuidadosamente preparadas. El tráfico de producción a través de cinco prefijos se redirigió a nuestro servicio Clean Pipe con la mitigación activada.

‍

Durante una prueba de mitigación inicial, un bucle de enrutamiento dejó un host inaccesible. En un evento posterior de 15 Gbps, la política de tráfico produjo un resultado inaceptable y requirió ajustes adicionales. Estos incidentes ocurrieron antes de que la prueba de concepto fuera entregada al SOC para su gestión operativa completa.

‍

¿Por qué incluir nuestras propias dificultades?
Porque la afirmación defendible no es que nuestra primera política nunca pueda fallar, sino que el servicio incluía a personas responsables de reconocer un mal resultado, corregirlo y observar lo que sucedía después.

‍

Tras la entrega al SOC, el equipo mantuvo bajo revisión la línea base inicial y la configuración preestablecida. Ajustaron las medidas contra la suplantación de identidad (anti-spoofing), la retransmisión, los protocolos y el control de acceso frente al tráfico de ataque que observaban. Cuando las políticas corrían el riesgo de descartar tráfico legítimo, el equipo las ajustaba con precisión. Cuando los patrones de ataque lograban pasar, adaptaban el filtrado. Los límites de tasa siguieron siendo el último recurso en lugar de la estrategia completa.

‍

‍

Así es como se ve la mitigación en producción. Si la propuesta de un proveedor no deja espacio para este ciclo, probablemente esté describiendo una demostración y no un servicio operativo.

‍

Qué cambió tras el traslado del tráfico de producción

El operador trasladó cinco prefijos de producción en vivo a Nexusguard. La ruta de mitigación Clean Pipe permaneció activa, por lo que el tráfico ya pasaba por el proceso de mitigación en lugar de esperar a una desviación durante el ataque. El SOC supervisó los eventos, ajustó los perfiles y mantuvo comunicación con el operador a medida que se desarrollaban los ataques.

‍

En el transcurso de una semana, uno de los prefijos más activos recibió ataques de 60 Gbps y 80 Gbps. El servicio de la empresa de videojuegos no se vio afectado. En algunos casos, la plataforma detectó y mitigó el ataque antes de que el cliente se percatara de que estaba ocurriendo.

‍

El cliente no canceló el servicio de tránsito IP con protección DDoS del operador. Tanto el operador como su cliente de videojuegos quedaron satisfechos con el resultado, aunque no existe una cita aprobada del cliente, y no voy a inventar una para lograr un final más pulido.

‍

Qué convirtió un equipo en un servicio

‍

La visibilidad no es mitigación, y no pretendo afirmar que la empresa de videojuegos utilizara todas las pantallas del portal. Pero una vez que la mitigación funciona, la visibilidad es la forma en que un proveedor de servicios demuestra su valor y recupera la confianza.

‍

El ataque de 80 Gbps no fue la verdadera lección

Ochenta gigabits por segundo es un buen titular. Demuestra que el servicio de producción manejó un ataque serio, pero la capacidad por sí sola nunca fue el problema central.

‍

El servicio anterior fallaba cuando más de 10 Gbps alcanzaban y saturaban el enlace del cliente. Un ataque menor que logra pasar puede causar más daño que uno mayor que se elimina limpiamente. Los compradores que solo comparan la capacidad de limpieza anunciada están midiendo el tamaño de la estación de bomberos, no si el agua llega realmente a su edificio.

‍

Un dispositivo DDoS es un activo.
La protección contra DDoS es una capacidad operativa.

‍

Un servicio completo requiere cuatro elementos trabajando en conjunto: una ruta de mitigación que detenga el tráfico malicioso antes de llegar al enlace protegido, políticas adaptadas al comportamiento real del cliente, operadores que supervisen y realicen ajustes, y pruebas que expliquen los resultados.

‍

Qué preguntar a su operador o proveedor de servicios DDoS

No se limite a preguntar qué proveedor utilizan o cuántos terabits puede absorber su plataforma. Haga preguntas que revelen cómo se comporta el servicio en el peor de los casos.

‍

‍

Si las respuestas son vagas, es posible que la palabra "protegido" en su contrato de tránsito esté haciendo más trabajo que la protección en sí.

‍

La protección consiste en cómo responder cuando la protección no es perfecta

A la empresa de videojuegos de este incidente no le importaba si el operador poseía un famoso dispositivo de mitigación. Le importaba que un servicio vendido como protegido permitiera que el tráfico de ataque saturara su enlace.

‍

Nexusguard no recuperó la confianza prometiendo que nada saldría mal. Tuvimos nuestras propias dificultades iniciales durante la prueba de concepto. La confianza regresó porque el servicio de producción fue supervisado, corregido, ajustado y probado nuevamente ante ataques reales que alcanzaron picos de 80 Gbps.

‍

Ese es el estándar que los compradores deberían exigir. No protección contra el 100% de los ataques. No una promesa ficticia de perfección permanente. Sino la preparación para gestionar, recuperar, adaptar y mitigar eficazmente cuando el ataque —o la primera respuesta ante él— hace algo que usted no esperaba.

‍

Dicho esto, ese es el estándar que también debería aplicar a Nexusguard. Háganos las mismas preguntas. Oblíguenos a explicar qué hace nuestra protección, qué no hace, quién la opera y cómo respondemos cuando la primera respuesta no es lo suficientemente buena.

‍

El proveedor en el que se puede confiar no es el que promete que nada saldrá mal. Es el que está preparado para mostrarle qué sucede cuando algo sale mal.

‍

Preguntas frecuentes

¿Qué es el tránsito IP con protección DDoS?

El tránsito IP con protección DDoS combina la conectividad a internet con sistemas de detección y mitigación diseñados para detener el tráfico malicioso antes de que sature la conexión del cliente. Las preguntas importantes son dónde se realiza el filtrado, cómo se desvía o se mantiene el tráfico en la ruta, y qué tráfico puede llegar a alcanzar el enlace descendente.

‍

¿Por qué puede saturarse un enlace con protección DDoS?

Una cantidad suficiente de tráfico malicioso puede llegar al cuello de botella debido a los umbrales de detección, una cobertura de políticas incompleta, el comportamiento de desvío, los límites de tasa, las decisiones de blackholing o las fugas de ataques. La causa depende del diseño y del incidente; la presencia de un dispositivo de mitigación por sí sola no garantiza que el enlace protegido permanezca operativo.

‍

¿Es mejor la mitigación siempre activa que la mitigación bajo demanda?

La mitigación siempre activa elimina el retraso que implica desviar el tráfico tras la detección, pero conlleva sus propias consideraciones de enrutamiento, latencia, ajuste y costes. Los diseños bajo demanda pueden reducir el impacto en la ruta de tráfico normal, pero dependen de una detección y un desvío oportunos. La elección correcta depende de la red, el riesgo y el modelo operativo del cliente.

‍

¿Qué debe ofrecer un operador más allá de un dispositivo DDoS?

Un servicio completo debe incluir la creación de perfiles de tráfico, monitorización continua, gestión activa de la mitigación, optimización de políticas, comunicación durante incidentes, pruebas posteriores al evento y personal responsable de los resultados. El dispositivo es importante, pero no puede realizar el trabajo organizativo que lo rodea.