Proteger un servidor de Unturned frente a ataques DDoS

Un servidor de Unturned que por las noches desaparece de la lista de servidores durante unos minutos y expulsa de paso a todos los jugadores con un tiempo de espera agotado rara vez tiene un problema de hardware. Lo habitual es que haya un ataque en marcha, y justo cuando hay más movimiento. Este artículo muestra primero lo que puedes asegurar tú mismo sin coste añadido, después dónde se acaban técnicamente esas medidas, y al final lo que entonces tiene que ocurrir en la red que hay delante del servidor.

Todos los datos se refieren al Unturned Dedicated Server (U3DS, App ID 1110390 de SteamCMD) 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 todavía en la configuración y no reinicies el servidor: guarda primero las mediciones (apartado 10), porque cuando el ataque pase habrán desaparecido.

Por qué atacan precisamente a los servidores de Unturned

Los servidores de Unturned reciben ataques porque su dirección es pública, porque el tráfico de juego va por UDP y porque un ataque no le cuesta a quien lo encarga ni conocimientos ni un dinero digno de mención. Los tres puntos pesan aquí más que en la mayoría de los demás juegos.

Un servidor público de Unturned publica su dirección IP por sí solo. Tiene que hacerlo, porque de lo contrario no lo encontraría nadie: el navegador de servidores de Steam le pregunta directamente, y las listas de terceros como unturned-servers.net o BattleMetrics recogen la dirección IP y el puerto en texto claro. unturned-servers.net comprueba para ello, según indica, cada cinco minutos si el servidor acepta conexiones UDP en el puerto del servidor. Para un atacante eso no es trabajo, es un formulario.

A eso se suma la base de jugadores. Unturned es gratis, la barrera de entrada es cero, y entre los proyectos de roleplay y de supervivencia hay competencia real por los mismos jugadores. Un jugador baneado, un ex administrador ofendido o un proyecto vecino no necesita acceso a tu servidor para dejarlo inservible durante una hora. Qué es técnicamente un ataque DDoS y por qué las direcciones de origen falsificadas lo hacen tan difícil de rastrear lo explica el artículo ¿Qué es un ataque DDoS?.

Los puertos que de verdad importan

Un servidor de Unturned ocupa exactamente dos puertos UDP consecutivos: el valor definido en Commands.dat y ese valor más uno. Por defecto son 27015 y 27016. La documentación oficial de Smartly Dressed Games describe así el reparto: el primer puerto transporta las consultas de la lista de servidores y el segundo el tráfico de juego. Solo se define el primero, el segundo sale de ahí automáticamente.

Name Mi servidor de Unturned
Port 27015
MaxPlayers 24
Map PEI
Mode Normal
Perspective Both
Owner 76561198000000000

El archivo Commands.dat está en U3DS/Servers/<Instancia>/Server/Commands.dat. Su formato es peculiar y una fuente de errores frecuente: un comando por línea, sin signo igual, el valor separado por un espacio, y los comandos distinguen entre mayúsculas y minúsculas. Las líneas que empiezan por // son comentarios.

El punto más importante para el firewall dice así: el puerto 27017 ya no se necesita desde la versión 3.21.30.0 del 21 de noviembre de 2021. Antes, un servidor de Unturned exigía tres puertos, porque la consulta de Steam estaba en el puerto más dos. Con esa actualización, la consulta comparte puerto con el propio servidor y el tercer puerto desapareció. Aun así, las guías de routers, los wikis de proveedores y los mensajes de foro siguen nombrando el 27017 hasta hoy. Un 27017 abierto ya no te aporta ninguna ventaja, es superficie de ataque y nada más.

Igual de importante: Unturned no tiene un puerto RCON integrado. La documentación oficial solo conoce la entrada y la salida de consola, que se pueden sustituir mediante la interfaz ICommandInputOutput. Todo control remoto que veas en un servidor de Unturned viene de un plugin y trae consigo su propio puerto TCP. Ese puerto tienes que encontrarlo y restringirlo tú mismo, porque nadie lo ha asegurado por ti.

Lo que puedes hacer tú mismo antes de gastar dinero

Este apartado es el más largo, y es a propósito. Un servidor de Unturned 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 -lnup
ss -lntp

El primer comando muestra los sockets UDP a la escucha, el segundo los sockets TCP. La columna interesante es la de la dirección local. 0.0.0.0:27015 y [::]:27015 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í un plugin de RCON, un panel web, una base de datos y un viejo servidor de pruebas en el 27017 que ya no usa nadie. La vista del atacante te la da un escaneo de puertos desde fuera, para Unturned expresamente con UDP:

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

2. Dejar abiertos solo 27015 y 27016

A Unturned le bastan dos aperturas UDP hacia fuera. Para el juego en sí no hace falta un solo puerto TCP: la documentación oficial exige expresamente UDP para los dos puertos, y la capa de red del juego (Steam Networking Sockets, el valor por defecto desde una de las actualizaciones) trabaja exclusivamente sobre UDP. Quien abre además TCP está siguiendo una guía obsoleta.

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Unturned consulta'
ufw allow 27016/udp comment 'Unturned juego'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

El orden importa, porque de lo contrario te quedas fuera de tu propio servidor. La guía completa, con vía de rescate incluida, está en Configurar el firewall UFW sin quedarte fuera del servidor. Si tienes varias instancias, respeta la separación recomendada de dos (27015, 27017, 27019) y abre por instancia exactamente los dos puertos que ocupa de verdad.

Un panel web, una base de datos o un plugin de RCON no pintan nada en la red abierta. Restringe el puerto correspondiente a tu propia dirección con ufw allow from 203.0.113.10 to any port 8080 proto tcp, o llega a la interfaz mediante una redirección local por SSH con ssh -N -L 8080:127.0.0.1:8080 root@IP.DE.TU.SERVIDOR. La base de datos se enlaza a 127.0.0.1.

3. Asegurar el puerto de consulta sin caerte de la lista de servidores

El puerto de consulta es el punto más delicado de un servidor de Unturned. Por él responde el servidor a las consultas de Steam A2S_INFO, A2S_PLAYERS y A2S_RULES. Si lo bloqueas del todo, el servidor desaparece de todas las listas de servidores aunque funcione sin un solo fallo.

Una respuesta A2S es bastante más grande que la petición. El US-CERT recoge el protocolo de Steam en su resumen sobre ataques de amplificación por UDP (TA14-017A) con un factor de amplificación de ancho de banda de 5,5. En concreto, eso significa que un atacante envía consultas con la dirección de origen falsificada a servidores de juego ajenos y dirige hacia su objetivo real las respuestas, unas cinco veces y media más grandes. Tu servidor no es entonces la víctima, sino el amplificador contra un tercero. En sentido contrario, basta un flood de consultas para que el servidor desaparezca del navegador de servidores sin que se caiga un solo jugador. Los operadores lo describen exactamente así: el servidor funciona, los jugadores que están dentro no notan nada, pero ya no se le encuentra.

Contra los floods de consultas pequeños ayuda un límite superior por dirección de origen. Las consultas legítimas llegan pocas veces: el navegador de Steam pregunta una vez por cada visualización, y los servicios de estado cada pocos minutos.

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name unturned_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name unturned_game --hashlimit-mode srcip --hashlimit-above 300/sec --hashlimit-burst 500 -j DROP

La segunda cifra se deriva directamente del juego: Unturned limita a un jugador de fábrica a 50 paquetes por segundo (Max_Packets_Per_Second). Así que 300 paquetes por segundo y dirección de origen le dejan aire de sobra a una sola conexión, incluso si hay varios jugadores detrás de la misma dirección. Los dos valores son puntos de partida, no verdades absolutas. Mide primero una semana de funcionamiento normal, porque si no echarás fuera a tus propios jugadores.

Las reglas de iptables a secas desaparecen tras un reinicio. En Debian y Ubuntu se guardan con apt-get install -y iptables-persistent y netfilter-persistent save. Con UFW, ese tipo de reglas van en /etc/ufw/before.rules, porque de lo contrario desaparecen con el siguiente ufw reload.

A eso se suma una costumbre que no cuesta nada: si tu página web o tu bot de Discord muestran el número de jugadores, no consultes el servidor desde el visitante, guarda el resultado en caché a intervalos fijos. Si no, una página de estado muy visitada genera una consulta por visitante en lugar de una por intervalo.

4. Poner los límites integrados en la Config.json

Unturned trae en la Config.json, dentro de la misma carpeta Server que la Commands.dat, un apartado que para la defensa es más importante de lo que su nombre sugiere. Los valores por defecto son estos:

"Server": {
    "VAC_Secure": true,
    "BattlEye_Secure": true,
    "Max_Ping_Milliseconds": 750,
    "Timeout_Queue_Seconds": 15.0,
    "Timeout_Game_Seconds": 30.0,
    "Max_Packets_Per_Second": 50.0,
    "Join_Rate_Limit_Window_Seconds": 40.0,
    "Rate_Limit_Kick_Threshold": 10,
    "Use_FakeIP": false
}

Max_Packets_Per_Second limita a un jugador conectado a 50 paquetes por segundo. Join_Rate_Limit_Window_Seconds y Rate_Limit_Kick_Threshold expulsan una conexión que pase del límite más de diez veces en 40 segundos. VAC_Secure y BattlEye_Secure exigen los dos sistemas anticheat en el lado del jugador y mantienen así fuera la mayor parte de los clientes desechables.

Una cosa tiene que quedar clara: estos límites actúan contra clientes que entran de verdad o lo intentan. Contra un flood con direcciones de origen falsificadas no actúan, porque ahí nunca llega a crearse una sesión. Aun así son importantes, porque atajan el caso individual más frecuente: un único cliente manipulado que sobrecarga el servidor él solo. Dejar Max_Ping_Milliseconds en 750 es razonable; si lo pones más bajo, el servidor tirará media partida fuera con cada microcorte de red.

5. Aliviar el seguimiento de conexiones

Este punto se pasa por alto casi siempre y explica caídas que parecen un ataque de volumen sin serlo. El kernel crea entradas en el seguimiento de conexiones (conntrack) también para el tráfico UDP, y con direcciones de origen falsificadas cada dirección nueva significa una entrada nueva. Cuando la tabla se llena, el kernel descarta paquetes sin distinguir: el ataque y tus jugadores se van fuera juntos. En el log del sistema aparece entonces nf_conntrack: table full, dropping packet.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack

El paso más eficaz es no dejar que el tráfico de Unturned se rastree siquiera. El juego gestiona sus propias sesiones y no necesita ningún seguimiento de estado en el kernel:

iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK
iptables -t raw -A PREROUTING -p udp --dport 27016 -j NOTRACK

Ten en cuenta que a partir de ahí tus aperturas para esos dos puertos ya no pueden ir por ESTABLISHED,RELATED, sino que tienen que existir como reglas de aceptación propias. Solo después merece la pena subir nf_conntrack_max. Quien agranda primero la tabla solo desplaza el problema unos minutos y gasta memoria para ello.

Si los paquetes llegan más rápido de lo que el proceso del servidor los recoge, se desborda además el búfer de recepción del socket. Para los jugadores eso se ve como pérdida de paquetes, aunque la línea esté libre:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Deja los valores en /etc/sysctl.d/ y actívalos con sysctl --system. Si hacen falta o no te lo dice el propio kernel: si UdpRcvbufErrors sube en nstat -az o si en ss -lunp hay algo permanentemente en la cola de recepción, entonces sirven. Si los dos se quedan a cero, el ajuste no cambia nada. Esto es reserva, no protección.

6. Flood de entradas, cola de espera y whitelist

Un flood de entradas es un ataque en el que el atacante usa la vía normal de acceso para consumir plazas y tiempo de proceso, en lugar de llenar la línea. Unturned trae contra eso cuatro herramientas, todas ellas en la Commands.dat:

• Queue_Size 32 fija la cola de espera. Por defecto son 8 plazas y el máximo es 64. Una cola demasiado grande le ayuda al atacante, una demasiado pequeña deja fuera a los jugadores reales en cada reinicio.
• Whitelisted pasa el servidor a lista de acceso. Se da de alta por consola con permit <SteamID64> y se retira con unpermit <SteamID64>.
• Password TuContrasena deja fuera a todo el que solo tiene la dirección porque la sacó de una lista.
• Filter rechaza a los jugadores con caracteres no permitidos en el nombre, y MaxPlayers 24 mantiene el número de plazas en lo que el hardware sostiene de verdad.

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 punto.

7. RocketMod, OpenMod y el lado de los plugins

Unturned tiene dos plataformas de plugins extendidas, y las dos corren en el mismo proceso que el servidor. RocketMod es la más antigua: los responsables originales dejaron de mantenerla el 20 de diciembre de 2019 y publicaron el código fuente bajo licencia MIT. Desde entonces, Smartly Dressed Games mantiene el derivado Legally Distinct Missile (LDM), que ya viene incluido con el Dedicated Server: se copia Rocket.Unturned desde la carpeta Extras a la carpeta Modules. Los desarrolladores recomiendan ese derivado de forma expresa, porque corrige problemas antiguos de Rocket como los fallos de threading y los exploits de teletransporte.

OpenMod es el sucesor más reciente, desarrollado por uno de los responsables originales de Rocket. No sustituye a RocketMod, sino que corre en paralelo y puede aprovechar los plugins de Rocket existentes mediante una integración. Para la defensa eso significa dos cosas.

Primera: cada plugin es superficie de ataque dentro del proceso principal. Un plugin que lanza una consulta a la base de datos con cada mensaje de chat o con cada evento de juego es un denial of service construido en casa. Un único jugador que dispare un evento en bucle deja entonces el servidor parado sin gastar nada de ancho de banda. Mantén la lista de plugins corta, prefiere los plugins de código abierto y mide la tasa de fotogramas del servidor después de cada ampliación.

Segunda: como Unturned no tiene un puerto RCON propio, todo control remoto viene de un plugin. Comprueba después de la instalación con ss -lntp qué puerto TCP ha abierto y restríngelo a tu propia dirección. Un puerto de control remoto abierto con una contraseña débil no es un problema de DDoS, es un problema de toma de control.

8. Contenidos del Workshop y el proceso de entrada

Los contenidos del Workshop encarecen la entrada, y eso repercute directamente en lo atacable que eres. Se controlan mediante la WorkshopDownloadConfig.json, en la misma carpeta Server:

{
    "File_IDs": [],
    "Ignore_Children_File_IDs": [],
    "Query_Cache_Max_Age_Seconds": 600,
    "Max_Query_Retries": 2,
    "Use_Cached_Downloads": true,
    "Should_Monitor_Updates": true,
    "Shutdown_Update_Detected_Timer": 600
}

En File_IDs están los identificadores de Workshop de los mapas y los mods. Al arrancar, el servidor los descarga junto con sus dependencias, y cada jugador los descarga automáticamente al conectarse. Deberías conocer tres consecuencias. Primera: con listas de mods grandes, la entrada tarda mucho, y después de un ataque todos los jugadores vuelven a la vez, lo que carga el servidor una segunda vez. Segunda: Should_Monitor_Updates detiene el servidor en cuanto se actualiza un archivo de Workshop, y el Shutdown_Update_Detected_Timer preconfigurado en 600 segundos provoca entonces un reinicio que los operadores confunden con regularidad, durante un ataque, con un éxito del atacante. Tercera: cada mod es código ajeno dentro de tu servidor.

En la práctica eso significa: mantén la lista lo más corta posible, revisa tras cada reinicio inesperado primero el log del servidor en busca del aviso de actualización del Workshop, y desactiva Should_Monitor_Updates solo si planificas tú mismo las actualizaciones.

9. Lista de servidores, código de servidor y la función Fake IP

Tu dirección IP no se puede mantener en secreto mientras el servidor esté listado públicamente. Cualquier jugador que se haya conectado una vez la conoce, y las listas de terceros la publican de todas formas. Aun así hay dos costumbres que ayudan: no publiques tú mismo la dirección en bruto en ninguna parte, y conecta a tus jugadores mediante un nombre de host, para que un cambio de dirección no rompa todas las referencias. El clásico es el registro A olvidado que apunta a la dirección anterior y deja sin efecto cualquier cambio.

Para funcionar en internet necesitas de todos modos un Game Server Login Token (GSLT) de la administración de servidores de Steam para el App ID 304930. Además, sirve para que el código de servidor de tu servidor se mantenga igual entre reinicios en lugar de generarse de nuevo en cada arranque.

Unturned ofrece además una función Fake IP. Se activa con "Use_FakeIP": true en la Config.json, y el comando de consola CopyFakeIP entrega la dirección que después publicas. El tráfico pasa a partir de ahí por la red de relés Steam Datagram Relay, las direcciones asignadas están en el rango de 169.254.0.0 a 169.254.255.255, y la dirección real del servidor ya no se les muestra a los jugadores. Valve describe ese tráfico como autenticado, cifrado y limitado en tasa.

El precio es alto y rara vez se menciona: la dirección y el puerto cambian en cada reinicio, un nombre de dominio no se puede apuntar ahí sin scripts propios, y las listas de Steam "Favoritos" e "Historial" no funcionan con ello, solo la función de marcadores. Pero, sobre todo, la función solo protege la vía del juego. Tu servidor conserva su dirección real, y SSH, el panel web, la base de datos y la página web siguen siendo accesibles por ella. Quien conozca la dirección por un registro DNS antiguo, por una página de estado o por una conexión anterior la seguirá atacando directamente. La función Fake IP no sustituye, por tanto, a un filtrado en la red que hay delante del servidor: solo reduce el número de personas que conocen tu dirección.

10. Registrar datos para no tener que adivinar durante el ataque

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 viernes por la noche. Con apt-get install -y vnstat sysstat la medición corre de forma permanente. Durante un incidente bastan cuatro comandos:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp portrange 27015-27016 -c 200 -q

Con tcpdump vale una norma: limítalo siempre con -c, porque una captura a plena carga carga todavía más un servidor que ya está saturado. Cómo interpretar los valores y distinguir un ataque de un fallo de software lo explica Detectar un ataque DDoS en el servidor.

Dónde terminan estas medidas

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. El funcionamiento normal se queda muy por debajo: con 24 jugadores y los 50 paquetes por jugador y segundo permitidos de fábrica llegan unos 1.200 paquetes por segundo. Un servicio de booter genera un múltiplo de eso sin ninguna preparación.

La segunda magnitud es la tasa de paquetes, y golpea casi siempre 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 eso

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 encender, 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 Frankfurt am Main. Justo delante del servidor se reconocen y se descartan los patrones propios de cada protocolo, paquete a paquete.

Dos propiedades son decisivas. 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. La ubicación es Frankfurt am Main. Qué juegos y protocolos están cubiertos lo enumera Protección DDoS para servidores de juego en tiempo real.

Advanced DDoS Protection para proyectos atacados de forma continua

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, sin permanencia mínima y sin cuota de instalación. 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: defines por separado qué se permite en 27015 UDP (las consultas) y qué en 27016 UDP (el tráfico de juego), sin tener que abrir un ticket para ello.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso, por ejemplo apretando las consultas y dejando el tráfico de juego intacto.
• Perfil de protección acorde al juego, igual que para aplicaciones modificadas y propias en cualquier puerto TCP o UDP, también para un plugin con puerto propio.

Los dos niveles, comparados

Para la mayoría de los proyectos de Unturned 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

"Mi guía dice que tengo que abrir del 27015 al 27017": esa guía es anterior a noviembre de 2021. Desde la versión 3.21.30.0, un servidor de Unturned solo necesita dos puertos, porque la consulta de Steam ya no está en el puerto más dos. Cierra el 27017, salvo que ahí corra una segunda instancia.

"El servidor funciona, pero ya no aparece en ninguna lista de servidores": esa es la imagen típica de un flood de consultas o de una regla propia demasiado estricta sobre 27015 UDP. Comprueba con iptables -L INPUT -n -v si tu propia regla cuenta aciertos. Si los contadores suben mucho, estás filtrando tus propias entradas de lista. No bloquees nunca el 27015 por completo.

"Todos los jugadores se caen a la vez con tiempo de espera agotado": mira primero si se ha desbordado el seguimiento de conexiones (dmesg -T | grep -i conntrack). Con la tabla llena, el kernel descarta sin distinguir. Timeout_Game_Seconds está de fábrica en 30 segundos: quien vuelve dentro de ese tiempo conserva su plaza.

"El servidor se reinicia en pleno funcionamiento": eso rara vez es un ataque. Revisa el log en busca del aviso de actualización de Workshop detectada. Should_Monitor_Updates apaga el servidor tras el plazo preconfigurado de 600 segundos.

"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 una lista de servidores, un bot de Discord o un registro DNS viejo. Cambiar de dirección da tiempo, no es una solución.

"Activé la función Fake IP y me siguen atacando": esconde la dirección ante los jugadores nuevos, pero no se la quita al servidor. Quien la conozca por una entrada de lista antigua, por una página de estado o por una conexión anterior seguirá llegando directamente a tu servidor, y también a SSH y a cualquier panel web que tengas ahí.

"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 invitado.

En resumen

• Un servidor de Unturned necesita exactamente dos puertos UDP abiertos: el Port definido en la Commands.dat (27015 por defecto) y ese valor más uno (27016). El juego en sí no necesita TCP.
• El puerto 27017 sobra desde la versión 3.21.30.0 del 21 de noviembre de 2021, porque la consulta de Steam ya no está en el puerto más dos. Quien lo siga teniendo abierto está siguiendo una guía obsoleta.
• Unturned no tiene un puerto RCON integrado. Todo control remoto viene de un plugin, trae su propio puerto TCP y tienes que restringirlo tú mismo.
• El puerto de consulta 27015 es el punto más delicado: un flood de consultas hace invisible al servidor en la lista de servidores sin tocar a un solo jugador, y el protocolo de Steam tiene según el US-CERT TA14-017A un factor de amplificación de 5,5.
• Los límites de la Config.json (Max_Packets_Per_Second 50,0, Rate_Limit_Kick_Threshold 10 por cada 40 segundos) solo actúan contra clientes que entran de verdad, no contra direcciones de origen falsificadas.
• Una línea de 1 Gbit/s está llena a 125 megabytes por segundo, y con paquetes de 64 bytes ya a unos 1,49 millones de paquetes por segundo. El funcionamiento normal con 24 jugadores está en unos 1.200 paquetes por segundo. Todo lo que pase de ahí lo decide la red que hay delante del servidor, no tu firewall.
• En KernelHost, la protección permanente en dos niveles está incluida en cada paquete de servidor sin recargo y activa desde el aprovisionamiento, sin null-routing. Quien quiera dirigir él mismo las reglas de filtrado añade la Advanced DDoS Protection desde 50,00 € al mes.

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 se reajusten 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.