Proteger un servidor de Arma 3 frente a ataques DDoS

Quien quiera proteger un servidor de Arma 3 frente a ataques DDoS tiene que vérselas con exactamente cinco puertos UDP: del 2302 al 2306. Un servidor dedicado que por las noches, en plena operación, se cae de golpe para todos los jugadores a la vez rara vez tiene un problema de hardware. Lo habitual es que haya un ataque en marcha contra justo ese bloque de puertos, y además cuando la lista de servidores muestra la cifra de jugadores más alta. Este artículo empieza por lo que puedes asegurar tú mismo sin coste añadido, sigue por el punto en el que esas medidas se acaban técnicamente y termina con lo que tiene que ocurrir en la red que hay delante del servidor.

Todos los datos se refieren a un servidor dedicado de Arma 3 (aplicación 233780 de SteamCMD) sobre Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS. Los comandos están escritos para root; si trabajas como usuario normal, antepón sudo. Si el ataque está en marcha ahora mismo: no cambies nada en la configuración y no reinicies el servidor, guarda primero las mediciones del apartado "Registrar datos". Cuando el ataque pase habrán desaparecido.

Por qué atacan a los servidores de Arma 3 y cuándo hace falta protección DDoS

Arma 3 reúne varias características que convierten a un servidor en un objetivo cómodo. Primero, el servidor publica su dirección por sí solo: se registra en el servidor maestro de Steam por el puerto 2304 UDP y responde en el puerto 2303 UDP a las consultas con el nombre, el mapa, el número de jugadores y la lista de mods. Sin esos dos puertos no te encuentra nadie, y con ellos tu dirección IP aparece en cualquier navegador de servidores y en cualquier página de estado que consulte ese navegador.

Segundo, la comunidad juega a horas fijas. Los proyectos de rol de vida en Altis y Tanoa, Exile, Antistasi y King of the Hill se llenan por las tardes y los fines de semana, así que una caída a las ocho de la tarde es lo más visible que hay. Tercero, existe competencia entre proyectos, jugadores baneados y conflictos internos, y un ataque no le cuesta a quien lo encarga ni conocimientos ni un dinero digno de mención.

A eso se suma el punto decisivo en lo técnico: Arma 3 funciona íntegramente sobre UDP, el juego no necesita TCP para la partida. UDP no tiene un establecimiento de conexión que se pueda exigir, y las direcciones de origen se pueden falsificar. Por tanto, un atacante no necesita entrar en tu servidor ni dirigirse a él correctamente para generarle carga. Además, el bucle de simulación de un servidor de Arma 3 corre en el fondo sobre un único núcleo de cálculo: quien manda paquetes suficientes le cuesta tiempo de proceso a ese único núcleo, y da igual cuántos núcleos tenga la máquina por lo demás. 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 de Arma 3 ocupa de fábrica el bloque del 2302 al 2306 UDP. El parámetro de arranque -port=2302 solo fija el primer puerto, los otros cuatro salen de ahí de forma fija, como puerto de juego más 1 hasta más 4. Quien explota varias instancias en la misma máquina deja por eso al menos 100 puertos de separación (2302, 2402, 2502), porque si no las instancias se quitan entre sí los puertos siguientes.

De estas ocho filas, exactamente tres deben estar en internet abierto: 2302, 2303 y 2304 UDP. Todo lo demás es administración, y los puertos de administración abiertos son el error evitable más frecuente en los servidores de Arma 3.

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

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

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:2302 significa "accesible desde todo internet", 127.0.0.1:3306 significa "solo local" y no necesita ninguna regla de firewall. Junto al juego, en un servidor de rol de vida aparecen ahí con frecuencia MariaDB, un servidor web para la página de la facción, un servicio de TeamSpeak o de voz y algún panel olvidado. La vista del atacante te la da un escaneo de puertos desde fuera:

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

El primer comando muestra el bloque UDP del juego, el segundo todo lo que esté abierto sobre TCP. Un servidor de Arma 3 no necesita ni un solo puerto TCP abierto para la partida.

2. Dejar abiertos solo los puertos que Arma 3 necesita de verdad

Bastan tres puertos UDP hacia fuera, todo lo demás se restringe. Con UFW queda así, y en este orden exacto para que no te quedes fuera de tu propio servidor:

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH'
ufw allow 2302:2304/udp comment 'Arma 3 Spiel, Steam-Query, Steam-Master'
ufw allow from 203.0.113.10 to any port 2306 proto udp comment 'BattlEye 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. El puerto 2305 se queda cerrado, porque Bohemia lo da como reservado y actualmente sin uso. Importante es la línea ufw default allow outgoing: BattlEye establece desde el servidor una conexión hacia arma31.battleye.com y necesita para ello el 2344 de salida en TCP y UDP, así como el 2345 en TCP. Quien bloquea la salida de forma general deja fuera a su propio anti-cheat. Comprueba después del cambio, con una entrada real al servidor, que BattlEye sigue dejando pasar a tus jugadores. La guía completa, con vía de rescate incluida, la tienes en Configurar el firewall UFW sin quedarte fuera del servidor.

La base de datos no tiene nada que hacer en la red abierta bajo ningún concepto. Altis Life y los demás frameworks de rol de vida hablan mediante la extensión extDB3 con una base de datos MySQL, y las credenciales están en texto claro en @extDB3/extdb3-conf.ini. Comprueba en /etc/mysql/mariadb.conf.d/50-server.cnf que ahí ponga:

bind-address = 127.0.0.1

3. Desactivar la carga del puerto de consulta de Steam sin salir del navegador de servidores

El puerto 2303 UDP es el punto más delicado de un servidor público de Arma 3. Responde a las peticiones A2S, es decir, a la consulta estándar del navegador de servidores de Steam: A2S_INFO entrega el nombre, el mapa y el número de jugadores, A2S_PLAYERS la lista de jugadores y A2S_RULES la lista de mods y firmas. Una consulta es un paquete UDP pequeño, la respuesta es un múltiplo de eso. El US-CERT recoge el protocolo de Steam en su alerta TA14-017A con un factor de amplificación de ancho de banda de 5,5, y en Arma 3 la respuesta resulta especialmente grande, porque incluye la lista completa de mods.

De ahí se siguen dos cosas. Primera, tu servidor puede ser utilizado como amplificador contra terceros si un atacante envía consultas con dirección de origen falsificada. Segunda, y más importante para ti, cada consulta cuesta tiempo de proceso en el único núcleo que sostiene la simulación. Bohemia mantiene desde 2015 un ticket al respecto (T83469): los paquetes UDP falsificados contra el puerto de juego o contra el puerto de consulta de Steam llevaban la CPU al 100 por ciento y congelaban el servidor, y para un ataque con éxito por el puerto de consulta bastaban ya 4 Mbit/s. Ese es el motivo por el que en Arma 3 la tasa de paquetes resulta más peligrosa que el ancho de banda.

La primera palanca es el tamaño de la respuesta. La directiva steamProtocolMaxDataSize en la server.cfg determina cuántos bytes puede meter el servidor en su respuesta de consulta. Los operadores con listas de mods grandes la suben a 2048 o más, porque de lo contrario aparece en el log el aviso "Query data overflow, Mods/Signatures will not be correctly received by clients". Cada subida agranda, eso sí, justo la respuesta que un atacante amplifica. Pon por eso el valor tan bajo como tu lista de mods permita, y saca del comando de arranque los mods que no uses:

steamProtocolMaxDataSize = 2048;

La segunda palanca es un límite de tasa por dirección de origen que afecte solo al puerto de consulta. No bloquees el 2303 UDP en bloque: sin respuesta de consulta tu servidor desaparece del navegador de servidores y de cualquier página de estado, y los jugadores nuevos ya no lo encuentran. Un navegador de servidores legítimo consulta unas pocas veces por minuto, no cientos de veces por segundo.

4. Sacar el RCon de BattlEye de la red abierta

BattlEye es el anti-cheat de Arma 3 y se activa en la server.cfg con BattlEye = 1;. El control remoto que lo acompaña, BattlEye RCon, es un protocolo UDP propio y se configura en BattlEye/beserver_x64.cfg (el archivo con el añadido _x64 vale para arma3server_x64, el servidor habitual hoy en día):

RConPassword IhrAlphanumerischesPasswort
RConPort 2306
RConIP 127.0.0.1
MaxPing 350
RestrictRCon 0

Hay tres puntos decisivos. La contraseña de RCon tiene que ser puramente alfanumérica, porque los caracteres especiales descolocan en silencio al analizador de protocolo de BattlEye, y un acceso RCon que falla en silencio es uno que no tienes cuando hace falta. RConIP determina en qué dirección escucha RCon: si ahí pone 127.0.0.1, la interfaz solo es accesible en local y tu herramienta de RCon llega a ella mediante un reenvío SSH. Y RConPort tiene que quedar por encima del bloque de juego, lo habitual es el puerto de juego más 4, es decir, el 2306. Quien tenga que abrir RCon hacia fuera solo libera el puerto para la dirección fija de su equipo de administración.

Una cosa debe quedar clara: BattlEye es un anti-cheat, no una protección DDoS. Comprueba a los jugadores que están conectados. Un atacante que inunda tu servidor no quiere entrar.

5. Enlazar el headless client de forma fija

Un headless client es una segunda instancia de Arma 3 sin gráficos que se conecta al servidor como si fuera un jugador y le quita el cálculo de la IA. En las misiones grandes es la mayor ganancia de rendimiento que existe, porque de lo contrario la IA queda en el mismo núcleo que la simulación. Se habilita en la server.cfg:

headlessClients[] = {"127.0.0.1"};
localClient[] = {"127.0.0.1"};

Sin esas entradas el servidor no admite ninguna conexión de headless client, y esa es la buena noticia. La mala: localClient[] concede a la dirección registrada ancho de banda ilimitado y prácticamente ninguna comprobación de latencia. Pon ahí únicamente 127.0.0.1 o la dirección fija de tu propio servidor de headless client, nunca un rango entero de direcciones. El cliente se arranca con -client -connect=127.0.0.1 -port=2302 -password=..., y ocupa un hueco de maxPlayers. Cuéntalo, por tanto, o tus jugadores se encontrarán con un servidor lleno.

6. Endurecer la entrada, las firmas y las votaciones

Estos ajustes no protegen tu línea, pero cierran todo lo que llega por la vía normal de entrada: clientes manipulados, ejecución de scripts dentro del juego y abuso de las votaciones. Las líneas siguientes deben estar en la server.cfg de cualquier servidor público:

verifySignatures = 2;
BattlEye = 1;
kickDuplicate = 1;
allowedFilePatching = 0;
maxPlayers = 64;
disconnectTimeout = 30;
maxPing = 200;
maxDesync = 150;
maxPacketLoss = 50;
kickClientsOnSlowNetwork[] = {1, 1, 1, 1};
voteThreshold = 1.5;
voteMissionPlayers = 100;
onUnsignedData = "kick (_this select 0)";
onHackedData = "kick (_this select 0)";

verifySignatures = 2 fuerza la comprobación de firmas versión 2 para todos los addons y es el requisito mínimo de cualquier servidor público con mods. allowedFilePatching = 0 niega la entrada a los clientes arrancados con -filePatching (el valor 1 se la permite solo a los headless clients, el valor 2 a todos). kickDuplicate = 1 echa la segunda conexión con el mismo identificador. kickClientsOnSlowNetwork[] decide entrada por entrada si los cuatro umbrales de maxPing, maxPacketLoss, maxDesync y disconnectTimeout solo se registran en el log (0) o se aplican (1). disconnectTimeout acepta valores de 5 a 90 segundos. Un voteThreshold por encima de 1 vuelve inalcanzables las votaciones y cierra así la vía más popular para molestar a un servidor sin un solo paquete de ataque: el cambio de misión por votación.

7. Limitar las tasas de paquetes y de conexiones por dirección de origen

Contra los ataques pequeños y los bots mal hechos ayuda un límite superior por dirección de origen. Como Arma 3 va en UDP puro, se trabaja con hashlimit, y el puerto de consulta recibe un límite bastante más estricto que el puerto de juego:

iptables -I INPUT -p udp --dport 2303 -m hashlimit --hashlimit-name a3_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name a3_game --hashlimit-mode srcip --hashlimit-above 900/sec --hashlimit-burst 1200 -j DROP
iptables -I INPUT -p udp --dport 2302:2306 -m length --length 0:27 -j DROP

La primera regla descarta las consultas desde el mismo origen a partir de más de diez por segundo sostenidas, la segunda los paquetes de juego a partir de más de 900 por segundo sostenidos, y la tercera los paquetes UDP sin carga útil aprovechable. Las tres cifras son puntos de partida, no verdades absolutas: un servidor de rol de vida lleno con 80 jugadores genera muchos más paquetes que una partida de Antistasi entre seis, y quien ajusta demasiado fino echa fuera a sus propios jugadores. Mide primero una semana de funcionamiento normal.

Dos avisos al respecto. 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. Otro cuello de botella que se pasa por alto a menudo es el seguimiento de conexiones del kernel: también UDP crea entradas ahí, y un flood de consultas desde muchas direcciones falsificadas llena la tabla en segundos. Si se llena, el servidor descarta también los paquetes legítimos y en el log aparece "nf_conntrack: table full". El valor actual y el límite los muestra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. basic.cfg: ancho de banda, tamaños de paquete y archivos añadidos

El segundo archivo de configuración de un servidor de Arma 3 se llama basic.cfg y se carga con -cfg=, mientras que -config= carga la server.cfg. Controla el comportamiento de red y contiene exactamente un valor que es relevante de forma directa para la seguridad:

MaxMsgSend = 1024;
MaxSizeGuaranteed = 512;
MaxSizeNonguaranteed = 256;
MinBandwidth = 15000000;
MaxBandwidth = 100000000;
MinErrorToSend = 0.001;
MinErrorToSendNear = 0.01;
MaxCustomFileSize = 0;
class sockets { maxPacketSize = 1400; };

MaxCustomFileSize es el tamaño máximo en bytes de los archivos de cara y de sonido que traen los jugadores y que el servidor reparte a todos los demás. El valor 0 desconecta ese reparto. Con ello desaparece una vía por la que un solo cliente ocupa el ancho de banda de tu servidor sin ninguna infraestructura de ataque. MinBandwidth es el ancho de banda que el servidor da por asegurado, y el valor orientativo es el número de jugadores por 256 kbit/s, es decir, unos 16 Mbit/s para 64 huecos. Los valores demasiado optimistas aumentan la carga y la desincronización, porque el servidor genera mensajes que luego descarta. MaxMsgSend limita los paquetes por paso de simulación y es la primera palanca contra la desincronización; el valor por defecto de 128 se queda corto para los servidores modernos.

9. Registrar datos para no tener que adivinar durante el ataque

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 sábado por la noche. Con apt-get install -y vnstat sysstat la medición corre de forma permanente, y logFile = "arma3server.log"; en la server.cfg te da además la vista del servidor. Durante un incidente bastan cuatro comandos:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp portrange 2302-2306 -c 200 -q

Lo revelador es la comparación entre puertos. Si la carga cae casi por completo sobre el 2303, es un flood de consultas, y golpea al tiempo de proceso. Si se reparte de forma uniforme por los puertos 2302 a 2306 con direcciones de origen siempre nuevas, es un flood UDP falsificado, y golpea a la línea. Con tcpdump vale una norma: limítalo siempre con -c, porque una captura a plena carga añade trabajo a un servidor que ya está saturado. Cómo interpretar los valores lo explica Detectar un ataque DDoS. Cómo se instala y se actualiza el servidor de forma limpia lo explica Instalar un servidor de juego con SteamCMD.

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 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 es la tasa de paquetes, y en Arma 3 golpea casi siempre antes. 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, y la simulación de Arma 3 depende además de un único núcleo.

La fila de los 4 Mbit/s es la más incómoda. En Arma 3 un ataque no tiene que ser grande para hacer efecto: le basta con mandar paquetes suficientes al puerto adecuado. Los operadores lo viven como "pero si la carga no era ni alta y aun así se cayó todo". Al revés, para los ataques volumétricos vale la física simple: con 473,4 Gbit/s cualquier ajuste local carece de sentido, porque los paquetes de tus jugadores dejan de pasar mucho antes. 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 proyectos no reciben ataques de vez en cuando, sino de forma dirigida y durante semanas. Un servidor de rol de vida con una comunidad fija y una escena de competencia es en esto el caso normal, no la excepción. Para eso existe la Advanced DDoS Protection desde 50,00 € al mes, PrePaid, sin permanencia mínima y sin cuota de instalación. La diferencia no está en más capacidad, sino en el control:

• IP de protección dedicada del núcleo de red de Frankfurt, a la que se cambia tu servidor dentro de nuestra propia red. En tu lado no hace falta ninguna modificación.
• Reglas de protección autogestionables por puerto y protocolo en el área de cliente: defines por separado qué se permite en 2302 UDP y qué en 2303 UDP, y puedes así llevar el puerto de consulta bastante más estricto que el puerto de juego.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso en lugar de esperar a una ventana de mantenimiento.
• Perfil de protección adaptado a cada juego, igual que para aplicaciones modificadas y propias en cualquier puerto TCP o UDP.

Los dos niveles, comparados

Para la mayoría de los proyectos de Arma 3 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

"Moví el puerto del 2302 al 2402 y el ataque siguió": es lo esperable. El servidor registra su puerto nuevo por sí mismo en el servidor maestro de Steam, y la lista de servidores lo vuelve a publicar de inmediato. Cambiar de puerto solo sirve contra alguien que use una dirección vieja sacada de una captura antigua.

"Bloqueé el 2303 por completo y ahora no nos encuentra nadie": pasa exactamente eso. Sin respuesta en el puerto de consulta de Steam falta la entrada en el navegador de servidores, y cualquier página de estado y cualquier bot de Discord muestran el servidor como offline. Lo correcto es un límite de tasa por dirección de origen, no un bloqueo.

"En el log aparece NetServer::SendMsg: cannot find channel": ese mensaje sale cuando el servidor quiere escribir en una conexión que ya no existe. Acompaña por lo general a conexiones de jugadores que se cortan y a caídas de rendimiento (Bohemia lo lleva bajo T83936), no necesariamente a un ataque. Comprueba primero si la tasa de paquetes de la interfaz es siquiera llamativa.

"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. Si se quedan a cero, la regla no se alcanza.

"Desde el firewall nuevo BattlEye echa a todos los jugadores": el servidor ya no alcanza arma31.battleye.com. Los puertos salientes 2344 en TCP y UDP, así como el 2345 en TCP, tienen que quedar abiertos, porque de lo contrario se cae la conexión de anti-cheat del servidor.

"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 de Arma 3 necesita hacia fuera exactamente tres puertos UDP: el 2302 para juego y voz, el 2303 para la consulta de Steam y el 2304 para el registro en el servidor maestro de Steam. El juego no necesita TCP.
• El puerto 2306 UDP lleva BattlEye y la interfaz RCon, y debe quedar abierto únicamente para tus propias direcciones de administración, fijado mediante RConPort y RConIP en beserver_x64.cfg.
• El puerto de consulta de Steam 2303 es el punto más delicado: el protocolo de Steam tiene, según el US-CERT TA14-017A, un factor de amplificación de 5,5, y cada consulta cuesta tiempo de proceso en el núcleo que sostiene la simulación. Limitar en lugar de bloquear.
• Mantén steamProtocolMaxDataSize tan bajo como la lista de mods permita, y pon MaxCustomFileSize = 0; en la basic.cfg: las dos cosas reducen la cantidad de datos que tu servidor entrega sin que nadie se lo pida.
• En Arma 3 decide la tasa de paquetes, no el ancho de banda. Bohemia documenta desde 2015, bajo T83469, que bastaban 4 Mbit/s contra el puerto de consulta para congelar un servidor.
• Las medidas locales acaban en la línea. A partir de 1 Gbit/s de volumen de ataque o de unos cientos de miles de paquetes por segundo decide exclusivamente el filtrado en la red que hay delante del servidor.
• En KernelHost, la protección permanente en dos niveles está incluida en todos los paquetes de servidor sin recargo y activa desde el aprovisionamiento, sin null-routing. La Advanced DDoS Protection la completa desde 50,00 € al mes con una IP de protección dedicada y reglas por puerto autogestionables.

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