Proteger o servidor Arma 3 contra ataques DDoS

Quem quer proteger um servidor Arma 3 contra ataques DDoS lida com exatamente cinco portas UDP: 2302 a 2306. Um servidor dedicado que desaparece à noite, a meio da operação e para todos os jogadores ao mesmo tempo, raramente tem um problema de hardware. Na maioria dos casos está a decorrer um ataque contra precisamente este bloco de portas, e precisamente à hora em que a lista de servidores mostra o número mais alto de jogadores. 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 na rede à frente do servidor.

Todas as indicações se referem a um servidor Arma 3 dedicado (aplicação SteamCMD 233780) 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 agora nada na configuração e não reinicie o servidor, guarde primeiro os valores medidos da secção "Registar em log". Depois do ataque desaparecem.

Porque é que os servidores Arma 3 são atacados e quando a proteção DDoS se torna necessária

O Arma 3 reúne várias características que fazem de um servidor um alvo cómodo. Em primeiro lugar, o servidor publica o seu endereço por iniciativa própria: regista-se no servidor mestre da Steam através da porta 2304 UDP e responde na porta 2303 UDP a consultas com nome, mapa, número de jogadores e lista de mods. Sem estas duas portas ninguém o encontra; com elas, o seu endereço IP fica em todos os navegadores de servidores e em todas as páginas de estado que consultam o navegador de servidores.

Em segundo lugar, a comunidade de jogadores está presa a horários fixos. Os projetos de roleplay Life em Altis e Tanoa, o Exile, o Antistasi e o King of the Hill enchem-se à noite e ao fim de semana, pelo que uma falha às 20 horas tem a máxima visibilidade possível. Em terceiro lugar, há concorrência entre projetos, jogadores banidos e conflitos internos, e um ataque não custa a quem o desencadeia nem competência nem dinheiro digno de nota.

Do lado técnico acresce o ponto decisivo: o Arma 3 corre inteiramente sobre UDP, o jogo não precisa de TCP para funcionar. O UDP não tem um estabelecimento de ligação que se possa exigir e os endereços de origem falsificam-se com facilidade. Um atacante não precisa, portanto, de entrar no seu servidor nem de o contactar corretamente para lhe gerar carga. Acresce ainda que o ciclo de simulação de um servidor Arma 3 corre, no essencial, num único núcleo de processamento: quem enviar pacotes suficientes consome o tempo de processamento desse núcleo, independentemente de quantos núcleos a máquina tenha. O que é exatamente um ataque DDoS fica explicado no artigo O que é um ataque DDoS?.

As portas que realmente contam

Por predefinição, um servidor Arma 3 ocupa o bloco 2302 a 2306 UDP. O parâmetro de arranque -port=2302 define apenas a primeira porta; as outras quatro resultam dela de forma fixa, como porta de jogo mais 1 até mais 4. Quem opera várias instâncias na mesma máquina deixa, por isso, pelo menos 100 portas de intervalo (2302, 2402, 2502), caso contrário as instâncias roubam umas às outras as portas seguintes.

Destas oito linhas, exatamente três pertencem à internet aberta: 2302, 2303 e 2304 UDP. Tudo o resto é administração, e as portas de administração abertas são o erro evitável mais frequente em servidores Arma 3.

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

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

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:2302 significa "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, num servidor Life aparecem ali regularmente o MariaDB, um servidor web para a página da facção, um serviço de TeamSpeak ou de voz e um painel há muito esquecido. A perspetiva do atacante obtém-se com um scan de portas a partir de fora:

nmap -Pn -sU -p 2300-2320 IP.DO.SEU.SERVIDOR
nmap -Pn -p- --min-rate 1000 IP.DO.SEU.SERVIDOR

O primeiro comando mostra o bloco UDP do jogo, o segundo tudo o que está aberto em TCP. Um servidor Arma 3 não precisa de uma única porta TCP aberta para o funcionamento do jogo.

2. Deixar abertas apenas as portas de que o Arma 3 precisa mesmo

Três portas UDP para o exterior chegam, tudo o resto fica restringido. 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 from 203.0.113.10 to any port 22 proto tcp comment 'SSH'
ufw allow 2302:2304/udp comment 'Arma 3 jogo, query Steam, master Steam'
ufw allow from 203.0.113.10 to any port 2306 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. A porta 2305 fica fechada, porque a Bohemia a indica como reservada e atualmente não utilizada. Importante é a linha ufw default allow outgoing: o BattlEye estabelece a partir do servidor uma ligação a arma31.battleye.com e precisa, para isso, das portas de saída 2344 em TCP e UDP e 2345 em TCP. Quem bloqueia a saída de forma indiscriminada bloqueia o seu próprio anti-cheat. Depois da mudança, confirme com uma entrada real que o BattlEye continua a deixar passar os seus jogadores. As instruções completas, incluindo o caminho de recuperação, encontram-se em Configurar a firewall UFW sem se trancar fora do servidor.

A base de dados não pertence, em caso algum, à rede aberta. O Altis Life e as outras frameworks Life comunicam com uma base de dados MySQL através da extensão extDB3, e os dados de acesso estão em texto simples em @extDB3/extdb3-conf.ini. Verifique em /etc/mysql/mariadb.conf.d/50-server.cnf que ali consta:

bind-address = 127.0.0.1

3. Desarmar a porta de query Steam sem cair do navegador de servidores

A porta 2303 UDP é o ponto mais sensível de um servidor Arma 3 público. Responde a consultas A2S, ou seja, à consulta padrão do navegador de servidores da Steam: A2S_INFO devolve nome, mapa e número de jogadores, A2S_PLAYERS a lista de jogadores, A2S_RULES a lista de mods e de assinaturas. Uma consulta é um pequeno pacote UDP, a resposta é um múltiplo disso. O US-CERT indica no alerta TA14-017A um fator de amplificação de largura de banda de 5,5 para o protocolo da Steam, e no Arma 3 a resposta sai especialmente grande, porque leva consigo a lista completa de mods.

Daí decorrem duas coisas. Primeiro, o seu servidor pode ser abusado como amplificador contra terceiros, se um atacante enviar consultas com endereço de origem falsificado. Segundo, e mais importante para si, cada consulta custa tempo de processamento no único núcleo que sustenta a simulação. A Bohemia mantém desde 2015 um ticket sobre o assunto (T83469): pacotes UDP falsificados dirigidos à porta de jogo ou à porta de query Steam levavam o CPU a 100 por cento e congelavam o servidor, e para um ataque bem-sucedido através da porta de query bastavam já 4 Mbit/s. É essa a razão pela qual, no Arma 3, a taxa de pacotes é mais perigosa do que a largura de banda.

A primeira alavanca é o tamanho da resposta. A diretiva steamProtocolMaxDataSize no server.cfg define quantos bytes o servidor pode colocar na sua resposta de query. Quem opera listas de mods grandes aumenta-a para 2048 ou mais, porque de outra forma aparece no log o aviso "Query data overflow, Mods/Signatures will not be correctly received by clients". Cada aumento amplia, porém, exatamente a resposta que um atacante amplifica. Defina por isso o valor tão baixo quanto a sua lista de mods ainda permitir, e retire do comando de arranque os mods não utilizados:

steamProtocolMaxDataSize = 2048;

A segunda alavanca é uma limitação de taxa por endereço de origem que só atinge a porta de query. Não bloqueie a 2303 UDP de forma indiscriminada: sem resposta de query o seu servidor desaparece do navegador de servidores e de qualquer página de estado, e os novos jogadores deixam de o encontrar. Um navegador de servidores legítimo consulta algumas vezes por minuto, não centenas de vezes por segundo.

4. Retirar o RCon do BattlEye da rede aberta

O BattlEye é o anti-cheat do Arma 3 e é ativado no server.cfg com BattlEye = 1;. O controlo remoto associado, o BattlEye RCon, é um protocolo UDP próprio e configura-se em BattlEye/beserver_x64.cfg (o ficheiro com o sufixo _x64 aplica-se ao arma3server_x64, o servidor habitual hoje em dia):

RConPassword SuaPalavraPasseAlfanumerica
RConPort 2306
RConIP 127.0.0.1
MaxPing 350
RestrictRCon 0

Três pontos são decisivos. A palavra-passe de RCon tem de ser puramente alfanumérica: os caracteres especiais desregulam em silêncio o analisador de protocolo do BattlEye, e um acesso RCon com falha silenciosa é um acesso que não tem quando precisa dele. RConIP define em que endereço o RCon fica à escuta: se ali estiver 127.0.0.1, a interface só é acessível localmente, e a sua ferramenta de RCon alcança-a através de um encaminhamento SSH. E RConPort tem de ficar acima do bloco do jogo, sendo habitual a porta de jogo mais 4, ou seja, 2306. Quem tem mesmo de abrir o RCon para o exterior liberta a porta apenas para o endereço fixo da sua equipa de administração.

Uma coisa tem de ficar clara: o BattlEye é um anti-cheat, não uma proteção DDoS. Verifica jogadores que estão ligados. Um atacante que inunda o seu servidor nem sequer quer entrar.

5. Ligar o Headless Client a um endereço fixo

Um Headless Client é uma segunda instância do Arma 3 sem gráficos, que se liga ao servidor como se fosse um jogador e lhe retira o cálculo da IA. Em missões grandes, é o maior ganho de desempenho que existe, porque de outra forma a IA fica no mesmo núcleo que a simulação. É autorizado no server.cfg:

headlessClients[] = {"127.0.0.1"};
localClient[] = {"127.0.0.1"};

Sem estas entradas, o servidor não permite qualquer ligação de Headless Client, e essa é a boa notícia. A má: localClient[] concede ao endereço ali indicado largura de banda ilimitada e praticamente nenhuma verificação de latência. Indique ali exclusivamente 127.0.0.1 ou o endereço fixo do seu próprio servidor de Headless Client, nunca uma gama inteira de endereços. O cliente arranca com -client -connect=127.0.0.1 -port=2302 -password=... e ocupa um slot de maxPlayers. Conte com ele, caso contrário os seus jogadores ficam à porta de um servidor cheio.

6. Endurecer a entrada, as assinaturas e as votações

Estas definições não protegem a sua linha, mas fecham tudo o que chega pelo caminho normal de entrada: clientes manipulados, execução de scripts dentro do jogo e abuso das votações. As linhas seguintes pertencem ao server.cfg de qualquer servidor público:

verifySignatures = 2;
BattlEye = 1;
kickDuplicate = 1;
allowedFilePatching = 0;
maxPlayers = 64;
disconnectTimeout = 30;
maxPing = 200;
maxDesync = 150;
maxPacketLoss = 50;
kickClientsOnSlowNetwork[] = {1, 1, 1, 1};
voteThreshold = 1.5;
voteMissionPlayers = 100;
onUnsignedData = "kick (_this select 0)";
onHackedData = "kick (_this select 0)";

verifySignatures = 2 impõe a verificação de assinaturas versão 2 para todos os addons e é o requisito mínimo para qualquer servidor público com mods. allowedFilePatching = 0 recusa a entrada a clientes que tenham arrancado com -filePatching (o valor 1 permite-o apenas a Headless Clients, o valor 2 a todos). kickDuplicate = 1 expulsa a segunda ligação do mesmo identificador. kickClientsOnSlowNetwork[] decide, entrada a entrada, se os quatro limiares de maxPing, maxPacketLoss, maxDesync e disconnectTimeout são apenas registados (0) ou aplicados (1). disconnectTimeout aceita valores de 5 a 90 segundos. Um voteThreshold acima de 1 torna as votações inalcançáveis e acaba assim com a forma mais popular de perturbar um servidor sem um único pacote de ataque: a mudança de missão por votação.

7. Limitar as taxas de pacotes e de ligações por endereço de origem

Contra ataques pequenos e bots mal feitos ajuda um limite máximo por endereço de origem. Como o Arma 3 corre em UDP puro, trabalha-se com hashlimit, e a porta de query recebe um limite bastante mais apertado do que a porta de jogo:

iptables -I INPUT -p udp --dport 2303 -m hashlimit --hashlimit-name a3_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 2302 -m hashlimit --hashlimit-name a3_game --hashlimit-mode srcip --hashlimit-above 900/sec --hashlimit-burst 1200 -j DROP
iptables -I INPUT -p udp --dport 2302:2306 -m length --length 0:27 -j DROP

A primeira regra descarta consultas de query da mesma origem a partir de mais de dez por segundo de forma continuada, a segunda pacotes de jogo a partir de mais de 900 por segundo de forma continuada, a terceira pacotes UDP sem carga útil aproveitável. Os três números são valores de partida, não verdades absolutas: um servidor Life cheio com 80 jogadores gera bastante mais pacotes do que uma ronda de Antistasi a seis, e quem aperta demasiado acaba por expulsar os seus próprios jogadores. Meça primeiro durante uma semana em funcionamento normal.

Duas notas a este respeito. 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 ao /etc/ufw/before.rules, porque de outra forma desaparecem no ufw reload seguinte. Outro estrangulamento muitas vezes ignorado é o seguimento de ligações do kernel: também o UDP cria ali entradas, e um flood de query a partir de muitos endereços falsificados enche a tabela em segundos. Se 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

8. basic.cfg: largura de banda, tamanhos de pacote e ficheiros adicionais

O segundo ficheiro de configuração de um servidor Arma 3 chama-se basic.cfg e é carregado com -cfg=, enquanto -config= carrega o server.cfg. Controla o comportamento de rede e contém exatamente um valor com relevância direta para a segurança:

MaxMsgSend = 1024;
MaxSizeGuaranteed = 512;
MaxSizeNonguaranteed = 256;
MinBandwidth = 15000000;
MaxBandwidth = 100000000;
MinErrorToSend = 0.001;
MinErrorToSendNear = 0.01;
MaxCustomFileSize = 0;
class sockets { maxPacketSize = 1400; };

MaxCustomFileSize é o tamanho máximo em bytes para os ficheiros de rosto e de som que os jogadores trazem consigo e que o servidor distribui por todos os outros. O valor 0 desliga essa distribuição. Com isso desaparece um caminho pelo qual um único cliente ocupa a largura de banda do seu servidor sem qualquer infraestrutura de ataque. MinBandwidth é a largura de banda que o servidor assume como garantida; o valor de referência é o número de jogadores vezes 256 kbit/s, ou seja, cerca de 16 Mbit/s para 64 slots. Valores demasiado otimistas aumentam a carga e a dessincronização, porque o servidor gera mensagens que depois descarta. MaxMsgSend limita os pacotes por passo de simulação e é a primeira alavanca contra a dessincronização; o valor predefinido de 128 está demasiado baixo para servidores modernos.

9. Registar em log, para não ter de adivinhar durante um 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. Com apt-get install -y vnstat sysstat, a medição fica sempre a correr, e logFile = "arma3server.log"; no server.cfg dá-lhe a perspetiva do servidor. 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 2302-2306 -c 200 -q

Esclarecedora é a comparação entre as portas. Se a carga estiver quase toda na 2303, é um flood de query, e esse atinge o tempo de processamento. Se se distribuir de forma uniforme pelas portas 2302 a 2306 com endereços de origem sempre novos, é um flood UDP falsificado, e esse atinge a linha. 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. Como instalar e atualizar o servidor de forma limpa está em Instalar um gameserver com o SteamCMD.

Onde estas medidas deixam de chegar

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. A segunda grandeza é a taxa de pacotes, e no Arma 3 é quase sempre ela a chegar primeiro ao limite. 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, e a simulação do Arma 3 depende ainda por cima de um único núcleo.

A linha dos 4 Mbit/s é a mais incómoda. No Arma 3, um ataque não precisa de ser grande para fazer efeito: basta-lhe enviar pacotes suficientes para a porta certa. Quem opera servidores vive isto como "a utilização nem sequer estava alta e mesmo assim desapareceu tudo". Ao contrário, para os ataques volumétricos vale a física simples: com 473,4 Gbit/s qualquer definição local perde o sentido, porque os pacotes dos seus jogadores já nem chegam a passar. 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. 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. Um servidor Life com uma comunidade fixa e um meio concorrencial é, nesse ponto, a regra e não a exceção. 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 2302 UDP e o que é permitido na 2303 UDP, podendo assim manter a porta de query bastante mais apertada do que a porta de jogo.
• As alterações entram em vigor em tempo real, pelo que pode afinar durante um ataque em curso, em vez de esperar por uma janela de manutenção.
• Perfil de proteção adequado a cada jogo, tal como para aplicações modificadas e próprias em quaisquer portas TCP ou UDP.

Os dois níveis em comparação

Para a maioria dos projetos de Arma 3, 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

"Mudei a porta de 2302 para 2402 e o ataque continuou": é o que se espera. O servidor regista a sua nova porta no servidor mestre da Steam por iniciativa própria, e a lista de servidores volta a publicá-la de imediato. Uma mudança de porta só ajuda contra quem use um endereço antigo tirado de uma captura de ecrã antiga.

"Bloqueei a 2303 por completo e agora ninguém nos encontra": é exatamente isso que acontece. Sem resposta na porta de query Steam falta a entrada no navegador de servidores, e qualquer página de estado e qualquer bot do Discord mostram o servidor como offline. O correto é uma limitação de taxa por endereço de origem, não um bloqueio.

"No log aparece NetServer::SendMsg: cannot find channel": esta mensagem surge quando o servidor quer escrever para uma ligação que já não existe. Acompanha normalmente quebras de ligação dos jogadores e quebras de desempenho (a Bohemia regista isso em T83936), não necessariamente um ataque. Verifique primeiro se a taxa de pacotes da interface é sequer anormal.

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

"Desde a nova firewall o BattlEye expulsa todos os jogadores": o servidor já não alcança arma31.battleye.com. As portas de saída 2344 em TCP e UDP e 2345 em TCP têm de continuar abertas, caso contrário a ligação de anti-cheat do servidor cai.

"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 Arma 3 precisa de exatamente três portas UDP para o exterior: 2302 para jogo e voz, 2303 para a query Steam e 2304 para o registo no servidor mestre da Steam. O jogo não precisa de TCP.
• A porta 2306 UDP transporta o BattlEye e a interface RCon e pertence exclusivamente aos seus próprios endereços de administração, definidos com RConPort e RConIP em beserver_x64.cfg.
• A porta de query Steam 2303 é o ponto mais sensível: segundo o US-CERT TA14-017A, o protocolo da Steam tem um fator de amplificação de 5,5, e cada consulta custa tempo de processamento no núcleo que sustenta a simulação. Limitar em vez de bloquear.
• Mantenha steamProtocolMaxDataSize tão baixo quanto a lista de mods permitir e defina MaxCustomFileSize = 0; no basic.cfg: ambos reduzem o volume de dados que o seu servidor entrega sem lhe perguntarem.
• No Arma 3 quem decide é a taxa de pacotes, não a largura de banda. A Bohemia documenta desde 2015, em T83469, que bastaram 4 Mbit/s na porta de query para congelar um servidor.
• As medidas locais terminam na linha. A partir de 1 Gbit/s de volume de ataque ou de algumas centenas de milhares de pacotes por segundo, quem decide é exclusivamente a filtragem na rede à frente do servidor.
• Na KernelHost, a proteção permanente em dois níveis está incluída em todos os pacotes de servidor sem sobretaxa e fica ativa a partir da disponibilização, sem null-routing. A Advanced DDoS Protection acrescenta-lhe, a partir de 50,00 EUR por mês, um IP de proteção dedicado e regras autogeríveis por porta.

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