Caso real de control contra escaneos maliciosos y mejora de rendimiento en nuestro servidor

Un caso real de optimización de seguridad en infraestructura con CyberPanel, OpenLiteSpeed y Cloudflare

Actualizado el 1 de noviembre de 2026.

Resumen rápido

  • Problema: bots de escaneo que pedían .env, .git, phpinfo.php y similares degradaban la velocidad de varios sitios, aunque todo devolviera 404.
  • Solución: defensa en profundidad con tres capas (limitación por cliente en OpenLiteSpeed, Fail2Ban con un filtro dirigido y reglas en Cloudflare), más un paso previo obligatorio: registrar la IP real del visitante.
  • Resultado: el tiempo de carga bajó de 3.2 s a 0.8 s y el uso de CPU de 65% a 25% (ver métricas).
  • Versiones de referencia (noviembre de 2026): OpenLiteSpeed 1.9.4, CyberPanel 3.0.8 y Fail2Ban 1.1.1.

Introducción

En nuestra empresa de hosting, hospedamos clientes en múltiples servidores distribuidos en diferentes ubicaciones. Durante las últimas semanas, comenzamos a notar una degradación significativa en la velocidad de respuesta de varios sitios web, especialmente durante horas pico.

Los clientes reportaban tiempos de carga lentos, y nuestro equipo de monitoreo detectó picos inusuales en el uso de recursos del servidor. Al investigar a fondo, descubrimos que la causa raíz no era falta de capacidad, sino ataques automatizados de escaneo que estaban consumiendo recursos valiosos.

En este artículo compartimos el proceso completo de diagnóstico y las soluciones que implementamos. También incluimos las correcciones y los aprendizajes que añadimos después, porque varias de las configuraciones que se ven en foros y tutoriales tienen trampas importantes.

El Problema: Escaneos Automatizados en Nuestros Logs

Al revisar los archivos de acceso de OpenLiteSpeed, encontramos patrones preocupantes. Una misma dirección IP estaba realizando cientos de solicitudes por minuto a archivos y directorios que no existían en nuestros servidores.

Estos son ejemplos reales de los logs que encontramos:

185.177.72.49 - - [16/Mar/2026:22:49:21 +0000] "GET /token.php HTTP/1.1" 404 711 "-" "curl/8.7.1"

185.177.72.49 - - [16/Mar/2026:22:49:21 +0000] "GET /tools/.env HTTP/1.1" 404 711 "-" "curl/8.7.1"

185.177.72.49 - - [16/Mar/2026:22:49:22 +0000] "GET /vendor/.env HTTP/1.1" 404 711 "-" "curl/8.7.1"

185.177.72.49 - - [16/Mar/2026:22:49:23 +0000] "GET /v1/admin/ HTTP/1.1" 404 711 "-" "curl/8.7.1"

¿Qué Estaba Pasando?

Un bot automatizado estaba escaneando nuestro servidor en busca de archivos sensibles como:

  • Archivos .env (que contienen credenciales y configuraciones)
  • Repositorios y credenciales expuestas: .git/, .aws/credentials, claves SSH
  • Archivos phpinfo.php (que revelan información del servidor)
  • Archivos de configuración como wp-config.php, config.php
  • Directorios de sistemas populares (Laravel, Vue, WordPress, etc.)

Por qué esto es más que ruido: el contexto de 2026

Este tipo de escaneo no es un fenómeno aislado, y quienes lo hacen buscan credenciales reales:

  • En agosto de 2026, GreyNoise reportó que escáneres distribuidos en 824 direcciones IP falsificaban los nombres de 13 rastreadores de IA (GPTBot, ClaudeBot y otros) para pedir archivos .env, claves de nube y claves privadas. Ninguno de ellos solicitó nunca /robots.txt. Las rutas más pedidas fueron /.env, /app/.env, /api/.env, /.env.local, /.env.production y /.aws/credentials.
  • Cisco Talos documentó la campaña UAT-10608, que comprometió al menos 766 hosts con aplicaciones Next.js vulnerables a React2Shell (CVE-2025-55182) y recolectó credenciales de bases de datos, claves SSH y tokens de nube.
  • El informe de The DFIR Report sobre el “Bissa Scanner” (abril de 2026) encontró más de 30,000 nombres de archivo .env distintos exfiltrados de víctimas en solo doce días.

Un archivo .env expuesto es una vía de entrada a toda la infraestructura de un cliente con una sola petición. Por eso conviene bloquear estos escaneos aunque cada solicitud devuelva 404.

Por qué un 404 no es gratis

Aunque todos los requests retornaban error 404 (archivo no encontrado), cada solicitud consumía:

  • Ciclos de CPU
  • Memoria RAM
  • Conexiones simultáneas del servidor web
  • Ancho de banda

El costo se dispara en sitios con CMS. En WordPress y otros frameworks con URLs amigables, una ruta inexistente suele reescribirse a index.php. Cada escaneo termina entonces ejecutando PHP y consultas a la base de datos, no solo una respuesta estática. Cuando miles de estas solicitudes llegan cada hora, el impacto es significativo, sobre todo en servidores con múltiples clientes hospedados.

Cómo diagnosticarlo en tu servidor

Antes de cambiar nada, identifica a los principales emisores de 404 con este comando (formato de log combinado: el campo 1 es la IP y el campo 9 el código de estado):

sudo awk '$9 == 404 {print $1}' /usr/local/lsws/logs/access.log \
  | sort | uniq -c | sort -rn | head -20

Para ver qué rutas sensibles piden:

sudo grep -E '"(GET|POST|HEAD) [^"]*(\.env|\.git/|\.aws|phpinfo|wp-config)' \
  /usr/local/lsws/logs/access.log | tail -50

CyberPanel también genera un log por sitio, normalmente en /home/<dominio>/logs/. Verifica las rutas exactas en tu instalación.

Paso 0 (obligatorio): Registrar la IP real si usas Cloudflare

Este es el error más común y más costoso al combinar Fail2Ban con Cloudflare. Con el proxy activado (nube naranja), tu servidor ve como origen de la conexión la IP de Cloudflare, no la del visitante. Hay dos consecuencias:

  • Si el log registra IPs de Cloudflare, Fail2Ban acabará baneando a Cloudflare y cortará el acceso a todos los visitantes que pasen por ese centro de datos.
  • Aunque el log muestre la IP real, un bloqueo en el firewall local no detiene al atacante, porque sus paquetes terminan en Cloudflare y nunca llegan directamente a tu servidor.

Configuración en OpenLiteSpeed

  1. En la consola WebAdmin ve a Server Configuration → General Settings y establece Use Client IP in Header en Trusted IP Only.
  2. En Access Control → Allowed List agrega los rangos oficiales de Cloudflare (cloudflare.com/ips) con el sufijo T (trusted), por ejemplo: ALL, 192.0.2.0/24T (usa los rangos reales de Cloudflare, no este ejemplo).

No uses la opción Yes. Permite que cualquier cliente falsifique su IP con la cabecera X-Forwarded-For. Ten en cuenta también que solo el access log muestra la IP real; el error log sigue mostrando las IPs de Cloudflare.

Si tu configuración usa deny ALL en el control de acceso, el modo Trusted IP Only puede provocar errores 403, porque OLS evalúa la regla contra la IP real. En ese caso, una alternativa es dejar la opción en No y registrar CF-Connecting-IP directamente en el formato del access log. Prueba siempre en un sitio no crítico primero.

Mantén tu stack actualizado

Revisa tus versiones antes de endurecer nada más. Estas eran las vigentes en noviembre de 2026:

Componente Versión actual Por qué importa
OpenLiteSpeed 1.9.4 (26 oct 2026) Desactiva WebAdmin por defecto, actualiza el binario PHP del administrador y la librería Brotli por vulnerabilidades, y elimina server push a favor de 103 Early Hints. Las versiones 1.9.x anteriores añadieron endurecimiento de HTTP/2 y HTTP/3 y corrigieron una vulnerabilidad de request smuggling en HTTP/2.
CyberPanel 3.0.8 (18 oct 2026) La 3.0.5 corrigió un bypass de la autenticación de dos factores en la API (CVE-2026-88895, severidad alta). Antes de la 3.0.0 existía un secreto JWT fijo en el servicio WebTerminal (puerto 8888) que permitía obtener una shell de root sin credenciales (CVE-2026-67614, severidad crítica).
Fail2Ban 1.1.1 (15 ago 2026) Ubuntu 24.04 LTS incluye el paquete 1.0.2 con parches de seguridad; la 1.1.x requiere instalación desde el código fuente en esa versión de Ubuntu.

Además, no expongas públicamente los puertos de administración (WebAdmin de OLS en 7080, CyberPanel en 8090, WebTerminal en 8888). Restríngelos por firewall a tus IPs de administración y activa 2FA en todas las cuentas del panel.

La Solución: Tres Capas de Protección

Decidimos implementar una estrategia de defensa en profundidad con tres capas de seguridad complementarias.

Capa 1: Limitación por Cliente (Per-Client Throttling) en OpenLiteSpeed

La primera línea de defensa fue configurar el propio servidor web para limitar las solicitudes y conexiones simultáneas que una misma IP puede generar. OpenLiteSpeed incluye esta función de forma nativa.

Dónde se configura

Accede a la consola WebAdmin de OpenLiteSpeed (puerto 7080) y ve a Server Configuration → Security → Per Client Throttling. Desde OpenLiteSpeed 1.9.4, WebAdmin viene desactivado por defecto, así que actívalo solo mientras lo necesites. Los límites también pueden definirse a nivel de Virtual Host, donde sustituyen a los del servidor.

Valores de partida

Parámetro Valor por defecto Valor de partida sugerido
Static Requests/Second 0 (sin límite) 50
Dynamic Requests/Second 0 (sin límite) 5
Connection Soft Limit 10000 10
Connection Hard Limit 10000 30
Block Bad Request No definido Yes
Grace Period (sec) 15 15
Banned Period (sec) 300 300

Los valores sugeridos son un punto de partida que ajustamos según el tráfico de cada servidor. Se apoyan en los rangos de la documentación de LiteSpeed (soft limit recomendado entre 5 y 10, hard limit entre 20 y 50). Si tu sitio carga muchos recursos en paralelo, súbelos gradualmente en lugar de arriesgarte a afectar a visitantes legítimos.

En el archivo httpd_config.conf, el bloque equivalente es:

perClientConnLimit {
  staticReqPerSec  50
  dynReqPerSec     5
  outBandwidth     0
  inBandwidth      0
  softLimit        10
  hardLimit        30
  gracePeriod      15
  banPeriod        300
}

Cómo funcionan los límites

  • Static / Dynamic Requests/Second: cuando una IP supera el límite, sus solicitudes quedan retenidas (“tar-pitted”) hasta el siguiente segundo, en lugar de rechazarse. Los límites de contenido estático y dinámico son independientes.
  • Hard Limit: máximo absoluto de conexiones simultáneas por IP. Al alcanzarlo, el servidor cierra de inmediato las nuevas conexiones de esa IP.
  • Soft Limit + Grace Period + Banned Period: una IP que permanece por encima del soft limit durante el período de gracia queda bloqueada durante el período de baneo.
  • IPs de confianza: las IPs marcadas con el sufijo T en la Allowed List no están sujetas a estos límites. Añade así tus IPs de monitoreo y administración.

Limitación importante: como las IPs de Cloudflare se tratan como confiables, estos límites protegen sobre todo el tráfico que llega directamente a tu origen. Para el tráfico proxificado, el control de tasa debe aplicarse en Cloudflare (Capa 3).

Resultado

Esta configuración redujo la carga en el servidor, ya que los bots no podían mantener cientos de conexiones paralelas desde una misma IP.

Capa 2: Fail2Ban con un Filtro Dirigido a Escaneos

La segunda capa fue implementar Fail2Ban, una herramienta que monitorea los logs y bloquea automáticamente las IPs que muestran comportamiento malicioso.

Un cambio de enfoque: no baneamos “todos los 404”

Nuestra primera versión del filtro baneaba cualquier IP con 5 errores 404 en 120 segundos. Funciona, pero tiene un riesgo real: un visitante legítimo con una imagen rota, un bot de buscador que sigue enlaces antiguos o un sitio recién migrado generan 404 en ráfagas. La versión actual detecta rutas que ningún usuario legítimo solicita (.env, .git, phpinfo, etc.), lo que reduce drásticamente los falsos positivos. Si aun así quieres un jail genérico de 404, usa un umbral mucho más alto (por ejemplo, 100 en 60 segundos).

Paso 1: Instalación de Fail2Ban

En cada servidor Ubuntu, ejecutamos:

sudo apt update
sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
fail2ban-client --version

Ubuntu 24.04 LTS incluye Fail2Ban 1.0.2. Si ves el error No module named 'asynchat', actualiza el paquete (sudo apt install --only-upgrade fail2ban), porque la versión corregida está en noble-updates. En Ubuntu 24.04 la acción de bloqueo predeterminada ya es nftables, no iptables.

Paso 2: Creación del Filtro Personalizado

sudo nano /etc/fail2ban/filter.d/cyberpanel-scan.conf

Contenido del filtro (formato de log combinado de OpenLiteSpeed):

[Definition]
failregex = ^<HOST> \S+ \S+ \[[^\]]+\] "(?:GET|POST|HEAD) \S*(?:/\.env|/\.git/|/\.aws/|/\.ssh/|/\.DS_Store|phpinfo|/wp-config|/vendor/phpunit|/config\.php)\S* HTTP/[\d.]+" (?:400|403|404|405)\s
ignoreregex =

Probamos esta lógica con las líneas de ejemplo de este artículo: detecta /tools/.env y /vendor/.env, y no coincide con rutas legítimas como /.well-known/acme-challenge/ (renovación SSL) ni con un 404 de imagen común. Valida siempre el filtro en tus propios logs antes de activarlo:

sudo fail2ban-regex /usr/local/lsws/logs/access.log /etc/fail2ban/filter.d/cyberpanel-scan.conf

Paso 3: Configuración del Jail

Configuramos el jail en /etc/fail2ban/jail.local:

[DEFAULT]
# Tus IPs legítimas y, por seguridad, los rangos de Cloudflare
ignoreip = 127.0.0.1/8 ::1 [NUESTRAS_IPS_LEGITIMAS]

[cyberpanel-scan]
enabled  = true
backend  = auto
filter   = cyberpanel-scan
logpath  = /usr/local/lsws/logs/access.log
           /home/*/logs/*.access_log
port     = http,https
maxretry = 3
findtime = 10m
bantime  = 1d
bantime.increment = true
bantime.factor    = 2

Explicación de los Parámetros

  • maxretry = 3: con rutas tan específicas, tres intentos bastan para considerar a una IP un escáner.
  • findtime = 10m: los intentos deben ocurrir dentro de 10 minutos.
  • bantime = 1d con incremento: la primera vez se bloquea un día, y los reincidentes reciben bloqueos cada vez más largos.
  • backend = auto: imprescindible en Ubuntu 24.04. Ese sistema define backend = systemd en [DEFAULT], y un jail basado en archivos lo ignoraría silenciosamente: se inicia sin errores pero nunca banea a nadie.
  • ignoreip: tus IPs nunca serán baneadas. Añade también los rangos de Cloudflare como red de seguridad.
  • Acción de bloqueo: la acción predeterminada de tu distribución (nftables en Ubuntu 24.04 y 26.04) se aplica automáticamente. Ya no hace falta forzar iptables-multiport.

Paso 4: Si usas Cloudflare, banea en el borde

Con el proxy de Cloudflare activo, un bloqueo local no detiene al atacante. Fail2Ban incluye la acción cloudflare-token, que crea una regla de bloqueo en las IP Access Rules de Cloudflare y la elimina cuando expira el baneo. Crea un token de API limitado a una zona con el permiso Zone → Firewall Services → Edit y guarda las credenciales en un archivo de acción protegido:

# /etc/fail2ban/action.d/cloudflare-token.local
[Init]
cfzone  = TU_ZONE_ID
cftoken = TU_API_TOKEN

sudo chmod 640 /etc/fail2ban/action.d/cloudflare-token.local

Luego añade la acción al jail (conservando el bloqueo local para quien llegue directo a tu IP de origen):

[cyberpanel-scan]
...
action = %(action_)s
         cloudflare-token

Cloudflare permite hasta 50,000 IP Access Rules por cuenta en todos los planes, así que vigila el contador si usas bloqueos largos en servidores muy atacados. Una zona por jail implica un token por dominio; si gestionas muchos clientes, valora un token a nivel de cuenta.

Paso 5: Activación y Monitoreo

sudo fail2ban-client reload
sudo fail2ban-client status
sudo fail2ban-client status cyberpanel-scan
sudo tail -f /var/log/fail2ban.log

Para probar el flujo completo sin esperar a un atacante: sudo fail2ban-client set cyberpanel-scan banip 192.0.2.15, y luego unbanip con la misma IP.

Resultado

En las primeras 24 horas, Fail2Ban bloqueó automáticamente más de 200 IPs maliciosas, reduciendo drásticamente el ruido en nuestros logs y liberando recursos del servidor.

Capa 3: Reglas de Cloudflare WAF

La tercera capa fue implementar reglas en el Web Application Firewall (WAF) de Cloudflare, que actúa antes de que el tráfico llegue a tu servidor.

Límites del plan gratuito (vigentes en noviembre de 2026)

  • Reglas personalizadas: 5 (Pro: 20, Business: 100, Enterprise: 1,000). La compatibilidad con regex no está disponible en el plan gratuito.
  • Reglas de rate limiting: 1, con periodo de conteo y de mitigación de 10 segundos, y solo los campos Path y Verified Bot en la expresión.
  • Bloqueo por país: la función de IP Access Rules para bloquear por país es solo Enterprise. En los demás planes se hace con reglas personalizadas (que es además lo que Cloudflare recomienda).

Regla 1: Bloquear (o desafiar) tráfico de países sin público objetivo

Al analizar los logs, notamos que una gran parte del tráfico malicioso provenía de rangos de IP chinos, y dado que nuestros clientes no tenían público objetivo en China, decidimos actuar. En el dashboard ve a Security → Security rules → Create rule → Custom rules:

  • Nombre: Bloquear tráfico China
  • Campo: Country (ip.src.country; el campo anterior ip.geoip.country está obsoleto)
  • Operador: equals / is in
  • Valor: China (CN)
  • Acción: Managed Challenge al principio y Block cuando hayas validado el impacto

Expresión equivalente: (ip.src.country eq "CN").

Cómo validarla: la acción Log solo existe en Enterprise. En los demás planes, empieza con Managed Challenge, revisa las solicitudes en Security Events y pasa a Block cuando confirmes que no hay falsos positivos.

Excepciones para tráfico legítimo

Las reglas se evalúan en orden, así que coloca primero una regla con acción Skip para:

  • IPs de socios en Asia (usa una lista de IPs en lugar de repetirlas en la expresión)
  • APIs específicas que requieren acceso global (por ejemplo, por ruta)
  • Webhooks de pasarelas de pago o servicios que gestiones

Ten presente que Cloudflare no sabe si un usuario está autenticado en tu aplicación, así que “excepción para usuarios logueados” solo es viable si identificas esa sesión de forma fiable (por ejemplo, con una cookie, sabiendo que es una señal manipulable).

Regla 2: Bloquear en el borde las rutas de escaneo más comunes

Es la regla de mayor rendimiento: elimina el escaneo antes de que consuma un solo recurso del origen. Funciona en el plan gratuito porque usa contains en lugar de regex:

(http.request.uri.path contains "/.env") or
(http.request.uri.path contains "/.git/") or
(http.request.uri.path contains "/.aws/") or
(http.request.uri.path contains "/.ssh/") or
(http.request.uri.path contains "phpinfo") or
(http.request.uri.path contains "/wp-config") or
(http.request.uri.path contains "/vendor/phpunit")

Acción: Block. Esta regla complementa a Fail2Ban: la regla del borde frena el 100% de esos intentos, mientras que Fail2Ban bloquea a la IP completa tras tres. Las rutas /.well-known/ necesarias para la renovación de SSL no coinciden con estos patrones.

Regla 3: Rate limiting en rutas sensibles

El plan gratuito permite una regla de rate limiting. Una buena candidata es el inicio de sesión de WordPress:

  • Expresión: (http.request.uri.path eq "/wp-login.php")
  • Conteo: por IP, 5 solicitudes en 10 segundos
  • Acción: Block (mitigación de 10 segundos en el plan gratuito)

Cloudflare advierte que el rate limiting no está diseñado para permitir un número exacto de solicitudes al origen, y puede pasar un pequeño exceso antes de aplicarse la mitigación.

Refuerzo: aceptar tráfico solo desde Cloudflare

Si el firewall de tu origen acepta conexiones de cualquier IP, un atacante que descubra la IP real del servidor puede saltarse el WAF. Cloudflare recomienda aceptar tráfico de las IPs publicadas por Cloudflare y bloquear el resto en los puertos 80 y 443 (mantén un procedimiento para actualizar la lista de rangos).

Resultado

Esta capa bloqueó aproximadamente el 40% del tráfico malicioso antes de que llegara a nuestros servidores, reduciendo aún más la carga en nuestra infraestructura.

Limitaciones del bloqueo geográfico

Bloquear por país es una herramienta tosca. Los escáneres modernos rotan de infraestructura constantemente: los informes de 2026 describen campañas que usan cientos de IPs, incluidas direcciones de proveedores de nube occidentales, que cambian cada día. Por eso el filtro por comportamiento (rutas sensibles, tasa de peticiones) tiene más valor a largo plazo que el filtro por país. Usa el bloqueo geográfico como complemento, no como defensa principal.

Resultados Obtenidos

Después de implementar las tres capas de protección, medimos los siguientes resultados en nuestra infraestructura:

Métricas de Rendimiento

Métrica Antes Después Mejora
Tiempo de carga promedio 3.2 segundos 0.8 segundos 75%
Requests 404 por hora 15,000+ menos de 200 98%
Uso de CPU promedio 65% 25% 62%
Conexiones simultáneas 450 120 73%

Estas cifras son promedios de nuestros servidores y dependen del número de sitios, el tipo de CMS y el volumen de ataque. Mide tu propia línea base antes de aplicar cambios para poder comparar.

Beneficios para Nuestros Clientes

  • Velocidad de carga significativamente mejor
  • Menos tiempos de inactividad
  • Mejor experiencia de usuario y mejores Core Web Vitals: Google usa señales de experiencia de página, y un servidor más rápido mejora el tiempo de respuesta inicial (TTFB), que influye directamente en métricas como LCP
  • Mayor seguridad para sus datos, al impedir que bots localicen archivos sensibles expuestos

Errores Comunes que Evitamos (y que Debes Evitar)

  • Dejar que Fail2Ban banee IPs de Cloudflare: verifica que tus logs muestren IPs de visitantes antes de activar ningún jail (Paso 0).
  • Confiar en el bloqueo local con tráfico proxificado: sin una acción en el borde, el atacante sigue llegando por Cloudflare.
  • Usar Use Client IP in Header = Yes: permite falsificar IPs con X-Forwarded-For.
  • Baneo genérico por 404: penaliza a usuarios y bots legítimos. Apunta a rutas que nadie legítimo solicita.
  • Jail que no banea nunca: en Ubuntu 24.04 olvidar backend = auto hace que Fail2Ban ignore tus archivos de log sin mostrar errores.
  • Olvidar ignoreip: acabarás baneando tu propia IP, tu monitoreo o la renovación de SSL.
  • Bloquear un país entero sin un periodo de prueba: empieza con Managed Challenge.
  • Dejar el panel expuesto: con las vulnerabilidades críticas publicadas en CyberPanel en 2026, un panel desactualizado y público es un riesgo mayor que cualquier escáner de .env.
  • Confiar en el nombre del User-Agent: los escáneres de 2026 se hacen pasar por GPTBot, ClaudeBot y otros. Para verificar un rastreador legítimo, comprueba su IP contra los rangos que publica su empresa.

Lecciones Aprendidas

1. El Monitoreo Proactivo es Esencial

No esperes a que los clientes se quejen. Implementa sistemas de monitoreo que te alerten sobre anomalías en el rendimiento antes de que se conviertan en problemas críticos. Una alerta sencilla sobre el número de 404 por minuto habría detectado este problema semanas antes.

2. La Defensa en Profundidad Funciona

Ninguna solución por sí sola es suficiente. La combinación de OpenLiteSpeed + Fail2Ban + Cloudflare WAF creó una barrera efectiva que ninguna capa individual podría haber logrado. Cada capa cubre los puntos ciegos de la anterior.

3. Los Logs Son Tu Mejor Amigo, si Registran la IP Correcta

Invierte tiempo en aprender a leer y analizar los logs de tu servidor. Antes de automatizar nada, asegúrate de que los logs reflejan la realidad: un log con IPs de proxy convierte cualquier automatización en un riesgo.

4. Automatiza Siempre Que Sea Posible, con Salvaguardas

Fail2Ban nos ahorró cientos de horas de trabajo manual. En lugar de banear IPs una por una, el sistema lo hace automáticamente 24/7. Eso sí: automatiza con ignoreip, bloqueos progresivos y validación previa de filtros.

5. Mantén Todo Actualizado

Los escáneres buscan configuraciones expuestas, pero los atacantes más peligrosos explotan vulnerabilidades conocidas. Actualizar CyberPanel y OpenLiteSpeed con regularidad, y reducir la exposición de los paneles, es tan importante como cualquier regla de bloqueo.

Recomendaciones para Otros Administradores

Si estás experimentando problemas similares, te recomendamos seguir estos pasos:

  1. Analiza tus logs para identificar patrones de tráfico malicioso (comandos de diagnóstico arriba).
  2. Configura la IP real del visitante si usas Cloudflare, antes de activar cualquier baneo automático.
  3. Actualiza OpenLiteSpeed y CyberPanel, activa 2FA y restringe los puertos de administración.
  4. Configura Per Client Throttling en OpenLiteSpeed con valores conservadores y ajústalos con datos.
  5. Implementa Fail2Ban con un filtro dirigido a rutas de escaneo y, si usas Cloudflare, con la acción cloudflare-token.
  6. Usa Cloudflare (el plan gratuito es suficiente para empezar): bloquea rutas sensibles en el borde, usa Managed Challenge antes de Block y limita tu origen a las IPs de Cloudflare.
  7. Revisa periódicamente (por ejemplo, cada mes): los rangos de IP de Cloudflare, los baneos activos, los falsos positivos y las versiones de software.

Conclusión

La degradación de rendimiento que experimentamos no fue causada por falta de recursos, sino por tráfico malicioso que consumía nuestros servidores. Al implementar estas tres capas de protección, no solo resolvimos el problema, sino que mejoramos significativamente la experiencia de todos nuestros clientes y reducimos el riesgo de que un archivo sensible expuesto acabe en manos equivocadas.

La seguridad y el rendimiento van de la mano. Un servidor protegido es un servidor rápido, siempre que sus defensas estén bien configuradas y se mantengan actualizadas.

¿Tienes preguntas sobre alguna de estas configuraciones? Déjanos un comentario y con gusto te ayudaremos.

Fuentes y Documentación Oficial

Nota: Este artículo se basa en una implementación real en nuestra infraestructura de hosting. Los valores de configuración, las rutas de logs y las métricas pueden variar según tu caso específico. Los límites de planes y las versiones de software cambian con frecuencia: verifícalos en la documentación oficial antes de aplicar cambios. Siempre prueba en un entorno de staging antes de aplicar cambios en producción.