Proteger un servidor de Lineage 2 frente a ataques DDoS

Un servidor privado de Lineage 2 en el que por la noche nadie consigue pasar de la pantalla de acceso, mientras los jugadores que ya están en el mundo siguen jugando sin molestias, no tiene un problema de hardware. Esa es la huella de un ataque DDoS contra el servidor de login, y justo ahí tiene que actuar una protección DDoS para Lineage 2. 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 entonces en la red que hay delante del servidor.

Todos los datos se refieren a L2J y a sus derivados (L2J-Mobius, aCis) sobre Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS, y también a los paquetes L2OFF con AuthD, CacheD y L2Server. 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 ni el servidor de login ni el servidor de juego. Guarda primero las mediciones (consulta el apartado "Registrar los datos"), porque cuando el ataque pase habrán desaparecido.

Proteger un servidor de Lineage 2 frente a DDoS: por qué atacan a los servidores privados de L2

Un servidor privado de Lineage 2 reúne varias características que lo convierten en un objetivo cómodo, y la protección DDoS para Lineage 2 tiene que actuar justo sobre esas características. Primero, tu dirección es pública, y lo es desde el principio: los jugadores se descargan una carpeta System parcheada, y en su l2.ini está la línea ServerAddr= con la dirección IP de tu servidor de login. Cualquiera que haya instalado tu proyecto una vez conoce esa dirección, haya creado un personaje o no.

Segundo, la comunidad juega a horas fijas. Los asedios, los raid bosses épicos y los eventos están en el calendario, y una caída justo a esa hora es lo más visible que hay. Tercero, los proyectos compiten directamente entre sí: quien abre un servidor pelea por los mismos pocos miles de jugadores que otros tres proyectos el mismo fin de semana. Dejar fuera a un competidor es una estrategia habitual en esta escena. El ataque se contrata además como un servicio (en el ambiente se conoce como booter o stresser) y no le cuesta a quien lo encarga ni conocimientos ni un dinero digno de mención. Qué es en detalle un ataque DDoS lo explica el artículo ¿Qué es un ataque DDoS?.

Por qué el servidor de login en el puerto 2106 es el objetivo real

Lineage 2 está repartido en dos procesos separados: un servidor de login y uno o varios servidores de juego. El cliente se conecta primero a 2106 TCP con el servidor de login, se identifica, recibe desde ahí la lista de servidores con la dirección externa y el puerto del servidor de juego, y después abre una segunda conexión a 7777 TCP con el servidor de juego. Los dos procesos tienen sus propios archivos de configuración, sus propios puertos y sus propios límites de carga.

De ahí sale el patrón de ataque que los operadores de L2 describen una y otra vez: un flood contra 2106 bloquea únicamente los accesos nuevos. Quien ya está en el mundo sigue jugando hasta que pierde la conexión por su cuenta. El contador de jugadores en línea baja despacio en lugar de caer de golpe, y en el foro aparece el clásico "el servidor funciona, pero no consigo entrar". Esa imagen es justo lo que distingue un ataque contra el servidor de login de un ataque contra el servidor de juego, en el que todos salen despedidos a la vez.

El servidor de login es además el objetivo más barato, porque el esfuerzo está repartido de forma desigual. El servidor de login de L2J genera al arrancar una reserva de diez pares de claves RSA de 1024 bits y veinte claves Blowfish. Cada intento de acceso le cuesta al cliente enviar un paquete y al servidor un descifrado con la clave RSA privada. Una sesión a medias ocupa mientras tanto una plaza, hasta que el temporizador integrado la descarta: LOGIN_TIMEOUT está fijado en el código fuente en 60 segundos. El valor por defecto MaxConnectionPerIP = 50 permite cincuenta conexiones simultáneas por cada dirección de origen. Mil direcciones de origen bastan, por tanto, para 50.000 sesiones abiertas a la vez, cada una de ellas durante hasta un minuto.

A eso se suma una particularidad del juego que lo diferencia de la mayoría de los servidores de juego: Lineage 2 funciona exclusivamente sobre TCP. El fabricante indica para el juego los puertos TCP 80, 2009, 2106 y 7777, y en UDP únicamente el puerto 53 para la resolución de nombres. No hay, por tanto, tráfico de juego por UDP que haya que filtrar, pero a cambio el clásico SYN flood con direcciones de origen falsificadas es directamente eficaz, y el seguimiento de conexiones del kernel se convierte en el primer cuello de botella.

Por qué los ataques a servidores de Lineage 2 se concentran en las aperturas de servidor

Los ataques contra servidores privados de Lineage 2 se acumulan alrededor de las aperturas de servidor porque la fecha y la hora de la inauguración son públicas semanas antes. Los calendarios de aperturas de proyectos de Lineage 2 listan los próximos arranques por crónica (Interlude, High Five, Classic, Essence), con las rates y la hora exacta de inicio, y se actualizan a diario. El atacante no tiene que investigar nada: el momento que más le conviene está en el anuncio del propio operador.

La segunda razón es económica. Un servidor privado de Lineage 2 gana su dinero al principio: toda la base de jugadores se capta en los primeros días, las donaciones llegan en las primeras semanas y después la población baja de forma constante. Un jugador que no consigue entrar en la primera hora se pasa al proyecto que abre ese mismo fin de semana, y ese proyecto existe siempre. Una hora de caída el día de la apertura no cuesta, por tanto, una hora de ingresos, sino una parte de toda la vida útil del servidor.

La tercera razón es técnica. En el grand opening, miles de jugadores intentan identificarse a la vez. El servidor de login está en ese minuto al límite de todas formas, y un flood añadido apenas se distingue del pico de carga. Un ataque que un martes tranquilo quedaría sin consecuencias basta en la hora de la apertura. Lo mismo vale para las citas anunciadas durante el funcionamiento normal: los asedios de castillos y los raid bosses épicos están en el calendario y son, por la misma razón, ventanas de ataque muy usadas. Cuando pasa la avalancha de la apertura vuelve a bajar el incentivo, y por eso los operadores viven los ataques como oleadas y no como un estado permanente.

Los puertos que de verdad importan

La tabla siguiente lista los puertos de un servidor privado de Lineage 2, el archivo de configuración correspondiente y la directiva que fija el valor. Los valores por defecto proceden de los archivos de configuración que trae L2J y de las guías de instalación de los paquetes L2OFF.

Esta tabla responde de paso a dos preguntas: Lineage 2 no tiene ni puerto de query ni puerto de RCON. No existe ningún servicio aparte que entregue el número de jugadores para una lista de servidores, ni un puerto de control remoto como en los juegos basados en Source. La lista de servidores la genera el propio servidor de login y se la envía por la misma conexión en 2106 al cliente ya identificado. El control remoto en L2J va por comandos dentro del juego y por la base de datos. Con eso desaparecen dos vectores de ataque que otros juegos sí tienen, y queda tanto más colgando del puerto 2106.

Órdenes de magnitud que conviene conocer

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

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

Antes de escribir una sola regla, mira qué ofrece tu servidor hacia fuera. No lo adivines, compruébalo:

ss -lntp

La columna interesante es la de la dirección local. 0.0.0.0:2106 y 0.0.0.0:7777 tienen que estar ahí. 0.0.0.0:9014 y 0.0.0.0:3306 son errores: esos son los dos puertos por los que un atacante puede colgarse de tu lista de servidores o sondear tu base de datos. 127.0.0.1:3306, en cambio, significa "solo local" y no necesita ninguna regla de firewall. La vista del atacante te la da un escaneo de puertos desde fuera:

nmap -Pn -p- --min-rate 1000 IP.DE.TU.SERVIDOR

2. Mantener el puerto 9014 y la base de datos fuera de la red abierta

El puerto 9014 es el canal por el que el servidor de juego se registra en el servidor de login, y no pinta nada en la red abierta bajo ningún concepto. L2J ya trae el valor por defecto correcto: LoginHostname = 127.0.0.1 enlaza el puerto a la interfaz de loopback, así que desde fuera no es accesible en absoluto. Si el servidor de login y el servidor de juego corren en dos máquinas distintas, escribe la dirección interna concreta en lugar de * y abre el puerto únicamente para la otra máquina.

La misma regla vale para la base de datos. Comprueba en /etc/mysql/mariadb.conf.d/50-server.cnf que ahí ponga:

bind-address = 127.0.0.1

Y cambia el usuario de la base de datos. El Server.properties que viene de serie está en Login = root, y el propio archivo comenta que justamente eso no es recomendable. Cómo crear un usuario propio con permisos mínimos lo tienes en Asegurar MariaDB y MySQL. Después comprueba el resultado:

ss -lntp | grep -E ':9014|:3306'

El firewall que va por encima se queda corto. A un servidor de Lineage 2 le bastan dos aperturas hacia fuera, y en este orden exacto para que no te quedes fuera de tu propio servidor:

ufw allow 22/tcp comment 'SSH'
ufw allow 2106/tcp comment 'L2 Login'
ufw allow 7777/tcp comment 'L2 Game'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

La guía completa, con vía de rescate incluida, la tienes en Configurar el firewall UFW sin quedarte fuera del servidor.

3. Desactivar AcceptNewGameServer en cuanto tu servidor esté registrado

En el LoginServer.properties viene de fábrica AcceptNewGameServer = True, y el comentario que hay encima describe exactamente lo que eso significa: cualquier servidor de juego puede registrarse en una plaza libre de tu servidor de login. Mientras 9014 esté solo en la interfaz de loopback, eso no tiene consecuencias. En cuanto el puerto sea accesible por otro motivo, es una puerta abierta. Pon el valor en False en cuanto tu propio servidor de juego esté registrado una vez y tenga su identificador:

AcceptNewGameServer = False

En la contraparte del lado del servidor de juego está AcceptAlternateID = True. Eso resulta cómodo durante el montaje, porque el servidor de login asigna entonces otro identificador si el deseado ya está ocupado. En un sistema en producción quieres lo contrario: un identificador fijo, y un error si está ocupado.

4. Ajustar bien la flood protection del servidor de login

L2J trae su propio freno de conexiones en el servidor de login. Está en el LoginServer.properties, y todos los valores de tiempo son milisegundos:

EnableFloodProtection = True
FastConnectionLimit = 15
NormalConnectionTime = 700
FastConnectionTime = 350
MaxConnectionPerIP = 50

Los valores están relacionados entre sí. Una conexión que llega desde la misma dirección de origen antes de FastConnectionTime tras la anterior cuenta como rápida. Después de FastConnectionLimit conexiones de ese tipo, la dirección se rechaza. NormalConnectionTime es el intervalo a partir del cual el contador vuelve a bajar. MaxConnectionPerIP es el límite superior de conexiones abiertas a la vez por dirección.

Cincuenta conexiones simultáneas son muy generosas para un solo jugador, y los valores más bajos ayudan de forma notable. Aun así conviene tener cuidado: varios jugadores del mismo hogar, un cibercafé y sobre todo las conexiones detrás de un CGNAT (en la escena de L2 eso afecta a muchos jugadores de Turquía, de Brasil y de partes de Europa del Este) comparten una dirección pública. Quien ponga aquí un 3 deja fuera a jugadores reales. Mide primero una semana de funcionamiento normal y baja después por pasos.

Y una limitación que tienes que conocer: ese freno corre dentro del proceso Java del servidor de login. Cada paquete sobre el que decide ya ha pasado por tu línea y ya ha costado tiempo de proceso. Contra un puñado de orígenes funciona, contra una botnet no.

5. Limitar los intentos fallidos y usar banned_ip.cfg

Otras dos directivas del LoginServer.properties controlan cuánto puede seguir probando alguien:

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

LoginTryBeforeBan es el número de combinaciones inválidas de cuenta y contraseña tras el cual se bloquea la dirección, y LoginBlockAfterBan es la duración del bloqueo en segundos (900 equivale a 15 minutos). Después el recuento empieza de nuevo.

Los bloqueos permanentes se escriben en el archivo banned_ip.cfg del directorio de configuración del servidor de login. Se admiten direcciones sueltas, redes enteras y un momento de caducidad opcional como marca de tiempo Unix en milisegundos; todo lo que va después de # es un comentario:

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

Pon además AutoCreateAccounts = False. El valor por defecto True crea automáticamente una cuenta en cada acceso con un nombre de cuenta desconocido. Eso resulta práctico durante el montaje y es un regalo en producción: un atacante genera así tantas cuentas como quiera, y cada una de ellas puede pedir la lista de servidores con la dirección de tu servidor de juego. Deja que las cuentas nazcan en el registro de tu web, y así controlas tú quién recibe un identificador.

6. Limitar en el kernel las tasas de conexión en 2106 y 7777

Lo que el freno de Java decide demasiado tarde, el kernel lo decide antes y más barato. Contra los ataques pequeños y los bots mal hechos ayuda un límite superior por dirección de origen:

iptables -I INPUT -p tcp --dport 2106 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 2106 --syn -m hashlimit --hashlimit-name l2login --hashlimit-mode srcip --hashlimit-above 6/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 6 --connlimit-mask 32 -j DROP

La primera regla descarta las conexiones nuevas al servidor de login en cuanto una dirección tiene más de ocho abiertas a la vez. Un cliente normal necesita exactamente una. La segunda limita la tasa de conexiones nuevas a seis por segundo y dirección, con un margen de veinte, lo que todavía deja pasar una tormenta de reconexiones tras un reinicio del servidor. La tercera permite en el servidor de juego seis conexiones simultáneas por dirección, porque en Lineage 2 el multicliente (dualbox y triplebox) es normal y un límite demasiado estrecho golpea a tus jugadores de pago.

Las tres cifras son puntos de partida, no verdades absolutas. Un servidor con 2000 jugadores simultáneos se comporta de otra manera que uno con 200. Mide primero, ajusta después. 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.

7. Parar un SYN flood: syncookies, backlog y seguimiento de conexiones

Como Lineage 2 funciona exclusivamente sobre TCP, el SYN flood es el vector evidente. Un SYN flood es un ataque que envía peticiones de conexión con direcciones de origen falsificadas y nunca responde a la confirmación, de modo que el servidor reserva para cada petición una memoria que no se usa jamás. Cuatro ajustes lo suavizan:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_synack_retries=2

Las SYN cookies son la línea más importante: el kernel responde a la petición sin guardar nada y crea el estado solo cuando la otra parte completa la conexión de verdad. Los remitentes falsificados se quedan así en nada. De forma permanente, los valores se guardan en un archivo dentro de /etc/sysctl.d/ y se cargan con sysctl --system.

Un cuello de botella que se pasa por alto a menudo es el seguimiento de conexiones del kernel. Si se llena, el servidor descarta también los paquetes legítimos y en el log aparece "nf_conntrack: table full, dropping packet". El valor actual y el límite los muestra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. Web, servidor de login y servidor de juego en direcciones IP separadas

La web del proyecto, con el registro, la tienda de donaciones y las páginas de voto, siempre se puede encontrar a través de tu dominio. Si está en la misma dirección IP que el servidor de login, un ataque contra la web deja al mismo tiempo sin acceso al juego, y al revés. Separa los tres papeles en direcciones distintas. Así, en un ataque contra la web el juego sigue accesible, y en un ataque contra 2106 los jugadores ya conectados siguen jugando.

Mantén al mismo tiempo limpios los registros DNS. El error más frecuente es un registro A olvidado que apunta a una dirección anterior: deja sin efecto cualquier cambio de dirección, porque el atacante encuentra la nueva por el mismo nombre que tus jugadores.

Y aquí toca honestidad en lugar de pensamiento mágico: la dirección de tu servidor de login no se puede mantener en secreto. Está en el l2.ini de la carpeta System que se descarga cada jugador. Y la dirección del servidor de juego la reparte el propio servidor de login: en L2J figura como dirección externa en el ipconfig.xml (en derivados más antiguos, como ExternalHostname en el Server.properties), y se le comunica a todo cliente que se haya identificado con éxito. Esconderse no es una estrategia; filtrar sí lo es.

9. 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 sábado 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
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 'tcp port 2106' -c 200 -q

La segunda línea es la más reveladora en Lineage 2: cuenta las conexiones a medio abrir. Un valor de cinco cifras con unos pocos cientos de jugadores es un SYN flood y nada más. 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.

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. Contra un servidor de Lineage 2 ni siquiera hace falta un ataque grande, porque la segunda magnitud golpea antes: la tasa de paquetes. 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.

En un juego puramente TCP se añade un tercer límite. Cada conexión a medio abrir ocupa una entrada en el seguimiento de conexiones y en el backlog, y el servidor de login de L2J mantiene sus sesiones hasta 60 segundos. Un ataque de unos pocos cientos de miles de paquetes por segundo, que no llena ni un tercio de tu línea, puede bloquear por completo el acceso. Los operadores lo viven como "pero si la carga no era ni alta y aun así no entraba nadie".

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 112,2 Gbit/s con más de 8,7 millones de paquetes por segundo contra un servidor de juego y un ataque multivector de más de 473,4 Gbit/s con más de 41,5 millones de paquetes por segundo contra un servidor de voz. Para eso no existe ningún ajuste local. Los ataques volumétricos tienen que terminar en la red que hay delante del servidor. Qué hacer en el caso agudo lo explica Ataque DDoS grave: qué hacer.

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. Justo en un grand opening, esa es la diferencia entre un arranque logrado y uno perdido. 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, y en la escena de Lineage 2 ese es el caso normal para cualquier servidor que llegue a los puestos altos de las listas. Para esos 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 am Main, 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 2106 TCP y qué en 7777 TCP. En Lineage 2 ese es el punto decisivo, porque los dos puertos tienen patrones de tráfico completamente distintos: muchas conexiones cortas por un lado, pocas y muy largas por el otro.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso, y puedes endurecer las reglas antes de la hora de la apertura y volver a aflojarlas después.
• Perfil de protección adaptado a la aplicación, también para archivos de servidor modificados y propios en cualquier puerto TCP o UDP. Que ejecutes L2J, L2J-Mobius, aCis o un paquete L2OFF no cambia nada para el conjunto de reglas, porque este se apoya en el puerto y el protocolo.

Los dos niveles, comparados

Para la mayoría de los proyectos de Lineage 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, y eso ocurre, por experiencia, en la semana anterior al grand opening.

Errores frecuentes y sus soluciones

"El acceso no funciona, pero el servidor de juego va con normalidad": eso no es casualidad, sino la forma habitual de un ataque contra un servidor de Lineage 2. El servidor de login y el servidor de juego son dos procesos en dos puertos. Mide ss -tn state syn-recv | wc -l y sar -n DEV 1 10. Si suben las conexiones a medio abrir mientras el ancho de banda no llama la atención, es un flood de conexiones contra 2106.

"Cambié la dirección IP y al día siguiente estaba otra vez fuera": el atacante recibe la dirección nueva por el mismo camino que tus jugadores, es decir, por la nueva carpeta System con el l2.ini modificado, por tu anuncio o por un registro DNS olvidado. Cambiar de dirección da tiempo, no es una solución.

"Puse MaxConnectionPerIP en 3 y ahora se quejan los jugadores": el dualbox es habitual en Lineage 2, y los jugadores detrás de un CGNAT comparten una dirección pública con otros cientos. Vuelve a un valor que cubra tus mediciones de funcionamiento normal y limita en su lugar la tasa de conexiones nuevas en el kernel.

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

"Todos los jugadores tienen lag spikes, pero la línea está tranquila": entonces no es un ataque DDoS. En un servidor Java, los sospechosos habituales son las pausas del recolector de basura, una base de datos sin los índices adecuados y un script o un evento propio metido en un bucle. Comprueba primero sar -n DEV 1 10: si las tasas de paquetes siguen siendo normales, la causa está en el servidor y no en la red.

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

"Mi grand opening es dentro de dos semanas": entonces múdate ahora y no en la semana del arranque. Una mudanza cuesta una carpeta System nueva para los jugadores, un cambio de DNS y una prueba completa. Todo eso lo quieres tener hecho antes de anunciar la fecha, porque desde el anuncio cualquier competidor conoce tu peor momento.

En resumen

• Un servidor privado de Lineage 2 necesita exactamente dos puertos en la red abierta: 2106 TCP para el servidor de login y 7777 TCP para el servidor de juego. El puerto 9014, la base de datos (3306 en L2J, 1433 en L2OFF) y los puertos internos de L2OFF 2002, 2006, 2008, 2104 y 2108 no entran ahí.
• Lineage 2 funciona exclusivamente sobre TCP y no tiene ni puerto de query ni puerto de RCON. El ataque típico es por eso un SYN flood o un flood de conexiones contra el puerto 2106, y no un flood UDP.
• Un ataque contra el servidor de login bloquea solo los accesos nuevos. Si no entra nadie mientras los jugadores del mundo siguen jugando, la causa hay que buscarla en el puerto 2106 y no en el 7777.
• Ajusta de forma consciente EnableFloodProtection, MaxConnectionPerIP, LoginTryBeforeBan y AutoCreateAccounts, pon AcceptNewGameServer en False tras el registro y limita además las tasas de conexión en el kernel, porque el freno de Java solo actúa por detrás de la línea.
• Los ataques a servidores de Lineage 2 se acumulan en las aperturas de servidor, porque la fecha y la hora son públicas semanas antes y el daño económico es mayor el día de la inauguración. La protección tiene que estar antes del anuncio, no después.
• Por encima de la capacidad de la línea y por encima de unos cientos de miles de paquetes por segundo decide únicamente el filtrado en la red que hay delante del servidor. En KernelHost es de dos niveles, está activo de forma permanente, sin recargo y sin null-routing.

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.