Proteger tu servidor de RAGE MP o alt:V frente a ataques DDoS

Un servidor multijugador de GTA es un objetivo agradecido para cualquier atacante: cuelga de una única dirección IP, su puerto figura en una lista pública de servidores y cada caída la ven todos los jugadores a la vez. Este artículo muestra primero lo que puedes conseguir de verdad en tu propio servidor y después, con la misma claridad, dónde se acaban esas posibilidades.

Si todavía no tienes claro si hay un ataque en marcha, mídelo primero: Detectar un ataque DDoS describe el diagnóstico paso a paso. Las bases técnicas están en ¿Qué es un ataque DDoS?.

¿Por qué reciben ataques tan a menudo precisamente RAGE MP y alt:V?

La escena de roleplay que gira alrededor de GTA V es pequeña, pública y muy competitiva. Un servidor vive de sus jugadores habituales, y esos jugadores se pasan enseguida a otro Discord cuando hay caídas largas. Eso hace que atacar salga a cuenta: nadie necesita mantener el ataque durante horas, bastan unos minutos en la mejor franja de juego, la noche de la inauguración o durante un wipe anunciado.

A eso se suma que nadie tiene que buscar mucho. Las dos plataformas anuncian tu servidor en una lista pública si tú quieres, RAGE MP mediante announce en conf.json y alt:V mediante announce y token en server.toml. Quien aparece ahí está publicando su dirección IP y su puerto. Por eso un servidor recién dado de alta recibe a menudo los primeros intentos de conexión automatizados ya en la primera hora, mucho antes de que llegue el primer jugador real.

El tercer motivo es de naturaleza técnica: el tráfico del juego va por UDP. UDP no tiene un establecimiento de conexión que el remitente tenga que esperar, así que la dirección de origen se puede falsificar. Quien conoce tu puerto puede bombardearlo sin recibir jamás una respuesta y sin enseñar su propia dirección.

Los puertos de los que hablamos

Antes de escribir la primera regla conviene que sepas para qué sirve cada puerto. Las dos plataformas necesitan más de uno.

Aquí hay dos particularidades importantes. En RAGE MP el puerto HTTP está atado al puerto de juego y es siempre el siguiente hacia arriba: si mueves el puerto de juego al 22015, el puerto de archivos se va con él al 22016. En alt:V, el tráfico del juego y la entrega de archivos comparten el mismo número de puerto, una vez por UDP y otra por TCP. Quien entrega los archivos del cliente a través de una red de distribución de contenidos (opciones useCdn y cdnUrl en server.toml) saca la parte TCP de su propia línea. El tráfico del juego por UDP no se ve afectado.

Lo que puedes hacer tú mismo antes de gastar dinero

Los pasos siguientes no detienen un ataque volumétrico, eso no lo consigue ningún software en el servidor. Lo que sí barren es todo lo que está por debajo: escaneos de puertos, avalanchas de conexiones desde unas pocas fuentes, ataques a la base de datos en lugar de al juego y el abuso de tu propio puerto de archivos. Eso es la mayor parte de lo que molesta a un servidor pequeño en el día a día, y solo cuesta media hora.

Paso 1: inventario de lo que escucha hacia fuera

ss -tulnp

La columna interesante es la de la dirección local. Todo lo que ahí esté en 0.0.0.0 o [::] es accesible desde internet, y todo lo que esté en 127.0.0.1 solo en local. En un servidor de roleplay típico aparecen enseguida, junto al juego, una base de datos, una caché, un panel web y a veces un servidor de voz. Cada uno de esos servicios es una superficie de ataque propia, y ninguno tiene que estar abierto solo porque esté funcionando.

Paso 2: limitar el firewall a los puertos que de verdad hacen falta

En un servidor de RAGE MP son tres aperturas: SSH, puerto de juego y puerto de archivos. Permite en cualquier caso primero tu puerto SSH, porque si no te quedas fuera de tu propio servidor con la última línea:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 22005/udp
ufw allow 22006/tcp
ufw enable

Para alt:V, las dos reglas del juego son estas otras:

ufw allow 7788/udp
ufw allow 7788/tcp

Comprueba después con ufw status verbose que de verdad solo estén abiertos esos puertos, y repite ss -tulnp. La configuración detallada, con IPv6 y las trampas habituales que te dejan fuera, la tienes en Configurar el firewall UFW.

Paso 3: sacar la base de datos y la caché de la red

En la mayoría de los gamemodes, MariaDB y Redis corren en la misma máquina que el servidor de juego y entonces no necesitan ninguna dirección en internet. En la configuración de MariaDB (en Debian y Ubuntu /etc/mysql/mariadb.conf.d/50-server.cnf) va para eso esta línea:

bind-address = 127.0.0.1

Y en /etc/redis/redis.conf:

bind 127.0.0.1 ::1
protected-mode yes

Después reinicia los dos servicios y compruébalo con ss -tulnp. Una caché abierta y sin contraseña no es un problema de DDoS, es una vía de entrada, y se escanea las veinticuatro horas.

Paso 4: limitar la tasa de conexiones en el puerto de archivos

El puerto TCP de los archivos del cliente es el sitio donde un límite de tasa en el servidor sirve realmente de algo, porque ahí hay un establecimiento de conexión de verdad y, con él, una dirección de origen en la que se puede confiar a medias. Bastan dos reglas, aquí para RAGE MP en el puerto 22006:

iptables -A INPUT -p tcp --dport 22006 --syn -m connlimit --connlimit-above 20 --connlimit-mask 32 -j DROP
iptables -A INPUT -p tcp --dport 22006 --syn -m hashlimit --hashlimit-name gtahttp --hashlimit-mode srcip --hashlimit-above 30/sec --hashlimit-burst 60 -j DROP

La primera regla limita las conexiones abiertas a la vez por dirección de origen; la segunda, los intentos de conexión por segundo. Para alt:V pon 7788 en los dos sitios. Tres avisos al respecto: ufw limit es aquí demasiado tosco y solo entiende de TCP, los valores numéricos los ajustas al tamaño de tus archivos del cliente, y las reglas solo sobreviven a un reinicio con iptables-persistent o como entrada en /etc/ufw/before.rules.

En el puerto de juego UDP, en cambio, la misma técnica aporta poco, porque ahí los remitentes están falsificados: un bloqueo por dirección de origen no alcanza entonces a nadie, salvo por casualidad a un jugador real. Lo que sí conviene vigilar es el seguimiento de conexiones del kernel:

cat /proc/sys/net/netfilter/nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

Cuando el primer valor se acerca al segundo, el kernel descarta paquetes con independencia de si pertenecen a un ataque o a un jugador. En el log del sistema aparece entonces nf_conntrack: table full, dropping packet.

Paso 5: usar lo que las dos plataformas ya traen de serie

Los dos núcleos de servidor traen ajustes pensados justamente contra el abuso de conexiones, y de fábrica están en su valor más permisivo. En RAGE MP eso afecta a tres claves de conf.json:

{
    "bind": "0.0.0.0",
    "port": 22005,
    "announce": true,
    "maxplayers": 200,
    "disallow-multiple-connections-per-ip": true,
    "limit-time-of-connections-per-ip": 1000,
    "enable-http-security": true
}

Es un extracto, las demás claves se quedan como están. disallow-multiple-connections-per-ip impide varias conexiones simultáneas desde la misma dirección, limit-time-of-connections-per-ip obliga a dejar un intervalo mínimo entre dos intentos de conexión (0 desactiva el límite) y enable-http-security activa las comprobaciones adicionales del servidor HTTP integrado. Contrasta la unidad de tiempo del valor central con la documentación de tu versión de servidor antes de subirlo. Y cuenta con que la primera opción deja fuera a los jugadores que comparten una misma conexión: pisos compartidos, familias y redes de empresa.

En alt:V, las opciones correspondientes están en server.toml:

host = '0.0.0.0'
port = 7788
players = 200
announce = true
duplicatePlayers = 4
connectionQueue = true
useEarlyAuth = true

duplicatePlayers limita cuántos jugadores pueden estar conectados a la vez desde la misma dirección IP. El valor por defecto es 4096, así que en la práctica no es ningún límite. connectionQueue mete los intentos de conexión en una cola en lugar de atenderlos todos de golpe. useEarlyAuth coloca un inicio de sesión delante del servidor de juego: el cliente tiene que iniciar sesión antes de entrar en tu mundo de juego, lo que descarta de entrada las avalanchas de conexiones sencillas. La dirección de la página de acceso va en earlyAuthUrl.

Paso 6: una whitelist mientras dure la emergencia

Si un ataque va por la mecánica del juego, es decir, por intentos de conexión masivos en lugar de por puro ancho de banda, una whitelist es la medida más eficaz a corto plazo. En alt:V, para funcionar en modo cerrado basta con un password en server.toml. En código, la forma más sencilla es esta, aquí para RAGE MP:

const whitelist = new Set(['JugadorUno', 'JugadorDos']);

mp.events.add('playerJoin', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('El servidor está cerrado en este momento.');
    }
});

Y la misma lógica para alt:V:

import * as alt from 'alt-server';

const whitelist = new Set(['JugadorUno', 'JugadorDos']);

alt.on('playerConnect', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('El servidor está cerrado en este momento.');
    }
});

Los dos ejemplos son deliberadamente simples y tienen un límite claro: el nombre visible no es un identificador fuerte. Quien mantenga una whitelist de forma permanente hará mejor en comprobar el identificador del inicio de sesión previo o su propia gestión de cuentas. Pero sobre todo: un kick solo ocurre después de que la conexión haya llegado al servidor. Contra los paquetes que ya están llenando la línea no sirve de nada.

Paso 7: la entrada en la lista de servidores y la higiene de la IP

Desactivar la entrada en la lista de servidores (announce en false) suena a solución rápida y casi nunca lo es. Quien ya tiene tu dirección IP sigue llegando a ti, y tus jugadores dejan de encontrarte. El paso solo tiene sentido junto con un cambio de dirección IP, porque solo entonces pierde el atacante su objetivo.

A largo plazo aporta más el orden en los sitios donde la dirección se acaba conociendo de pasada: llevar la web y el foro en otra máquina, borrar los registros DNS antiguos (también mail, ftp y los nombres de prueba de los inicios), no ejecutar bots de Discord ni indicadores de estado desde el servidor de juego y separar el servidor de voz. Aun así, la dirección de un servidor de juego no se puede esconder del todo: el tráfico del juego por UDP tiene que llegar directamente hasta ti, y una red de distribución de contenidos por delante para las webs no cambia eso. Lo que ayuda aquí no es el disimulo, sino una dirección que tenga un filtrado detrás.

Paso 8: recoger mediciones antes de que la cosa se ponga seria

Cuando llega el momento crítico solo cuenta lo que puedes demostrar. Prepárate de antemano los comandos con los que registras en segundos la tasa de paquetes entrantes y el estado de las conexiones:

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) paquetes/s entrantes en $IF"
ss -s

Anota estos valores una vez en funcionamiento normal, en la franja de más jugadores, porque sin un valor de referencia cualquier cifra durante un ataque no vale nada. Si tu servidor de juego corre como servicio de systemd, entra también journalctl -u <nombre-del-servicio> -n 200: las avalanchas de conexiones suelen dejar ahí un rastro claro. Hay una limitación que conviene conocer: en el servidor solo mides lo que ha conseguido pasar. Si delante hay un filtrado, la cifra fiable está en el gráfico de tráfico del área de cliente y no en /proc.

Dónde se acaban estas medidas

Cualquier regla en el servidor actúa solo después de que el paquete haya llegado. Esa es la frase decisiva. Un firewall decide sobre paquetes que ya han pasado por tu línea, y justo esa línea es el objetivo de un ataque volumétrico.

Los órdenes de magnitud son estos: un servidor individual cuelga normalmente de 1 Gbit/s. Con los paquetes más pequeños eso equivale a unos 1,5 millones de paquetes por segundo, y físicamente no cabe más. Para taponar esa línea nadie necesita un ataque récord, bastan de 2 a 5 Gbit/s. A modo de comparación, un ataque medido de verdad en la red de KernelHost en Fráncfort del Meno: más de 473,4 Gbit/s y más de 41,5 millones de paquetes por segundo contra un único servicio. Eso es unas 470 veces una línea de gigabit, y hasta una conexión de 10 Gbit/s se queda a un factor de 47 de ahí.

Cuando la línea está llena, ya descarta el router que hay delante, y lo hace sin mirar el paquete concreto. Tus jugadores están entonces en la misma cola que el ataque. Nada de eso lo cambia iptables, ni un plugin, ni una CPU más potente, porque el cuello de botella está delante del servidor. A eso se suma que en las avalanchas de UDP las direcciones de origen están falsificadas: sencillamente no hay nadie a quien tenga sentido bloquear.

Por eso lo único eficaz es un filtrado que se sitúe en la red por delante de tu línea y que tenga allí tanta capacidad que el ataque no llegue a saturarla.

Lo que KernelHost pone frente a eso

La protección permanente que ya funciona en todos los servidores

En KernelHost (KernelHost GmbH, con sede en Viena, Austria) todos los servidores llevan una protección DDoS de dos niveles permanentemente activa, sin pedirla, sin configurarla y sin recargo:

• Nivel 1: red global de scrubbing con 17 Tbps de capacidad de mitigación. Los ataques volumétricos se interceptan cerca de su origen, antes incluso de que lleguen al centro de datos.
• Nivel 2: filtrado Arbor en tiempo real con 3,2 Tbps. Está in situ en el centro de datos maincubes de Frankfurt am Main (Alemania) y se encarga del trabajo fino justo delante de tu servidor, paquete a paquete.

Igual de importante es lo que no ocurre: no se utiliza null-routing. Tu dirección IP se queda en la red durante un ataque y solo se descartan los paquetes dañinos. Para un servidor de roleplay esa diferencia es considerable, porque una dirección retirada con null-routing es, para tus jugadores, indistinguible de un ataque con éxito. Si durante un incidente ya no consigues entrar por SSH, sigues llegando al sistema por la consola VNC del área de cliente, que funciona con independencia de la conectividad de red del servidor.

Advanced DDoS Protection para proyectos atacados de forma continua

A algunos proyectos no los golpean una sola vez, sino durante semanas. Para ese caso existe la Advanced DDoS Protection desde 50,00 € al mes, PrePaid y sin permanencia mínima, sin plazo de preaviso, sin contrato y sin cuota de instalación. Incluye:

• una IP de protección dedicada del núcleo de red de Fráncfort, a la que se cambia tu servidor sin ninguna modificación por tu parte,
• reglas de protección que gestionas tú mismo, por puerto y protocolo, directamente en el área de cliente,
• cambios que surten efecto en tiempo real, sin ticket y sin esperas,
• un perfil de protección adaptado a cada juego, de entre más de 40 perfiles para juegos, servicios y protocolos, RageMP y alt:V incluidos, además de perfiles genéricos para tus propias aplicaciones TCP y UDP.

La diferencia práctica está en el control: decides tú qué perfil corre en 22005 UDP y qué regla se aplica a 22006 TCP, incluso en mitad de un ataque.

Los dos niveles, comparados

Errores frecuentes y sus soluciones

Todos los puertos abiertos porque si no algo deja de funcionar: eso es casi siempre un diagnóstico equivocado. Apunta con ss -tulnp qué servicio necesita qué puerto y abre exactamente esos. Si después falta algo, suele deberse a un servicio que de todas formas solo está enlazado en local.

Bloquear las direcciones IP de los atacantes: en una avalancha UDP los remitentes están falsificados. Con eso bloqueas direcciones que no tienen nada que ver y, en el peor de los casos, a tus propios jugadores. Solo tiene sentido en conexiones TCP con un establecimiento completo, es decir, en el puerto de archivos.

Poner solo announce en false: el servidor desaparece de la lista, pero la dirección IP sigue siendo la misma. Un ataque en marcha continúa igual, solo que tus jugadores ya no encuentran el servidor. Sin un cambio de dirección, el paso no aporta nada.

Limitar la tasa en el puerto de juego UDP: las redes móviles y las conexiones de empresa agrupan a muchos jugadores detrás de una sola dirección. Un límite por dirección de origen echa ahí a jugadores reales, mientras que los remitentes falsificados de la avalancha se quedan tan tranquilos.

Más CPU y más RAM como respuesta al DDoS: las dos cosas ayudan contra un gamemode sobrecargado, no contra una línea llena. El cuello de botella está delante del servidor, y ahí un hardware más potente no cambia nada.

Reiniciar en mitad del ataque: borra todos los contadores que habrías necesitado para un aviso sólido, y después el ataque continúa igual. Recoge primero las mediciones y actúa luego.

La base de datos abierta a internet porque el panel web corre en otra máquina: lleva la conexión por un túnel SSH o por una red privada. Si eso no es posible, limita al menos el acceso a la única dirección de origen que de verdad lo necesita.

Si está ocurriendo ahora mismo

Recoge primero las mediciones del paso 8 para que tu aviso sea sólido: el momento con zona horaria, la dirección IP y el puerto afectados y la tasa de paquetes medida con indicación del sentido. Después abre un ticket de soporte. Con un ataque en marcha puedes localizarnos además en el chat de emergencia de WhatsApp en el +43 650 8209883. La visión general independiente del proveedor sobre los siguientes pasos la da Proteger el servidor frente a ataques DDoS.