Proteger tu servidor de FiveM frente a ataques DDoS

Un servidor de roleplay de FiveM que desaparece una y otra vez durante unos minutos por las noches rara vez tiene un problema de hardware. Lo habitual es que haya un ataque en marcha, y justo cuando hay más jugadores conectados. Este artículo empieza por lo que puedes asegurar tú mismo sin coste añadido, sigue por el punto en el que esas medidas se acaban técnicamente y termina con lo que tiene que ocurrir en la red que hay delante del servidor.

Todo lo que sigue se refiere a un FXServer sobre Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS. Los comandos están escritos para root; si trabajas como usuario normal, antepón sudo.

Si el ataque está en marcha ahora mismo: no cambies nada en la configuración y no reinicies el servidor. Guarda primero las mediciones (consulta el apartado "Registrar los datos"), porque cuando el ataque pase habrán desaparecido.

¿Por qué atacan tan a menudo precisamente a los servidores de FiveM?

Los proyectos de FiveM reúnen varias características que los convierten en un objetivo cómodo. Primero, un servidor de roleplay publica su dirección por sí solo: la entrada en la lista de servidores de Cfx.re contiene la dirección IP y el puerto en texto claro, porque de lo contrario los jugadores nunca encontrarían el servidor. Segundo, la comunidad juega a horas fijas, así que una caída a las ocho de la tarde es lo más visible que hay. Tercero, existe competencia entre proyectos, jugadores baneados y conflictos internos, y un ataque no le cuesta a quien lo encarga ni conocimientos ni un dinero digno de mención.

A eso se suma un detalle técnico: el tráfico del juego va por UDP. UDP no tiene un establecimiento de conexión que se pueda exigir, y las direcciones de origen se pueden falsificar. Por tanto, un atacante no necesita entrar en tu servidor ni dirigirse a él correctamente para generarle carga. Qué es en detalle un ataque DDoS lo explica el artículo ¿Qué es un ataque DDoS?.

Los puertos que de verdad importan

Por defecto, un FXServer se enlaza a un único puerto, y lo hace en los dos protocolos. En server.cfg:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

Estas dos líneas son toda la superficie de ataque del juego en sí:

• 30120 UDP transporta el tráfico del juego en curso: datos de posición, sincronización y voz.
• 30120 TCP transporta el establecimiento de la conexión y los endpoints HTTP integrados del FXServer: /info.json, /players.json y /dynamic.json.
• 40120 TCP es el valor por defecto de la interfaz web de txAdmin.
• 3306 TCP pertenece a la base de datos que necesita cualquier framework ESX o QBCore.
• 22 TCP es tu acceso SSH.

De estos cinco puertos, exactamente dos deben estar en la red abierta. Los otros tres son el error evitable más frecuente en los servidores de FiveM.

Lo que puedes hacer tú mismo antes de gastar dinero

Este apartado es el más largo, y es a propósito. Un servidor bien configurado aguanta por su cuenta los ataques pequeños y medianos, esté alojado donde esté.

1. Inventario: ¿qué está escuchando realmente?

Antes de escribir una sola regla, mira qué ofrece tu servidor hacia fuera. No lo adivines, compruébalo:

ss -lntup

La columna interesante es la de la dirección local. 0.0.0.0:30120 y [::]:30120 significan "accesible desde todo internet", 127.0.0.1:3306 significa "solo local" y no necesita ninguna regla de firewall. Junto al juego suelen aparecer ahí txAdmin, MariaDB, un servidor web y algún servicio de voz olvidado hace tiempo. La vista del atacante te la da un escaneo de puertos desde fuera:

nmap -Pn -p- --min-rate 1000 IP.DE.TU.SERVIDOR

2. Dejar abierto solo lo que el juego necesita de verdad

A FiveM le bastan dos aperturas hacia fuera, todo lo demás se restringe o directamente no se publica. Con UFW queda así, y en este orden exacto para que no te quedes fuera de tu propio servidor:

ufw allow 22/tcp comment 'SSH'
ufw allow 30120/tcp comment 'FiveM'
ufw allow 30120/udp comment 'FiveM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sustituye 203.0.113.10 por tu propia dirección. En una conexión con dirección cambiante esto resulta poco práctico, y el camino mejor viene más abajo. La guía completa, con vía de rescate incluida, la tienes en Configurar el firewall UFW sin quedarte fuera del servidor.

La base de datos no tiene nada que hacer en la red abierta bajo ningún concepto. Comprueba en /etc/mysql/mariadb.conf.d/50-server.cnf que ahí ponga:

bind-address = 127.0.0.1

3. Asegurar el puerto de query y los endpoints HTTP

En la parte TCP del 30120, el FXServer responde a peticiones HTTP sin que nadie tenga que iniciar el juego. Mira qué entrega ahí:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600

/players.json lista los jugadores conectados junto con sus identificadores. Resulta cómodo para páginas de estado y bots de Discord, pero también es una invitación: el endpoint se puede consultar tantas veces como uno quiera, cada consulta le cuesta trabajo a tu servidor y el contenido le revela a un atacante cuándo merece la pena atacar. Dos contramedidas no cuestan nada. La primera: los endpoints de los jugadores no pintan nada en la respuesta, y para eso basta una línea en server.cfg:

sv_endpointPrivacy true

La segunda: si tu bot de Discord o tu web muestran el número de jugadores, no consultes el endpoint desde el navegador del visitante, guarda el resultado en caché a intervalos fijos. Así, una página de estado muy visitada genera una consulta por intervalo en lugar de una por visitante.

4. No dejar txAdmin en la red abierta

El puerto 40120 es una interfaz web con acceso total a tu servidor. Si no tienes una dirección IP fija para la regla de apertura, deja el puerto cerrado desde fuera y llega hasta él por un túnel SSH; después abres en local http://127.0.0.1:40120:

ssh -N -L 40120:127.0.0.1:40120 root@IP.DE.TU.SERVIDOR

5. Limitar las conexiones y la tasa de paquetes

Contra los ataques pequeños y los bots mal hechos ayuda un límite superior por dirección de origen:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 12 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name fivem_udp --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

La primera regla descarta las conexiones TCP nuevas en cuanto una dirección tiene más de doce abiertas a la vez; la segunda descarta los paquetes UDP a partir de más de 600 paquetes por segundo sostenidos desde el mismo origen. Las dos cifras son puntos de partida, no verdades absolutas: un servidor de roleplay lleno genera muchos más paquetes que uno vacío, y quien ajusta demasiado fino echa fuera a sus propios jugadores. Mide primero una semana de funcionamiento normal.

Dos avisos al respecto. Las reglas de iptables a secas desaparecen tras un reinicio; en Debian y Ubuntu se guardan así:

apt-get install -y iptables-persistent
netfilter-persistent save

Y con UFW, ese tipo de reglas van en /etc/ufw/before.rules, porque de lo contrario desaparecen con el siguiente ufw reload. Otro cuello de botella que se pasa por alto a menudo es el seguimiento de conexiones del kernel: si se llena, el servidor descarta también los paquetes legítimos y en el log aparece "nf_conntrack: table full". El valor actual y el límite los muestra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. La entrada en la lista de servidores

Aquí conviene la honestidad antes que el pensamiento mágico: tu dirección IP no se puede mantener en secreto. Cualquier jugador que se haya conectado una vez la conoce, y la entrada de la lista la publica de todas formas. Quien no necesite la entrada pública, porque el proyecto funciona solo por Discord y conexión directa, puede desactivarla con sv_master1 "". Eso cuesta, eso sí, toda la visibilidad para los jugadores nuevos, y solo sirve contra el más cómodo de los atacantes.

Hay dos costumbres más eficaces. No publiques tú mismo la dirección IP en bruto en ninguna parte, ni en el canal de Discord ni en la página del proyecto. Y conecta a tus jugadores mediante un nombre de host, para poder cambiar la dirección llegado el caso sin que se rompan todas las referencias. El clásico aquí son los registros DNS antiguos: un registro A olvidado que apunte a la dirección anterior deja sin efecto cualquier cambio.

7. Whitelist y comprobación al entrar

Una whitelist funciona contra todo lo que usa la vía normal de entrada: troles, clientes con cheats, botnets montadas con cuentas desechables. Se implementa en el lado del servidor en el evento playerConnecting, donde retienes la conexión con las funciones de deferrals, compruebas el identificador y solo entonces das paso. A eso se suman una comprobación estricta de la cuenta, un límite de jugadores realista y el ScriptHook desactivado:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 48
sv_scriptHookAllowed 0

Pon una contraseña de RCON solo si de verdad necesitas RCON, porque ese acceso está en el mismo puerto abierto. Y hay algo que tiene que quedar claro: una whitelist protege tu lógica de juego, no tu línea. Un atacante que inunda tu servidor no quiere entrar. Sus paquetes se rechazan, pero han llegado igualmente, y ese es justo el problema.

8. Validar los eventos de red en el lado del servidor

Muchas caídas que se comunican como ataque DDoS se deben a un único script. Los recursos de FiveM se comunican mediante eventos de red, y un evento que el servidor ejecuta sin comprobarlo es una puerta abierta: quien lance desde el cliente un TriggerServerEvent con valores arbitrarios puede generar dinero, hacer aparecer vehículos o disparar consultas a la base de datos en bucle hasta que el servidor se pare.

Tres reglas atajan la mayor parte. Registra con RegisterNetEvent únicamente los eventos que de verdad deban venir del cliente. No te fíes nunca de los valores que manda el cliente, determina el jugador en el lado del servidor a partir de source. Y limita cuántas veces puede un jugador disparar el mismo evento, sobre todo en todo lo que consulte la base de datos. Si el servidor va a tirones mientras la línea está tranquila, resmon 1 en la consola del cliente muestra el tiempo de proceso por recurso, y el culpable suele estar arriba del todo.

9. Registrar los datos para tenerlos cuando haga falta

El paso más importante es el que casi nadie da antes de tiempo: crear una base de comparación mientras todo funciona con normalidad. Sin un valor normal no puedes decir, después de un incidente, si 40.000 paquetes por segundo eran muchos o simplemente un martes por la noche. Con apt-get install -y vnstat sysstat la medición corre de forma permanente. Durante un incidente bastan cuatro comandos: tasas de paquetes por segundo, contador de descartes de la interfaz, mensajes del kernel y una muestra breve del tráfico.

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 port 30120 -c 200 -q

Con tcpdump vale una norma: limítalo siempre con -c, porque una captura a plena carga añade trabajo a un servidor que ya está saturado. Cómo interpretar los valores lo explica Detectar un ataque DDoS.

El punto en el que estas medidas dejan de servir

Llega ahora la parte que ningún archivo de configuración puede resolver. Todas las medidas anteriores corren en tu servidor, es decir, al final de la línea. Una regla de firewall decide sobre un paquete que ya ha pasado por el cable. Puedes descartarlo, pero no puedes hacer que no se haya enviado.

Echa cuentas una vez. Un servidor de juego típico está conectado a 1 Gbit/s, o sea, 125 megabytes por segundo, y la línea se llena en cuanto alguien manda más. Los ataques contra proyectos de FiveM se mueven normalmente entre 5 y 50 Gbit/s, es decir, entre cinco y cincuenta veces tu línea. Que tu regla de iptables por detrás sea buena o no ya da igual, porque los paquetes de tus jugadores dejan de pasar mucho antes.

La segunda magnitud es la tasa de paquetes, y golpea a menudo antes que el ancho de banda. Con paquetes pequeños de 64 bytes caben en una línea de 1 Gbit/s unos 1,49 millones de paquetes por segundo. Un kernel de servidor normal procesa, según la CPU y la tarjeta de red, unos cientos de miles antes de empezar a descartar. Así que un ataque que no llena ni un tercio de tu línea puede dejar tu servidor fuera de combate igualmente, porque el tiempo de proceso se va en descartar. Los operadores lo viven como "pero si la carga no era ni alta y aun así se cayó todo".

Para hacerse una idea de las magnitudes que se dan de verdad: en servidores de KernelHost se han filtrado, entre otros, un ataque de más de 473,4 Gbit/s con más de 41,5 millones de paquetes por segundo contra un servidor de voz y un flood UDP de más de 112,2 Gbit/s contra un servidor de juego. Para eso no existe ningún ajuste local. Los ataques volumétricos tienen que terminar en la red que hay delante del servidor.

Lo que KernelHost pone frente a esos ataques

La protección permanente incluida en todos los servidores

La protección DDoS de KernelHost está estructurada en dos niveles y activa de forma permanente, sin que tengas que activar, pedir ni configurar nada:

• Nivel 1: 17 Tbps de capacidad de mitigación en la red global de scrubbing. Los ataques volumétricos se limpian cerca de su origen, antes de que lleguen al centro de datos.
• Nivel 2: filtrado Arbor en tiempo real con 3,2 Tbps en Fráncfort del Meno. Justo delante del servidor se reconocen y se descartan los patrones propios de cada protocolo, paquete a paquete.

Dos propiedades marcan la diferencia. La protección funciona de forma permanente y no tiene que reaccionar primero a un ataque, así que no hay unos minutos iniciales en los que el servidor esté fuera. Y no se utiliza null-routing: tu dirección IP se queda en la red y solo se descartan los paquetes dañinos. Quien retira la dirección IP de la red consigue para ti el mismo resultado que el atacante. El centro de datos es maincubes, en Frankfurt am Main (Alemania). Qué juegos y protocolos están cubiertos lo detalla Protección DDoS para servidores de juego en tiempo real.

Advanced DDoS Protection para proyectos bajo fuego continuo

Algunos proyectos no reciben ataques de vez en cuando, sino de forma dirigida y durante semanas. Para esos existe la Advanced DDoS Protection desde 50,00 € al mes, PrePaid y sin permanencia mínima. La diferencia no está en más capacidad, sino en el control:

• IP de protección dedicada del núcleo de red de Fráncfort, a la que se cambia tu servidor dentro de nuestra propia red. En tu lado no hace falta ninguna modificación.
• Reglas de protección autogestionables por puerto y protocolo en el área de cliente: tú defines qué se permite en 30120 UDP y qué en 30120 TCP, sin tener que abrir un ticket para ello.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso.
• Perfil de protección adaptado a cada juego. Para FiveM hay un perfil listo, igual que para aplicaciones modificadas y propias en cualquier puerto TCP o UDP.

Los dos niveles, comparados

Para la mayoría de los proyectos de FiveM basta con la protección permanente incluida junto a una configuración limpia del servidor. La Advanced DDoS Protection es la respuesta a que alguien se lo tome como algo personal.

Errores frecuentes y sus soluciones

"Cambié la dirección IP y dos horas después estaba otra vez fuera": el atacante ha sacado la dirección nueva de la misma fuente que la antigua, normalmente la entrada de la lista, un bot de Discord o un registro DNS viejo. Cambiar de dirección da tiempo, no es una solución.

"Mis reglas de iptables no hacen nada": hay tres causas frecuentes. Las reglas están detrás de las cadenas de UFW y no se alcanzan nunca, se perdieron con el último reinicio (entonces ayudan netfilter-persistent save o una entrada en /etc/ufw/before.rules), o el ataque es volumétrico y la regla trabaja correctamente en una línea que ya está llena. Comprueba con iptables -L INPUT -n -v si suben los contadores de aciertos. Si se quedan a cero, la regla no se alcanza.

"El servidor funciona, pero todos los jugadores tienen rubber banding": eso suele ser un script antes que un ataque. Mira primero con resmon 1 si algún recurso se está comiendo el tiempo de proceso. Si sar -n DEV 1 10 no muestra nada llamativo, no era un ataque DDoS.

"txAdmin muestra cientos de intentos de conexión fallidos": eso es un flood de intentos de entrada y golpea a la lógica del juego, no a la línea. Contra eso funcionan la whitelist, la comprobación de la cuenta y el límite de conexiones por dirección de origen.

"Mi proveedor anterior bloqueó mi dirección IP": eso es null-routing. Con ello el proveedor protege su propia red; para ti el resultado es idéntico al de un ataque con éxito, normalmente durante horas después. En caso de duda, pregunta si se filtra o si se hace null-routing. La respuesta dice más sobre tu disponibilidad que cualquier dato de hardware.

"En el tcpdump no veo nada llamativo": si el tráfico ya se filtra en la red anterior, al servidor no llega nada, como cabe esperar. Ese es el caso normal cuando el filtrado funciona. Al revés también vale: si la línea está saturada, puede que ni siquiera te llegue la sesión SSH con la que querías medir. Usa entonces la consola VNC del área de cliente, que funciona con independencia de la red del sistema huésped.

En resumen

Cierra todo salvo 30120 TCP y UDP, mantén txAdmin y la base de datos fuera de la red abierta, limita las conexiones y la tasa de paquetes por dirección de origen, lleva una whitelist y valida los eventos de red en el lado del servidor. Con eso estás preparado contra todo lo que se apaña sin un ancho de banda digno de mención. Más allá de ahí decide únicamente la red que hay delante del servidor.

Si tu proyecto ya está en KernelHost, el filtrado está activo sin que tengas que hacer nada. Si aun así notas algo raro, abre un ticket de soporte para que ajustemos con más precisión las reglas de filtrado de tu dirección IP. Durante un ataque en curso puedes localizarnos además en el chat de emergencia de WhatsApp en el +43 650 8209883.