Proteger o servidor FiveM contra ataques DDoS

Um servidor de roleplay em FiveM que desaparece durante alguns minutos, sempre à noite, raramente tem um problema de hardware. Na maioria dos casos está a decorrer um ataque, e precisamente à hora em que há mais jogadores online. 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 FXServer 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 (ver a secção "Registar em log"), porque depois do ataque desaparecem.

Porque é que são precisamente os servidores FiveM a ser atacados com tanta frequência

Os projetos de FiveM reúnem várias características que fazem deles um alvo cómodo. Em primeiro lugar, um servidor de RP publica o seu endereço por iniciativa própria: a entrada na lista de servidores da Cfx.re contém o endereço IP e a porta em texto simples, porque de outra forma os jogadores não encontrariam o servidor. Em segundo lugar, a comunidade de jogadores está presa a horários fixos, 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 que o tráfego de jogo corre sobre UDP. 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. O que é exatamente um ataque DDoS fica explicado no artigo O que é um ataque DDoS?.

As portas que realmente contam

Por predefinição, um FXServer liga-se a uma única porta, e nos dois protocolos. No server.cfg:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

Estas duas linhas são toda a superfície de ataque do próprio jogo:

• 30120 UDP transporta o tráfego de jogo em curso: dados de posição, sincronização, transmissão de voz.
• 30120 TCP transporta o estabelecimento da ligação e os endpoints HTTP integrados do FXServer: /info.json, /players.json e /dynamic.json.
• 40120 TCP é a predefinição para a interface web do txAdmin.
• 3306 TCP pertence à base de dados de que precisa qualquer framework ESX ou QBCore.
• 22 TCP é o seu acesso SSH.

Destas cinco portas, exatamente duas pertencem à rede aberta. As outras três são o erro evitável mais frequente em servidores FiveM.

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

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

1. Levantamento: o que é 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:30120 e [::]:30120 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 txAdmin, o MariaDB, um servidor web e um serviço de voz há muito esquecido. A perspetiva do atacante obtém-se com um scan de portas a partir de fora:

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

2. Deixar aberto apenas o que o jogo precisa mesmo

Para o FiveM bastam duas aberturas 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 30120/tcp comment 'FiveM'
ufw allow 30120/udp comment 'FiveM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
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. Numa ligação com endereço IP variável isso é pouco prático, e a melhor solução está mais abaixo. 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. Verifique em /etc/mysql/mariadb.conf.d/50-server.cnf que ali consta:

bind-address = 127.0.0.1

3. Proteger a porta de query e os endpoints HTTP

Na parte TCP da 30120, o FXServer responde a pedidos HTTP sem que ninguém tenha de abrir o jogo. Veja o que ele entrega ali:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600

O /players.json lista os jogadores ligados juntamente com os respetivos identificadores. Isso é prático para páginas de estado e para bots do Discord, mas é também um convite: o endpoint pode ser consultado as vezes que se quiser, cada consulta custa trabalho ao seu servidor e o conteúdo revela a um atacante quando é que vale a pena atacar. Duas contramedidas não custam nada. Primeiro, os endpoints dos jogadores não pertencem à resposta, e para isso basta uma linha no server.cfg:

sv_endpointPrivacy true

Segundo: se o seu bot do Discord ou o seu site mostrar o número de jogadores, não consulte o endpoint a partir do visitante, guarde antes o resultado em cache a intervalos fixos. Assim, uma página de estado muito visitada gera uma consulta por intervalo em vez de uma por visitante.

4. Não colocar o txAdmin na rede aberta

A porta 40120 é uma interface web com acesso total ao seu servidor. Sem um endereço IP fixo para a regra de abertura, mantenha a porta fechada para o exterior e chegue até ela através de um túnel SSH; depois abra localmente http://127.0.0.1:40120:

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

5. Limitar as taxas de ligações e de pacotes

Contra ataques pequenos e bots mal feitos ajuda um limite máximo por endereço de origem:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 12 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name fivem_udp --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

A primeira regra descarta novas ligações TCP assim que um endereço tenha mais de doze abertas em simultâneo; a segunda descarta pacotes UDP a partir de mais de 600 pacotes por segundo, de forma continuada, vindos da mesma origem. Os dois números são valores de partida, não verdades absolutas: um servidor de RP cheio gera bastante mais pacotes do que um vazio, 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

E 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: 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

6. A entrada na lista de servidores

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. Quem não precisa da entrada pública, porque o projeto funciona apenas por Discord e por ligação direta, pode desligá-la com sv_master1 "". Isso custa, no entanto, toda a visibilidade junto de novos jogadores e só ajuda contra o mais preguiçoso dos atacantes.

Mais eficazes são dois hábitos. Não publique o endereço IP em bruto em lado nenhum, ou seja, nem no canal de Discord nem na página do projeto. 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, são os registos DNS antigos: um registo A esquecido a apontar para o endereço anterior torna qualquer mudança inútil.

7. Whitelist e verificação na entrada

Uma whitelist funciona contra tudo o que usa o caminho normal de entrada: trolls, clientes de cheats, botnets feitas de contas descartáveis. É implementada do lado do servidor no evento playerConnecting, onde suspende a ligação com as funções de deferrals, verifica o identificador e só depois deixa entrar. A isto juntam-se uma verificação de conta rigorosa, um limite de jogadores realista e o ScriptHook desativado:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 48
sv_scriptHookAllowed 0

Defina uma palavra-passe de RCON apenas se precisar mesmo de RCON, porque esse acesso fica na mesma porta aberta. E uma coisa tem de ficar clara: uma whitelist protege a 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.

8. Validar os eventos de rede do lado do servidor

Muitas falhas comunicadas como ataque DDoS resultam de um único script. Os recursos do FiveM comunicam através de eventos de rede, e um evento que o servidor executa sem verificação é uma porta aberta: quem dispare no cliente um TriggerServerEvent com valores arbitrários pode criar dinheiro, fazer aparecer veículos ou lançar consultas à base de dados em ciclo até o servidor parar.

Três regras travam a maior parte disso. Registe com RegisterNetEvent apenas os eventos que devem mesmo vir do cliente. Nunca confie nos valores que o cliente envia, determine antes o jogador do lado do servidor a partir de source. E limite quantas vezes um jogador pode disparar o mesmo evento, sobretudo em tudo o que envolva uma consulta à base de dados. Se o servidor engasga enquanto a linha está calma, o resmon 1 na consola do cliente mostra o tempo de processamento por recurso, e normalmente o culpado está logo no topo.

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 terça-feira à noite. Com apt-get install -y vnstat sysstat, a medição fica sempre a correr. Durante um incidente bastam quatro comandos: taxas de pacotes por segundo, taxa de descarte da interface, mensagens do kernel e uma amostra curta do tráfego.

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 port 30120 -c 200 -q

Quanto ao tcpdump vale a regra: limitar sempre com -c, porque uma captura a plena carga sobrecarrega ainda mais um servidor que já está sobrecarregado. Como interpretar os valores está em Detetar um ataque DDoS.

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. Os ataques contra projetos de FiveM situam-se habitualmente entre 5 e 50 Gbit/s, ou seja, entre cinco e cinquenta vezes a sua linha. Nessa altura já não interessa se a sua regra de iptables por trás é boa, porque os pacotes dos seus jogadores nem chegam a passar.

A segunda grandeza é a taxa de pacotes, e muitas vezes ela chega 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 ataque que nem sequer enche um terço da sua linha pode, ainda assim, deixar o seu servidor inoperacional, porque o tempo de processamento se gasta a descartar. Quem opera servidores vive isto como "a utilização nem sequer estava alta e mesmo assim desapareceu tudo".

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. O datacenter é o maincubes em Frankfurt am Main, na Alemanha. Que jogos e protocolos estão cobertos é o que lista Proteção DDoS em tempo real para servidores de jogos.

Advanced DDoS Protection para projetos sob fogo permanente

Alguns projetos não são atacados de forma ocasional, mas sim de forma dirigida e ao longo de semanas. Para esses existe a Advanced DDoS Protection a partir de 50,00 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 30120 UDP e o que é permitido na 30120 TCP, sem ter de escrever um ticket para isso.
• 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. Para o FiveM existe um perfil pronto a usar, 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 FiveM, 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 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 ou de um registo DNS antigo. Mudar de endereço é ganhar tempo, não é uma solução.

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

"O servidor está a funcionar, mas todos os jogadores têm efeito de elástico": isso é mais vezes um script do que um ataque. Veja primeiro com o resmon 1 se algum recurso está a devorar o tempo de processamento. Se o sar -n DEV 1 10 não mostrar nada de especial, não foi um ataque DDoS.

"O txAdmin mostra centenas de tentativas de ligação falhadas": isso é um flood de entradas e atinge a lógica de jogo, não a linha. Contra isso resultam a whitelist, a verificação de conta e o limite de ligações por endereço de origem.

"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

Feche tudo exceto a 30120 TCP e UDP, mantenha o txAdmin e a base de dados fora da rede aberta, limite as ligações e as taxas de pacotes por endereço de origem, mantenha uma whitelist e valide os eventos de rede do lado do servidor. Assim fica preparado contra tudo o que dispense largura de banda digna de nota. Para além disso, quem decide é exclusivamente a rede à frente do servidor.

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.