Proteger un servidor de Garry's Mod frente a ataques DDoS

Un servidor de Garry's Mod que desaparece tres minutos a las ocho de la tarde y vuelve después rara vez tiene un problema de hardware. En la inmensa mayoría de los casos hay un ataque en marcha, y ocurre justo cuando hay más jugadores conectados. Por eso, la protección DDoS para Garry's Mod empieza siempre por lo mismo: saber qué paquetes tienen permiso para llegar a tu servidor. Este artículo muestra, en este orden, qué puedes asegurar tú mismo en los próximos diez minutos sin gastar un céntimo, dónde acaban físicamente esas medidas y qué tiene que ocurrir después en la red que hay delante del servidor.

Todos los datos se refieren a un servidor srcds bajo Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS. El archivo de configuración está en garrysmod/cfg/server.cfg, los comandos están escritos para root; si trabajas como usuario normal, antepón sudo. Se habla siempre del funcionamiento sobre un servidor root o dedicado propio, no de un slot contratado a un proveedor de servidores de juego.

Si el ataque está en marcha ahora mismo: no cambies nada en server.cfg y no reinicies srcds. Guarda primero las mediciones (apartado 9), porque cuando el ataque pase habrán desaparecido. Un reinicio te cuesta los contadores y devuelve el servidor a la misma avalancha.

Por qué un servidor de Garry's Mod necesita protección DDoS

Un servidor de Garry's Mod publica por sí solo su dirección IP y su puerto. No es un descuido, sino un requisito: quien no aparece en el navegador de servidores no consigue jugadores nuevos. La entrada existe porque el servidor se registra en el servidor maestro de Steam y a partir de ahí responde a cualquier consulta A2S que llegue desde fuera. Así que la pregunta nunca es si un atacante va a encontrar tu dirección, sino qué pasa cuando dispare contra ella.

A eso se suma el tipo de comunidades. Garry's Mod no se juega por rondas, sino en mundos permanentes: una comunidad de DarkRP lleva cuentas de jugador, propiedades, trabajos y progreso durante meses en una base de datos. Una caída el viernes por la noche cuesta entonces más que una partida perdida, cuesta jugadores habituales. Justo por eso, las comunidades rivales, los jugadores baneados y los server booter comprados (servicios que, por unos pocos euros al mes, lanzan ataques contra cualquier dirección) son los tres desencadenantes más frecuentes. Al atacante no le hacen falta ni conocimientos ni un dinero digno de mención.

Técnicamente se juntan tres particularidades. El tráfico de juego va por UDP, y UDP no tiene un establecimiento de conexión que se pueda exigir: las direcciones de origen se pueden falsificar. La consulta de servidor está en el mismo puerto que el juego, así que un bloqueo tosco afecta siempre a los dos. Y por encima de todo está Lua: cada addon del Workshop mete su propio código en el mismo proceso, y basta un único evento de red sin proteger para que un solo cliente frene el servidor sin ancho de banda alguno. Qué es en esencia un ataque DDoS lo explica el artículo ¿Qué es un ataque DDoS?.

Los puertos de los que se trata realmente en Garry's Mod

Un servidor de Garry's Mod arranca por defecto en el puerto 27015, y lo hace en UDP para el juego junto con la consulta de servidor y en TCP para RCON. El número se cambia al arrancar con -port; con varias instancias se va subiendo (27016, 27017 y así sucesivamente). Un comando de arranque típico tiene este aspecto:

./srcds_run -game garrysmod -console \
  -port 27015 \
  +maxplayers 64 \
  +gamemode darkrp \
  +map rp_downtown_v4c_v2 \
  +sv_setsteamaccount IHR_GSLT_TOKEN \
  +host_workshop_collection 123456789 \
  -authkey IHR_STEAM_WEB_API_KEY

De ahí sale toda la superficie de ataque. La tabla siguiente es la base de cualquier regla de firewall de las que vienen más abajo:

De estas ocho entradas, exactamente una pertenece sin restricciones a la internet abierta: 27015/UDP. Todo lo demás se limita a tu propia dirección, se enlaza a 127.0.0.1 o directamente no se arranca. El error de razonamiento más caro en este terreno es suponer que en Garry's Mod existe un puerto de query separado que se puede cerrar sin más. No existe.

Qué puedes hacer tú mismo antes de gastar dinero

Este apartado es el más largo, y lo es a propósito. Un servidor de Garry's Mod bien configurado aguanta por su cuenta los ataques pequeños y medianos, esté alojado donde esté. Nada de esto cuesta dinero, y la mayor parte está hecha en un cuarto de hora.

1. Inventario: qué está escuchando de verdad

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:27015 y [::]:27015 significan "accesible desde todo internet", 127.0.0.1:3306 significa "solo local" y no necesita ninguna regla de firewall. En un servidor de DarkRP que lleva tiempo creciendo casi siempre hay más servicios de los esperados: MySQL, un servidor web para FastDL, un panel, un bot de Discord, un segundo servidor de pruebas en 27016 y un servicio de voz olvidado hace tiempo. La vista del atacante te la da un escaneo de puertos desde fuera:

nmap -Pn -sU -sT -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

2. Dejar abiertos solo los puertos que srcds necesita de verdad

A Garry's Mod le basta con una única apertura hacia fuera, más SSH y el acceso RCON restringido. 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 27015/udp comment 'Garrys Mod Spiel und A2S'
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment '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. SourceTV en 27020/UDP solo lo abres si de verdad retransmites. La guía completa, con vía de rescate incluida, está en Configurar el firewall UFW sin quedarte fuera del servidor. Y si aun así ocurre: los servidores root KVM y los servidores dedicados de KernelHost no tienen IPMI ni iDRAC, así que vuelves a entrar por la consola VNC del área de cliente. Esa consola no depende del stack de red del sistema invitado, y ninguna regla de firewall dentro del invitado puede bloquearla.

La base de datos no tiene nada que hacer en la internet 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. Limitar la consulta A2S sin caerte de la lista de servidores

Aquí está el error que les cuesta el servidor a la mayoría de las comunidades de Garry's Mod. Como el tráfico de juego y la consulta de servidor ocupan el mismo puerto, un bloqueo general o un límite de tasa demasiado estrecho sobre 27015/UDP echa fuera a tus propios jugadores y termina el ataque por su cuenta. El punto de partida correcto es distinguir entre paquetes de consulta y paquetes de juego.

El motor trae para eso tres variables de consola que van en server.cfg. Sus valores por defecto son conservadores, pero están puestos:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

sv_max_queries_sec limita las consultas respondidas por dirección de origen (3 por segundo por defecto), sv_max_queries_sec_global pone un tope a la suma de todas las direcciones (60 por segundo por defecto) y sv_max_queries_window fija la ventana de promediado (30 segundos por defecto). Estos valores protegen a la CPU de generar respuestas inútiles. No impiden que los paquetes lleguen, y quien aprieta mucho el valor global desaparece del navegador de servidores durante el ataque, porque también quedan sin respuesta las consultas de las páginas de listados.

Un nivel más abajo, el tráfico de consultas se puede separar limpiamente. Todos los paquetes sin conexión del motor Source empiezan con cuatro bytes puestos a uno (0xffffffff), mientras que el tráfico de los jugadores ya conectados no lleva esa cabecera. Justo sobre eso se puede poner con nftables un límite de tasa por dirección de origen:

table inet gmod {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 8/second burst 20 packets } drop
    }
}

El archivo se carga con nft -f. La prioridad -10 hace que la regla actúe antes que la cadena de filtrado de UFW, y @th,64,32 lee los primeros cuatro bytes que hay detrás de la cabecera UDP. Con iptables clásico, una comparación u32 consigue lo mismo:

iptables -A INPUT -p udp --dport 27015 \
  -m u32 --u32 "0>>22&0x3C@8=0xFFFFFFFF" \
  -m hashlimit --hashlimit-name gmod_a2s --hashlimit-mode srcip \
  --hashlimit-above 8/sec --hashlimit-burst 20 -j DROP

Un punto que casi todas las guías de internet se callan: no solo la consulta de servidor va sin conexión, también el establecimiento de la conexión. Un jugador que entra envía varios paquetes con la misma cabecera antes de estar dentro de la partida. Por eso, un límite demasiado estrecho deja fuera a los jugadores nuevos aunque el servidor siga siendo accesible. Empieza con margen (de 8 a 15 paquetes por segundo y dirección) y aprieta el límite solo cuando hayas medido una semana de funcionamiento normal.

4. Asegurar RCON o apagarlo del todo

RCON es un objetivo apetecible en los servidores Source, y por tres motivos a la vez. Primero, está en el mismo número de puerto que el juego, solo que en TCP, así que se encuentra sin buscar. Segundo, el protocolo Source RCON transmite la contraseña en texto claro, sin TLS y sin intercambio de claves: quien lee el tráfico, la tiene. Tercero, la ganancia es máxima, porque quien tiene RCON puede cambiar el mapa, banear a todos los jugadores, modificar la configuración y parar el servidor. Un atacante que se hace con RCON ya no necesita ancho de banda alguno.

No dejes nunca rcon_password vacía ni la pongas a ojo, con un valor de openssl rand -base64 32 basta. Contra los intentos de inicio de sesión, el motor trae un freno:

rcon_password "HIER_EIN_LANGES_ZUFALLSPASSWORT"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Con esto, una dirección queda bloqueada durante un día tras tres intentos fallidos en 30 segundos. Dos avisos al respecto. Primero, ese mismo mecanismo deja fuera también a tu propio panel de administración si ahí hay guardada una contraseña antigua: lo que los operadores notifican como "RCON ha dejado de funcionar de golpe" suele ser el bloqueo propio. Segundo, la restricción de firewall del paso 2 sigue siendo más eficaz, porque no deja que el intento llegue siquiera hasta la aplicación. Quien solo necesita RCON de vez en cuando deja el puerto cerrado del todo y trabaja mediante una redirección de puertos por SSH:

ssh -N -L 27015:127.0.0.1:27015 root@IHRE.SERVER.IP.ADRESSE

5. Limitar los mensajes de red de Lua, la caída casera más frecuente

Una parte considerable de las caídas de Garry's Mod que se notifican como DDoS no lo son. Son sobrecargas de Lua, provocadas por un único cliente conectado con unos pocos kilobits por segundo. El motivo está en cómo está construida la biblioteca net: en cuanto un addon registra un evento de red con util.AddNetworkString y lo escucha con net.Receive, cualquier cliente puede disparar ese evento en bucle. Sin un límite propio, el servidor ejecuta cada uno de los mensajes. Facepunch lo ha documentado varias veces en sus propios informes de error y no ha previsto ninguna solución dentro del motor: limitar es expresamente tarea del autor del addon.

Revisa por eso cada addon propio y cada addon comprado en tres puntos: un tope por jugador y segundo, una comprobación de la longitud del mensaje, y que el jugador se determine en el lado del servidor a partir del segundo parámetro en lugar de a partir del contenido del mensaje. Un patrón que aguanta tiene este aspecto:

util.AddNetworkString("khrp_buy")

local budget = {}

net.Receive("khrp_buy", function(len, ply)
    if not IsValid(ply) then return end
    if len > 256 then return end

    local now = CurTime()
    local b = budget[ply]

    if not b or now - b.start >= 1 then
        b = { start = now, count = 0 }
        budget[ply] = b
    end

    b.count = b.count + 1
    if b.count > 10 then return end

    KHRP.HandleBuy(ply, net.ReadString())
end)

hook.Add("PlayerDisconnected", "khrp_budget_cleanup", function(ply)
    budget[ply] = nil
end)

A eso se suman dos líneas en server.cfg. sv_allowcslua está en Garry's Mod a 1 por defecto y permite a los clientes ejecutar su propio código con lua_run_cl y lua_openscript_cl: en un servidor público ese valor tiene que estar a 0. Y sv_kickerrornum desconecta a los clientes que generan más errores del lado del cliente que el número indicado (0 por defecto, es decir, desactivado):

sv_allowcslua 0
sv_kickerrornum 25

6. Separar del servidor de juego los contenidos del Workshop y FastDL

Los addons del Workshop no son un asunto marginal en Garry's Mod, son la norma: una comunidad de DarkRP enlaza su colección con +host_workshop_collection y los clientes descargan esos contenidos directamente de Steam. Eso no carga tu línea. La clave de -authkey es una clave de la Steam Web API y hay que tratarla como una contraseña: va en el script de arranque, no en un repositorio público ni en un canal de Discord.

El ancho de banda lo cuesta el segundo camino. Todo lo que no viene del Workshop (mapas propios, sonidos, materiales) pasa por el canal de descarga. Sin sv_downloadurl, ese canal va por el propio puerto de juego y compite directamente con el tráfico de la partida. Con FastDL va por HTTP. Si ese servidor web está en el mismo host y en la misma dirección IP, los dos comparten la misma línea: una oleada de entradas o un ataque contra 80/TCP afecta entonces también al juego. Estos valores tienen sentido:

sv_downloadurl "https://fastdl.ihre-domain.de/garrysmod/"
sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64

sv_allowupload 0 les quita a los clientes la posibilidad de enviar archivos propios al servidor y cierra así una vía que ni se necesita ni se controla. net_maxfilesize limita en megabytes el tamaño de los archivos transferidos por el canal de juego. Pon FastDL, si es posible, en otro host o detrás de un nombre propio: así la carga no recae sobre la misma dirección que el puerto de juego.

7. Frenar la avalancha de entradas y el agotamiento de plazas

El agotamiento de plazas es un ataque que no necesita ancho de banda: el atacante ocupa con conexiones automatizadas todas las plazas libres, de modo que los jugadores reales se encuentran un servidor lleno. En Garry's Mod hay un agravante, y es que cada entrada le cuesta trabajo al servidor, porque se negocian la lista de recursos y el gamemode mucho antes de que el jugador esté en la partida.

Contra eso funcionan cuatro cosas. Primera, un tope realista: poner +maxplayers más alto de lo que tu gamemode soporta solo agranda la superficie de ataque. Segunda, sv_timeout, que fija tras cuántos segundos sin mensaje se desconecta a un cliente (120 en las configuraciones más extendidas): quien quiera deshacerse antes de las medias conexiones colgadas, baja el valor. Tercera, el límite de tasa sobre los paquetes sin conexión del paso 3, porque el establecimiento de la conexión pasa justo por ahí. Cuarta, para grupos cerrados, una contraseña de servidor:

sv_password "stammgruppe_2026"
sv_timeout 90
sv_filterban 1
sv_region 3

Garry's Mod no trae una whitelist de verdad, esa llega a través de extensiones como ULX o mediante una comprobación propia en el hook CheckPassword. 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 punto.

8. Aliviar el kernel: seguimiento de conexiones y búfer de recepción

Este paso explica caídas que parecen un ataque de volumen sin serlo. El kernel crea entradas en el seguimiento de conexiones (conntrack) para el tráfico UDP y, con direcciones de origen falsificadas, cada dirección significa una entrada nueva. Cuando la tabla se llena, el kernel descarta paquetes sin distinguir: el ataque y tus jugadores se van fuera juntos, y en el log del sistema aparece "nf_conntrack: table full". El estado y el límite los muestra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

El paso más eficaz es no dejar que el tráfico de juego se rastree siquiera, porque el motor gestiona sus propias sesiones:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 27015, 27020 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 27015, 27020 } notrack
    }
}

Con iptables, el equivalente es iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK y la misma línea para OUTPUT con --sport. Después el puerto necesita una apertura explícita, porque sin seguimiento ya no actúa ninguna regla que compruebe un estado existente. Y si además los paquetes llegan más rápido de lo que srcds los recoge, el búfer de recepción se desborda, y para los jugadores eso se ve como pérdida de paquetes con la línea libre:

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

Esas líneas van en un archivo dentro de /etc/sysctl.d/ y se activan con sysctl --system. Si hacen falta o no te lo dice el propio kernel: si UdpRcvbufErrors sube en nstat -az, entonces sirven. Si el contador se queda en cero, el ajuste no cambia nada. Esto es reserva, no protección.

9. Guardar mediciones 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. 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. Calcula una vez el valor normal de tu servidor: 64 jugadores con cl_cmdrate 66 generan unos 4.200 paquetes entrantes por segundo, y todo lo que esté claramente por encima pide una explicación. 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
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"

El primero muestra paquetes y bytes por segundo, el segundo los contadores de descartes de la interfaz y el tercero los contadores de error UDP del kernel. La cuarta línea muestra únicamente los paquetes sin conexión, es decir, exactamente la clase que aprovecha una avalancha de consultas: si el contador se dispara en segundos mientras casi nadie está conectado, ya tienes tu respuesta. Limita tcpdump 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 en el servidor.

Qué es el agujero de A2S Reflection y si todavía me afecta

A2S Reflection es un ataque en el que tu servidor no es el objetivo, sino la herramienta. El atacante envía una consulta pequeña con la dirección de origen falsificada a miles de servidores de juego, y las respuestas de esos servidores, bastante más grandes, confluyen todas en la víctima real. Históricamente, una petición A2S_INFO medía 25 bytes (4 bytes 0xFFFFFFFF, 1 byte 0x54, más 20 bytes para la cadena "Source Engine Query"), mientras que la respuesta ocupaba varios cientos de bytes. El US-CERT recoge el protocolo de Steam en su lista de ataques de amplificación con un factor de 5,5, lo que significa: de un gigabit en el atacante salen 5,5 gigabits en la víctima.

Valve cerró ese agujero a partir de noviembre de 2020, y lo hizo por dos vías. Desde entonces, el emisor tiene que rellenar los paquetes de consulta sin conexión hasta 1.200 bytes, con lo que la petición es más grande que la respuesta y el factor de amplificación cae por debajo de 1. Durante el cambio, los operadores podían forzar de antemano el comportamiento más estricto con la variable de entorno STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200. Además, ante A2S_PLAYER y A2S_RULES el servidor ya no responde de inmediato con datos, sino con un challenge (S2C_CHALLENGE) que quien pregunta tiene que devolver en una segunda petición. Quien falsifica la dirección de origen no llega a ver nunca ese challenge.

Para ti se derivan de ahí dos cosas. Mantén el binario del servidor al día, porque la protección está en la base del servidor de juego de Steam y no en tu configuración. Y no confundas la reflexión con una avalancha de consultas dirigida contra ti: contra esa segunda forma solo sirven el límite de tasa del paso 3 y, más allá de eso, el filtrado en la red que hay delante del servidor.

Dónde terminan estas medidas: ancho de banda y tasa de paquetes

Llega ahora la parte que ningún archivo de configuración puede resolver. Todo lo descrito hasta aquí corre 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. La segunda magnitud suele golpear antes: con el tamaño de paquete más pequeño posible, 64 bytes, en 1 Gbit/s caben unos 1,49 millones de paquetes por segundo, y en 10 Gbit/s unos 14,88 millones. 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í todos tenían lag spikes".

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

Qué pone KernelHost frente a eso

La protección permanente incluida en todos los paquetes de servidor

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 incluso 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 ningún tiempo de conmutación durante el cual tus jugadores se caigan. Y no se recurre al 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 comunidades atacadas de forma continua

Algunos proyectos no reciben ataques de vez en cuando, sino de forma dirigida y durante semanas, con patrones cambiantes y siempre justo a la hora punta. Para esos casos 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 Frankfurt, a la que se pasa tu servidor dentro de nuestra propia red. Por tu parte 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 27015/UDP y qué en 27015/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 en lugar de esperar a la siguiente ventana de mantenimiento.
• Perfil de protección acorde a cada juego, tanto para Garry's Mod y los demás títulos Source como perfiles TCP y UDP libres para servidores modificados y aplicaciones propias.

Aquí también rige el modelo PrePaid: sin permanencia mínima, sin plazo de preaviso, sin contrato y sin cuota de instalación. Cuando pase la oleada de ataques, simplemente no renuevas. Quien tenga su servidor de Garry's Mod alojado hasta ahora en otro sitio obtiene esta protección mudándose a KernelHost, porque el filtrado se hace en nuestra propia red y no sobre infraestructura ajena.

Los dos niveles de protección en comparación

Para la mayoría de las comunidades de Garry's Mod 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 soluciones

"El servidor funciona, pero ha desaparecido del navegador de servidores": normalmente se ha bloqueado 27015/UDP en bloque o se le ha puesto un límite de tasa demasiado estrecho. Como el tráfico de juego y la consulta comparten puerto, una regla tosca afecta a los dos. Trabaja en su lugar con la comparación sobre los paquetes sin conexión. Si el servidor sigue invisible aunque el puerto sea accesible, revisa sv_setsteamaccount: sin un Game Server Login Token válido, un servidor de Garry's Mod queda muy degradado en la lista, y cada servidor necesita su propio token.

"Mi regla de iptables es correcta y aun así no surte efecto": hay tres causas frecuentes. La regla está detrás de las cadenas de UFW y no se alcanza nunca, se perdió con el último reinicio (entonces ayudan apt-get install -y iptables-persistent y 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.

"Mi servidor de DarkRP va a tirones para todos, pero la línea está libre": eso es casi siempre Lua y no un ataque contra la línea. Mira en el log del servidor qué evento de red llega con una frecuencia llamativa y revisa si el addon correspondiente tiene un límite por jugador. Si sar -n DEV 1 10 y los contadores de descartes no muestran nada raro, no era un ataque DDoS.

"RCON ha dejado de funcionar de golpe": no es un DDoS, sino casi siempre el bloqueo propio. Un panel de administración con una contraseña antigua dispara sv_rcon_minfailures, y sv_rcon_banpenalty bloquea la dirección durante los minutos configurados. Corrige la contraseña, levanta el bloqueo y restringe después el puerto a tu propia dirección.

"Cambié la dirección IP y dos días después estaba otra vez fuera": es lo normal. Tu servidor publica él mismo la dirección nueva en cuanto vuelve a estar registrado en el servidor maestro, y un servidor de juego sin dirección pública no tiene jugadores. Un cambio de dirección da horas o días, no es una solución.

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

En resumen

• Un servidor de Garry's Mod necesita exactamente un puerto abierto: 27015/UDP. El tráfico de juego y la consulta A2S pasan juntos por ahí, no existe un puerto de query separado.
• RCON está en 27015/TCP, transmite la contraseña en texto claro y solo debe abrirse para tu propia dirección o alcanzarse mediante una redirección de puertos por SSH.
• No limites el puerto, limita los paquetes sin conexión que llevan la cabecera 0xffffffff. Un bloqueo general sobre 27015/UDP echa fuera a tus propios jugadores.
• La caída más frecuente en Garry's Mod no es un ataque DDoS, sino un evento de red sin límite: cada evento registrado con util.AddNetworkString necesita un tope por jugador y segundo.
• Con paquetes de 64 bytes, una línea de 1 Gbit/s transporta unos 1,49 millones de paquetes por segundo. Por encima de eso la pérdida se produce en el router anterior, y cualquier regla local deja de servir.
• En KernelHost, la protección permanente en dos niveles está incluida en cada paquete de servidor sin recargo: 17 Tbps de capacidad de mitigación en la red global de scrubbing y filtrado Arbor en tiempo real con 3,2 Tbps en Frankfurt am Main, sin null-routing.
• Quien recibe ataques dirigidos de forma continua añade la Advanced DDoS Protection desde 50,00 € al mes: IP de protección dedicada, reglas autogestionables por puerto y protocolo, con efecto en tiempo real.

Si tu servidor 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. Indica directamente cuatro datos: dirección IP, puerto, franja de tiempo en tu zona horaria y qué estás viendo (los jugadores se caen, el servidor no aparece en el navegador, lag spikes). Durante un ataque en curso también puedes contactarnos por el chat de emergencia de WhatsApp en el +43 650 8209883.

Quien, además de Garry's Mod, gestiona otros títulos Source encontrará las bases comunes en Proteger servidores CS2 y Source frente a ataques DDoS, y cómo se monta limpiamente la base está en Instalar un servidor de juego con SteamCMD.