Cualquier instalación de WHMCS expuesta públicamente es bombardeada con intentos de inicio de sesión por fuerza bruta a las pocas horas de ponerse en marcha. Fail2ban monitoriza tus registros, detecta fallos repetidos y bloquea automáticamente las IP infractoras. Esta guía lo configura para WHMCS (y la pila SSH + web que lo rodea) en Ubuntu.

Requisitos previos

  • Ubuntu 22.04 con acceso root
  • WHMCS ejecutándose detrás de nginx o Apache
  • Registro de actividad de WHMCS habilitado (lo está por defecto)

Paso 1 — Instalar Fail2ban

apt update
apt install -y fail2ban
systemctl enable fail2ban

Paso 2 — Crear una configuración de jail local

Nunca edites jail.conf directamente (las actualizaciones lo sobrescriben). Crea /etc/fail2ban/jail.local:

[DEFAULT]
# Ban for 1 hour after 5 failures within 10 minutes
bantime  = 3600
findtime = 600
maxretry = 5
# Ignore your own IPs (office, home, monitoring)
ignoreip = 127.0.0.1/8 ::1 YOUR.OFFICE.IP

[sshd]
enabled = true
port    = 2222

Ajusta port a tu puerto SSH real y añade tus IP estáticas a ignoreip para que nunca te quedes fuera.

Paso 3 — Habilitar prohibiciones escalonadas para infractores reincidentes

El jail recidive prohíbe las IP que siguen regresando después de que su primera prohibición expira — por mucho más tiempo:

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
banaction = iptables-allports
bantime  = 604800   ; 1 week
findtime = 86400    ; 1 day
maxretry = 3

Paso 4 — Crear un filtro de WHMCS

WHMCS registra los inicios de sesión de administrador fallidos en su base de datos, pero también escribe en el registro del servidor web en caso de intentos repetidos. El enfoque más limpio es un filtro en el propio registro de inicios de sesión fallidos de WHMCS. Primero, apunta WHMCS a un archivo de registro — o analiza el registro de acceso web para el endpoint de inicio de sesión.

Crea /etc/fail2ban/filter.d/whmcs.conf:

[Definition]
# Matches failed admin/client login POSTs returning to login page
failregex = ^<HOST> .* "POST /(dologin|admin/login)\.php.* 200
            ^<HOST> .* "POST /index\.php\?rp=/login.* 200
ignoreregex =

Este es un patrón inicial — ajusta failregex a la estructura de URL y plantilla de tu WHMCS. La clave es hacer coincidir el POST de inicio de sesión desde la IP del cliente.

Paso 5 — Añadir el jail de WHMCS

Añade a /etc/fail2ban/jail.local:

[whmcs]
enabled  = true
port     = http,https
filter   = whmcs
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 600
bantime  = 7200

Apunta logpath a tu registro de acceso real de nginx/Apache para el vhost de WHMCS.

Paso 6 — Cuidado con el problema de la IP real

Si WHMCS está detrás de un CDN o proxy inverso, tu registro de acceso mostrará la IP del CDN, no la del visitante — Fail2ban banearía el CDN y tumbaría todo tu sitio.

Soluciona esto en nginx restaurando primero la IP real. Para SprintCDN o Cloudflare, añade sus rangos a una configuración de IP real:

# /etc/nginx/snippets/realip.conf
set_real_ip_from 1.2.3.0/24;   # your CDN's ranges
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Inclúyelo en tu bloque de servidor y asegúrate de que el formato de registro utiliza $remote_addr (que ahora refleja el cliente real). Solo entonces Fail2ban baneará la IP correcta.

Paso 7 — Iniciar y verificar

systemctl restart fail2ban
fail2ban-client status

Deberías ver tus jails activos: sshd, recidive, whmcs. Verifica un jail específico:

fail2ban-client status sshd

Esto muestra las IP actualmente prohibidas y los recuentos totales.

Paso 8 — Probar que funciona

Desde una IP desechable (un teléfono con datos móviles funciona), falla deliberadamente el inicio de sesión SSH o WHMCS 6 veces. Luego en el servidor:

fail2ban-client status sshd
# Should list the test IP under "Banned IP list"
iptables -L -n | grep <TEST_IP>

Desbloquéala cuando termines:

fail2ban-client set sshd unbanip <TEST_IP>

Paso 9 — Recibir notificaciones de prohibiciones (opcional)

Fail2ban puede enviarte un correo electrónico con cada prohibición. En jail.local bajo [DEFAULT]:

destemail = you@yourdomain.com
sender    = fail2ban@yourdomain.com
action    = %(action_mwl)s

action_mwl = prohibición + correo electrónico con whois + líneas de registro, para que obtengas contexto sobre quién está atacando.

Defensa por capas

Fail2ban gestiona la capa de aplicación, pero los ataques volumétricos (alguien lanzando 50 Gbit/s a tu página de inicio de sesión) necesitan defensa a nivel de red. En Hostfory, el DDoS scrubbing absorbe la capa volumétrica antes de que llegue a tu servidor, y Fail2ban se encarga de los ataques de fuerza bruta inteligentes y de bajo volumen que se cuelan. Usa ambos.

Solución de problemas

Fail2ban no prohíbe a nadie: tu failregex no coincide con las líneas de registro. Pruébalo: fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/whmcs.conf. Muestra cuántas líneas coincidieron.

Fail2ban prohibió mi CDN / toda mi base de usuarios: el problema de la IP real del Paso 6. Estás leyendo la IP del proxy. Soluciona la restauración de la IP real antes de volver a habilitarlo.

Te has quedado fuera: si tienes acceso a la consola/IPMI (incluido en todos los servidores dedicados de Hostfory), accede por esa vía y añade tu IP a ignoreip. Por eso IPMI es importante.

Próximos pasos

Combina esto con un túnel de gestión WireGuard para que SSH ni siquiera esté expuesto públicamente, y restringe la ruta de administración de WHMCS a la IP de tu oficina a nivel de nginx. La defensa en profundidad supera cualquier control único.