Como recuperar um servidor de MU Online após uma invasão (hack)

Uma invasão bem-sucedida é o pior dia na vida de um administrador de servidor de MU Online — itens duplicados, contas roubadas, banco de dados corrompido ou, no pior caso, dados de jogadores vazados. O que diferencia um incidente administrado de um desastre permanente é a velocidade e a ordem das ações nas primeiras horas. Este tutorial apresenta um plano de resposta a incidente adaptado à realidade de servidores privados, cobrindo contenção, diagnóstico, restauração e comunicação.

Reconhecendo os sinais de uma invasão

Antes de agir, confirme que realmente há uma invasão e não um bug ou pico de tráfego legítimo. Sinais típicos incluem: quantidade anormal de Zen ou itens raros aparecendo do nada, logins administrativos em horários e IPs incomuns, contas de jogadores sendo esvaziadas em sequência, o painel web ou GameServer respondendo de forma anômala, ou alertas de ferramentas de monitoramento (CPU/banco disparados sem motivo aparente).

Passo 1 — Conter o ataque imediatamente

A prioridade zero é parar o dano em andamento, não investigar a causa. Isso geralmente significa:

1. Colocar o GameServer e o ConnectServer offline imediatamente.
2. Bloquear o acesso externo ao painel administrativo web.
3. Se possível, isolar o banco de dados da rede externa (regra de firewall temporária).
4. Revogar tokens/sessões ativas de administradores no painel.

Não pule esse passo para "investigar primeiro" — cada minuto online com o atacante ativo é dano adicional.

Passo 2 — Preservar evidências antes de qualquer limpeza

Antes de restaurar qualquer coisa, copie os logs relevantes para um local seguro fora do servidor comprometido: logs do GameServer, logs do MySQL (general_log, slow_query_log se ativos), logs de acesso do painel web (Apache/Nginx) e logs do sistema operacional (auth.log/eventos de login). Esses arquivos são a única forma de identificar o vetor de ataque depois.

mkdir -p /root/incidente_2026-03-14
cp /var/log/mysql/*.log /root/incidente_2026-03-14/
cp /var/log/nginx/access.log /root/incidente_2026-03-14/
cp -r /path/to/gameserver/logs /root/incidente_2026-03-14/

Passo 3 — Identificar o vetor de ataque

Com os logs preservados, cruze horários. Os vetores mais comuns em servidores de MU privado são:

Passo 4 — Avaliar a extensão do dano

Antes de restaurar, entenda o escopo: quantas contas foram afetadas, quais itens/Zen foram duplicados ou roubados, se houve exclusão de tabelas, e se dados sensíveis (e-mails, hashes de senha) foram exfiltrados. Uma query simples ajuda a mapear atividade anômala por horário:

SELECT memb___id, appl_date, appl_ip
FROM MEMB_INFO
WHERE appl_date BETWEEN '2026-03-14 18:00:00' AND '2026-03-14 23:00:00'
ORDER BY appl_date;

Passo 5 — Restaurar a partir de backup limpo

Identifique o backup mais recente anterior ao início confirmado do ataque — não ao momento em que você percebeu, que geralmente é depois do início real. Restaure o banco de dados nesse ponto e reaplique, se possível e seguro, apenas as transações legítimas identificadas manualmente entre o backup e o incidente (compras confirmadas, progresso validado). Nunca restaure sobre o mesmo servidor comprometido sem antes reinstalar o sistema operacional ou, no mínimo, revisar todos os binários e configurações quanto a backdoors.

Passo 6 — Resetar credenciais em massa

Depois da restauração, resete: senha de todos os administradores e GMs, senha de acesso ao banco de dados (MySQL root e usuários de aplicação), chaves de API do painel web, e force reset de senha para jogadores se houver qualquer indício de exfiltração de hashes. Comunique o reset forçado de senha de jogadores com antecedência e instruções claras de como redefinir.

Passo 7 — Corrigir a causa raiz antes de reabrir

Reabrir o servidor sem corrigir a vulnerabilidade identificada é o erro mais recorrente pós-incidente — o mesmo atacante volta em dias. Dependendo do vetor:

• SQL Injection: aplique prepared statements no painel, atualize ou substitua o CMS vulnerável.
• Credencial vazada: ative 2FA para administradores, revise política de senha forte.
• Exploit do emulador: aplique patch da comunidade ou atualize para versão corrigida.
• RDP/SSH fraco: troque para autenticação por chave, restrinja por IP/VPN, mude a porta padrão.

Passo 8 — Comunicar a comunidade com transparência

Publique um comunicado claro no site e Discord explicando o que aconteceu (sem detalhes técnicos exploráveis), o que foi feito para conter, o impacto para os jogadores (reset de senha, reversão de itens duplicados) e o prazo estimado de retorno. Transparência controlada preserva a confiança da comunidade; silêncio ou minimização gera desconfiança e êxodo de jogadores.

Prevenção contínua pós-incidente

Erros comuns e soluções

Checklist de recuperação pós-invasão

• Servidor colocado offline imediatamente após detecção.
• Logs preservados antes de qualquer limpeza.
• Vetor de ataque identificado com evidências.
• Extensão do dano mapeada (contas, itens, dados).
• Backup limpo restaurado em ambiente revisado.
• Credenciais de admin, banco e painel resetadas.
• Causa raiz corrigida antes de reabrir ao público.
• Comunicado transparente publicado para a comunidade.

Depois de recuperar o servidor, revisite os fundamentos de configuração segura desde a origem para reduzir a chance de um novo incidente — o tutorial de criação de servidor de MU Online é um bom ponto de partida para reforçar a base antes de reabrir ao público.

Perguntas frequentes