Proteger un servidor de Left 4 Dead 2 frente a ataques DDoS

Un servidor de Left 4 Dead 2 rara vez se cae en un momento cómodo. Se cae en el último tramo de una campaña, en la segunda vuelta de una partida de Versus o justo cuando un jugador baneado ha sido rechazado por tercera vez. Quien está recibiendo el ataque no necesita un debate de fondo sobre redes, sino un orden de trabajo. Este artículo muestra primero cómo proteger un servidor de Left 4 Dead 2 frente a ataques DDoS mientras eso todavía se puede hacer con los medios del propio servidor, después dónde acaban físicamente esas posibilidades y, por último, qué tiene que ocurrir antes, dentro de la red.

Todos los datos se refieren a un servidor dedicado (srcds), instalado con SteamCMD bajo el App ID 222860, 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. Un punto por delante, porque marca el orden: durante un ataque en curso no cambies nada a ciegas y no reinicies el servidor antes de haber guardado las mediciones. Cuando el ataque pase habrán desaparecido.

Por qué los servidores de Left 4 Dead 2 son un objetivo DDoS rentable

La diferencia con un shooter de 64 plazas está en el tamaño de la partida. Una campaña cooperativa tiene cuatro plazas para los supervivientes, una partida de Versus ocho plazas entre ambos bandos. Por eso una caída no afecta nunca a jugadores sueltos, sino siempre a la partida entera: quien interrumpe una campaña en el tercero de cinco tramos ha terminado la noche para todos los participantes. Justo eso hace atractivo un ataque para quien lo encarga, porque no le cuesta ni conocimientos ni un dinero digno de mención, mientras que al otro lado destruye una hora de juego.

A eso se suma el diseño. Left 4 Dead 2 corre sobre el motor Source, y un servidor Source se localiza públicamente por dirección IP y puerto. Eso es un requisito, no un descuido: un servidor que no responde a ninguna consulta no aparece en ninguna lista y no lo encuentra ninguna lobby. Así que la pregunta nunca es si un atacante conoce tu dirección, sino qué pasa cuando dispare contra ella. El tráfico de juego va por UDP, y UDP no tiene un establecimiento de conexión que se pueda exigir, y además las direcciones de origen se pueden falsificar. Qué ocurre técnicamente en ese proceso lo explica el artículo ¿Qué es un ataque DDoS?.

Un tercer punto es propio de Left 4 Dead 2 y no tiene equivalente en Counter-Strike, Garry's Mod o Team Fortress 2: la mayoría de los jugadores no llega por el navegador de servidores, sino por el sistema de lobbies. Una lobby de hasta cuatro jugadores se envía a través del matchmaking de Steam a un servidor dedicado, que recibe para ello una reserva. Ese procedimiento es al mismo tiempo tu filtro de acceso más eficaz y una superficie de ataque adicional. Las dos cosas vienen más abajo en detalle.

Los puertos de los que se trata realmente

Un servidor de Left 4 Dead 2 ocupa exactamente un puerto UDP para todo lo que constituye el juego. El estándar es 27015, definido con -port o con +hostport en la línea de arranque:

./srcds_run -game left4dead2 -console -nohltv \
  -port 27015 \
  +ip 203.0.113.10 \
  +maxplayers 4 \
  +exec server.cfg \
  +map c1m1_hotel

La primera fila de esta tabla es el núcleo del problema. El tráfico de juego y la consulta de servidor comparten 27015/UDP: en Left 4 Dead 2 no existe un puerto de query separado. Quien bloquea ese puerto en bloque o le aplica un límite de tasa tosco echa fuera de paso a sus propios jugadores y termina el ataque en el sentido que quería el atacante.

Una petición A2S es un paquete de unas pocas decenas de bytes, la respuesta es un múltiplo de eso. En UDP, la dirección de origen se puede falsificar, y con ello tu servidor deja de ser solo la víctima y pasa a ser el amplificador: un atacante consulta servidores de juego ajenos con la dirección de su objetivo y desvía las respuestas hacia allí. Valve añadió a A2S_INFO en diciembre de 2020 una petición previa (S2C_CHALLENGE) que quien consulta tiene que devolver antes de recibir la respuesta. Eso suaviza la reflexión, pero no la termina, porque los programas de consulta antiguos se siguen atendiendo.

Qué puedes hacer tú mismo antes de gastar dinero

La parte que viene no cuesta nada y merece la pena independientemente de dónde esté tu servidor. No te va a quitar de encima un ataque volumétrico, pero hace que los ataques pequeños y medianos se queden en nada, y elimina las caídas que se notifican como ataque DDoS sin serlo.

1. Inventario: qué está escuchando de verdad

Antes de escribir una regla, aclara qué servicios son accesibles. En un servidor de Left 4 Dead 2 que lleva tiempo creciendo casi siempre hay más de los esperados, porque junto a srcds corren también un servidor web para las campañas, una base de datos de estadísticas y, a veces, un segundo servidor para Versus:

ss -lntup

Todo lo que esté enlazado a 127.0.0.1 o a ::1 no necesita ninguna apertura. Todo lo que escuche en 0.0.0.0 o en [::] es accesible desde internet. La vista del atacante te la da un escaneo de puertos desde fuera, y por experiencia no coincide con lo que uno espera:

nmap -Pn -sU -sT -p 27000-27050,80,443,3306 IHRE.SERVER.IP.ADRESSE

Si la base está recién montada o quieres reconstruir el camino, el artículo Instalar un servidor de juego con SteamCMD describe el recorrido desde SteamCMD hasta el srcds en marcha.

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

Un puerto UDP hacia fuera, un puerto TCP para tu propia dirección, nada más. RCON no pinta nada en la internet abierta, porque quien tiene RCON cambia el mapa, banea a todos los jugadores y para el servidor:

ufw allow 27015/udp comment "L4D2 Spielport und A2S"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

Sustituye 203.0.113.10 por tu propia dirección. Si esa dirección cambia con frecuencia, el camino pasa por una redirección de puertos por SSH en lugar de por una apertura permanente. El orden en el que activas el firewall decide si te dejas fuera a ti mismo; ese orden, con su vía de vuelta, está en el artículo Configurar el firewall UFW sin quedarte fuera del servidor. Y si aun así pasa: los servidores root KVM y los servidores dedicados de KernelHost no tienen IPMI ni iDRAC, así que llegas al servidor por la consola VNC del área de cliente, y esa consola no depende del stack de red del sistema invitado.

3. Frenar la consulta A2S sin caerte de la búsqueda por lobby

Aquí está el error más caro de todo este terreno. Como el tráfico de juego y la consulta de servidor ocupan el mismo puerto, el freno tiene que distinguir entre las dos clases de paquetes, no entre puertos.

La base del servidor de juego de Steam trae para ello, desde los cambios de diciembre de 2020, un límite propio que se define antes del arranque como variable de entorno. STEAM_GAMESERVER_RATE_LIMIT_200MS=N descarta los paquetes sin conexión (A2S_INFO, A2S_RULES, A2S_PLAYERS) de una dirección de origen en cuanto llegan más de N en una ventana de 200 milisegundos. Valve menciona de 25 a 75 como rango útil; por defecto el límite está desactivado:

export STEAM_GAMESERVER_RATE_LIMIT_200MS=50
./srcds_run -game left4dead2 -console -port 27015 +exec server.cfg +map c1m1_hotel

En una unidad de systemd, ese mismo valor va como Environment=STEAM_GAMESERVER_RATE_LIMIT_200MS=50 en la sección [Service], porque si no desaparece tras el siguiente reinicio. Ese freno solo actúa si tu build de servidor trae la base actual de Steamworks, y protege el tiempo de proceso de tu servidor, no tu línea: los paquetes ya han llegado.

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

table inet l4d2 {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/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. Empieza con margen y aprieta el límite solo cuando compruebes que las consultas legítimas pasan: tu propia entrada en la lista de servidores depende de ello.

4. Usar el sistema de lobbies como filtro de acceso

Esta es la palanca que solo tienen Left 4 Dead 2 y su predecesor. El servidor decide por sí mismo si acepta siquiera conexiones que vengan de fuera del matchmaking. Eso lo determinan cuatro directivas en server.cfg:

sv_allow_lobby_connect_only 1
sv_search_key "ihr-eigener-schluessel"
sv_steamgroup "103582791400000000"
sv_steamgroup_exclusive 2

• sv_allow_lobby_connect_only 1 permite exclusivamente las entradas que vienen de una lobby de matchmaking. Un connect 203.0.113.10:27015 desde la consola de desarrollador y una invitación de Steam quedan rechazados. El valor 0 permite las dos cosas.
• sv_search_key es una clave de búsqueda que eliges libremente. Solo una lobby en la que esté puesta esa misma clave encuentra el servidor a través del matchmaking. Sin esa clave, el servidor no aparece en la búsqueda pública.
• sv_steamgroup vincula el servidor a un grupo de Steam y hace que aparezca entre los servidores de ese grupo.
• sv_steamgroup_exclusive tiene tres niveles: 0 deja pasar a cualquiera, 1 se comporta como 0 pero exige la entrada a través de una lobby, y 2 deja pasar únicamente a los miembros del grupo y al acceso directo por dirección IP.

Para una comunidad fija, la combinación de clave de búsqueda y sv_steamgroup_exclusive 2 es el filtro de acceso gratuito más eficaz que conoce el juego. Un servidor público no puede usarla, porque un servidor que nadie encuentra está igual de vacío que uno que está offline.

Y ahora la parte que los textos publicitarios suelen omitir: estas directivas protegen tu lógica de juego, no tu línea. Un atacante que inunda 27015/UDP no quiere entrar. Sus paquetes se rechazan, pero han llegado igualmente, han consumido ancho de banda y han costado un recorrido por el stack de red. Contra una avalancha de entradas desde cuentas desechables, sv_allow_lobby_connect_only 1 funciona de maravilla; contra un booter no funciona en absoluto.

5. La reserva de lobby y cuándo sv_force_unreserved es la mejor opción

Una reserva de lobby es una ocupación temporal de tu servidor por parte de una lobby de matchmaking. Mientras existe, el servidor cuenta como asignado para las demás lobbies, y solo expira por sí sola pasado un rato. Para un servidor de cuatro plazas eso es un recurso escaso: a diferencia de un shooter de 32 o 64 plazas, hace falta muy poco para bloquear una partida.

Quien no gestiona su servidor a través del matchmaking elimina esa superficie por completo:

sv_force_unreserved 1
sv_allow_lobby_connect_only 0

sv_force_unreserved 1 hace que el servidor deje de responder a las peticiones de reserva del sistema de lobbies y rechace las entradas que lleven una marca de reserva. Ese mismo ajuste lo necesitas de todas formas si gestionas más de cuatro plazas cooperativas con L4DToolZ, porque de lo contrario la lobby recibe una reserva en cuanto se ocupan las cuatro primeras plazas y las restantes quedan inalcanzables. La contrapartida es clara: tus jugadores entran entonces solo por el navegador de servidores o mediante connect.

Decide conscientemente por uno de los dos modos de funcionamiento. La mezcla de matchmaking a medias y entrada directa a medias es la variante que reúne los inconvenientes de ambos.

6. Asegurar RCON

Un puerto RCON abierto con una contraseña débil no es un problema de DDoS, es una toma de control. No dejes nunca rcon_password vacía ni la pongas a ojo, con un valor de openssl rand -base64 32 basta. Los títulos Source traen además un freno contra los intentos de inicio de sesión:

rcon_password "HIER_EIN_ZUFAELLIGER_WERT"
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; find sv_rcon en la consola del servidor muestra cuáles de esas variables conoce tu build. Aun así, 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. Si no necesitas RCON, deja la contraseña vacía: entonces la parte TCP de 27015 no escucha.

7. Sacar fuera las campañas personalizadas en lugar de servirlas por el puerto de juego

Las campañas personalizadas son el motivo por el que Left 4 Dead 2 se sigue jugando quince años después y, a la vez, una fuente de carga que en Counter-Strike no existe de esta forma. Una campaña es un paquete VPK con mapas, modelos, texturas y sonidos, es decir, un múltiplo de lo que pesa un solo mapa competitivo.

El camino cómodo para los jugadores es el Steam Workshop: el paquete viene entonces de Steam y no de tu servidor, y no te cuesta ancho de banda. Si sirves tú mismo archivos sueltos, esa entrega corresponde a un servidor web y no al puerto de juego:

sv_allowdownload 1
sv_allowupload 0
sv_downloadurl "https://cdn.example.org/l4d2/"
sv_consistency 1

Los archivos para sv_downloadurl van al servidor web como archivo bzip2, así que meinekarte.bsp pasa a ser meinekarte.bsp.bz2. Sin sv_downloadurl, srcds envía los archivos él mismo por la conexión de juego, y entonces vale esto: cada intento de conexión de un jugador nuevo te cuesta la descarga completa, y cada interrupción a mitad de descarga también. Es una manera bastante barata de llenar una línea, y en ninguna estadística parece un ataque.

Tres puntos al respecto que duelen en la práctica. sv_allowupload 0 debe estar puesto, porque no necesitas subidas del cliente al servidor. Si el servidor web de sv_downloadurl está en el mismo host que el juego, la descarga y el tráfico de juego comparten la misma línea y la misma dirección IP, y entonces un ataque contra 443/TCP afecta también a tu partida en curso. Y sv_consistency 1 no es una protección contra ataques, sino contra archivos de cliente divergentes; solo deberías desactivarlo si una campaña demuestra no arrancar de otra manera.

8. SourceMod, Metamod y las extensiones

Una parte considerable de las caídas que se notifican como DDoS no lo son. Son crashes y picos de carga que provoca un único cliente, porque en el binario del servidor o en una extensión hay un agujero abierto. Contra eso no ayuda el ancho de banda, sino el mantenimiento:

• Mantén Metamod:Source y SourceMod acordes a la versión del motor. Left 4 Dead 2 sigue recibiendo actualizaciones, y una extensión que no encaja es el motivo más frecuente de crashes justo después de una actualización.
• Left4DHooks en lugar de intervenciones propias. Los eventos propios de L4D2 están agrupados en esa extensión. Intervenir por tu cuenta en esas mismas funciones es el camino más rápido hacia un binario de servidor que se cae ante determinadas secuencias de paquetes.
• Usa L4DToolZ solo de forma consciente. Esa extensión sube los límites de plazas fijados en el propio juego. Cada plaza adicional es un jugador adicional que genera tiempo de proceso y, en combinación con el sistema de lobbies, necesita sv_force_unreserved 1.
• Menos extensiones. Cada plugin es código dentro del mismo proceso. Las extensiones con servicios web propios abren puertos adicionales y muchas veces publican justo la dirección que quieres proteger.

Los baneos hay que guardarlos de forma permanente, si no desaparecen tras el reinicio. Los títulos Source tienen para eso banid con writeid y addip con writeip, y los archivos generados se vuelven a leer mediante exec banned_user.cfg y exec banned_ip.cfg.

9. Aliviar el seguimiento de conexiones y el búfer de recepción

Este punto se pasa por alto a menudo y 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. El estado y el límite los muestra un vistazo:

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 notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport 27015 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. Si los paquetes llegan más rápido de lo que srcds los recoge, se desborda además el búfer de recepción, y para los jugadores eso se ve como pérdida de paquetes en una línea libre:

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

El archivo lo dejas en /etc/sysctl.d/ y lo activas con sysctl -p. Si esos valores hacen falta siquiera 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.

10. Medir para no tener que adivinar durante el ataque

Durante un ataque la pregunta más importante es: cuánto llega, por qué puerto, y si es tráfico de consulta o de juego. Bastan cuatro comandos:

ip -s link show eth0
nstat -az | grep -i udp
sar -n DEV 1 10
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"

El primer comando lo ejecutas dos veces con diez segundos de diferencia, y así tienes una tasa en lugar de un valor absoluto. La última 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. Deja la captura corta, porque bajo carga consume tiempo de proceso ella misma. Cómo interpretar los valores está en el artículo Detectar un ataque DDoS en el servidor.

El paso más importante es, en todo caso, 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 el servidor de Versus lleno.

Dónde terminan estas medidas

Ahora la parte honesta. Todo lo descrito hasta aquí solo actúa cuando los paquetes ya han llegado a tu tarjeta de red. 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, lo que equivale a 125 megabytes por segundo. Con el tamaño de paquete más pequeño posible, esa línea transporta unos 1,49 millones de paquetes por segundo, y una de 10 Gbit/s unos 14,88 millones. Ese es el límite físico, independientemente de la CPU, del kernel y del firewall. Un kernel de servidor normal procesa, según el procesador y la tarjeta de red, unos cientos de miles de paquetes por segundo 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 perdió todo".

Frente a eso están los ataques reales. Dos ejemplos de la operativa en KernelHost, ambos filtrados en tiempo real: un flood UDP contra un servidor de juego en 7777/UDP con más de 112,2 Gbit/s y más de 8,7 millones de paquetes por segundo, y un ataque multivector contra un servidor de voz en 9987/UDP con más de 473,4 Gbit/s y más de 41,5 millones de paquetes por segundo. Compáralo con tu línea: 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.

Por eso los dos frenos de emergencia más extendidos resultan insatisfactorios. El null-routing (blackholing) retira de la red la IP atacada y termina el ataque, sí, pero también termina con tu servidor: para tus jugadores el resultado es idéntico al de un ataque con éxito. Un desvío reactivo cuesta, en su tiempo de conmutación, justo los minutos en los que se decide la campaña. Lo único eficaz es un filtrado que funcione de forma permanente en la red, delante del servidor.

Qué pone KernelHost frente a eso

La protección permanente que está 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, mucho 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 en las capas 3 a 7, paquete a paquete.

Dos propiedades son decisivas. Primero, el filtrado funciona de forma permanente, así que no hay ningún tiempo de conmutación durante el cual tus jugadores se caigan. Segundo, no se recurre al null-routing: la dirección IP atacada se queda en la red y solo se descartan los paquetes dañinos. La protección está incluida en cada paquete de servidor sin recargo, sin un paquete de protección aparte y sin instalación, y está activa desde el aprovisionamiento. Los servidores están en el maincubes Premium Datacenter de Frankfurt am Main. Qué juegos y protocolos están cubiertos lo enumera el artículo 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, con patrones cambiantes y siempre justo la noche de campaña acordada. 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:

• Una IP de protección dedicada. Tu servidor se pasa a esa dirección dentro de nuestra red, sin que tengas que reconfigurar nada por tu parte.
• Reglas de protección autogestionables por puerto y protocolo. En el área de cliente defines qué puerto se filtra con qué perfil, es decir, 27015/UDP de forma distinta al servidor web que sirve tus campañas.
• Los cambios surten efecto en tiempo real, sin ticket y sin esperas. Así puedes reajustar durante un ataque en curso.
• Un perfil de protección acorde a cada juego. Tanto para Left 4 Dead 2 y los demás títulos Source como para más de 40 juegos y protocolos adicionales, además de perfiles TCP y UDP libres para servidores modificados.

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.

Los dos niveles en comparación

Para la mayoría de los proyectos de Left 4 Dead 2 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 ha desaparecido de la búsqueda por lobby, pero sigue funcionando: normalmente se ha bloqueado 27015/UDP en bloque o se le ha puesto un límite de tasa demasiado estrecho y, como el tráfico de juego y la consulta comparten puerto, una regla tosca afecta a los dos. Trabaja en su lugar con una comparación sobre los paquetes sin conexión. Si el puerto es accesible y el servidor sigue invisible, revisa sv_search_key, sv_steamgroup_exclusive, sv_lan 0 y sv_region 255, y si el arranque se hizo por descuido con -nomaster.

En la consola del servidor aparece sin parar "Invalid split packet length": eso no es un ataque volumétrico, sino un paquete de red mal compuesto que se envía en rápida sucesión. El tráfico se mantiene minúsculo y aun así el servidor va a tirones. Comprueba primero si el ancho de banda llama siquiera la atención y pon al día el binario del servidor y las extensiones. Aquí el ancho de banda no sirve de nada.

Todos los jugadores tienen ping alto, pero la línea no está llena: eso apunta a tasa de paquetes en lugar de a volumen. Mira los paquetes descartados en ip -s link show y los contadores UDP en nstat -az. Si en el log del sistema aparece nf_conntrack: table full, saca el puerto de juego con notrack.

La regla del firewall es correcta y aun así no surte efecto: comprueba con iptables -L INPUT -n -v si suben los contadores de aciertos. Si se quedan a cero, la regla no se alcanza, porque está detrás de las cadenas de UFW o se perdió con el último reinicio. Si suben y aun así no cambia nada, la línea que hay delante del servidor está saturada, y a partir de ahí solo sirve el filtrado en la red.

El servidor ya no acepta jugadores aunque haya plazas libres: normalmente hay una reserva de lobby colgada. O gestionas el servidor de forma consecuente a través del matchmaking, o pones sv_force_unreserved 1 y dejas que tus jugadores entren por el navegador de servidores. Con más de cuatro plazas cooperativas y L4DToolZ ese ajuste es obligatorio de todas formas.

Los jugadores nuevos cargan eternamente y la línea está llena mientras tanto: entonces srcds está sirviendo él mismo los archivos de campaña por el puerto de juego. Pon sv_downloadurl apuntando a un servidor web y deja ahí los archivos como archivo bzip2, o remite a tus jugadores al Steam Workshop.

El ataque se detiene tras un cambio de IP y vuelve al cabo de uno o dos días: es lo normal, porque tu servidor publica él mismo la nueva dirección en cuanto vuelve a estar registrado, y un registro DNS olvidado o un bot de Discord con indicador de estado hace el resto. Un cambio de IP da horas, no una solución.

En el servidor se ejecutan comandos de administración ajenos: no es un ataque DDoS, sino un acceso RCON comprometido. Cambia la contraseña de inmediato y restringe la parte TCP de 27015 a tu propia dirección.

En resumen

• Un servidor de Left 4 Dead 2 necesita exactamente un puerto abierto hacia fuera: 27015/UDP. El tráfico de juego y la consulta A2S lo comparten, no existe un puerto de query separado.
• 27015/TCP es RCON y pertenece exclusivamente a tu propia dirección. Quien no necesite RCON deja rcon_password vacía.
• El sistema de lobbies es el filtro de acceso gratuito más eficaz que conoce el juego: sv_allow_lobby_connect_only 1, un sv_search_key propio y sv_steamgroup_exclusive 2 dejan fuera todo lo que no venga del matchmaking. Filtra entradas, no paquetes.
• Las campañas personalizadas pertenecen al Steam Workshop o a un sv_downloadurl, nunca al puerto de juego. Si no, cada intento de conexión interrumpido lo pagas con tu ancho de banda.
• El límite de tasa tiene que distinguir entre los paquetes sin conexión (los que empiezan con 0xffffffff) y el tráfico de juego. Una regla tosca sobre 27015/UDP echa fuera a tus propios jugadores.
• 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 decide únicamente la red que hay delante del servidor, ningún ajuste en el servidor mismo.
• En KernelHost filtran de forma permanente y sin recargo 17 Tbps de scrubbing global y un filtrado Arbor en tiempo real con 3,2 Tbps en Frankfurt am Main, sin null-routing y sin tiempo de conmutación.

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 nuestro equipo reajuste las reglas de filtrado de tu dirección IP. Durante un ataque en curso también puedes contactarnos por el chat de emergencia de WhatsApp en el +43 650 8209883. 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 la búsqueda por lobby, ping alto). Eso ahorra una ronda de preguntas, y esa ronda cuenta cuando hay una campaña en marcha.

Si alojas en otro sitio y recibes ataques con regularidad, mudarte a KernelHost es el camino más corto que cualquier regla adicional en un servidor cuya línea termina antes. La protección permanente forma parte de cada paquete de servidor, no es un extra que se contrata cuando llega el apuro.