Proteger tu servidor de MTA:SA frente a ataques DDoS

Un servidor de Multi Theft Auto: San Andreas se comporta bajo un ataque DDoS de forma distinta a cualquier otro proyecto multijugador de GTA, porque ofrece tres servicios de red separados a la vez: el tráfico del juego en 22003 UDP, un servidor HTTP completo en 22005 TCP y la consulta ASE en 22126 UDP. Cada uno de esos tres servicios se puede atacar por separado, y cada uno falla de una manera distinta. Este artículo muestra primero lo que puedes asegurar tú mismo sin coste añadido, después dónde se acaban esas medidas ante la física de la línea y, al final, qué tiene que ofrecer en la red que hay delante del servidor una protección DDoS eficaz para MTA:SA.

Si el ataque está en marcha ahora mismo, la pregunta más importante es cuál de los tres servicios recibe el golpe. Si los jugadores siguen conectados, pero al entrar ya no cargan recursos, le toca al servidor HTTP en 22005. Si el servidor desaparece del navegador mientras los jugadores conectados siguen jugando con normalidad, le toca a la consulta ASE en 22126. Si todas las conexiones se cortan a la vez, o bien el objetivo es 22003 o bien la línea está llena. Todos los datos se refieren a un servidor de MTA 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.

Por qué los servidores de MTA:SA son tan a menudo objetivo de ataques DDoS

Los proyectos de MTA:SA son objetivos cómodos porque tienen que publicar su dirección ellos mismos. Un servidor solo aparece en el navegador del juego si se da de alta en la lista maestra de servidores y después responde a las consultas que llegan de fuera. La lista contiene la dirección IP y el puerto en texto claro, así que para un atacante cualquier trabajo previo de reconocimiento sobra.

A eso se suma la escena en sí. Los servidores de rol de habla alemana y los brasileños, los servidores de drift y las adaptaciones de DayZ compiten por la misma comunidad de jugadores, y una caída en la hora de mayor afluencia es lo más visible que hay. Un jugador baneado, un equipo enfrentado o un proyecto de la competencia no necesitan ni conocimientos ni un dinero digno de mención para dejar una tarde inservible. Los servicios de ataque contratables, llamados en la escena booter o stresser, venden por unos pocos euros al mes exactamente dos resultados: dejar el servidor de MTA fuera de línea durante minutos o volverlo injugable con picos de lag. Qué es técnicamente un ataque DDoS y qué tipos de ataque existen lo explica el artículo ¿Qué es un ataque DDoS?.

Técnicamente, MTA:SA se lo pone más fácil a los atacantes que otras modificaciones multijugador en dos puntos. Primero, la consulta está en un puerto UDP propio que, ante un único byte, envía una respuesta de varios kilobytes. Segundo, a cada servidor de MTA le pertenece un servidor HTTP que entrega los archivos del lado del cliente de todos los recursos, y lo hace sin autenticación a cualquiera que lo pida.

Los puertos que de verdad importan

Un servidor de MTA:SA necesita exactamente tres puertos: 22003 UDP para el juego, 22005 TCP para el servidor HTTP interno y 22126 UDP para la consulta ASE. El tercer puerto no es un ajuste de libre elección, sino que resulta de forma fija del puerto de juego más 123. Quien pone serverport en 22010 recibe la consulta en 22133.

Dos detalles vienen así en la mtaserver.conf que se entrega y se pasan por alto con regularidad. httpport puede tener el mismo valor numérico que serverport, porque uno de los puertos es TCP y el otro UDP. Y serverip está en auto y ahí debe quedarse: un valor fijo enlaza el socket de ASE exactamente a esa dirección y rompe la entrada en la lista en cuanto la dirección cambia.

El protocolo de consulta ASE y por qué es un amplificador

ASE (All-Seeing Eye) es un protocolo de consulta puramente UDP: el primer byte del paquete determina la respuesta, y no existe ningún establecimiento de conexión. El servidor de MTA conoce cinco consultas y las responde en 22126:

• s es la consulta ASE completa. La respuesta empieza por EYE1 y contiene el nombre del servidor, el tipo de juego, el nombre del mapa, la versión, el estado de la contraseña, el número de jugadores, la lista completa de todas las reglas puestas con setRuleValue y, después, cada jugador conectado con nombre, puntuación y ping. Esa respuesta no tiene límite de tamaño.
• b y r son las consultas más ligeras para el navegador del juego. La respuesta empieza por EYE2 y en el código fuente se corta en 1.340 bytes, para evitar la fragmentación.
• x entrega un mensaje de estado abreviado, v solo el identificador de versión de ASE.

De ahí surge el problema. Una petición consta de un único byte de carga útil, es decir, de 29 bytes en el cable (20 bytes de cabecera IP, 8 bytes de cabecera UDP, 1 byte de carga útil). Una respuesta de 1.400 bytes de carga útil son 1.428 bytes en el cable. La proporción es de unas 49 veces, y como UDP no tiene establecimiento de conexión, la dirección de origen se puede falsificar. Un atacante puede por tanto usar tu servidor como amplificador contra un tercer objetivo, sin entrar nunca en tu juego. En la consulta completa, el factor crece con el número de jugadores y con cada regla que ponga tu gamemode.

MTA trae contra eso dos frenos integrados que conviene conocer, porque explican por qué algunas avalanchas funcionan y otras no. El servidor responde como mucho a cinco consultas por dirección de origen en seis segundos y después ignora esa dirección durante siete segundos. Además mantiene las respuestas diez segundos en la memoria intermedia, en lugar de volver a componerlas en cada petición. Pero el recuento por dirección de origen se salta por completo en cuanto hay más de 100 direcciones de origen distintas a la vez en la lista. Eso es exactamente lo normal en una avalancha distribuida desde una botnet o con remitentes falsificados, y por eso el freno integrado no sirve contra un ataque serio.

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

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

Mira primero qué ofrece tu servidor hacia fuera. No lo adivines, compruébalo:

ss -lntup

Lo esperable son tres líneas del proceso de MTA: 0.0.0.0:22003 en UDP, 0.0.0.0:22005 en TCP y 0.0.0.0:22126 en UDP. Si ahí aparece además una base de datos en 0.0.0.0:3306, un servidor web o un servicio de voz olvidado, eso hay que apagarlo. La vista del atacante te la da un escaneo de puertos desde fuera:

nmap -Pn -sU -p 22003,22126 IP.DE.TU.SERVIDOR
nmap -Pn -p 22005 IP.DE.TU.SERVIDOR

El servidor trae para eso también un comando de consola propio. En la consola del servidor, openports comprueba si los tres puertos son accesibles desde fuera.

2. Dejar abiertos solo los tres puertos que MTA necesita de verdad

Con UFW, una configuración de partida sólida 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 22003/udp comment 'MTA juego'
ufw allow 22005/tcp comment 'MTA HTTP'
ufw allow 22126/udp comment 'MTA ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

La guía completa, con vía de rescate incluida, está en el artículo Configurar el firewall UFW. En los servidores root KVM y en los servidores dedicados de KernelHost llegas al sistema en caso de emergencia mediante la consola VNC del área de cliente, incluso con la línea saturada.

La base de datos no pinta nada en la red abierta. Si ss -lntp | grep 3306 muestra un 0.0.0.0:3306, pon en /etc/mysql/mariadb.conf.d/50-server.cnf la línea bind-address = 127.0.0.1 y reinicia el servicio.

3. Limitar el puerto ASE sin caerte de la lista de servidores

A diferencia de SA-MP, en MTA:SA la consulta está en un puerto propio, así que la puedes limitar con independencia del juego. Esa es la mayor ventaja práctica de esta arquitectura: una regla en 22126 no echa fuera a un solo jugador.

Con nftables en una tabla propia, para que el conjunto de reglas no se cruce con UFW:

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

La primera regla limita cada dirección de origen por separado, la segunda el puerto entero. Las dos juntas son importantes: una avalancha distribuida pasa por el hueco que dejan muchas fuentes individuales si solo se limita por dirección. Los valores están elegidos estrechos, y aquí eso es defendible, porque un navegador de servidores real consulta tu servidor solo cada pocos segundos. Con iptables, el módulo hashlimit consigue lo mismo:

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

El intento de cerrar el puerto del todo es una decisión con contrapartidas y no un truco de experto: sin ASE tu servidor desaparece del navegador del juego y con ello del flujo orgánico de jugadores nuevos. Si aun así lo quieres, <ase>0</ase> no basta. En el código fuente, la apertura del puerto depende de la disyunción entre el modo internet y el modo LAN, así que con <ase>0</ase> el socket sigue abierto mientras esté puesto <donotbroadcastlan>0</donotbroadcastlan>. Quien quiera cerrar el puerto de verdad pone las dos cosas:

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

El camino más honesto para un proyecto que crece es este: dejar el puerto abierto, limitar la tasa y mantener pequeño el efecto de amplificación haciendo que tu gamemode no publique reglas innecesarias con setRuleValue. Cada regla aparece en la consulta completa y agranda la respuesta.

4. Aliviar el servidor HTTP interno

El servidor HTTP en 22005 es en MTA:SA una superficie de ataque propia, porque cada jugador que entra descarga ahí todos los archivos del lado del cliente de todos los recursos en marcha. En un proyecto de rol con modelos propios eso son enseguida varios cientos de megabytes, repartidos en cientos de archivos sueltos. El servidor integrado está hecho sencillo a propósito: sin compresión, con un número fijo de hilos de trabajo. Unas cuantas docenas de descargas simultáneas bastan para que los jugadores reales se queden minutos colgados en la pantalla de carga.

La medida más eficaz es sacar las descargas por completo del servidor de juego. MTA prepara para eso los propios archivos que hay que entregar, en mods/deathmatch/resource-cache/http-client-files. Esa carpeta la sirves con nginx o lighttpd y pones la dirección en la mtaserver.conf:

<httpdownloadurl>http://cdn.tu-dominio.tld/mta</httpdownloadurl>

Eso trae dos cosas a la vez. Las descargas van por un servidor web hecho para eso, y ya no van por la dirección de tu servidor de juego. Si el servidor web está en otra máquina o detrás de una red de distribución de contenidos, una avalancha contra las descargas ya no alcanza al juego. Importante: si la dirección externa es incorrecta o no es accesible, MTA vuelve en silencio al servidor interno.

Si el servidor interno se queda en uso, aprovecha sus propios límites. En la mtaserver.conf:

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

httpmaxconnectionsperclient limita las conexiones simultáneas por cliente a 5, dentro del rango admisible de 1 a 8. httpdosthreshold limita cuántas conexiones puede abrir una sola dirección IP en poco tiempo, valor por defecto 20. http_dos_exclude exime de eso a direcciones concretas, por ejemplo tu propia página de estado. httpthreadcount determina el número de hilos de trabajo, valor por defecto 8 en el rango de 1 a 20. Un valor más alto ayuda con muchos archivos pequeños, pero cuesta tiempo de cálculo que le falta al juego.

Piensa además en qué más se entrega por ese mismo puerto. Los recursos webadmin y resourcebrowser vienen arrancados en la configuración que se entrega y son accesibles en el navegador por 22005. Una interfaz de administración no pinta nada sin protección en la red abierta: asigna permisos limpios en la acl.xml, crea una cuenta propia con una contraseña larga y aleatoria, y para el recurso cuando no lo necesites.

5. Aprovechar los límites integrados en mtaserver.conf

MTA trae más límites de protección de los que usan la mayoría de los proyectos. Algunos están fijos en el código fuente, otros en la mtaserver.conf. Esta tabla reúne los que juegan un papel durante un ataque:

Tres ajustes merecen una decisión consciente. maxplayers está en 32 y debería corresponderse con la realidad: cada slot adicional agranda la consulta completa y aumenta el número de conexiones que un atacante puede ocupar. bandwidth_reduction está en medium, el valor maximum baja de forma perceptible la carga saliente, pero cuesta precisión de sincronización. Y <password></password> convierte tu servidor sin esfuerzo en un círculo cerrado, mientras la entrada en la lista se mantiene: el freno de emergencia más rápido ante una avalancha de entradas en curso.

6. Distinguir las avalanchas de entradas de las avalanchas de eventos

Dos patrones de ataque no apuntan a la línea, sino a la lógica del juego, y se confunden con regularidad.

Una avalancha de entradas abre conexiones reales en rápida sucesión, hasta que todos los slots están ocupados o el servidor ya no da abasto con el establecimiento. MTA lo limita por sí mismo a cuatro conexiones por dirección de origen en 30 segundos y después ignora la dirección durante 30 segundos. Lo que está haciendo el freno en cada momento lo muestra el comando de consola debugjoinflood. El límite actúa por dirección, y una botnet con mil direcciones pasa de largo. Contra eso ayudan una contraseña de servidor, una whitelist en el gamemode y una limitación de tasa en 22003.

Una avalancha de eventos, en cambio, viene de jugadores ya conectados: un cliente manipulado lanza triggerServerEvent en bucle, hasta que el servidor ya no reúne el tiempo de cálculo. MTA permite de fábrica 100 eventos por jugador y segundo y, por encima de eso, avisa con un mensaje sobre avalanchas de eventos. Si tu gamemode usa muchos eventos pequeños, comprueba el valor antes de bajarlo: ajustado demasiado estrecho, echa fuera a tus propios jugadores.

Al margen de eso, en el lado del servidor vale la misma regla que en todas partes: no te fíes nunca de los valores que manda el cliente, determina el jugador a partir del remitente del evento y limita todo lo que dispare una consulta a la base de datos. Un solo evento sin comprobar que inicia una consulta basta para dejar parado un servidor sin ningún ataque de red.

7. La lista de servidores, la dirección IP y qué más delata

Tu dirección IP no se puede mantener en secreto. Cualquier jugador que se haya conectado una vez la conoce, y la entrada en la lista maestra de servidores la publica de todas formas. Un dominio por delante no ayuda: el cliente resuelve el nombre una vez y después habla directamente con la dirección.

Comprueba en cambio qué más delata tu dirección. Las fugas típicas en los proyectos de MTA son los registros A y AAAA antiguos en el DNS, la página del proyecto en la misma máquina, un bot de Discord con indicador de estado que lee la consulta ASE en público, los certificados TLS con nombres de host antiguos y los mensajes de foro de los primeros tiempos. De ahí sale una regla que muchos proyectos aprenden demasiado tarde: si te mudas a una dirección protegida, cambia al mismo tiempo la dirección antigua. Si se mantiene, está en cualquier base de datos de escáneres, y el ataque pasa de largo de la protección.

Dos entradas de la mtaserver.conf afectan directamente a la visibilidad. <serverip>auto</serverip> se queda en auto, salvo que sepas exactamente por qué no. Y <owner_email_address> hay que rellenarlo: si falta la entrada o es incorrecta, eso puede perjudicar la visibilidad en la lista maestra de servidores.

8. Registrar los datos para tenerlos 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, separa primero los tres puertos entre sí. Bastan estos cuatro comandos:

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

La interpretación es más sencilla de lo que parece. Si suben los errores de búfer con la CPU poco cargada, te llega más tráfico del que el proceso puede procesar. Si un núcleo está al máximo mientras el tráfico parece normal, el problema está en el gamemode y no en la red. Si la captura en 22126 muestra muchos paquetes con un único byte de carga útil, es una avalancha ASE. Si el número de conexiones abiertas en 22005 se mantiene de forma permanente en cifras de cuatro dígitos, le toca al servidor HTTP. Con tcpdump vale siempre: limitarlo con -c, porque una captura a plena carga añade trabajo a un servidor que ya está saturado. Cómo interpretar los valores en detalle lo describe el artículo Detectar un ataque DDoS en el servidor.

El registro del servidor está en logs/server.log, el registro de scripts en logs/scripts.log. Las dos rutas están en la mtaserver.conf y se pueden cambiar de sitio.

El punto en el que estas medidas se acaban

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, lo que equivale a 125 megabytes por segundo y, con paquetes de 64 bytes, a unos 1,49 millones de paquetes por segundo. Los ataques contra proyectos de servidores de juego de ese tamaño se mueven normalmente entre 5 y 50 Gbit/s, es decir, entre cinco y cincuenta veces tu línea. Que tu regla de nftables por detrás sea buena ya no importa, porque los paquetes de tus jugadores dejan de pasar mucho antes.

La tasa de paquetes golpea además a menudo antes que el ancho de banda. Un kernel de servidor normal procesa, según la CPU y la tarjeta de red, unos cientos de miles de paquetes por segundo antes de empezar a descartar. Un ataque que no llena ni un tercio de tu línea puede por tanto dejar tu servidor fuera de combate, 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".

En MTA:SA se añade un tercer límite, y es el que actúa antes que ninguno. El servidor lee los puertos de red en un único flujo de trabajo. Una avalancha de consultas en 22126 ocupa ese flujo de tal modo que los paquetes de sincronización de los jugadores reales caducan en el búfer de recepción, mucho antes de que la línea esté llena. El proceso no se cae, solo se vuelve lento, y los jugadores ven efectos de goma. Lo mismo vale para el servidor HTTP: comparte el tiempo de cálculo con el juego.

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 con más de 8,7 millones de paquetes por segundo contra un servidor de juego. El primer caso es unas 473 veces el ancho de banda y unas 28 veces la tasa de paquetes que una línea de 1 Gbit/s puede admitir siquiera. 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

Cada servidor en KernelHost está detrás de un filtrado en dos niveles permanentemente activo:

• 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 de Frankfurt am Main.
• Nivel 2: filtrado Arbor en tiempo real con 3,2 Tbps directamente in situ en Frankfurt am Main. Justo delante del servidor se reconocen los patrones propios de cada protocolo y se descartan paquete a paquete.

Tres propiedades son decisivas. La protección está activa de forma permanente, así que no hay ninguna fase de detección en la que tu servidor se quede fuera de línea. No se utiliza null-routing: la dirección atacada se queda en la red y solo se descartan los paquetes dañinos, mientras las conexiones de los jugadores reales siguen funcionando. Y no cuesta nada aparte, sino que está incluida desde el aprovisionamiento en cada paquete de servidor, desde el servidor root KVM y el servidor de juego hasta el servidor dedicado. Se filtra en las capas 3, 4 y 7 en cualquier puerto TCP o UDP, es decir, en 22003 UDP, 22005 TCP y 22126 UDP a la vez. Todo esto funciona en el centro de datos maincubes en Frankfurt am Main, Alemania. Qué juegos y protocolos tienen perfil propio lo muestra el artículo Protección DDoS para servidores de juego en tiempo real.

Advanced DDoS Protection para proyectos bajo fuego continuo

Algunos proyectos no reciben golpes de vez en cuando, sino de forma dirigida durante semanas. Para ese caso 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 del núcleo de red de Frankfurt. Tu servidor se cambia a ella dentro de la red de KernelHost, y en tu lado no modificas nada.
• Reglas de protección autogestionables por puerto y protocolo en el área de cliente. Justo ahí está la clave en MTA:SA: defines reglas separadas para 22003 UDP, 22005 TCP y 22126 UDP, en lugar de medir con el mismo rasero tres servicios muy distintos.
• Los cambios surten efecto en tiempo real, sin ticket y sin espera. Puedes por tanto reajustar en mitad de un ataque en curso.
• Un perfil de protección adaptado al juego. Multi Theft Auto existe como perfil propio, igual que los servidores web, los servidores de voz y las aplicaciones TCP o UDP propias que encajen detrás de la misma dirección protegida.

Los dos niveles en comparación

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

Errores frecuentes y sus soluciones

"Bloqueé el 22126, el servidor no aparece en ninguna lista y aun así siguen llegando consultas": entonces el socket sigue abierto. <ase>0</ase> por sí solo no cierra el puerto mientras esté puesto <donotbroadcastlan>0</donotbroadcastlan>. Comprueba con ss -lnup | grep 22126 si de verdad ya no hay nada escuchando.

"Los jugadores se quedan colgados en la pantalla de carga, el juego en sí va normal": eso no es un ataque contra 22003, sino el servidor HTTP en 22005 al límite. Externaliza las descargas con httpdownloadurl y revisa httpmaxconnectionsperclient y httpthreadcount.

"El servidor ha desaparecido del navegador y los jugadores que están dentro no notan nada": entonces le toca únicamente a 22126. Para los jugadores conectados eso no tiene consecuencias, para la llegada de jugadores nuevos sí. Una limitación de tasa en ese único puerto es la respuesta correcta, no una en el puerto del juego.

"Cambiamos la dirección IP y dos horas después estábamos otra vez fuera de línea": 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 consulta de estado o un registro DNS viejo. Cambiar de dirección da tiempo, no es una solución.

"Hemos puesto un límite de 20 paquetes por segundo y dirección en 22003": eso es demasiado estrecho. Un solo jugador ya queda por encima con la sincronización activa, y varios jugadores detrás de la misma dirección NAT comparten ese mismo cupo. Con ello echas fuera a tus propios jugadores. En 22126, en cambio, los valores estrechos no son problema.

"Nos hemos quedado fuera con el firewall": un reinicio no ayuda, porque UFW restaura sus reglas al arrancar. En KernelHost abres la consola VNC del área de cliente y ejecutas ahí ufw disable. La consola VNC trabaja con independencia de la red del sistema huésped.

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

"Simplemente esperamos a que pase el ataque": los ataques que funcionan se repiten. Documenta el momento con la zona horaria, la duración, los valores máximos y el puerto afectado. Justo esos datos necesita también un ticket de soporte, para que el filtrado se ajuste de forma dirigida.

En resumen

• Un servidor de MTA:SA necesita exactamente tres puertos: 22003 UDP para el juego, 22005 TCP para el servidor HTTP interno y 22126 UDP para la consulta ASE. El tercero resulta de forma fija del puerto de juego más 123.
• La consulta ASE está en un puerto propio y por eso se puede limitar sin dejar fuera a un solo jugador. Esa es la diferencia más importante con SA-MP, donde el juego y la consulta comparten el mismo puerto.
• Un único byte de petición en 22126 genera una respuesta de hasta varios kilobytes, y la dirección de origen es falsificable. Un puerto ASE sin freno es por tanto objetivo y amplificador a la vez.
• Los frenos integrados de MTA actúan por dirección de origen: cinco consultas en seis segundos, cuatro entradas en 30 segundos. Con más de 100 direcciones de origen simultáneas se salta el recuento de consultas, así que una avalancha distribuida pasa de largo.
• El servidor HTTP interno en 22005 es una superficie de ataque propia. Quien externaliza las descargas con httpdownloadurl a un servidor web externo las saca del juego.
• Todo lo que corre en el servidor decide solo sobre los ataques pequeños. En 1 Gbit/s la cosa se acaba en unos 1,49 millones de paquetes por segundo, independientemente de la calidad de tus reglas.
• La protección permanente en dos niveles de KernelHost está incluida en cada paquete de servidor sin recargo y trabaja sin null-routing. Quien quiera dirigir él mismo las reglas por puerto añade la Advanced DDoS Protection desde 50,00 € al mes.

Si tu proyecto ya está en KernelHost, el filtrado está activo de forma permanente y no tienes que activar nada. Si aun así notas algo raro, abre un ticket de soporte con el periodo, el puerto y el comportamiento observado, para que se reajusten las reglas de tu dirección. Durante un ataque en curso puedes localizarnos además en el chat de emergencia de WhatsApp en el +43 650 8209883. Si todavía alojas en otro sitio y te golpean con regularidad, el traslado a Frankfurt am Main es la solución más corta: los siguientes pasos para el caso agudo están en el artículo Ataque DDoS grave: qué hacer ahora.