Proteger o servidor Call of Duty contra ataques DDoS

Proteger um servidor de Call of Duty contra ataques DDoS é, nos títulos clássicos, uma tarefa agradavelmente concreta: trata-se de exatamente uma porta UDP, de um punhado de dvars no server.cfg e de um vetor de amplificação que a engine traz consigo desde 2003. Já um servidor que perde à noite, a meio da ronda, todos os jogadores ao mesmo tempo, raramente tem um problema de hardware. Na maioria dos casos está a decorrer um ataque, e ele decorre precisamente quando o servidor está cheio.

Este artigo mostra primeiro para que títulos é que ele vale, depois o que pode proteger por conta própria e sem custos adicionais, a seguir onde estas medidas terminam do ponto de vista técnico e, por fim, o que tem então de acontecer na rede à frente do servidor. Os comandos estão escritos para Debian 12, Debian 13, Ubuntu 22.04 LTS e Ubuntu 24.04 LTS e pressupõem root; como utilizador normal, anteponha sudo.

Se o ataque estiver a decorrer neste momento: não altere agora nada no server.cfg e não reinicie o servidor. Guarde primeiro os valores medidos (ver a secção "Registar em log"), porque depois do ataque desaparecem.

Para que títulos de Call of Duty pode proteger um servidor contra DDoS

Só pode proteger um servidor de Call of Duty contra DDoS nos títulos que permitem servidores dedicados próprios. São as versões originais de Call of Duty (2003), Call of Duty United Offensive, Call of Duty 2, Call of Duty 4 Modern Warfare e Call of Duty World at War, às quais se juntam as plataformas comunitárias Plutonium (World at War, Black Ops, Black Ops II, Modern Warfare 3), IW4x (Modern Warfare 2) e CoD4X (Call of Duty 4). Todos estes títulos trazem o mesmo padrão: um server.cfg, uma porta UDP aberta e uma entrada numa lista pública de servidores.

Para os títulos modernos, este artigo não se aplica de todo. O Warzone, o Modern Warfare (2019), o Black Ops Cold War, o Vanguard, o Modern Warfare II, o Modern Warfare III e o Black Ops 6 não conhecem servidores dedicados que se possam alugar: as partidas correm na infraestrutura de matchmaking da Activision, não existe server.cfg, não existe navegador de servidores e não existe uma porta que possa abrir ou proteger. As listas de portas que a Activision publica para estes títulos (entre outras TCP 3074 e 27014 a 27050, bem como UDP 3074, 3478 e 27000 a 27031) descrevem portas de cliente e de plataforma, não portas de servidor. Quem tem quebras de ligação no Warzone tem um problema na sua própria linha ou um problema na Activision, mas nenhum que um servidor alugado resolvesse.

Porque é que são precisamente os servidores de Call of Duty a ser atacados

Os servidores de Call of Duty reúnem quatro características que fazem deles um alvo cómodo. Em primeiro lugar, cada servidor listado publica o seu endereço por iniciativa própria: a entrada na lista de servidores contém o endereço IP e a porta em texto simples, caso contrário ninguém lá conseguiria entrar. Em segundo lugar, todo o tráfego corre sobre UDP, e o UDP não tem um estabelecimento de ligação que se possa exigir, além de os endereços de origem se falsificarem com facilidade. Em terceiro lugar, a engine responde a consultas de estado de qualquer pessoa, sem que ninguém tenha de abrir o jogo. Em quarto lugar, o controlo remoto RCON está na mesma porta que o próprio jogo.

A isto junta-se a parte social: jogadores banidos, concorrência entre clãs, conflitos numa comunidade que se conhece há anos. Um ataque não custa a quem o desencadeia nem competência nem dinheiro digno de nota, os chamados booters e stressers são vendidos como subscrição por poucos euros por mês, e os ataques de amplificação através de servidores de jogos fazem ali parte da oferta padrão. O que é exatamente um ataque DDoS fica explicado no artigo O que é um ataque DDoS?.

As portas que realmente contam

Um servidor clássico de Call of Duty ocupa exatamente uma porta UDP, a 28960. Nessa única porta correm três coisas ao mesmo tempo: o tráfego de jogo, as consultas de estado da lista de servidores e o controlo remoto RCON. Não existe uma porta de query própria nem uma porta de RCON própria. A linha de arranque de um servidor dedicado é igual em todos os títulos, só o nome do ficheiro executável muda:

+set dedicated 2 +set net_ip 0.0.0.0 +set net_port 28960 +set sv_maxclients 32 +exec server.cfg +map_rotate

As portas dos servidores mestre não pertencem às aberturas da sua firewall. A 20810 e a 20800 são portas de destino do outro lado, não portas à escuta na sua máquina: é o seu servidor que contacta a lista por iniciativa própria. Ainda assim, muitos guias de abertura de portas recomendam abri-las à entrada. Isso aumenta a superfície de ataque sem qualquer contrapartida.

Ordens de grandeza habituais no Call of Duty

A segunda tabela é a mais importante quando quer avaliar se ainda consegue resolver o assunto sozinho. Coloca a carga normal de um servidor cheio ao lado dos números de que se trata num ataque.

Porque é que jogo, query e RCON estão na mesma porta

Esta é a particularidade decisiva do Call of Duty. A engine id Tech 3, sobre a qual assentam todos os títulos clássicos de Call of Duty, não conhece portas separadas para jogo, consulta e controlo remoto. Tudo corre através dos chamados pacotes sem ligação, na mesma porta UDP. Um pacote sem ligação é um pacote UDP que começa com quatro bytes 0xFF e que traz a seguir o nome do comando em texto simples: getstatus, getinfo, getchallenge, connect ou rcon.

A consequência prática é incómoda: não consegue separar o RCON do jogo com a firewall sem bloquear também o jogo. Uma regra na porta 28960 atinge sempre tudo. Quem quiser separar especificamente os floods de query e os ataques por RCON tem de olhar para o conteúdo do pacote e não apenas para o número da porta. É exatamente por isso que, no Call of Duty, as regras de firewall baseadas em portas chegam ao seu limite mais cedo do que em jogos com uma porta de query separada.

O que é a reflexão getstatus no Call of Duty?

A reflexão getstatus é um ataque de amplificação no qual um atacante envia pequenas consultas de estado com endereço de origem falsificado a muitos servidores de jogos, para que as respostas destes, bastante maiores, acabem na vítima real. Os servidores de jogos não são aqui o alvo, mas sim o amplificador. Este vetor está documentado para a engine id Tech 3 há mais de uma década e afeta o Call of Duty tal como afeta o Quake 3 e os restantes derivados dele.

Atinge-o a dobrar, a partir de duas direções. Como atacado, recebe uma enxurrada de pedidos getstatus que consomem tempo de processamento e largura de banda de saída, e os seus jogadores notam isso como lag spikes. Como amplificador involuntário, envia respostas a uma vítima alheia, e a queixa de abuso acaba por lhe chegar a si. As duas coisas acontecem na mesma porta, com os mesmos pacotes, e ambas parecem à primeira vista inofensivas no gráfico de utilização.

Como é um pacote getstatus

O pedido é composto por quatro bytes 0xFF e pela palavra getstatus, ao todo 13 bytes de carga útil. Com o cabeçalho IP e o cabeçalho UDP, são 41 bytes na linha. É exatamente a isso que se dirige a verificação de comprimento nas regras de firewall que circulam há anos nos fóruns de Call of Duty:

iptables -A INPUT -p udp -m length --length 41:45 -m recent --set --name getstatus_cod
iptables -A INPUT -p udp -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

A resposta é incomparavelmente maior. Um statusResponse contém toda a configuração do servidor como cadeia de carateres mais uma linha por cada jogador ligado, ou seja, vários kilobytes com o servidor cheio. A CISA indica na sua panorâmica dos ataques de amplificação por UDP (TA14-017A) um fator de amplificação de 63,9 para o protocolo de rede Quake e nomeia expressamente como comando abusado a troca de informações do servidor. De 1 Mbit/s de pedidos falsificados resultam assim cerca de 64 Mbit/s na vítima. A título de comparação: na mesma panorâmica, o DNS situa-se entre 28 e 54 e o NTP em 556,9.

O travão integrado: sv_queryIgnoreTime e sv_queryIgnoreMegs

O Call of Duty 4 tem, desde a versão de servidor 1.7, um travão de query integrado. Ele memoriza cada endereço que tenha enviado uma consulta de estado e ignora consultas adicionais do mesmo endereço durante um tempo configurável. Quatro dvars controlam isso, com estas predefinições:

sv_queryIgnoreMegs        1
sv_queryIgnoreTime        2000
sv_queryBounceIgnoreTime  12000
sv_queryIgnoreDebug       0

sv_queryIgnoreMegs determina quanta memória a lista de ignorados pode ocupar. 1 megabyte comporta cerca de 65 000 endereços, cada megabyte adicional cerca de 87 000 mais. O valor 0 desliga o travão por completo, e é exatamente esse o caso em muitos servidores, porque a configuração vem de um modelo antigo. sv_queryIgnoreTime é o tempo de bloqueio em milissegundos. sv_queryBounceIgnoreTime entra em ação quando volta uma resposta com "ICMP Port Unreachable", ou seja, precisamente quando o seu servidor está a ser abusado como amplificador contra uma vítima alheia. sv_queryIgnoreDebug 1 escreve as ocorrências no log, para que consiga sequer ver se está a acontecer alguma coisa.

Quem usa o CoD4X tem adicionalmente limites fixos no código do servidor: no máximo 20 respostas getstatus por cada 20 segundos, no máximo 100 respostas getinfo por cada 100 segundos e no máximo uma mensagem de erro de RCON por cada 100 milissegundos. O comentário no código-fonte nomeia a intenção com clareza: o servidor pode deixar-se inundar à vontade, mas não deve desperdiçar largura de banda de saída com isso. A prioridade está bem definida, mas não substitui a filtragem à frente do servidor.

Porque é que o RCON no Call of Duty é historicamente um problema

O RCON é o controlo remoto do servidor e, no Call of Duty, é um pacote UDP não cifrado na porta de jogo. Um comando de RCON tem, na linha, este aspeto: quatro bytes 0xFF, depois a palavra rcon, depois a palavra-passe em texto simples, depois o comando propriamente dito. Não há cifragem, não há sessão, não há conta de utilizador e não há segundo fator. Daí decorrem três problemas, todos eles reais:

• Interceção. Quem vir o tráfego em qualquer ponto do caminho lê a sua palavra-passe de RCON em texto simples. Isso vale para qualquer rede entre si e o servidor e para qualquer ferramenta a que entregue a palavra-passe.
• Adivinhação. Não existe um início de sessão que se possa bloquear nem um bloqueio de conta ao fim de dez tentativas falhadas. Um atacante experimenta palavras-passe à velocidade que quiser. O servidor original não trava isso de todo, o CoD4X trava apenas a resposta, limitando-a a uma mensagem de erro por cada 100 milissegundos, e regista a tentativa como "Bad rcon".
• Reflexão. Também uma mensagem de erro de RCON é uma resposta a um pacote falsificado. Quem bombardeia o seu servidor com pacotes de RCON falsificados usa-o como pequeno amplificador, e o seu servidor enche entretanto o log.

A consequência prática: defina rcon_password apenas se precisar mesmo de RCON. Se precisar, então que seja longa e aleatória. O CoD4X exige pelo menos oito carateres, o que é um limite mínimo e não uma recomendação. No dia a dia, administre através de SSH e da consola do servidor em vez de usar RCON a partir da rede aberta. E se operar uma ferramenta de administração como o IW4MAdmin, que por sua vez comunica por RCON, a interface web dela na porta 1624 não pertence à rede aberta.

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

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

1. Levantamento: o que está sequer à escuta?

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:28960 e [::]:28960 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 o IW4MAdmin, um servidor web para o Fast Download, uma base de dados para estatísticas e uma segunda instância de jogo esquecida. A perspetiva do atacante obtém-se com um scan de portas a partir de fora:

nmap -Pn -sU -p 28960-28970,4976,27016 IP.DO.SEU.SERVIDOR
nmap -Pn -p- --min-rate 1000 IP.DO.SEU.SERVIDOR

2. Deixar aberto apenas o que o jogo precisa mesmo

Para um único servidor de Call of Duty basta uma única abertura 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 28960/udp comment 'Call of Duty'
ufw allow from 203.0.113.10 to any port 1624 proto tcp comment 'IW4MAdmin'
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. No Plutonium T6, 4976/udp toma o lugar de 28960/udp, e no Plutonium IW5 é 27016/udp. Se operar várias instâncias, abra exclusivamente a gama efetivamente utilizada, ou seja, por exemplo 28960:28962/udp e não, de forma indiscriminada, de 28960 a 28970. Uma porta onde nada está à escuta não é, é certo, uma porta de entrada, mas mesmo assim dá trabalho ao kernel em caso de ataque. As instruções completas, incluindo o caminho de recuperação, encontram-se em Configurar a firewall UFW sem se trancar fora do servidor.

3. Ligar o travão de query no server.cfg

Estas quatro linhas pertencem ao server.cfg de qualquer servidor de Call of Duty 4 e não custam nada além de alguns megabytes de memória:

set sv_queryIgnoreMegs "4"
set sv_queryIgnoreTime "2000"
set sv_queryBounceIgnoreTime "12000"
set sv_queryIgnoreDebug "0"

4 megabytes comportam cerca de 326 000 endereços, o que chega também para um flood a sério. Aumente sv_queryIgnoreTime apenas com cautela para além dos 2000 milissegundos predefinidos: a lista de servidores e qualquer navegador de servidores consultam o seu servidor pelo mesmo mecanismo, e quem define um tempo de bloqueio demasiado alto desaparece da lista. Ponha sv_queryIgnoreDebug temporariamente a 1 se quiser saber se o travão está sequer a funcionar, e volte a pô-lo a 0 depois, para que o log não lhe encha o disco.

4. Separar os floods de query na firewall

O travão na engine só atua depois de o pacote ter chegado ao processo do jogo. Uma regra de firewall decide mais cedo e custa menos. Estas duas linhas limitam o getstatus por endereço de origem:

iptables -A INPUT -p udp --dport 28960 -m length --length 41:45 -m recent --set --name cod_query --rsource
iptables -A INPUT -p udp --dport 28960 -m string --algo bm --string "getstatus" -m recent --update --seconds 2 --hitcount 4 --name cod_query --rsource -j DROP

A primeira linha memoriza cada endereço de origem que envie um pacote com o comprimento típico de uma consulta de estado. A segunda descarta cada pedido getstatus adicional assim que o mesmo endereço tenha enviado mais de quatro deles em dois segundos. Quatro pedidos por cada dois segundos chegam a qualquer navegador de servidores. Nos fóruns circulam também variantes com 20 pedidos por segundo, bastante mais generosas, que funcionam mais contra bots grosseiros do que contra uma onda de reflexão bem feita.

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. Verifique depois 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.

5. Desligar o RCON ou mantê-lo bem apertado

O acesso RCON mais seguro é aquele que não existe. Um rcon_password vazio recusa qualquer pacote de RCON:

set rcon_password ""

Tenha em conta um pormenor: mesmo assim o servidor continua a responder, nomeadamente com uma mensagem de erro, e permanece portanto um pequeno amplificador. Quem quiser excluir isso e, de qualquer forma, só precisa de RCON a partir de um endereço fixo descarta os pacotes antes disso:

iptables -A INPUT -p udp --dport 28960 ! -s 203.0.113.10 -m string --algo bm --string "rcon " -j DROP

Esta regra tem um efeito secundário que deve conhecer: a cadeia de carateres rcon pode teoricamente aparecer também num pacote de chat de um jogador ligado, e esse pacote seria igualmente descartado. Na prática isso é tolerável. Quem não quiser o efeito secundário deixa a regra de lado e trabalha apenas com uma palavra-passe vazia ou muito longa.

6. Travar o flood de entradas e o esgotamento de slots

Um flood de entradas não visa a linha, mas sim a lógica de jogo: o atacante envia em sequência rápida pacotes getchallenge e connect até todos os slots estarem ocupados com ligações a meio. Os jogadores reais recebem então "Server is full", embora não esteja ninguém dentro do jogo. Contra isso funcionam estas definições:

set sv_maxclients "32"
set sv_reconnectLimit "3"
set sv_floodProtect "1"
set sv_connectTimeout "30"
set sv_timeout "120"

sv_reconnectLimit limita quantas vezes o mesmo jogador se pode voltar a ligar seguidamente. sv_floodProtect limita quantos comandos de cliente o servidor processa por jogador e impede assim que um único cliente trave o servidor com comandos. sv_connectTimeout e sv_timeout determinam quanto tempo uma ligação a meio, ou uma ligação muda, bloqueia um slot: quem deixa aqui valores generosos vindos de um modelo antigo facilita ao atacante o esgotamento dos slots.

No CoD4X acresce sv_authorizemode. O valor 1 deixa entrar apenas jogadores com cópia válida, o 0 apenas jogadores sem ela, e o -1 ambos. Quem define 1 exclui grande parte dos clientes descartáveis, mas perde também jogadores reais sem cópia original. O meio mais duro é uma palavra-passe de servidor através de g_password, que funciona contra tudo o que use o caminho normal de entrada. E uma coisa tem de ficar clara: uma palavra-passe 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. A entrada na lista de servidores e o seu próprio endereço

Aqui compensa mais a honestidade do que o pensamento mágico: o seu endereço IP não se consegue manter em segredo. Qualquer jogador que se tenha ligado uma vez conhece-o, e a entrada na lista publica-o de qualquer forma, juntamente com a porta. Pode desligar a entrada não definindo nenhum servidor mestre no server.cfg (os dvars chamam-se sv_master1, sv_master2 e assim por diante). Isso custa, no entanto, toda a visibilidade junto de novos jogadores e só ajuda contra o mais preguiçoso dos atacantes.

Uma nota sobre o estado das listas: os servidores mestre originais da Activision (codmaster.activision.com na 20510, cod2master.activision.com na 20710, cod4master.activision.com na 20810) já não respondem a nada para os títulos antigos. Quem quiser estar listado hoje usa as listas comunitárias: o CoD4X opera uma própria e exige para isso um token em sv_authtoken, e o Plutonium traz consigo uma lista de servidores própria. Quanto ao essencial nada muda, o endereço fica ali igualmente em texto simples.

Duas práticas funcionam mesmo assim. Não publique o endereço IP em bruto em lado nenhum, ou seja, nem no canal de Discord nem na página do clã. E ligue os seus jogadores através de um hostname, para que em caso de necessidade possa mudar de endereço sem que todas as referências deixem de funcionar. O clássico, aqui, é um registo A esquecido a apontar para o endereço antigo: torna qualquer mudança inútil.

8. Retirar interfaces web, base de dados e Fast Download da rede aberta

Além do jogo, na maioria dos servidores de Call of Duty corre ainda mais coisa: o IW4MAdmin com a sua interface web na porta 1624, um servidor web para o Fast Download dos mapas, por vezes uma base de dados para estatísticas. Cada um destes serviços é uma superfície de ataque própria, e nenhum deles pertence sem limites à rede aberta.

Restrinja a 1624 ao seu próprio endereço ou aceda à interface através de um encaminhamento SSH e abra depois localmente http://127.0.0.1:1624:

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

Ligue a base de dados a 127.0.0.1, ela não tem em caso algum nada que fazer na rede aberta. E coloque o Fast Download num servidor web próprio em vez de o deixar no processo do jogo: um servidor web sob carga retira ao jogo exatamente o tempo de processamento de que ele precisa para a simulação.

9. Registar em log, para ter dados quando for preciso

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 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 port 28960 -c 200 -q

Para o Call of Duty existe um quinto, que responde à pergunta decisiva. Esta captura mostra exclusivamente os pacotes sem ligação, ou seja, precisamente getstatus, getinfo, getchallenge, connect e rcon:

tcpdump -ni eth0 'udp port 28960 and udp[8:4] = 0xffffffff' -c 200 -A

Se ali aparecer getstatus às centenas a partir de endereços sempre novos, tem um flood de query. Se ali aparecer rcon, alguém está a tentar adivinhar a sua palavra-passe. Se ali aparecerem apenas getchallenge e connect, é um flood de entradas. Quanto ao tcpdump vale sempre a regra: limitar 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.

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 servidor cheio de 32 slots gera à saída cerca de 6,4 Mbit/s, o que é menos de um por cento de uma linha de gigabit. Essa mesma linha fica cheia assim que alguém enviar 125 megabytes por segundo, e é precisamente para isso que estão feitos os ataques que se encomendam por dez euros por mês. Se a sua regra de iptables por trás é boa deixa então de ter importância, porque os pacotes dos seus jogadores já nem chegam a passar.

A segunda grandeza é a taxa de pacotes, e no Call of Duty é regularmente ela a chegar 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 pedido getstatus, com 41 bytes, é ainda mais pequeno do que isso: um ataque que nem sequer enche um terço da sua linha deixa mesmo assim o seu servidor inoperacional, porque todo 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".

No Call of Duty acresce uma particularidade que agrava as contas. Como jogo, query e RCON estão na mesma porta, não pode fechar a 28960 em caso de emergência: seria o mesmo que desligar o servidor. E como a engine responde a cada consulta de estado com um múltiplo do tamanho do pedido, um atacante gasta, para o mesmo efeito, menos largura de banda própria do que noutros jogos.

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. 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 clãs e comunidades 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 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 o que é permitido na 28960 UDP sem ter de escrever um ticket para isso e, havendo várias instâncias, separadamente por porta.
• As alterações entram em vigor em tempo real, pelo que pode afinar durante um ataque em curso.
• Perfil de proteção adequado a cada jogo, também para aplicações modificadas e próprias em quaisquer portas TCP ou UDP. Esse é o ponto relevante para o Plutonium e o CoD4X, porque as portas deles podem divergir das predefinições.

A Advanced DDoS Protection destina-se a servidores alojados na KernelHost. Se o seu servidor de Call of Duty corre atualmente noutro sítio e é ali retirado da rede com regularidade, a mudança para a KernelHost é o caminho que muda alguma coisa.

Os dois níveis em comparação

Para a maioria dos servidores de Call of Duty, a proteção permanente incluída chega, em conjunto com um server.cfg limpo. A Advanced DDoS Protection é a resposta para quando alguém leva a coisa a peito.

Erros frequentes e respetivas soluções

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

"O meu fornecedor envia-me uma queixa de abuso, quando a vítima sou eu": então o seu servidor não é o alvo, mas sim o amplificador. Alguém envia pedidos getstatus falsificados e o seu servidor responde obedientemente a uma vítima alheia. Verifique primeiro se sv_queryIgnoreMegs está a 0 e defina os quatro dvars de query, bem como a regra de firewall da secção 4.

"O servidor aparece na lista como cheio, mas está vazio": isso é um flood de entradas, e atinge a lógica de jogo, não a linha. Contra isso funcionam o sv_reconnectLimit, valores mais curtos para sv_connectTimeout e sv_timeout e, na dúvida, uma palavra-passe de servidor.

"O servidor desaparece da lista de servidores durante o ataque": isso é a consequência, não a causa. A lista de servidores verifica pelas mesmas consultas de estado se o seu servidor está vivo. Se as respostas não passarem, ou se tiverem sido descartadas pelo seu próprio travão, o servidor conta como offline. Verifique se sv_queryIgnoreTime está demasiado alto antes de suspeitar da firewall.

"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.

"O servidor está a funcionar, mas todos os jogadores têm lag spikes": olhe primeiro para a taxa de pacotes da interface, não para a carga do CPU. Se o sar -n DEV 1 10 não mostrar nada de especial e mesmo assim houver engasgos, a causa está quase sempre num mod, num sv_maxRate exagerado ou simplesmente em demasiados bots na ronda.

"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 clássico de Call of Duty precisa de exatamente uma porta aberta: 28960 UDP. No Plutonium T6 é a 4976 UDP, no Plutonium IW5 a 27016 UDP.
• No Call of Duty, o jogo, a consulta de estado e o RCON estão na mesma porta. Não consegue separar o RCON do jogo com uma regra de porta, para isso precisa de uma regra que olhe para o conteúdo do pacote.
• A reflexão getstatus é o vetor de amplificação típico do jogo: 41 bytes de pedido e, segundo o alerta TA14-017A da CISA, um fator de 63,9 no protocolo de rede Quake, ou seja, cerca de 2 600 bytes de resposta.
• Ligue o travão de query: sv_queryIgnoreMegs 4, sv_queryIgnoreTime 2000, sv_queryBounceIgnoreTime 12000. Em muitos servidores está a 0 e, portanto, desligado.
• Defina rcon_password apenas se precisar mesmo de RCON: a palavra-passe circula sem cifragem sobre UDP e pode ser adivinhada as vezes que quiserem, sem bloqueio de conta.
• As portas dos servidores mestre 20810 e 20800 são portas de destino de saída e não pertencem às suas aberturas de entrada.
• A partir de cerca de 1 Gbit/s ou de algumas centenas de milhares de pacotes por segundo, quem decide é exclusivamente a rede à frente do servidor, já não a sua configuração.

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