Cómo configurar protección anti-DDoS en la capa 4/7 en MU Online

Los servidores de MU Online están entre los blancos más atacados del escenario de servidores privados. La combinación de competencia feroz, jugadores insatisfechos y la facilidad de contratar ataques de denegación de servicio por pocos pesos hace del DDoS una amenaza constante y no una hipótesis lejana. Un ataque exitoso tumba el servidor, expulsa a los jugadores en el momento más crítico (un evento, un lanzamiento) y destruye la reputación construida en meses. Este tutorial avanzado explica cómo montar una defensa en profundidad que cubre tanto los ataques volumétricos de capa 4 como los ataques sofisticados de capa 7, siempre con ejemplos que varían por proveedor/versión.

La idea central que necesitas interiorizar es que no existe una única solución mágica. Una defensa anti-DDoS eficaz se hace en capas, cada una cubriendo un tipo de ataque que la otra no cubre. Proteger solo el sitio y olvidar el ConnectServer, o filtrar paquetes en Windows y dejar que el enlace del datacenter se sature, son errores que dejan la puerta abierta. Vamos a construir la defensa de afuera hacia adentro.

Requisitos previos

Para seguir esta guía vas a necesitar:

• Acceso administrativo al servidor (Windows Server 2016/2019/2022) que corre el ConnectServer, GameServer y demás servicios del emulador.
• Acceso al panel de tu proveedor de hospedaje o datacenter, para verificar si hay mitigación de capa 4 incluida o contratable.
• Una cuenta en un proveedor de protección (Cloudflare, o un proveedor de VPS con scrubbing anti-DDoS incluido). Los nombres y límites varían por proveedor/versión.
• Conocimiento de qué puertos usa tu emulador: típicamente el puerto del ConnectServer, el rango de puertos de los GameServers y el puerto del servidor web. Los valores exactos varían por versión.
• Acceso al DNS de tu dominio.
• Respaldo y un plan de rollback antes de aplicar reglas de firewall, pues una regla mal hecha puede bloquear a tus propios jugadores.

Si el servidor todavía está en fase de montaje, sigue primero el paso a paso de cómo crear un servidor de MU Online y solo después blinda la infraestructura con esta guía.

Entendiendo los dos tipos de ataque

Antes de defender, hay que saber contra qué luchas. Los ataques se dividen en dos grandes familias, nombradas por las capas del modelo OSI.

Capa 4 (transporte) — ataques volumétricos. El objetivo es saturar el enlace de red del servidor con un volumen masivo de paquetes: SYN flood, UDP flood, amplificación DNS/NTP. El servidor ni siquiera llega a procesar las solicitudes; el propio cable de red se satura. La defensa contra esto debe ocurrir antes de que el tráfico llegue a tu servidor, en la red del proveedor (scrubbing).

Capa 7 (aplicación) — ataques de agotamiento. Aquí el atacante envía solicitudes que parecen legítimas: floods de login en el ConnectServer, intentos repetidos de creación de cuenta, HTTP flood en el sitio. El volumen de banda es bajo, pero cada solicitud consume CPU y base de datos. Son más difíciles de distinguir de jugadores reales y exigen inteligencia de aplicación para mitigar.

Los ejemplos de vectores de arriba son representativos y la mezcla usada en cada ataque varía.

Paso 1: ocultar la IP real del servidor

Esta es la base de todo. Si la IP real (de origen) de tu servidor se filtra, cualquier proxy o mitigación que contrates se vuelve inútil, porque el atacante simplemente envía el flood directo a la IP real, sorteando toda la protección. Por lo tanto, la IP real nunca debe aparecer públicamente.

Fuentes comunes de filtración de IP que necesitas cerrar:

1. Registros DNS antiguos. Un registro A histórico apuntando a la IP real queda indexado en servicios de historial de DNS. Al migrar detrás de un proxy, cambia la IP real del servidor por una nueva, pues la antigua ya está quemada.
2. Correo del propio servidor. Si el sitio envía correos de recuperación de contraseña directamente desde la IP del servidor, el encabezado del correo revela la IP. Usa un servicio de correo externo (SMTP relay).
3. Subdominios expuestos. Un direct.tudominio.com o ftp.tudominio.com apuntando a la IP real lo entrega todo. Audita todos los registros DNS.
4. El propio archivo del cliente. El ServerList o .dat de conexión del cliente del juego contiene la dirección de destino. Si apunta a la IP real en vez de a la IP protegida, de nada sirve ocultarla en el DNS. Apunta el cliente a la dirección protegida.

Después de cerrar las filtraciones, configura el firewall del servidor para aceptar tráfico de juego solo de las IP de tu proveedor de mitigación, rechazando conexiones directas de cualquier otra origen. Esto garantiza que, aunque la IP se filtre en el futuro, el ataque directo sea rechazado en el borde.

Paso 2: mitigación de capa 4 (volumétrica)

La capa 4 no puede defenderse dentro de tu servidor, porque cuando el paquete llega a Windows, el enlace ya se saturó. La mitigación debe ocurrir upstream, en la red que tiene capacidad de absorber y limpiar (scrubbing) el tráfico. Tienes tres caminos principales:

• Proveedor de VPS/dedicado con anti-DDoS incluido. Diversos proveedores ofrecen protección de capa 4 con capacidad de ejemplo del orden de cientos de Gbps a algunos Tbps de absorción. Es la opción más simple: el scrubbing es transparente. Confirma los límites y si hay costo por ataque.
• Túnel GRE / IP protegida. Algunos servicios proporcionan una IP limpia que recibe el tráfico, filtra y reenvía el legítimo a tu servidor por un túnel. Exige configuración de red más avanzada.
• Cloudflare Spectrum o equivalente para TCP. Para proteger el tráfico del juego (TCP puro del ConnectServer y GameServer), un servicio de proxy TCP con anti-DDoS es necesario, ya que el plan web común solo cubre HTTP/HTTPS.

El punto innegociable: el tráfico del juego (los puertos del ConnectServer y de los GameServers) necesita estar cubierto por mitigación de capa 4, no solo el sitio. Muchos administradores protegen solo el sitio con proxy y dejan el puerto del juego expuesto, y es exactamente allí donde entra el ataque.

Paso 3: endurecimiento de la pila TCP en Windows Server

Incluso con scrubbing upstream, endurecer el servidor añade una capa de defensa contra lo que atraviese el filtro y contra ataques menores. Algunos ajustes de registro y firewall ayudan. Estos son ejemplos y los valores ideales varían por versión de Windows y carga.

:: Ejemplo: habilitar protección contra SYN flood (SynAttackProtect)
:: Ajuste vía registro en HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
:: SynAttackProtect, TcpMaxHalfOpen, TcpMaxHalfOpenRetried
:: Los valores exactos varían por versión de Windows Server

En el firewall de Windows, crea reglas que:

1. Permitan tráfico de entrada solo en los puertos realmente usados (ConnectServer, rango de GameServers, web). Cierra todo lo demás.
2. Restrinjan los puertos administrativos (RDP, SQL Server) a IP específicas de administración, nunca abiertas al mundo. RDP abierto es vector tanto de intrusión como de ataque.
3. Limiten la tasa de nuevas conexiones por IP cuando el emulador o un firewall de aplicación lo permita.

# Ejemplo: restringir RDP a una IP de administracion
New-NetFirewallRule -DisplayName "RDP Admin Only" -Direction Inbound `
  -Protocol TCP -LocalPort 3389 -RemoteAddress SEU_IP_ADMIN -Action Allow

Paso 4: defensa de capa 7 en el ConnectServer y el login

Los ataques de capa 7 en MU suelen apuntar al ConnectServer con floods de conexión y a la rutina de login/creación de cuenta, que tocan la base de datos. Como el volumen de banda es bajo, el scrubbing volumétrico no los detecta. La defensa aquí es inteligencia de aplicación:

• Rate-limit por IP. Limita el número de intentos de login y de nuevas conexiones por IP en una ventana de tiempo. Un jugador legítimo no intenta iniciar sesión 200 veces por minuto. El límite de ejemplo varía por versión del emulador y herramienta de firewall.
• CAPTCHA en el registro y en el login web. Impide la automatización de creación de cuentas en masa que sobrecarga la base de datos. Usa una solución de desafío moderna.
• Cola de conexión. Algunos emuladores o proxies soportan una cola que absorbe picos de nuevas conexiones sin tumbar el servicio.
• Bloqueo geográfico opcional. Si el servidor atiende solo a una región, restringir conexiones a rangos de IP nacionales reduce drásticamente la superficie de ataque. Hazlo con cuidado para no bloquear jugadores legítimos con VPN.

Paso 5: protección del sitio y de la aplicación web

El sitio del servidor (registro, ranking, tienda VIP) es el blanco de capa 7 más fácil y el más visible. Colócalo detrás de un proxy inverso con WAF (Web Application Firewall) y protección DDoS de capa 7. Configuraciones esenciales:

• Modo "under attack" accionable. Un botón que, al activarse durante un ataque, presenta un desafío a cada visitante antes de liberar el acceso.
• Reglas de rate-limit en los endpoints sensibles: login, registro, recuperación de contraseña y endpoints de pago.
• Cache agresivo de las páginas estáticas (ranking, noticias) para que un flood no llegue al PHP ni a la base de datos.
• Ocultar tecnologías. Elimina los encabezados que revelan versiones de servidor web y framework, que orientan al atacante.

Paso 6: monitoreo y respuesta a incidentes

Una defensa sin visibilidad es ciega. Necesitas saber que estás bajo ataque antes de que los jugadores se quejen. Monta un mínimo de observabilidad:

• Alertas de uso de banda y de CPU que se disparan cuando superan un umbral de ejemplo.
• Monitor externo de disponibilidad (uptime) que prueba el ConnectServer y el sitio cada pocos minutos desde fuera de la red.
• Logs de conexión del ConnectServer para identificar patrones de flood e IP recurrentes.
• Un runbook escrito: quién hace qué cuando el ataque empieza (activar el modo under attack, contactar al soporte del proveedor de scrubbing, comunicar a la comunidad).

La comunicación con la comunidad durante un ataque está subestimada. Un anuncio transparente ("estamos bajo ataque, trabajando en la mitigación") preserva mucho más la confianza que el silencio.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• IP real del servidor cambiada y la antigua descartada
• Todos los registros DNS auditados sin filtrar la IP de origen
• Correo transaccional movido a SMTP relay externo
• Cliente del juego apuntando a la dirección protegida, no a la IP real
• Firewall aceptando tráfico de juego solo de las IP del proveedor de mitigación
• Mitigación de capa 4 confirmada para los puertos del juego (no solo el sitio)
• RDP y SQL Server restringidos a IP de administración
• Rate-limit de login/conexión configurado en el ConnectServer
• CAPTCHA activo en el registro y login web
• Sitio detrás de WAF con modo "under attack" probado
• Cache de las páginas estáticas del sitio activo
• Alertas de banda y CPU configuradas
• Monitor de uptime externo activo en el juego y en el sitio
• Runbook de respuesta a incidentes escrito y compartido con el equipo

Conclusión

Proteger un servidor de MU Online contra DDoS no es comprar un único servicio y olvidarse. Es construir defensa en profundidad: ocultar la IP real, contratar mitigación volumétrica de capa 4 que cubra el tráfico del juego, endurecer la pila TCP de Windows, aplicar rate-limit y CAPTCHA contra los ataques de capa 7 y blindar el sitio con WAF. Cada capa cubre un flanco que la otra deja abierto. El error más común y más fatal es proteger solo el sitio y olvidar que el puerto del ConnectServer es donde el ataque realmente duele. Con la arquitectura en capas de esta guía, calibrada a los límites de tu proveedor (que varían por proveedor/versión), tu servidor sobrevive a los ataques que tumban a la competencia despreparada.

Preguntas frecuentes