Cómo segmentar la red del GameServer para proteger tu servidor de MU Online

Un servidor de MU Online privado típico expone, sin darse cuenta, mucho más de lo que debería: es común ver GameServer, ConnectServer, base de datos e incluso el panel administrativo web corriendo en la misma red plana, todos accesibles desde internet en los mismos puertos. Esto convierte cualquier vulnerabilidad en un componente en una puerta de entrada para todos los demás. Segmentar la red —aislando cada componente en su propia zona, con reglas de firewall explícitas sobre quién puede hablar con quién— es una de las medidas de seguridad más efectivas y menos aplicadas por los administradores de servidores privados. Este tutorial muestra cómo planificar e implementar esa segmentación, desde el diseño de la topología hasta las reglas de firewall específicas.

Por qué la red plana es un riesgo

En una red plana, si un atacante compromete el servidor web (generalmente el componente más expuesto y más atacado, por correr un CMS o panel PHP), obtiene acceso de red directo a la base de datos y al GameServer, porque no hay ninguna barrera entre ellos. Una vulnerabilidad en un formulario de login del sitio se convierte, en pocos pasos, en un volcado completo de la base de cuentas e ítems. La segmentación de red rompe esa cadena: aunque un componente sea comprometido, el atacante no puede "saltar" lateralmente a los demás sin pasar por una regla de firewall explícita.

Componentes típicos de un servidor de MU y su exposición ideal

La regla general: solo el ConnectServer y el sitio necesitan estar accesibles directamente desde internet. Todo lo demás debe vivir detrás de un firewall que bloquea por defecto y libera solo lo necesario.

Diseñando los segmentos de red

Una topología de referencia con tres segmentos:

[ Internet ]
     |
[ Segmento Público ]  -- ConnectServer, Sitio/Panel Web
     |  (regla: solo puertos específicos liberados)
[ Segmento de Aplicación ]  -- GameServer, DataServer
     |  (regla: solo el GameServer habla con la base de datos)
[ Segmento de Base de Datos ]  -- MSSQL/MySQL

Cada flecha representa una regla de firewall explícita, no una vía abierta. El tráfico entre segmentos debe ser una excepción documentada, nunca la norma.

Implementando con VPC y Security Groups (nube)

Si el servidor corre en un proveedor de nube (AWS, Azure, GCP, u otros proveedores con VPC), la segmentación se hace vía subredes privadas y grupos de seguridad. Un ejemplo de estructura en una VPC:

VPC: 10.0.0.0/16
├── Subred Pública:    10.0.1.0/24  → ConnectServer, Sitio
├── Subred Aplicación: 10.0.2.0/24  → GameServer, DataServer
└── Subred Base de Datos: 10.0.3.0/24  → MSSQL/MySQL

El ConnectServer en la subred pública tiene IP accesible desde internet (o detrás de un Load Balancer); GameServer y base de datos quedan en subredes privadas, sin ruta directa a internet, accesibles solo vía IP interna.

Reglas de firewall por segmento

La siguiente tabla resume las reglas mínimas necesarias entre segmentos:

Nota que el sitio tiene su propio camino hasta la base de datos, idealmente con una cuenta de base de datos con permisos restringidos (solo SELECT en tablas de ranking, nunca UPDATE/DELETE).

Configurando con iptables (servidor Linux dedicado)

Si los componentes corren en servidores Linux propios (no en nube gestionada), iptables o nftables cumplen el mismo papel. Un ejemplo de reglas en el servidor de base de datos, aceptando conexiones solo desde la IP interna del GameServer:

# Política por defecto: bloquear todo
iptables -P INPUT DROP

# Permitir loopback
iptables -A INPUT -i lo -j ACCEPT

# Permitir solo al GameServer en el puerto de MySQL
iptables -A INPUT -p tcp -s 10.0.2.10 --dport 3306 -j ACCEPT

# Permitir SSH solo desde una IP de gestión conocida
iptables -A INPUT -p tcp -s 198.51.100.5 --dport 22 -j ACCEPT

# Log y drop del resto
iptables -A INPUT -j LOG --log-prefix "IPTABLES-DROPPED: "
iptables -A INPUT -j DROP

Guarda las reglas con iptables-save y asegúrate de que se restauren en el arranque, o un reinicio dejará al servidor sin protección.

Aislando el panel administrativo web

El panel administrativo (donde los GMs gestionan cuentas, ítems, eventos) es un objetivo particularmente sensible —generalmente tiene permisos de escritura directa en la base de datos. Nunca lo expongas en la misma URL/puerto público del sitio de jugadores. Recomendaciones:

• Coloca el panel en un subdominio o puerto separado, protegido por VPN o lista de IPs permitidas.
• Usa autenticación de dos factores para las cuentas de administrador.
• Restringe la cuenta de base de datos usada por el panel a las tablas estrictamente necesarias.

Segmentando también la red de gestión (SSH/RDP)

Un error común es segmentar bien los servicios del juego pero dejar el acceso administrativo (SSH, RDP, paneles de hosting) abierto a internet sin restricción. Trata el acceso de gestión como un segmento más: libera SSH/RDP solo desde una VPN de administración o una lista fija de IPs de confianza, nunca 0.0.0.0/0.

Monitoreando y auditando las reglas

La segmentación sin monitoreo es una falsa sensación de seguridad. Configura logs de firewall (bloqueos y liberaciones) y revísalos periódicamente:

Probando la segmentación

Después de implementarla, valida activamente que la segmentación funciona como se espera, intentando conexiones que deberían fallar:

1. Desde internet pública, intenta conectarte directamente al puerto de la base de datos —debe fallar (timeout o connection refused).
2. Desde el segmento público (ConnectServer), intenta conectarte al puerto de la base de datos —debe fallar, porque solo el GameServer tiene permiso.
3. Desde el GameServer, confirma que la conexión a la base de datos funciona normalmente.
4. Corre un escáner de puertos (nmap) desde fuera de la red contra la IP pública —confirma que solo aparecen abiertos los puertos esperados (ConnectServer, sitio).

Errores comunes y soluciones

Lista de verificación de segmentación de red

• Topología de segmentos diseñada (público, aplicación, base de datos).
• Solo ConnectServer y sitio expuestos directamente a internet.
• Reglas de firewall explícitas por origen/destino/puerto, bloqueo por defecto.
• Panel administrativo aislado con VPN o lista de IPs y 2FA.
• Acceso de gestión (SSH/RDP) restringido a VPN o IPs de confianza.
• Persistencia de las reglas de firewall configurada (sobrevive a reinicios).
• Pruebas activas de segmentación realizadas (intentos de conexión que deben fallar).
• Monitoreo y logs de firewall configurados con revisión periódica.

Con la red del GameServer debidamente segmentada, el siguiente paso lógico es aplicar el mismo rigor a la capa de datos —consulta el tutorial de segregación de red de la base de datos para profundizar específicamente en la protección del componente más sensible de todo el servidor.

Preguntas frecuentes