Proteger tu servidor de Mordhau frente a ataques DDoS

Un servidor de Mordhau que pierde de golpe a todos los jugadores en mitad de una ronda de Frontline, se queda después unos minutos fuera de línea y desaparece de la lista de servidores rara vez tiene un problema de hardware. En la inmensa mayoría de los casos hay un ataque en marcha contra uno de los cuatro puertos UDP que un servidor dedicado de Mordhau tiene que mantener abiertos hacia fuera. Este artículo muestra primero lo que puedes resolver tú mismo sin coste añadido en la protección DDoS de Mordhau, después dónde se acaban esas medidas por pura física y, al final, qué tiene que ocurrir en la red que hay delante del servidor.

Todos los datos se refieren al servidor dedicado oficial de Mordhau (Steam App ID 629800, Unreal Engine 4) 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 (apartado 9), porque cuando el ataque pase habrán desaparecido. En Mordhau se añade un segundo motivo que muchos operadores aprenden por las malas: al terminar, el proceso del servidor vuelca en la Game.ini el estado que tiene en memoria. Quien edita el archivo con el servidor en marcha pierde sus cambios en la siguiente parada.

Por qué los servidores de Mordhau necesitan protección DDoS y quién los ataca

Los servidores de Mordhau reciben ataques porque su dirección es pública, todo el tráfico del juego va por UDP y una caída se vuelve visible para todos al instante. La entrada en el navegador de servidores contiene la dirección IP y el puerto de juego en texto claro, porque de lo contrario los jugadores no encontrarían el servidor. Las listas de servidores públicas y los trackers recogen esos mismos datos a través del puerto de consulta de Steam y los publican una segunda vez. Tu dirección no es por tanto un secreto, sino un dato de producto.

A eso se suma la técnica del juego. Unreal Engine 4 transmite movimientos, golpes y paradas por UDP. UDP no tiene un establecimiento de conexión que se pueda exigir, y la dirección de origen de un paquete UDP se puede falsificar. Un atacante no necesita entonces ni entrar en tu servidor ni dirigirse a él correctamente para generarle carga. En Mordhau eso pesa más que en muchos otros juegos: un intercambio de golpes se decide en unas pocas décimas de segundo, y solo 200 milisegundos de retardo adicional dejan el combate cuerpo a cuerpo injugable, mucho antes de que el servidor llegue a caerse de verdad. Justo por eso basta un ataque pequeño para arruinar una ronda. Qué es en detalle un ataque DDoS lo explica el artículo ¿Qué es un ataque DDoS?.

Los detonantes típicos son poco espectaculares: competencia entre comunidades, jugadores baneados, duelos perdidos, discusiones en Discord. Un ataque no le cuesta a quien lo encarga ni conocimientos ni un dinero digno de mención, porque los servicios de booter de alquiler hacen el trabajo. Los operadores cuentan con regularidad que los ataques empiezan justo cuando el servidor está lleno y terminan en cuanto se vacía. Eso no es casualidad, sino una señal de que alguien vigila tu entrada en el navegador de servidores y usa el número de jugadores como disparador.

Los puertos que de verdad importan en Mordhau

Un servidor dedicado de Mordhau necesita exactamente cuatro puertos UDP hacia fuera: 7777, 7778, 15000 y 27015. Todo lo demás es opcional o no pinta nada en la red abierta. Los puertos se pasan como parámetros al arrancar:

./MordhauServer.sh FFA_ThePit -log -Port=7777 -QueryPort=27015 -BeaconPort=15000 -RconPort=27020

Dos cosas se malinterpretan una y otra vez. Primera: el puerto del beacon 15000 no es un accesorio. El beacon reserva el slot en el momento en que un jugador entra, para que no salga despedido después de cargar el mapa. Si 15000 está bloqueado o saturado, los jugadores ya no entran, aunque el puerto 7777 responda. Segunda: RCON no viene preconfigurado en Mordhau. Solo se activa cuando defines RconPassword y RconPort, y entonces funciona por TCP, no por UDP.

Los datos clave de un servidor de Mordhau de un vistazo:

Los patrones de ataque que aparecen en Mordhau

Cuatro patrones cubren prácticamente todo lo que se lanza contra un servidor de Mordhau, y cada uno golpea un puerto distinto.

• Flood UDP contra el puerto de juego 7777. Es el ataque estándar de un booter: tantos paquetes falsificados como sea posible contra el puerto que aparece en el navegador de servidores. Apunta al ancho de banda y a la tasa de paquetes, no a una vulnerabilidad, y se manifiesta primero como picos de lag, mucho antes de que alguien pierda la conexión.
• Flood de consultas contra el puerto de consulta 27015. Una consulta A2S_INFO ocupa 25 bytes, la respuesta con nombre del servidor, mapa, modo de juego y número de jugadores es un múltiplo de eso. El atacante invierte por tanto poco y te obliga a gastar cálculo y tráfico saliente.
• Reflexión a través de tu propio puerto de consulta. Aquí tu servidor no es el objetivo, sino la herramienta: el atacante envía consultas con la dirección de origen falsificada y tu servidor responde a la víctima. Lo notas como un tráfico saliente inexplicablemente alto en 27015 y como un aviso de abuso de tu proveedor.
• Agotamiento de entradas y de slots a través del puerto del beacon 15000. En lugar de quemar ancho de banda, unas entradas automatizadas ocupan los slots reservados. El servidor sigue funcionando, pero está lleno, y los jugadores de verdad ya no entran.

A eso se suma un quinto patrón en cuanto RCON queda abierto en la red: intentos de autenticación cada segundo contra el puerto RCON. Rara vez es volumétrico, pero cuesta tiempo de cálculo, y es el único de los cinco casos en el que un acierto te quita el servidor de las manos por completo.

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 Mordhau bien configurado aguanta por su cuenta los ataques pequeños y medianos, esté alojado donde esté.

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

Antes de escribir una sola regla de firewall, 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:7777 y [::]:7777 significan "accesible desde todo internet", 127.0.0.1:27020 significa "solo local" y no necesita ninguna regla de firewall. Junto al juego suelen aparecer ahí un panel web, un servicio de base de datos y algún servicio de voz olvidado hace tiempo. La vista del atacante te la da un escaneo desde fuera, para UDP con una lista corta de puertos, porque un escaneo UDP completo es muy lento:

nmap -Pn -sU -p 7777,7778,15000,27015 IP.DE.TU.SERVIDOR
nmap -Pn -p- --min-rate 1000 IP.DE.TU.SERVIDOR

2. Dejar abiertos solo los cuatro puertos que Mordhau necesita de verdad

A Mordhau le bastan cuatro aperturas UDP 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 7777/udp comment 'Mordhau juego'
ufw allow 7778/udp comment 'Mordhau Steam'
ufw allow 15000/udp comment 'Mordhau beacon'
ufw allow 27015/udp comment 'Mordhau consulta'
ufw allow from 203.0.113.10 to any port 27020 proto tcp comment 'Mordhau RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sustituye 203.0.113.10 por tu propia dirección. Lo importante es lo que aquí no aparece: ninguna apertura para un panel web, ninguna para una base de datos, ninguna para un servidor de archivos. Cada puerto abierto de más es un objetivo de más que no tiene nada que ver con el juego. La guía completa, con vía de rescate incluida, la tienes en Configurar el firewall UFW sin quedarte fuera del servidor.

3. Limitar el puerto de consulta 27015 sin caerte de la lista de servidores

El puerto de consulta lo puedes limitar, pero no cerrar. Si cierras 27015 UDP, tu servidor desaparece del navegador de servidores, porque el número de jugadores, el nombre del mapa y el nombre del servidor se leen exactamente por ese puerto. Un límite superior por dirección de origen resuelve el problema sin costarte visibilidad:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name mh_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Un navegador de servidores normal consulta tu servidor unas cuantas veces por minuto, no unas cuantas veces por segundo. Diez consultas por segundo y dirección de origen son por tanto generosas para cualquier jugador y estrechas para cualquier bot. Comprueba después en el contador de aciertos si la regla llega a aplicarse:

iptables -L INPUT -n -v | head -20
tcpdump -ni eth0 udp port 27015 -c 200 -q

Aquí está también la respuesta a la cuestión de la reflexión. En una reflexión tu servidor no es atacado, sino usado como amplificador: las consultas llegan con la dirección de origen falsificada, y tus respuestas golpean a una víctima ajena. Una limitación de tasa por dirección de origen es contra eso la medida local más eficaz, porque una dirección de origen falsificada solo sirve mientras tu servidor responda de buena gana y sin límite.

4. Sacar RCON de la red abierta

En Mordhau, RCON no debe estar en internet sin restricciones bajo ningún concepto. El acceso se activa en la Game.ini, en el apartado [/Script/Mordhau.MordhauGameSession]:

[/Script/Mordhau.MordhauGameSession]
ServerName=Mi servidor de Mordhau
MaxSlots=64
ServerPassword=
AdminPassword=UnaContrasenaLargaAleatoria
RconPassword=OtraContrasenaLargaAleatoria
RconPort=27020

Mordhau habla el protocolo Source RCON, es decir, TCP, y por eso funciona con cualquier herramienta RCON habitual. Eso mismo aprovechan los scripts que van probando credenciales. Tres reglas cubren el caso. Primera: RconPassword y AdminPassword son dos contraseñas distintas, largas y aleatorias, no variaciones del nombre del servidor. Segunda: la apertura del puerto RCON la limitas a tu propia dirección, igual que en el bloque de UFW de arriba. Tercera, si no tienes una dirección fija: deja el puerto cerrado desde fuera y llega hasta él por una redirección de puertos de SSH; después te conectas en local a 127.0.0.1:27020:

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

Si aun así RCON tiene que quedarse abierto, limita al menos las conexiones simultáneas por dirección de origen. Una herramienta RCON necesita una conexión, un script de fuerza bruta cientos:

iptables -I INPUT -p tcp --dport 27020 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

5. Proteger el puerto del beacon 15000 frente a las oleadas de entrada

El puerto del beacon es el punto de ataque infravalorado de un servidor de Mordhau. Por él reserva el juego el slot de un jugador que entra, mientras este todavía carga. Un bot que lanza entradas en rápida sucesión ocupa así los slots sin llegar nunca al juego. El servidor sigue en línea y aun así parece lleno. Un límite superior por dirección de origen lo frena, porque un jugador real hace beacon exactamente una vez por entrada y no veinte veces por segundo:

iptables -I INPUT -p udp --dport 15000 -m hashlimit --hashlimit-name mh_beacon --hashlimit-mode srcip --hashlimit-above 20/sec --hashlimit-burst 40 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name mh_game --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

La segunda regla se refiere al puerto de juego y requiere sentido de la medida. Con un tickrate de 60, el servidor intercambia con cada jugador conectado del orden de 60 paquetes por segundo y sentido. Un límite de 400 paquetes por segundo y dirección de origen deja así aire de sobra a cualquier jugador real y alcanza igualmente a cualquier origen que esté inundando de forma evidente. Mide primero una semana de funcionamiento normal antes de apretar más: quien ajusta demasiado fino echa fuera a sus propios jugadores y después lo toma por un ataque.

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

Con UFW, ese tipo de reglas van en /etc/ufw/before.rules, porque de lo contrario desaparecen con el siguiente ufw reload.

6. Game.ini y Engine.ini: lo que de verdad aporta algo

Mordhau tiene dos archivos de configuración, y los dos están en Linux en Mordhau/Saved/Config/LinuxServer/ y en Windows en Mordhau\Saved\Config\WindowsServer\. La Game.ini regula el nombre del servidor, los slots, las contraseñas, la lista de administradores, la rotación de mapas y los identificadores de los mods de mod.io; la Engine.ini regula el comportamiento de red. Edita las dos únicamente con el servidor parado, porque si no el proceso del servidor sobrescribe tus cambios al terminar con el estado que tiene en memoria.

Tres ajustes son realmente relevantes para la superficie de ataque. Primero, una ServerPassword: mantiene fuera a cualquiera que no esté invitado, pero cuesta la visibilidad pública y no ayuda en absoluto contra una inundación del puerto 7777, porque el atacante no quiere entrar. Segundo, un número de MaxSlots realista: Mordhau está pensado para hasta 64 jugadores, y cada slot adicional es una fuente de paquetes más que tu CPU tiene que atender. Tercero, el tickrate en la Engine.ini:

[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=60
LanServerMaxTickRate=60

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

El tickrate por defecto de un servidor de Mordhau es 60. Subirlo a 120 duplica la tasa de paquetes por jugador y la carga de CPU, y es justo lo que no te conviene bajo ataque. Un servidor de 64 slots con tickrate 120 genera ya en funcionamiento normal del orden de 8.000 paquetes por segundo y sentido. Quien recibe ataques de forma continua va notablemente más estable con 60 que con 120.

7. Aliviar el seguimiento de conexiones y los búferes de recepción

Un cuello de botella que se pasa por alto a menudo es el seguimiento de conexiones del kernel. Lleva una entrada propia para cada flujo UDP, y una inundación desde decenas de miles de direcciones de origen falsificadas llena la tabla en segundos. Si se llena, el servidor descarta también los paquetes legítimos, y en el registro aparece "nf_conntrack: table full". El estado y el límite los muestra:

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

Contra eso ayudan dos caminos. Subes el límite, o sacas los puertos del juego del seguimiento por completo. Lo segundo suele ser lo mejor en un servidor de juego, porque UDP no tiene de todas formas ningún estado que haya que seguir:

iptables -t raw -I PREROUTING -p udp --dport 7777 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 15000 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 27015 -j NOTRACK

También tiene sentido ampliar los búferes de recepción y la cola de la tarjeta de red, para que los picos cortos no provoquen descartes de inmediato:

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=4194304
sysctl -w net.core.netdev_max_backlog=5000

De forma permanente, esos valores van en un archivo bajo /etc/sysctl.d/, por ejemplo 99-gameserver.conf. Importante para entenderlo: unos búferes más grandes no aumentan tu resistencia frente a un ataque grande, solo evitan que un pico corto ya te cueste paquetes.

8. Tu dirección está en la lista de servidores, y eso no se puede cambiar

Aquí conviene la honestidad antes que el pensamiento mágico: la dirección IP de un servidor público de Mordhau no se puede mantener en secreto. Está en la entrada del navegador de servidores, está en las listas de servidores públicas de terceros que leen el puerto de consulta con regularidad, y cualquier jugador que se haya conectado una vez la conoce. Un cambio de dirección da por eso horas, rara vez días, porque el atacante encuentra la dirección nueva por el mismo camino que la antigua.

Para esto sirven tres costumbres. 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. Conecta a tus jugadores mediante un nombre de host, para que un cambio de dirección llegado el caso no rompa todas las referencias. Y limpia los registros DNS antiguos, porque un registro A olvidado que apunte a la dirección anterior deja sin efecto cualquier cambio. Lo mismo vale para los servidores de pruebas: cualquier segundo servidor accesible públicamente en la misma máquina delata la dirección del servidor principal.

9. Medir mientras todo funciona con normalidad

El paso más importante es el que casi nadie da antes de tiempo: crear una base de comparación mientras el servidor funciona tranquilo. Sin un valor normal no puedes decir, después de un incidente, si 40.000 paquetes por segundo eran muchos o simplemente un sábado 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 port 7777 or udp port 15000 or udp port 27015' -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. Fíjate sobre todo en los contadores de descartes de ip -s link. Unos valores dropped crecientes con la CPU tranquila al mismo tiempo son la señal más clara de que el problema es la tasa de paquetes y no la potencia de cálculo. Cómo interpretar los valores está en Detectar un ataque DDoS en el servidor. Cómo montar el servidor limpiamente con SteamCMD y mantenerlo al día lo describe Instalar un servidor de juego con SteamCMD.

El punto en el que estas medidas se acaban: ancho de banda y tasa de paquetes

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. Un servidor de Mordhau lleno con 64 slots necesita de eso solo una fracción: con tickrate 60, el tráfico del juego está del orden de 4.000 paquetes por segundo y sentido. Un booter de alquiler, en cambio, entrega sin problema 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 ya no importa, 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. Un ataque que no llena ni un tercio de tu línea puede dejar tu servidor de Mordhau 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 cada servidor

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 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 detalla Protección DDoS para servidores de juego en tiempo real.

Advanced DDoS Protection para servidores de Mordhau bajo fuego continuo

Algunos servidores no reciben ataques de vez en cuando, sino de forma dirigida y durante semanas. Para eso 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 Frankfurt, 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 7777 UDP, qué en 15000 UDP y qué en 27015 UDP, sin tener que abrir un ticket para ello.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso en lugar de esperar a una ventana de mantenimiento.
• Perfil de protección adaptado al juego. Para servidores de juego de Unreal Engine sobre UDP y para puertos de consulta de Steam hay perfiles listos, igual que para aplicaciones modificadas y propias en cualquier puerto TCP o UDP.

La Advanced DDoS Protection está pensada para servidores que funcionan en KernelHost. Si tu servidor de Mordhau está ahora mismo en otro sitio y lo sacan de la red con regularidad, el traslado es el camino hacia este filtrado.

Los dos niveles en comparación

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

Errores frecuentes y sus soluciones

"Cerré el puerto 27015 y ahora mi servidor ya no aparece en la lista": es la consecuencia esperable. El puerto de consulta de Steam entrega nombre, mapa y número de jugadores al navegador de servidores. Sin él tu servidor deja de aparecer o figura como inaccesible. Lo correcto es una limitación de tasa por dirección de origen en lugar de un bloqueo.

"Los jugadores no entran, aunque el servidor funciona": comprueba primero el puerto 15000 UDP. El beacon reserva el slot durante la carga. Si está bloqueado, filtrado demasiado estrecho o saturado, la entrada se queda colgada aunque el puerto 7777 responda y el servidor aparezca en el navegador.

"Mis cambios en la Game.ini desaparecen después del reinicio": has editado el archivo con el servidor en marcha. El proceso del servidor de Mordhau vuelca al terminar el estado que tiene en memoria y sobrescribe con ello tu versión. Parar el servidor, editar, arrancar, en ese orden.

"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 hace tiempo que 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 tienen picos de lag y los golpes llegan tarde": mira primero si sube la tasa de paquetes entrantes mientras la CPU sigue tranquila. Ese es exactamente el patrón de un ataque. Si la tasa de paquetes se mantiene normal y la CPU está al 100 por ciento, no es un ataque DDoS, sino casi siempre un tickrate demasiado alto, demasiados slots o un mod.

"Mi proveedor avisa de abuso saliente desde el puerto 27015": tu servidor ha sido usado como amplificador para una reflexión. Las consultas llegaron con la dirección de origen falsificada, y quien respondió a una víctima ajena fue tu servidor. Una limitación de tasa en 27015 UDP por dirección de origen acaba con eso.

"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

• Un servidor dedicado de Mordhau necesita exactamente cuatro puertos UDP hacia fuera: 7777 (juego), 7778 (Steam), 15000 (beacon) y 27015 (consulta de Steam). Todo lo demás va cerrado.
• RCON funciona en Mordhau por TCP según el protocolo Source RCON y solo se activa con RconPassword y RconPort en la Game.ini. Limita el puerto a tu propia dirección.
• El puerto 27015 UDP lo puedes limitar, pero no cerrar: sin él tu servidor desaparece del navegador de servidores, porque el número de jugadores, el mapa y el nombre se leen por ese puerto.
• El puerto 15000 UDP es el puerto del beacon y reserva el slot durante la carga. Si está bloqueado o saturado, los jugadores no entran aunque el servidor funcione.
• Edita Game.ini y Engine.ini solo con el servidor parado, porque el proceso del servidor vuelca al terminar el estado que tiene en memoria.
• Las reglas de firewall locales terminan en el ancho de banda: 1 Gbit/s son 125 megabytes por segundo y, con paquetes de 64 bytes, unos 1,49 millones de paquetes por segundo. Por encima de eso decide únicamente la red que hay delante del servidor.
• 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 el filtrado lo consigue con la Advanced DDoS Protection desde 50,00 € al mes.

Si tu servidor de Mordhau 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.