Proteger un servidor de Minecraft Bedrock frente a ataques DDoS

Un servidor de Minecraft Bedrock que por las noches desaparece unos minutos de la lista de servidores y después vuelve rara vez tiene un problema de hardware. Lo habitual es que haya un ataque en marcha, y que ocurra justo cuando hay más jugadores conectados. Este artículo muestra cómo proteger un servidor de Minecraft Bedrock frente a ataques DDoS: primero lo que puedes asegurar tú mismo sin coste añadido, después el punto en el que esas medidas se acaban por pura física, y al final lo que tiene que ocurrir en la red que hay delante del servidor.

Todos los datos se refieren a un Bedrock Dedicated Server, PocketMine-MP o Nukkit 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. Quien use la Java Edition encontrará los ataques de protocolo típicos de esa versión en Protección DDoS y protección Nullping para Minecraft. La instalación pura de un servidor Bedrock la describe Instalar un servidor de Minecraft Bedrock con Nukkit.

Si el ataque está en marcha ahora mismo: no cambies nada en la configuración y no reinicies el servidor. Guarda primero las mediciones (apartado "Recoger mediciones antes de que estalle"), porque cuando el ataque pase habrán desaparecido sin remedio.

Por qué los servidores de Minecraft Bedrock son objetivo de ataques DDoS tan a menudo

La Bedrock Edition es la versión que corre en consolas, smartphones, tabletas y Windows, y reúne la mayor base de jugadores de todo Minecraft. Donde hay muchos servidores aparece el mayor incentivo para atacar: redes competidoras, jugadores baneados, peleas internas. Un ataque no le cuesta a quien lo lanza ni conocimientos ni un dinero digno de mención, y un booter para servidores se vende por suscripción.

La razón técnica está más abajo. Un servidor Bedrock habla UDP, no TCP, y le responde a cualquiera que pregunte mucho antes de que se haya producido ningún acceso. Justo esas dos propiedades convierten el puerto 19132 UDP en un objetivo agradecido. Qué es en general un ataque DDoS lo explica el artículo ¿Qué es un ataque DDoS?.

RakNet: un protocolo UDP que responde antes de que nadie se haya identificado

RakNet es la biblioteca de red UDP con la que la Minecraft Bedrock Edition gestiona todo su tráfico de juego. UDP no tiene un establecimiento de conexión que un servidor pueda exigir, y por eso las direcciones de origen se pueden falsificar. RakNet construye encima su propia capa de fiabilidad: números de secuencia, confirmaciones (ACK) y confirmaciones negativas (NAK), con las que un cliente puede volver a pedir los paquetes perdidos.

El establecimiento de la conexión consta de siete paquetes, cuatro del cliente y tres del servidor:

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

Solo después envía el cliente el paquete de login con sus credenciales de Xbox Live. Esa es la frase decisiva para quien quiera asegurar su servidor Bedrock: el servidor ha procesado siete paquetes, ha gastado tiempo de proceso y memoria y ha respondido varias veces antes de enterarse siquiera de quién está llamando a la puerta. Cualquier medida que actúe en el momento del acceso llega, por tanto, cuando la carga ya se ha producido.

A eso se suma un segundo punto de entrada, todavía más temprano. Para que un servidor aparezca en la lista de servidores de un jugador con nombre, versión y número de jugadores, responde al Unconnected Ping (ID de paquete 0x01) con un Unconnected Pong (ID de paquete 0x1C). Ese intercambio ocurre antes del establecimiento de conexión propiamente dicho, no exige ninguna credencial y en el Bedrock Dedicated Server no se puede desactivar sin sacar el servidor de todas las listas.

El Unconnected Ping como vector de amplificación: las cifras

Un ataque de amplificación es un ataque en el que el atacante envía peticiones pequeñas con la dirección de origen falsificada a servidores ajenos para que las respuestas, más grandes, acaben en la víctima. El servidor Bedrock no es atacado en ese caso, sino utilizado. Con el Unconnected Ping la cuenta queda así:

De ahí se siguen dos cosas de forma inmediata. Primera: un nombre de servidor largo agranda la respuesta y con ella el factor de amplificación que pones a disposición de atacantes ajenos. Un nombre corto no es cosmética, sino una medida de protección. Segunda: el factor 4 de la configuración estándar es lo bastante pequeño como para que tu servidor siga sin interesar como reflector, pero lo bastante grande como para que una avalancha de pings cargue tu propia línea de salida con el cuádruple de lo que entra.

El fallo de amplificación de 2024 muestra lo mal que puede ponerse la cosa cuando se abusa de la propia capa de fiabilidad. En la biblioteca RakNet que se usaba entonces, el paquete Connection Request Accepted estaba marcado como fiable. Un atacante podía representar el establecimiento de conexión con una dirección de origen falsificada hasta ese punto y enviar después una única confirmación negativa con el rango 0 a 8191. El servidor mandaba a continuación miles de paquetes a la dirección falsificada, sin que el atacante tuviera que hacer nada más. Se corrigió pasando el paquete a no fiable, enviando en Open Connection Reply 1 una cookie que un cliente real devuelve, e introduciendo límites de paquetes: 120 paquetes por dirección de origen y ciclo de 10 milisegundos, y 1.000 paquetes en total por ciclo.

Bedrock Edition o Java Edition: qué cambia en la protección DDoS

Quien ya ha asegurado alguna vez un servidor Java se lleva casi todo mal traducido. Las dos ediciones comparten el nombre, pero no el protocolo de red:

La fila de las SYN cookies es la más importante. En la Java Edition, el kernel de Linux rechaza una avalancha de SYN sin que el proceso de Minecraft se entere de nada. En la Bedrock Edition esa ayuda no existe: cada paquete UDP se pasa hasta el proceso del servidor y se evalúa allí. Un servidor Bedrock no tiene ninguna protección integrada en el sistema operativo contra un flood en el puerto 19132, porque UDP no la conoce.

La fila del registro SRV que falta tiene una consecuencia práctica que sorprende a muchos: en la Bedrock Edition no puedes esconder el puerto detrás de un registro DNS. Los jugadores escriben a mano la dirección y el puerto. Quien mueva el puerto tiene que comunicar el nuevo a cada jugador.

Los puertos que de verdad importan

Un Bedrock Dedicated Server se enlaza a exactamente dos puertos, y en los dos casos por UDP. En el server.properties:

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

Esos son los valores por defecto de Microsoft, consultables en la referencia del Bedrock Dedicated Server. Alrededor de esos dos puertos hay otros servicios que corren según el software de servidor:

La tercera y la cuarta fila son los errores evitables más frecuentes en los servidores Bedrock. En Nukkit y PocketMine-MP, enable-query viene de fábrica activado, y en Nukkit un RCON encendido por descuido acaba en 19132 TCP, es decir, en el mismo número de puerto que el juego. Quien solo mire "el 19132 está abierto, todo en orden" se lo salta.

Una particularidad del Bedrock Dedicated Server oficial va también aquí: no conoce ninguna directiva server-ip. PocketMine-MP y Nukkit sí la tienen (server-ip, y en PocketMine además server-ipv6), el servidor oficial no. Escucha, por tanto, siempre en todas las direcciones del sistema, y el firewall es tu única forma de limitarlo.

Lo que puedes hacer tú mismo antes de gastar dinero

Este apartado es el más largo, y es a propósito. Un servidor Bedrock bien configurado aguanta por su cuenta los ataques pequeños y medianos, esté alojado donde esté.

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

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

ss -lntup
ss -lnup sport = :19132

La columna interesante es la de la dirección local. 0.0.0.0:19132 y [::]:19133 significan "accesible desde todo internet". Si al lado aparece una entrada TCP con el mismo número de puerto, es que RCON está funcionando. La vista del atacante te la da un escaneo de puertos desde fuera, para UDP con -sU:

nmap -Pn -sU -p 19132,19133 IP.DE.TU.SERVIDOR
nmap -Pn -p- --min-rate 1000 IP.DE.TU.SERVIDOR

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

A un servidor Bedrock le basta una única apertura hacia fuera, dos con IPv6. 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 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Si no tienes jugadores con IPv6, deja fuera la línea del 19133 y pon además en PocketMine-MP enable-ipv6=false. Cada puerto que no abres es un puerto que no tienes que defender. La guía completa, con vía de rescate incluida, está en Configurar el firewall UFW sin quedarte fuera del servidor.

3. Desactivar la visibilidad en LAN, o el 19132 seguirá abierto

Esta es la trampa en la que cae casi todo el que quiere mover el puerto. La directiva enable-lan-visibility viene de fábrica en true y hace que el servidor responda a las búsquedas de la red local. Microsoft escribe al respecto de forma expresa que con ello el servidor se enlaza además a los puertos estándar 19132 y 19133, aunque server-port y server-portv6 tengan otros valores.

Quien mueva el puerto al 19140 y se crea a salvo sigue escuchando en el 19132. Para un servidor en internet, en el server.properties tiene que estar, por tanto:

enable-lan-visibility=false

Después comprueba con ss -lnup que el 19132 ha desaparecido de verdad. De paso, ese mismo ajuste resuelve el problema de que dos servidores Bedrock en el mismo host se quiten el puerto el uno al otro.

4. Desactivar query y RCON

PocketMine-MP y Nukkit traen el query GS4, una consulta de servidor por UDP con el patrón del protocolo de UT3, y responden a esas consultas en el mismo puerto 19132 en el que corre el juego. La respuesta detallada contiene el nombre del servidor, la versión, el nombre del mundo, el estado de la whitelist, la dirección y el puerto, el número de jugadores, los nombres de todos los jugadores conectados y, en PocketMine-MP y si se quiere, la lista completa de plugins. Resulta práctico para páginas de estado y bots de Discord, pero le revela a un atacante exactamente cuándo merece la pena atacar, y cuesta tiempo de proceso en cada consulta.

enable-query=off
enable-rcon=off

En PocketMine-MP los valores son false en lugar de off, y la lista de plugins se desactiva en el pocketmine.yml con settings.query-plugins: false. Una aclaración que se lee pocas veces: el query GS4 de PocketMine-MP comprueba un token salado con la dirección de origen. La respuesta grande no se puede reflejar hacia una dirección falsificada. Aun así, la consulta cuesta tiempo de proceso, y los datos publicados le ayudan al atacante a elegir objetivo. El Bedrock Dedicated Server oficial no conoce ni query ni RCON, así que ahí este punto no aplica.

Si de verdad necesitas RCON, pon en Nukkit sin falta rcon.port en un valor propio y ábrelo solo para tu propia dirección. Si no, la caída sobre server-port significa que un control remoto de tu servidor está escuchando en 19132 TCP, es decir, en el mismo número que tienes apuntado en todas partes como "abierto".

5. Forzar la autenticación de Xbox Live

La autenticación de Xbox Live es la comprobación de si un jugador que entra tiene una cuenta real firmada por Microsoft. Viene activada de fábrica en los tres softwares de servidor y ahí tiene que quedarse.

En el Bedrock Dedicated Server la directiva se llama online-mode, en PocketMine-MP y Nukkit se llama xbox-auth. En los dos casos true es el estado de fábrica y el valor correcto:

online-mode=true
xbox-auth=true

Microsoft formula al respecto una limitación importante: los clientes que se conectan con un servidor fuera de la red local necesitan la autenticación de Xbox Live siempre, con independencia de este ajuste. La credencial se transmite como cadena de tokens firmados dentro del paquete de login, junto con el identificador de Xbox (XUID) y el nombre visible.

Y ahora la parte que evita malentendidos: la autenticación de Xbox Live protege tu lógica de juego, no tu línea. Ocurre en el paquete de login, es decir, después del establecimiento completo de la conexión RakNet. Un atacante que inunda tu servidor no quiere entrar. Sus paquetes se rechazan, pero han llegado igualmente, y ese es justo el punto.

6. Allowlist y límite de jugadores, y lo que no consiguen

La allowlist (antes whitelist) es la lista de los jugadores que pueden entrar. En el Bedrock Dedicated Server la activas con allow-list=true, y las entradas están en el allowlist.json con nombre, XUID y el campo ignoresPlayerLimit. En Nukkit y PocketMine-MP la directiva se sigue llamando white-list.

allow-list=true
max-players=60
player-idle-timeout=15

Un tiempo de inactividad corto mediante player-idle-timeout es eficaz contra el agotamiento de plazas: los jugadores que solo ocupan un sitio salen despedidos tras el número de minutos indicado. El valor 0 significa que nadie se desconecta nunca por inactividad, y eso es justo lo que aprovecha un atacante que te bloquea las plazas con cuentas reales.

También aquí vale el límite del apartado anterior, y es el punto que más se pasa por alto: la allowlist solo se comprueba cuando el paquete de login ya se ha procesado. Impide entradas, no paquetes.

7. Limitar las tasas de paquetes 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. Para UDP se trabaja con hashlimit, no con connlimit, porque UDP no conoce las conexiones:

iptables -I INPUT -p udp --dport 19132 -m hashlimit --hashlimit-name bedrock_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

La regla descarta los paquetes UDP en cuanto la misma dirección de origen manda de forma sostenida más de 400 paquetes por segundo. El valor es un punto de partida, no una verdad absoluta: un servidor lleno con 60 jugadores y mucha distancia de visión genera bastantes más paquetes que uno vacío, y quien ajuste demasiado fino echa fuera a sus propios jugadores. Mide primero una semana de funcionamiento normal.

Con el Unconnected Ping puedes afinar bastante más, porque un cliente real pregunta por el estado del servidor solo mientras la lista de servidores está abierta, y entonces una vez por segundo. Con nftables se puede acertar justo a ese paquete, porque la ID de paquete es el primer byte que sigue a la cabecera UDP:

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

La expresión @th,64,8 lee ocho bits a partir del bit 64 de la cabecera de transporte, es decir, el primer byte de la carga útil UDP. El valor 0x01 es la ID de paquete del Unconnected Ping. Ese mismo punto lo puedes usar para observar antes de descartar nada:

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

La primera línea cuenta las consultas de estado entrantes, la segunda tus propias respuestas. Si las dos se cuentan por miles cada segundo mientras casi nadie juega, lo que ves es una avalancha de pings y no a tus jugadores.

Dos avisos sobre la durabilidad. 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

Y con UFW, ese tipo de reglas van en /etc/ufw/before.rules, porque de lo contrario desaparecen con el siguiente ufw reload.

8. Aliviar el seguimiento de conexiones del kernel

Un cuello de botella que en los juegos UDP golpea mucho antes que en TCP: el kernel crea una entrada en el seguimiento de conexiones por cada par de paquetes UDP. En una avalancha con direcciones de origen falsificadas, cada paquete es una dirección de origen nueva y, por tanto, una entrada nueva. Si la tabla se llena, el servidor descarta también los paquetes legítimos y en el log aparece "nf_conntrack: table full, dropping packet".

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Si el contador se queda de forma permanente cerca del límite, puedes dejar el tráfico de juego fuera del seguimiento. Eso es eficaz, pero no es inocuo, así que hazlo en los dos sentidos y con una prueba de conexión después:

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

A partir de ahí, las reglas basadas en estado ya no valen para ese tráfico. Tu apertura para 19132 UDP tiene que ser, por tanto, una apertura de puerto real y no puede apoyarse en el estado ESTABLISHED. Comprueba después de aplicarlo con conntrack -L | grep 19132 que ya no se crean entradas, y conéctate una vez con el juego antes de guardar las reglas de forma permanente.

9. Manejar bien Geyser y Floodgate

Geyser es un puente que permite a los clientes Bedrock jugar en un servidor de Java Edition: acepta conexiones Bedrock en 19132 UDP, traduce el protocolo y habla por el otro lado con el servidor Java en 25565 TCP. Floodgate es el complemento que permite a esos jugadores de Bedrock entrar sin cuenta de Java. Para la protección DDoS eso significa tres cosas.

Primera: mantén Geyser actualizado. Justo ese puente fue dos veces el motivo de ataques documentados. En marzo de 2024 se explotó a gran escala el fallo de amplificación descrito más arriba en la biblioteca RakNet, corregido a partir de la build 478. En julio de 2025 siguió un segundo caso: un paquete enviado de forma repetida para confirmar los paquetes de recursos generaba varias sesiones por jugador, y los clientes desconectados podían seguir mandando paquetes porque el canal de red no se cerraba. Corregido a partir de la build 897. Los dos casos los ha publicado el propio proyecto con su cronología.

Segunda: el servidor Java no pinta nada en la red abierta. En la configuración de Geyser, remote.address apunta a auto o a 127.0.0.1, y remote.port al 25565. Enlaza el servidor Java en consecuencia de forma local y no abras el 25565 TCP hacia fuera. Si no, tienes dos superficies de ataque en lugar de una, y la segunda es aquella para la que nunca has pensado ninguna regla.

Tercera: el archivo key.pem es un secreto. Es la clave con la que Floodgate se salta la autenticación de Java para las cuentas de Bedrock. Quien lo suba a un repositorio público, lo copie en un ticket de soporte o lo enseñe en una captura de pantalla ha regalado el acceso a su servidor. El proyecto avisa de ello de forma expresa.

10. Recoger mediciones antes de que estalle

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.

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

Tres de estos valores son especialmente reveladores en un servidor Bedrock. Un Recv-Q distinto de cero de forma permanente en el socket UDP del 19132 significa que el proceso del servidor ya no recoge los paquetes entrantes con la rapidez suficiente. UdpRcvbufErrors cuenta exactamente los paquetes que por eso se descartaron, y es la prueba más dura de que el cuello de botella no es la línea, sino el proceso. UdpNoPorts sube cuando alguien dispara contra puertos en los que no escucha nada, una imagen típica de un escaneo de puertos amplio antes del ataque propiamente dicho.

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: 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. Tu línea está llena en cuanto alguien manda más de 125 megabytes por segundo. Un ataque de 5 a 50 Gbit/s está entre cinco y cincuenta veces por encima. Que tu regla de hashlimit por detrás sea buena ya no importa, porque los paquetes de tus jugadores dejan de pasar mucho antes.

La segunda magnitud es la tasa de paquetes, y en un servidor Bedrock golpea casi siempre primero. Todo el tráfico de juego consta de muchos paquetes UDP pequeños, y justo en esa disciplina un atacante va lo más barato posible. Un ataque que no llena ni un tercio de tu línea puede dejar tu servidor fuera de combate igualmente, porque el tiempo de proceso se va en evaluar y descartar. Los operadores lo viven como "pero si la carga no era ni alta y aun así se cayeron todos". Dentro del juego, lo mismo se nota como picos de lag, efectos de goma y cortes de conexión en mitad de una construcción.

Para eso no existe ningún ajuste local. Los ataques volumétricos tienen que terminar en la red que hay delante del servidor.

Lo que KernelHost pone frente a los ataques DDoS contra servidores Bedrock

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. Entre ellos están también los patrones UDP en el 19132 que no muestran un comportamiento propio de RakNet.

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. La ubicación es Frankfurt am Main. 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. 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 qué se permite en 19132 UDP, qué en 19133 UDP y qué en un puerto distinto, si has movido tu servidor.
• 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. Para Minecraft hay perfiles listos, igual que para aplicaciones modificadas y propias en cualquier puerto TCP o UDP, así que también para Nukkit, PocketMine-MP o una instancia de Geyser en un puerto elegido por ti.

Los dos niveles, comparados

Para la mayoría de los proyectos de Bedrock 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. Quien tenga su servidor ahora mismo en otro sitio resuelve el problema sobre todo con una mudanza: el filtrado actúa en la red que hay delante del servidor, y esa red tiene que ser nuestra.

Errores frecuentes y sus soluciones

"Cambié el puerto al 19140 y el 19132 sigue abierto": eso es enable-lan-visibility=true. El Bedrock Dedicated Server se enlaza entonces además al 19132 y al 19133, ponga lo que ponga en server-port. Ponlo en false, reinicia el servidor y compruébalo con ss -lnup.

"Edité el allowlist.json y ahora no entro ni yo": hay dos causas frecuentes. Todavía queda un whitelist.json antiguo en el directorio y el servidor lee ese, o falta la entrada de XUID, o es incorrecta. Con la autenticación de Xbox Live activa, el nombre por sí solo no basta de forma fiable.

"Mi proveedor bloqueó mi servidor aunque el atacado era yo": comprueba si tu propio servidor ha estado enviando paquetes. Eso es justo lo que pasó con el fallo de amplificación de RakNet de 2024: los servidores afectados mandaban miles de paquetes a direcciones ajenas, y en los avisos de abuso figuraba el puerto 19132 como origen. Con tcpdump -ni eth0 'udp src port 19132' -c 200 -q ves adónde responde tu servidor. Una build actual elimina la causa.

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

"El servidor aparece en la lista, pero no entra nadie": si la entrada muestra el nombre y el número de jugadores, el Unconnected Pong funciona, así que el puerto es accesible en principio. Si aun así falla la entrada, suele estar en el acceso con Xbox Live o en la allowlist. Si al revés solo se quedan fuera los jugadores con IPv6, falta la apertura del 19133 UDP.

"El servidor funciona, pero todos tienen picos de lag": eso es más a menudo un plugin que un ataque. Mira primero si el Recv-Q del socket UDP crece y si sube UdpRcvbufErrors. Si los dos se quedan tranquilos y sar -n DEV 1 10 no muestra nada llamativo, no era un ataque DDoS, sino el propio proceso del servidor. En el Bedrock Dedicated Server ayudan entonces los vigilantes de scripts, cuyos umbrales están en el server.properties bajo script-watchdog-hang-threshold y script-watchdog-slow-threshold.

"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 Minecraft Bedrock necesita exactamente un puerto abierto hacia fuera: 19132 UDP, y además 19133 UDP solo para jugadores con IPv6. El query, el RCON, el depurador de scripts en 19144 TCP y un servidor Java detrás de Geyser en 25565 TCP no pintan nada en la red abierta.
• Quien mueva el puerto tiene que poner enable-lan-visibility=false, porque de lo contrario el Bedrock Dedicated Server se sigue enlazando además al 19132 y al 19133.
• La autenticación de Xbox Live y la allowlist solo actúan en el paquete de login, es decir, tras el establecimiento completo de la conexión RakNet. Protegen tu lógica de juego y tus plazas, no tu línea.
• El Unconnected Ping se pregunta con 33 bytes y se responde con unos 131 bytes, un factor de amplificación de alrededor de cuatro. Un nombre de servidor corto mantiene ese factor pequeño.
• Con UDP ayuda hashlimit en lugar de connlimit, y el seguimiento de conexiones del kernel es lo primero que se llena con direcciones de origen falsificadas. Las dos cosas deberías haberlas medido antes del primer ataque.
• A partir de aproximadamente 1 Gbit/s tu línea está llena, y con paquetes de 64 bytes ahí caben unos 1,49 millones de paquetes por segundo. Por encima de eso decide únicamente el filtrado en la red que hay delante del servidor.
• En KernelHost, la protección permanente en dos niveles está incluida en cada paquete de servidor, activa desde el aprovisionamiento y sin null-routing. La Advanced DDoS Protection la completa con una IP de protección dedicada y reglas autogestionables por puerto.

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.