Cómo recuperar un servidor de MU Online después de una invasión (hack)

Una invasión exitosa es el peor día en la vida de un administrador de servidor de MU Online — objetos duplicados, cuentas robadas, base de datos corrompida o, en el peor caso, datos de jugadores filtrados. Lo que diferencia un incidente bien gestionado de un desastre permanente es la velocidad y el orden de las acciones en las primeras horas. Este tutorial presenta un plan de respuesta a incidentes adaptado a la realidad de los servidores privados, cubriendo contención, diagnóstico, restauración y comunicación.

Reconociendo las señales de una invasión

Antes de actuar, confirma que realmente hay una invasión y no un bug o un pico de tráfico legítimo. Las señales típicas incluyen: cantidad anormal de Zen u objetos raros apareciendo de la nada, inicios de sesión administrativos en horarios e IPs inusuales, cuentas de jugadores siendo vaciadas en secuencia, el panel web o el GameServer respondiendo de forma anómala, o alertas de herramientas de monitoreo (CPU/base de datos disparados sin motivo aparente).

Paso 1 — Contener el ataque de inmediato

La prioridad cero es detener el daño en curso, no investigar la causa. Esto generalmente significa:

1. Poner el GameServer y el ConnectServer offline de inmediato.
2. Bloquear el acceso externo al panel administrativo web.
3. Si es posible, aislar la base de datos de la red externa (regla de firewall temporal).
4. Revocar tokens/sesiones activas de administradores en el panel.

No te saltes este paso para "investigar primero" — cada minuto en línea con el atacante activo es daño adicional.

Paso 2 — Preservar evidencias antes de cualquier limpieza

Antes de restaurar cualquier cosa, copia los logs relevantes a un lugar seguro fuera del servidor comprometido: logs del GameServer, logs de MySQL (general_log, slow_query_log si están activos), logs de acceso del panel web (Apache/Nginx) y logs del sistema operativo (auth.log/eventos de inicio de sesión). Estos archivos son la única forma de identificar el vector de ataque después.

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/

Paso 3 — Identificar el vector de ataque

Con los logs preservados, cruza los horarios. Los vectores más comunes en servidores de MU privado son:

Paso 4 — Evaluar el alcance del daño

Antes de restaurar, entiende el alcance: cuántas cuentas fueron afectadas, qué objetos/Zen fueron duplicados o robados, si hubo eliminación de tablas, y si datos sensibles (correos, hashes de contraseña) fueron exfiltrados. Una consulta simple ayuda a mapear la actividad anómala por horario:

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;

Paso 5 — Restaurar desde un backup limpio

Identifica el backup más reciente anterior al inicio confirmado del ataque —no al momento en que lo notaste, que generalmente es posterior al inicio real. Restaura la base de datos en ese punto y, si es posible y seguro, reaplica solo las transacciones legítimas identificadas manualmente entre el backup y el incidente (compras confirmadas, progreso validado). Nunca restaures sobre el mismo servidor comprometido sin antes reinstalar el sistema operativo o, como mínimo, revisar todos los binarios y configuraciones en busca de backdoors.

Paso 6 — Restablecer credenciales en masa

Después de la restauración, restablece: contraseña de todos los administradores y GMs, contraseña de acceso a la base de datos (MySQL root y usuarios de aplicación), claves de API del panel web, y fuerza el reset de contraseña para los jugadores si hay algún indicio de exfiltración de hashes. Comunica el reset forzado de contraseña a los jugadores con anticipación e instrucciones claras de cómo restablecerla.

Paso 7 — Corregir la causa raíz antes de reabrir

Reabrir el servidor sin corregir la vulnerabilidad identificada es el error más recurrente después de un incidente — el mismo atacante vuelve en pocos días. Dependiendo del vector:

• SQL Injection: aplica prepared statements en el panel, actualiza o reemplaza el CMS vulnerable.
• Credencial filtrada: activa 2FA para los administradores, revisa la política de contraseñas fuertes.
• Exploit del emulador: aplica el parche de la comunidad o actualiza a la versión corregida.
• RDP/SSH débil: cambia a autenticación por clave, restringe por IP/VPN, cambia el puerto predeterminado.

Paso 8 — Comunicar a la comunidad con transparencia

Publica un comunicado claro en el sitio y Discord explicando qué pasó (sin detalles técnicos explotables), qué se hizo para contenerlo, el impacto para los jugadores (reset de contraseña, reversión de objetos duplicados) y el plazo estimado de retorno. La transparencia controlada preserva la confianza de la comunidad; el silencio o la minimización genera desconfianza y éxodo de jugadores.

Prevención continua después del incidente

Errores comunes y soluciones

Lista de verificación de recuperación después de una invasión

• Servidor puesto offline de inmediato tras la detección.
• Logs preservados antes de cualquier limpieza.
• Vector de ataque identificado con evidencias.
• Alcance del daño mapeado (cuentas, objetos, datos).
• Backup limpio restaurado en un entorno revisado.
• Credenciales de admin, base de datos y panel restablecidas.
• Causa raíz corregida antes de reabrir al público.
• Comunicado transparente publicado para la comunidad.

Después de recuperar el servidor, revisa los fundamentos de configuración segura desde el origen para reducir la posibilidad de un nuevo incidente — el tutorial de creación de servidor de MU Online es un buen punto de partida para reforzar la base antes de reabrir al público.

Preguntas frecuentes