Proteger o servidor Unturned contra ataques DDoS

Um servidor Unturned que à noite desaparece durante alguns minutos da lista de servidores e, ao mesmo tempo, expulsa todos os jogadores com um timeout raramente tem um problema de hardware. Na maioria dos casos está a decorrer um ataque, e precisamente à hora em que há mais movimento. Este artigo mostra primeiro o que pode proteger por conta própria e sem custos adicionais, depois onde estas medidas acabam do ponto de vista técnico e, por fim, o que tem então de acontecer na rede à frente do servidor.

Todas as indicações se referem ao Unturned Dedicated Server (U3DS, app ID 1110390 do SteamCMD) 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, não altere nada na configuração e não reinicie o servidor: guarde os valores medidos (secção 10), porque depois do ataque desaparecem.

Porque é que são precisamente os servidores Unturned a ser atacados

Os servidores Unturned são atacados porque o seu endereço é público, porque o tráfego de jogo corre sobre UDP e porque um ataque não custa a quem o desencadeia nem competência nem dinheiro digno de nota. Os três pontos valem aqui mais do que na maioria dos outros jogos.

Um servidor Unturned público publica o seu endereço IP por iniciativa própria. Tem de o fazer, caso contrário ninguém o encontraria: o navegador de servidores da Steam consulta-o diretamente, e as listas de terceiros, como a unturned-servers.net ou a BattleMetrics, apresentam o endereço IP e a porta em texto simples. Para isso, a unturned-servers.net verifica, segundo a própria indicação, de cinco em cinco minutos se o servidor aceita ligações UDP na porta do servidor. Para um atacante, isto não é trabalho, é um formulário.

A isto junta-se o público do jogo. O Unturned é gratuito, a barreira de entrada é nula, e entre os projetos de roleplay e de survival há concorrência real pelos mesmos jogadores. Um jogador banido, um antigo administrador ofendido ou um projeto vizinho não precisa de acesso ao seu servidor para o tornar inutilizável durante uma hora. O que é tecnicamente um ataque DDoS, e porque é que os endereços de origem falsificados o tornam tão difícil de rastrear, fica explicado no artigo O que é um ataque DDoS?.

As portas que realmente contam

Um servidor Unturned ocupa exatamente duas portas UDP consecutivas: o valor definido na Commands.dat e esse valor mais um. Na predefinição são a 27015 e a 27016. A documentação oficial da Smartly Dressed Games descreve a repartição assim: a primeira porta transporta as consultas da lista de servidores, a segunda o tráfego de jogo. Definida é apenas a primeira, a segunda resulta automaticamente.

Name O Meu Servidor Unturned
Port 27015
MaxPlayers 24
Map PEI
Mode Normal
Perspective Both
Owner 76561198000000000

A Commands.dat fica em U3DS/Servers/<Instância>/Server/Commands.dat. O seu formato é peculiar e é uma fonte de erros frequente: um comando por linha, sem sinal de igual, o valor separado por um espaço, e os comandos são sensíveis a maiúsculas e minúsculas. As linhas que começam por // são comentários.

O ponto mais importante para a firewall é este: a porta 27017 deixou de ser necessária desde a versão 3.21.30.0, de 21 de novembro de 2021. Antes disso, um servidor Unturned exigia três portas, porque a consulta da Steam ficava na porta mais dois. Com essa atualização, a consulta passou a partilhar a porta com o próprio servidor e a terceira porta deixou de existir. Mesmo assim, guias de router, wikis de alojadores e mensagens de fórum continuam até hoje a mencionar a 27017. Uma 27017 aberta já não lhe traz qualquer vantagem, é pura superfície de ataque.

Igualmente importante: o Unturned não tem uma porta de RCON integrada. A documentação oficial conhece apenas a entrada e a saída de consola, que podem ser substituídas através da interface ICommandInputOutput. Qualquer controlo remoto que veja num servidor Unturned vem de um plugin e traz consigo uma porta TCP própria. Essa porta tem de ser encontrada e restringida por si, porque ninguém a protegeu por si.

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

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

1. Levantamento: o que está mesmo à escuta

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

ss -lnup
ss -lntp

O primeiro comando mostra os sockets UDP à escuta, o segundo os sockets TCP. A coluna interessante é a do endereço local. 0.0.0.0:27015 e [::]:27015 significam "acessível a partir de toda a internet", 127.0.0.1:3306 significa "apenas local" e não precisa de regra de firewall. Além do jogo, aparecem ali muitas vezes um plugin de RCON, um painel web, uma base de dados e um antigo servidor de testes na 27017 que já ninguém usa. A perspetiva do atacante obtém-se com um scan de portas a partir de fora, no caso do Unturned expressamente com UDP:

nmap -Pn -sU -p 27000-27050 IP.DO.SEU.SERVIDOR
nmap -Pn -p- --min-rate 1000 IP.DO.SEU.SERVIDOR

2. Deixar abertas apenas a 27015 e a 27016

Ao Unturned bastam duas aberturas UDP para o exterior. Para o jogo em si não é preciso uma única porta TCP: a documentação oficial exige expressamente UDP para as duas portas, e a camada de rede do jogo (Steam Networking Sockets, a predefinição desde uma das atualizações) trabalha exclusivamente sobre UDP. Quem abre TCP adicionalmente está a seguir um guia desatualizado.

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Unturned consulta'
ufw allow 27016/udp comment 'Unturned jogo'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

A ordem é importante, caso contrário tranca-se a si próprio fora do servidor. As instruções completas, incluindo a via de regresso, estão em Configurar a firewall UFW sem se trancar fora do servidor. Se operar várias instâncias, mantenha o intervalo recomendado de dois (27015, 27017, 27019) e abra por cada instância exatamente as duas portas que ela ocupa de facto.

Um painel web, uma base de dados ou um plugin de RCON não pertencem à rede aberta. Restrinja a respetiva porta ao seu próprio endereço com ufw allow from 203.0.113.10 to any port 8080 proto tcp, ou chegue à interface através de um encaminhamento local por SSH com ssh -N -L 8080:127.0.0.1:8080 root@IP.DO.SEU.SERVIDOR. A base de dados liga-se a 127.0.0.1.

3. Proteger a porta de consulta sem cair da lista de servidores

A porta de consulta é o ponto mais sensível de um servidor Unturned. É por ela que o servidor responde às consultas Steam A2S_INFO, A2S_PLAYERS e A2S_RULES. Se a bloquear por completo, o servidor desaparece de todas as listas de servidores, mesmo que esteja a correr sem qualquer falha.

Uma resposta A2S é bastante maior do que o pedido. O US-CERT atribui ao protocolo Steam, na sua síntese sobre ataques de amplificação por UDP (TA14-017A), um fator de amplificação de largura de banda de 5,5. Em concreto, isso significa: um atacante envia consultas com o endereço de origem falsificado a gameservers alheios e desvia para o seu verdadeiro alvo as respostas, cerca de cinco vezes e meia maiores. O seu servidor deixa então de ser a vítima e passa a ser o amplificador contra um terceiro. No sentido inverso, basta uma enxurrada de consultas para fazer o servidor desaparecer do navegador de servidores sem que um único jogador seja expulso. Os operadores comunicam exatamente isso: o servidor corre, os jogadores que estão nele não notam nada, mas ele deixou de ser encontrável.

Contra pequenas enxurradas de consultas ajuda um limite máximo por endereço de origem. As consultas legítimas chegam raramente: o navegador da Steam consulta uma vez por apresentação, os serviços de estado de poucos em poucos minutos.

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name unturned_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name unturned_game --hashlimit-mode srcip --hashlimit-above 300/sec --hashlimit-burst 500 -j DROP

O segundo número deriva diretamente do jogo: o Unturned limita um jogador, de fábrica, a 50 pacotes por segundo (Max_Packets_Per_Second). Portanto, 300 pacotes por segundo e por endereço de origem deixam bastante folga a uma ligação isolada, mesmo que vários jogadores estejam atrás do mesmo endereço. Ambos os valores são valores de partida, não verdades absolutas. Meça primeiro durante uma semana em funcionamento normal, caso contrário expulsa os seus próprios jogadores.

As regras puras de iptables desaparecem depois de um reinício. No Debian e no Ubuntu guardam-se com apt-get install -y iptables-persistent e netfilter-persistent save. Com o UFW, estas regras pertencem ao /etc/ufw/before.rules, porque de outra forma desaparecem no ufw reload seguinte.

A isto junta-se um hábito que não custa nada: se o seu site ou o seu bot do Discord mostrar o número de jogadores, não consulte o servidor a partir do visitante, guarde antes o resultado em cache a intervalos fixos. Caso contrário, uma página de estado muito visitada gera uma consulta por visitante em vez de uma por intervalo.

4. Definir os limites integrados na Config.json

O Unturned traz na Config.json, na mesma pasta Server onde está a Commands.dat, uma secção que é mais importante para a defesa do que o seu nome deixa supor. As predefinições são estas:

"Server": {
    "VAC_Secure": true,
    "BattlEye_Secure": true,
    "Max_Ping_Milliseconds": 750,
    "Timeout_Queue_Seconds": 15.0,
    "Timeout_Game_Seconds": 30.0,
    "Max_Packets_Per_Second": 50.0,
    "Join_Rate_Limit_Window_Seconds": 40.0,
    "Rate_Limit_Kick_Threshold": 10,
    "Use_FakeIP": false
}

O Max_Packets_Per_Second limita um jogador ligado a 50 pacotes por segundo. O Join_Rate_Limit_Window_Seconds e o Rate_Limit_Kick_Threshold expulsam uma ligação que, dentro de 40 segundos, ultrapasse o limite mais de dez vezes. O VAC_Secure e o BattlEye_Secure exigem os dois sistemas de anticheat do lado do jogador e mantêm assim afastada a maior parte dos clientes descartáveis.

Uma coisa tem de ficar clara: estes limites atuam contra clientes que entram de facto ou que o tentam. Contra uma enxurrada com endereços de origem falsificados não atuam, porque ali nunca chega a nascer uma sessão. São importantes na mesma, porque apanham o caso isolado mais frequente: um único cliente manipulado que sobrecarrega o servidor sozinho. Deixar o Max_Ping_Milliseconds em 750 é sensato; com um valor mais baixo, o servidor expulsa meias rondas a cada pequeno soluço da rede.

5. Aliviar o seguimento de ligações

Este ponto é quase sempre ignorado e explica falhas que parecem um ataque volumétrico sem o serem. 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 novo significa uma entrada nova. Quando a tabela enche, o kernel descarta pacotes sem distinguir: o ataque e os seus jogadores caem em conjunto. No registo do sistema fica então nf_conntrack: table full, dropping packet.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack

O passo mais eficaz é não deixar sequer que o tráfego do Unturned seja seguido. O jogo gere as suas próprias sessões e não precisa de seguimento de estado no kernel:

iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK
iptables -t raw -A PREROUTING -p udp --dport 27016 -j NOTRACK

Tenha em atenção que, a partir daí, as suas aberturas para estas duas portas já não podem passar por ESTABLISHED,RELATED, tendo de existir como regras de aceitação próprias. Só depois disso vale a pena aumentar o nf_conntrack_max. Quem começa por aumentar a tabela apenas adia o problema alguns minutos e gasta memória para isso.

Se os pacotes chegarem mais depressa do que o processo do servidor os levanta, transborda adicionalmente o buffer de receção do socket. Para os jogadores isso parece perda de pacotes, apesar de a linha estar livre:

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

Coloque os valores em /etc/sysctl.d/ e ative-os com sysctl --system. Se são necessários, é o kernel que o revela: se o UdpRcvbufErrors subir em nstat -az, ou se em ss -lunp houver permanentemente algo na fila de receção, então fazem efeito. Se ambos ficarem a zero, o ajuste não muda nada. Isto é reserva, não é proteção.

6. Enxurrada de entradas, fila de espera e whitelist

Uma enxurrada de entradas é um ataque em que o atacante usa o caminho normal de entrada para consumir lugares e tempo de processamento, em vez de encher a linha. Contra isso, o Unturned traz quatro ferramentas, todas na Commands.dat:

• Queue_Size 32 define a fila de espera. A predefinição são 8 lugares, o máximo é 64. Uma fila demasiado grande ajuda um atacante, uma fila demasiado pequena deita fora os jogadores verdadeiros a cada reinício.
• Whitelisted muda o servidor para lista de acesso. A inscrição faz-se pela consola com permit <SteamID64> e a remoção com unpermit <SteamID64>.
• Password ASuaPalavraPasse exclui tudo o que só tem o endereço porque o tirou de uma lista.
• Filter recusa jogadores com caracteres não permitidos no nome, e MaxPlayers 24 mantém o número de lugares naquilo que o hardware realmente suporta.

Uma whitelist protege a sua lógica de jogo, não a sua linha. 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.

7. RocketMod, OpenMod e o lado dos plugins

O Unturned tem duas plataformas de plugins difundidas, e ambas correm no mesmo processo que o servidor. O RocketMod é a mais antiga: os responsáveis originais encerraram a manutenção a 20 de dezembro de 2019 e colocaram o código-fonte sob a licença MIT. Desde então, a Smartly Dressed Games mantém o fork Legally Distinct Missile (LDM), que já vem incluído no Dedicated Server: copia-se o Rocket.Unturned da pasta Extras para a pasta Modules. Os programadores recomendam expressamente esse fork, porque corrige problemas antigos do Rocket, como erros de threading e exploits de teletransporte.

O OpenMod é o sucessor mais recente, desenvolvido por um dos responsáveis originais do Rocket. Não substitui o RocketMod, corre ao lado dele e pode aproveitar plugins Rocket existentes através de uma integração. Para a defesa, isto significa duas coisas.

Primeiro: cada plugin é superfície de ataque no processo principal. Um plugin que dispare uma consulta à base de dados a cada mensagem de chat ou a cada evento de jogo é uma negação de serviço construída em casa. Um único jogador que dispare um evento em ciclo deixa então o servidor inoperacional sem qualquer largura de banda. Mantenha curta a lista de plugins, prefira plugins de código aberto e meça a taxa de imagens do servidor depois de cada extensão.

Segundo: como o Unturned não tem uma porta de RCON própria, qualquer controlo remoto vem de um plugin. Verifique depois da instalação, com ss -lntp, que porta TCP ele abriu, e restrinja-a ao seu próprio endereço. Uma porta de controlo remoto aberta com uma palavra-passe fraca não é um problema de DDoS, é um problema de tomada de controlo.

8. Conteúdos da Workshop e o processo de entrada

Os conteúdos da Workshop tornam a entrada cara, e isso tem efeito direto sobre a vulnerabilidade. Tudo isso se controla através da WorkshopDownloadConfig.json, na mesma pasta Server:

{
    "File_IDs": [],
    "Ignore_Children_File_IDs": [],
    "Query_Cache_Max_Age_Seconds": 600,
    "Max_Query_Retries": 2,
    "Use_Cached_Downloads": true,
    "Should_Monitor_Updates": true,
    "Shutdown_Update_Detected_Timer": 600
}

Em File_IDs estão os identificadores da Workshop dos mapas e dos mods. No arranque, o servidor descarrega-os juntamente com as respetivas dependências, e cada jogador descarrega-os automaticamente ao ligar-se. Deve conhecer três consequências. Primeira: com listas de mods grandes, a entrada demora muito, e depois de um ataque todos os jogadores voltam ao mesmo tempo, o que sobrecarrega o servidor uma segunda vez. Segunda: o Should_Monitor_Updates para o servidor assim que um ficheiro da Workshop é atualizado, e o Shutdown_Update_Detected_Timer predefinido de 600 segundos leva então a um reinício que os operadores tomam regularmente, em caso de ataque, por um sucesso do atacante. Terceira: cada mod é código alheio no seu servidor.

Na prática, isso significa: mantenha a lista tão curta quanto possível, verifique após cada reinício inesperado se o registo do servidor traz a mensagem sobre a atualização da Workshop, e desligue o Should_Monitor_Updates apenas se planear as atualizações por si próprio.

9. Lista de servidores, código do servidor e a função Fake IP

O seu endereço IP não se consegue manter em segredo enquanto o servidor estiver listado publicamente. Qualquer jogador que se tenha ligado uma vez conhece-o, e as listas de terceiros publicam-no de qualquer forma. Ainda assim, dois hábitos ajudam: não publique você próprio o endereço em bruto em lado nenhum, e ligue os seus jogadores através de um hostname, para que uma mudança de endereço não quebre todas as referências. O clássico é o registo A esquecido a apontar para o endereço anterior, que torna inútil qualquer mudança.

Para o funcionamento na internet precisa de qualquer forma de um Game Server Login Token (GSLT) da gestão de servidores da Steam, para o identificador de aplicação 304930. Ele garante adicionalmente que o código do servidor do seu servidor se mantém igual ao longo dos reinícios, em vez de ser gerado de novo a cada arranque.

O Unturned oferece além disso uma função Fake IP. Liga-se com "Use_FakeIP": true na Config.json, e o comando de consola CopyFakeIP devolve o endereço que depois publica. O tráfego passa a correr pela rede de retransmissão Steam Datagram Relay, os endereços atribuídos situam-se entre 169.254.0.0 e 169.254.255.255, e o endereço verdadeiro do servidor deixa de ser mostrado aos jogadores. A Valve descreve esse tráfego como autenticado, cifrado e com limite de taxa.

O preço disso é alto e raramente é mencionado: o endereço e a porta mudam a cada reinício, um nome de domínio não se consegue apontar para ali sem scripts próprios, e as listas "Favoritos" e "Histórico" da Steam não funcionam com isso, apenas a função de marcadores. Sobretudo, porém, a função protege apenas o caminho do jogo. O seu servidor mantém o endereço verdadeiro, e o SSH, o painel web, a base de dados e o site continuam acessíveis por ele. Quem conhecer o endereço a partir de um registo DNS antigo, de uma página de estado ou de uma ligação anterior continua a atacá-lo diretamente. A função Fake IP não substitui, portanto, a filtragem na rede à frente do servidor, apenas reduz o número de pessoas que chegam a conhecer o seu endereço.

10. Registar dados para não ter de adivinhar durante o ataque

O passo mais importante é aquele que quase ninguém dá com antecedência: criar uma base de comparação enquanto tudo corre 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 uma sexta-feira à 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 udp portrange 27015-27016 -c 200 -q

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 avaliar os valores e distinguir um ataque de um erro de software está em Detetar um ataque DDoS no servidor.

Onde estas medidas acabam

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, ou seja, 125 megabytes por segundo, e a linha fica cheia assim que alguém enviar mais do que isso. O funcionamento normal fica muito abaixo disso: com 24 jogadores e os 50 pacotes por jogador e por segundo permitidos de fábrica, chegam cerca de 1 200 pacotes por segundo. Um serviço de booter gera um múltiplo disso sem qualquer preparação.

A segunda grandeza é a taxa de pacotes, e ela chega ao limite quase sempre 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 CPU 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".

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 incluída em cada 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 local é 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, 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 27015 UDP (as consultas) e o que é permitido na 27016 UDP (o tráfego de jogo), 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 apertando as consultas e deixando o tráfego de jogo intacto.
• Perfil de proteção adequado ao jogo, tal como para aplicações modificadas e próprias em quaisquer portas TCP ou UDP, ou seja, também para um plugin com porta própria.

Os dois níveis em comparação

Para a maioria dos projetos de Unturned, 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 e respetivas soluções

"O meu guia diz que tenho de abrir da 27015 à 27017": o guia é anterior a novembro de 2021. Desde a versão 3.21.30.0, um servidor Unturned só precisa de duas portas, porque a consulta da Steam deixou de estar na porta mais dois. Feche a 27017, a não ser que ali corra uma segunda instância.

"O servidor corre, mas já não está em nenhuma lista de servidores": esse é o quadro típico de uma enxurrada de consultas ou de uma regra própria demasiado severa na 27015 UDP. Verifique com iptables -L INPUT -n -v se a sua própria regra conta acertos. Se os contadores subirem muito, está a filtrar as suas próprias entradas nas listas. Nunca bloqueie a 27015 por completo.

"Todos os jogadores são expulsos ao mesmo tempo com timeout": veja primeiro se o seguimento de ligações transbordou (dmesg -T | grep -i conntrack). Se a tabela estiver cheia, o kernel descarta sem distinguir. O Timeout_Game_Seconds está de fábrica em 30 segundos: quem voltar dentro desse tempo mantém o seu lugar.

"O servidor reinicia a meio do funcionamento": raramente é um ataque. Verifique no registo a mensagem sobre a atualização da Workshop detetada. O Should_Monitor_Updates desliga o servidor ao fim do período predefinido de 600 segundos.

"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, normalmente de uma lista de servidores, de um bot do Discord ou de um registo DNS antigo. Mudar de endereço é ganhar tempo, não é uma solução.

"Liguei a função Fake IP e mesmo assim sou atacado": ela esconde o endereço dos novos jogadores, mas não o retira ao servidor. Quem o conhecer de uma entrada antiga numa lista, de uma página de estado ou de uma ligação anterior continua a chegar diretamente ao seu servidor, e também ao SSH e a qualquer painel web nele.

"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 Unturned precisa de exatamente duas portas UDP abertas: a Port definida na Commands.dat (predefinição 27015) e esse valor mais um (27016). O jogo em si não precisa de TCP.
• A porta 27017 é supérflua desde a versão 3.21.30.0, de 21 de novembro de 2021, porque a consulta da Steam deixou de estar na porta mais dois. Quem ainda a tem aberta está a seguir um guia desatualizado.
• O Unturned não tem uma porta de RCON integrada. Qualquer controlo remoto vem de um plugin, traz consigo uma porta TCP própria e tem de ser restringido por si.
• A porta de consulta 27015 é o ponto mais sensível: uma enxurrada de consultas torna o servidor invisível na lista de servidores sem atingir um único jogador, e o protocolo Steam tem, segundo o US-CERT TA14-017A, um fator de amplificação de 5,5.
• Os limites da Config.json (Max_Packets_Per_Second 50,0, Rate_Limit_Kick_Threshold 10 por cada 40 segundos) atuam apenas contra clientes que entram de facto, não contra endereços de origem falsificados.
• Uma linha de 1 Gbit/s fica cheia com 125 megabytes por segundo e, com pacotes de 64 bytes, já com cerca de 1,49 milhões de pacotes por segundo. O funcionamento normal com 24 jogadores fica em cerca de 1 200 pacotes por segundo. Tudo acima disso decide-se na rede à frente do servidor, não na sua firewall.
• Na KernelHost, a proteção permanente em dois níveis está incluída em cada pacote de servidor sem sobretaxa e fica ativa a partir da disponibilização, sem null-routing. Quem quiser controlar por si próprio as regras de filtragem junta a Advanced DDoS Protection a partir de 50,00 EUR por mês.

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.