Proteger um servidor Minecraft Bedrock contra ataques DDoS

Um servidor Minecraft Bedrock que, à noite, desaparece durante alguns minutos da lista de servidores e depois volta, raramente tem um problema de hardware. Na maioria dos casos está a decorrer um ataque, e ele decorre precisamente quando há mais jogadores online. Este artigo mostra como proteger um servidor Minecraft Bedrock contra ataques DDoS: primeiro aquilo que pode proteger por conta própria e sem custos adicionais, depois o ponto em que estas medidas terminam do ponto de vista físico e, por fim, o que tem de acontecer na rede à frente do servidor.

Todas as indicações se referem a um Bedrock Dedicated Server, ao PocketMine-MP ou ao Nukkit 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. Quem gere a Java Edition encontra os ataques de protocolo típicos dessa versão em Proteção DDoS para Minecraft e proteção Nullping. A simples instalação de um servidor Bedrock está descrita em Instalar um servidor Minecraft Bedrock com Nukkit.

Se o ataque estiver a decorrer neste momento: não altere agora nada na configuração e não reinicie o servidor. Guarde primeiro os valores medidos (secção "Recolher valores medidos antes de rebentar"), porque depois do ataque desaparecem de forma irrecuperável.

Porque é que os servidores Minecraft Bedrock são tão frequentemente alvo de ataques DDoS

A Bedrock Edition é a versão que corre em consolas, smartphones, tablets e Windows, e representa a maior base de jogadores do Minecraft de todas. Onde há muitos servidores nasce o maior incentivo para atacar: redes concorrentes, jogadores banidos, conflitos internos. Um ataque não custa a quem o desencadeia nem competência nem dinheiro digno de nota, e um server booter vende-se por subscrição.

A razão técnica está mais fundo. Um servidor Bedrock fala UDP, não TCP, e responde a toda a gente que pergunta, muito antes de ter havido qualquer autenticação. São precisamente estas duas características que fazem da porta 19132 UDP um alvo agradecido. O que é, no fundo, um ataque DDoS fica explicado no artigo O que é um ataque DDoS?.

RakNet: um protocolo UDP que responde antes de alguém se ter autenticado

O RakNet é a biblioteca de rede UDP através da qual a Minecraft Bedrock Edition trata todo o seu tráfego de jogo. O UDP não tem um estabelecimento de ligação que um servidor pudesse exigir, e por isso os endereços de origem falsificam-se com facilidade. O RakNet constrói por cima a sua própria camada de fiabilidade: números de sequência, confirmações (ACK) e confirmações negativas (NAK), com as quais um cliente pode voltar a pedir pacotes perdidos.

O estabelecimento da ligação é feito de sete pacotes, quatro do cliente e três do 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

Só depois disso é que o cliente envia o pacote de login com as suas credenciais Xbox Live. Esta é a frase decisiva para quem quer proteger o seu servidor Bedrock: o servidor processou sete pacotes, gastou tempo de processamento e memória e respondeu várias vezes, antes sequer de ficar a saber quem está a bater à porta. Qualquer medida que atue ao nível da autenticação só age, portanto, depois de a carga já ter sido criada.

A isto junta-se um segundo ponto de entrada, ainda mais precoce. Para que um servidor apareça na lista de servidores de um jogador com nome, versão e número de jogadores, ele responde ao Unconnected Ping (ID de pacote 0x01) com um Unconnected Pong (ID de pacote 0x1C). Esta troca acontece antes do próprio estabelecimento da ligação, não exige prova nenhuma e não se consegue desligar no Bedrock Dedicated Server sem tirar o servidor de todas as listas de servidores.

O Unconnected Ping como vetor de amplificação: os números

Um ataque de amplificação é um ataque em que o atacante envia pedidos pequenos com o endereço de origem falsificado a servidores alheios, para que as respostas maiores destes aterrem na vítima. O servidor Bedrock não está a ser atacado, está a ser usado. No caso do Unconnected Ping, as contas são estas:

Daqui decorrem imediatamente duas coisas. Primeira: um nome de servidor comprido aumenta a resposta e, com ela, o fator de amplificação que coloca à disposição de atacantes alheios. Um nome curto não é cosmética, é uma medida de proteção. Segunda: o fator 4 da configuração padrão é pequeno o suficiente para o seu servidor continuar a ser pouco interessante como refletor, mas grande o suficiente para que uma enxurrada de pings carregue a sua própria linha de saída com o quádruplo daquilo que entra.

A falha de amplificação de 2024 mostra como as coisas podem ficar feias quando é a própria camada de fiabilidade a ser abusada. Na biblioteca RakNet então utilizada, o pacote Connection Request Accepted estava marcado como fiável. Um atacante conseguia percorrer o estabelecimento da ligação com endereço de origem falsificado até esse ponto e enviar a seguir uma única confirmação negativa com o intervalo de 0 a 8191. O servidor passava então a enviar milhares de pacotes para o endereço falsificado, sem que o atacante tivesse de fazer mais alguma coisa. A correção passou por colocar o pacote como não fiável, por enviar no Open Connection Reply 1 um cookie que um cliente verdadeiro devolve, e por introduzir limites de pacotes: 120 pacotes por endereço de origem e ciclo de 10 milissegundos, 1.000 pacotes no total por ciclo.

Bedrock Edition ou Java Edition: o que é diferente na proteção DDoS

Quem já protegeu um servidor Java transpõe quase tudo de forma errada. As duas edições partilham o nome, mas não o protocolo de rede:

A linha dos SYN cookies é a mais importante. Na Java Edition, o kernel do Linux trava uma enxurrada de SYN sem que o processo do Minecraft dê por nada. Na Bedrock Edition essa ajuda não existe: cada pacote UDP é encaminhado até ao processo do servidor e avaliado ali. Um servidor Bedrock não tem no sistema operativo qualquer proteção integrada contra um flood na porta 19132, porque o UDP não conhece nenhuma.

A linha do registo SRV em falta tem uma consequência prática que surpreende muita gente: na Bedrock Edition não consegue esconder a porta atrás de um registo DNS. Os jogadores introduzem endereço e porta à mão. Quem muda a porta tem de comunicar a porta nova a cada jogador.

As portas que realmente contam

Um Bedrock Dedicated Server liga-se a exatamente duas portas, e em ambas por UDP. No 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

Estas são as predefinições da Microsoft, consultáveis na referência do Bedrock Dedicated Server. À volta destas duas portas estão outros serviços que correm em paralelo consoante o software de servidor:

A terceira e a quarta linhas são os erros evitáveis mais frequentes em servidores Bedrock. No Nukkit e no PocketMine-MP, o enable-query vem de fábrica ligado, e no Nukkit um RCON ligado por descuido aterra na 19132 TCP, ou seja, no mesmo número de porta do jogo. Quem olha apenas para "a 19132 está aberta, está tudo bem" não repara nisso.

Uma particularidade do Bedrock Dedicated Server oficial pertence igualmente a este ponto: ele não conhece nenhuma diretiva server-ip. O PocketMine-MP e o Nukkit têm-na (server-ip, no PocketMine adicionalmente server-ipv6), o servidor oficial não. Ele escuta portanto sempre em todos os endereços do sistema, e a firewall é a sua única forma de restringir isso.

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

Esta secção é a mais longa, e isso é intencional. Um servidor Bedrock bem configurado aguenta ataques pequenos e médios pelos seus próprios meios, independentemente de onde esteja alojado.

1. Levantamento: o que é que está sequer à escuta na 19132?

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

ss -lntup
ss -lnup sport = :19132

A coluna interessante é a do endereço local. 0.0.0.0:19132 e [::]:19133 significam "acessível a partir de toda a internet". Se ao lado aparecer uma entrada TCP no mesmo número de porta, está a correr RCON. A perspetiva do atacante obtém-se com um scan de portas a partir de fora, para UDP com -sU:

nmap -Pn -sU -p 19132,19133 IP.DO.SEU.SERVIDOR
nmap -Pn -p- --min-rate 1000 IP.DO.SEU.SERVIDOR

2. Deixar aberta apenas a 19132 UDP e fechar tudo o resto

Para um servidor Bedrock basta uma única abertura para o exterior, duas com IPv6. 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 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

Se não tiver jogadores com IPv6, deixe de fora a linha da 19133 e coloque no PocketMine-MP adicionalmente enable-ipv6=false. Cada porta que não abre é uma porta que não tem de defender. As instruções completas, incluindo o caminho de recuperação, encontram-se em Configurar a firewall UFW sem se trancar fora do servidor.

3. Desligar a visibilidade na LAN, senão a 19132 continua aberta

Esta é a armadilha em que quase todos caem quando querem mudar a porta. A diretiva enable-lan-visibility vem de fábrica em true e faz com que o servidor responda a pedidos de procura na rede local. A Microsoft escreve a este respeito, de forma expressa, que o servidor passa assim a ligar-se adicionalmente às portas padrão 19132 e 19133, mesmo quando server-port e server-portv6 têm outros valores.

Quem muda portanto a porta para 19140 e se sente em segurança continua à escuta na 19132. Para um servidor na internet pertence por isso ao server.properties:

enable-lan-visibility=false

Depois confirme com ss -lnup que a 19132 desapareceu mesmo. De caminho, esta mesma definição resolve o problema de dois servidores Bedrock no mesmo anfitrião roubarem a porta um ao outro.

4. Desligar o query e o RCON

O PocketMine-MP e o Nukkit trazem o query GS4, uma consulta de servidor por UDP segundo o modelo do protocolo do UT3, e respondem a essas consultas na mesma porta 19132 em que corre o jogo. A resposta detalhada contém o nome do servidor, a versão, o nome do mundo, o estado da whitelist, endereço e porta, o número de jogadores, os nomes de todos os jogadores ligados e, no PocketMine-MP, a pedido, a lista completa de plugins. Isso é prático para páginas de estado e para bots do Discord, mas revela a um atacante exatamente quando vale a pena atacar, e custa tempo de processamento a cada consulta.

enable-query=off
enable-rcon=off

No PocketMine-MP os valores são false em vez de off, e a lista de plugins desliga-se no pocketmine.yml com settings.query-plugins: false. Uma avaliação que raramente se lê: o query GS4 do PocketMine-MP verifica um token ao qual o endereço de origem foi juntado como sal. A resposta grande não se consegue, portanto, refletir para um endereço falsificado. Ainda assim, a consulta custa tempo de processamento, e os dados publicados ajudam o atacante a escolher o alvo. O Bedrock Dedicated Server oficial não conhece nem query nem RCON, e aí este ponto não se aplica.

Se precisar mesmo de RCON, coloque obrigatoriamente no Nukkit o rcon.port num valor próprio e abra-o apenas para o seu próprio endereço. Caso contrário, a recaída sobre o server-port significa que um controlo remoto do seu servidor fica à escuta na 19132 TCP, ou seja, no mesmo número que já inscreveu por todo o lado como "aberto".

5. Impor a autenticação Xbox Live

A autenticação Xbox Live é a verificação de que um jogador que entra possui uma conta verdadeira e assinada pela Microsoft. Vem de fábrica ligada nos três softwares de servidor e também deve ficar assim.

No Bedrock Dedicated Server, a diretiva chama-se online-mode; no PocketMine-MP e no Nukkit chama-se xbox-auth. Nos dois casos, true é o estado de fábrica e o valor correto:

online-mode=true
xbox-auth=true

A Microsoft formula a este respeito uma limitação importante: os clientes que se ligam a um servidor fora da rede local precisam sempre da autenticação Xbox Live, independentemente desta definição. A prova é transmitida como cadeia de tokens assinada dentro do pacote de login, juntamente com a identificação Xbox (XUID) e o nome de apresentação.

E agora a parte que ajuda contra mal-entendidos: a autenticação Xbox Live protege a sua lógica de jogo, não a sua linha. Acontece no pacote de login, ou seja, depois do estabelecimento completo da ligação RakNet. Um atacante que inunda o seu servidor nem sequer quer entrar. Os pacotes dele são recusados, mas mesmo assim chegaram, e é precisamente esse o ponto.

6. Allowlist e limite de jogadores, e o que eles não conseguem fazer

A allowlist (antigamente whitelist) é a lista dos jogadores que podem entrar. No Bedrock Dedicated Server liga-a com allow-list=true, e as entradas ficam no allowlist.json com nome, XUID e o campo ignoresPlayerLimit. No Nukkit e no PocketMine-MP a diretiva continua a chamar-se white-list.

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

Um tempo de inatividade curto através de player-idle-timeout é eficaz contra o esgotamento dos lugares: os jogadores que apenas ocupam um lugar são expulsos ao fim do número de minutos indicado. O valor 0 significa que ninguém é alguma vez desligado por inatividade, e é precisamente isso que aproveita um atacante que bloqueia os seus lugares com contas verdadeiras.

Também aqui vale o limite da secção anterior, e é o ponto mais ignorado de todos: a allowlist só é verificada quando o pacote de login já foi processado. Ela impede entradas, não impede pacotes.

7. Limitar as taxas de pacotes por endereço de origem

Contra ataques pequenos e bots mal feitos ajuda um limite máximo por endereço de origem. Para UDP trabalha-se com hashlimit e não com connlimit, porque o UDP não conhece ligações:

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

A regra descarta pacotes UDP assim que o mesmo endereço de origem envia, de forma continuada, mais de 400 pacotes por segundo. O valor é um valor de partida, não uma verdade absoluta: um servidor cheio com 60 jogadores e grande distância de visão gera bastante mais pacotes do que um vazio, e quem aperta demasiado acaba por expulsar os seus próprios jogadores. Meça primeiro durante uma semana em funcionamento normal.

Pode apertar bastante mais no Unconnected Ping, porque um cliente verdadeiro só consulta o estado do servidor enquanto a lista de servidores está aberta, e aí ao ritmo de um por segundo. Com o nftables consegue atingir exatamente este pacote, porque o ID de pacote é o primeiro byte a seguir ao cabeçalho 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

A expressão @th,64,8 lê oito bits a partir do 64.º bit do cabeçalho de transporte, ou seja, o primeiro byte da carga útil UDP. O valor 0x01 é o ID de pacote do Unconnected Ping. Pode usar este mesmo ponto para observar, antes de descartar seja o que for:

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

A primeira linha conta as consultas de estado que entram, a segunda as suas próprias respostas. Se ambas subirem aos milhares ao ritmo de um segundo enquanto quase ninguém joga, está a ver uma enxurrada de pings e não os seus jogadores.

Duas notas sobre a durabilidade. 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

E com o UFW estas regras pertencem ao /etc/ufw/before.rules, porque de outra forma desaparecem no ufw reload seguinte.

8. Aliviar o seguimento de ligações do kernel

Um estrangulamento que, nos jogos por UDP, bate muito mais cedo do que no TCP: o kernel cria uma entrada no seguimento de ligações para cada par de pacotes UDP. Numa enxurrada com endereços de origem falsificados, cada pacote é um endereço de origem novo e, portanto, uma entrada nova. Se a tabela encher, o servidor passa a descartar também pacotes legítimos e no log aparece "nf_conntrack: table full, dropping packet".

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Se o contador estiver permanentemente perto do limite máximo, pode retirar o tráfego de jogo do seguimento. Isso é eficaz, mas não é inofensivo, por isso faça-o nos dois sentidos e com um teste de ligação a seguir:

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

A partir daí, as regras baseadas em estado deixam de se aplicar a esse tráfego. A sua abertura para a 19132 UDP tem portanto de ser uma abertura de porta verdadeira e não pode apoiar-se no estado ESTABLISHED. Depois de definir as regras, verifique com conntrack -L | grep 19132 que já não surgem entradas, e ligue-se uma vez com o jogo antes de guardar as regras de forma permanente.

9. Operar o Geyser e o Floodgate de forma limpa

O Geyser é uma ponte que permite a clientes Bedrock jogar num servidor de Java Edition: aceita ligações Bedrock na 19132 UDP, traduz o protocolo e fala do outro lado com o servidor Java na 25565 TCP. O Floodgate é o complemento que permite a esses jogadores Bedrock entrar sem conta Java. Para a proteção DDoS isso significa três coisas.

Primeira: mantenha o Geyser atualizado. Foi precisamente esta ponte a razão de ataques documentados por duas vezes. Em março de 2024, a falha de amplificação descrita acima na biblioteca RakNet foi explorada em larga escala, corrigida a partir da build 478. Em julho de 2025 seguiu-se um segundo caso: um pacote de confirmação dos pacotes de recursos, enviado repetidamente, criava várias sessões por jogador, e os clientes desligados podiam continuar a enviar pacotes porque o canal de rede não era fechado. Corrigido a partir da build 897. Os dois casos foram publicados pelo próprio projeto com a respetiva cronologia.

Segunda: o servidor Java não pertence à rede aberta. Na configuração do Geyser, o remote.address aponta para auto ou para 127.0.0.1 e o remote.port para 25565. Ligue o servidor Java localmente em conformidade e não abra a 25565 TCP para o exterior. Caso contrário tem duas superfícies de ataque em vez de uma, e a segunda é aquela para a qual nunca pensou em regras.

Terceira: o ficheiro key.pem é um segredo. É a chave com que o Floodgate salta a autenticação Java para contas Bedrock. Quem a coloca num repositório público, a copia para um ticket de suporte ou a mostra numa captura de ecrã ofereceu a autenticação do seu servidor. O projeto avisa disso de forma expressa.

10. Recolher valores medidos antes de rebentar

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 conntrack, a medição fica sempre a correr.

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

Três destes valores são particularmente reveladores num servidor Bedrock. Um Recv-Q permanentemente diferente de zero no socket UDP da 19132 significa que o processo do servidor já não recolhe os pacotes que chegam com rapidez suficiente. O UdpRcvbufErrors conta exatamente os pacotes que por isso foram descartados e é a prova mais dura de que o estrangulamento não é a linha, mas sim o processo. O UdpNoPorts sobe quando alguém dispara contra portas onde não está nada à escuta, uma imagem típica num scan de portas alargado antes do ataque propriamente dito.

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. Como interpretar os valores está em Detetar um ataque DDoS.

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. A sua linha fica cheia assim que alguém enviar mais do que 125 megabytes por segundo. Um ataque de 5 a 50 Gbit/s corresponde a cinco a cinquenta vezes esse valor. Nessa altura já não interessa se a sua regra de hashlimit por trás é boa, porque os pacotes dos seus jogadores nem chegam a passar.

A segunda grandeza é a taxa de pacotes e, num servidor Bedrock, é quase sempre ela a bater primeiro. Todo o tráfego de jogo é feito de muitos pacotes UDP pequenos, e é precisamente nessa disciplina que um atacante fica mais barato. Um ataque que não enche sequer um terço da sua linha pode mesmo assim paralisar o seu servidor, porque o tempo de processamento se gasta a avaliar e a descartar. Quem opera servidores vive isto como "a utilização nem sequer estava alta e mesmo assim ficaram todos de fora". Dentro do jogo, o mesmo manifesta-se como picos de lag, efeitos de elástico e quedas de ligação a meio de uma construção.

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 contra os ataques DDoS a servidores Bedrock

A proteção permanente incluída em todos os servidores

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. Aí entram também os padrões UDP na 19132 que não mostram comportamento de RakNet.

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. A localização é Frankfurt am Main. Que jogos e protocolos estão cobertos é o que lista Proteção DDoS em tempo real para servidores de jogos.

Advanced DDoS Protection para projetos 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 e sem prazo mínimo. 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 o que é permitido na 19132 UDP, o que é permitido na 19133 UDP e o que é permitido numa porta diferente, caso tenha mudado o seu servidor de porta.
• As alterações entram em vigor em tempo real, pelo que pode afinar durante um ataque em curso em vez de esperar por uma janela de manutenção.
• Perfil de proteção adequado a cada jogo. Para o Minecraft existem perfis prontos a usar, tal como para aplicações modificadas e próprias em quaisquer portas TCP ou UDP, portanto também para o Nukkit, o PocketMine-MP ou uma instância do Geyser numa porta à sua escolha.

Os dois níveis em comparação

Para a maioria dos projetos de Bedrock, 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. Quem, de momento, tem o seu servidor noutro sítio resolve melhor o problema com uma mudança: a filtragem atua na rede à frente do servidor, e essa rede tem de ser nossa.

Erros frequentes e respetivas soluções

"Mudei a porta para 19140 e a 19132 continua aberta": isso é o enable-lan-visibility=true. O Bedrock Dedicated Server liga-se então adicionalmente à 19132 e à 19133, independentemente do que esteja em server-port. Coloque em false, reinicie o servidor e confirme com ss -lnup.

"Editei o allowlist.json e agora nem eu consigo entrar": há duas causas frequentes. Ainda existe um whitelist.json antigo no diretório, que o servidor lê em vez do outro, ou falta a entrada do XUID, ou ela está errada. Com a autenticação Xbox Live ativa, o nome sozinho não chega de forma fiável.

"O meu alojador bloqueou o meu servidor, apesar de o atacado ser eu": verifique se o seu próprio servidor enviou pacotes. Foi precisamente isso que aconteceu na falha de amplificação do RakNet de 2024: os servidores afetados enviavam milhares de pacotes para endereços alheios, e nas comunicações de abuso constava a porta 19132 como origem. Com tcpdump -ni eth0 'udp src port 19132' -c 200 -q vê para onde o seu servidor responde. Uma build atual elimina a causa.

"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. Se ficarem a zero, a regra não está a ser alcançada.

"O servidor está na lista, mas ninguém consegue entrar": se a entrada mostra o nome e o número de jogadores, o Unconnected Pong funciona, ou seja, a porta está acessível em princípio. Se a entrada falha mesmo assim, o problema está normalmente na autenticação Xbox Live ou na allowlist. Se, pelo contrário, só os jogadores com IPv6 não conseguem entrar, falta a abertura da 19133 UDP.

"O servidor funciona, mas toda a gente tem picos de lag": isso é mais vezes um plugin do que um ataque. Veja primeiro se o Recv-Q no socket UDP cresce e se o UdpRcvbufErrors sobe. Se ambos ficarem calmos e o sar -n DEV 1 10 não mostrar nada de especial, não foi um ataque DDoS, foi o próprio processo do servidor. No Bedrock Dedicated Server ajudam então os watchdogs de scripts, cujos limiares estão no server.properties em script-watchdog-hang-threshold e script-watchdog-slow-threshold.

"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 Minecraft Bedrock precisa exatamente de uma porta aberta para o exterior: 19132 UDP, mais a 19133 UDP apenas para jogadores com IPv6. O query, o RCON, o depurador de scripts na 19144 TCP e um servidor Java por trás do Geyser na 25565 TCP não pertencem à rede aberta.
• Quem muda a porta tem de colocar enable-lan-visibility=false, senão o Bedrock Dedicated Server continua a ligar-se adicionalmente à 19132 e à 19133.
• A autenticação Xbox Live e a allowlist só atuam no pacote de login, ou seja, depois do estabelecimento completo da ligação RakNet. Protegem a sua lógica de jogo e os seus lugares, não a sua linha.
• O Unconnected Ping é pedido com 33 bytes e respondido com cerca de 131 bytes, um fator de amplificação de cerca de quatro. Um nome de servidor curto mantém esse fator pequeno.
• Em UDP ajuda o hashlimit em vez do connlimit, e o seguimento de ligações do kernel é o primeiro a encher com endereços de origem falsificados. Deve ter medido as duas coisas antes do primeiro ataque.
• A partir de cerca de 1 Gbit/s a sua linha está cheia e, com pacotes de 64 bytes, cabem ali cerca de 1,49 milhões de pacotes por segundo. Acima disso, quem decide é exclusivamente a filtragem na rede à frente do servidor.
• Na KernelHost, a proteção permanente em dois níveis está incluída em todos os pacotes de servidor, ativa a partir da disponibilização e sem null-routing. A Advanced DDoS Protection acrescenta-lhe um IP de proteção dedicado e regras autogeríveis por porta.

Se o seu projeto 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.