Plano de Resposta a DDoS em Camadas para Servidores de MU Online

Um ataque de negação de serviço distribuído (DDoS) é, para a maioria dos administradores de servidor de MU Online, uma questão de quando, não de se. A competição entre projetos, desavenças com jogadores banidos e até ataques por diversão fazem das portas do GameServer e ConnectServer alvos frequentes. A diferença entre um servidor que sobrevive a esses ataques com credibilidade intacta e um que perde sua base de jogadores está em ter um plano de resposta em camadas preparado antes do incidente, não improvisado durante ele. Este tutorial apresenta um plano estruturado em cinco camadas de defesa, os papéis de cada pessoa da equipe durante o ataque, e os passos de comunicação com a comunidade — tudo pensado para a realidade de servidores privados de médio porte.

Por que servidores de MU são alvos frequentes

MU Online privado tem uma dinâmica competitiva incomum: servidores concorrem diretamente pela mesma base de jogadores, e rankings de população movem receita de doação. Isso cria incentivo real para sabotagem. Além disso, jogadores banidos por cheat ou por comportamento tóxico frequentemente têm conhecimento técnico suficiente para contratar "boosters" (serviços de stress/DDoS) baratos disponíveis publicamente. Eventos de lançamento, resets de temporada e fins de semana com eventos pagos são os momentos de maior risco, porque é quando o prejuízo de um ataque é maximizado.

As cinco camadas de defesa

A ideia central de um plano "em camadas" é que nenhuma camada sozinha resolve tudo — cada uma cobre um tipo de ataque diferente e reduz a superfície que chega à camada seguinte.

Camada 1 — Proteção na borda de rede (upstream)

Esta é a defesa contra ataques volumétricos (centenas de Mbps a vários Gbps), que sozinho seu servidor nunca vai conseguir absorver, independente de firewall local. A solução é contratar hospedagem com anti-DDoS incluso na camada de rede — provedores como OVH (com o "Game" anti-DDoS), Voxility ou serviços de scrubbing dedicados a jogos. A configuração típica envolve anunciar seu IP via BGP através do provedor de proteção, que filtra o tráfego malicioso antes de rotear o tráfego limpo até seu servidor real.

Um erro comum é achar que um VPS genérico de nuvem (sem anti-DDoS de jogo) resolve o problema só porque tem "proteção DDoS básica" — essa proteção geralmente cobre HTTP/HTTPS, não o tráfego de jogo em portas customizadas como 44405 (ConnectServer) ou 55901+ (GameServer).

Camada 2 — Proxy de jogo dedicado

Entre a internet e seu GameServer real, coloque um proxy que absorve e filtra conexões antes de repassar ao servidor de jogo. Isso esconde o IP real do seu servidor (dificultando ataques direcionados) e permite terminar conexões suspeitas sem sobrecarregar o processo do emulador. Uma configuração comum usa iptables com um IP reverse-proxy em uma VPS barata só para essa função, redirecionando com DNAT:

# Exemplo simplificado de DNAT para redirecionar tráfego do proxy ao servidor real
iptables -t nat -A PREROUTING -p tcp --dport 44405 -j DNAT --to-destination 10.0.0.5:44405
iptables -t nat -A POSTROUTING -j MASQUERADE

Se o proxy cair sob ataque, você troca o IP público e atualiza o DNS/launcher rapidamente — o servidor real nunca fica exposto diretamente.

Camada 3 — Firewall local e limitação de conexões

Mesmo com proteção upstream, configure limites locais para conter ataques de menor escala (flood de conexão, tentativas de login em massa). Um exemplo de regra com iptables limitando novas conexões por IP na porta do ConnectServer:

iptables -A INPUT -p tcp --dport 44405 -m connlimit --connlimit-above 10 -j DROP
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 5 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Complemente com fail2ban monitorando os logs do ConnectServer para banir IPs que tentam autenticação repetida em curto intervalo — um padrão comum tanto de bot de conta quanto de teste de flood.

Camada 4 — Ajustes na aplicação (emulador)

A maioria dos emuladores (IGCN, MuEMU, X-Team) tem parâmetros de limite de pacotes por segundo e de conexões simultâneas por IP no ConnectServer. Ative-os mesmo que o padrão pareça suficiente — em ataque real, o volume de conexões falsas pode saturar o processo antes que o firewall reaja. Configure também um limite de tentativas de login por IP por minuto, para impedir que um ataque de flood de autenticação derrube o banco de dados de contas.

Papéis da equipe durante o incidente

Um ataque real dura de minutos a dias — ter papéis definidos evita decisões de pânico.

Playbook de ativação passo a passo

1. Detectar: monitoramento acusa pico de banda/conexões incomum (idealmente com alerta automático via Zabbix, Grafana ou script simples de threshold).
2. Confirmar: diferenciar DDoS real de pico legítimo de jogadores (ex.: lançamento com fila grande) checando IPs de origem e padrão de tráfego.
3. Isolar: se o proxy de jogo (camada 2) estiver ativo, trocar o IP público exposto e atualizar o launcher/DNS.
4. Escalar: abrir chamado com o provedor de anti-DDoS informando IP atacado e assinatura do ataque, se identificável.
5. Comunicar: publicar no canal de status a primeira mensagem em até 10 minutos do início percebido.
6. Mitigar localmente: aplicar regras temporárias de firewall mais agressivas (camada 3) enquanto a mitigação upstream se estabiliza.
7. Monitorar recuperação: confirmar queda do tráfego malicioso antes de reabrir totalmente o acesso.
8. Registrar: documentar duração, vetor de ataque e ações tomadas para o post-mortem.

Métricas para monitorar continuamente

Comunicação com a comunidade durante o ataque

Nunca deixe o silêncio ser a mensagem padrão. Jogadores toleram instabilidade técnica muito melhor do que a sensação de abandono. Tenha um canal de status fora da infraestrutura potencialmente atacada — um Discord webhook publicando em canal fixo, ou uma página de status em serviço externo (ex.: um status.io ou uma página estática hospedada em outro provedor). Publique atualizações regulares mesmo sem novidade concreta: "ataque em mitigação, provedor acionado, sem previsão exata" já reduz a ansiedade e evita boatos de "servidor fechou".

Plano de compensação pós-incidente

Para servidores com sistema de VIP ou pacotes pagos, defina previamente a política de compensação — isso evita decisões improvisadas sob pressão de jogadores insatisfeitos. Uma régua comum:

Post-mortem e prevenção de recorrência

Depois de cada incidente relevante, produza um resumo curto (mesmo que interno) com: horário de início/fim, vetor identificado, camadas que funcionaram, camadas que falharam e ações de melhoria. Servidores que sofrem ataques recorrentes do mesmo agente devem considerar medidas adicionais como whitelisting geográfico temporário ou parceria com um provedor de anti-DDoS mais robusto — o custo de upgrade costuma ser menor que o de outro incidente prolongado.

Erros comuns e soluções

Checklist de preparação para resposta a DDoS

• Contrato de anti-DDoS de camada de rede específico para jogos ativo.
• Proxy de jogo dedicado configurado e testado.
• Regras de firewall local (connlimit, rate limit) aplicadas nas portas críticas.
• Limites de conexão/login configurados no ConnectServer.
• Papéis da equipe definidos e documentados.
• Canal de status externo à infraestrutura principal criado.
• Política de compensação pós-incidente definida antes do primeiro ataque.
• Processo de post-mortem documentado para cada incidente relevante.

Com o plano em camadas montado, o próximo passo é revisar a resiliência geral da sua infraestrutura — incluindo backups e failover — para que um ataque não seja o único cenário de risco coberto. Confira também o tutorial de criação de servidor de MU Online para revisar a base de infraestrutura sobre a qual esse plano de resposta deve ser construído.

Perguntas frequentes