Proteger o servidor Palworld contra ataques DDoS

Um servidor Palworld que, à noite e a meio da partida, expulsa todos os jogadores ao mesmo tempo, fica offline durante alguns minutos e depois volta a estar acessível por si próprio, raramente tem um problema de hardware. Na maioria dos casos está a decorrer um ataque. Este artigo mostra como proteger um servidor Palworld contra ataques DDoS: primeiro aquilo que pode configurar por conta própria e sem custos adicionais, depois o ponto em que estas medidas terminam do ponto de vista técnico e, por fim, o que tem de acontecer na rede à frente do servidor para que este se mantenha acessível.

Todas as indicações se referem ao servidor dedicado oficial da Pocketpair (App ID da Steam 2394010) em Debian 12, Debian 13, Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS. Os comandos estão escritos para root; como utilizador normal, anteponha sudo. Se o ataque estiver a decorrer neste momento, vale uma ordem: primeiro medir, só depois alterar. Um reinício forçado sob carga descarta tudo o que aconteceu no mundo desde o último ponto de gravação automático, e os valores medidos do incidente desaparecem igualmente.

Porque é que os servidores Palworld são paralisados de forma dirigida com ataques DDoS

Um servidor Palworld é um público pequeno e fixo num endereço fixo. O servidor dedicado está limitado a 32 jogadores, valor controlado por ServerPlayerMaxNum com o intervalo válido de 1 a 32. Quem, em vez disso, aloja a partida a partir do menu do jogo fica por quatro jogadores, e apenas enquanto o próprio anfitrião estiver online. Destes 32 lugares decorre tudo o resto: o grupo joga a horas fixas ao final do dia, conhece-se entre si, e uma falha às 20 horas não atinge uma parte dos jogadores, atinge todos.

O endereço do servidor não é, nisto, segredo nenhum. O Palworld não conhece qualquer intermediação através de um serviço do fabricante: os jogadores escrevem o endereço IP e a porta no campo de ligação direta, e quem quiser ter o servidor também na lista de servidores da comunidade inicia-o com -publiclobby e deixa a porta de query responder. Qualquer pessoa que se tenha ligado uma vez conhece, assim, o alvo. Um serviço de booter que dispare contra esse endereço por alguns euros por mês não exige de quem o contrata nem competência nem esforço.

Do lado técnico acresce que todo o tráfego de jogo corre sobre UDP. O UDP não tem um estabelecimento de ligação que se possa exigir e o endereço de origem de um pacote UDP falsifica-se com facilidade. Um atacante não precisa, portanto, de entrar no servidor nem de o contactar corretamente para lhe gerar carga. O que acontece tecnicamente num ataque destes é explicado no artigo O que é um ataque DDoS?.

As portas que realmente contam num servidor Palworld

Um servidor Palworld precisa exatamente de uma porta aberta: 8211 UDP. Tudo o resto é opcional e, consoante a função, até prejudicial quando está exposto na internet. Daqui decorre uma distinção útil: um ataque DDoS à porta 8211 atinge sempre o próprio tráfego de jogo, ao passo que um ataque à porta 27015 UDP atinge apenas a entrada na lista de servidores.

Todos os respetivos parâmetros estão num único ficheiro: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, em Windows o correspondente Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. Começa pela linha de secção [/Script/Pal.PalGameWorldSettings], à qual se segue uma única linha OptionSettings=(...) que contém todas as definições sob a forma de lista. Uma quebra de linha dentro do parêntesis torna toda a configuração inválida e o servidor regressa aos valores por omissão sem dar qualquer aviso. O modelo DefaultPalWorldSettings.ini no diretório do servidor não se edita, porque é substituído em cada atualização.

O servidor Palworld em números

Os valores seguintes são a base de qualquer decisão sobre regras de filtragem e limites.

Porque é que a porta de query 27015 é o ponto mais sensível

A porta de query responde a pedidos de estado no formato A2S da Steam, ou seja, exatamente a mesma consulta que servem também os servidores de Counter-Strike e de ARK. Um pedido A2S_INFO é um pacote UDP sem ligação, de algumas dezenas de bytes, e a resposta com o nome do servidor, o mundo, o número de jogadores e o estado do jogo é um múltiplo disso. Como no UDP o endereço de origem se deixa falsificar, um atacante pode dirigir-se a portas de query alheias e encaminhar as respostas maiores para o seu verdadeiro alvo. Nesse caso o seu servidor não é a vítima, é o amplificador, e é a ligação dele que paga a conta.

Por isso, a Valve acrescentou ao A2S_INFO, em 8 de dezembro de 2020, um desafio prévio: o servidor responde primeiro com S2C_CHALLENGE, quem faz o pedido tem de devolver o token e prova assim que não está a falsificar o seu endereço de origem. Isso atenua a amplificação, mas não a termina, e contra uma simples enxurrada de consultas iguais a partir de endereços reais não produz efeito nenhum.

Para o Palworld resulta daqui uma vantagem importante face à Source Engine: o tráfego de jogo e a consulta ao servidor estão em portas separadas. No Counter-Strike 2, ambos partilham a porta 27015, e ali uma limitação de taxa grosseira expulsa também os próprios jogadores. No Palworld pode limitar a 27015 UDP de forma dura ou fechá-la por completo, sem tocar num único tráfego de jogo em curso na 8211 UDP. Quem não precisa da entrada na lista retira -publiclobby e a porta de query sem substituição, e tira assim uma superfície de ataque inteira da rede.

O que pode fazer por conta própria antes de gastar dinheiro

Os passos seguintes não travam um ataque volumétrico, isso nenhum software no servidor consegue fazer. Mas limpam tudo o que está abaixo disso: scans de portas, enxurradas de consultas, tentativas de tomada de controlo pelas portas de administração e a ocupação dos 32 lugares por estranhos. É a maior parte daquilo que perturba um servidor Palworld no dia a dia, e custa meia hora.

1. Levantamento: o que é que está à escuta no servidor?

Antes de escrever uma única regra, veja o que o seu servidor oferece para o exterior. Não adivinhe, verifique:

ss -lntup

A coluna interessante é a do endereço local. 0.0.0.0:8211 significa "acessível a partir de toda a internet", 127.0.0.1:8212 significa "apenas local" e não precisa de regra de firewall. Além do processo do jogo, num servidor que foi crescendo aparecem ali muitas vezes ainda um painel de administração, um servidor web para a visualização do mapa e uma base de dados. A perspetiva do atacante obtém-se com um scan de portas a partir de fora:

nmap -Pn -sU -p 8211,27015 IP.DO.SEU.SERVIDOR
nmap -Pn -p- --min-rate 1000 IP.DO.SEU.SERVIDOR

2. Abrir apenas o que o Palworld precisa mesmo

Bastam duas aberturas, e a segunda é opcional. Com o UFW isso fica assim, e exatamente por esta ordem, para que não se tranque a si próprio fora do servidor:

ufw allow 22/tcp comment 'SSH'
ufw allow 8211/udp comment 'Palworld tráfego de jogo'
ufw allow 27015/udp comment 'Palworld consulta Steam'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

A terceira linha fica de fora se o seu servidor não tiver de constar da lista de servidores da comunidade. Os seus jogadores continuam a ligar-se através do endereço IP e da porta 8211, o servidor limita-se a desaparecer da lista pública. As instruções completas, incluindo o caminho de recuperação, encontram-se em Configurar a firewall UFW sem se trancar fora do servidor.

3. Tirar o RCON na 25575 e a REST API na 8212 da internet

Ambas as portas são acessos de administração com controlo total sobre o servidor, e ambas vêm desligadas de origem: RCONEnabled=False e RESTAPIEnabled=False. Quem as liga deve saber o que está a publicar com isso.

A REST API na 8212 TCP autentica através de HTTP Basic Auth com o nome de utilizador fixo admin e o valor de AdminPassword, e fá-lo sobre HTTP não cifrado. A palavra-passe de administração corre assim pela linha, em forma reversível, a cada pedido individual. O RCON na 25575 TCP é um protocolo de texto igualmente não cifrado, e a Pocketpair marcou-o como obsoleto a favor da REST API. Para instalações novas, a REST API é a escolha certa; para ambas vale a mesma regra: fora da rede aberta.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="um valor longo e aleatório"

Torne a interface acessível através de um reencaminhamento de porta por SSH e trabalhe depois localmente contra 127.0.0.1:8212:

ssh -N -L 8212:127.0.0.1:8212 root@IP.DO.SEU.SERVIDOR

Nunca deixe AdminPassword vazio, porque vazio é a predefinição. Um valor de openssl rand -base64 32 chega. O mesmo vale para ServerPassword, e já lá vamos.

4. Limitar a porta de query 27015 sem perder a entrada na lista

Os pacotes Steam sem ligação começam com quatro bytes com todos os bits a um (0xffffffff), o tráfego de jogo normal não tem esse cabeçalho. Sobre isso pode assentar uma limitação de taxa por endereço de origem que trava as consultas e mantém a entrada na lista. Com nftables, carregado através de 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
    }
}

A prioridade -10 faz com que a regra atue antes da cadeia de filtragem do UFW, e @th,64,32 lê os primeiros quatro bytes a seguir ao cabeçalho UDP. Com o iptables clássico, a mesma separação consegue-se com uma comparação sobre a assinatura do 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

Dez consultas por segundo e por endereço é uma medida generosa: um serviço de listagem consulta habitualmente de poucos em poucos minutos, não várias vezes por segundo. Importante é apenas que esta regra esteja sobre a 27015 e não sobre a 8211, caso contrário atinge os seus próprios jogadores.

5. Limitar as taxas de pacotes na 8211 UDP

Na própria porta de jogo, um limite máximo por endereço de origem ajuda contra pequenas enxurradas vindas de poucas origens. No Palworld esse limite é comparativamente pouco arriscado de definir, porque estão ligados no máximo 32 jogadores e cada um deles ocupa exatamente um endereço de origem:

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

O número é um valor de partida, não uma verdade absoluta. Um servidor cheio com 32 jogadores e muitas bases gera bastante mais pacotes do que uma partida a quatro, e quem aperta demasiado acaba por expulsar os seus próprios jogadores. Meça primeiro durante uma semana em funcionamento normal e só depois coloque o limite no dobro do valor de pico medido.

As regras puras de iptables desaparecem depois de um reinício. No Debian e no Ubuntu guardam-se assim:

apt-get install -y iptables-persistent
netfilter-persistent save

Com o UFW, regras destas pertencem além disso ao /etc/ufw/before.rules, porque de outra forma desaparecem no ufw reload seguinte. Se uma regra chega sequer a ser alcançada é o que mostra iptables -L INPUT -n -v: se os contadores de correspondências ficarem a zero, a regra não está a atuar.

6. Palavra-passe do servidor, lista de banidos e os 32 lugares contra o esgotamento de slots

O esgotamento de slots é o ataque mais barato contra um servidor Palworld e não precisa de largura de banda. Um servidor dedicado tem no máximo 32 lugares, portanto bastam 32 ligações em simultâneo para deixar toda a comunidade de fora. Um ataque volumétrico custa dinheiro a quem o encomenda, 32 sessões não lhe custam nada. Isso torna este caminho mais atrativo para servidores pequenos do que qualquer enxurrada.

O Palworld não tem whitelist integrada. As ferramentas de moderação são o kick, o banimento e uma palavra-passe de servidor, e é precisamente a palavra-passe de servidor que é a medida isolada mais eficaz contra o esgotamento de slots:

ServerPassword="um valor que só o seu grupo conhece"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword vem vazio de origem, portanto qualquer pessoa com endereço IP e porta entra. BanListURL aponta por predefinição para a lista mantida pela Pocketpair e pode ser desviada para um ficheiro de texto próprio, se quiser manter bloqueios do seu projeto. ServerPlayerMaxNum não deve ser colocado acima de 32: valores mais altos não são suportados e acabam por sair caro, o mais tardar na atualização seguinte. E uma coisa tem de ficar clara: uma palavra-passe de servidor protege os seus lugares, não a sua linha. Um atacante que inunda o seu servidor nem sequer quer entrar.

7. Aliviar o seguimento de ligações e aumentar os buffers

Este ponto explica falhas que parecem um ataque de volume mas não são. O kernel cria entradas no seguimento de ligações (conntrack) também para o tráfego UDP, e com endereços de origem falsificados cada endereço significa uma entrada nova. Se a tabela encher, o kernel descarta pacotes sem distinção, o ataque e os seus jogadores saem juntos e no registo aparece "nf_conntrack: table full". O estado atual e o limite máximo são mostrados por:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

O passo mais eficaz é não deixar sequer que o tráfego de jogo seja seguido, porque o Palworld gere as suas sessões por si próprio:

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

Com iptables, o equivalente é iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK e a mesma linha para OUTPUT com --sport. As portas precisam depois de uma abertura expressa, porque sem seguimento deixa de atuar qualquer regra que verifique um estado existente. Se os pacotes chegarem mais depressa do que o processo do servidor os levanta, transborda ainda o buffer de receção. Para os jogadores isso parece perda de pacotes, apesar de a linha estar livre. Um acrescento em /etc/sysctl.d/, ativado com sysctl -p:

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

Se os valores são necessários é o próprio kernel que o revela: se UdpRcvbufErrors subir em nstat -az, então fazem efeito. Se o contador ficar a zero, o ajuste não muda nada.

8. Recolher valores medidos antes de a coisa ficar séria

O passo mais importante é aquele que quase ninguém dá com antecedência: criar uma base de comparação enquanto tudo funciona normalmente. Sem um valor normal, depois de um incidente não consegue dizer se 40 000 pacotes por segundo foram muito ou se era simplesmente um sábado à noite. Com apt-get install -y vnstat sysstat, a medição fica sempre a correr. Durante um incidente bastam quatro 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"

Quanto ao tcpdump vale a regra: limitar sempre com -c, porque uma captura a plena carga sobrecarrega ainda mais um servidor que já está sobrecarregado. O Palworld fornece adicionalmente uma grandeza de medição que nenhuma outra ferramenta tem. Com a REST API ativada, o endpoint de métricas devolve, entre outras coisas, a taxa de imagens do servidor, o número atual de jogadores e o tempo de funcionamento:

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

Este único número separa com clareza as duas causas mais frequentes. Se a taxa de imagens do servidor cair enquanto as taxas de pacotes se mantêm sem nada de especial, não é um ataque, é carga ou o conhecido aumento de memória do processo do servidor. Se a taxa de imagens se mantiver estável enquanto os pacotes de entrada sobem muito acima do valor normal, é um ataque. Como avaliar em detalhe os valores de rede está em Detetar um ataque DDoS no servidor.

Onde estas medidas deixam de chegar: largura de banda e taxa de pacotes

Agora a parte que nenhum ficheiro de configuração resolve. Todas as medidas anteriores correm no seu servidor, ou seja, no fim da linha. Uma regra de firewall decide sobre um pacote que já passou pelo cabo. Pode descartá-lo, mas não pode fazer com que ele não tenha sido enviado.

Faça as contas connosco. Um gameserver típico está ligado a 1 Gbit/s, o que corresponde a 125 megabytes por segundo, e a linha fica cheia assim que alguém enviar mais do que isso. Os ataques contra projetos de gameservers situam-se habitualmente entre 5 e 50 Gbit/s, ou seja, entre cinco e cinquenta vezes a sua linha. Nessa altura já não interessa se a sua regra de iptables por trás é boa, porque os pacotes dos seus jogadores nem chegam a passar.

A segunda grandeza é a taxa de pacotes, e muitas vezes ela chega ao limite antes da largura de banda. Com pacotes pequenos de 64 bytes cabem numa linha de 1 Gbit/s cerca de 1,49 milhões de pacotes por segundo. Um kernel de servidor normal processa, consoante o processador e a placa de rede, algumas centenas de milhares deles antes de começar a descartar. Um ataque que nem sequer enche um terço da sua linha pode, ainda assim, deixar o seu servidor inoperacional, porque o tempo de processamento se gasta a descartar. Quem opera servidores vive isto como "a utilização nem sequer estava alta e mesmo assim desapareceu tudo", e no Palworld manifesta-se primeiro como picos de lag e só depois como quebra de ligação.

Num servidor Palworld acresce uma relação desfavorável. Um servidor completamente cheio com 32 jogadores ocupa apenas uma fração de uma linha de 1 Gbit/s. O ataque não precisa, portanto, de ser grande para atingir um múltiplo do funcionamento normal, e é exatamente por isso que aqui já chegam ataques que numa plataforma grande não dariam nas vistas.

Para dar uma ideia das ordens de grandeza que ocorrem na realidade: em servidores da KernelHost foram filtrados, entre outros, um ataque com mais de 473,4 Gbit/s e mais de 41,5 milhões de pacotes por segundo contra um servidor de voz, e um flood UDP com mais de 112,2 Gbit/s contra um gameserver. Para isso não existe nenhuma definição local. Os ataques volumétricos têm de terminar na rede à frente do servidor.

O que a KernelHost põe do outro lado

A proteção permanente que está incluída em cada pacote de servidor

A proteção DDoS da KernelHost está construída em dois níveis e permanentemente ativa, sem que tenha de ativar, encomendar ou configurar seja o que for:

• Nível 1: 17 Tbps de capacidade de mitigação na rede global de scrubbing. Os ataques volumétricos são limpos perto da sua origem, antes de chegarem ao datacenter.
• Nível 2: filtragem Arbor em tempo real com 3,2 Tbps em Frankfurt am Main. Mesmo à frente do servidor são reconhecidos e descartados os padrões específicos de cada protocolo, pacote a pacote.

Duas características são decisivas. A proteção corre em permanência e não precisa de reagir primeiro a um ataque, pelo que não existem aqueles minutos iniciais em que o servidor desaparece. E não é usado null-routing: o seu endereço IP mantém-se na rede e só os pacotes nocivos são descartados. Quem retira o endereço IP da rede consegue, para si, o mesmo resultado que o atacante. O Palworld é um dos jogos com perfil de proteção próprio; que outros títulos e protocolos estão cobertos é o que lista Proteção DDoS em tempo real para servidores de jogos.

Advanced DDoS Protection para projetos Palworld sob fogo permanente

Alguns projetos não são atacados de forma ocasional, mas sim de forma dirigida e ao longo de semanas. Para esses existe a Advanced DDoS Protection a partir de 50,00 EUR por mês, PrePaid, sem prazo mínimo e sem taxa de instalação. A diferença não está em mais capacidade, mas sim no controlo:

• IP de proteção dedicado a partir do núcleo de Frankfurt, para o qual o seu servidor é comutado dentro da nossa própria rede. Do seu lado não é preciso qualquer alteração.
• Regras de proteção autogeríveis por porta e por protocolo na área de cliente: define em separado o que é permitido na 8211 UDP e o que é permitido na 27015 UDP, sem ter de escrever um ticket para isso.
• As alterações entram em vigor em tempo real, pelo que pode afinar durante um ataque em curso, por exemplo limitar temporariamente a porta de query de forma mais dura e deixar a porta de jogo intocada.
• Perfil de proteção adequado ao jogo, tanto para o Palworld como para aplicações próprias em quaisquer portas TCP ou UDP.

A Advanced DDoS Protection dirige-se a servidores que estão alojados na KernelHost. Quem tiver o seu projeto de Palworld noutro sítio e estiver a ser atacado de forma permanente transfere-o para a KernelHost, e a partir da disponibilização atuam ambos os níveis.

Os dois níveis em comparação

Para a maioria dos servidores Palworld, a proteção permanente incluída chega, em conjunto com uma configuração de servidor limpa. A Advanced DDoS Protection é a resposta para quando alguém leva a coisa a peito.

Erros frequentes em servidores Palworld e respetivas soluções

"Bloqueei a 27015 e agora o servidor desapareceu da lista da comunidade": este é o comportamento esperado, porque é a porta de query que sustenta a entrada na lista. Não a bloqueie de forma geral, limite antes os pacotes sem ligação por endereço de origem, como no passo 4. Se, de qualquer forma, não precisar da entrada na lista, deixe a porta fechada, retire -publiclobby e dê aos seus jogadores o endereço IP e a porta 8211 para a ligação direta.

"Mudei de endereço IP e duas horas depois estava outra vez offline": o atacante obteve o endereço novo a partir da mesma fonte que o antigo. No Palworld é quase sempre um de três caminhos: um jogador que já tem o endereço no campo de ligação direta, um bot do Discord com indicação de estado que o volta a publicar, ou um registo A antigo no DNS a apontar para o endereço anterior. Mudar de endereço é ganhar tempo, não é uma solução.

"O servidor tem picos de lag, mas a linha está calma": no Palworld isso é mais vezes carga do que ataque. O processo do servidor ocupa cada vez mais memória ao longo do tempo de funcionamento, razão pela qual um reinício planeado faz parte do funcionamento normal e não deve ser entendido como remendo. Verifique a taxa de imagens do servidor através do endpoint de métricas e o consumo de memória do processo. Se sar -n DEV 1 10 não mostrar nada de especial, não foi um ataque DDoS.

"Os 32 lugares estão todos ocupados, mas dentro do jogo não se vê ninguém": isso é esgotamento de slots e atinge a lógica de jogo, não a linha. Defina uma ServerPassword, bloqueie as contas suspeitas através da lista de banidos e limite os pacotes por endereço de origem na 8211 UDP.

"A REST API esteve acessível a partir do exterior durante alguns dias": então a sua palavra-passe de administração está comprometida, porque o HTTP Basic Auth sobre HTTP não cifrado transmite-a em forma reversível a cada pedido. Altere AdminPassword, feche a 8212 TCP para o exterior e aceda à interface apenas através de um reencaminhamento de porta por SSH.

"As minhas regras de iptables não fazem efeito": há três causas frequentes. As regras estão atrás das cadeias do UFW e nunca chegam a ser alcançadas; desapareceram no último reinício (nesse caso ajudam o netfilter-persistent save ou uma entrada em /etc/ufw/before.rules); ou o ataque é volumétrico e a regra trabalha corretamente numa linha que já está cheia. Verifique com iptables -L INPUT -n -v se os contadores de correspondências sobem.

"O meu fornecedor anterior bloqueou o meu endereço IP": isso é null-routing. Com isso o fornecedor protege a sua própria rede; para si, o resultado é idêntico ao de um ataque bem-sucedido, normalmente ainda durante horas depois. Na dúvida, pergunte se filtram ou se aplicam null-routing. A resposta decide mais sobre a sua disponibilidade do que qualquer indicação de hardware.

"No tcpdump não vejo nada de especial": se o tráfego já é filtrado na rede à frente, é natural que nada chegue ao servidor. Esse é o caso normal quando a filtragem funciona. O inverso também é verdade: se a linha estiver saturada, é possível que nem sequer consiga estabelecer a sessão SSH com que queria medir. Nesse caso utilize a consola VNC na área de cliente, que funciona independentemente da rede do sistema convidado.

Em resumo

• Um servidor Palworld precisa exatamente de uma porta aberta: 8211 UDP. A porta de query 27015 UDP só é necessária para a entrada na lista de servidores da comunidade.
• O RCON na 25575 TCP e a REST API na 8212 TCP nunca pertencem à rede aberta, porque ambos transmitem as suas credenciais sem cifragem. O RCON está adicionalmente marcado pela Pocketpair como obsoleto.
• Como no Palworld o tráfego de jogo e a consulta ao servidor estão em portas separadas, a 27015 UDP pode ser limitada de forma dura sem tocar no tráfego de jogo em curso na 8211 UDP.
• O servidor dedicado está limitado a 32 lugares, e por isso o esgotamento de slots é o ataque mais barato. Uma ServerPassword definida é a medida isolada mais eficaz contra isso, porque o Palworld não tem whitelist integrada.
• As medidas locais terminam na linha: 1 Gbit/s são 125 megabytes por segundo, e com pacotes de 64 bytes cabem ali cerca de 1,49 milhões de pacotes por segundo. Tudo acima disso tem de terminar na rede à frente do servidor.
• Na KernelHost, a proteção permanente em dois níveis está incluída em cada pacote de servidor sem sobretaxa e ativa a partir da disponibilização, sem null-routing. A Advanced DDoS Protection com IP de proteção dedicado e regras autogeríveis por porta começa em 50,00 EUR por mês.

Se o seu servidor Palworld já estiver alojado na KernelHost, a filtragem está ativa sem que tenha de fazer o que quer que seja. Se, ainda assim, notar anomalias, abra um ticket de suporte, para que as regras de filtragem sejam afinadas para o seu endereço IP. Durante um ataque em curso pode ainda falar connosco pelo chat de emergência do WhatsApp, através do +43 650 8209883.