Cómo monitorear intentos de invasión en tu servidor de MU Online

Los servidores privados de MU Online con economía activa — ítems raros, moneda premium, rankings disputados — son objetivos reales de intentos de invasión, desde fuerza bruta simple en cuentas de administrador hasta SQL injection en formularios del sitio y explotación de vulnerabilidades en el panel de administración. A diferencia del lag o el disco lleno, una invasión exitosa puede significar duplicación de ítems, robo de cuentas de jugadores o incluso acceso total al servidor. Este tutorial cubre cómo monitorear logs de acceso (SSH, panel web, MySQL), configurar defensas automáticas con fail2ban y firewall, identificar señales de compromiso y armar un plan de respuesta a incidentes para actuar rápido cuando algo se sale de lo normal.

Por qué los servidores de MU Online son un objetivo

Un servidor privado popular mueve una economía real (venta de Zen, ítems raros, VIP), lo que atrae desde script kiddies probando exploits conocidos de paneles genéricos hasta individuos con motivación directa de sabotear a la competencia entre servidores. La superficie de ataque incluye el panel web (login de cuenta, tienda, registro), el SSH/RDP de administración del servidor, y el propio MySQL si está expuesto incorrectamente a internet.

Superficies de ataque más comunes

Paso 1 — Cerrar puertos innecesarios con firewall

Antes de monitorear, reduce la superficie de ataque. Expón públicamente solo los puertos realmente necesarios (ConnectServer, panel web en HTTPS), y mantén SSH y MySQL cerrados o restringidos por IP.

# Ejemplo con ufw
sudo ufw default deny incoming
sudo ufw allow 22/tcp   # restringe por IP si es posible
sudo ufw allow 443/tcp
sudo ufw allow 44405/tcp  # puerto estándar del ConnectServer, ajusta según tu emulador
sudo ufw deny 3306/tcp  # MySQL nunca expuesto públicamente
sudo ufw enable

Paso 2 — Instalar y configurar fail2ban contra fuerza bruta

Fail2ban monitorea logs de autenticación y banea automáticamente IPs tras un número de intentos fallidos en un intervalo corto:

sudo apt install fail2ban

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

[nginx-limit-req]
enabled = true

Para el panel web, crea un filtro personalizado apuntando al log de intentos de login fallidos de tu sistema (Laravel, PHP puro, etc.), baneando IPs que exceden intentos de login en minutos.

Paso 3 — Monitorear logs de SSH y del panel web

Revisa regularmente (o automatiza con un script) los logs de autenticación en busca de patrones anómalos: muchos intentos en poco tiempo, intentos en horarios inusuales, o intentos provenientes de países fuera del público objetivo del servidor.

# Ver intentos de login SSH fallidos recientes
sudo grep "Failed password" /var/log/auth.log | tail -50

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

Paso 4 — Proteger el panel web contra SQL injection

Confirma que todo el código del panel use prepared statements/queries parametrizadas en lugar de concatenación directa de string SQL — la causa más común de SQL injection en paneles de MU Online hechos a medida. Revisa especialmente los formularios de login, registro, recuperación de contraseña y tienda, que son los objetivos más buscados.

// Incorrecto — vulnerable a SQL injection
$query = "SELECT * FROM MEMB_INFO WHERE memb___id = '$usuario'";

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

Paso 5 — Restringir y auditar cuentas de GM

Las cuentas de Game Master tienen poder total sobre ítems y personajes, lo que las convierte en el objetivo más valioso de cualquier invasión. Usa contraseñas fuertes y únicas, autenticación de dos factores en el panel si está disponible, y mantén un log de auditoría de todas las acciones de GM (creación de ítem, teletransporte, baneo) para detectar uso indebido rápidamente.

Paso 6 — Monitorear MySQL contra accesos anómalos

Aunque MySQL esté cerrado a internet, monitorea intentos de conexión provenientes de IPs internas inusuales y queries fuera del patrón esperado (por ejemplo, updates masivos en la tabla de ítems fuera de un evento programado). Activa el log general de MySQL temporalmente durante una investigación, pero evita dejarlo encendido de forma permanente por el impacto en el rendimiento y el espacio en disco.

-- Activar el log general temporalmente para investigación
SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/var/log/mysql/general.log';

Paso 7 — Identificar señales de compromiso ya ocurrido

Algunas señales indican que una invasión ya ocurrió, incluso sin alerta en tiempo real: cuentas de GM creadas sin registro del equipo, Zen o ítems raros duplicados en cuentas específicas sin log de evento correspondiente, procesos desconocidos consumiendo CPU en el servidor, y entradas de acceso SSH en horarios fuera del patrón del equipo.

Paso 8 — Armar un plan de respuesta a incidentes

Ten un plan documentado antes de que ocurra la invasión, no durante el pánico. Como mínimo, define: quién tiene autoridad para aislar el servidor de la red, cómo preservar los logs antes de cualquier reinicio, y cómo comunicarte con la comunidad con transparencia sin exponer detalles que ayuden al invasor.

1. Aislar el servidor de la red (o bloquear la IP de origen en el firewall).
2. Preservar los logs actuales copiándolos antes de cualquier reinicio.
3. Cambiar todas las credenciales de administración (SSH, MySQL, panel, GM).
4. Investigar la extensión del daño (ítems duplicados, cuentas afectadas).
5. Restaurar desde un backup íntegro anterior a la invasión, si es necesario.
6. Comunicar a la comunidad con transparencia sobre lo ocurrido y las correcciones aplicadas.

Errores comunes y soluciones

Lista de verificación de seguridad y monitoreo de invasión

• Firewall configurado, exponiendo solo los puertos necesarios.
• Fail2ban activo para SSH y panel web.
• Panel web revisado contra SQL injection (prepared statements).
• Cuentas de GM con contraseña fuerte, 2FA y log de auditoría.
• MySQL nunca expuesto directamente a internet.
• Señales de compromiso revisadas periódicamente.
• Plan de respuesta a incidentes documentado y conocido por el equipo.

Con las defensas básicas monitoreadas y activas, el siguiente paso es integrar estas alertas de seguridad al mismo panel donde sigues CPU, disco y jugadores en línea, para tener una visión única de la salud del servidor — revisa el tutorial de creación de servidor de MU Online para garantizar que la base de infraestructura ya nace con estas protecciones en mente.

Preguntas frecuentes