Como proteger o seu servidor de FiveM contra ataques DDoS
A mitigação de rede já vem inclusa, mas metade da proteção depende da sua máquina. As portas a fechar, o txAdmin a esconder e como saber se a queda foi ataque.
A cidade cai no dia do lançamento. Some no meio de um evento. Volta sozinha vinte minutos depois. A conclusão automática é sempre a mesma: fui atacado.
Às vezes foi. Muitas vezes não. E nos dois casos existe uma parte da proteção que a hospedagem entrega e outra que depende de como a sua máquina está configurada.
Este guia cobre as duas.
Por que cidade de FiveM é alvo
Não é preciso ser grande para apanhar. O cenário tem três características que fazem disso rotina:
Concorrência direta. Dezenas de cidades disputam o mesmo público. Derrubar o concorrente no dia do lançamento é uma tática que, infelizmente, alguém sempre usa.
Momentos previsíveis. Inauguração, wipe, evento anunciado, gravação de streamer. O atacante sabe exatamente quando o estrago é maior.
Jogador banido com rancor. É o caso mais comum de todos, e o mais barato de executar.
Some a isso que contratar um ataque virou coisa de poucos reais, e fica claro por que cidade pequena também é alvo.
A parte que já está resolvida
Na WyzeHost a proteção DDoS vem inclusa em todos os planos, sem custo extra e sem configuração da sua parte. O IP nasce protegido, com o tráfego passando continuamente por filtragem em vez de ser descartado quando o ataque começa.
Essa diferença decide tudo. Muita hospedagem reage com null-route: joga fora todo o tráfego do seu IP, o legítimo junto com o malicioso. O ataque para e a sua cidade também, que é exatamente o que o atacante queria. Explicamos em proteção DDoS: o que é e por que importa.
Com mitigação inline, o ataque volumétrico deixa de ser problema seu. Mas ele é só um dos vetores.
A parte que depende de você
Proteção de rede cuida do tráfego que tenta entupir a banda. Ela não fecha porta aberta, não cria senha forte e não esconde o seu painel. Essa metade é configuração da sua máquina.
Feche tudo que não precisa estar aberto
Uma cidade de FiveM precisa de uma porta, em dois protocolos:
| Porta | Protocolo | Para quê |
|---|---|---|
| 30120 | TCP e UDP | Conexão dos jogadores |
É só isso. Se você usa outra porta no server.cfg, é essa que vai no lugar.
O erro comum é liberar o programa em vez da porta, ou abrir faixas inteiras "por garantia". Cada porta aberta a mais é superfície de sondagem sem contrapartida. O passo a passo da regra correta está em como abrir uma porta na sua VPS.
Cuidado com o txAdmin
Esse é o ponto mais negligenciado do FiveM.
O txAdmin roda na porta 40120 e dá controle total do servidor: console,
reinício, arquivos, jogadores. Se você o usa apenas de dentro da VPS, pelo
localhost, não precisa abrir nada.
Se você acessa do seu computador, a porta 40120 fica exposta para a internet inteira. Nesse caso:
- Senha longa e única, nunca repetida de outro serviço
- Restrinja a porta ao seu IP no firewall, em vez de liberar para todos
- Feche a porta quando parar de acessar de fora
Os detalhes do painel estão em como iniciar o seu servidor pelo txAdmin.
Nunca exponha o banco de dados
O MySQL da sua base, na porta 3306, não tem motivo nenhum para estar acessível pela internet. Ele conversa com o servidor dentro da própria máquina.
Banco exposto recebe tentativa de login automatizada todos os dias, e quem entra não precisa derrubar nada: ele copia, apaga ou vende os personagens dos seus jogadores. É bem pior que uma hora offline.
Divulgue endereço, não IP
Esse ponto é específico do FiveM e vale ouro.
Se você divulga connect mais um IP, qualquer mudança de máquina significa
perder todo mundo que salvou o endereço antigo. Se você divulga um endereço
próprio, tipo seuservidor.fivembr.com, a troca é invisível para o jogador.
O passo a passo está em como redirecionar o seu domínio para o servidor, e o recurso já vem incluso nos planos.
Cuidado com o que vaza sem você perceber
Você não esconde o IP do servidor, mas consegue evitar entregar o resto:
- Print do txAdmin com endereço e usuário visíveis
- Vídeo gravado com a área de trabalho da VPS aberta
server.cfgenviado no Discord "para alguém ajudar", com a license key e a steam_webApiKey dentro
Antes de mandar um arquivo de configuração, apague as chaves. Antes de postar um print, olhe a barra de título.
Backup fora da máquina
Backup não impede ataque, mas separa um susto de um projeto encerrado. Backup que mora no mesmo servidor cai junto com ele. Veja como fazer backup do banco de dados.
Nem toda queda é ataque
Antes de concluir que foi DDoS, elimine as causas mais comuns:
| Sintoma | Causa provável |
|---|---|
| Cidade trava no pico, mas você acessa a VPS normal | Base pesada ou plano pequeno |
| Um resource crasha e o resto segue | Erro de script |
| Jogadores demoram para entrar, mas quem está dentro joga bem | Download de arquivos, não ataque |
| Cai sempre no mesmo horário | Reinício agendado ou backup rodando |
| Ping alto para todos, o dia inteiro | Distância até o público |
| Servidor no ar e ninguém conecta | Porta fechada ou serviço parado |
| Cai do nada, com a máquina saudável | Aí sim, provavelmente ataque |
A checagem rápida: se você consegue acessar a VPS normalmente, o processador e a memória estão tranquilos e mesmo assim ninguém conecta, o problema é rede. Se a máquina está sufocada, o problema é a base ou o plano, e o diagnóstico está em como saber se a sua base precisa de otimização.
E se a reclamação for demora para entrar, e não travada dentro do jogo, isso nunca foi ataque: é a entrega dos seus mods, resolvida pelo cache externo.
O que fazer quando acontecer
Não troque de IP no susto. Com mitigação inline isso é desnecessário, e você ainda perde quem salvou o endereço antigo.
Abra um ticket com horário e sintoma. A que horas começou, se você conseguia acessar a máquina, se todos caíram ou só alguns.
Não anuncie o ataque em detalhes. Confirmar publicamente que funcionou é o incentivo que quem atacou está esperando. Avise que houve instabilidade e siga.
Depois que passar, revise a lista acima. Ataque costuma ser o momento em que as pessoas descobrem que estavam com o txAdmin aberto para o mundo.
Resumindo quem cuida do quê
| Camada | Quem resolve |
|---|---|
| Ataque volumétrico contra a rede | A hospedagem, com mitigação inclusa |
| Portas abertas sem necessidade | Você, no firewall |
| txAdmin exposto na 40120 | Você, restringindo por IP |
| Banco de dados acessível de fora | Você |
| Chaves vazadas em print ou arquivo | Você |
| Perda de dados | Você, com backup fora da máquina |
As duas metades se somam. A melhor mitigação do mundo não protege um txAdmin com senha fraca.
O resto das práticas está em como manter a segurança da sua VPS, e os detalhes da nossa estrutura na página de proteção DDoS.
Nos planos de FiveM da WyzeHost a proteção vem inclusa em todos, com servidores no Brasil, cache externo e endereço personalizado.
