Proteger servidores SA-MP e open.mp contra ataques DDoS

Um projeto de SA-MP ou de open.mp cresce quase sempre pelo mesmo padrão: o número de jogadores sobe, o servidor trepa na lista e, poucos dias depois, as ligações começam a cair umas atrás das outras. A parte mais longa deste guia descreve o que pode alterar por conta própria no seu servidor, sem custos adicionais. A seguir fica explicado onde estas medidas terminam do ponto de vista técnico e, só depois, o que a KernelHost lhes contrapõe.

Porque é que são precisamente o SA-MP e o open.mp a ser atingidos com tanta frequência

A cena é pequena e muito competitiva. Há muitos servidores de roleplay e de freeroam a disputar os mesmos jogadores, e a barreira para tirar um concorrente da lista durante algumas horas é baixa. A isso juntam-se jogadores banidos e tentativas de extorsão contra projetos que têm loja própria.

Do lado técnico, o jogo facilita a vida a quem ataca. Todo o tráfego de jogo corre sobre UDP, e o UDP não tem um estabelecimento de ligação que custe alguma coisa ao atacante; além disso, os endereços de origem falsificam-se com facilidade. A entrada na lista publica o endereço e a porta, pelo que nem sequer é preciso um reconhecimento prévio. E como a maioria dos projetos corre num único servidor, o servidor de jogo, a base de dados, o painel de utilizadores e muitas vezes o servidor de voz partilham o mesmo endereço: um acerto derruba tudo ao mesmo tempo.

As portas e os protocolos em causa

• Servidor SA-MP: 7777 UDP por predefinição, ajustável através de port no server.cfg.
• Servidor open.mp: também 7777 UDP por predefinição, ajustável através de network.port no config.json.
• Query: a mesma porta UDP. Não existe uma porta de consulta separada. O browser de servidores, as páginas de estado e os bots do Discord contactam exatamente a porta por onde também se joga.
• RCON: igualmente a mesma porta UDP, como opcode próprio dentro do protocolo de query e em texto simples.
• A entrada na lista é feita de saída para a respetiva lista de servidores, pelo que não é preciso abrir nada de entrada.
• Tudo o resto na mesma máquina: SSH na 22 TCP, MariaDB ou MySQL na 3306 TCP, o painel de utilizadores na 80 e na 443 TCP.

A consequência: não consegue separar o acesso de query do funcionamento do jogo com a firewall, porque ambos estão na mesma porta. Quem bloqueia a 7777 UDP tranca os próprios jogadores fora do servidor.

Um pedido de query começa com onze bytes: quatro bytes de identificação, quatro bytes de endereço do servidor, dois bytes de porta e um byte de opcode. O opcode determina a resposta: i devolve as informações do servidor, r as regras, c uma lista curta de jogadores, d uma lista detalhada com nome, pontuação e ping de cada jogador, p reenvia quatro bytes para medir o ping e x é o RCON. Num servidor bem frequentado, onze bytes de pedido geram vários kilobytes de resposta. É isso que torna um acesso de query aberto duplamente interessante: como alvo e como amplificador contra terceiros. O que está por trás deste padrão de ataque fica explicado no artigo O que é um ataque DDoS?.

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

Os passos seguintes não custam nada e funcionam contra os ataques que fazem o dia a dia: enxurradas de joins, enxurradas de query e fontes isoladas com uma taxa de pacotes elevada. Todos os comandos pressupõem root; caso contrário, anteponha sudo.

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

ss -lnup
ss -lntp

O que estiver à escuta em 127.0.0.1 ou em ::1 não precisa de regra de firewall. O que estiver em 0.0.0.0 ou em [::] é contactável a partir do exterior e tem de ter uma justificação.

2. Fechar tudo aquilo de que o jogo não precisa

Um filtro de pacotes não resolve um ataque volumétrico, mas reduz a superfície de ataque. Uma configuração de partida sólida com o UFW:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'SA-MP / open.mp'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

A ordem não é por acaso: as regras de autorização vêm antes de ligar a firewall, senão tranca-se a si próprio fora do servidor. Os pormenores, incluindo o caminho de recuperação, estão no artigo Configurar a firewall UFW. Nos servidores root KVM e nos servidores dedicados da KernelHost, em caso de emergência chega ao sistema através da consola VNC na área de cliente.

A base de dados não pertence à rede aberta. Se ss -lntp | grep 3306 mostrar um 0.0.0.0:3306, defina bind-address = 127.0.0.1 e reinicie o serviço. Também o servidor de jogo deve ficar ligado a um endereço fixo, no SA-MP através de bind e no open.mp através de network.bind.

3. Desarmar o acesso de query sem trancar os jogadores fora

O SA-MP tem no server.cfg a opção query 0, com a qual o servidor deixa de responder a qualquer consulta. Funciona, mas tem um preço alto: o servidor desaparece do browser, o número de jogadores e as regras deixam de ser legíveis, e as páginas de estado e os bots do Discord passam a mostrá-lo como offline. Para um círculo fechado é uma opção, para um projeto em crescimento não é. No open.mp, essa comutação fica na secção network do config.json; verifique o nome exato da chave na sua versão, em vez de o adivinhar.

O caminho realista é, por isso, limitar em vez de desligar. Esta regra de filtragem mostra ao vivo apenas os pacotes com a identificação de query:

tcpdump -ni any -c 100 'udp port 7777 and udp[8:4] = 0x53414d50'

Que endereços de origem enviam mais tráfego para a porta de jogo:

tcpdump -nn -q -c 2000 'udp dst port 7777' 2>/dev/null \
  | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

4. Definir rate limits na stack de rede

Com o nftables limita a taxa de pacotes por endereço de origem. O conjunto de regras seguinte cria uma tabela própria, para não entrar em conflito com o UFW:

nft add table inet gameguard
nft add chain inet gameguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet gameguard input udp dport 7777 meter perip '{ ip saddr limit rate over 60/second burst 120 packets }' drop
nft list table inet gameguard

Faz ainda sentido definir um limite máximo para a porta inteira, para que uma enxurrada muito distribuída não passe pela folga que fica entre muitas fontes isoladas:

nft add rule inet gameguard input udp dport 7777 limit rate over 20000/second burst 5000 packets drop

Com o iptables, o módulo hashlimit consegue o mesmo:

iptables -N SAMPGUARD
iptables -A INPUT -p udp --dport 7777 -j SAMPGUARD
iptables -A SAMPGUARD -m hashlimit --hashlimit-name samp --hashlimit-mode srcip \
  --hashlimit-above 60/sec --hashlimit-burst 120 --hashlimit-htable-expire 30000 -j DROP

Estes números são valores de partida, não uma recomendação para o seu servidor. Um único jogador gera algumas dezenas de pacotes por segundo só com a sincronização de posição; a cadência é controlada no SA-MP através de onfoot_rate, incar_rate e weapon_rate. A coisa fica crítica quando vários jogadores estão atrás do mesmo endereço, por exemplo na mesma casa ou atrás do carrier NAT de um operador móvel. Um limite demasiado apertado expulsa precisamente esses jogadores, e isso tem o aspeto de um ataque. Primeiro medir, depois definir e depois observar as quebras de ligação.

5. Limites no server.cfg e no config.json

As duas implementações trazem limites de proteção próprios, que muitas vezes ficam nas predefinições. Para o SA-MP, no server.cfg:

lanmode 0
query 1
announce 1
rcon 0
conncookies 1
connseedtime 300000
minconnectiontime 1000
messageslimit 500
messageholelimit 3000
ackslimit 3000
playertimeout 10000

No open.mp, os mesmos parâmetros estão no config.json:

{
  "network": {
    "port": 7777,
    "bind": "",
    "use_lan_mode": false,
    "cookie_reseed_time": 300000,
    "minimum_connection_time": 1000,
    "messages_limit": 500,
    "message_hole_limit": 3000,
    "acks_limit": 3000,
    "player_timeout": 10000,
    "limits_ban_time": 60000
  },
  "rcon": {
    "enable": false
  }
}

O que estes valores fazem:

• Os cookies de ligação (conncookies ou cookie_reseed_time) exigem do cliente uma resposta a uma pergunta de retorno antes de ser ocupado um slot. Um endereço de origem falsificado nunca chega a ver essa pergunta e, por isso, também não consegue responder-lhe. É o travão integrado mais eficaz contra enxurradas de ligações, deixe-o ligado.
• O intervalo mínimo entre tentativas de ligação (minconnectiontime ou minimum_connection_time, em milissegundos) impede que o mesmo endereço estabeleça ligações novas ao ritmo de uma por segundo. Contra os joins de bots, este é o segundo parâmetro importante.
• Os limites de mensagens, de falhas e de confirmações (messageslimit, messageholelimit, ackslimit) definem quanto é que uma ligação já estabelecida pode enviar. Protegem contra clientes manipulados, não contra volume.
• O timeout (playertimeout, player_timeout) determina durante quanto tempo uma ligação silenciosa bloqueia um slot. Um valor baixo liberta lugares mais depressa numa enxurrada de joins, mas também expulsa mais cedo os jogadores com uma ligação fraca. A duração do bloqueio (limits_ban_time no open.mp) define durante quanto tempo um endereço suspeito fica excluído.

Duas notas: o config.json tem de continuar a ser JSON válido, porque uma vírgula a mais impede o arranque. E o open.mp completa sozinho as definições em falta durante o arranque, por isso edite o ficheiro com o servidor parado.

Ainda uma palavra sobre o RCON: a palavra-passe corre em texto simples sobre UDP e é legível ao longo de todo o caminho. Se não precisar do RCON, desligue-o com rcon 0 ou com "enable": false; caso contrário, vale a regra: palavra-passe longa e aleatória, e acesso apenas através de uma VPN.

6. Defesa no gamemode e nos plugins

O SA-MP chama OnIncomingConnection antes de ser ocupado um slot de jogador. É aí que pode ir contando e bloquear temporariamente os endereços suspeitos:

public OnIncomingConnection(playerid, ip_address[], port)
{
    if (ConnectAttemptsTooHigh(ip_address))
    {
        BlockIpAddress(ip_address, 60000);
    }
    return 1;
}

ConnectAttemptsTooHigh é de propósito uma função de contagem sua: os limiares razoáveis dependem do seu número de jogadores. BlockIpAddress espera a duração do bloqueio em milissegundos, e UnBlockIpAddress levanta-o antes do tempo. A lista de bloqueios fica na memória RAM e está vazia depois de um reinício.

A somar a isso, há duas ferramentas que pertencem a qualquer projeto. O plugin crashdetect mostra, num crash, a função afetada e a linha no gamemode; sem ele, um erro de execução no seu próprio código vê-se de fora exatamente como um ataque. Um anti-cheat bem mantido como o Nex-AC cobre as manipulações do lado do cliente, mas trabalha exclusivamente sobre jogadores ligados e dentro da lógica de jogo. Uma enxurrada de pacotes falsificados nunca chega a tornar-se um jogador e passa ao lado disso. São dois problemas diferentes.

Mantenha além disso os includes e os plugins atualizados: vários métodos conhecidos para provocar crashes no SA-MP assentam em valores fora do intervalo válido que são passados a funções nativas. E nunca encaminhe entradas de jogadores não validadas para SendRconCommand nem para uma consulta à base de dados.

7. A entrada na lista de servidores e o seu endereço real

A entrada na lista torna-o encontrável, tanto para os jogadores como para quem ataca. Com announce 0 desaparece das duas listas e, com elas, também do afluxo orgânico de jogadores. É uma ponderação, não uma dica milagrosa.

Pôr um domínio à frente não ajuda: o cliente resolve o nome uma vez e a partir daí fala diretamente com o endereço, e esse nome qualquer pessoa o consegue resolver. Verifique antes o que mais denuncia o seu endereço: registos A e AAAA antigos no DNS, o painel de utilizadores na mesma máquina, a indicação de estado de um bot do Discord, uma interface web de base de dados aberta, certificados TLS com hostnames antigos e mensagens de fórum dos primeiros tempos.

Daqui resulta uma regra que muitos projetos aprendem tarde de mais: quando muda para um endereço protegido, mude ao mesmo tempo o endereço de origem. Caso contrário, o antigo fica em todas as bases de dados de scanners e o ataque passa ao lado da proteção.

8. Whitelist e funcionamento fechado

Para a porta de jogo, uma whitelist raramente é praticável, porque os jogadores chegam de endereços que mudam. Uma palavra-passe de servidor (password nas duas implementações) transforma o servidor num círculo fechado sem qualquer esforço, mantendo a entrada na lista. Já para os acessos de administração a whitelist é obrigatória, ou seja, para o SSH, a base de dados, o painel e, se o mantiver, o RCON:

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'Admin'
ufw delete allow 22/tcp
ufw status numbered

Se o endereço da sua ligação mudar, uma VPN é mais limpa do que uma lista de exceções que não para de crescer.

9. Registar em log: primeiro medir, depois agir

O SA-MP escreve o seu log no server_log.txt, dentro da diretoria do servidor, e o open.mp no ficheiro configurado na secção logging. Que endereços batem à porta com mais frequência:

grep "Incoming connection" server_log.txt \
  | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' \
  | sort | uniq -c | sort -rn | head -20

Um número elevado de cookies de ligação pedidos aponta para uma enxurrada de joins:

grep -c "requests connection cookie" server_log.txt

O valor mais revelador não está, porém, no log do jogo, mas sim no kernel. Se o processo do servidor não retirar os pacotes do buffer de receção com rapidez suficiente, é o kernel que vai contando as perdas:

nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
ip -s -s link show

Daqui sai a distinção mais importante de todas: se os erros de buffer subirem com uma carga de CPU baixa, está a chegar-lhe mais tráfego do que o processo consegue tratar. Se, pelo contrário, houver um núcleo no máximo enquanto o tráfego parece normal, o problema está no gamemode e não na rede. Como distinguir os dois casos fica descrito no artigo Detetar um ataque DDoS no servidor.

Onde é que estas medidas terminam

Todos os passos anteriores só atuam depois de os pacotes já terem passado pela sua linha: o kernel descarta-os à chegada. Fica assim definido um limite máximo rígido, que nada tem a ver com a qualidade das suas regras.

Uma ligação de 1 Gbit/s aceita, com o menor tamanho de pacote possível, cerca de 1,49 milhões de pacotes por segundo, e fisicamente não passa mais do que isso. Para comparar, dois ataques medidos e filtrados em servidores da KernelHost: mais de 473,4 Gbit/s com mais de 41,5 milhões de pacotes por segundo contra um servidor de voz na 9987 UDP, e mais de 112,2 Gbit/s com mais de 8,7 milhões de pacotes por segundo contra um gameserver na 7777 UDP. O primeiro caso corresponde a cerca de 473 vezes a largura de banda e a cerca de 28 vezes a taxa de pacotes que uma linha de 1 Gbit/s consegue sequer aceitar. Nem sequer um filtro perfeito no servidor muda alguma coisa nisso, porque os pacotes já nem chegam até ele: a ligação à frente está cheia e, com ela, caem também os pacotes dos seus jogadores.

Há mais dois limites que atuam ainda mais cedo. Em primeiro lugar, o servidor de jogo lê a porta num único thread de execução. Uma enxurrada de query consegue ocupar esse thread ao ponto de os pacotes de sincronização dos jogadores reais expirarem no buffer de receção, muito antes de a linha ficar saturada. O processo não chega a ir abaixo, apenas fica lento, e os jogadores veem rubberbanding. Em segundo lugar, no UDP os endereços de origem são falsificáveis; nesse caso, os bloqueios por endereço atingem quem não tem nada a ver com o assunto e não atingem o atacante.

Em resumo e sem dramatismos: o seu trabalho no servidor decide se um ataque pequeno passa. Se um ataque grande passa, quem decide é a rede à frente do servidor.

O que a KernelHost lhe contrapõe

Incluído em todos os servidores: a proteção permanente em dois níveis

Todos os servidores da KernelHost estão por trás de uma filtragem em dois níveis, permanentemente ativa:

• Nível 1: rede global de scrubbing com 17 Tbps de capacidade de mitigação. Os ataques volumétricos são intercetados e limpos perto da sua origem, antes sequer de chegarem ao datacenter em Frankfurt am Main.
• Nível 2: filtragem Arbor em tempo real com 3,2 Tbps no próprio local, em Frankfurt am Main. Mesmo à frente do servidor são reconhecidos os padrões específicos de cada protocolo e descartados pacote a pacote.

Há três características decisivas. A proteção está permanentemente ativa, pelo que não existe uma fase de deteção durante a qual o seu servidor fique offline. Não é usado null-routing: o endereço atacado mantém-se na rede e só os pacotes nocivos são descartados, enquanto as ligações dos jogadores reais continuam a correr. E não custa nada a mais, porque está incluída em todos os pacotes de servidor, desde o servidor root KVM, passando pelo gameserver, até ao servidor dedicado. A filtragem acontece nas camadas 3, 4 e 7, em qualquer porta TCP ou UDP, portanto também na 7777 UDP. Tudo isto é operado no datacenter maincubes em Frankfurt am Main, na Alemanha, pela KernelHost GmbH, com sede em Viena, na Áustria. Que jogos e protocolos têm perfis próprios é o que mostra o artigo Proteção DDoS em tempo real para servidores de jogos.

Para projetos sob fogo permanente: Advanced DDoS Protection

Alguns projetos não são atingidos de forma ocasional, mas sim de forma dirigida e ao longo de semanas. Para esses casos existe a Advanced DDoS Protection a partir de 50,00 EUR por mês, PrePaid e sem prazo mínimo. Acrescenta três coisas à proteção permanente:

• Um IP de proteção dedicado a partir do núcleo de Frankfurt. O seu servidor é comutado para esse endereço dentro da rede da KernelHost, sem que tenha de alterar seja o que for do seu lado.
• Regras de proteção autogeríveis por porta e por protocolo na área de cliente. As alterações entram em vigor em tempo real, sem ticket e sem tempo de espera, pelo que pode afinar a meio de um ataque.
• Um perfil de proteção adequado ao jogo. Perfis prontos para mais de 40 jogos, serviços e protocolos, entre eles o SA-MP e o open.mp, além de aplicações TCP e UDP próprias. Também o painel de utilizadores, o servidor de voz e a VPN cabem por trás do mesmo endereço protegido.

Os dois níveis em comparação

Erros frequentes e as respetivas soluções

"O servidor desapareceu, logo é um ataque." Verifique primeiro se o processo ainda está a correr. Um erro de execução no gamemode tem, visto de fora, um aspeto idêntico. Com o crashdetect, a causa fica no log; sem ele, anda a adivinhar.

"Bloqueámos a porta de query." Não existe uma porta de query separada. Quem bloqueia a 7777 UDP bloqueia o funcionamento do jogo. O que se quer dizer é query 0 (e aí o servidor desaparece da lista) ou uma limitação de taxa na mesma porta.

"Mudámos de IP e voltámos a estar online." Sem fechar a fuga, o endereço novo volta a ser público em poucas horas. Registos DNS antigos, o painel na mesma máquina e a indicação de estado de um bot do Discord denunciam-no de forma fiável.

"Definimos um rate limit de 20 pacotes por segundo por endereço." É demasiado apertado. Já um único jogador fica acima disso, e vários jogadores atrás de um endereço NAT partilham a mesma quota. Com isso está a expulsar os seus próprios jogadores.

"Trancámo-nos fora do servidor com a firewall." Reiniciar não resolve, porque o UFW repõe as suas regras no arranque. Na KernelHost, abra a consola VNC na área de cliente e execute aí ufw disable. Nos servidores root KVM e nos servidores dedicados não existe IPMI nem iDRAC, o caminho passa pela consola VNC.

"A palavra-passe de RCON está no chat da equipa." O RCON corre em texto simples sobre UDP e é legível ao longo de todo o caminho. Se não precisar dele, desligue-o; caso contrário, vale a regra: palavra-passe longa e aleatória, e acesso apenas através de uma VPN.

"Esperamos simplesmente que o ataque passe." Os ataques que resultam repetem-se. Documente a hora, a duração, os valores de pico e as portas afetadas. São exatamente estes dados que um ticket de suporte também precisa, para que a filtragem seja afinada de forma dirigida.

Se estiver a ser atacado neste momento

Se o seu projeto já estiver alojado na KernelHost, a filtragem está permanentemente ativa e não tem de ligar nada. Se, ainda assim, notar anomalias, abra um ticket de suporte com o período de tempo, a porta e o comportamento observado, para que as regras sejam afinadas para o seu endereço. Durante um ataque em curso pode ainda falar connosco pelo chat de emergência do WhatsApp, através do +43 650 8209883.