Como monitorar tentativas de invasão no seu servidor de MU Online

Servidores privados de MU Online com economia ativa — itens raros, moeda premium, rankings disputados — são alvos reais de tentativas de invasão, desde força bruta simples em contas de administrador até SQL injection em formulários do site e exploração de vulnerabilidades no painel de administração. Diferente de lag ou disco cheio, uma invasão bem-sucedida pode significar duplicação de itens, roubo de contas de jogadores ou até acesso total ao servidor. Este tutorial cobre como monitorar logs de acesso (SSH, painel web, MySQL), configurar defesas automáticas com fail2ban e firewall, identificar sinais de comprometimento e montar um plano de resposta a incidentes para agir rápido quando algo sai do padrão.

Por que servidores de MU Online são alvo

Um servidor privado popular movimenta uma economia real (venda de Zen, itens raros, VIP), o que atrai desde script kiddies testando exploits conhecidos de painéis genéricos até indivíduos com motivação direta de sabotar concorrência entre servidores. A superfície de ataque inclui o painel web (login de conta, loja, cadastro), o SSH/RDP de administração do servidor, e o próprio MySQL se exposto incorretamente à internet.

Superfícies de ataque mais comuns

Passo 1 — Fechar portas desnecessárias com firewall

Antes de monitorar, reduza a superfície de ataque. Exponha publicamente apenas as portas realmente necessárias (ConnectServer, painel web em HTTPS), e mantenha SSH e MySQL fechados ou restritos por IP.

# Exemplo com ufw
sudo ufw default deny incoming
sudo ufw allow 22/tcp   # restrinja por IP se possível
sudo ufw allow 443/tcp
sudo ufw allow 44405/tcp  # porta padrão do ConnectServer, ajuste conforme seu emulador
sudo ufw deny 3306/tcp  # MySQL nunca exposto publicamente
sudo ufw enable

Passo 2 — Instalar e configurar fail2ban contra força bruta

Fail2ban monitora logs de autenticação e bane automaticamente IPs após um número de tentativas falhas em um intervalo curto:

sudo apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 5
findtime = 600
bantime = 3600

[nginx-limit-req]
enabled = true

Para o painel web, crie um filtro customizado apontando para o log de tentativas de login falhas do seu sistema (Laravel, PHP puro, etc.), banindo IPs que excedem tentativas de login em minutos.

Passo 3 — Monitorar logs de SSH e do painel web

Revise regularmente (ou automatize com um script) os logs de autenticação em busca de padrões anômalos: muitas tentativas em curto espaço de tempo, tentativas em horários incomuns, ou tentativas vindas de países fora do público-alvo do servidor.

# Ver tentativas de login SSH falhas recentes
sudo grep "Failed password" /var/log/auth.log | tail -50

# Contar tentativas por IP
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head

Passo 4 — Proteger o painel web contra SQL injection

Confirme que todo o código do painel usa prepared statements/queries parametrizadas em vez de concatenação direta de string SQL — a causa mais comum de SQL injection em painéis de MU Online feitos sob medida. Revise especialmente os formulários de login, cadastro, recuperação de senha e loja, que são os alvos mais visados.

// Errado — vulnerável a SQL injection
$query = "SELECT * FROM MEMB_INFO WHERE memb___id = '$usuario'";

// Correto — prepared statement
$stmt = $pdo->prepare("SELECT * FROM MEMB_INFO WHERE memb___id = ?");
$stmt->execute([$usuario]);

Passo 5 — Restringir e auditar contas de GM

Contas de Game Master têm poder total sobre itens e personagens, o que as torna o alvo mais valioso de qualquer invasão. Use senhas fortes e únicas, autenticação de dois fatores no painel se disponível, e mantenha um log de auditoria de todas as ações de GM (criação de item, teleporte, ban) para detectar uso indevido rapidamente.

Passo 6 — Monitorar o MySQL contra acessos anômalos

Mesmo com o MySQL fechado à internet, monitore tentativas de conexão vindas de IPs internos incomuns e queries fora do padrão esperado (por exemplo, updates em massa na tabela de itens fora de um evento programado). Ative o log geral do MySQL temporariamente durante uma investigação, mas evite deixá-lo ligado permanentemente pelo impacto em performance e espaço em disco.

-- Ativar log geral temporariamente para investigação
SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/var/log/mysql/general.log';

Passo 7 — Identificar sinais de comprometimento já ocorrido

Alguns sinais indicam que uma invasão já aconteceu, mesmo sem alerta em tempo real: contas de GM criadas sem registro da equipe, Zen ou itens raros duplicados em contas específicas sem log de evento correspondente, processos desconhecidos consumindo CPU no servidor, e entradas de acesso SSH em horários fora do padrão da equipe.

Passo 8 — Montar um plano de resposta a incidentes

Tenha um plano documentado antes que a invasão aconteça, não durante o pânico. No mínimo, defina: quem tem autoridade para isolar o servidor da rede, como preservar logs antes de qualquer reinicialização, e como comunicar a comunidade com transparência sem expor detalhes que ajudem o invasor.

1. Isolar o servidor da rede (ou bloquear o IP de origem no firewall).
2. Preservar logs atuais copiando-os antes de qualquer reinicialização.
3. Trocar todas as credenciais de administração (SSH, MySQL, painel, GM).
4. Investigar a extensão do dano (itens duplicados, contas afetadas).
5. Restaurar de backup íntegro anterior à invasão, se necessário.
6. Comunicar a comunidade com transparência sobre o ocorrido e as correções aplicadas.

Erros comuns e soluções

Checklist de segurança e monitoramento de invasão

• Firewall configurado, expondo só as portas necessárias.
• Fail2ban ativo para SSH e painel web.
• Painel web revisado contra SQL injection (prepared statements).
• Contas de GM com senha forte, 2FA e log de auditoria.
• MySQL nunca exposto diretamente à internet.
• Sinais de comprometimento revisados periodicamente.
• Plano de resposta a incidentes documentado e conhecido pela equipe.

Com as defesas básicas monitoradas e ativas, o próximo passo é integrar esses alertas de segurança ao mesmo painel onde você acompanha CPU, disco e jogadores online, para ter uma visão única da saúde do servidor — revise o tutorial de criação de servidor de MU Online para garantir que a base de infraestrutura já nasce com essas proteções em mente.

Perguntas frequentes