Proteger un servidor de Hytale frente a ataques DDoS

Un servidor de Hytale que por las noches, en plena partida, pierde todas las conexiones a la vez, se queda inalcanzable unos minutos y después vuelve a funcionar por sí solo rara vez tiene un problema de hardware. Lo habitual es que haya un ataque en marcha. Este artículo muestra cómo proteger un servidor de Hytale frente a ataques DDoS: primero lo que puedes configurar tú mismo sin coste añadido, después el punto en el que esas medidas se acaban técnicamente y, al final, lo que tiene que ocurrir en la red que hay delante del servidor para que siga siendo accesible.

Todos los datos se refieren al servidor dedicado oficial de Hypixel Studios, es decir, a HytaleServer.jar junto con Assets.zip bajo Java 25, en 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. Hytale está en Early Access y se mueve rápido: por eso en este artículo cada afirmación sobre el juego lleva una fecha, y todo lo que no está documentado de forma oficial queda marcado expresamente como expectativa o como fuente de la comunidad. Si el ataque está en marcha ahora mismo vale además un orden: primero medir, después cambiar. Un reinicio en caliente bajo carga descarta todo lo que haya pasado en el mundo desde el último punto de guardado, y las mediciones del incidente también se pierden.

Por qué los servidores de Hytale son tumbados con ataques DDoS dirigidos

Un servidor de Hytale es un público en una dirección fija, y ese público es sustituible. Quien tres tardes seguidas no puede entrar en su servidor habitual se busca otro. Ese es justo el modelo de negocio que hay detrás de los ataques contra servidores de comunidad: no van por los datos ni por la extorsión, van por los jugadores que se marchan. Un servicio de booter que bombardea una dirección por unos pocos euros al mes no le exige a quien lo encarga ni conocimientos ni esfuerzo, y el daño se produce de nuevo con cada caída.

A eso se suma en Hytale una particularidad: el código del servidor es público. Hypixel Studios anunció en junio de 2026 el programa Hytale Shared Source y pone a disposición por esa vía el código completo del servidor, el protocolo de red y los assets a través de GitHub, accesibles para cualquiera con una licencia válida del juego. Para los operadores de servidores es una ganancia, porque los plugins se desarrollan contra interfaces reales. Para el lado atacante significa que ya nadie tiene que adivinar el protocolo. Quien quiera saber en qué punto el establecimiento de conexión cuesta tiempo de proceso puede leerlo. Qué ocurre técnicamente en un ataque así lo explica el artículo ¿Qué es un ataque DDoS?.

La situación de Hytale a 27 de septiembre de 2026

Hytale está en Early Access desde el 13 de enero de 2026, disponible para Windows, macOS y Linux, y en los días siguientes al lanzamiento superó el millón de jugadores. El camino hasta ahí fue poco habitual, y explica por qué los artículos más antiguos sobre Hytale a menudo ya no son válidos.

La consecuencia práctica de esta cronología: un servidor de Hytale de hoy no es un servidor de enero. Con Update 6 el protocolo de red pasó de hytale/2 a hytale/3 y, según las notas de parche oficiales del 27 de agosto de 2026, el servidor y los plugins tienen que volver a compilarse antes de poder conectarse. Quien planifica su disponibilidad no solo planifica contra ataques, sino también contra cambios de protocolo.

Por qué el 12 de octubre de 2026 es la fecha crítica

Las grandes actualizaciones de contenido funcionan como un segundo lanzamiento. Devuelven a los jugadores antiguos, atraen nuevos y, durante unos días, la accesibilidad decide qué servidor de comunidad crece con esa ola y cuál la pierde. Ese patrón está documentado en otros juegos: Palworld alcanzó en enero de 2024 millones de jugadores en pocos días, y los servidores de comunidad de esa fase inicial fueron los más atacados justo en el momento en que más tenían que perder. La mecánica que hay detrás está descrita con detalle en Proteger servidores de Palworld frente a ataques DDoS y se traslada uno a uno a Hytale.

De ahí se sigue una verdad incómoda sobre el calendario: la protección que se pide el 12 de octubre llega tarde. Una línea, una IP de protección, un conjunto de reglas por puerto y un valor de referencia del funcionamiento normal necesitan margen previo, porque sin datos de comparación no se pueden ajustar con sentido. Quien empieza dos semanas antes de una actualización grande tiene tiempo de sobra. Quien empieza el día de la actualización ajusta a ciegas.

Los puertos que de verdad importan en un servidor de Hytale

Un servidor de Hytale necesita exactamente un puerto abierto: 5520 UDP. El tráfico de juego va por QUIC, es decir, por UDP, y el juego no necesita TCP para la partida. Quien solo abre TCP ve la misma imagen que con un firewall cerrado: los jugadores se quedan en un tiempo de espera agotado. El enlace por defecto es 0.0.0.0:5520, y un puerto distinto se fija al arrancar con --bind.

Esta tabla es más corta que en la mayoría de los demás juegos, y esa es la diferencia más importante. Un servidor de Counter-Strike responde a consultas de estado en el formato A2S de Steam, un servidor de Minecraft Bedrock responde a un Unconnected Ping, un servidor de Palworld mantiene abierto un puerto de consulta propio. Para Hytale, en la documentación pública no hay descrito ningún otro puerto además de 5520 UDP: ni puerto de consulta, ni puerto RCON, ni interfaz REST en el estado de fábrica. Todo lo que un servidor de Hytale ofrece hacia fuera está en un único puerto UDP.

Los servidores de Hytale en cifras

Los valores siguientes son la base de cualquier decisión sobre reglas de filtrado y umbrales. En cada caso se indica la procedencia, porque es lo que decide su solidez.

Lo que QUIC cambia en la superficie de ataque

QUIC es un protocolo de transporte que establece conexiones seguras sobre UDP y que lleva el cifrado según TLS 1.3 integrado de forma fija. No existe un QUIC sin cifrar. Para un operador de servidor eso significa dos cosas que se contradicen, y las dos importan.

La primera es una mejora real. Como UDP no obliga a establecer una conexión y las direcciones de origen se pueden falsificar, los servicios UDP sin conexión son los amplificadores clásicos para atacar a terceros. QUIC limita eso en el propio estándar. El RFC 9000 prescribe en su apartado 8.1 que un servidor, antes de comprobar la dirección de origen, solo puede enviar como máximo el triple de la cantidad de bytes recibida, y el apartado 14.1 exige que un cliente rellene su primer datagrama hasta al menos 1200 bytes. Juntas, esas dos reglas dejan el factor de amplificación de un servicio QUIC en un máximo de tres, mientras que un puerto de consulta de Steam o un Unconnected Ping de Bedrock llega a un múltiplo de eso. Por ello un servidor de Hytale que funcione correctamente resulta prácticamente sin interés como amplificador de reflexión. Es una ventaja estructural frente a casi todos los demás juegos con tráfico UDP, y en la comparación con los servidores de Minecraft Bedrock se aprecia con claridad.

La segunda es el precio de eso. Un establecimiento de conexión QUIC le cuesta al servidor tiempo de proceso, porque incluye una negociación TLS 1.3 con criptografía asimétrica. Un único paquete falsificado no puede forzar un establecimiento, pero una avalancha de intentos de conexión reales procedente de un botnet sí. El atacante paga también tiempo de proceso, y es justo esa relación la que decide: mientras el servidor haga por cada intento de conexión más trabajo que el atacante, el ataque resulta rentable. Una avalancha de intentos de conexión no carga por tanto la línea, sino el procesador, y en la estadística de ancho de banda no parece nada. Es el mismo mecanismo que en Minecraft se conoce como nullping y flood de handshakes, y que se describe en detalle en Protección DDoS y protección contra nullping en Minecraft.

De todo esto lo más aprovechable en la práctica es la regla de los 1200 bytes. Un intento de conexión nuevo tiene que llegar como datagrama de al menos 1200 bytes; si no, según el estándar no es un establecimiento de conexión válido. El tráfico de juego en marcha, en cambio, consiste sobre todo en paquetes pequeños. Esa distinción se puede volcar en una regla de filtrado, y a eso llegamos en seguida.

Lo que en Hytale no está documentado públicamente

Esta lista pertenece a un artículo honesto, porque fija dónde no puedes fiarte de las cifras. Todo lo que sigue no está confirmado de forma oficial a 27 de septiembre de 2026:

• Si el servidor usa QUIC Retry para comprobar la dirección. El RFC 9000 permite en su apartado 8.1.2 un paquete Retry con token, con el que un servidor comprueba la dirección de origen antes de reservar recursos. No está documentado si Hytale lo hace ni a partir de qué carga. Da por hecho que no puedes contar con eso.
• Los valores por defecto de los bloques RateLimit y ConnectionTimeouts en config.json. Que existen los dos bloques es consistente en varias fuentes. Las cifras indicadas, sin embargo, se contradicen: una fuente da umbrales concretos, otra describe los bloques como presentes pero sin efecto. Por eso en este artículo no aparece ninguna de esas cifras, y por eso no deberías incluir esos bloques en tu defensa.
• Los nombres y valores por defecto de los modos de autenticación. La documentación de la comunidad sobre el código del servidor publicado describe tres modos, fijados mediante --auth-mode, con authenticated como valor por defecto y además offline e insecure para entornos privados y desarrollo. Eso no está confirmado de forma oficial. La regla que se deriva es de todos modos inequívoca: no cambies el modo en un servidor público.
• Los detalles del establecimiento TLS. La documentación del protocolo hecha por la comunidad, basada en el código del servidor publicado, describe un certificado por ambas partes, un certificado de servidor autofirmado generado al arrancar cuya huella SHA-256 llega a los clientes a través del servicio de sesión, y un 0-RTT desactivado. Es plausible y encaja con TLS 1.3, pero no está confirmado de forma oficial, y no cambia nada de las medidas de más abajo.
• Tamaños de ataque específicos contra servidores de Hytale. No hay cifras públicas al respecto. Los 5 a 50 Gbit/s de la tabla son un valor de experiencia a través de proyectos de servidores de juego y expresamente no una estadística de Hytale.
• Tasas de paquetes por jugador en funcionamiento normal. Tampoco hay para eso ninguna publicación sólida. Por eso en este artículo no aparece ningún umbral que pudieras adoptar sin comprobarlo, sino una guía para medirlo tú mismo.

Lo que puedes hacer tú mismo antes de gastar dinero

Los pasos siguientes no detienen ningún ataque volumétrico, eso no lo puede lograr ningún software en el servidor. Pero se llevan por delante todo lo que queda por debajo: escaneos de puertos, avalanchas de intentos de conexión desde pocos orígenes, intentos de toma de control por interfaces de administración instaladas además y la ocupación de todos los slots por gente ajena. Eso es la mayor parte de lo que molesta a un servidor de Hytale en el día a día, y cuesta una hora larga.

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:5520 significa "accesible desde todo internet", 127.0.0.1:8080 significa "solo local" y no necesita ninguna apertura. Junto al proceso Java del servidor, en una máquina que ha ido creciendo aparecen a menudo un panel de administración, un servidor web para el visor de mapa y una base de datos. La vista del atacante te la da un escaneo de puertos desde fuera:

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

El segundo comando es el más importante. Muestra qué más está abierto, y en la práctica eso es casi siempre más de lo esperado.

2. Dejar abierto solo el 5520 UDP y cerrar todo lo demás

Bastan dos aperturas. 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 5520/udp comment 'Hytale QUIC'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

No necesitas ninguna apertura de TCP en el 5520. Si explotas el servidor en un puerto distinto, la apertura tiene que coincidir con el valor de --bind, porque si no el arranque se completa y los jugadores siguen sin llegar. La guía completa, con vía de rescate incluida, la tienes en Configurar el firewall UFW sin quedarte fuera del servidor.

Para todo lo que hayas instalado además para administrar vale la misma regla que en cualquier otro juego: no ponerlo en la red abierta, sino hacerlo accesible mediante un reenvío de puertos por SSH y trabajar después en local contra 127.0.0.1:

ssh -N -L 8080:127.0.0.1:8080 root@IP.DE.TU.SERVIDOR

3. Arrancar el servidor como está pensado

El arranque consiste en un único comando. Los archivos del servidor los obtienes mediante el descargador oficial de Hytale o desde tu propia instalación del juego:

java -Xms2G -Xmx4G -jar HytaleServer.jar --assets Assets.zip --bind 0.0.0.0:5520

En el primer arranque el servidor crea config.json, el directorio logs/ y el directorio del mundo universe/. Después lo das de alta una sola vez en su cuenta para que funcione la autenticación de los jugadores. Eso se hace con un código de dispositivo en la consola del servidor:

/auth login device
/auth status

No pongas -Xmx a toda la memoria de la máquina. El sistema operativo, la caché del sistema de archivos y el consumo del entorno de ejecución de Java fuera del heap también necesitan sitio, y un servidor que bajo carga se va a la memoria de intercambio se ve para tus jugadores exactamente igual que un ataque.

4. Whitelist, contraseña del servidor y límite de jugadores contra el agotamiento de slots

El agotamiento de slots es el ataque más barato contra un servidor de comunidad y no necesita ancho de banda. Quien abre suficientes conexiones simultáneas ocupa todos los slots y deja fuera a la propia comunidad sin comprar un solo gigabit. Hytale trae para eso, al contrario que algún otro juego, las herramientas adecuadas en el estado de fábrica: una whitelist en whitelist.json, una lista de bloqueados en bans.json, permisos en permissions.json y, en config.json, las claves Password y MaxPlayers.

{
  "ServerName": "Mi servidor de Hytale",
  "MOTD": "",
  "Password": "un valor que solo conozca tu grupo",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password viene vacío de fábrica, así que entra cualquiera que tenga la dirección y el puerto. Para un servidor cerrado, una contraseña puesta es la medida individual más eficaz contra el agotamiento de slots, y para un servidor público lo es la whitelist durante una oleada de ataques. Y una cosa tiene que quedar clara: una contraseña de servidor protege tus slots, no tu línea. Un atacante que inunda tu servidor no quiere entrar.

Edita estos archivos solo con el servidor parado. El proceso del servidor en marcha mantiene su propio estado en memoria y puede sobrescribir sin avisar, al apagarse, los cambios que hayas escrito en el archivo mientras funcionaba. Para cambios en caliente usa los comandos de consola en lugar del editor.

5. Dejar la autenticación en su valor por defecto

El modo por defecto exige a cada jugador una cuenta de Hytale válida. Eso es más que una comprobación de licencia: es un filtro de acceso que hace caras las cuentas en masa. Un atacante que quiera ocupar slots necesita para ello cuentas válidas, y esas cuestan dinero. No retires ese filtro.

La documentación de la comunidad describe, además del modo por defecto, dos modos más para entornos privados y para desarrollo, con los que se puede entrar sin comprobación de cuenta. Para un servidor público son el peor ajuste posible, porque convierten el agotamiento de slots de una cuestión de dinero en una cuestión de scripting. Si cambias de modo para hacer pruebas, hazlo en una máquina que no esté en internet, y vuelve a cambiarlo después.

6. Limitar los intentos de conexión nuevos, y hacerlo con la regla de los 1200 bytes

Aquí la ventaja estructural de QUIC se vuelve práctica. Un establecimiento de conexión válido llega, según el RFC 9000, como datagrama de al menos 1200 bytes. El tráfico de juego en marcha es bastante más pequeño. Con el seguimiento de conexiones puedes distinguir por eso los flujos de datos nuevos de los existentes y descartar todo lo que sea nuevo y demasiado pequeño. Con nftables, cargado mediante nft -f:

table inet hytale {
    chain input {
        type filter hook input priority -10; policy accept;

        ct state new udp dport 5520 udp length < 1208 drop

        ct state new udp dport 5520 \
            meter hyconn { ip saddr limit rate over 5/second burst 10 packets } drop
    }
}

La primera regla trabaja sobre la longitud UDP, es decir, 8 bytes de cabecera más 1200 bytes de carga útil, 1208 en total. Afecta exclusivamente a los paquetes que quieren abrir un flujo de datos nuevo y que son demasiado pequeños para ello, y no puede alcanzar a los jugadores conectados. La segunda regla limita cuántas conexiones nuevas puede abrir por segundo una única dirección de origen. Cinco por segundo es generoso: un jugador real establece una conexión y la mantiene. La prioridad -10 hace que las dos reglas actúen antes de la cadena de filtrado de UFW.

Un límite superior de la tasa de paquetes por dirección de origen en el propio puerto de juego es la tercera regla con sentido, y aquí vale expresamente: la cifra es un punto de partida, no una verdad absoluta.

iptables -I INPUT -p udp --dport 5520 \
  -m hashlimit --hashlimit-name hytale_udp --hashlimit-mode srcip \
  --hashlimit-above 800/sec --hashlimit-burst 1200 -j DROP

Mide primero una semana de funcionamiento normal y pon después el límite en el doble del pico medido. Para Hytale no hay ninguna cifra de referencia publicada, y los valores dependen mucho del número de jugadores y de la distancia de visión. Quien ajusta demasiado fino echa fuera a sus propios jugadores, y primero a los que tienen la peor línea.

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, esas reglas van además en /etc/ufw/before.rules, porque si no desaparecen con el siguiente ufw reload. Si una regla se alcanza siquiera lo muestra iptables -L INPUT -n -v: si los contadores de aciertos se quedan a cero, no está actuando.

7. Ajustar bien el seguimiento de conexiones del kernel

Este punto explica caídas que parecen un ataque de volumen y no lo son. El kernel crea entradas en el seguimiento de conexiones para el tráfico UDP y, con direcciones de origen falsificadas, cada dirección significa una entrada nueva. Si la tabla se llena, el kernel descarta paquetes sin distinguir, el ataque y tus jugadores se van fuera juntos, y en el log aparece "nf_conntrack: table full". El estado y el límite los muestra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

En la mayoría de los juegos la mejor respuesta a eso es no hacer seguimiento del tráfico de juego. En Hytale es una decisión de verdad, porque la regla de los 1200 bytes del paso 6 necesita el seguimiento de conexiones. Sin él, el filtro no sabe qué paquete abre un flujo de datos nuevo. La recomendación es por tanto: mantener el seguimiento, agrandar la tabla y dejar corto el tiempo de espera para UDP. Un añadido bajo /etc/sysctl.d/, activado con sysctl --system:

net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Quien quiera desactivar el seguimiento de todos modos, por ejemplo en una máquina con muchísimos jugadores simultáneos, pone udp dport 5520 notrack en la tabla raw y renuncia con ello a la regla de los 1200 bytes. Las dos cosas juntas no son posibles. Para un servidor de Hytale individual, la regla vale más que las entradas de tabla ahorradas.

Si los paquetes llegan más rápido de lo que el proceso Java los recoge, se desborda además el búfer de recepción. Para los jugadores eso se ve como pérdida de paquetes, aunque la línea esté libre. Si los ajustes de búfer de arriba son necesarios lo dice el propio kernel: si UdpRcvbufErrors sube en nstat -az, entonces sí sirven. Si el contador se queda a cero, el ajuste no cambia nada.

8. Elegir la distancia de visión y el número de jugadores según la línea

Este paso no es una medida de seguridad, pero decide cuánto ataque puedes aguantar. Hypixel Studios lo formuló con claridad en los requisitos de hardware oficiales del 1 de diciembre de 2025: si duplicas la distancia de visión, cuadruplicas la cantidad de mundo alrededor del jugador. La recomendación oficial está en 12 chunks como máximo, es decir, 384 bloques, fijados mediante MaxViewRadius. Del lado del cliente, esos mismos requisitos indican 2 Mbit/s como mínimo y 8 Mbit/s como recomendación por jugador para la partida multijugador.

Echa cuentas una vez para tu servidor. Un servidor con 40 jugadores y una distancia de visión generosa mueve en funcionamiento normal una cifra baja de tres dígitos en megabits. Ese es el valor con el que se tiene que medir tu línea, y es al mismo tiempo el valor que un ataque tiene que superar para llamar la atención. Quien llena un tercio de una línea de 1 Gbit/s en funcionamiento normal tiene menos reserva que quien está en el cinco por ciento. Una distancia de visión menor no es por tanto solo una cuestión de rendimiento, sino también de robustez.

9. Vigilar mods, plugins y cambios de protocolo

Hytale se puede modificar del lado del servidor: los mods van como .zip o .jar en el directorio mods/, y los plugins hablan directamente con la interfaz del servidor. Es cómodo, porque los jugadores no tienen que instalar nada, y es al mismo tiempo un riesgo de disponibilidad que no tiene nada que ver con los ataques. Un plugin que trabaje de forma costosa por cada evento de red es un amplificador dentro de tu propia casa.

A eso se suma el cambio de protocolo. Con Update 6, según las notas de parche oficiales del 27 de agosto de 2026, el protocolo de red pasó de hytale/2 a hytale/3, y el servidor y los plugins tienen que volver a compilarse antes de poder conectarse. Para la disponibilidad eso significa: lleva una lista de tus mods con su versión, compruébalos antes de cada actualización en una segunda instancia y reserva una ventana de mantenimiento antes del 12 de octubre de 2026. Un servidor que no arranca después de una actualización es, para tus jugadores, indistinguible de un ataque.

10. Reunir mediciones antes de que la cosa se ponga seria

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 conntrack la medición corre de forma permanente. Durante un incidente bastan cinco comandos:

sar -n DEV 1 10
ip -s link show eth0
conntrack -C
nstat -az | grep -i -E 'udp|drop'
tcpdump -ni eth0 -c 200 "udp port 5520"

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. Como el servidor de Hytale corre sobre Java, necesitas una segunda prueba que descarte el falso positivo más frecuente. Una pausa de la garbage collection se ve para los jugadores exactamente igual que un ataque: todos se quedan parados a la vez y después sigue todo. La diferencia está en las cifras.

jcmd $(pgrep -f HytaleServer.jar) GC.heap_info
tail -n 200 logs/latest.log

La interpretación es sencilla. Si los paquetes de entrada suben muy por encima del valor normal mientras el proceso Java apenas trabaja, es un ataque. Si la tasa de paquetes se queda sin llamar la atención mientras el heap se llena o el log muestra pausas largas, es carga. Cómo interpretar los datos de red uno a uno está en Detectar un ataque DDoS en el servidor.

11. Backup, plan de vuelta atrás y un ensayo antes de la fecha grande

Un plan de protección que nunca se ha probado es una suposición. Antes de una fecha como el 12 de octubre de 2026 hay cuatro cosas que dejar hechas: un backup del directorio universe/ junto con config.json que esté fuera de la máquina, una vuelta comprobada a la versión anterior del servidor, una segunda instancia en la que instalar primero la actualización, y una prueba de carga puntual que dispare tus propias reglas de filtrado.

La prueba de carga es el punto en el que la mayoría de los operadores se detiene, y es el más importante. No compruebes si tus reglas frenan ataques, comprueba si dejan pasar a tus propios jugadores. Para eso basta observar los contadores de aciertos mientras veinte jugadores reales entran al mismo tiempo. Si los contadores de las reglas de descarte suben durante esa prueba, tu límite está demasiado apretado, y lo habrías descubierto el día de la actualización y en las peores condiciones.

El punto en el que estas medidas se acaban: ancho de banda y tasa de paquetes

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, eso son 125 megabytes por segundo, y la línea se llena en cuanto alguien manda más. Los ataques contra proyectos de servidores de juego se mueven habitualmente entre 5 y 50 Gbit/s, es decir, entre cinco y cincuenta veces tu línea. Que tu regla de nftables detrás sea buena deja entonces de tener importancia, porque los paquetes de tus jugadores dejan de pasar mucho antes.

La segunda magnitud es la tasa de paquetes, y golpea a menudo 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 el procesador y la tarjeta de red, unos cientos de miles antes de empezar a descartar. Un ataque que no llena ni un tercio de tu línea puede por tanto tumbar tu servidor igualmente, porque el tiempo de proceso se va en descartar. Los operadores lo viven como "pero si la carga no era ni alta y aun así se cayó todo".

En Hytale se suma una tercera magnitud que en la mayoría de los juegos no existe: el tiempo de proceso del establecimiento de conexión. Una avalancha de intentos de conexión válidos procedente de un botnet no llena ninguna línea y no genera una tasa de paquetes llamativa, mantiene ocupado al procesador con criptografía. Esos ataques son invisibles en la estadística de ancho de banda y muy visibles en la carga de procesador del proceso Java, y contra ellos no sirve ni un límite de tasa por dirección de origen ni un búfer de recepción más grande si los orígenes son bastante numerosos.

Para situar qué magnitudes ocurren de verdad: en servidores de KernelHost se filtraron, 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 hay 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 los ataques DDoS contra servidores de Hytale

La protección permanente incluida en todos los paquetes de servidor

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é títulos y protocolos están cubiertos con perfiles de protección propios lo detalla Protección DDoS para servidores de juego en tiempo real.

Advanced DDoS Protection para proyectos de Hytale bajo fuego continuo

Algunos proyectos no reciben ataques de vez en cuando, sino de forma dirigida y durante semanas, y en un juego en Early Access eso afecta sobre todo a los servidores que están creciendo. 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 qué se permite en 5520 UDP, por separado de todo lo demás, y no necesitas ningún ticket para ello.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso, por ejemplo limitar las conexiones nuevas más fuerte durante un rato y dejar intacto el tráfico de juego en marcha.
• Conjunto de reglas adaptado al protocolo, tanto para QUIC sobre UDP como para aplicaciones propias en cualquier puerto TCP o UDP.

La Advanced DDoS Protection está dirigida a los servidores que están en KernelHost. Quien explote su proyecto de Hytale ahora mismo en otro sitio y reciba ataques de forma continua lo traslada aquí para eso, y entonces los dos niveles actúan desde el aprovisionamiento.

Los dos niveles, comparados

Para la mayoría de los servidores de Hytale 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.

Lo que se puede trasladar a Hytale desde otros juegos

Como Hytale es todavía joven y no hay cifras públicas sobre ataques contra servidores de Hytale, el camino más rápido hacia un conocimiento sólido es mirar juegos comparables. Lo que se traslada no es el número de puerto, sino el patrón.

• El arranque explosivo y lo que desencadena: Palworld muestra cómo se solapan en el tiempo una ola de jugadores nuevos y una ola de ataques, y por qué son precisamente los servidores que crecen los que se convierten en objetivo.
• La diferencia entre consulta y tráfico de juego: Minecraft Bedrock explica con el Unconnected Ping cómo funciona la amplificación por UDP. Justo esa vía de ataque no la tiene Hytale gracias a QUIC, y ahí se entiende mejor la diferencia.
• El establecimiento de conexión como objetivo: Protección DDoS y protección contra nullping en Minecraft describe avalanchas de handshakes que se arreglan con casi nada de ancho de banda. Es el parentesco más cercano al flood de conexiones QUIC.
• Pocos jugadores y agotamiento de slots: Project Zomboid y Conan Exiles muestran qué poco esfuerzo hace falta para dejar fuera a un grupo fijo, y qué papel juegan ahí la whitelist y la contraseña.
• Funcionamiento bajo carga continua: Terraria muestra cómo reacciona a los ataques un proceso de servidor único con carga sobre un solo núcleo. El servidor de Hytale es un proceso Java, y el problema de fondo es comparable.

Errores frecuentes en los servidores de Hytale y su solución

"Abrí el puerto 5520 TCP y los jugadores siguen sin entrar": el tráfico de juego va por QUIC, es decir, por UDP. Una apertura de TCP no aporta nada al tráfico de juego. Abre el 5520 UDP y compruébalo desde fuera con nmap -Pn -sU -p 5520. Si has puesto el servidor con --bind en otro puerto, la apertura tiene que nombrar ese puerto.

"El servidor funciona, pero nadie puede entrar, y en el log no hay nada de ataques": comprueba el alta del servidor en su cuenta con /auth status. Un servidor cuyo alta ha caducado sigue funcionando y rechaza a los jugadores igualmente. Eso no es un problema de red ni una regla de filtrado.

"Después de la actualización ya no arranca nada": eso no es un ataque, es el cambio de protocolo. Con Update 6 el protocolo de red pasó de hytale/2 a hytale/3, y el servidor y los plugins necesitan una compilación nueva. Instala las actualizaciones primero en una segunda instancia antes de dejarlas entrar en el servidor de producción.

"Todos los jugadores se quedan parados dos segundos a la vez y después sigue todo": con mucha probabilidad es la garbage collection del entorno de ejecución de Java y no un ataque. Comprueba jcmd ... GC.heap_info y el log del servidor. Si sar -n DEV 1 10 no muestra nada llamativo, no había ningún ataque de por medio, sino un heap demasiado justo o una distancia de visión demasiado grande.

"Mi regla contra los paquetes pequeños dejó fuera a los jugadores": entonces la condición de los 1200 bytes está en la cadena sin ct state new. El tráfico de juego en marcha consiste sobre todo en paquetes pequeños, y una condición de longitud sin comprobación de estado acierta justo a esos. La condición vale exclusivamente para los flujos de datos recién abiertos.

"Cambié la dirección IP y dos horas después estaba otra vez fuera de línea": el atacante tiene la dirección nueva de la misma fuente que la vieja. En Hytale eso suele ser un registro A antiguo en el DNS, un bot de Discord con indicador de estado o una entrada en alguna de las muchas listas de servidores de terceros. Desde Update 6 las direcciones de servidor están ocultas de fábrica en la lista de servidores oficial, lo que cierra la vía más cómoda, pero no todas. Cambiar de dirección es ganar tiempo, no una solución.

"Mis reglas de filtrado 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.

"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 Hytale necesita exactamente un puerto abierto: 5520 UDP para QUIC. El juego no necesita TCP para la partida, y en la documentación pública no hay descrito ningún otro puerto para consultas, RCON o control remoto.
• Como QUIC, según el RFC 9000, solo puede enviar como máximo el triple de la cantidad de bytes recibida antes de comprobar la dirección, y como un primer intento de conexión tiene que medir al menos 1200 bytes, un servidor de Hytale resulta prácticamente sin interés como amplificador de reflexión. Eso lo distingue de los servidores con consulta de Steam o con Unconnected Ping de Bedrock.
• Esa misma regla de los 1200 bytes es la mejor regla de filtrado local: lo que quiera abrir un flujo de datos nuevo en 5520 UDP y sea más pequeño no puede ser un establecimiento de conexión válido y se puede descartar sin alcanzar a los jugadores conectados.
• La parte cara de un establecimiento QUIC es la criptografía, no el ancho de banda. Una avalancha de intentos de conexión válidos es invisible en la estadística de ancho de banda y solo se ve en la carga de procesador y en los contadores de conexiones nuevas.
• El modo por defecto con cuenta obligatoria es un filtro de acceso que hace caras las cuentas en masa. Para un servidor público se deja intacto, y a eso se añaden whitelist.json, bans.json y un valor puesto en Password contra el agotamiento de slots.
• Las medidas locales acaban en la línea: 1 Gbit/s son 125 megabytes por segundo y, con paquetes de 64 bytes, ahí caben unos 1,49 millones de paquetes por segundo. Todo lo que pase de ahí tiene que terminar en la red que hay delante del servidor.
• Hytale está en Early Access desde el 13 de enero de 2026, y Chapter 1 está anunciado para el 12 de octubre de 2026. Las fechas grandes son fechas de ataque, y la protección que se pide el mismo día llega tarde.
• 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, con IP de protección dedicada y reglas por puerto autogestionables, parte de 50,00 € al mes.

Si tu servidor de Hytale 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.

Este artículo refleja la situación a 27 de septiembre de 2026. Hytale está en Early Access, y el protocolo de red ya ha cambiado una vez este año. Se irá actualizando después de Chapter 1 y después de cada actualización que afecte al establecimiento de conexión, a los puertos o a la lista de servidores.