¿Qué son OWASP Top 10, Core Rule Set (CRS) y ModSecurity?

reparar Windows 11

Solicitud enviada al sitio
        ↓
ModSecurity la inspecciona
        ↓
Se aplican las reglas de OWASP CRS
        ↓
¿Comportamiento normal o sospechoso?
        ↓
La solicitud continúa o puede bloquearse

Tener ModSecurity instalado no significa que sea eficaz

Este punto es importante. Puedes tener el módulo ModSecurity instalado en el servidor sin disfrutar de la protección que imaginas. El motor debe estar activo, las reglas deben estar cargadas, deben inspeccionarse las partes importantes de las solicitudes y las reglas deben poder desencadenar acciones.

ModSecurity tiene tres estados principales para SecRuleEngine:

Off
DetectionOnly
On

En modo DetectionOnly, las reglas se ejecutan, pero no se aplican las acciones de bloqueo. El motor puede detectar algo y registrarlo sin impedir que la solicitud continúe. Es lo que recomiendo a quien empieza con ModSecurity y CRS, porque comprobarás que son muy potentes y que incluso pueden bloquearte a ti mismo. Me ocurrió: CRS bloqueó mi editor de WordPress y ni siquiera podía modificar o actualizar un artículo. Esto nos lleva a uno de los puntos más importantes al utilizar CRS.

¿Por qué no activar simplemente CRS en modo de bloqueo?

Porque CRS es deliberadamente general. Debe poder utilizarse delante de una enorme variedad de aplicaciones sin conocer de antemano cómo funcionan. WordPress, Nextcloud, una API propia o una tienda online no se comunican de la misma manera.

Algunas aplicaciones también envían datos que, fuera de contexto, pueden parecer un ataque. Esto se llama un falso positivo. Un WAF no entiende una página como lo haría una persona: principalmente ve una URL, cookies, cabeceras HTTP, el cuerpo de una solicitud y cadenas de caracteres.

No puedo buscar PowerShell en mi sitio WordPress

En Assistouest.fr publiqué un artículo informático que contiene un comando de PowerShell. Para mí, es simplemente contenido destinado a explicar una operación de Windows. Pero parte de ese comando se parece a algo que un atacante enviaría para intentar ejecutar código en Windows Server. El firewall no sabe necesariamente que estoy redactando un artículo. Principalmente ve la cadena de caracteres.

Los falsos positivos que encontré en mi servidor

En mi infraestructura me he encontrado con varios casos de falsos positivos con ModSecurity y CRS.

Entre ellos había algunas solicitudes de Nextcloud que utilizaban WebDAV, contenidos de WordPress sobre PowerShell o Base64 y determinadas cookies de Cloudflare, como cf_clearance.

La regla detectaba a menudo algo parecido a lo que buscaba. El problema era simplemente que, en ese contexto concreto, la solicitud era legítima. Por eso los registros son indispensables para configurar correctamente CRS y ModSecurity.

Un 403 no basta para entender qué ha ocurrido

Cuando ModSecurity bloquea una solicitud, el navegador recibe un 403 Forbidden, un código que indica que la solicitud ha sido rechazada. En mi infraestructura, cuando un comportamiento me sorprende, no empiezo desactivando la regla.

Empiezo por buscar por qué se activó. Y lo contrario también es cierto. La ausencia de un 403 no significa que ModSecurity no haya detectado nada.

Una regla puede haberse activado sin que la solicitud se bloquee.

Puede ocurrir si el motor funciona en modo DetectionOnly, pero también si el nivel total de sospecha no es suficiente para alcanzar el umbral de bloqueo.

La puntuación de anomalía: varias señales pequeñas pueden activar una regla

OWASP CRS utiliza una puntuación de anomalía ponderada. Cuando una regla coincide con algo sospechoso, puede añadir puntos a la transacción. No todas las detecciones tienen la misma importancia. La configuración oficial utiliza puntuaciones diferentes según la gravedad de las reglas y después compara el total con un umbral de bloqueo.

Utilicemos deliberadamente un ejemplo simplificado. Una primera regla detecta un elemento algo sospechoso:

+ 3 puntos

Una segunda regla encuentra otro elemento sospechoso:

+ 2 puntos

La puntuación total llega a 5. Si el umbral de bloqueo está fijado en 5, la solicitud puede rechazarse.

Los Paranoia Levels: detectar más y bloquear sin avisar, o no

CRS también cuenta con varios Paranoia Levels (PL). El nivel 1 es el predeterminado.

Al subir de nivel, se activan más reglas y las comprobaciones se vuelven progresivamente más estrictas. Esto puede mejorar la detección de determinados comportamientos.

Pero hay una contrapartida: cuanto más sensibles son las reglas, más aumenta también el riesgo de falsos positivos. Por tanto, esto no significa:

PL4 = mejor seguridad

La configuración adecuada es la que puedes administrar correctamente.

Un PL muy alto que después te obligue a desactivar familias enteras de reglas puede ser menos interesante que un nivel más razonable correctamente ajustado.

Tendrás que permitir exactamente lo que sea legítimo

Probablemente sea uno de los aspectos menos visibles de CRS. Cuando una regla bloquea una solicitud legítima, la solución más sencilla consiste en crear una excepción en lugar de desactivar la regla.

Imagina que una regla XSS solo causa problemas cuando un campo concreto de WordPress contiene código destinado a un artículo técnico.

Podrías desactivar esa regla en todas partes.

El falso positivo desaparece.

Pero la protección también desaparece en el resto del sitio.

El mejor enfoque consiste en decir:

Esta regla sigue activa en todas partes

EXCEPTO

Para este campo concreto, en esta función y cuando sea necesario

CRS ofrece varios mecanismos de exclusión que permiten limitar una excepción a una variable, una URL o un contexto concreto, sin eliminar la regla de todo el sitio.

Hay que volver a probar después de cada exclusión

Una exclusión corrige un problema. Pero si es demasiado amplia, también puede crear una debilidad en la protección. Por eso después realizo pruebas de regresión.

En mi instalación utilicé solicitudes de prueba correspondientes a varias familias de inyección SQL, XSS, LFI, intentos de RCE y accesos a determinados archivos sensibles, como .env.

¿Puede un WAF proteger frente a una vulnerabilidad zero-day?

Este es también uno de los aspectos más interesantes de las reglas generales de CRS. Una zero-day es una vulnerabilidad descubierta recientemente para la que puede que todavía no exista una solución disponible.

Por supuesto, CRS no puede conocer por arte de magia una vulnerabilidad que acaba de aparecer.

Pero no necesita necesariamente conocer el nombre de la vulnerabilidad para reconocer la técnica utilizada para explotarla. Imaginemos que se descubre una nueva vulnerabilidad en una extensión de WordPress.

Nadie ha añadido todavía una regla específica para esa extensión.

Pero si la explotación consiste en enviar una inyección SQL clásica en un parámetro, CRS ya conoce muchos patrones característicos de las inyecciones SQL.

Por tanto, puede bloquear el intento porque reconoce la familia de ataque, no porque conozca esa vulnerabilidad concreta.

nueva vulnerabilidad
        ↓
técnica de explotación
        ↓
inyección SQL
        ↓
reglas SQL ya presentes en CRS
        ↓
detección

Este es también el principio de lo que OWASP denomina virtual patching: una capa de seguridad intermedia puede impedir determinados intentos de explotación antes de que se corrija el código vulnerable. Evidentemente, esto no sustituye a una actualización.

En cuanto exista una solución real, la vulnerabilidad debe corregirse en su origen.

El WAF permite aun así reducir temporalmente la exposición y, de forma más general, la superficie de ataque.

¿Y todos los ataques que CRS no puede ver?

Aquí es donde OWASP Top 10 también ayuda a comprender los límites de un WAF.

Imagina un sitio donde /factura?id=100 muestra tu factura.

Si simplemente sustituyes 100 por 101 y la aplicación te muestra la factura de otro cliente, existe un problema de control de acceso. Sin embargo, tu solicitud HTTP puede parecer completamente normal.

No hay SQL sospechoso. No hay JavaScript. No hay ningún comando del sistema. El problema está en la lógica de la aplicación. Un conjunto de reglas genéricas no puede saber que el usuario conectado no tiene permiso para consultar ese recurso.

Lo mismo ocurre con una arquitectura de autenticación deficiente, un error criptográfico y otros fallos puramente lógicos.

ModSecurity y CRS deben formar parte de un conjunto

Un WAF es una capa de protección, no la única. En mi caso, ModSecurity y CRS funcionan junto con otras protecciones situadas en distintos puntos de la infraestructura.

Cloudflare puede filtrar parte del tráfico antes de que llegue al servidor. Un firewall puede limitar determinados accesos de red. Una herramienta como CrowdSec puede analizar los registros para detectar determinados eventos y comportamientos presentes en los registros de ModSecurity.

Pero su funcionamiento es otro tema y ninguna de estas capas hace innecesarias a las demás.

La función de ModSecurity y CRS es analizar las transacciones web según unas reglas e intervenir cuando coinciden suficientemente con comportamientos considerados peligrosos.