Proteger um servidor de DayZ contra ataques DDoS

Um servidor de DayZ que à noite atira todos os jogadores para fora a meio do jogo e desaparece do browser de servidores durante minutos raramente tem um problema de hardware. Na maioria dos casos está a decorrer um ataque, e precisamente quando há mais jogadores online ou quando se aproxima o reinício planeado. Quem quer proteger o seu servidor de DayZ contra ataques DDoS precisa por isso das duas coisas: uma abertura de portas limpa no servidor e uma filtragem na rede à frente. Este artigo mostra primeiro o que pode proteger por conta própria e sem custos adicionais, depois onde estas medidas terminam do ponto de vista técnico e, por fim, o que tem de acontecer à frente do servidor.

Todas as indicações se referem a um servidor dedicado de DayZ com serverDZ.cfg, quer corra em Windows Server, quer corra em Debian e Ubuntu através de uma camada de compatibilidade. A Bohemia Interactive não disponibiliza um programa de servidor nativo para Linux pronto para produção no ramo estável, e o build experimental para Linux só aceita clientes experimentais. Os comandos de Linux estão escritos para root; como utilizador normal, anteponha sudo.

Se o ataque estiver a decorrer neste momento: não altere agora nada na serverDZ.cfg e não reinicie o servidor. Um reinício de DayZ volta a carregar os mods e a economia central e custa-lhe vários minutos em que o servidor fica garantidamente offline. Guarde primeiro os valores medidos (ver a secção "Registar em log"), porque depois do ataque desaparecem.

Porque é que os servidores de DayZ são tantas vezes alvo de ataques DDoS

O DayZ reúne várias características que fazem de um servidor um alvo cómodo. Em primeiro lugar, um servidor de comunidade publica o seu endereço por iniciativa própria: para aparecer no browser de servidores do jogo e no DZSA Launcher tem de responder a consultas da Steam, e essa resposta contém o endereço IP e a porta em texto simples. Um atacante não precisa, portanto, de descobrir seja o que for, basta-lhe ler uma lista.

Em segundo lugar, o dia a dia de um servidor de DayZ é público. Praticamente todos os projetos reiniciam automaticamente de três em três ou de quatro em quatro horas, anunciam-no por mensagem no chat e escrevem o plano no Discord. Um ataque que caia exatamente nessa janela tem efeito duplo: o servidor já está inacessível de qualquer forma e os jogadores que ficam à espera vão para outro lado.

Em terceiro lugar, o que está em jogo para os jogadores é muito. No DayZ, uma falha no minuto errado não significa apenas frustração, significa equipamento perdido, raids interrompidos e uma base que fica desprotegida no mundo. É precisamente por isso que os jogadores banidos, os grupos rivais e os projetos concorrentes são os mandantes mais frequentes. Um ataque através de um dos habituais serviços de booter não custa a quem o desencadeia nem competência nem dinheiro digno de nota.

Em quarto lugar, todo o tráfego do DayZ corre sobre UDP. O UDP não tem um estabelecimento de ligação que se possa exigir e o endereço de origem falsifica-se com facilidade. Um atacante não precisa, portanto, de entrar no seu servidor nem de o contactar corretamente para lhe gerar carga. Que nem o próprio fabricante escapa a isto ficou demonstrado em fevereiro de 2025: os serviços online da Bohemia Interactive para o DayZ e para o Arma Reforger estiveram mais de uma semana sob fogo DDoS, confirmado a 3 de fevereiro de 2025 e ainda não terminado a 6 de fevereiro de 2025, e os servidores de comunidade foram afetados em conjunto. O que é em detalhe um ataque DDoS fica explicado no artigo O que é um ataque DDoS?.

As portas de um servidor de DayZ: tabela de factos

Um servidor de DayZ fala exclusivamente UDP. Não existe uma porta de jogo em TCP. O único valor que no DayZ está mesmo fixo é a 2302/UDP como porta de jogo, tudo o resto é configurável e difere consoante o fornecedor de alojamento. Veja por isso na sua própria linha de arranque e na sua própria serverDZ.cfg, em vez de confiar num valor predefinido.

Há dois valores que geram confusão com regularidade, por isso aqui fica o esclarecimento. O Steam Query Port: a configuração de exemplo fornecida pela Bohemia define steamQueryPort = 2305;, ao passo que uma grande parte dos fornecedores de alojamento usa 27016/UDP. Ambos os valores são válidos, o que conta é apenas o valor que está no seu ficheiro. A porta de RCon do BattlEye: aqui não existe sequer um valor predefinido obrigatório. A regra prática mais divulgada é a porta de jogo mais três, ou seja, 2305, mas outros fornecedores definem 2310. Desde o DayZ 1.13 que o BattlEye avalia de forma fiável o parâmetro RConPort na BEServer_x64.cfg; antes disso a porta era difícil de prever.

Daqui resulta uma armadilha que apanha muitos operadores: nunca defina steamQueryPort e RConPort com o mesmo valor. Se a sua configuração previr a 2305 para a consulta da Steam, o RCon pertence a outra porta, por exemplo a 2310.

Porque é que o Steam Query Port é a porta mais sensível

O Steam Query Port responde às três consultas A2S_INFO, A2S_PLAYERS e A2S_RULES. A A2S_INFO devolve o nome do servidor, o mapa, o número de jogadores e a versão, a A2S_PLAYERS os nomes dos jogadores ligados e a A2S_RULES as variáveis de servidor definidas. Cada uma destas respostas é bastante maior do que o pedido que a desencadeou, e é precisamente isso que torna a porta duplamente perigosa.

Para si, enquanto alvo, significa o seguinte: um atacante consegue ocupar o seu Query Port com poucos bytes por pedido, enquanto o seu servidor monta e envia de cada vez uma resposta completa. Para terceiros significa outra coisa: um atacante consegue consultar o seu servidor com um endereço de origem falsificado e dirigir as respostas para o alvo que realmente tem em vista. O seu servidor deixa então de ser apenas vítima e passa também a amplificador. Foi por isso que a Valve acrescentou à A2S_INFO, em dezembro de 2020, uma consulta de desafio: o servidor responde primeiro com um número aleatório que quem pergunta tem de devolver. Isso atenua a amplificação, mas não acaba com ela, porque nem todas as consultas seguem esse caminho.

O DayZ tem aqui uma particularidade que outros jogos não têm: são duas listas de servidores separadas que o consultam, o browser de servidores de comunidade integrado e o muito difundido DZSA Launcher. Fechar simplesmente o Query Port não é, por isso, uma opção, porque assim o seu projeto desaparece de ambas as listas, apesar de a ligação direta continuar a funcionar. Limitar em vez de fechar é a resposta certa.

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

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

1. Levantamento: que portas o seu servidor de DayZ abre mesmo

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

ss -lnup
ss -lntup

No Windows Server, a linha de comandos dá o mesmo quadro:

netstat -ano -p UDP | findstr "2302 2303 2304 2305 27016"

O interessante é a coluna com o endereço local. 0.0.0.0:2302 significa "acessível a partir de toda a internet", 127.0.0.1:2310 significa "apenas local" e não precisa de abertura. A seguir, leia os valores efetivos diretamente nos seus ficheiros de configuração, em vez de confiar num guia:

grep -iE "steamQueryPort|maxPlayers|password|enableWhitelist|verifySignatures" serverDZ.cfg
grep -iE "RConPort|RestrictRCon" battleye/BEServer_x64.cfg

A perspetiva do atacante obtém-se com um scan de portas UDP a partir de fora, executado a partir de outra máquina:

nmap -Pn -sU -p 2302-2310,27015-27020 IP.DO.SEU.SERVIDOR

2. Abrir apenas o que a linha de arranque e a serverDZ.cfg precisam mesmo

Para o DayZ bastam duas aberturas para o exterior: o bloco da porta de jogo e o Query Port. Tudo o resto é restringido ao seu próprio endereço ou nem sequer chega a ser publicado. Com a 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 2302:2305/udp comment 'DayZ porta de jogo'
ufw allow 27016/udp comment 'DayZ Steam Query'
ufw allow from 203.0.113.10 to any port 2310 proto udp comment 'BattlEye 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 e 27016 pelo valor que está mesmo na sua linha steamQueryPort. As instruções completas, incluindo o caminho de recuperação, encontram-se em Configurar a firewall UFW sem se trancar fora do servidor. Num servidor Windows vale o mesmo princípio: uma regra de entrada por grupo de portas, o Ambiente de Trabalho Remoto limitado ao seu próprio endereço e todo o resto bloqueado.

3. Limitar o Steam Query Port em vez de o fechar

Um limite máximo por endereço de origem separa as listas de servidores reais das avalanches de consultas. Um browser de servidores consulta-o ao ritmo de segundos, um atacante ao ritmo de milissegundos:

iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name dayz_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name dayz_game --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

A primeira regra descarta consultas da Steam a partir de mais de dez por segundo, de forma continuada, vindas da mesma origem; a segunda descarta pacotes de jogo a partir de mais de 600 por segundo. Os dois números são valores de partida, não verdades absolutas. Um servidor cheio com 60 jogadores gera bastante mais pacotes do que um vazio, e quem aperta demasiado expulsa os seus próprios jogadores ou desaparece da lista de servidores. Meça primeiro durante uma semana em funcionamento normal.

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 a UFW, regras destas pertencem ao /etc/ufw/before.rules, porque de outra forma desaparecem no ufw reload seguinte. Além disso, a biblioteca de servidor da Steam tem um travão próprio para pacotes sem ligação: a variável de ambiente STEAM_GAMESERVER_RATE_LIMIT_200MS descarta todos os pacotes A2S de um endereço assim que, numa janela de 200 milissegundos, chegar mais do que o valor definido.

O terceiro ponto não custa nada: se o seu bot do Discord ou a sua página de projeto mostrar o número de jogadores, não consulte o servidor a partir do visitante, guarde antes o resultado em cache a intervalos fixos. Assim, uma página de estado muito visitada gera uma consulta por intervalo em vez de uma por visitante.

4. Tirar o RCon do BattlEye da rede aberta

O BattlEye é a componente anti-cheat do DayZ e liga-se na serverDZ.cfg com BattlEye = 1;. A administração remota fica, pelo contrário, num ficheiro próprio, a BEServer_x64.cfg, no diretório do BattlEye ao lado da BEServer_x64.dll, diretório esse que a linha de arranque define com -BEpath=:

RConPassword UmaPalavraPasseLongaEAleatoria
RConPort 2310
RestrictRCon 0

Três regras a este respeito. Primeira: a porta de RCon é UDP, não TCP. Uma regra de firewall que diga por engano proto tcp não filtra nada e ao mesmo tempo faz com que as ferramentas de administração não cheguem a lado nenhum. Segunda: restrinja a porta aos endereços dos seus administradores. Quem não tem um endereço fixo fecha a porta completamente ao exterior e arranca a ferramenta de administração diretamente no servidor, acessível por SSH ou por Ambiente de Trabalho Remoto. Terceira: o RestrictRCon 1 limita os comandos executáveis por RCon e é a definição certa assim que mais do que uma pessoa tem acesso.

Uma porta de RCon aberta é duas coisas ao mesmo tempo: um convite a experimentar palavras-passe e mais uma porta UDP que se pode inundar. Ambas desaparecem assim que a abertura passar a valer apenas para um punhado de endereços.

5. Fila de espera de entrada, whitelist e esgotamento de slots

O DayZ não processa todas as ligações ao mesmo tempo, processa-as através de uma fila de espera. Cinco valores na serverDZ.cfg controlam-na:

maxPlayers = 60;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 100;
guaranteedSlots = 10;
maxPing = 200;

O loginQueueConcurrentPlayers define quantos jogadores entram ao mesmo tempo (predefinição 5) e o loginQueueMaxPlayers limita a própria fila de espera (valores habituais entre 100 e 500). É exatamente aqui que atua o esgotamento de slots: um atacante não precisa de largura de banda, só precisa de contas ou de tentativas de ligação em número suficiente para ocupar a fila. Os jogadores reais deixam então de conseguir entrar, apesar de o servidor estar a funcionar sem qualquer falha técnica. O guaranteedSlots reserva lugares para a sua equipa, para que nessa situação consiga ainda entrar no servidor.

Contra isso ajuda a whitelist integrada. É ativada com enableWhitelist = 1; e lê em seguida o ficheiro profiles/whitelist.txt, com um Steam64 ID por linha. Qualquer ID não listado é recusado na ligação. O ficheiro é lido no arranque do servidor, pelo que as alterações precisam de um reinício. Uma password adicional na serverDZ.cfg tem efeito parecido, mas é mais fraca, porque uma palavra-passe passa de mão em mão e um Steam64 ID não.

Uma coisa tem de ficar clara: uma whitelist protege os seus lugares de jogador, não a sua linha. Um atacante que inunda o seu servidor não quer entrar. Os pacotes dele são recusados, mas mesmo assim chegaram, e é precisamente esse o ponto.

6. Mods, verificação de assinaturas e a janela de tempo depois do reinício

No DayZ, os mods não são apenas um tema de conforto, são parte da superfície de ataque. Quatro definições na serverDZ.cfg devem estar sempre configuradas:

verifySignatures = 2;
forceSameBuild = 1;
allowFilePatching = 0;
BattlEye = 1;

O verifySignatures = 2 verifica cada ficheiro PBO contra a respetiva assinatura .bisign e precisa para isso dos ficheiros .bikey correspondentes na pasta keys. O forceSameBuild = 1 exige exatamente a mesma versão do jogo que está no servidor. O allowFilePatching = 0 recusa clientes que arranquem com ficheiros de jogo alterados. Nenhuma destas definições trava um ataque volumétrico, mas as três fecham o caminho pelo qual um cliente manipulado desequilibra o seu servidor.

O segundo ponto é o mais importante e é quase sempre ignorado: a fase de arranque. Ao arrancar, um servidor de DayZ carrega primeiro a lista de mods a partir da linha de arranque e depois a economia central com todas as tabelas de loot. Num servidor com muitos mods isso são facilmente vários minutos, durante os quais o servidor não responde a uma única consulta da Steam:

./DayZServer -config=serverDZ.cfg -port=2302 -profiles=./profiles -BEpath=./battleye -mod=@CF;@OSeuMod;@OutroMod -cpuCount=4 -dologs -adminlog -netlog -freezecheck

Como praticamente todos os projetos reiniciam de três em três ou de quatro em quatro horas e ainda anunciam esse plano, a janela de tempo é trivial de acertar para um atacante. Três contramedidas são eficazes e não custam nada. Mantenha a lista de mods o mais curta possível, porque cada mod adicional prolonga exatamente essa janela. Coloque as horas de reinício em valores quebrados em vez de na hora certa. E meça uma vez quanto tempo o seu arranque demora mesmo, em vez de estimar: com timeStampFormat = "Full"; e um logFile definido, a duração fica depois registada no log.

7. Seguimento de ligações, buffers de receção e parâmetros do kernel

Um estrangulamento muitas vezes ignorado é o seguimento de ligações do kernel. O UDP não conhece ligações, mas o kernel cria mesmo assim uma entrada para cada par de endereço de origem e endereço de destino. Se a tabela encher, o servidor passa a descartar também pacotes legítimos e no log 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

Para um gameserver puro, a solução limpa é não deixar sequer que o tráfego de jogo seja seguido e, adicionalmente, aumentar os buffers de receção e a fila da placa de rede:

iptables -t raw -A PREROUTING -p udp --dport 2302 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 2302 -j NOTRACK
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.rmem_default=1048576
sysctl -w net.core.netdev_max_backlog=5000
sysctl -w net.netfilter.nf_conntrack_max=524288

Atenção: o NOTRACK e as regras com estado excluem-se mutuamente. Quem retira a porta de jogo do seguimento não pode usar mais nenhuma regra com -m conntrack --ctstate para essa porta, caso contrário a abertura deixa de funcionar. De forma permanente, os valores de sysctl pertencem ao /etc/sysctl.d/, senão desaparecem no reinício seguinte.

8. O seu endereço IP está no browser de servidores

Aqui compensa mais a honestidade do que o pensamento mágico: o endereço IP de um servidor público de DayZ não se consegue manter em segredo. Qualquer jogador que se tenha ligado uma vez conhece-o, o browser de servidores publica-o e o DZSA Launcher guarda-o em cache. Mudar de endereço dá-lhe horas, raramente dias.

Mais eficazes são dois hábitos. Não publique o endereço IP em bruto em mais lado nenhum, ou seja, nem na mensagem afixada do Discord nem na página do projeto. E arrume os seus registos DNS: um registo A esquecido a apontar para o endereço anterior torna qualquer mudança inútil, e é precisamente nisso que a maioria das mudanças falha. Quem deixa ainda um serviço de estado a correr no servidor antigo entrega logo também o endereço novo.

9. Registar em log, 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 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. Do lado do servidor, ligue para isso os logs integrados:

timeStampFormat = "Short";
logAverageFps = 300;
logPlayers = 300;
logFile = "server_console.log";

O logAverageFps é o valor mais honesto que o DayZ fornece. Se a taxa de fotogramas do servidor cair enquanto o número de jogadores se mantém, é um problema de mods ou da economia. Se a taxa de fotogramas se mantiver estável enquanto os jogadores vão sendo atirados para fora, o problema está na rede. Do lado do sistema, as medições ficam sempre a correr com apt-get install -y vnstat sysstat e, 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 2302 -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 interpretar os valores está em Detetar um ataque DDoS no servidor.

Onde a autoproteção termina: 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.

No DayZ, a taxa de pacotes chega muitas vezes ao limite antes da largura de banda, e isso tem uma razão simples: o tráfego de jogo é feito de muitos pacotes UDP pequenos e não de poucos pacotes grandes. Um ataque que nem sequer enche um terço da sua linha pode, por isso, 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 toda a gente teve picos de lag e foi caindo uns atrás dos outros".

Os ataques volumétricos têm de terminar na rede à frente do servidor. Isto não é uma afirmação de produto, é física.

Proteção DDoS para DayZ: o que a KernelHost põe do outro lado

A proteção permanente que corre em todos os servidores

A proteção DDoS da KernelHost está construída em dois níveis e permanentemente ativa, sem que tenha de ligar, 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 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 € por mês, PrePaid e sem prazo mínimo. A diferença não está em mais capacidade, mas sim no controlo:

• IP de proteção dedicado a partir do núcleo de Frankfurt, para o qual o seu servidor é comutado dentro da nossa própria rede. Do seu lado não é preciso qualquer alteração.
• Regras de proteção autogeríveis por porta e por protocolo na área de cliente: define separadamente o que é permitido na 2302/UDP, o que é permitido no Query Port e o que é permitido na porta de RCon. É precisamente essa separação que no DayZ faz a diferença, porque o tráfego de jogo e o tráfego de consulta têm um aspeto completamente diferente.
• As alterações entram em vigor em tempo real, pelo que pode afinar durante um ataque em curso, em vez de esperar por um ticket.
• Perfil de proteção adequado ao jogo, também para servidores com muitos mods e para aplicações próprias em quaisquer portas TCP ou UDP.

Os dois níveis em comparação

Para a maioria dos projetos de DayZ, a proteção permanente incluída chega, em conjunto com uma configuração de servidor limpa. A Advanced DDoS Protection é a resposta para quando alguém leva a coisa a peito. Quem opera atualmente o seu servidor de DayZ noutro sítio não consegue acrescentar esta proteção: ela é parte da rede e vale para servidores que estão na KernelHost. O caminho para lá chegar é uma mudança, não um produto adicional.

Erros frequentes e respetivas soluções

"O meu servidor desapareceu do DZSA Launcher e do browser de servidores, mas por ligação direta consigo entrar": na maioria dos casos não é um ataque, é o Query Port. Ou o valor em steamQueryPort é diferente do que está na firewall, ou uma limitação de taxa demasiado apertada descarta as consultas da lista de servidores. Verifique os dois valores um contra o outro antes de suspeitar de um ataque.

"O RCon deixou de ligar desde que filtrei as portas": o RCon do BattlEye corre sobre UDP. Uma abertura com proto tcp na mesma porta não produz efeito nenhum. Verifique além disso se o RConPort e o steamQueryPort estão por engano com o mesmo valor.

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

"O ataque chega todos os dias exatamente na hora do reinício": isso não é coincidência. O plano de reinícios está no Discord e é anunciado dentro do jogo, e enquanto os mods e a economia carregam o servidor já não responde de qualquer forma. Uma lista de mods mais curta, horas de reinício quebradas e uma filtragem que corre em permanência em vez de reagir apenas a um ataque tiram o efeito a este padrão.

"Todos os jogadores têm picos de lag, mas a rede está calma": então não foi um ataque DDoS. Veja primeiro em logAverageFps se a taxa de fotogramas do servidor caiu e depois a economia central e a lista de mods. Se o sar -n DEV 1 10 se mantiver discreto, o problema não está na rede.

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

"O 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 de DayZ precisa, para o exterior, de exatamente duas coisas: o bloco da porta de jogo a partir da 2302/UDP e o Steam Query Port que está na sua linha steamQueryPort. Tudo o resto deve ser restringido ou fechado.
• A porta de RCon do BattlEye não tem um valor predefinido obrigatório, corre sobre UDP e define-se na BEServer_x64.cfg com RConPort. Nunca pertence à rede aberta e nunca deve ter o mesmo valor que o Query Port.
• Limitar o Query Port em vez de o fechar: quem o fecha desaparece do browser de servidores e do DZSA Launcher, apesar de a ligação direta continuar a funcionar.
• A whitelist, o guaranteedSlots e a fila de espera de entrada protegem os seus lugares de jogador contra o esgotamento de slots, mas não protegem a sua linha contra largura de banda.
• A janela de tempo mais perigosa de um servidor de DayZ é o reinício planeado de três em três ou de quatro em quatro horas, porque os mods e a economia central levam minutos a carregar e porque o momento é do conhecimento público.
• A partir de cerca de 1 Gbit/s de volume de ataque ou de algumas centenas de milhares de pacotes por segundo, quem decide é exclusivamente a rede à frente do servidor e já não a sua firewall.
• Na KernelHost, a proteção permanente em dois níveis está incluída em todos os pacotes de servidor, sem sobretaxa e sem null-routing. A Advanced DDoS Protection a partir de 50,00 € por mês junta-se a isso quando quiser controlar por si próprio as regras de cada porta.

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