ModSecurity y el OWASP Core Rule Set en cPanel: guía práctica de WAF

Un firewall de aplicaciones web (WAF) inspecciona cada solicitud HTTP antes de que llegue a WordPress, a un carrito de compras o a una aplicación PHP a la medida, y bloquea las que parecen ataques. En un servidor cPanel, la opción integrada es ModSecurity con el OWASP Core Rule Set (CRS): instale el módulo de Apache en EasyApache 4, agregue el paquete actual del CRS, manténgalo activo en todos los dominios, revise la Hits List para detectar falsos positivos y corríjalos con excepciones precisas por dominio, en lugar de apagar el firewall. Esta guía recorre cada paso con las interfaces actuales de cPanel.

Qué hacen realmente ModSecurity y el CRS

ModSecurity es el motor: un módulo de Apache que puede leer solicitudes y respuestas y actuar según reglas. Por sí solo no hace nada útil. El OWASP Core Rule Set es el conjunto de reglas gratuito, mantenido por la comunidad, que le da ese conocimiento. Según el proyecto CRS, cubre tipos de ataque como:

• Inyección SQL (SQLi) y cross-site scripting (XSS)
• Inclusión de archivos locales y remotos (LFI/RFI)
• Inyección de código PHP y Java, e inyección de comandos de shell Unix/Windows
• Inyección de plantillas del lado del servidor, Shellshock y HTTPoxy
• Fijación de sesión
• Detección de escáneres y bots
• Fugas de metadatos y errores en las respuestas

Lo que no hará

Un WAF es una red de seguridad, no un parche. No corrige un plugin desactualizado, no detiene a quien inicia sesión con una contraseña robada y no limpia malware que ya está en el servidor. Mantenga las aplicaciones al día, use 2FA y conserve copias de seguridad; el WAF le da tiempo y bloquea la mayor parte del sondeo automatizado.

Cómo decide el CRS qué bloquear

El CRS usa puntuación de anomalías (anomaly scoring). Cada regla que coincide suma puntos a la solicitud, y esta se bloquea solo cuando el total supera un umbral. Así, una señal débil aislada pasa, mientras que una solicitud con varios rasgos sospechosos se detiene.

Paso 1: Instale ModSecurity y el conjunto de reglas

1. En WHM » Software » EasyApache 4, personalice su perfil y confirme que el módulo de Apache mod_security2 esté instalado.
2. En el mismo perfil de EasyApache 4, vaya a Additional Packages e instale ea-modsec2-rules-owasp-crs. La documentación de cPanel describe este paquete como el conjunto de reglas más reciente, que recibe actualizaciones frecuentes.
3. Abra WHM » Security Center » ModSecurity Vendors. Si todavía ve instalado el proveedor anterior OWASP ModSecurity Core Rule Set V3.0, tenga en cuenta que cPanel indica que ya no se actualiza; planifique el cambio al paquete.
4. Verifique que Updates esté activado para el conjunto de reglas que usa, de modo que las versiones nuevas se instalen durante la actualización regular de cPanel.

Revise la configuración del motor

En WHM » Security Center » ModSecurity Configuration, revise dos opciones:

• Rules Engine: procesar las reglas (bloqueo), no procesarlas, o procesarlas sin ejecutar acciones disruptivas. Esta última es un modo de solo detección, útil para una prueba corta en un servidor con mucho tráfico.
• Audit Log Level: cPanel recomienda registrar solo las transacciones relevantes. Registrarlo todo puede capturar datos privados y llenar los discos rápidamente.

Paso 2: Elija un nivel de paranoia

El CRS tiene cuatro niveles de paranoia (PL), que se definen en crs-setup.conf. Los niveles más altos agregan más reglas y detectan más ataques, pero también marcan más tráfico legítimo.

Nivel	Descripción del proyecto CRS	Uso típico
PL 1	Seguridad básica con mínima necesidad de ajustar falsos positivos	Cualquier sitio público; el punto de partida correcto para la mayoría de las empresas
PL 2	Adecuado cuando hay datos reales de usuarios	Tiendas en línea, portales de clientes
PL 3	Nivel de banca en línea, con muchos falsos positivos	Aplicaciones de alto valor con alguien que las ajuste
PL 4	Bajo su propio riesgo; espere muchos falsos positivos	Rara vez apropiado en hosting compartido

Empiece en PL 1. La documentación del CRS desaconseja usar un nivel alto en modo de bloqueo sin un ajuste adecuado.

Paso 3: Encuentre los falsos positivos

Un falso positivo es una solicitud legítima con la que una regla del CRS coincide por error; por ejemplo, un editor que guarda una entrada de blog con HTML o un campo de formulario que parece SQL. Los síntomas típicos son una página 403 Forbidden al guardar contenido en WordPress, cargas de archivos que fallan o un aviso de pago rechazado.

Para rastrearlo:

1. Abra WHM » Security Center » ModSecurity Tools. La Hits List muestra los eventos recientes con el ID de la regla, el host y la solicitud.
2. Busque la hora y la URL que reportó el usuario. Anote el Rule ID (por ejemplo, una regla 941xxx pertenece a la familia XSS y una 942xxx a inyección SQL).
3. Revise el registro de errores de Apache para ver el mensaje completo si necesita el argumento exacto que coincidió.

Paso 4: Corríjalo con precisión, por dominio

La peor solución es la más común: apagar ModSecurity para todo el dominio. La propia documentación de cPanel recomienda enfáticamente mantener ModSecurity activo en todos los dominios y desactivarlo solo mientras se diagnostica un problema. El CRS agrega que nunca se deben editar sus archivos de reglas directamente, porque las actualizaciones sobrescriben los cambios; use excepciones.

Opción A: Quitar una regla en un solo dominio

cPanel permite agregar directivas de Apache a un único host virtual mediante archivos include:

• /etc/apache2/conf.d/userdata/ssl/2_4/<usuario>/<dominio>/modsec.conf para HTTPS
• /etc/apache2/conf.d/userdata/std/2_4/<usuario>/<dominio>/modsec.conf para HTTP

Dentro, envuelva la excepción para que Apache arranque aunque falte el módulo:

<IfModule mod_security2.c>
  SecRuleRemoveById 941160
</IfModule>

Luego ejecute /usr/local/cpanel/scripts/rebuildhttpdconf y /usr/local/cpanel/scripts/restartsrv_httpd. La regla sigue activa para todos los demás sitios del servidor.

Opción B: Excluir un campo, no toda la regla

Mejor aún, conserve la regla y evite solo que inspeccione el campo que causa el problema. El CRS documenta SecRuleUpdateTargetById para esto; por ejemplo, para excluir un único argumento de formulario de una regla XSS. También puede limitar una excepción a una ruta, como una URL de administración, con un bloque <LocationMatch> en el mismo archivo include.

Opción C: Cambios para todo el servidor

Si una regla del proveedor falla en todos los sitios, puede desactivarla desde la Hits List haciendo clic en el ID de la regla, o agregar reglas propias en ModSecurity Tools » Rules List y hacer clic en Deploy and Restart Apache. Úselo con moderación: una regla quitada en todo el servidor se quita para todos los clientes.

Use las excepciones de aplicaciones del CRS

El proyecto CRS ofrece excepciones de reglas ya preparadas para aplicaciones populares como WordPress y Drupal (empaquetadas como plugins en CRS v4). Revise si existe una para su aplicación antes de escribir las suyas.

Paso 5: Deje que los dueños de sitios ayuden, con cuidado

Con la función ModSecurity Domain Manager activada en WHM » Packages » Feature Manager, los usuarios de cPanel pueden encender o apagar ModSecurity por dominio en cPanel » Security » ModSecurity. Es práctico para diagnosticar, pero también significa que un usuario frustrado puede dejar un sitio sin protección. Revise esa configuración periódicamente o reserve la función para los administradores.

Una rutina breve de mantenimiento

1. Cada semana: revise la Hits List en busca de coincidencias repetidas en la misma URL legítima.
2. Después de cada actualización de la aplicación: pruebe inicios de sesión, formularios, cargas de archivos y el proceso de pago.
3. Cada mes: confirme que las actualizaciones del conjunto de reglas se siguen instalando.
4. Lleve un registro breve de cada excepción, su motivo y la fecha, para que el próximo administrador sepa por qué existe.

¿Quiere que lo ajustemos para sus sitios?

Un WAF que bloquea a sus propios clientes termina apagado; uno bien ajustado se queda activo y detiene ataques sin hacer ruido. Max, nuestro fundador, está certificado en cPanel & WHM, y nuestro equipo configura y ajusta ModSecurity para empresas de Miami-Dade y todo el sur de Florida. Solicite una evaluación de TI gratuita y revisaremos con usted la protección web de su servidor.

Fuentes

• ModSecurity Vendors – cPanel & WHM Documentation
• ModSecurity Tools – cPanel & WHM Documentation
• ModSecurity for cPanel – cPanel & WHM Documentation
• Modify Apache Virtual Hosts with Include Files – cPanel Documentation
• OWASP CRS: False Positives and Tuning
• OWASP CRS: Paranoia Levels
• OWASP CRS Project