Proteger o servidor Mordhau contra ataques DDoS

Um servidor Mordhau que a meio de uma ronda de Frontline perde todos os jogadores de uma só vez, fica offline durante alguns minutos e deixa de aparecer na lista de servidores raramente tem um problema de hardware. Na esmagadora maioria dos casos está a decorrer um ataque contra uma das quatro portas UDP que um servidor dedicado de Mordhau tem de manter abertas para o exterior. Este artigo mostra primeiro o que pode tratar por conta própria e sem custos adicionais na proteção DDoS do Mordhau, depois onde estas medidas terminam por razões físicas e, por fim, o que tem de acontecer na rede à frente do servidor.

Todas as indicações se referem ao servidor dedicado oficial de Mordhau (Steam App ID 629800, Unreal Engine 4) 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 primeiro nada na configuração e não reinicie o servidor, guarde antes os valores medidos (secção 9), porque depois do ataque desaparecem. No Mordhau junta-se uma segunda razão, que muitos operadores aprendem da forma mais dolorosa: ao terminar, o processo do servidor escreve o estado que tem em memória de volta no Game.ini. Quem editar o ficheiro com o servidor a correr perde as suas alterações na paragem seguinte.

Porque é que os servidores Mordhau precisam de proteção DDoS e quem os ataca

Os servidores Mordhau são atacados porque o seu endereço é público, porque todo o tráfego de jogo corre sobre UDP e porque uma falha fica imediatamente visível para toda a gente. A entrada no navegador de servidores contém o endereço IP e a porta de jogo em texto simples, porque de outra forma os jogadores não conseguiriam encontrar o servidor. As listas de servidores públicas e os trackers recolhem os mesmos dados através da porta de consulta da Steam e publicam-nos uma segunda vez. O seu endereço não é, portanto, um segredo, é uma indicação de produto.

A isto acresce a técnica do jogo. O Unreal Engine 4 transmite movimentos, golpes e defesas sobre UDP. O UDP não tem um estabelecimento de ligação que se possa exigir e o endereço de origem de um pacote UDP falsifica-se com facilidade. Um atacante não precisa, portanto, de entrar no seu servidor nem de o contactar corretamente para lhe gerar carga. No Mordhau isso pesa mais do que em muitos outros jogos: um confronto decide-se na ordem de poucas décimas de segundo, e apenas 200 milissegundos de atraso adicional tornam o combate corpo a corpo injogável, muito antes de o servidor falhar de facto. É precisamente por isso que basta um ataque pequeno para destruir uma ronda. O que é em detalhe um ataque DDoS fica explicado no artigo O que é um ataque DDoS?.

Os motivos habituais são pouco espetaculares: concorrência entre comunidades, jogadores banidos, duelos perdidos, discussões no Discord. Um ataque não custa a quem o encomenda nem competência nem dinheiro digno de nota, porque são serviços de booter alugados que fazem o trabalho. Os operadores relatam com regularidade que os ataques começam exatamente quando o servidor está cheio e param assim que ele fica vazio. Isso não é coincidência, é um indício de que alguém está a observar a sua entrada no navegador de servidores e usa o número de jogadores como gatilho.

As portas que no Mordhau realmente contam

Um servidor dedicado de Mordhau precisa de exatamente quatro portas UDP para o exterior: 7777, 7778, 15000 e 27015. Todo o resto é opcional ou não pertence à rede aberta. As portas são passadas como parâmetros no arranque:

./MordhauServer.sh FFA_ThePit -log -Port=7777 -QueryPort=27015 -BeaconPort=15000 -RconPort=27020

Duas coisas são regularmente mal entendidas. Primeira: a porta de beacon 15000 não é um acessório. O beacon reserva o slot no momento em que um jogador entra, para que este não volte a ser expulso depois de carregar o mapa. Se a 15000 estiver bloqueada ou sobrecarregada, os jogadores deixam de conseguir entrar, mesmo com a porta 7777 a responder. Segunda: o RCON não vem pré-configurado no Mordhau. Só fica ativo quando define RconPassword e RconPort, e corre então sobre TCP, não sobre UDP.

Os indicadores mais importantes de um servidor Mordhau num relance:

Os padrões de ataque que ocorrem no Mordhau

Quatro padrões cobrem praticamente tudo o que é usado contra um servidor Mordhau, e cada um atinge uma porta diferente.

• Flood UDP contra a porta de jogo 7777. Este é o ataque padrão de um booter: o maior número possível de pacotes falsificados contra a porta que consta da lista de servidores. Visa a largura de banda e a taxa de pacotes, não uma vulnerabilidade, e manifesta-se primeiro como picos de lag, muito antes de alguém perder a ligação.
• Flood de consultas contra a porta de consulta 27015. Uma consulta A2S_INFO tem 25 bytes, a resposta com nome do servidor, mapa, modo de jogo e número de jogadores é um múltiplo disso. O atacante investe pouco e força do seu lado trabalho de processamento e tráfego de saída.
• Reflection através da sua própria porta de consulta. Aqui o seu servidor não é o alvo, é a ferramenta: o atacante envia consultas com o endereço de origem falsificado e o seu servidor responde à vítima. Isso nota-se como um tráfego de saída inexplicavelmente alto na 27015 e como uma comunicação de abuso do seu fornecedor.
• Esgotamento de entradas e de slots através da porta de beacon 15000. Em vez de queimar largura de banda, entradas automatizadas ocupam os slots reservados. O servidor continua a correr, mas está cheio, e os jogadores reais deixam de conseguir entrar.

A isto junta-se um quinto padrão, assim que o RCON fica aberto na rede: tentativas de autenticação ao ritmo de segundos contra a porta de RCON. Raramente é volumétrico, mas custa tempo de processamento, e é o único dos cinco casos em que um acerto lhe tira o servidor por completo das mãos.

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

Esta secção é a mais longa, e isso é intencional. Um servidor Mordhau 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 no servidor?

Antes de escrever uma única regra de firewall, 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:7777 e [::]:7777 significam "acessível a partir de toda a internet", 127.0.0.1:27020 significa "apenas local" e não precisa de regra de firewall. Além do jogo, aparecem ali muitas vezes um painel web, um serviço de base de dados e um serviço de voz há muito esquecido. A perspetiva do atacante obtém-se com um scan a partir de fora, em UDP com uma lista curta de portas, porque um scan UDP completo é muito lento:

nmap -Pn -sU -p 7777,7778,15000,27015 IP.DO.SEU.SERVIDOR
nmap -Pn -p- --min-rate 1000 IP.DO.SEU.SERVIDOR

2. Deixar abertas apenas as quatro portas de que o Mordhau precisa mesmo

Para o Mordhau bastam quatro aberturas UDP para o exterior, tudo o resto fica restringido ou nem sequer chega a ser publicado. 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 7777/udp comment 'Mordhau jogo'
ufw allow 7778/udp comment 'Mordhau Steam'
ufw allow 15000/udp comment 'Mordhau beacon'
ufw allow 27015/udp comment 'Mordhau consulta'
ufw allow from 203.0.113.10 to any port 27020 proto tcp comment 'Mordhau RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Substitua 203.0.113.10 pelo seu próprio endereço. Importante é o que aqui não consta: nenhuma abertura para um painel web, nenhuma para uma base de dados, nenhuma para um servidor de ficheiros. Cada porta aberta a mais é um alvo a mais que nada tem a ver com o jogo. As instruções completas, incluindo o caminho de recuperação, encontram-se em Configurar a firewall UFW sem se trancar fora do servidor.

3. Limitar a porta de consulta 27015 sem cair da lista de servidores

A porta de consulta pode ser limitada, mas não fechada. Se a 27015 UDP for fechada, o seu servidor desaparece do navegador de servidores, porque o número de jogadores, o nome do mapa e o nome do servidor são lidos exatamente por esta porta. Um limite máximo por endereço de origem resolve o problema sem custar visibilidade:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name mh_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Um navegador de servidores normal consulta o seu servidor algumas vezes por minuto, não algumas vezes por segundo. Dez consultas por segundo e por endereço de origem são, portanto, generosas para qualquer jogador e apertadas para qualquer bot. Verifique depois no contador de correspondências se a regra chega sequer a atuar:

iptables -L INPUT -n -v | head -20
tcpdump -ni eth0 udp port 27015 -c 200 -q

Aqui está também a resposta à questão da reflection. Numa reflection o seu servidor não é atacado, é abusado como amplificador: as consultas chegam com o endereço de origem falsificado e as suas respostas atingem uma vítima alheia. A limitação de taxa por endereço de origem é a medida local mais eficaz contra isso, porque um endereço de origem falsificado só é útil enquanto o seu servidor responder de boa vontade e sem limite.

4. Retirar o RCON da rede aberta

No Mordhau o RCON não pertence em caso algum à internet sem restrições. O acesso é ligado no Game.ini, na secção [/Script/Mordhau.MordhauGameSession]:

[/Script/Mordhau.MordhauGameSession]
ServerName=O meu servidor Mordhau
MaxSlots=64
ServerPassword=
AdminPassword=UmaPalavraPasseLongaAleatoria
RconPassword=OutraPalavraPasseLongaAleatoria
RconPort=27020

O Mordhau fala o protocolo Source RCON, ou seja, TCP, e funciona por isso com qualquer ferramenta de RCON corrente. É precisamente isso que aproveitam também os scripts que vão testando credenciais. Três regras cobrem o caso. Primeira: RconPassword e AdminPassword são duas palavras-passe diferentes, longas e aleatórias, e não variações do nome do servidor. Segunda: restrinja a abertura da porta de RCON ao seu próprio endereço, tal como no bloco de UFW acima. Terceira, se não tiver um endereço fixo: mantenha a porta fechada a partir do exterior e chegue até ela através de um encaminhamento de porta por SSH, ligando-se depois localmente a 127.0.0.1:27020:

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

Se o RCON tiver mesmo de continuar aberto, limite pelo menos as ligações simultâneas por endereço de origem. Uma ferramenta de RCON precisa de uma ligação, um script de força bruta precisa de centenas:

iptables -I INPUT -p tcp --dport 27020 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

5. Proteger a porta de beacon 15000 contra floods de entrada

A porta de beacon é o ponto de ataque subestimado de um servidor Mordhau. Através dela o jogo reserva o slot de um jogador que está a entrar, enquanto este ainda carrega. Um bot que dispare entradas em sequência rápida ocupa assim os slots sem nunca chegar ao jogo. O servidor mantém-se online e, ainda assim, parece cheio. Um limite máximo por endereço de origem trava isso, porque um jogador real faz beacon exatamente uma vez por entrada e não vinte vezes por segundo:

iptables -I INPUT -p udp --dport 15000 -m hashlimit --hashlimit-name mh_beacon --hashlimit-mode srcip --hashlimit-above 20/sec --hashlimit-burst 40 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name mh_game --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

A segunda regra diz respeito à porta de jogo e exige bom senso. Com uma tickrate de 60, o servidor troca com cada jogador ligado algo na ordem de 60 pacotes por segundo em cada sentido. Um limite de 400 pacotes por segundo e por endereço de origem deixa, portanto, folga suficiente a qualquer jogador real e atinge, mesmo assim, qualquer origem que esteja claramente a inundar. Meça primeiro durante uma semana em funcionamento normal antes de apertar: quem aperta demasiado expulsa os seus próprios jogadores e toma isso depois por um ataque.

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

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

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

6. Game.ini e Engine.ini: o que traz mesmo alguma coisa

O Mordhau tem dois ficheiros de configuração, e ambos estão no Linux em Mordhau/Saved/Config/LinuxServer/ e no Windows em Mordhau\Saved\Config\WindowsServer\. O Game.ini regula o nome do servidor, os slots, as palavras-passe, a lista de administradores, a rotação de mapas e os identificadores dos mods do mod.io; o Engine.ini regula o comportamento de rede. Edite ambos exclusivamente com o servidor parado, caso contrário o processo do servidor sobrescreve as suas alterações ao terminar, com o estado que tem em memória.

Três definições são realmente relevantes para a superfície de ataque. Primeira, uma ServerPassword: mantém afastado quem não foi convidado, mas custa a descoberta pública e não ajuda absolutamente nada contra um flood na porta 7777, porque o atacante nem sequer quer entrar. Segunda, um número realista em MaxSlots: o Mordhau está concebido para até 64 jogadores, e cada slot adicional é uma fonte de pacotes adicional que o seu CPU tem de servir. Terceira, a tickrate no Engine.ini:

[/Script/OnlineSubsystemUtils.IpNetDriver]
NetServerMaxTickRate=60
LanServerMaxTickRate=60

[IpDrv.TcpNetDriver]
NetServerMaxTickRate=60

A tickrate predefinida de um servidor Mordhau é 60. Um aumento para 120 duplica a taxa de pacotes por jogador e a carga de CPU, e é exatamente aquilo de que não precisa sob ataque. Um servidor de 64 slots com tickrate 120 gera, já em funcionamento normal, algo na ordem de 8000 pacotes por segundo em cada sentido. Quem é alvejado de forma continuada corre visivelmente mais estável com 60 do que com 120.

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

Um estrangulamento muitas vezes ignorado é o seguimento de ligações do kernel. Ele mantém uma entrada própria para cada fluxo UDP, e um flood vindo de dezenas de milhares de endereços de origem falsificados enche a tabela em segundos. Se ela encher, o servidor passa a descartar também pacotes legítimos e no registo aparece "nf_conntrack: table full". O estado atual e o limite máximo são mostrados por:

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

Contra isso ajudam duas coisas. Ou aumenta o limite máximo, ou retira as portas de jogo por completo do seguimento. Num gameserver esta segunda via é normalmente a melhor, porque o UDP não tem, de qualquer forma, um estado que fosse preciso seguir:

iptables -t raw -I PREROUTING -p udp --dport 7777 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 15000 -j NOTRACK
iptables -t raw -I PREROUTING -p udp --dport 27015 -j NOTRACK

Igualmente sensatos são buffers de receção maiores e uma fila mais profunda na placa de rede, para que picos curtos não levem imediatamente a descartes:

sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=4194304
sysctl -w net.core.netdev_max_backlog=5000

De forma permanente, estes valores pertencem a um ficheiro em /etc/sysctl.d/, por exemplo 99-gameserver.conf. Importante para perceber: buffers maiores não aumentam a sua resistência a um ataque grande, apenas evitam que um pico curto já custe pacotes.

8. O seu endereço consta da lista de servidores, e isso não se muda

Aqui compensa mais a honestidade do que o pensamento mágico: o endereço IP de um servidor Mordhau público não se consegue manter em segredo. Consta da entrada no navegador de servidores, consta das listas de servidores públicas de terceiros, que leem a porta de consulta com regularidade, e qualquer jogador que se tenha ligado uma vez conhece-o. Mudar de endereço dá, por isso, horas, raramente dias, porque o atacante encontra o novo endereço pelo mesmo caminho que encontrou o antigo.

Eficazes são três hábitos. Não publique o endereço IP em bruto em lado nenhum, ou seja, nem no canal de Discord nem na página do projeto. Ligue os seus jogadores através de um hostname, para que em caso de necessidade uma mudança de endereço não quebre todas as referências. E limpe os registos DNS antigos, porque um registo A esquecido a apontar para o endereço anterior torna qualquer mudança inútil. O mesmo vale para servidores de teste: qualquer segundo servidor acessível publicamente na mesma máquina revela o endereço do servidor principal.

9. Medir enquanto tudo corre normalmente

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

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 'udp port 7777 or udp port 15000 or udp port 27015' -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. Preste especial atenção aos contadores de descarte de ip -s link. Valores dropped a subir com o CPU simultaneamente tranquilo são o indício mais claro de que o problema é a taxa de pacotes e não a capacidade de processamento. Como avaliar os valores está em Detetar um ataque DDoS. Como instalar e manter atualizado o servidor de forma limpa com o SteamCMD é descrito em Instalar um servidor de jogos com o SteamCMD.

Onde estas medidas terminam: largura de banda e taxa de pacotes

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

Faça as contas connosco. Um gameserver típico está ligado a 1 Gbit/s, o que corresponde a 125 megabytes por segundo, e a linha fica cheia assim que alguém enviar mais do que isso. Um servidor Mordhau cheio com 64 slots precisa apenas de uma fração disso: com tickrate 60, o tráfego de jogo situa-se na ordem de 4000 pacotes por segundo em cada sentido. Um booter alugado entrega, em contrapartida, sem dificuldade entre 5 e 50 Gbit/s, ou seja, entre cinco e cinquenta vezes a sua linha. Nessa altura já não interessa se a sua regra de iptables por trás é boa, porque os pacotes dos seus jogadores nem chegam a passar.

A segunda grandeza é a taxa de pacotes, e muitas vezes ela chega ao limite antes da largura de banda. Com pacotes pequenos de 64 bytes cabem numa linha de 1 Gbit/s cerca de 1,49 milhões de pacotes por segundo. Um kernel de servidor normal processa, consoante o 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, portanto, deixar o seu servidor Mordhau 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 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.

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 servidores Mordhau sob fogo permanente

Alguns servidores 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 separadamente o que é permitido na 7777 UDP, o que é permitido na 15000 UDP e o que é permitido na 27015 UDP, sem ter de escrever um ticket para isso.
• As alterações entram em vigor em tempo real, pelo que pode afinar durante um ataque em curso em vez de esperar por uma janela de manutenção.
• Perfil de proteção adequado ao jogo. Para gameservers em Unreal Engine sobre UDP e para portas de consulta da Steam existem perfis prontos a usar, tal como para aplicações modificadas e próprias em quaisquer portas TCP ou UDP.

A Advanced DDoS Protection dirige-se a servidores que correm na KernelHost. Se o seu servidor Mordhau estiver neste momento noutro sítio e for regularmente atirado para fora da rede, a mudança é o caminho para esta filtragem.

Os dois níveis em comparação

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

Erros frequentes e respetivas soluções

"Fechei a porta 27015 e agora o meu servidor já não aparece na lista": essa é a consequência esperada. A porta de consulta da Steam entrega nome, mapa e número de jogadores ao navegador de servidores. Sem ela, o seu servidor deixa de aparecer ou passa a constar como inacessível. O correto é uma limitação de taxa por endereço de origem em vez de um bloqueio.

"Os jogadores não conseguem entrar, apesar de o servidor estar a correr": verifique primeiro a porta 15000 UDP. O beacon reserva o slot durante o carregamento. Se estiver bloqueada, filtrada com demasiado aperto ou sobrecarregada, a entrada fica pendurada, mesmo com a porta 7777 a responder e com o servidor a constar do navegador.

"As minhas alterações no Game.ini desaparecem depois do reinício": editou o ficheiro com o servidor a correr. Ao terminar, o processo do servidor Mordhau escreve de volta o estado que tem em memória e sobrescreve com isso a sua versão. Parar o servidor, editar, arrancar, exatamente por esta ordem.

"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 há muito. 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á a correr, mas todos têm picos de lag e os golpes chegam tarde": veja primeiro se a taxa de pacotes de entrada sobe enquanto o CPU se mantém tranquilo. Esse é exatamente o padrão de um ataque. Se a taxa de pacotes se mantiver normal e o CPU estiver a 100 por cento, não é um ataque DDoS, mas sim, na maioria dos casos, uma tickrate demasiado alta, slots a mais ou um mod.

"O meu fornecedor comunica abuso de saída na porta 27015": o seu servidor foi abusado como amplificador para uma reflection. As consultas chegaram com o endereço de origem falsificado e quem respondeu a uma vítima alheia foi o seu servidor. Uma limitação de taxa na 27015 UDP por endereço de origem põe fim a isso.

"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 dedicado de Mordhau precisa de exatamente quatro portas UDP para o exterior: 7777 (jogo), 7778 (Steam), 15000 (beacon) e 27015 (consulta da Steam). Todo o resto fica fechado.
• No Mordhau o RCON corre sobre TCP segundo o protocolo Source RCON e só fica ativo através de RconPassword e RconPort no Game.ini. Restrinja a porta ao seu próprio endereço.
• A porta 27015 UDP pode ser limitada, mas não fechada: sem ela o seu servidor desaparece do navegador de servidores, porque o número de jogadores, o mapa e o nome são lidos por esta porta.
• A porta 15000 UDP é a porta de beacon e reserva o slot durante o carregamento. Se estiver bloqueada ou sobrecarregada, os jogadores não conseguem entrar, apesar de o servidor estar a correr.
• Edite o Game.ini e o Engine.ini apenas com o servidor parado, porque ao terminar o processo do servidor escreve de volta o estado que tem em memória.
• As regras locais de firewall terminam na largura de banda: 1 Gbit/s são 125 megabytes por segundo e, com pacotes de 64 bytes, cerca de 1,49 milhões de pacotes por segundo. Acima disso, quem decide é exclusivamente a rede à frente do servidor.
• 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. Quem quiser controlar a filtragem por si próprio obtém isso com a Advanced DDoS Protection a partir de 50,00 EUR por mês.

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