Proteger un servidor de Call of Duty frente a ataques DDoS

Proteger un servidor de Call of Duty frente a ataques DDoS es, en los títulos clásicos, una tarea agradablemente concreta: se trata de exactamente un puerto UDP, de un puñado de dvars en la server.cfg y de un vector de amplificación que el motor arrastra desde 2003. Un servidor que por las noches pierde de golpe a todos los jugadores en plena ronda, en cambio, rara vez tiene un problema de hardware. Lo habitual es que haya un ataque en marcha, y que ocurra justo cuando el servidor está lleno.

Este artículo empieza por los títulos a los que se aplica siquiera, sigue por lo que puedes asegurar tú mismo sin coste añadido, después por el punto en el que esas medidas se acaban técnicamente y termina con lo que tiene que ocurrir entonces en la red que hay delante del servidor. Los comandos están escritos para Debian 12, Debian 13, Ubuntu 22.04 LTS y Ubuntu 24.04 LTS y dan por supuesto root; si trabajas como usuario normal, antepón sudo.

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

En qué títulos de Call of Duty puedes proteger un servidor frente a DDoS

Proteger un servidor de Call of Duty frente a DDoS solo es posible en los títulos que permiten servidores dedicados propios. Esos son las versiones originales de Call of Duty (2003), Call of Duty United Offensive, Call of Duty 2, Call of Duty 4 Modern Warfare y Call of Duty World at War, además de las plataformas comunitarias Plutonium (World at War, Black Ops, Black Ops II, Modern Warfare 3), IW4x (Modern Warfare 2) y CoD4X (Call of Duty 4). Todos esos títulos comparten el mismo patrón: una server.cfg, un puerto UDP abierto y una entrada en una lista de servidores pública.

Para las entregas modernas este artículo no vale, y conviene decirlo con claridad. Warzone, Modern Warfare (2019), Black Ops Cold War, Vanguard, Modern Warfare II, Modern Warfare III y Black Ops 6 no conocen servidores dedicados que se puedan alquilar: las partidas corren sobre la infraestructura de matchmaking de Activision, no hay server.cfg, ni navegador de servidores, ni ningún puerto que pudieras abrir o asegurar. Las listas de puertos que Activision publica para esos títulos (entre otros TCP 3074 y 27014 a 27050, así como UDP 3074, 3478 y 27000 a 27031) describen puertos de cliente y de plataforma, no puertos de servidor. Quien tenga cortes de conexión en Warzone tiene un problema en su propia línea o uno en Activision, pero ninguno que un servidor alquilado fuera a resolver.

Por qué atacan precisamente a los servidores de Call of Duty

Los servidores de Call of Duty reúnen cuatro características que los convierten en un objetivo cómodo. Primera, todo servidor listado publica su dirección por sí solo: la entrada en la lista de servidores contiene la dirección IP y el puerto en texto claro, porque de lo contrario nadie podría entrar. Segunda, todo el tráfico va por UDP, y UDP no tiene un establecimiento de conexión que se pueda exigir, así que las direcciones de origen se pueden falsificar. Tercera, el motor responde a las consultas de estado de cualquiera, sin que nadie tenga que arrancar el juego. Cuarta, el control remoto RCON está en el mismo puerto que el juego.

A eso se suma la parte social: jugadores baneados, competencia entre clanes, riñas en una comunidad que se conoce desde hace años. Un ataque no le cuesta a quien lo encarga ni conocimientos ni un dinero digno de mención, los llamados booter y stresser se venden como suscripción por unos pocos euros al mes, y los ataques de amplificación a través de servidores de juego forman parte allí de la oferta estándar. Qué es en detalle un ataque DDoS lo explica el artículo ¿Qué es un ataque DDoS?.

Los puertos que de verdad importan

Un servidor clásico de Call of Duty ocupa exactamente un puerto UDP, y es el 28960. En ese único puerto corren tres cosas a la vez: el tráfico de juego, las consultas de estado de la lista de servidores y el control remoto RCON. No existe un puerto de consulta propio ni un puerto RCON propio. La línea de arranque de un servidor dedicado es igual en todos los títulos, solo cambia el nombre del archivo ejecutable:

+set dedicated 2 +set net_ip 0.0.0.0 +set net_port 28960 +set sv_maxclients 32 +exec server.cfg +map_rotate

Los puertos de los servidores maestros no pintan nada en tus reglas de apertura. El 20810 y el 20800 son puertos de destino en el otro extremo, no puertos de escucha en tu máquina: tu servidor contacta con la lista por iniciativa propia. Muchas guías de apertura de puertos recomiendan aun así abrirlos de entrada. Eso agranda la superficie de ataque sin ninguna contrapartida.

Órdenes de magnitud habituales en Call of Duty

La segunda tabla es la más importante si quieres calcular si todavía puedes con ello tú mismo. Enfrenta la carga normal de un servidor lleno a las cifras de las que se trata en un ataque.

Por qué juego, consulta y RCON están en el mismo puerto

Esta es la particularidad decisiva de Call of Duty. El motor id Tech 3, sobre el que se construyen todos los títulos clásicos de Call of Duty, no conoce puertos separados para juego, consulta y control remoto. Todo corre mediante los llamados paquetes sin conexión en el único puerto UDP. Un paquete sin conexión es un paquete UDP que empieza con cuatro bytes 0xFF y después lleva el nombre del comando en texto claro: getstatus, getinfo, getchallenge, connect o rcon.

La consecuencia práctica es incómoda: no puedes separar RCON del juego con el firewall sin bloquear también el juego. Una regla sobre el puerto 28960 afecta siempre a todo. Quien quiera descartar de forma selectiva los floods de consultas y los ataques a RCON tiene que mirar dentro del contenido del paquete y no solo el número de puerto. Justo por eso las reglas de firewall basadas en puertos llegan antes a su límite en Call of Duty que en los juegos con un puerto de consulta separado.

¿Qué es la reflexión getstatus en Call of Duty?

La reflexión getstatus es un ataque de amplificación en el que un atacante envía pequeñas consultas de estado con dirección de origen falsificada a muchos servidores de juego, para que sus respuestas, mucho mayores, acaben en la víctima real. Los servidores de juego no son ahí el objetivo, sino el amplificador. Este vector está documentado para el motor id Tech 3 desde hace más de una década y afecta a Call of Duty igual que a Quake 3 y a sus demás derivados.

Te golpea por partida doble, desde dos direcciones. Como atacado recibes una avalancha de peticiones getstatus que consumen tiempo de proceso y ancho de banda saliente, y tus jugadores lo notan como picos de lag. Como amplificador involuntario envías respuestas a una víctima ajena, y la queja por abuso acaba en tu buzón. Las dos cosas ocurren en el mismo puerto, con los mismos paquetes, y las dos parecen al principio inofensivas en la gráfica de uso.

Cómo es un paquete getstatus

La petición consta de cuatro bytes 0xFF y de la palabra getstatus, en total 13 bytes de carga útil. Con la cabecera IP y la UDP son 41 bytes en la línea. Justo a eso apunta la comprobación de longitud de las reglas de firewall que circulan desde hace años por los foros de Call of Duty:

iptables -A INPUT -p udp -m length --length 41:45 -m recent --set --name getstatus_cod
iptables -A INPUT -p udp -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

La respuesta es incomparablemente mayor. Un statusResponse contiene la configuración completa del servidor como cadena de texto más una línea por cada jugador conectado, así que con el servidor lleno son varios kilobytes. CISA recoge el protocolo de red de Quake en su resumen de los ataques de amplificación por UDP (TA14-017A) con un factor de amplificación de 63,9 y señala como comando abusado, de forma expresa, el intercambio de información del servidor. De 1 Mbit/s de peticiones falsificadas salen así unos 64 Mbit/s en la víctima. A modo de comparación: DNS está en ese mismo resumen entre 28 y 54, y NTP en 556,9.

El freno integrado: sv_queryIgnoreTime y sv_queryIgnoreMegs

Call of Duty 4 tiene desde la versión de servidor 1.7 un freno de consultas integrado. Recuerda cada dirección que ha enviado una consulta de estado e ignora las consultas siguientes de esa misma dirección durante un tiempo ajustable. Lo controlan cuatro dvars, con estos valores por defecto:

sv_queryIgnoreMegs        1
sv_queryIgnoreTime        2000
sv_queryBounceIgnoreTime  12000
sv_queryIgnoreDebug       0

sv_queryIgnoreMegs determina cuánta memoria de trabajo puede ocupar la lista de ignorados. 1 megabyte da para unas 65.000 direcciones, y cada megabyte adicional para unas 87.000 más. El valor 0 desconecta el freno por completo, y eso es justo lo que ocurre en muchos servidores, porque la configuración viene de una plantilla antigua. sv_queryIgnoreTime es el tiempo de bloqueo en milisegundos. sv_queryBounceIgnoreTime actúa cuando vuelve una respuesta con "ICMP Port Unreachable", es decir, exactamente cuando tu servidor está siendo utilizado como amplificador contra una víctima ajena. sv_queryIgnoreDebug 1 escribe los aciertos en el log, para que puedas ver siquiera si está pasando algo.

Quien use CoD4X tiene además límites fijos en el código del servidor: como mucho 20 respuestas getstatus cada 20 segundos, como mucho 100 respuestas getinfo cada 100 segundos y como mucho un mensaje de error de RCON cada 100 milisegundos. El comentario del código fuente deja clara la intención: al servidor no le importa dejarse inundar, pero no debe malgastar ancho de banda saliente en ello. Esa es la prioridad correcta, pero no sustituye al filtrado delante del servidor.

Por qué RCON es históricamente un problema en Call of Duty

RCON es el control remoto del servidor, y en Call of Duty es un paquete UDP sin cifrar en el puerto de juego. Un comando RCON se ve así en la línea: cuatro bytes 0xFF, después la palabra rcon, después la contraseña en texto claro, después el comando propiamente dicho. No hay cifrado, ni sesión, ni cuenta de usuario, ni segundo factor. De ahí se siguen tres problemas, y los tres son reales:

• Lectura del tráfico. Quien vea el tráfico en cualquier punto del camino lee tu contraseña de RCON en texto claro. Eso vale para cualquier red entre tú y el servidor y para cualquier herramienta a la que le des la contraseña.
• Adivinación. No hay un inicio de sesión que se pueda bloquear, ni un bloqueo de cuenta tras diez intentos fallidos. Un atacante prueba contraseñas a la velocidad que quiera. El servidor original no frena eso en absoluto, y CoD4X solo frena la respuesta a un mensaje de error cada 100 milisegundos y registra el intento como "Bad rcon".
• Reflexión. También un mensaje de error de RCON es una respuesta a un paquete falsificado. Quien dispara a tu servidor con paquetes RCON falsificados lo usa como pequeño amplificador, y tu servidor se llena el log de paso.

La consecuencia práctica: pon rcon_password solo si de verdad necesitas RCON. Y si es así, que sea larga y aleatoria. CoD4X exige un mínimo de ocho caracteres, que es un umbral inferior y no una recomendación. Administra en el día a día por SSH y por la consola del servidor en lugar de por RCON desde la red abierta. Y si tienes una herramienta de administración como IW4MAdmin, que a su vez habla por RCON, su interfaz web en el puerto 1624 no pinta nada en la red abierta.

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

1. Inventario: ¿qué está escuchando?

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:28960 y [::]:28960 significan "accesible desde todo internet", 127.0.0.1:3306 significa "solo local" y no necesita ninguna regla de firewall. Junto al juego aparecen ahí a menudo IW4MAdmin, un servidor web para el Fast Download, una base de datos para las estadísticas y una segunda instancia de juego olvidada. La vista del atacante te la da un escaneo de puertos desde fuera:

nmap -Pn -sU -p 28960-28970,4976,27016 IHRE.SERVER.IP.ADRESSE
nmap -Pn -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

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

Para un único servidor de Call of Duty basta con una sola apertura 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 28960/udp comment 'Call of Duty'
ufw allow from 203.0.113.10 to any port 1624 proto tcp comment 'IW4MAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Sustituye 203.0.113.10 por tu propia dirección. En Plutonium T6, 4976/udp ocupa el lugar de 28960/udp, y en Plutonium IW5 es 27016/udp. Si explotas varias instancias, abre exclusivamente el rango que utilizas de verdad, por ejemplo 28960:28962/udp y no del 28960 al 28970 en bloque. Un puerto en el que no escucha nada no es una puerta de entrada, pero en caso de ataque le cuesta trabajo al kernel de todas formas. La guía completa, con vía de rescate incluida, la tienes en Configurar el firewall UFW sin quedarte fuera del servidor.

3. Activar el freno de consultas en la server.cfg

Estas cuatro líneas deben estar en la server.cfg de cualquier servidor de Call of Duty 4 y no cuestan nada más que unos megabytes de memoria de trabajo:

set sv_queryIgnoreMegs "4"
set sv_queryIgnoreTime "2000"
set sv_queryBounceIgnoreTime "12000"
set sv_queryIgnoreDebug "0"

4 megabytes dan para unas 326.000 direcciones, y eso llega también para un flood serio. Sube sv_queryIgnoreTime por encima de los 2000 milisegundos por defecto solo con prudencia: la lista de servidores y cualquier navegador de servidores consultan a tu servidor por ese mismo mecanismo, y quien pone el tiempo de bloqueo demasiado alto desaparece de la lista. Pon sv_queryIgnoreDebug temporalmente en 1 si quieres saber si el freno actúa siquiera, y después vuelve a dejarlo en 0 para que el log no te llene el disco.

4. Descartar los floods de consultas en el firewall

El freno del motor actúa solo después de que el paquete haya llegado al proceso del juego. Una regla de firewall decide antes y cuesta menos. Estas dos líneas limitan getstatus por dirección de origen:

iptables -A INPUT -p udp --dport 28960 -m length --length 41:45 -m recent --set --name cod_query --rsource
iptables -A INPUT -p udp --dport 28960 -m string --algo bm --string "getstatus" -m recent --update --seconds 2 --hitcount 4 --name cod_query --rsource -j DROP

La primera línea recuerda cada dirección de origen que envía un paquete con la longitud típica de una consulta de estado. La segunda descarta cualquier otra petición getstatus en cuanto esa misma dirección ha enviado más de cuatro en dos segundos. Cuatro peticiones cada dos segundos le bastan a cualquier navegador de servidores. Por los foros circulan también variantes con 20 peticiones por segundo, bastante más generosas, que actúan más contra los bots toscos que contra una oleada de reflexión bien hecha.

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. Comprueba después con iptables -L INPUT -n -v si suben los contadores de aciertos. Si se quedan a cero, la regla no se alcanza.

5. Desconectar RCON o llevarlo muy corto

El acceso RCON más seguro es el que no existe. Una rcon_password vacía rechaza cualquier paquete RCON:

set rcon_password ""

Ten en cuenta un detalle: el servidor sigue respondiendo incluso entonces, en concreto con un mensaje de error, y sigue siendo por tanto un pequeño amplificador. Quien quiera descartar eso y solo necesite RCON desde una dirección fija, descarta los paquetes antes:

iptables -A INPUT -p udp --dport 28960 ! -s 203.0.113.10 -m string --algo bm --string "rcon " -j DROP

Esta regla tiene un efecto secundario que conviene conocer: la cadena rcon puede aparecer en teoría también en un paquete de chat de un jugador conectado, y ese paquete se descartaría igualmente. En la práctica es asumible. Quien no quiera ese efecto secundario deja la regla fuera y trabaja solo con una contraseña vacía o muy larga.

6. Defenderse del flood de entradas y del agotamiento de slots

Un flood de entradas no apunta a la línea, sino a la lógica del juego: el atacante envía en rápida sucesión paquetes getchallenge y connect hasta que todos los slots quedan ocupados con conexiones a medio hacer. Los jugadores reales reciben entonces "Server is full" aunque en el juego no haya nadie. Contra eso actúan estos ajustes:

set sv_maxclients "32"
set sv_reconnectLimit "3"
set sv_floodProtect "1"
set sv_connectTimeout "30"
set sv_timeout "120"

sv_reconnectLimit limita cuántas veces seguidas puede reconectarse el mismo jugador. sv_floodProtect limita cuántos comandos de cliente procesa el servidor por jugador y evita así que un solo cliente frene al servidor a base de comandos. sv_connectTimeout y sv_timeout determinan cuánto tiempo bloquea un slot una conexión a medio hacer o una conexión muda: quien deje aquí valores generosos heredados de una plantilla antigua le pone fácil al atacante el agotamiento de slots.

En CoD4X se añade sv_authorizemode. El valor 1 deja entrar solo a los jugadores con copia válida, el 0 solo a los jugadores sin ella, y el -1 a ambos. Quien ponga 1 deja fuera a buena parte de los clientes desechables, pero pierde también jugadores reales sin copia original. El recurso más duro es una contraseña de servidor mediante g_password, que actúa contra todo lo que usa la vía normal de entrada. Y una cosa tiene que quedar clara: una contraseña 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. La entrada en la lista de servidores y tu propia dirección

Aquí conviene la honestidad antes que el pensamiento mágico: tu dirección IP no se puede mantener en secreto. Cualquier jugador que se haya conectado una vez la conoce, y la entrada de la lista la publica de todas formas, junto con el puerto. Puedes desactivar la entrada no poniendo ningún servidor maestro en la server.cfg (las dvars se llaman sv_master1, sv_master2 y así sucesivamente). Eso cuesta, eso sí, toda la visibilidad para los jugadores nuevos, y solo sirve contra el más cómodo de los atacantes.

Un apunte sobre el estado de las listas: los servidores maestros originales de Activision (codmaster.activision.com en el 20510, cod2master.activision.com en el 20710, cod4master.activision.com en el 20810) ya no responden nada para los títulos antiguos. Quien quiera estar listado hoy usa las listas comunitarias: CoD4X mantiene una propia y pide para ello un token en sv_authtoken, y Plutonium trae su propia lista de servidores. En el fondo del asunto eso no cambia nada, porque la dirección aparece allí igualmente en texto claro.

Aun así hay dos costumbres que funcionan. 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 clan. Y conecta a tus jugadores mediante un nombre de host, para poder cambiar la dirección llegado el caso sin que se rompan todas las referencias. El clásico aquí es un registro A olvidado que apunte a la dirección antigua: deja sin efecto cualquier cambio.

8. Sacar de la red abierta las interfaces web, la base de datos y el Fast Download

Junto al juego, en la mayoría de los servidores de Call of Duty corre algo más: IW4MAdmin con su interfaz web en el puerto 1624, un servidor web para el Fast Download de los mapas y a veces una base de datos para las estadísticas. Cada uno de esos servicios es una superficie de ataque propia, y ninguno de ellos pinta nada sin límites en la red abierta.

Limita el 1624 a tu propia dirección o llega a la interfaz por un reenvío SSH; después abres en local http://127.0.0.1:1624:

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

La base de datos la enlazas a 127.0.0.1, porque en la red abierta no tiene nada que hacer bajo ningún concepto. Y pon el Fast Download en un servidor web propio en lugar de dentro del proceso del juego: un servidor web bajo carga le quita al juego justo el tiempo de proceso que necesita para la simulación.

9. Registrar datos para tener cifras cuando haga falta

El paso más importante es el que casi nadie da antes de tiempo: crear una base de comparación mientras todo funciona con normalidad. Sin un valor normal no puedes decir, después de un incidente, si 40.000 paquetes por segundo eran muchos o simplemente un 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 port 28960 -c 200 -q

Para Call of Duty hay un quinto que responde a la pregunta decisiva. Esta captura muestra exclusivamente los paquetes sin conexión, es decir, justamente getstatus, getinfo, getchallenge, connect y rcon:

tcpdump -ni eth0 'udp port 28960 and udp[8:4] = 0xffffffff' -c 200 -A

Si ahí aparece cien veces getstatus desde direcciones siempre nuevas, tienes un flood de consultas. Si aparece rcon, alguien está intentando adivinar tu contraseña. Si solo aparecen getchallenge y connect, es un flood de entradas. Con tcpdump vale siempre lo mismo: limítalo con -c, porque una captura a plena carga añade trabajo a un servidor que ya está saturado. Cómo interpretar los valores lo explica Detectar un ataque DDoS.

El punto en el que estas medidas dejan de servir

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

Echa cuentas una vez. Un servidor lleno de 32 slots genera de salida unos 6,4 Mbit/s, que es menos del uno por ciento de una línea gigabit. Esa misma línea se llena en cuanto alguien manda 125 megabytes por segundo, y justo para eso están pensados los ataques que se pueden encargar por diez euros al mes. Que tu regla de iptables por detrás sea buena o no ya da igual, porque los paquetes de tus jugadores dejan de pasar mucho antes.

La segunda magnitud es la tasa de paquetes, y en Call of Duty golpea con regularidad 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. Una petición getstatus, con sus 41 bytes, es todavía más pequeña que eso: un ataque que no llena ni un tercio de tu línea deja tu servidor fuera de combate igualmente, porque todo 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".

En Call of Duty se añade una particularidad que agrava la cuenta. Como juego, consulta y RCON están en el mismo puerto, no puedes cerrar el 28960 en caso de emergencia: sería lo mismo que apagar el servidor. Y como el motor responde a cada consulta de estado con un múltiplo del tamaño de la petición, un atacante gasta menos ancho de banda propio para el mismo efecto que en otros juegos.

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

Lo que KernelHost pone frente a esos ataques

La protección permanente incluida en todos los servidores

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

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

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

Advanced DDoS Protection para proyectos bajo fuego continuo

Algunos clanes y comunidades 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 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 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 qué se permite en 28960 UDP sin tener que abrir un ticket para ello, y con varias instancias lo haces por puerto y por separado.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso.
• Perfil de protección adaptado a cada juego, también para aplicaciones modificadas y propias en cualquier puerto TCP o UDP. Ese es el punto relevante para Plutonium y CoD4X, porque sus puertos pueden apartarse de los valores por defecto.

La Advanced DDoS Protection se dirige a los servidores que están alojados en KernelHost. Si tu servidor de Call of Duty corre ahora mismo en otro sitio y allí lo sacan de la red con regularidad, el traslado a KernelHost es el camino que cambia algo.

Los dos niveles, comparados

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

Errores frecuentes y sus soluciones

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

"Mi proveedor me manda un aviso de abuso aunque la víctima soy yo": entonces tu servidor no es el objetivo, sino el amplificador. Alguien envía peticiones getstatus falsificadas y tu servidor responde obedientemente a una víctima ajena. Comprueba primero si sv_queryIgnoreMegs está a 0, y pon las cuatro dvars de consulta y la regla de firewall del apartado 4.

"El servidor aparece en la lista como lleno, pero está vacío": eso es un flood de entradas, y golpea a la lógica del juego, no a la línea. Contra eso actúan sv_reconnectLimit, valores más cortos para sv_connectTimeout y sv_timeout y, en caso de duda, una contraseña de servidor.

"El servidor desaparece de la lista de servidores durante el ataque": eso es la consecuencia, no la causa. La lista de servidores comprueba mediante esas mismas consultas de estado si tu servidor sigue vivo. Si las respuestas no pasan o si las ha descartado tu propio freno, el servidor cuenta como offline. Comprueba si sv_queryIgnoreTime está demasiado alto antes de sospechar del firewall.

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

"El servidor funciona, pero todos los jugadores tienen picos de lag": mira primero la tasa de paquetes de la interfaz, no la carga de la CPU. Si sar -n DEV 1 10 no muestra nada llamativo y aun así va a tirones, suele deberse a un mod, a una sv_maxRate exagerada o simplemente a demasiados bots en la ronda.

"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 clásico de Call of Duty necesita exactamente un puerto abierto: el 28960 UDP. En Plutonium T6 es el 4976 UDP y en Plutonium IW5 el 27016 UDP.
• En Call of Duty, el juego, la consulta de estado y RCON están en el mismo puerto. No puedes separar RCON del juego con una regla de puerto, para eso necesitas una regla que mire dentro del contenido del paquete.
• La reflexión getstatus es el vector de amplificación propio del juego: 41 bytes de petición y, según la alerta TA14-017A de CISA, un factor de 63,9 en el protocolo de red de Quake, es decir, unos 2.600 bytes de respuesta.
• Activa el freno de consultas: sv_queryIgnoreMegs 4, sv_queryIgnoreTime 2000, sv_queryBounceIgnoreTime 12000. En muchos servidores está a 0 y, por tanto, apagado.
• Pon rcon_password solo si de verdad necesitas RCON: la contraseña va sin cifrar por UDP y se puede adivinar cuantas veces se quiera, porque no hay bloqueo de cuenta.
• Los puertos de los servidores maestros 20810 y 20800 son puertos de destino salientes y no pintan nada en tus aperturas de entrada.
• A partir de aproximadamente 1 Gbit/s o de unos cientos de miles de paquetes por segundo decide exclusivamente la red que hay delante del servidor, y ya no tu configuración.

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 ajustemos con más precisión las reglas de filtrado de tu dirección IP. Durante un ataque en curso puedes localizarnos además en el chat de emergencia de WhatsApp en el +43 650 8209883.