Proteger um servidor ARK contra ataques DDoS

Um cluster de ARK raramente cai num momento aleatório. Quem gere servidores PvP conhece o padrão: pouco antes de uma base alheia ser destruída, o servidor fica inacessível, todos os jogadores são atirados para fora e, quando volta, o raid já está feito. Este artigo mostra primeiro o que pode configurar no próprio servidor, depois onde estas medidas acabam do ponto de vista técnico e, por fim, o que a KernelHost coloca à frente.

Porque é que o ARK é atacado de forma tão dirigida

Na maioria dos jogos, uma falha do servidor é apenas irritante. No ARK: Survival Evolved e no ARK: Survival Ascended, é uma jogada. As perdas dentro do jogo são permanentes, uma janela de raid dura poucos minutos e qualquer proteção contra raids offline só funciona enquanto o servidor estiver acessível. Quem tira os defensores do jogo durante dez minutos ganha recursos e criaturas. O ataque tem, assim, um lucro concreto e um momento planeado, e repete-se assim que resultar uma vez.

A isto junta-se a forma como um cluster é construído. Vários mapas correm normalmente na mesma máquina, atrás do mesmo endereço IP. Por isso, um ataque não atinge um servidor, mas sim The Island, Ragnarok, Aberration e a transferência entre eles ao mesmo tempo. Os jogadores que ficam presos exatamente durante a transferência perdem, no pior dos casos, a personagem e os objetos. O que acontece do ponto de vista técnico num ataque DDoS está descrito no artigo O que é um ataque DDoS?.

As portas que interessam

O ARK transmite todo o tráfego de jogo por UDP. É essa a razão pela qual muitos guias de firewall não ajudam aqui: abrem TCP.

O Survival Evolved ocupa ainda a porta imediatamente acima da porta de jogo, porque o motor abre aí um segundo socket UDP. O Survival Ascended já não precisa desta segunda porta. A porta de consulta responde a pedidos de estado no formato Steam (nome do servidor, mapa, número de jogadores, tempo de jogo) e é a porta mais interessante para quem ataca.

Num cluster, as portas atribuem-se de dois em dois, para que o segundo socket não colida com a instância seguinte: 7777 e 7778 para o primeiro mapa, 7779 e 7780 para o segundo, mais 27015 e 27016 como portas de consulta.

O que pode fazer sozinho antes de gastar dinheiro

Os passos seguintes não custam nada e funcionam contra os casos mais frequentes: floods pequenos e dirigidos a partir de poucas fontes, portas de consulta usadas de forma abusiva e tentativas de assumir o controlo por RCON. Valem a pena mesmo quando já existe um filtro de rede a trabalhar à frente.

1. Abrir apenas o que o cluster precisa mesmo

Um host de ARK acumula depressa mais portas abertas do que se imagina: o painel, a base de dados, um servidor web para o mapa e ainda as instâncias do jogo. Cada uma delas é um alvo para pacotes. O conjunto de regras nftables seguinte, para /etc/nftables.conf, deixa passar aquilo de que um cluster com dois mapas precisa e descarta o resto.

#!/usr/sbin/nft -f

flush ruleset

table inet ark {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set queryflood {
        type ipv4_addr
        size 65535
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority 0; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        ip saddr @adminips tcp dport { 22, 27020 } accept

        udp dport { 7777-7780 } accept

        udp dport { 27015-27016 } add @queryflood { ip saddr limit rate over 10/second burst 20 packets } drop
        udp dport { 27015-27016 } accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Indique o seu endereço IP fixo em adminips antes de carregar as regras, caso contrário fica fechado fora do SSH.

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset

nft -c verifica apenas a sintaxe e não altera nada. Só o segundo comando carrega o conjunto de regras e faz com que sobreviva a um reinício. Quem preferir trabalhar com a UFW encontra esse caminho em Configurar a firewall UFW. Atenção: flush ruleset apaga também as regras da UFW e do Docker. Se um dos dois estiver a correr, deixe essa linha de fora.

2. Limitar a porta de consulta em vez de a fechar

A porta de consulta é a única porta em que o seu servidor devolve a qualquer desconhecido uma resposta bastante maior do que o pedido. Daí resultam dois problemas. Primeiro, o seu servidor pode ser abusado como amplificador: o atacante falsifica o endereço de origem, o seu servidor responde a uma vítima que não conhece e a sua linha carrega com o tráfego de saída. Segundo, cada resposta custa tempo de CPU exatamente no processo que também calcula o jogo. Por isso, um flood contra a 27015 nota-se muitas vezes como lag e não como quebra de ligação.

Fechar a porta não é solução, porque assim o servidor desaparece da lista de servidores. Em vez disso, a regra acima limita por endereço de origem: dez consultas por segundo com uma margem de vinte pacotes chegam para os jogadores e para a monitorização, ao passo que uma fonte com milhares de pedidos por segundo é descartada. Os endereços que estão a ser limitados neste momento são mostrados por:

nft list set inet ark queryflood

3. Retirar o RCON da internet

O RCON dá controlo total: quem tiver a palavra-passe expulsa jogadores, desliga o servidor e mexe no mundo do jogo. A porta é TCP, a palavra-passe está em texto simples na configuração e o início de sessão pode ser tentado as vezes que se quiser. É por isso que, no conjunto de regras acima, essa porta só está aberta para o endereço do administrador.

[ServerSettings]
RCONEnabled=True
RCONPort=27020
ServerAdminPassword=<palavra-passe aleatória longa>

O ficheiro GameUserSettings.ini encontra-se em ShooterGame/Saved/Config/, dentro do diretório do servidor. Uma palavra-passe utilizável é gerada por:

openssl rand -base64 24

Se um painel web na mesma máquina usar RCON, basta o acesso por 127.0.0.1 e a porta continua fechada a partir do exterior. Se o painel correr noutro sítio, o endereço dele entra em adminips e em mais lado nenhum.

4. Aliviar o seguimento de ligações

Um flood UDP raramente derruba um servidor Linux pela largura de banda, mas sim pelo seguimento de ligações. O kernel cria uma entrada para cada pacote UDP recebido, a tabela enche e, a partir daí, descarta também os pacotes de jogadores reais, o que se reconhece por nf_conntrack: table full, dropping packet no log do sistema. Para o tráfego de jogo esse seguimento não serve de nada, portanto retire de lá as portas do jogo:

table inet arkraw {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        udp dport { 7777-7780, 27015-27016 } notrack
    }

    chain output {
        type filter hook output priority -300; policy accept;
        udp sport { 7777-7780, 27015-27016 } notrack
    }
}

São precisas as duas direções, caso contrário ficam entradas incompletas para o tráfego de saída. A isso juntam-se alguns parâmetros do kernel em /etc/sysctl.d/90-ark.conf:

net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_udp_timeout = 15
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216
net.ipv4.tcp_syncookies = 1

sysctl --system
cat /proc/sys/net/netfilter/nf_conntrack_count

Se o segundo valor subir na direção do máximo durante um ataque, o estrangulamento estava no seguimento de ligações e não na linha.

5. Whitelist e palavra-passe do servidor

Se o seu cluster serve de qualquer forma um grupo fechado, uma lista de acesso é a medida mais eficaz contra quem vem incomodar. O ARK traz essa lista de origem e, para isso, o servidor arranca com -exclusivejoin:

./ShooterGameServer "TheIsland?listen?SessionName=MeuCluster?Port=7777?QueryPort=27015?RCONEnabled=True?RCONPort=27020" -server -log -exclusivejoin

Os jogadores autorizados ficam depois, um identificador por linha, em PlayersExclusiveJoinList.txt, no diretório do binário do servidor. Em funcionamento, a lista é mantida a partir da consola do servidor ou por RCON:

AllowPlayerToJoinNoCheck <ID do jogador>
DisallowPlayerToJoinNoCheck <ID do jogador>

Uma palavra-passe de servidor através de ServerPassword funciona de forma parecida, mas a experiência mostra que passa depressa de boca em boca. Ambas têm o mesmo limite duro: a verificação acontece dentro do processo do jogo, ou seja, só depois de o pacote ter chegado. Contra uma avalanche de pacotes uma whitelist não ajuda, mas contra o jogador que primeiro anda a espiar o seu cluster ajuda bastante.

6. O que o anti-cheat e os plugins conseguem fazer, e o que não

Ambos os títulos trazem de origem um sistema anti-cheat e existem ainda plugins de servidor através da respetiva API de servidor. As duas coisas fazem sentido, mas resolvem outro problema. O anti-cheat verifica se um cliente ligado está manipulado, e um plugin consegue contar tentativas de ligação ou desligar jogadores com comportamento suspeito. Todas estas verificações correm no mesmo processo que o jogo e só atuam quando o pacote já está a ser processado. Se o processo estiver saturado, a lógica de proteção cai com ele. É por essa razão que não pode existir um plugin capaz de travar ataques DDoS. O que ajuda mesmo assim: manter atualizados os ficheiros do servidor e os mods, e manter o número de mods baixo, porque boa parte dos crashes em clusters de ARK são mods defeituosos e não ataques.

7. O seu endereço está na lista de servidores

Um servidor de ARK listado publicamente divulga o endereço IP e a porta de consulta, caso contrário ninguém o conseguiria encontrar, e essas listas são consultadas e arquivadas de forma automatizada sem parar. O seu endereço passa portanto a ser conhecido assim que o servidor tenha sido listado uma única vez. Esconder-se não é opção, porque quem não se lista não cresce. Restam os caminhos laterais por onde um endereço escapa adicionalmente:

• Registos DNS antigos. Um registo A que ainda aponta para o servidor anterior denuncia o endereço antigo. Esses registos devem ser apagados.
• Outros serviços no mesmo endereço. O site, a vista do mapa, o painel, o servidor de voz e a base de dados são, cada um deles, um segundo caminho para atingir o cluster.
• O próprio Discord. Os bots de estado, as capturas de ecrã da consola e os guias de ligação contêm muitas vezes o endereço em texto simples.

8. Medir em vez de adivinhar

O erro mais frequente no meio de uma avaria é o diagnóstico errado. Um mod que rebentou, um sistema de ficheiros cheio e um ataque a sério sentem-se exatamente da mesma maneira para os jogadores. Distingui-los leva um minuto. Primeiro, a taxa de pacotes na placa de rede:

r1=$(cat /sys/class/net/eth0/statistics/rx_packets)
sleep 1
r2=$(cat /sys/class/net/eth0/statistics/rx_packets)
echo "$((r2-r1)) pacotes por segundo"

Um cluster com cinquenta jogadores situa-se normalmente na casa das dezenas de milhar, ao passo que valores de seis ou sete dígitos são um ataque. A seguir, os contadores da pilha de rede:

nstat -az UdpInDatagrams UdpNoPorts UdpRcvbufErrors
ss -ulnp | grep -E '7777|27015'

UdpNoPorts sobe quando chegam pacotes a portas onde nada está à escuta, um sinal típico de um flood disparado às cegas. UdpRcvbufErrors sobe quando o processo do servidor já não recolhe os pacotes com rapidez suficiente. Por fim, o log do jogo:

tail -n 200 ShooterGame/Saved/Logs/ShooterGame.log

Se aí estiver um relatório de crash enquanto os contadores de pacotes não mostram nada de estranho, não foi um ataque. Durante uma avaria, dispense o tcpdump, porque a captura custa tempo de CPU num sistema que neste momento não o tem. Outros sinais são indicados no artigo Detetar um ataque DDoS no servidor.

Onde estas medidas acabam

Tudo o que foi descrito até aqui atua no servidor, e é exatamente aí que está o limite. Uma regra de firewall só consegue descartar o que já chegou. Mas o estrangulamento está antes disso, na linha.

Os números são claros. Uma ligação de 1 Gbit/s fica saturada, com os pacotes mais pequenos possíveis, a partir de cerca de 1,49 milhões de pacotes por segundo, independentemente daquilo que o servidor pretenda fazer com eles. Um flood UDP real contra um gameserver de ARK na KernelHost, na porta 7777, chegou a mais de 112,2 Gbit/s e a mais de 8,7 milhões de pacotes por segundo, ou seja, cerca de 1,6 kilobytes por pacote em média. Isso é 112 vezes uma linha de 1 Gbit/s e ainda mais de onze vezes uma linha de 10 Gbit/s.

O segundo estrangulamento também se atinge depressa: com um conjunto de regras normal, um núcleo de CPU descarta, consoante o hardware, algumas centenas de milhares de pacotes por segundo. Com 8,7 milhões, essa conta não fecha nem com muitos núcleos. A regra atua corretamente e mesmo assim o servidor fica offline.

Por isso, os ataques volumétricos têm de ser filtrados na rede, à frente do servidor. No próprio servidor não há solução, nem com mais hardware nem com um conjunto de regras melhor.

O que a KernelHost coloca à frente

A proteção permanente incluída em cada servidor

Em cada servidor da KernelHost corre uma proteção DDoS permanente de dois níveis, sem encomenda e sem configuração. O primeiro nível é uma rede global de scrubbing com 17 Tbps de capacidade de mitigação: os ataques volumétricos são travados perto da sua origem, muito antes de chegarem ao datacenter. O segundo nível é uma filtragem Arbor em tempo real com 3,2 Tbps, no local, no datacenter maincubes em Frankfurt am Main, na Alemanha. É ela que faz o trabalho fino nas camadas 3, 4 e 7 e conhece os padrões de protocolo dos gameservers mais comuns.

Três características são decisivas. A proteção está permanentemente ativa, ou seja, não existe um tempo de reação durante o qual um ataque ainda tivesse de ser detetado. Não se recorre a null-routing, o endereço IP atacado permanece na rede e só os pacotes maliciosos caem. E não custa nada a mais. Como isto funciona para gameservers está descrito no artigo Proteção DDoS para gameservers em tempo real.

Advanced DDoS Protection para projetos atacados de forma continuada

Alguns clusters não são atingidos uma única vez, mas ao longo de semanas, todas as noites à mesma hora e com padrões que vão mudando. Para esses casos existe a Advanced DDoS Protection a partir de 50,00 € por mês, em PrePaid e, por isso, sem prazo mínimo, sem período de aviso prévio, sem contrato e sem taxa de instalação.

Recebe um endereço IP de proteção dedicado do núcleo de Frankfurt. O seu servidor é comutado para esse endereço dentro da rede da KernelHost, pelo que não há nada a alterar do seu lado. A diferença vem a seguir: as regras de proteção são geridas por si na área de cliente, separadas por porta e protocolo, e as alterações fazem efeito em tempo real, sem ticket. Como perfil de proteção escolhe o título que a respetiva porta serve, disponível para mais de 40 jogos, serviços e protocolos, entre eles o ARK: Survival Evolved. Para um cluster, isso significa: perfil de jogo nas portas de jogo, um limite mais apertado na porta de consulta e uma regra própria para um painel web, em vez do mesmo compromisso em todo o lado.

Os dois níveis em comparação

Erros frequentes e soluções

Só o TCP foi aberto, o servidor está a correr, mas ninguém consegue entrar: o tráfego de jogo do ARK é UDP e uma regra para tcp dport 7777 não muda nada nisso. Verifique com ss -ulnp e abra as portas como udp dport.

O servidor está acessível, mas não aparece na lista de servidores: normalmente a porta de consulta está fechada ou o rate limit está demasiado apertado. Abra a 27015 UDP e suba o limite. Para controlo, nft list set inet ark queryflood mostra que endereços estão a ser limitados.

O próprio bot de estado dá o servidor como offline, apesar de haver jogadores nele: um bot do Discord consulta a partir de um único endereço de origem, muitas vezes várias vezes por segundo e para cada mapa em separado, batendo assim no mesmo limite que um atacante. Coloque uma exceção para esse endereço antes da regra de limite.

Depois de carregar o conjunto de regras já não é possível aceder por SSH: em adminips estava o endereço errado, ou o SSH corre noutra porta. Volta a entrar no servidor pela consola VNC na área de cliente, já que nos servidores dedicados e nos servidores root KVM não existe IPMI nem iDRAC. Aí execute nft flush ruleset como travão de emergência e corrija depois o ficheiro.

O sysctl não consegue definir os valores do conntrack: os parâmetros em net.netfilter só existem depois de o módulo estar carregado. Carregue-o com modprobe nf_conntrack e execute sysctl --system outra vez.

Um suposto ataque é, na realidade, um mod: se os contadores de pacotes estiverem normais e existir um relatório de crash em ShooterGame.log, a causa não foi a rede. Depois de uma atualização no Workshop, essa é a explicação mais provável, sobretudo quando é sempre o mesmo mapa a ser afetado.

O cluster inteiro fica offline ao mesmo tempo: todas as instâncias estão presas ao mesmo endereço IP, portanto um ataque atinge tudo de uma vez, incluindo as transferências. Um IP de proteção dedicado resolve exatamente este padrão, porque a filtragem passa a estar à frente do endereço em vez de estar no servidor por trás dele.

Em resumo

Abra apenas as portas de jogo, a porta de consulta e o acesso para o seu próprio endereço, limite a porta de consulta por fonte, mantenha o RCON fora da internet e meça as taxas de pacotes antes de assumir uma causa. Isto não custa nada e cobre o dia a dia. Tudo o que vai além disto já não se decide no servidor: a proteção permanente incluída, com 17 Tbps de capacidade de mitigação na rede global de scrubbing e 3,2 Tbps de filtragem Arbor em tempo real em Frankfurt am Main, trava esses ataques sem custo adicional e sem null-routing. Em caso de fogo continuado, a Advanced DDoS Protection acrescenta um IP de proteção dedicado com regras definidas por si. O operador é a KernelHost GmbH, com sede em Viena, na Áustria.