Saltar al contenido
EdgeServers
Blog

ModSecurity y el OWASP CRS — las reglas WAF que de verdad entregamos en Apache

14 de mayo de 2026 · 2 min de lectura · por Sudhanshu K.

Este es un extracto. El artículo completo está en Medium.

ModSecurity es una de esas herramientas que casi todo el mundo tiene instalada y casi nadie ha afinado. El patrón en auditorías es consistente: el módulo está cargado, el OWASP Core Rule Set está puesto con su configuración por defecto, los logs se llenan de miles de alertas que nadie lee, y o bien (a) lleva años corriendo silenciosamente en DetectionOnly, o bien (b) bloquea tráfico legítimo y el cliente no lo sabe.

Ambos modos significan que el WAF no está haciendo nada útil.

¿Por qué molestarse en 2026 cuando Cloudflare existe?

Tres razones por las que aún desplegamos ModSecurity a nivel de origin detrás de un cloud WAF:

  1. Defensa en profundidad. El cloud WAF es una capa. Cuando clasifica mal, o el cliente no ha activado un pack de reglas, o alguien descubre la IP de origin, la capa interna pilla lo que el edge perdió.
  2. Reglas específicas de la aplicación. Cloudflare no sabe que tu endpoint /admin/export nunca debería ver una palabra clave SELECT. ModSecurity en el origin sí.
  3. Forense. El log de auditoría de ModSecurity te da la petición completa que disparó la regla. Los cloud WAFs dan datos muestreados, con pérdidas.

La configuración base

ModSecurity 3 (libmodsecurity) con el conector de Apache — no el v2 legacy:

<IfModule security2_module>
    SecRuleEngine On
    SecRequestBodyAccess On
    SecRequestBodyLimit 13107200
    SecAuditEngine RelevantOnly
    SecAuditLogParts ABIJDEFHZ
    Include /etc/modsecurity/crs/crs-setup.conf
    Include /etc/modsecurity/crs/rules/*.conf
</IfModule>

Luego el trabajo de tuning real — elegir el paranoia level correcto, hacer allowlist de las reglas que disparan en el tráfico normal de tu aplicación, y escribir las reglas por ruta que Cloudflare no puede. El artículo completo en Medium cubre:

  • Paranoia Level 1 → 4 — qué añade cada uno, y el nivel que entregamos por defecto
  • El workflow de «triage de falsos positivos» que ejecutamos durante dos semanas antes de pasar a modo block
  • Reglas custom para rutas comunes de aplicación (admin, endpoints de API, subidas de archivos)
  • Enviar el log de auditoría al SIEM, y los dashboards que vigilamos
  • Las reglas que siempre desactivamos (y por qué)

Continúa en Medium.