Cómo crear cuentas de GM/Admin con seguridad en MU Online

Las cuentas de GM y Admin son las llaves maestras de tu servidor de MU Online. Una única cuenta administrativa comprometida permite que un atacante cree ítems perfectos, inyecte zen infinito, borre personajes, altere rankings y destruya la economía en minutos, y muchas veces el dueño del servidor solo lo nota cuando los jugadores empiezan a quejarse. Crear estas cuentas no es difícil; crearlas con seguridad exige cuidado con la contraseña, el nivel de acceso, el aislamiento, el log y un plan de revocación. Este tutorial muestra el proceso completo, desde el INSERT en la base hasta la auditoría continua, recordando siempre que los nombres de tabla, campos y valores de ctl_code son ejemplos que varían según la season/emulador.

Requisitos previos

• Acceso a la base de datos del servidor, vía SQL Server Management Studio (SSMS) para emuladores basados en MSSQL o phpMyAdmin/HeidiSQL para los basados en MySQL.
• Conocimiento del schema de tu emulador: saber si la tabla de cuentas es MEMB_INFO, accounts u otra, y qué campo controla el nivel (ctl_code, AccountLevel, etc.).
• Gestor de contraseñas para generar y guardar contraseñas fuertes y únicas.
• Entorno de prueba para validar la creación antes de tocar la producción.
• Acceso al archivo de configuración del GameServer, en caso de que tu emulador use una GMList además del ctl_code.
• Política mínima definida: quién tendrá acceso, con qué nivel, y cómo se revocará el acceso. Si aún estás montando el servidor desde cero, comienza por cómo crear un servidor de MU Online.

Cómo define MU Online una cuenta administrativa

En la mayoría de los emuladores, el nivel de acceso de una cuenta es un número guardado en la base. En servidores basados en el schema clásico, la tabla es MEMB_INFO y el campo es ctl_code. El valor 0 es jugador común; los valores mayores liberan comandos y privilegios. La escala exacta cambia entre distribuciones: en algunos, 1 ya es Admin; en otros existe una gradación (1 = GM, 8 = Admin). Algunos emuladores modernos ignoran el ctl_code y usan una GMList en el config del GameServer, donde asocias el nick a un nivel numérico. Muchos usan ambos. Antes de crear cualquier cuenta, descubre qué modelo usa tu servidor.

La tabla de abajo muestra una escala típica de ejemplo:

Paso 1 — Generar una contraseña fuerte y única

Antes del INSERT, genera la contraseña. Las cuentas de GM son objetivo de fuerza bruta e ingeniería social. Reglas mínimas:

• Al menos 16 caracteres, mezclando mayúsculas, minúsculas, números y símbolos.
• Única — nunca reutilizada del correo, Discord u otra cuenta del servidor.
• Generada por un gestor de contraseñas, no inventada de memoria.
• Guardada solo en el gestor, nunca en un txt en el escritorio o en el chat de Discord.

Recuerda que el formato de almacenamiento de la contraseña varía según el emulador: algunos la guardan en texto plano (pésimo, pero común en builds antiguas), otros usan MD5, y los más nuevos usan un hash mejor. Si tu emulador tiene la columna de contraseña en texto plano, trata la base entera como sensible y restringe el acceso al SQL.

Paso 2 — Crear la cuenta en la base

Con la contraseña en mano, crea la cuenta. Ejemplo en MSSQL para schema clásico (varía según la season/emulador):

USE MuOnline;

-- Crear cuenta administrativa nueva
INSERT INTO MEMB_INFO
    (memb___id, memb__passwd, memb_name, sno__numb, bloc_code, ctl_code)
VALUES
    ('adm_bruno', 'S3nh4-F0rt3-Unica!2026', 'Bruno Admin',
     '000-000-000-0000', 0, 8);

-- Confirmar creación
SELECT memb___id, memb_name, ctl_code, bloc_code
FROM MEMB_INFO
WHERE memb___id = 'adm_bruno';

Puntos de atención:

1. sno__numb necesita un valor válido en el formato que el emulador espera; algunos validan el tamaño de la string.
2. bloc_code = 0 garantiza que la cuenta no nace bloqueada.
3. ctl_code define el nivel; usa el mínimo necesario para la función de la persona.
4. Si la contraseña se almacena con hash, usa la función del emulador o el panel, no un texto plano que el servidor no va a reconocer.

Para elevar una cuenta existente en lugar de crear una nueva:

-- Promover cuenta ya existente a GM sénior
UPDATE MEMB_INFO
SET ctl_code = 2
WHERE memb___id = 'conta_do_moderador';

-- Auditar todas las cuentas con acceso administrativo
SELECT memb___id, memb_name, ctl_code
FROM MEMB_INFO
WHERE ctl_code > 0
ORDER BY ctl_code DESC;

Paso 3 — Aplicar el nivel mínimo necesario

El error más común es dar Admin (ctl_code máximo) a todo el equipo. Aplica el principio del menor privilegio: cada persona recibe solo lo que necesita para su trabajo. Un moderador de chat no necesita crear ítems; un organizador de eventos no necesita banear cuentas en masa. Cuantas menos cuentas tengan poder total, menor la superficie de ataque y más fácil la auditoría. Mapea funciones a niveles antes de distribuir acceso, y documenta ese mapa.

Paso 4 — Aislar la cuenta administrativa

Una cuenta de Admin no debe mezclarse con la vida normal del servidor:

• Nick y cuenta dedicados: no uses la cuenta que usas para jugar. Si tu cuenta de juego se filtra en un phishing de Discord, el daño queda contenido.
• Sin participación en la economía real: las cuentas de GM no deben comprar, vender ni tradear con jugadores. Eso evita sospechas de favoritismo y mantiene los logs limpios.
• IP restringida cuando sea posible: algunos emuladores y paneles permiten restringir el login administrativo a IPs conocidas. Combínalo con acceso remoto seguro al servidor.
• Correo de recuperación fuerte: la cuenta de correo ligada a la cuenta administrativa también necesita contraseña fuerte y verificación en dos pasos.

Paso 5 — Configurar la GMList (si el emulador la usa)

Muchos emuladores modernos exigen que el nick esté en una GMList en el config del GameServer, además del ctl_code en la base. Formato de ejemplo (ini):

[GMList]
; nick = nivel de acceso (varía por emulador)
adm_bruno   = 8
gm_suporte  = 1
gm_eventos  = 2

[GMConfig]
LogGMCommands   = 1   ; registrar todos los comandos de GM
GMInvisible     = 1   ; permite que el GM quede invisible
RestrictByIP    = 0   ; 1 = valida el IP del GM

Si el nick está en la base con ctl_code alto pero fuera de la GMList (o viceversa), el acceso puede no funcionar como se espera. Mantén ambos sincronizados.

Paso 6 — Habilitar el log de todas las acciones

Ninguna cuenta administrativa debe actuar sin dejar rastro. Configura el LogServer o los logs del GameServer para registrar autor, acción, objetivo y hora, especialmente para creación de ítem, entrega de zen/coin, baneo y alteración de personaje. Además del log del juego, registra también quién accedió al SQL y cuándo. Un servidor sin log administrativo es imposible de auditar después de un incidente.

Paso 7 — Probar el acceso

Después de crear, valida antes de confiar:

1. Inicia sesión con la cuenta nueva en un cliente de prueba.
2. Ejecuta un comando de bajo impacto compatible con el nivel (por ejemplo, /post en un staging).
3. Confirma que el log registró la acción.
4. Intenta un comando por encima del nivel de la cuenta y confirma que es denegado.
5. Verifica en la base que el ctl_code sigue siendo el esperado.

Rotación y revocación de acceso

El acceso administrativo no es permanente. Cada vez que alguien deja el equipo, o sospechas de una filtración:

-- Revocar acceso administrativo de inmediato
UPDATE MEMB_INFO
SET ctl_code = 0
WHERE memb___id = 'gm_que_saiu';

Y, si usas GMList, elimina el nick de ahí también, y cambia cualquier contraseña que haya sido compartida. Haz una revisión trimestral de todas las cuentas con ctl_code > 0 para eliminar accesos olvidados; la query de auditoría del Paso 2 sirve para eso.

Errores comunes y soluciones

Buenas prácticas de seguridad

• Una cuenta administrativa por persona — nada de cuenta compartida por todo el equipo.
• Contraseña única y fuerte por cuenta, guardada en un gestor, con verificación en dos pasos en el correo asociado.
• Menor privilegio siempre: da el nivel mínimo que la función exige.
• Nunca uses la cuenta de Admin para jugar o tradear.
• Log obligatorio en toda acción generadora de valor.
• Auditoría periódica de las cuentas con ctl_code > 0.
• Revocación inmediata en la salida de cualquier miembro del staff.

Lista de verificación de lanzamiento

• Modelo de acceso del emulador identificado (ctl_code, GMList o ambos)
• Escala de niveles mapeada por función del equipo
• Contraseñas fuertes y únicas generadas en un gestor
• Cuentas administrativas separadas de las cuentas de juego
• ctl_code aplicado con el menor privilegio posible
• GMList sincronizada con la base (si aplica)
• Log de comandos de GM habilitado y probado
• Acceso validado en prueba, incluida la denegación de comando por encima del nivel
• Verificación en dos pasos en los correos de las cuentas administrativas
• Procedimiento de revocación documentado y probado
• Auditoría periódica de cuentas con acceso agendada

Preguntas frecuentes