Anti-DDoS GAME: la protección contra los ataques en el universo del juego online

En la actualidad, se puede ejecutar un ataque de denegación de servicio (DDoS) con una facilidad desconcertante. Ya no es necesario tener conocimientos técnicos avanzados ni grandes medios para desestabilizar o incluso inhabilitar un servicio. La protección anti-DDoS, desarrollada por OVH desde 2013, permite limitar el alcance de estos ataques, cada vez más frecuentes (un 80% más entre 2013 y 2014). Sin embargo, el sector del juego y los e-sports se ve particularmente afectado por este fenómeno, y los mecanismos de protección implementados por los proveedores de alojamiento suelen evidenciar sus limitaciones ante la intensidad y la frecuencia de estos ataques, especialmente los que explotan el modo sin conexión del protocolo de red UDP, utilizado en la mayoría de los juegos y servidores de voz. En este sentido, OVH ha desarrollado una protección anti-DDoS específicamente adaptada a los servidores de juegos. Clément Sciascia, desarrollador responsable del proyecto en OVH, nos habla al respecto.

¿Por qué los ataques dirigidos contra los servidores de juegos constituyen un problema específico?

Primeramente, los ataques dirigidos contra los servidores de juegos son más frecuentes. Un jugador descontento, un adolescente que se cree hacker o se dedica a extorsionar, un adversario sin escrúpulos... Los pretextos para los ataques son diversos y, a menudo, triviales. Si los ataques se multiplican, esto significa que cada vez son más fáciles de ejecutar. Resulta muy sencillo acceder a tutoriales y scripts en internet y, a muy bajo precio, se puede alquilar un pequeño ejército de servidores cloud para bombardear un servidor con solicitudes.
Algunos sitios web ofrecen un sistema parecido al «DDoS as a Service». Pretenden comercializar un servicio de pruebas de aumento de la carga, pero muchos han comprendido el otro uso que se le puede dar.
Por otra parte, los servidores de juegos (o que alojan sistemas de comunicación por voz) son particularmente sensibles: el mínimo lag provocado por una sobrecarga del servidor o una saturación del ancho de banda, puede afectar a los jugadores: se ralentiza la partida o, si se trata de un servidor de voz, se entrecortan las conversaciones o sencillamente se cortan.
Ahora bien, el VAC utilizado en la solución anti-DDoS «clásica» funciona en tres fases: el análisis de paquetes, la aspiración del tráfico de entrada en caso de ataque y a continuación la mitigación (filtrado de paquetes ilegítimos). De este modo, la aspiración se activa ligeramente después del inicio del ataque. Se trata tan solo de algunos segundos, que se traducen en una ralentización casi imperceptible en una aplicación normal, pero que, en el caso de un servidor de juegos, ocasionan molestias bastante significativas a los jugadores.
Además, numerosos juegos y servicios de comunicación vocal como TeamSpeak o Mumble (que los jugadores de un mismo equipo usan para hablar durante una partida) utilizan el protocolo de comunicación UDP. El principal atractivo de este protocolo, también utilizado por los servicios de streaming, es la rapidez con la que se pueden transmitir pequeños paquetes de datos, consumiendo pocos recursos. En cambio, el UDP, a diferencia del TCP, funciona sin negociación. No existe una autorización previa (handshake) para enviar paquetes de parte de las máquinas que se comunican entre sí.
La autorización de conexión que se le concede a un jugador que se une a la partida se gestiona a nivel de aplicación (capa L7). Por eso resulta difícil distinguir a priori un paquete enviado desde una IP autorizada de un paquete enviado desde una IP falsa.
En otras palabras, la mitigación es un proceso complejo, ya que los paquetes ilegítimos tienen en apariencia las mismas características que los paquetes legítimos. Un buen ejemplo es el caso del ataque llamado «Source Engine Query» contra los servidores de Counter Strike: Source. El ataque consiste básicamente en sobrecargar el servidor con queries, con el objetivo de conseguir información sobre el estado del servidor. Si se filtran estos paquetes sin ninguna diferenciación, los verdaderos jugadores dejan de ver el servidor y de recibir información.
El VAC, capaz de gestionar con eficiencia una gran variedad de ataques, tiene más dificultades para hacer frente a este tipo de ataque. De ahí la necesidad de innovar, por ejemplo, a nivel del tráfico de salida de las máquinas. En el caso del ataque «Source Engine Query», la solución consiste en conservar en caché la respuesta del servidor para responder en su lugar en caso de flood. De este modo, las peticiones ilegítimas no consiguen agotar los recursos del servidor.

¿En qué se diferencia exactamente la protección anti-DDoS GAME de la protección anti-DDoS clásica? ¿Qué mecanismos han incorporado y cómo lo han conseguido?

La primera etapa de nuestro trabajo, que duró en total más de seis meses, consistió en establecer una lista con los juegos y servicios de comunicación por voz basándonos en dos criterios: su éxito comercial y su capacidad para «atraer» ataques DDoS. Tal y como nos explicó VeryGames, uno de nuestros clientes especializados en el alojamiento de servicios relacionados con videojuegos, hay juegos populares pero que reciben muy pocos ataques, como Farming Simulator, cuyos jugadores tienen una edad media superior a los de Minecraft. Lo que hicimos fue instalar esta selección de juegos en los laptops de nuestro laboratorio y conectarnos a los servidores para analizar las tramas de red. Esto nos permitió estudiar las distintas estrategias posibles de ataque para cada juego. En un primer momento, nos resultaba más fácil recurrir a la ingeniería inversa que ponernos en contacto uno por uno con todos los editores de juegos. Como aficionado a los juegos en línea, fue un poco frustrante, ya que no se trataba de meterse en grandes partidas con la excusa del I+D; lo que realmente nos interesaba era básicamente la fase de conexión entre la máquina del jugador y el servidor, porque es a este nivel que se deben detectar y tratar la mayoría de los ataques.
A continuación ideamos una infraestructura complementaria a la del anti-DDoS «clásico» (el VAC), que nos permite analizar el tráfico de entrada, pero también vigilar el tráfico de salida (algo imposible en el caso del VAC). De este modo, la mitigación es bidireccional (de entrada y de salida) y, además, permanece activa en todo momento para poder reaccionar desde el primer paquete de un ataque. El objetivo es que se pueda jugar en el servidor mientras dure el DDoS y, aún mejor, que los jugadores no se den cuenta de nada.

Un dispositivo Tilera situado lo más cerca posible de la máquina analiza los paquetes. Se elabora una respuesta específica para cada juego alojado.

Concretamente, como podemos ver en el esquema, un dispositivo Tilera, situado lo más cerca posible de la máquina y que inspecciona los paquetes TCP/IP y UDP, activa la mitigación y puede actuar como caché para aliviar la carga de la máquina atacada cuando resulta difícil distinguir los paquetes ilegítimos de los legítimos.
En el caso de los ataques «clásicos», es decir, los ataques que el VAC puede mitigar perfectamente, el dispositivo Tilera garantiza la protección hasta que el VAC se activa y toma el relevo. Además, como el Tilera se sitúa lo más cerca posible del servidor (al mismo nivel que los switches), la protección resulta eficaz incluso si el ataque proviene de la propia red de OVH. En estos casos, la mitigación filtra el ataque hasta que se identifican y suspenden las máquinas situadas en OVH que originaron el ataque.
Seleccionamos la solución Tilera por su potencia de cálculo teniendo en cuenta la carga a la que se enfrenta: varios millones de paquetes por segundo cribados por algoritmos especialmente complejos a una gran velocidad. La diferencia con respecto a la solución Arbor, con la que Tilera se combina en el sistema VAC, es que Tilera es un equipo que se suministra sin el software: el análisis lógico del tráfico se debe desarrollar íntegramente.
La implementación de este código de mitigación (algoritmos) se basa en la información recopilada durante la fase de ingeniería inversa. Era imposible crear un código de mitigación universal, así que hemos desarrollado un «perfil» para cada gran familia de juegos (Counter Strike, Minecraft...), es decir, un conjunto de reglas predefinidas que el usuario puede desplegar con un solo clic en el dispositivo Tilera (a través del manager) para filtrar el tráfico ilegítimo de entrada y salida de su servidor con la mayor exactitud posible.

Para cada gran familia de juegos (Counter Strike, Minecraft...) hemos desarrollado un «perfil»  que el usuario puede desplegar con un solo clic en el dispositivo Tilera para filtrar con la mayor precisión posible el tráfico ilegítimo entrante y saliente de su servidor.

¿Se trata de una protección única en su género? ¿Qué resultados han obtenido?

Después de implementar la solución, tuvimos que probarla. Lo hicimos a nivel interno en primer lugar y, después, con una prueba beta abierta al público que permitía alquilar cincuenta máquinas durante un periodo máximo de quince días. El objetivo pasaba por multiplicar los juegos probados para experimentar y analizar la eficiencia del anti-DDoS, detectar sus puntos débiles y corregir los algoritmos para erradicar los falsos positivos. También nos dimos cuenta de que Counter Strike: Global Offensive tenía un protocolo de conexión que varía en función del método de conexión utilizado por el jugador (a través de un explorador, uniéndose a un amigo, en conexión directa, etc.). ¡Todo un rompecabezas! En junio de 2015 logramos un resultado satisfactorio que nos permitía plantearnos con calma la comercialización de servidores GAME que incluyeran esta protección.
Sin embargo, nuestro trabajo no acaba ahí. Seguimos pendientes de los ataques y analizamos minuciosamente todos los que no habíamos identificado hasta ahora.
Algunos son fruto de una mala configuración del servidor por parte del administrador. Otros nos permiten optimizar aún más la protección propuesta, integrando la respuesta a nuestros algoritmos. De cualquier manera, no podemos cantar victoria: estamos jugando al ratón y al gato con todos aquellos que lanzan los ataques o, mejor dicho, con aquellos (afortunadamente menos numerosos) que intentan atravesar nuestra protección y que, a base de distintas pruebas, consiguen poner en marcha nuevas formas de ataque. Nunca vamos a encontrar una respuesta intemporal.
Lo importante es mantener siempre la ventaja suficiente para anticiparnos a las estrategias de ataque del mañana. Por este motivo, resultaría contraproducente desvelar demasiada información sobre el funcionamiento de nuestros algoritmos. Y, por otro lado, los juegos se actualizan regularmente, por lo que nosotros también tenemos que «actualizar» nuestros perfiles.
¿Somos los únicos que ofrecemos una protección anti-DDoS GAME eficaz? Actualmente, pocos proveedores de alojamiento proponen una protección igual. Sin embargo, no es imposible copiar este sistema: se necesitan dinero, material y tiempo humano. También requiere un cierto know how y probablemente ser reconocido como un actor creíble dentro del mercado del alojamiento de los servidores de juegos, para cooperar aún más con editores de juegos en el futuro. En cambio, OVH cuenta con un elemento exclusivo: la capacidad excedentaria del ancho de banda en su red backbone (con una capacidad de aproximadamente 3 Tbps, muy por encima del uso normal de todos nuestros clientes de OVH, sobre un total de 4 Tbps).
Ni la protección más perfeccionada podrá garantizar la disponibilidad de los servidores si los ataques consiguen ir por delante de los equipos de mitigación y saturar los enlaces de red. Y este es precisamente el motivo por el que los editores que explotan su propia plataforma tendrán cada vez más dificultades en el futuro. El aumento de la intensidad máxima de los ataques (varios centenares de Gbps actualmente y varias decenas de millones de paquetes por segundo) tiene dos consecuencias para los operadores con una red que no esté dimensionada para absorber este volumen de tráfico: la saturación de su backbone y la interrupción del servicio para el conjunto de sus clientes, y/o consecuencias financieras nada desdeñables (costo de tránsito para el tráfico excendentario).

¿Se podrán utilizar las investigaciones que se han realizado para desarrollar el anti-DDoS GAME en otros servicios de OVH y otros sectores de actividad diferentes del sector de juegos en línea? ¿Esto conduciría al mejoramiento del anti-DDoS «clásico» (VAC)?

No tiene mucho sentido observar el tráfico de salida de los 200 000 servidores alojados en OVH. El VAC funciona muy bien en la gran mayoría de los ataques. Sin embargo, se podrían concebir otras aplicaciones que tuvieran la protección que hemos desarrollado específicamente para los servidores GAME; por ejemplo, para mejorar la protección de los servidores VoIP, ya que también utilizan el protocolo UDP y, por lo tanto, están expuestos a los mismos riesgos que muchos servidores de juegos. O incluso para proteger a los servidores SQL, puesto que muchos también explotan este protocolo no conectado (MSSQL principalmente). De igual manera, algunos servicios como el streaming de video o de música podrían estar interesados en una opción anti-DDoS Pro bidireccional.

A largo plazo, la evolución prevista contempla la fusión del anti-DDoS y del routing en vRouter (aún en proyecto), lo cual permitiría simplificar la arquitectura de la red OVH, garantizar un mejor control del dispositivo y un seguimiento completo. Esta evolución requerirá un cambio de tecnología ya que tiene que ser compatible con el x86 (lo cual no es posible con Tilera).

Mi cuenta de clienteContact SalesWebmail OVHcloud Blog

¡Bienvenido/a a OVHcloud!

Identifíquese para contratar una solución, gestionar sus productos y servicios, y consultar sus pedidos

Conectar