Como configurar proteção anti-DDoS na camada 4/7 no MU Online

Servidores de MU Online estão entre os alvos mais atacados do cenário de private servers. A combinação de concorrência acirrada, jogadores insatisfeitos e a facilidade de contratar ataques de negação de serviço por poucos reais faz do DDoS uma ameaça constante e não uma hipótese distante. Um ataque bem-sucedido derruba o servidor, expulsa os jogadores no momento mais crítico (um evento, um lançamento) e destrói a reputação construída em meses. Este tutorial avançado explica como montar uma defesa em profundidade que cobre tanto os ataques volumétricos de camada 4 quanto os ataques sofisticados de camada 7, sempre com exemplos que variam por provedor/versão.

A ideia central que você precisa internalizar é que não existe uma única solução mágica. Defesa anti-DDoS eficaz é feita em camadas, cada uma cobrindo um tipo de ataque que a outra não cobre. Proteger só o site e esquecer o ConnectServer, ou filtrar pacotes no Windows e deixar o link do datacenter saturar, são erros que deixam a porta aberta. Vamos construir a defesa de fora para dentro.

Pré-requisitos

Para acompanhar este guia você vai precisar de:

• Acesso administrativo ao servidor (Windows Server 2016/2019/2022) que roda o ConnectServer, GameServer e demais serviços do emulador.
• Acesso ao painel do seu provedor de hospedagem ou datacenter, para verificar se há mitigação de camada 4 inclusa ou contratável.
• Uma conta em um provedor de proteção (Cloudflare, ou um provedor de VPS com scrubbing anti-DDoS incluso). Os nomes e limites variam por provedor/versão.
• Conhecimento de quais portas seu emulador usa: tipicamente a porta do ConnectServer, a faixa de portas dos GameServers e a porta do servidor web. Os valores exatos variam por versão.
• Acesso ao DNS do seu domínio.
• Backup e um plano de rollback antes de aplicar regras de firewall, pois uma regra mal feita pode bloquear seus próprios jogadores.

Se o servidor ainda está em fase de montagem, siga primeiro o passo a passo de como criar servidor de MU Online e só depois blinde a infraestrutura com este guia.

Entendendo os dois tipos de ataque

Antes de defender, é preciso saber contra o que você luta. Os ataques se dividem em duas grandes famílias, nomeadas pelas camadas do modelo OSI.

Camada 4 (transporte) — ataques volumétricos. O objetivo é entupir o link de rede do servidor com um volume massivo de pacotes: SYN flood, UDP flood, amplificação DNS/NTP. O servidor nem chega a processar as requisições; o próprio cabo de rede satura. A defesa contra isso precisa acontecer antes de o tráfego chegar ao seu servidor, na rede do provedor (scrubbing).

Camada 7 (aplicação) — ataques de exaustão. Aqui o atacante envia requisições que parecem legítimas: floods de login no ConnectServer, tentativas repetidas de criação de conta, HTTP flood no site. O volume de banda é baixo, mas cada requisição consome CPU e banco de dados. São mais difíceis de distinguir de jogadores reais e exigem inteligência de aplicação para mitigar.

Os exemplos de vetores acima são representativos e a mistura usada em cada ataque varia.

Passo 1: esconder o IP real do servidor

Esta é a fundação de tudo. Se o IP real (de origem) do seu servidor vaza, qualquer proxy ou mitigação que você contratar se torna inútil, porque o atacante simplesmente envia o flood direto ao IP real, contornando toda a proteção. Portanto, o IP real nunca deve aparecer publicamente.

Fontes comuns de vazamento de IP que você precisa fechar:

1. Registros DNS antigos. Um registro A histórico apontando para o IP real fica indexado em serviços de histórico de DNS. Ao migrar para trás de um proxy, troque o IP real do servidor por um novo, pois o antigo já está queimado.
2. E-mail do próprio servidor. Se o site envia e-mails de recuperação de senha diretamente do IP do servidor, o cabeçalho do e-mail revela o IP. Use um serviço de e-mail externo (SMTP relay).
3. Subdomínios expostos. Um direct.seudominio.com ou ftp.seudominio.com apontando ao IP real entrega tudo. Audite todos os registros DNS.
4. O próprio arquivo do cliente. O ServerList ou .dat de conexão do cliente do jogo contém o endereço de destino. Se ele aponta para o IP real em vez do IP protegido, não adianta esconder no DNS. Aponte o cliente para o endereço protegido.

Depois de fechar os vazamentos, configure o firewall do servidor para aceitar tráfego de jogo apenas dos IPs do seu provedor de mitigação, recusando conexões diretas de qualquer outra origem. Isso garante que, mesmo que o IP vaze no futuro, o ataque direto seja recusado na borda.

Passo 2: mitigação de camada 4 (volumétrica)

A camada 4 não pode ser defendida dentro do seu servidor, porque quando o pacote chega ao Windows, o link já saturou. A mitigação precisa acontecer upstream, na rede que tem capacidade de absorver e limpar (scrubbing) o tráfego. Você tem três caminhos principais:

• Provedor de VPS/dedicado com anti-DDoS incluso. Diversos provedores oferecem proteção de camada 4 com capacidade de exemplo na casa de centenas de Gbps a alguns Tbps de absorção. É a opção mais simples: o scrubbing é transparente. Confirme os limites e se há custo por ataque.
• Túnel GRE / IP protegido. Alguns serviços fornecem um IP limpo que recebe o tráfego, filtra e encaminha o legítimo ao seu servidor por um túnel. Exige configuração de rede mais avançada.
• Cloudflare Spectrum ou equivalente para TCP. Para proteger o tráfego do jogo (TCP puro do ConnectServer e GameServer), um serviço de proxy TCP com anti-DDoS é necessário, já que o plano web comum só cobre HTTP/HTTPS.

O ponto inegociável: o tráfego do jogo (as portas do ConnectServer e dos GameServers) precisa estar coberto por mitigação de camada 4, não só o site. Muitos administradores protegem apenas o site com proxy e deixam a porta do jogo exposta, e é exatamente ali que o ataque entra.

Passo 3: endurecimento da pilha TCP no Windows Server

Mesmo com scrubbing upstream, endurecer o servidor adiciona uma camada de defesa contra o que passar pelo filtro e contra ataques menores. Alguns ajustes de registro e firewall ajudam. Estes são exemplos e os valores ideais variam por versão do Windows e carga.

:: Exemplo: habilitar proteção contra SYN flood (SynAttackProtect)
:: Ajuste via registro em HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
:: SynAttackProtect, TcpMaxHalfOpen, TcpMaxHalfOpenRetried
:: Os valores exatos variam por versao do Windows Server

No firewall do Windows, crie regras que:

1. Permitam tráfego de entrada apenas nas portas realmente usadas (ConnectServer, faixa de GameServers, web). Feche todo o resto.
2. Restrinjam as portas administrativas (RDP, SQL Server) a IPs específicos de administração, nunca abertas ao mundo. RDP aberto é vetor tanto de invasão quanto de ataque.
3. Limitem a taxa de novas conexões por IP quando o emulador ou um firewall de aplicação permitir.

# Exemplo: restringir RDP a um IP de administracao
New-NetFirewallRule -DisplayName "RDP Admin Only" -Direction Inbound `
  -Protocol TCP -LocalPort 3389 -RemoteAddress SEU_IP_ADMIN -Action Allow

Passo 4: defesa de camada 7 no ConnectServer e login

Os ataques de camada 7 no MU costumam mirar o ConnectServer com floods de conexão e a rotina de login/criação de conta, que tocam o banco de dados. Como o volume de banda é baixo, o scrubbing volumétrico não os detecta. A defesa aqui é inteligência de aplicação:

• Rate-limit por IP. Limite o número de tentativas de login e de novas conexões por IP em uma janela de tempo. Um jogador legítimo não tenta logar 200 vezes por minuto. O limite de exemplo varia por versão do emulador e ferramenta de firewall.
• CAPTCHA no cadastro e no login web. Impede a automação de criação de contas em massa que sobrecarrega o banco. Use uma solução de desafio moderna.
• Fila de conexão. Alguns emuladores ou proxies suportam uma fila que absorve picos de novas conexões sem derrubar o serviço.
• Bloqueio geográfico opcional. Se o servidor atende apenas o Brasil, restringir conexões a faixas de IP nacionais reduz drasticamente a superfície de ataque. Faça isso com cuidado para não bloquear jogadores legítimos com VPN.

Passo 5: proteção do site e da aplicação web

O site do servidor (registro, ranking, loja de VIP) é o alvo de camada 7 mais fácil e o mais visível. Coloque-o atrás de um proxy reverso com WAF (Web Application Firewall) e proteção DDoS de camada 7. Configurações essenciais:

• Modo "under attack" acionável. Um botão que, ao ser ativado durante um ataque, apresenta um desafio a cada visitante antes de liberar o acesso.
• Regras de rate-limit nos endpoints sensíveis: login, registro, recuperação de senha e endpoints de pagamento.
• Cache agressivo das páginas estáticas (ranking, notícias) para que um flood não chegue ao PHP e ao banco.
• Ocultar tecnologias. Remova cabeçalhos que revelam versões de servidor web e framework, que orientam o atacante.

Passo 6: monitoramento e resposta a incidentes

Defesa sem visibilidade é cega. Você precisa saber que está sob ataque antes que os jogadores reclamem. Monte um mínimo de observabilidade:

• Alertas de uso de banda e de CPU que disparam quando ultrapassam um limiar de exemplo.
• Monitor externo de disponibilidade (uptime) que testa o ConnectServer e o site a cada poucos minutos de fora da rede.
• Logs de conexão do ConnectServer para identificar padrões de flood e IPs recorrentes.
• Um runbook escrito: quem faz o quê quando o ataque começa (ativar modo under attack, acionar suporte do provedor de scrubbing, comunicar a comunidade).

A comunicação com a comunidade durante um ataque é subestimada. Um anúncio transparente ("estamos sob ataque, trabalhando na mitigação") preserva muito mais a confiança do que o silêncio.

Erros comuns e soluções

Checklist de lançamento

• IP real do servidor trocado e antigo descartado
• Todos os registros DNS auditados sem vazar o IP de origem
• E-mail transacional movido para SMTP relay externo
• Cliente do jogo apontando para o endereço protegido, não o IP real
• Firewall aceitando tráfego de jogo apenas dos IPs do provedor de mitigação
• Mitigação de camada 4 confirmada para as portas do jogo (não só o site)
• RDP e SQL Server restritos a IPs de administração
• Rate-limit de login/conexão configurado no ConnectServer
• CAPTCHA ativo no cadastro e login web
• Site atrás de WAF com modo "under attack" testado
• Cache das páginas estáticas do site ativo
• Alertas de banda e CPU configurados
• Monitor de uptime externo ativo no jogo e no site
• Runbook de resposta a incidente escrito e compartilhado com a equipe

Conclusão

Proteger um servidor de MU Online contra DDoS não é comprar um único serviço e esquecer. É construir defesa em profundidade: esconder o IP real, contratar mitigação volumétrica de camada 4 que cubra o tráfego do jogo, endurecer a pilha TCP do Windows, aplicar rate-limit e CAPTCHA contra os ataques de camada 7 e blindar o site com WAF. Cada camada cobre um flanco que a outra deixa aberto. O erro mais comum e mais fatal é proteger apenas o site e esquecer que a porta do ConnectServer é onde o ataque realmente dói. Com a arquitetura em camadas deste guia, calibrada aos limites do seu provedor (que variam por provedor/versão), seu servidor sobrevive aos ataques que derrubam a concorrência despreparada.

Perguntas frequentes