Como proteger o seu servidor de RedM contra ataques DDoS
Comunidade menor significa que cada jogador perdido pesa mais. O que a hospedagem resolve, o que depende de você e como separar ataque de problema da máquina.
Servidor de RedM tem uma vulnerabilidade que não é técnica: a comunidade é pequena.
Numa cidade de FiveM, uma queda de meia hora custa jogadores que voltam depois, porque existe fluxo constante de gente nova procurando servidor. No RedM não. O público é concentrado, cada jogador demora mais para ser reposto, e uma noite fora do ar num evento pode custar semanas de crescimento.
Ou seja: aqui a proteção importa mais, não menos.
O que muda em relação ao FiveM
Tecnicamente, quase nada. O RedM roda no mesmo FXServer, usa as mesmas portas e o mesmo painel. Se você já configurou um servidor de FiveM, o procedimento é idêntico.
O que muda é o cálculo do prejuízo, e a chance de você estar sozinho na madrugada quando acontecer.
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 tráfego passa continuamente por filtragem, em vez de ser descartado quando o ataque começa.
A diferença é decisiva. Muita hospedagem responde com null-route, que descarta todo o tráfego do seu IP: o ataque para e o seu servidor também. Explicamos em proteção DDoS: o que é e por que importa.
Com isso, o ataque volumétrico deixa de ser problema seu. O resto é configuração.
A parte que depende de você
Só uma porta precisa estar aberta
| Porta | Protocolo | Para quê |
|---|---|---|
| 30120 | TCP e UDP | Conexão dos jogadores |
Se você definiu outra porta no server.cfg, é ela que entra no lugar. Nada
além disso precisa estar acessível para a internet.
Libere a porta, nunca o programa, e não abra faixas "por garantia". O passo a passo está em como abrir uma porta na sua VPS.
O txAdmin é a porta dos fundos
O painel roda na 40120 e dá controle total: console, reinício, arquivos, jogadores. Quem entra nele não precisa derrubar o servidor, ele simplesmente desliga.
Se você usa o painel só de dentro da VPS, pelo localhost, não abra nada. Se
acessa do seu computador:
- Senha longa e única
- Restrinja a porta 40120 ao seu IP, em vez de liberar para todos
- Feche quando parar de acessar de fora
Os detalhes estão em como iniciar o seu servidor pelo txAdmin.
O banco da VORP não vai para a internet
O MySQL que a VORP Core usa conversa com o servidor dentro da própria máquina. Não existe motivo para a porta 3306 estar aberta para fora.
Banco exposto recebe tentativa automatizada todos os dias, e quem entra copia ou apaga os personagens dos seus jogadores. Numa comunidade pequena, perder a progressão de todo mundo é o tipo de coisa que encerra o projeto.
Cuidado com o que vaza
- 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
Apague as chaves antes de mandar qualquer arquivo de configuração.
Backup fora da máquina
Backup no mesmo servidor cai junto com ele. Guarde em outro lugar e mantenha uma rotina, não uma cópia de meses atrás. O procedimento está em como fazer backup do banco de dados.
Nem toda queda é ataque
Antes de concluir DDoS, elimine o que é mais provável:
| Sintoma | Causa provável |
|---|---|
| Um resource da VORP crasha e o resto segue | Erro de script |
| Trava no pico, mas você acessa a VPS normal | Plano pequeno ou base pesada |
| Cai sempre no mesmo horário | Reinício agendado ou backup rodando |
| Servidor no ar e ninguém conecta | Porta fechada ou serviço parado |
| Ping alto para todos | Distância até o público |
| Cai do nada, com a máquina saudável | Aí sim, provavelmente ataque |
A checagem rápida: se você acessa a VPS normalmente, processador e memória estão tranquilos e mesmo assim ninguém conecta, o problema é rede. Se a máquina está sufocada, é dimensionamento, e o caminho está em como escolher a VPS para o seu servidor de RedM.
O que fazer quando acontecer
Não troque de IP no susto. Com mitigação inline é desnecessário, e trocar significa reconfigurar tudo e avisar uma comunidade inteira.
Abra um ticket com horário e sintoma. Quanto mais preciso, mais rápido o diagnóstico.
Comunique com sobriedade. Num público pequeno, todo mundo lê tudo. Avise que houve instabilidade, diga que está resolvido e siga. Detalhar o ataque só serve de incentivo para quem atacou.
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 acessível de fora | Você |
| Chaves vazadas em print ou arquivo | Você |
| Perda de dados | Você, com backup fora da máquina |
O restante 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 RedM da WyzeHost a proteção já vem inclusa em todos, com servidores no Brasil e suporte 24 horas.


