Un caso real de optimización de seguridad en infraestructura con CyberPanel, OpenLiteSpeed y Cloudflare
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 tres soluciones que implementamos para resolver el problema de manera definitiva.
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) - 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.)
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
Cuando miles de estas solicitudes llegan cada hora, el impacto en el rendimiento es significativo, especialmente en servidores con múltiples clientes hospedados.
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 de Conexiones en OpenLiteSpeed
La primera línea de defensa fue configurar el propio servidor web para limitar la cantidad de conexiones simultáneas que una misma IP puede establecer.
Configuración de Límites para Recursos Estáticos
Accedimos al panel de administración de OpenLiteSpeed (puerto 7080) y navegamos a Server Configuration → Security → Access Control.
Configuramos las siguientes reglas:
- Requests por segundo: 10
- Burst permitido: 20
- Período de bloqueo: 300 segundos
Configuración a Nivel de Virtual Host
Para cada sitio hospedado, agregamos reglas específicas en la configuración del Virtual Host:
connLimit = 50
sslConnLimit = 50
throttle = 10,5
Esto significa que cada IP puede tener máximo 50 conexiones simultáneas, y si excede 10 requests por segundo durante 5 segundos, se throttlean las solicitudes.
Resultado
Esta configuración redujo inmediatamente la carga en el servidor, ya que los bots no podían establecer cientos de conexiones paralelas.
Capa 2: Implementación de Fail2Ban para Bloquear Escaneos 404
La segunda capa de protección fue implementar Fail2Ban, una herramienta que monitorea los logs del servidor y bloquea automáticamente las IPs que muestran comportamiento malicioso.
Paso 1: Instalación de Fail2Ban
En cada servidor Ubuntu, ejecutamos:
sudo apt update
sudo apt install fail2ban -y
sudo systemctl start fail2ban
sudo systemctl enable fail2ban
Paso 2: Creación del Filtro Personalizado
Creamos un archivo de filtro específico para detectar escaneos de archivos inexistentes:
sudo nano /etc/fail2ban/filter.d/cyberpanel-404.conf
Contenido del filtro:
[Definition]
failregex = <HOST> -.*"(GET|POST).*" (404)
ignoreregex =
Paso 3: Configuración del Jail
Configuramos el jail en /etc/fail2ban/jail.local:
[cyberpanel-404]
enabled = true
port = http,https
filter = cyberpanel-404
logpath = /usr/local/lsws/logs/access.log
maxretry = 5
findtime = 120
bantime = 7200
ignoreip = 127.0.0.1/8 ::1 [NUESTRAS_IPS_LEGITIMAS]
action = iptables-multiport[name=cyberpanel-404, port="http,https", protocol=tcp]
Explicación de los Parámetros
- maxretry = 5: Una IP es baneada después de 5 requests 404
- findtime = 120: Los 5 requests deben ocurrir en 120 segundos
- bantime = 7200: La IP permanece bloqueada por 2 horas
- ignoreip: Nuestras IPs nunca serán baneadas
Paso 4: Activación y Monitoreo
Reiniciamos Fail2Ban y verificamos el estado:
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status cyberpanel-404
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: Regla Cloudflare WAF para Tráfico Chino
La tercera capa de protección fue implementar una regla en el Web Application Firewall (WAF) de Cloudflare. 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.
Paso 1: Acceso al Dashboard de Cloudflare
Navegamos a Security → WAF → Custom Rules en el dashboard de Cloudflare.
Paso 2: Creación de la Regla
Configuramos una regla con los siguientes parámetros:
- Nombre: Bloquear tráfico China
- Field: Country
- Operator: equals
- Value: China (CN)
- Action: Block (o Challenge, según el caso)
Paso 3: Excepciones para Tráfico Legítimo
Agregamos excepciones para permitir tráfico chino legítimo en casos específicos:
- IPs de nuestros socios en Asia
- Tráfico autenticado (usuarios logueados)
- APIs específicas que requieren acceso global
Resultado
Esta regla 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.
Resultados Obtenidos
Después de implementar las tres capas de protección, medimos los siguientes resultados:
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+ | 200- | 98% |
| Uso de CPU promedio | 65% | 25% | 62% |
| Conexiones simultáneas | 450 | 120 | 73% |
Beneficios para Nuestros Clientes
- Velocidad de carga significativamente mejor
- Menos tiempos de inactividad
- Mejor posicionamiento SEO (Google considera la velocidad)
- Mayor seguridad para sus datos
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.
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.
3. Los Logs Son Tu Mejor Amigo
Invierte tiempo en aprender a leer y analizar los logs de tu servidor. Contienen información valiosa sobre lo que realmente está pasando en tu infraestructura.
4. Automatiza Siempre Que Sea Posible
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.
Recomendaciones para Otros Administradores
Si estás experimentando problemas similares, te recomendamos seguir estos pasos:
- Analiza tus logs para identificar patrones de tráfico malicioso
- Configura límites de conexión en tu servidor web
- Implementa Fail2Ban para bloqueo automático de IPs
- Usa Cloudflare (el plan gratuito es suficiente para empezar)
- Monitorea regularmente y ajusta las reglas según sea necesario
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.
La seguridad y el rendimiento van de la mano. Un servidor protegido es un servidor rápido.
¿Tienes preguntas sobre alguna de estas configuraciones? Déjanos un comentario y con gusto te ayudaremos.
Nota: Este artículo se basa en una implementación real en nuestra infraestructura de hosting. Los valores de configuración pueden variar según tu caso específico. Siempre prueba en un entorno de staging antes de aplicar cambios en producción.