En resumen: ModSecurity es un Web Application Firewall que se ejecuta en el servidor web; el OWASP Core Rule Set (CRS) aporta reglas libremente disponibles contra los tipos de ataque más extendidos. Para Apache, el proyecto CRS recomienda ModSecurity v2; para Nginx se plantean el conector v3 o Coraza. Empiece en modo de bloqueo con umbrales de anomalía muy altos, redúzcalos poco a poco y trate los falsos positivos con excepciones específicas. Una actualización de PHP no se sustituye con esto.
Un WAF propio como capa adicional
Desde PHP2Shell, muchas empresas se preguntan si necesitan un Web Application Firewall. Quien sirve sus sitios web a través de Cloudflare tiene, según Cloudflare, reglas de protección activas automáticamente desde el 21 de octubre de 2026. Quien no lo hace o no quiere desviar el tráfico de datos a través de un tercero puede operar un WAF directamente en su propio servidor.
La combinación más conocida para ello es ModSecurity con el OWASP Core Rule Set. Ambos son de código abierto y gratuitos. El CRS es un conjunto de reglas de detección generales, por ejemplo contra la inyección SQL, el cross-site scripting o la inyección de archivos. El propio proyecto describe su objetivo como una detección general de ataques con el menor número posible de falsos positivos, como un elemento entre varios.
Con ello queda señalado también el límite. Un WAF examina peticiones y respuestas; no repara ninguna vulnerabilidad del intérprete de PHP. Por qué necesita ambas cosas lo describe WAF o actualización: por qué necesita ambos.
Qué motor encaja con su servidor web
El conjunto de reglas necesita un motor que lo ejecute. Según la documentación del CRS, hay tres opciones compatibles:
| Motor | Servidor web | Valoración según el proyecto CRS |
|---|---|---|
| ModSecurity v2 | Apache (módulo) | implementación de referencia, recomendada para Apache |
| ModSecurity v3 (libModSecurity) | sobre todo Nginx mediante conector | solo el conector de Nginx es realmente utilizable en producción; no supera entre el 2 y el 4 por ciento de las pruebas del CRS |
| Coraza | proxies e integraciones basados en Go | supera por completo la suite de pruebas de CRS v4 |
Como contexto: ModSecurity fue desarrollado durante mucho tiempo por Trustwave. Trustwave anunció en 2021 que pondría fin al desarrollo en 2024. El 25 de enero de 2024, el proyecto pasó a la OWASP Foundation. En instalaciones nuevas, compruebe qué versión entrega su distribución y cuán actual es.
Cómo funciona el Core Rule Set
En su configuración por defecto, el CRS no bloquea ante la primera anomalía sospechosa. Trabaja con puntos de anomalía: cada regla activada suma puntos según su gravedad y solo cuando la suma supera un umbral se rechaza la petición.
- Niveles de gravedad: crítico 5 puntos, error 4, advertencia 3, aviso 2.
- Umbral para peticiones:
tx.inbound_anomaly_score_threshold, por defecto 5. - Umbral para respuestas:
tx.outbound_anomaly_score_threshold, por defecto 4. - Niveles de paranoia del 1 al 4 en
crs-setup.conf: el nivel 1 es la protección básica para todo servidor en internet; el nivel 2 encaja, según el proyecto, con aplicaciones con datos reales de usuarios, como tiendas online; los niveles 3 y 4 traen bastantes más falsos positivos.
Un nivel de paranoia más alto detecta más, pero también genera más falsos positivos. Para la mayoría de los sitios web corporativos, el nivel 1 es el inicio y el nivel 2 un objetivo posterior.
Introducir ModSecurity con OWASP CRS sin paralizar el sitio web
Para instalaciones nuevas, el proyecto CRS recomienda activar el modo de bloqueo desde el principio, pero con umbrales muy altos, de hasta 10000, y reducirlos después poco a poco. Así acumula experiencia con accesos reales sin dejar fuera a los usuarios. Los umbrales se fijan en crs-setup.conf:
# crs-setup.conf: fase inicial con umbrales muy altos
SecAction \
"id:900110,\
phase:1,\
pass,\
t:none,\
nolog,\
setvar:tx.inbound_anomaly_score_threshold=10000,\
setvar:tx.outbound_anomaly_score_threshold=10000"
La inclusión en Apache sigue el orden que la documentación del CRS establece para los plugins. Las rutas varían según la distribución:
<IfModule security2_module>
SecRuleEngine On
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/plugins/*-config.conf
Include /etc/modsecurity/crs/plugins/*-before.conf
Include /etc/modsecurity/crs/rules/*.conf
Include /etc/modsecurity/crs/plugins/*-after.conf
</IfModule>
Después analice el registro de auditoría definido en SecAuditLog. Cómo recorrer sistemáticamente los registros lo describe Analizar los logs del servidor web tras un ataque. Reduzca los umbrales por etapas, por ejemplo a lo largo de varias semanas, hasta llegar al valor por defecto.
Tratar los falsos positivos de forma específica
Los falsos positivos son normales, sobre todo en backends de CMS con editores que guardan HTML. La peor reacción es desactivar el WAF. Son mejores dos herramientas.
Primero, los plugins: el proyecto CRS mantiene plugins con reglas de excepción para aplicaciones extendidas, por ejemplo para WordPress. Se copian en la carpeta de plugins y se cargan mediante las líneas Include mostradas arriba. El proyecto mantiene la lista oficial en su directorio de plugins.
Segundo, excepciones propias y muy acotadas. En lugar de desactivar una regla en todas partes, retírela solo para la ruta en la que molesta:
# Excepción propia, cargar ANTES de las reglas del CRS (p. ej. en un *-before.conf)
SecRule REQUEST_URI "@beginsWith /admin/editor/speichern" \
"id:1000010,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941100"
El ID de la regla se obtiene del registro de auditoría del falso positivo. Documente cada excepción con su motivo y fecha, para que pueda revisarse más adelante.
Tras cada cambio de umbrales o excepciones, pruebe las vías críticas de su aplicación: inicio de sesión, pedido, pago, formulario de contacto y redacción. Un WAF que bloquea pedidos se desactiva enseguida.
Para los servidores Apache merece la pena abordar el WAF junto con el resto de la configuración; los fundamentos figuran en Configurar Apache para PHP de forma segura. Cómo situar las reglas de Cloudflare en comparación lo muestra Reglas de protección de Cloudflare contra PHP2Shell. Las medidas transitorias en el propio servidor figuran en Medidas inmediatas si todavía no puede parchear.
Conclusión: un WAF necesita mantenimiento
ModSecurity con el OWASP Core Rule Set le da un Web Application Firewall potente, sin costes de licencia y sin dependencia de un servicio externo. El precio es trabajo: elegir el motor adecuado al servidor web, empezar con umbrales altos, analizar falsos positivos, mantener las excepciones y conservar las reglas actualizadas.
Quien no pueda asumir ese esfuerzo suele salir mejor con un WAF en la nube bien configurado. Quien lo asume obtiene una capa que intercepta muchos ataques estándar y ofrece en los registros de auditoría pistas valiosas. En ningún caso sustituye a la actualización: frente a PHP2Shell solo protegen PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 o un backport confirmado, seguido del reinicio de todos los procesos de PHP.
¿Cómo ayuda PHP SOS en concreto?
- Elegir el motor: revisamos servidor web, distribución y paquetes existentes y recomendamos la combinación adecuada.
- Introducirlo: instalamos el CRS con umbrales iniciales altos, incorporamos los plugins adecuados y configuramos el registro.
- Afinar: durante varias semanas analizamos los falsos positivos, creamos excepciones específicas y reducimos los umbrales.
- Situarlo: en el marco de WAF y parcheo virtual conectamos el WAF con las medidas transitorias y con el camino hacia el parche regular.
Preguntas frecuentes
¿Protege el OWASP CRS frente a PHP2Shell?
No debería darlo por supuesto. El Core Rule Set detecta patrones de ataque generales y no está pensado para una vulnerabilidad concreta. Cloudflare advierte además de que, en PHP2Shell, las reglas basadas solo en los datos de la petición no bastan. La actualización de PHP sigue siendo obligatoria.
¿Qué motor debo elegir para Nginx?
Según el proyecto CRS, con ModSecurity v3 solo el conector de Nginx es realmente utilizable en producción, y v3 no supera una pequeña parte de las pruebas del CRS. Como alternativa existe Coraza, que según el proyecto supera por completo la suite de pruebas de CRS v4. Para Apache, el proyecto recomienda ModSecurity v2.
¿Se sigue manteniendo ModSecurity?
Según la documentación del CRS, Trustwave había anunciado que pondría fin al desarrollo en 2024. El 25 de enero de 2024 el proyecto se transfirió a la OWASP Foundation, que lo continúa desde entonces.
¿Cómo evito que el WAF paralice mi tienda?
Empiece con umbrales de anomalía muy altos, como recomienda el proyecto CRS, y redúzcalos poco a poco. Analice entretanto los registros y cree excepciones específicas para su aplicación en lugar de desactivar reglas en bloque.