Proteger o servidor Hytale contra ataques DDoS

Um servidor Hytale que perde todas as ligações ao mesmo tempo a meio do jogo à noite, fica inacessível durante alguns minutos e depois volta a funcionar por si só, raramente tem um problema de hardware. Na maioria dos casos está a decorrer um ataque. Este artigo mostra como proteger um servidor Hytale 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 o servidor se mantenha acessível.

Todas as indicações se referem ao servidor dedicado oficial da Hypixel Studios, ou seja, ao HytaleServer.jar em conjunto com o Assets.zip sob Java 25, em funcionamento no 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. O Hytale está em Early Access e move-se depressa: por isso, neste artigo cada afirmação sobre o jogo traz uma data, e tudo o que não esteja oficialmente comprovado está expressamente assinalado como expectativa ou como fonte da comunidade. Se o ataque estiver a decorrer neste momento, vale além disso uma ordem: primeiro medir, depois alterar. Um reinício forçado sob carga descarta tudo o que aconteceu no mundo desde o último ponto de gravação, e os valores medidos do incidente também desaparecem depois disso.

Porque é que os servidores Hytale são paralisados com ataques DDoS dirigidos

Um servidor Hytale é um público num endereço fixo, e esse público é substituível. Quem à noite não consegue entrar três vezes seguidas no seu servidor habitual procura outro. É precisamente esse o modelo de negócio por trás dos ataques a servidores de comunidade: não se trata de dados nem de extorsão, mas sim de jogadores que se vão embora. Um serviço de booter que bombardeia um endereço por alguns euros por mês não exige de quem o encomenda nem competência nem esforço, e o prejuízo volta a surgir em cada falha.

A isto acresce no Hytale uma particularidade: o código do servidor é público. A Hypixel Studios anunciou em junho de 2026 o programa Hytale Shared Source e disponibiliza através dele, no GitHub, o código completo do servidor, o protocolo de rede e os assets, acessíveis a qualquer pessoa com uma licença válida do jogo. Para quem gere servidores isso é um ganho, porque os plugins passam a ser feitos contra interfaces reais. Do lado do ataque significa que ninguém tem de adivinhar o protocolo. Quem quiser saber em que ponto o estabelecimento da ligação custa tempo de processamento pode simplesmente consultá-lo. O que acontece tecnicamente num ataque destes é explicado no artigo O que é um ataque DDoS?.

A situação do Hytale a 27 de setembro de 2026

O Hytale está em Early Access desde 13 de janeiro de 2026, disponível para Windows, macOS e Linux, e nos dias seguintes ao lançamento alcançou mais de um milhão de jogadores. O caminho até aí foi invulgar, e explica por que razão os artigos mais antigos sobre o Hytale muitas vezes já não estão corretos.

A consequência prática desta cronologia: um servidor Hytale de hoje não é um servidor de janeiro. Com a Update 6 o protocolo de rede passou de hytale/2 para hytale/3 e, segundo os patch notes oficiais de 27 de agosto de 2026, o servidor e os plugins têm de ser reconstruídos antes de conseguirem ligar-se. Quem planeia a sua disponibilidade planeia por isso não só contra ataques, mas também contra mudanças de protocolo.

Porque é que 12 de outubro de 2026 é a data crítica

As grandes atualizações de conteúdo funcionam como um segundo lançamento comercial. Trazem de volta jogadores antigos, atraem novos e, por alguns dias, é a acessibilidade que decide qual dos servidores de comunidade cresce a partir dessa onda e qual a perde. Este padrão está documentado noutros jogos: o Palworld alcançou em janeiro de 2024 milhões de jogadores em poucos dias, e os servidores de comunidade dessa fase inicial foram os mais atacados precisamente no momento em que tinham mais a perder. A mecânica por trás disso está descrita em detalhe em Proteger servidores Palworld contra ataques DDoS e transpõe-se um para um para o Hytale.

Daí decorre uma verdade incómoda sobre o calendário: proteção encomendada a 12 de outubro chega tarde. Uma linha, um IP de proteção, um conjunto de regras por porta e um valor medido do funcionamento normal precisam de antecedência, porque sem dados de comparação não podem ser ajustados de forma sensata. Quem começa duas semanas antes de uma grande atualização tem tempo suficiente. Quem começa no dia da atualização afina às cegas.

As portas que realmente contam num servidor Hytale

Um servidor Hytale precisa de exatamente uma porta aberta: 5520 UDP. O tráfego de jogo passa por QUIC, ou seja, por UDP, e o TCP não é necessário para o tráfego de jogo. Quem só liberta TCP vê a mesma imagem de uma firewall fechada: os jogadores entram num tempo de espera esgotado. A ligação predefinida é 0.0.0.0:5520, uma porta diferente define-se no arranque com --bind.

Esta tabela é mais curta do que na maioria dos outros jogos, e essa é a diferença mais importante. Um servidor de Counter-Strike responde a consultas de estado no formato Steam A2S, um servidor de Minecraft Bedrock responde a um Unconnected Ping, um servidor de Palworld mantém uma porta de query própria aberta. Para o Hytale, na documentação pública não está descrita nenhuma outra porta além da 5520 UDP: nenhuma porta de query, nenhuma porta de RCON, nenhuma interface REST no estado de origem. Tudo o que um servidor Hytale oferece para o exterior está numa única porta UDP.

O servidor Hytale em números

Os valores seguintes são a base para qualquer decisão sobre regras de filtragem e limites. A origem está indicada em cada caso, porque é ela que decide a fiabilidade.

O que o QUIC altera na superfície de ataque

O QUIC é um protocolo de transporte que estabelece ligações seguras sobre UDP e que tem a criação da cifragem segundo TLS 1.3 integrada de forma fixa. Não existe QUIC sem cifragem. Para quem gere um servidor isso significa duas coisas que se contradizem, e ambas são importantes.

A primeira é uma melhoria real. Como o UDP não obriga a um estabelecimento de ligação e os endereços de remetente podem ser falsificados, os serviços UDP sem ligação são os amplificadores clássicos de ataques a terceiros. O QUIC limita isso na norma. O RFC 9000 prescreve na secção 8.1 que um servidor, antes de verificar o endereço de remetente, só pode enviar no máximo o triplo da quantidade de bytes recebida, e a secção 14.1 exige que um cliente preencha o seu primeiro datagrama até pelo menos 1200 bytes. Em conjunto, estas duas regras levam o fator de amplificação de um serviço QUIC a um máximo de três, enquanto uma porta de query Steam ou um Unconnected Ping do Bedrock alcança um múltiplo disso. Um servidor Hytale que funcione corretamente é por isso praticamente sem interesse como amplificador de reflexão. Trata-se de uma vantagem estrutural face a quase todos os outros jogos com tráfego UDP, e na comparação com servidores Minecraft Bedrock essa vantagem é bem visível.

A segunda é o preço a pagar por isso. Um estabelecimento de ligação QUIC custa tempo de processamento ao servidor, porque envolve uma negociação TLS 1.3 com criptografia assimétrica. Um único pacote falsificado não consegue forçar um estabelecimento, mas uma inundação de tentativas de ligação reais a partir de um botnet consegue. O atacante também paga tempo de processamento, e é precisamente essa relação que decide: enquanto o servidor fizer mais trabalho por tentativa de ligação do que o atacante, o ataque é economicamente viável. Uma inundação de tentativas de ligação não sobrecarrega por isso a linha, mas sim o processador, e nas estatísticas de largura de banda não parece nada. É o mesmo mecanismo que no Minecraft é conhecido como Nullping e flood de handshake e que está descrito em detalhe no artigo Proteção DDoS e proteção Nullping para Minecraft.

Na prática, o que mais se aproveita disto é a regra dos 1200 bytes. Uma nova tentativa de ligação tem de chegar como datagrama de pelo menos 1200 bytes, caso contrário, segundo a norma, não é um estabelecimento de ligação válido. O tráfego de jogo corrente é, em contrapartida, composto predominantemente por pacotes pequenos. Esta distinção consegue transformar-se numa regra de filtragem, e é o que veremos a seguir.

O que não está publicamente documentado sobre o Hytale

Esta lista pertence a um artigo honesto, porque define onde não se pode confiar em números. Tudo o que segue não está oficialmente comprovado à data de 27 de setembro de 2026:

• Se o servidor usa QUIC Retry para a verificação do endereço. O RFC 9000 permite na secção 8.1.2 um pacote Retry com token, com o qual um servidor verifica o endereço de remetente antes de reservar recursos. Se e a partir de que carga o Hytale faz isso não está documentado. Assuma que não pode contar com isso.
• Os valores predefinidos dos blocos RateLimit e ConnectionTimeouts no config.json. Que ambos os blocos existem é consistente em várias fontes. Mas os números indicados contradizem-se: uma fonte indica limites concretos, outra descreve os blocos como presentes, mas sem efeito. Por isso, neste artigo não consta nenhum desses números, e por isso não deve planear estes blocos como sendo a sua defesa.
• Os nomes e as predefinições dos modos de autenticação. A documentação da comunidade sobre o código do servidor publicado descreve três modos, definidos através de --auth-mode, com authenticated como predefinição e ainda offline e insecure para ambientes privados e para desenvolvimento. Isso não está confirmado oficialmente. A regra que daí decorre é, ainda assim, inequívoca: não altere o modo num servidor público.
• Detalhes do estabelecimento de TLS. A documentação de protocolo da comunidade, que se baseia no código do servidor publicado, descreve um certificado de ambos os lados, um certificado de servidor autoassinado gerado no arranque, cuja impressão digital SHA-256 chega aos clientes através do serviço de sessão, bem como um 0-RTT desativado. Isso é plausível e encaixa no TLS 1.3, mas não está confirmado oficialmente, e não altera nada nas medidas indicadas mais abaixo.
• Dimensões de ataque especificamente contra servidores Hytale. Não há números públicos sobre isso. Os 5 a 50 Gbit/s indicados na tabela são um valor empírico transversal aos projetos de gameserver e expressamente não uma estatística do Hytale.
• Taxas de pacotes por jogador em funcionamento normal. Também para isso não existe publicação fiável. Por isso, neste artigo não consta nenhum limite que possa adotar sem verificar, mas sim um guia para o medir por si próprio.

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

Os passos seguintes não travam nenhum ataque volumétrico, isso nenhum software no servidor consegue fazer. Mas limpam tudo o que está abaixo disso: scans de portas, inundações de tentativas de ligação a partir de poucas origens, tentativas de tomada de controlo através de interfaces de administração instaladas adicionalmente e a ocupação de todos os lugares por estranhos. É essa a maior parte daquilo que perturba um servidor Hytale no dia a dia, e custa uma boa hora de trabalho.

1. Levantamento: o 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:5520 significa "acessível a partir de toda a internet", 127.0.0.1:8080 significa "apenas local" e não precisa de regra de firewall. Além do processo Java do servidor, numa máquina que foi crescendo aparecem frequentemente 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 5520 IP.DO.SEU.SERVIDOR
nmap -Pn -p- --min-rate 1000 IP.DO.SEU.SERVIDOR

O segundo comando é o mais importante. Mostra o que mais está aberto e, na prática, é quase sempre mais do que se esperava.

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

Duas autorizações chegam. 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 5520/udp comment 'Hytale QUIC'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Não precisa de uma autorização TCP na 5520. Se operar o servidor numa porta diferente, a autorização tem de corresponder ao valor de --bind, caso contrário o arranque corre bem e os jogadores continuam a não chegar. As instruções completas, incluindo o caminho de recuperação, encontram-se em Configurar a firewall UFW sem se trancar fora do servidor.

Para tudo o que tenha instalado adicionalmente para administração vale a mesma regra de qualquer outro jogo: não o exponha à rede aberta, torne-o acessível através de um encaminhamento de porta por SSH e trabalhe depois localmente contra 127.0.0.1:

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

3. Arrancar o servidor como ele foi pensado

O arranque consiste num único comando. Os ficheiros do servidor obtêm-se através do downloader oficial do Hytale ou a partir da sua própria instalação do jogo:

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

No primeiro arranque, o servidor cria o config.json, a pasta logs/ e a pasta do mundo universe/. Depois disso, autentica-o uma única vez na respetiva conta, para que a autenticação dos jogadores funcione. Isso passa por um código de dispositivo na consola do servidor:

/auth login device
/auth status

Não defina -Xmx com toda a memória RAM da máquina. O sistema operativo, a cache do sistema de ficheiros e o consumo do ambiente de execução Java fora do heap também precisam de espaço, e um servidor que sob carga entra em memória de paginação tem, para os seus jogadores, exatamente o aspeto de um ataque.

4. Whitelist, palavra-passe do servidor e limite máximo de jogadores contra o esgotamento de slots

O esgotamento de slots é o ataque mais barato a um servidor de comunidade e não precisa de largura de banda. Quem estabelecer ligações simultâneas suficientes ocupa todos os lugares e exclui assim a própria comunidade, sem comprar um único gigabit. Ao contrário de outros jogos, o Hytale tem para isso as ferramentas adequadas no estado de origem: uma whitelist em whitelist.json, uma lista de banimentos em bans.json, permissões em permissions.json e, no config.json, as chaves Password e MaxPlayers.

{
  "ServerName": "O meu servidor Hytale",
  "MOTD": "",
  "Password": "um valor que só o seu grupo conhece",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password vem vazia de origem, portanto qualquer pessoa com endereço e porta entra. Para um servidor fechado, uma palavra-passe definida é a medida individual mais eficaz contra o esgotamento de slots; para um servidor público, essa medida é a whitelist durante uma onda de ataques. 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 não quer entrar.

Edite estes ficheiros apenas com o servidor parado. O processo do servidor em funcionamento mantém o seu próprio estado em memória e pode, ao encerrar, sobrescrever sem aviso as alterações que tenha escrito no ficheiro nesse intervalo. Para alterações em funcionamento, use os comandos de consola em vez do editor.

5. Deixar a autenticação no valor predefinido

O modo predefinido exige de cada jogador uma conta Hytale válida. Isso é mais do que uma verificação de licença: é um filtro de acesso que torna caras as contas em massa. Um atacante que queira ocupar lugares precisa para isso de contas válidas, e essas custam dinheiro. Não retire este filtro.

A documentação da comunidade descreve, além do modo predefinido, dois outros modos para ambientes privados e para desenvolvimento, com os quais é possível entrar sem verificação de conta. Para um servidor público são a pior definição possível, porque transformam o esgotamento de slots de uma questão de dinheiro numa questão de script. Se mudar para testar, faça-o numa máquina que não esteja na internet, e volte a mudar depois.

6. Limitar as novas tentativas de ligação, e fazê-lo com a regra dos 1200 bytes

Agora a vantagem estrutural do QUIC torna-se prática. Um estabelecimento de ligação válido chega, segundo o RFC 9000, como datagrama de pelo menos 1200 bytes. O tráfego de jogo corrente é claramente mais pequeno. Com o seguimento de ligações consegue por isso distinguir fluxos de dados novos dos existentes e descartar tudo o que seja novo e demasiado pequeno. Com o nftables, carregado através de nft -f:

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

        ct state new udp dport 5520 udp length < 1208 drop

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

A primeira regra trabalha sobre o comprimento UDP, ou seja, 8 bytes de cabeçalho mais 1200 bytes de carga útil, 1208 no total. Atinge exclusivamente os pacotes que querem abrir um novo fluxo de dados e que para isso são demasiado pequenos, e não consegue atingir jogadores ligados. A segunda regra limita quantas novas ligações um único endereço de origem pode abrir por segundo. Cinco por segundo é generoso: um jogador real estabelece uma ligação e mantém-na. A prioridade -10 assegura que ambas as regras atuam antes da cadeia de filtragem do UFW.

Um limite máximo para a taxa de pacotes por endereço de origem na própria porta de jogo é a terceira regra sensata, e aqui vale expressamente: o valor numérico é um valor de partida, não uma verdade absoluta.

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

Meça primeiro durante uma semana em funcionamento normal e defina depois o limite no dobro do valor de pico medido. Para o Hytale não existe um número de referência publicado para isso, e os valores dependem muito do número de jogadores e do raio de visão. Quem aperta demasiado expulsa os seus próprios jogadores, e primeiro aqueles que têm a pior linha.

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, estas regras pertencem adicionalmente a /etc/ufw/before.rules, porque de outra forma desaparecem no ufw reload seguinte. Se uma regra é sequer alcançada é o que mostra o iptables -L INPUT -n -v: se os contadores de correspondências ficarem a zero, ela não atua.

7. Configurar corretamente o seguimento de ligações do kernel

Este ponto explica falhas que parecem um ataque de volume, mas não o são. O kernel cria entradas no seguimento de ligações para o tráfego UDP e, com endereços de remetente falsificados, cada endereço significa uma nova entrada. Se a tabela ficar cheia, o kernel descarta pacotes sem distinção, o ataque e os seus jogadores caem em conjunto, e no log fica "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

Na maioria dos jogos, a melhor resposta a isso é não deixar que o tráfego de jogo seja seguido. No Hytale isso é uma ponderação a sério, porque a regra dos 1200 bytes do passo 6 precisa do seguimento de ligações. Sem ele, o filtro não sabe que pacote abre um novo fluxo de dados. A recomendação é por isso: manter o seguimento, aumentar a tabela, manter curto o tempo de espera para o UDP. Um acréscimo em /etc/sysctl.d/, ativado com sysctl --system:

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

Quem quiser desligar o seguimento ainda assim, por exemplo numa máquina com muitos jogadores simultâneos, define udp dport 5520 notrack na tabela raw e prescinde com isso da regra dos 1200 bytes. As duas coisas em conjunto não são possíveis. Para um único servidor Hytale, a regra vale mais do que as entradas de tabela poupadas.

Se os pacotes chegarem mais depressa do que o processo Java os recolhe, transborda além disso o buffer de receção. Para os jogadores isso parece perda de pacotes, embora a linha esteja livre. Se as definições de buffer acima são necessárias é o próprio kernel que o diz: se o UdpRcvbufErrors subir no nstat -az, então elas atuam. Se o contador ficar a zero, o ajuste não muda nada.

8. Escolher o raio de visão e o número de jogadores de acordo com a linha

Este passo não é uma medida de segurança, mas decide quanto ataque consegue suportar. A Hypixel Studios formulou-o com clareza nos requisitos de hardware oficiais de 1 de dezembro de 2025: se duplicar o raio de visão, quadruplica a quantidade de mundo em torno do jogador. A recomendação oficial é de no máximo 12 chunks, ou seja, 384 blocos, definidos através de MaxViewRadius. Do lado do cliente, os mesmos requisitos indicam 2 Mbit/s como mínimo e 8 Mbit/s como recomendação por jogador para o modo multijogador.

Faça essa conta uma vez para o seu servidor. Um servidor com 40 jogadores e um raio de visão generoso movimenta em funcionamento normal uma casa baixa de centenas de megabits. É esse o valor com que a sua linha se tem de medir, e é ao mesmo tempo o valor que um ataque tem de exceder para chamar a atenção. Quem enche em funcionamento normal um terço de uma linha de 1 Gbit/s tem menos reserva do que quem está nos cinco por cento. Um raio de visão menor não é por isso apenas uma questão de desempenho, mas também uma questão de robustez.

9. Manter à vista mods, plugins e mudanças de protocolo

O Hytale é moddável do lado do servidor: os mods ficam como .zip ou .jar na pasta mods/, e os plugins acedem diretamente à interface do servidor. Isso é cómodo, porque os jogadores não têm de instalar nada, e é ao mesmo tempo um risco de disponibilidade que nada tem a ver com ataques. Um plugin que trabalhe de forma dispendiosa a cada evento de rede é um amplificador dentro da sua própria casa.

A isso acresce a mudança de protocolo. Com a Update 6, o protocolo de rede passou, segundo os patch notes oficiais de 27 de agosto de 2026, de hytale/2 para hytale/3, e o servidor e os plugins têm de ser reconstruídos antes de conseguirem ligar-se. Para a disponibilidade isso significa: mantenha uma lista dos seus mods com a respetiva versão, verifique-a antes de cada atualização numa segunda instância e planeie uma janela de manutenção antes de 12 de outubro de 2026. Um servidor que não arranca depois de uma atualização é, para os seus jogadores, indistinguível de um ataque.

10. 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 conntrack a medição fica sempre a correr. Durante um incidente bastam cinco comandos:

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

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 o servidor Hytale corre em Java, precisa de uma segunda prova que exclua o falso alarme mais frequente. Uma pausa da recolha de lixo tem, para os jogadores, exatamente o mesmo aspeto de um ataque: todos param ao mesmo tempo e depois a coisa continua. A diferença está nos números.

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

A interpretação é simples. Se os pacotes de entrada subirem muito acima do valor normal enquanto o processo Java quase não trabalha, é um ataque. Se a taxa de pacotes se mantiver sem nada de especial enquanto o heap se enche ou o log mostra pausas longas, é carga. Como interpretar em detalhe os valores de rede está em Detetar um ataque DDoS no servidor.

11. Backup, plano de recuo e um ensaio antes da grande data

Um conceito de proteção que nunca foi testado é uma suposição. Antes de uma data como 12 de outubro de 2026 há quatro coisas a fazer: um backup da pasta universe/ com o config.json, guardado fora da máquina, um regresso verificado à versão anterior do servidor, uma segunda instância na qual instala primeiro a atualização, e um teste de carga único que acione as suas próprias regras de filtragem.

O teste de carga é o ponto em que a maioria dos operadores desiste, e é o mais importante. Não verifique se as suas regras travam ataques, mas sim se deixam passar os seus próprios jogadores. Para isso basta observar os contadores de correspondências enquanto vinte jogadores reais entram ao mesmo tempo. Se os contadores das regras de descarte subirem nesse momento, o seu limite está apertado demais, e tê-lo-ia descoberto no dia da atualização, nas piores condições possíveis.

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

Agora a parte que nenhum ficheiro de configuração consegue resolver. 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 gameserver situam-se habitualmente entre 5 e 50 Gbit/s, ou seja, entre cinco e cinquenta vezes a sua linha. Se a sua regra de nftables atrás disso é boa deixa então de ter importância, porque os pacotes dos seus jogadores já nem chegam a passar.

A segunda grandeza é a taxa de pacotes, e muitas vezes chega ao limite mais cedo do que a 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 não enche nem um terço da sua linha pode portanto, ainda assim, paralisar o seu servidor, porque o tempo de processamento se gasta a descartar. Quem gere servidores vive isto como "a utilização nem sequer estava alta e mesmo assim desapareceu tudo".

No Hytale acresce uma terceira grandeza que na maioria dos jogos não existe: o tempo de processamento para o estabelecimento da ligação. Uma inundação de tentativas de ligação válidas a partir de um botnet não enche nenhuma linha e não gera uma taxa de pacotes notável, ocupa o processador com criptografia. Ataques destes são invisíveis nas estatísticas de largura de banda e bem visíveis na carga de processador do processo Java, e contra eles não ajuda nem uma limitação de taxa por endereço de origem nem um buffer de receção maior, se as origens forem suficientemente numerosas.

Para enquadrar as ordens de grandeza que ocorrem realmente: 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 há definição local nenhuma. Os ataques volumétricos têm de terminar na rede à frente do servidor.

O que a KernelHost põe contra ataques DDoS a servidores Hytale

A proteção permanente incluída em todos os pacotes 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. Que títulos e protocolos estão cobertos com perfis de proteção próprios é o que lista Proteção DDoS em tempo real para servidores de jogos.

Advanced DDoS Protection para projetos Hytale sob fogo permanente

Alguns projetos não são atacados de forma ocasional, mas sim de forma dirigida e ao longo de semanas, e num jogo em Early Access isso atinge sobretudo os servidores que estão a crescer. Para esses existe a Advanced DDoS Protection a partir de 50,00 € 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 o que é permitido na 5520 UDP, em separado de tudo o resto, e não precisa de abrir 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 por pouco tempo as novas ligações com mais rigor e deixar intacto o tráfego de jogo corrente.
• Conjunto de regras adequado ao protocolo, tanto para QUIC sobre UDP como para aplicações próprias em quaisquer portas TCP ou UDP.

A Advanced DDoS Protection destina-se a servidores que estão na KernelHost. Quem opera o seu projeto Hytale atualmente noutro sítio e é atacado de forma permanente transfere-o para a KernelHost, e então os dois níveis atuam a partir da disponibilização.

Os dois níveis em comparação

Para a maioria dos servidores Hytale, 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.

O que se pode transpor de outros jogos para o Hytale

Como o Hytale ainda é novo e não existem números públicos sobre ataques a servidores Hytale, o caminho mais rápido para conhecimento fiável é olhar para jogos comparáveis. O que é transponível não é o número da porta, mas sim o padrão.

• O lançamento explosivo e o que ele desencadeia: o Palworld mostra como uma onda de novos jogadores e uma onda de ataques se sobrepõem no tempo e por que razão são precisamente os servidores em crescimento a tornar-se alvo.
• A diferença entre query e tráfego de jogo: o Minecraft Bedrock explica, a partir do Unconnected Ping, como funciona a amplificação sobre UDP. É precisamente esse caminho de ataque que o Hytale não tem, graças ao QUIC, e é aí que a diferença se compreende melhor.
• O estabelecimento da ligação como alvo de ataque: Proteção DDoS e proteção Nullping para Minecraft descreve floods de handshake que se bastam com quase nenhuma largura de banda. É o parente mais próximo da inundação de ligações QUIC.
• Números pequenos de jogadores e esgotamento de slots: o Project Zomboid e o Conan Exiles mostram quão pouco esforço é necessário para excluir um grupo fixo, e que papel a whitelist e a palavra-passe desempenham nisso.
• Funcionamento sob carga permanente: o Terraria mostra como um único processo de servidor com carga num só núcleo reage a ataques. O servidor Hytale é um processo Java, o problema de fundo é comparável.

Erros frequentes em servidores Hytale e a respetiva solução

"Libertei a porta 5520 TCP e os jogadores continuam a não entrar": o tráfego de jogo passa por QUIC, ou seja, por UDP. Uma autorização TCP não serve para nada no tráfego de jogo. Liberte a 5520 UDP e verifique-o de fora com nmap -Pn -sU -p 5520. Se tiver colocado o servidor noutra porta com --bind, a autorização tem de indicar essa porta.

"O servidor corre, mas ninguém consegue entrar, e no log não há nada sobre ataques": verifique a autenticação do servidor na respetiva conta com /auth status. Um servidor cuja autenticação expirou continua a correr e, apesar disso, recusa jogadores. Não é um problema de rede nem uma regra de filtragem.

"Depois da atualização já não arranca nada": não é um ataque, é a mudança de protocolo. Com a Update 6 o protocolo de rede passou de hytale/2 para hytale/3, e o servidor e os plugins precisam de uma nova construção. Instale as atualizações primeiro numa segunda instância, antes de as deixar chegar ao servidor de produção.

"Todos os jogadores param ao mesmo tempo durante dois segundos e depois continua": com elevada probabilidade é a recolha de lixo do ambiente de execução Java e não um ataque. Verifique o jcmd ... GC.heap_info e o log do servidor. Se o sar -n DEV 1 10 não mostrar nada de especial, não houve ataque, mas sim um heap mal dimensionado ou um raio de visão demasiado grande.

"A minha regra contra pacotes pequenos excluiu os jogadores": então a condição dos 1200 bytes está na cadeia sem ct state new. O tráfego de jogo corrente é composto predominantemente por pacotes pequenos, e uma condição de comprimento sem verificação de estado atinge precisamente esses. A condição vale exclusivamente para fluxos de dados recém-abertos.

"Mudei o endereço IP e duas horas depois estava outra vez offline": o atacante tirou o novo endereço da mesma fonte que o antigo. No Hytale, essa fonte é normalmente um registo A antigo no DNS, um bot do Discord com indicação de estado ou uma entrada numa das muitas listas de servidores de terceiros. Desde a Update 6, os endereços de servidor estão ocultos de origem na lista de servidores oficial, o que fecha o caminho mais cómodo, mas não todos. Uma mudança de endereço dá tempo, não é solução.

"As minhas regras de filtragem 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 Hytale precisa de exatamente uma porta aberta: 5520 UDP para QUIC. O TCP não é necessário para o tráfego de jogo e, na documentação pública, não está descrita nenhuma outra porta para query, RCON ou controlo remoto.
• Como o QUIC, segundo o RFC 9000, só pode enviar no máximo o triplo da quantidade de bytes recebida antes da verificação do endereço e uma primeira tentativa de ligação tem de ter pelo menos 1200 bytes, um servidor Hytale é praticamente sem interesse como amplificador de reflexão. Isso distingue-o dos servidores com query Steam ou com Unconnected Ping do Bedrock.
• Essa mesma regra dos 1200 bytes é a melhor regra de filtragem local: aquilo que quiser abrir um novo fluxo de dados na 5520 UDP e for mais pequeno não pode ser um estabelecimento de ligação válido e pode ser descartado sem atingir jogadores ligados.
• A parte dispendiosa de um estabelecimento QUIC é a criptografia, não a largura de banda. Uma inundação de tentativas de ligação válidas é invisível nas estatísticas de largura de banda e só se vê na carga do processador e nos contadores de novas ligações.
• O modo predefinido com obrigação de conta é um filtro de acesso que torna caras as contas em massa. Num servidor público mantém-se intacto, e a isso acrescentam-se o whitelist.json, o bans.json e um valor definido em Password contra o esgotamento de slots.
• 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 o que estiver acima disso tem de terminar na rede à frente do servidor.
• O Hytale está em Early Access desde 13 de janeiro de 2026, e o Chapter 1 está anunciado para 12 de outubro de 2026. As grandes datas são datas de ataque, e proteção encomendada na data chega tarde.
• Na KernelHost, a proteção permanente em dois níveis está incluída em todos os pacotes de servidor sem sobretaxa e fica 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 € por mês.

Se o seu servidor Hytale 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 para o seu endereço IP sejam afinadas. Durante um ataque em curso pode ainda falar connosco pelo chat de emergência do WhatsApp, através do +43 650 8209883.

Este artigo tem a data de 27 de setembro de 2026. O Hytale está em Early Access, e o protocolo de rede já mudou uma vez este ano. Será atualizado depois do Chapter 1 e depois de cada atualização que afete o estabelecimento da ligação, as portas ou a lista de servidores.