Proteger un servidor de Palworld frente a ataques DDoS

Un servidor de Palworld que por la tarde, en mitad de la partida, expulsa a todos los jugadores a la vez, se queda unos minutos fuera de línea y después vuelve a estar accesible por sí solo rara vez tiene un problema de hardware. Por regla general hay un ataque en marcha. Este artículo muestra cómo proteger un servidor de Palworld 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 Pocketpair (ID de aplicación de Steam 2394010) sobre Debian 12, Debian 13, Ubuntu 22.04 LTS o Ubuntu 24.04 LTS. Los comandos están escritos para root; si trabajas como usuario normal, antepón sudo. Si el ataque está en marcha ahora mismo, hay un orden que vale la pena respetar: primero medir, después cambiar. Un reinicio forzado bajo carga descarta todo lo que haya ocurrido en el mundo desde el último punto de guardado automático, y las mediciones del incidente también desaparecen con él.

Por qué los servidores de Palworld son objetivo de ataques DDoS dirigidos

Un servidor de Palworld es un público pequeño y fijo en una dirección fija. El servidor dedicado está limitado a 32 jugadores, controlado con ServerPlayerMaxNum y con el rango válido de 1 a 32. Quien en su lugar aloja la partida desde el menú del juego llega a cuatro jugadores, y solo mientras el propio anfitrión esté conectado. De esas 32 plazas se deriva todo lo demás: el grupo juega a horas fijas de la tarde, se conoce entre sí, y una caída a las ocho de la tarde no alcanza a una fracción de los jugadores, sino a todos.

La dirección del servidor no es ningún secreto. Palworld no tiene intermediación a través de un servicio del fabricante: los jugadores escriben la dirección IP y el puerto en el campo de conexión directa, y quien además quiera que el servidor figure en la lista de servidores de la comunidad lo arranca con -publiclobby y deja que el puerto de consulta responda. Cualquiera que se haya conectado una vez conoce por tanto el objetivo. Un servicio de booter que dispare contra esa dirección por unos pocos euros al mes no le exige a quien lo encarga ni conocimientos ni esfuerzo.

A eso se suma que todo el tráfico de juego va por UDP. UDP no tiene un establecimiento de conexión que se pueda exigir, y la dirección de origen de un paquete UDP se puede falsificar. Un atacante no necesita entonces ni entrar en tu servidor ni dirigirse a él correctamente para generarle carga. Lo que ocurre técnicamente durante un ataque así lo explica el artículo ¿Qué es un ataque DDoS?.

Los puertos que de verdad importan en un servidor de Palworld

Un servidor de Palworld necesita exactamente un puerto abierto: 8211 UDP. Todo lo demás es opcional y, según para qué sirva, incluso perjudicial si está en internet. De ahí sale una distinción útil: un ataque DDoS contra el puerto 8211 alcanza siempre al tráfico de juego en sí, mientras que un ataque contra el puerto 27015 UDP solo alcanza a la entrada en la lista de servidores.

Todos esos interruptores están en un único archivo: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, en Windows el equivalente Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. Empieza con la línea de sección [/Script/Pal.PalGameWorldSettings], y a continuación viene una única línea OptionSettings=(...) que contiene todos los ajustes como lista. Un salto de línea dentro del paréntesis invalida la configuración entera, y el servidor vuelve a los valores estándar sin decir nada. La plantilla DefaultPalWorldSettings.ini del directorio del servidor no se edita, porque se sobrescribe en cada actualización.

El servidor de Palworld en cifras

Los valores siguientes son la base de cualquier decisión sobre reglas de filtrado y umbrales.

Por qué el puerto de consulta 27015 es el punto más sensible

El puerto de consulta responde a peticiones de estado en el formato A2S de Steam, es decir, la misma consulta que atienden los servidores de Counter-Strike y de ARK. Una petición A2S_INFO es un paquete UDP sin conexión de unas pocas decenas de bytes, y la respuesta con el nombre del servidor, el mundo, el número de jugadores y el estado de la partida es un múltiplo de eso. Como en UDP se puede falsificar la dirección de origen, un atacante puede dirigirse a puertos de consulta ajenos y desviar las respuestas, más grandes, hacia su objetivo real. En ese caso tu servidor no es la víctima, sino el amplificador, y es su conexión la que paga la factura.

Por eso Valve añadió a A2S_INFO, el 8 de diciembre de 2020, un challenge previo: el servidor responde primero con S2C_CHALLENGE, quien pregunta tiene que devolver el token y demuestra así que no está falsificando su dirección de origen. Eso suaviza la amplificación, pero no la termina, y contra una simple avalancha de consultas iguales desde direcciones reales no sirve de nada.

Para Palworld de ahí se deriva una ventaja importante frente al motor Source: el tráfico de juego y la consulta del servidor están en puertos separados. En Counter-Strike 2 los dos comparten el puerto 27015, y allí un límite de tasa tosco echa fuera también a los propios jugadores. En Palworld puedes limitar 27015 UDP con dureza o cerrarlo del todo sin tocar ni un solo paquete del tráfico de juego en curso en 8211 UDP. Quien no necesite la entrada en la lista quita -publiclobby y el puerto de consulta sin sustituirlos por nada, y saca así de la red una superficie de ataque completa.

Lo que puedes hacer tú mismo antes de gastar dinero

Los pasos siguientes no detienen ningún ataque volumétrico, eso no lo puede hacer ningún software en el servidor. Pero retiran todo lo que queda por debajo: escaneos de puertos, avalanchas de consultas, intentos de toma de control por los puertos de administración y la ocupación de las 32 plazas por gente ajena. Eso es la mayor parte de lo que molesta a un servidor de Palworld en el día a día, y cuesta media hora.

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:8211 significa "accesible desde todo internet", 127.0.0.1:8212 significa "solo local" y no necesita ninguna regla de firewall. Junto al proceso del juego, en un servidor que ha ido creciendo suelen aparecer además un panel de administración, un servidor web para la vista del mapa y una base de datos. La vista del atacante te la da un escaneo de puertos desde fuera:

nmap -Pn -sU -p 8211,27015 IP.DE.TU.SERVIDOR
nmap -Pn -p- --min-rate 1000 IP.DE.TU.SERVIDOR

2. Abrir solo lo que Palworld necesita de verdad

Bastan dos aperturas, y la segunda es opcional. 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 8211/udp comment 'Palworld tráfico de juego'
ufw allow 27015/udp comment 'Palworld consulta de Steam'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

La tercera línea la dejas fuera si tu servidor no tiene que aparecer en la lista de servidores de la comunidad. Tus jugadores seguirán conectándose por dirección IP y puerto 8211, el servidor solo desaparece de la lista pública. La guía completa, con vía de rescate incluida, está en Configurar el firewall UFW sin quedarte fuera del servidor.

3. Sacar de internet RCON en 25575 y la REST API en 8212

Los dos puertos son accesos de administración con control total sobre el servidor, y los dos vienen desactivados de fábrica: RCONEnabled=False y RESTAPIEnabled=False. Quien los active debería saber qué está publicando con ello.

La REST API en 8212 TCP autentica mediante HTTP Basic Auth con el nombre de usuario fijo admin y el valor de AdminPassword, y lo hace sobre HTTP sin cifrar. La contraseña de administración viaja así por la línea en forma reversible en cada petición. RCON en 25575 TCP es un protocolo de texto igual de poco cifrado, y Pocketpair lo ha marcado como obsoleto en favor de la REST API. Para instalaciones nuevas la elección correcta es la REST API, y para las dos vale la misma regla: no van en la red abierta.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="un valor largo y aleatorio"

La interfaz la haces accesible mediante una redirección de puerto por SSH, y después trabajas en local contra 127.0.0.1:8212:

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

No dejes nunca AdminPassword vacío, porque vacío es el valor por defecto. Un valor sacado de openssl rand -base64 32 basta. Lo mismo vale para ServerPassword, y sobre eso hay más enseguida.

4. Limitar el puerto de consulta 27015 sin perder la entrada en la lista

Los paquetes de Steam sin conexión empiezan con cuatro bytes puestos a uno (0xffffffff), mientras que el tráfico de juego normal no lleva esa cabecera. Sobre eso se puede poner un límite de tasa por dirección de origen que frena las consultas y conserva la entrada en la lista. Con nftables, cargado mediante nft -f:

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

La prioridad -10 hace que la regla actúe antes que la cadena de filtrado de UFW, y @th,64,32 lee los cuatro primeros bytes que vienen detrás de la cabecera UDP. Con iptables clásico, la misma separación se consigue comparando la firma de A2S_INFO:

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Diez consultas por segundo y dirección es un margen generoso: un servicio de listados pregunta normalmente cada pocos minutos, no varias veces por segundo. Lo único importante es que esta regla esté en 27015 y no en 8211, porque si no alcanzas a tus propios jugadores.

5. Limitar las tasas de paquetes en 8211 UDP

En el propio puerto de juego, un límite superior por dirección de origen ayuda contra las avalanchas pequeñas desde pocos orígenes. En Palworld ese límite es comparativamente poco peligroso de poner, porque como mucho hay 32 jugadores conectados a la vez y cada uno de ellos ocupa exactamente una dirección de origen:

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

La cifra es un punto de partida, no una verdad. Un servidor lleno con 32 jugadores y muchas bases genera bastantes más paquetes que una partida de cuatro, y quien ajusta demasiado fino echa fuera a sus propios jugadores. Mide primero una semana de funcionamiento normal y pon después el límite en el doble del valor punta medido.

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 además en /etc/ufw/before.rules, porque de lo contrario desaparecen con el siguiente ufw reload. Si una regla llega a alcanzarse o no lo muestra iptables -L INPUT -n -v: si los contadores de aciertos se quedan a cero, no actúa.

6. Contraseña del servidor, lista de baneos y las 32 plazas contra el agotamiento de slots

El agotamiento de slots es el ataque más barato contra un servidor de Palworld y no necesita ancho de banda. Un servidor dedicado tiene como mucho 32 plazas, así que bastan 32 conexiones simultáneas para dejar fuera a toda la comunidad. Un ataque volumétrico le cuesta dinero a quien lo encarga, 32 sesiones no le cuestan nada. Eso hace que esta vía resulte más atractiva para los servidores pequeños que cualquier avalancha.

Palworld no tiene whitelist integrada. Sus herramientas de moderación son el kick, el baneo y una contraseña de servidor, y justamente la contraseña de servidor es la medida individual más eficaz contra el agotamiento de slots:

ServerPassword="un valor que solo conozca tu grupo"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword viene vacío de fábrica, así que entra cualquiera que tenga dirección IP y puerto. BanListURL apunta por defecto a la lista que mantiene Pocketpair y se puede redirigir a un archivo de texto propio si quieres llevar bloqueos del proyecto. ServerPlayerMaxNum no lo pongas por encima de 32: los valores más altos no están soportados y te pasan factura como muy tarde en la siguiente actualización. Y algo tiene que quedar claro: una contraseña de servidor protege tus plazas, no tu línea. Un atacante que inunda tu servidor no quiere entrar.

7. Aliviar el seguimiento de conexiones y ampliar los búferes

Este punto explica caídas que parecen un ataque volumétrico y no lo son. El kernel crea entradas en el seguimiento de conexiones (conntrack) también 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 registro aparece "nf_conntrack: table full". El estado y el límite los muestra:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

El paso más eficaz es no dejar que el tráfico de juego se siga siquiera, porque Palworld gestiona sus sesiones por su cuenta:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

Con iptables, el equivalente es iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK y la misma línea para OUTPUT con --sport. Después, los puertos necesitan una apertura explícita, porque sin seguimiento ya no actúa ninguna regla que compruebe un estado existente. Si los paquetes llegan más rápido de lo que el proceso del servidor 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. Un añadido bajo /etc/sysctl.d/, activado con sysctl -p:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Si esos valores hacen falta te lo dice el propio kernel: si UdpRcvbufErrors sube en nstat -az, entonces sirven. Si el contador se queda a cero, el ajuste no cambia nada.

8. Recoger 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 tarde. 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
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 -c 200 "udp port 8211 or udp port 27015"

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. Palworld aporta además una magnitud de medición que ninguna otra herramienta tiene. Si la REST API está activada, el endpoint de métricas devuelve, entre otras cosas, la tasa de fotogramas del servidor, el número actual de jugadores y el tiempo de ejecución:

curl -s -u admin:TU_PASSWORD_ADMIN http://127.0.0.1:8212/v1/api/metrics

Esa única cifra separa limpiamente las dos causas más frecuentes. Si la tasa de fotogramas del servidor se hunde mientras las tasas de paquetes siguen sin llamar la atención, no es un ataque, sino carga o el conocido crecimiento de memoria del proceso del servidor. Si la tasa de fotogramas se mantiene estable mientras los paquetes de entrada suben muy por encima del valor normal, es un ataque. Cómo interpretar los valores de red en detalle lo explica Detectar un ataque DDoS.

Dónde se acaban estas medidas: 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, o sea, 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 normalmente entre 5 y 50 Gbit/s, es decir, entre cinco y cincuenta veces tu línea. Que tu regla de iptables por detrás sea buena o no ya da igual, 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 dejar tu servidor fuera de combate 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", y en Palworld se manifiesta primero como picos de lag y solo después como corte de conexión.

En un servidor de Palworld se añade una proporción desfavorable. Un servidor lleno con 32 jugadores ocupa solo una fracción de una línea de 1 Gbit/s. El ataque no necesita por tanto ser grande para alcanzar un múltiplo del funcionamiento normal, y justo por eso aquí bastan ataques que en una plataforma grande no llamarían la atención.

Para hacerse una idea de las magnitudes que se dan de verdad: en servidores de KernelHost se han filtrado, entre otros, un ataque de más de 473,4 Gbit/s con más de 41,5 millones de paquetes por segundo contra un servidor de voz y un flood UDP de más de 112,2 Gbit/s contra un servidor de juego. Para eso no existe ningún ajuste local. Los ataques volumétricos tienen que terminar en la red que hay delante del servidor.

Lo que KernelHost pone frente a esos ataques

La protección permanente incluida en 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. Palworld está entre los juegos con perfil de protección propio; qué otros títulos y protocolos están cubiertos lo lista Protección DDoS para servidores de juego en tiempo real.

Advanced DDoS Protection para proyectos de Palworld 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, 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 Fráncfort, 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 8211 UDP y qué en 27015 UDP, sin tener que abrir un ticket para ello.
• Los cambios surten efecto en tiempo real, así que puedes reajustar durante un ataque en curso, por ejemplo limitar el puerto de consulta con más dureza de forma temporal y dejar el puerto de juego intacto.
• Perfil de protección adaptado al juego, tanto para Palworld como para aplicaciones propias en cualquier puerto TCP o UDP.

La Advanced DDoS Protection se dirige a servidores alojados en KernelHost. Quien tenga ahora mismo su proyecto de Palworld en otro sitio y esté bajo ataque continuo lo traslada a KernelHost, y entonces los dos niveles actúan desde el aprovisionamiento.

Los dos niveles, comparados

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

Errores frecuentes en servidores de Palworld y su solución

"He bloqueado 27015 y ahora el servidor ha desaparecido de la lista de la comunidad": ese es el comportamiento esperado, porque el puerto de consulta es el que sostiene la entrada en la lista. No lo bloquees en bloque, limita los paquetes sin conexión por dirección de origen como en el paso 4. Si de todas formas no necesitas la entrada en la lista, deja el puerto cerrado, quita -publiclobby y dale a tus jugadores la dirección IP y el puerto 8211 para la conexión directa.

"Cambié la dirección IP y dos horas después estaba otra vez fuera": el atacante ha sacado la dirección nueva de la misma fuente que la antigua. En Palworld es casi siempre una de tres vías: un jugador que ya tiene la dirección en su campo de conexión directa, un bot de Discord con indicador de estado que vuelve a publicarla, o un registro A antiguo en el DNS que apunta a la dirección anterior. Cambiar de dirección da tiempo, no es una solución.

"El servidor tiene picos de lag, pero la línea está tranquila": en Palworld eso es más a menudo carga que ataque. El proceso del servidor va ocupando cada vez más memoria a lo largo del tiempo de ejecución, por lo que un reinicio planificado forma parte del funcionamiento normal y no hay que entenderlo como un apaño. Comprueba la tasa de fotogramas del servidor mediante el endpoint de métricas y el consumo de memoria del proceso. Si sar -n DEV 1 10 no muestra nada llamativo, no era un ataque DDoS.

"Las 32 plazas están ocupadas, pero dentro del juego no se ve a nadie": eso es agotamiento de slots y golpea a la lógica del juego, no a la línea. Pon una ServerPassword, bloquea las cuentas llamativas mediante la lista de baneos y limita los paquetes por dirección de origen en 8211 UDP.

"La REST API estuvo unos días accesible desde fuera": entonces tu contraseña de administración está comprometida, porque HTTP Basic Auth sobre HTTP sin cifrar la transmite en forma reversible en cada petición. Cambia AdminPassword, cierra 8212 TCP hacia fuera y llega a la interfaz solo mediante una redirección de puerto por SSH.

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

"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 Palworld necesita exactamente un puerto abierto: 8211 UDP. El puerto de consulta 27015 UDP solo hace falta para la entrada en la lista de servidores de la comunidad.
• RCON en 25575 TCP y la REST API en 8212 TCP no van nunca en la red abierta, porque los dos transmiten sus credenciales sin cifrar. RCON está además marcado como obsoleto por Pocketpair.
• Como en Palworld el tráfico de juego y la consulta del servidor están en puertos separados, 27015 UDP se puede limitar con dureza sin tocar el tráfico de juego en curso en 8211 UDP.
• El servidor dedicado está limitado a 32 plazas, por eso el agotamiento de slots es el ataque más barato. Una ServerPassword puesta es la medida individual más eficaz contra ello, porque Palworld no tiene whitelist integrada.
• Las medidas locales se 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 esté por encima tiene que terminar en la red que hay delante del servidor.
• En KernelHost, la protección permanente en dos niveles está incluida en cada paquete de servidor sin recargo y activa desde el aprovisionamiento, sin null-routing. La Advanced DDoS Protection con IP de protección dedicada y reglas autogestionables por puerto parte de 50,00 € al mes.

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