Cómo implementar un honeypot contra bots de login en tu servidor de MU Online

Los bots de creación masiva de cuentas y los scripts de fuerza bruta de login son un dolor de cabeza constante para los administradores de servidores privados de MU Online: inflan cifras falsas de registro, intentan adivinar contraseñas de cuentas valiosas y, en servidores con sistema de recompensa por primer login, explotan ese tipo de beneficio a escala. Un honeypot es una trampa discreta — un campo, endpoint o comportamiento con el que solo un script automatizado interactuaría, nunca un humano real — que permite identificar y bloquear esos bots sin perjudicar la experiencia de los jugadores legítimos. Este tutorial detalla cómo implementar honeypots tanto en el sitio de registro como en el ConnectServer de tu emulador, con ejemplos prácticos de código y configuración.

Qué es un honeypot y por qué funciona

La lógica del honeypot es simple: creas un "cebo" que está técnicamente presente en la página o en el protocolo, pero invisible o irrelevante para un usuario humano normal. Los bots que analizan el HTML/DOM de forma automatizada, o que envían paquetes de red de forma genérica sin reproducir el comportamiento exacto de un cliente real, terminan interactuando con ese cebo — llenando un campo que deberían ignorar, o accediendo a un endpoint al que ningún humano accedería directamente. A diferencia de un CAPTCHA, el honeypot no exige ninguna acción extra del usuario real, lo que lo hace prácticamente invisible a la experiencia legítima.

Honeypot en el formulario de registro del sitio

La implementación más simple y ampliamente usada en cualquier sitio con formulario es el campo invisible. Agrega un campo de entrada al formulario de registro, oculto vía CSS (nunca vía type="hidden", que algunos bots ya ignoran por defecto), y rechaza cualquier envío en el que ese campo venga lleno.

<style>
  .hp-field { position: absolute; left: -9999px; top: -9999px; }
</style>

<form method="POST" action="/registro">
  <input type="text" name="usuario" placeholder="Usuario">
  <input type="password" name="clave" placeholder="Contraseña">
  <input type="email" name="email" placeholder="Correo">

  <!-- Campo honeypot: invisible para humanos, visible para bots que leen el DOM -->
  <input type="text" name="website" class="hp-field" tabindex="-1" autocomplete="off">

  <button type="submit">Crear cuenta</button>
</form>

<?php
if (!empty($_POST['website'])) {
    // Campo honeypot lleno = bot. Rechaza en silencio.
    http_response_code(200); // finge éxito para no alertar al bot
    exit;
}
// continúa el flujo normal de registro para envíos legítimos

Nota el detalle de responder con éxito falso (200) en vez de un error explícito — esto evita que el operador del bot ajuste el script al percibir un rechazo inmediato, manteniendo la trampa eficaz por más tiempo.

Honeypot de tiempo de llenado

Complementando el campo invisible, mide el tiempo entre la carga del formulario y su envío. Los bots frecuentemente envían formularios en menos de 1-2 segundos, un tiempo imposible para que un humano lea los campos y escriba usuario, contraseña y correo.

<?php
session_start();
if (!isset($_SESSION['form_loaded_at'])) {
    $_SESSION['form_loaded_at'] = time();
}

// En el procesamiento del POST:
$tempo_decorrido = time() - $_SESSION['form_loaded_at'];
if ($tempo_decorrido < 3) {
    // Envío demasiado rápido para ser humano
    http_response_code(200);
    exit;
}

Honeypot en el ConnectServer (nivel de protocolo)

Para bots que atacan directamente el ConnectServer (fuerza bruta de login, creación de cuenta vía protocolo sin pasar por el sitio), la estrategia consiste en monitorear patrones de paquetes que un cliente oficial nunca produciría: secuencia de paquetes fuera de orden, ausencia del handshake de versión esperado, o volumen de intentos de login desde la misma IP en un intervalo imposible para escritura humana. La mayoría de los emuladores (IGCN, MuEMU) ya exponen un log de intentos de login en tabla propia; la consulta de abajo identifica patrones sospechosos.

SELECT IP, COUNT(*) AS tentativas, MIN(LoginTime) AS primeira, MAX(LoginTime) AS ultima
FROM LoginAttemptLog
WHERE LoginTime > DATEADD(minute, -10, GETDATE())
GROUP BY IP
HAVING COUNT(*) > 15
ORDER BY tentativas DESC;

IPs con decenas de intentos en pocos minutos, especialmente contra usuarios secuenciales o inexistentes, indican fuerza bruta o escaneo automatizado, y pueden agregarse a una lista negra temporal en el firewall o en el propio ConnectServer.

Tabla de tipos de honeypot y dónde aplicarlos

Endpoint cebo en el sitio (ruta falsa)

Además del formulario, crea una ruta que nunca esté enlazada en ningún lugar visible del sitio (por ejemplo /wp-login.php o /admin-old), pero que los escáneres automatizados intentan acceder por defecto al rastrear cualquier dominio. Cualquier acceso a esa ruta es, por definición, automatizado — ningún humano navegando normalmente llegaría ahí. Registra la IP de acceso y agrégala a una lista de bloqueo automática.

Cuenta cebo monitoreada en la base de datos

Una técnica más avanzada es crear una cuenta "cebo" con credenciales nunca divulgadas públicamente y nunca usadas por el equipo, pero presente en la base de datos como cualquier cuenta real. Si esa cuenta específica sufre un intento de login, es evidencia fuerte de que alguien está probando credenciales obtenidas de una filtración de otro servicio (reutilización de contraseña) o de un volcado anterior del propio servidor — una alerta valiosa para revisar la seguridad general de la base de datos.

Respuesta gradual: soft-block antes del ban definitivo

Para minimizar el riesgo de que un falso positivo perjudique a un jugador real, aplica respuestas en capas crecientes de severidad en vez de banear ante la primera detección:

Integrando el honeypot al panel de administración

Centraliza las alertas de honeypot (formulario, endpoint cebo, cuenta cebo, protocolo) en un único panel o canal de notificación (webhook al Discord del staff, por ejemplo), para que el equipo de seguridad vea el panorama completo en vez de logs dispersos. Un webhook simple puede disparar un mensaje cada vez que se active un honeypot, incluyendo IP, timestamp y tipo de trampa activada, permitiendo una respuesta manual rápida en casos ambiguos que la automatización no debería resolver sola.

Errores comunes y soluciones

Lista de verificación de implementación del honeypot

• Campo invisible agregado al formulario de registro y login.
• Verificación de tiempo mínimo de llenado implementada.
• Endpoint cebo creado y sin ningún enlace visible en el sitio.
• Cuenta cebo monitoreada registrada en la base de datos.
• Consulta de patrón de intentos de login programada en el ConnectServer.
• Respuesta gradual (soft-block antes del ban) configurada.
• Alertas centralizadas en un panel o webhook para el equipo de seguridad.
• Ningún detalle técnico de la implementación divulgado públicamente.

Con el honeypot activo, reduces significativamente el ruido de bots en el registro y el login sin sacrificar la experiencia de los jugadores reales; para cerrar el ciclo de seguridad de tu infraestructura, revisa también el tutorial de creación de servidor de MU Online y confirma que las demás capas de protección (firewall, anti-DDoS) están alineadas con esta estrategia.

Preguntas frecuentes