Introduccion a Mod Security y reglas free Owasp.

Como alguna vez hemos hablado en este blog aquí y aquí, Mod security es el Web Application Firewall del mundo software libre más usado.

Mod Security funciona como módulo embebido de Apache o para cualquier web server como reverse proxy.

Las funciones que nos permite este WAF son las clásicas:

• Monitorización en tiempo real de los accesos web. Podemos delimitar el acceso a nuestros recursos web no solo con htaccess, sino con reglas específicas.
•  Virtual Patching. Este concepto me parece muy interesante, al igual que con Snort, tenemos la posibilidad de crear una regla que detecte un exploit concreto contra una vulnerabilidad concreta, y podemos parar la ejecución, aún contando con la vulnerabilidad sin parchear. Muy útil para sistemas heredados, integrados o con dificultad para actualizar.
• Logging. Como herramienta de registros de la actividad http/s.
• WEB Hardening. Podemos crear reglas para securizar nuestro webserver. Por ejemplo, podemos crear una regla que inspeccione el Body Response y detecte una fuga de información de una caída de Mysql, inyectando código en la respuesta o redirección a otro recurso, para evitar dan información al atacante. Hay muchas, algunas las iremos comentando en Inseguros.
• ...

Como habéis podido leer, funciona como un ids tipo Snort/Suricata, en el que el motor mod security examina todo el tráfico en base a una reglas, y en el caso de que hagan "Match", que encuentre el patrón de la regla, podemos vincular una acción.

Es decir, aparte de la potencia de procesamiento de Mod Security, lo importante son las reglas.

Si te vas a animar en probar Mod Security sobre tus webserver, puedes hacerlo de una manera muy sencilla.

El proceso es bajar mod security, compilarlo (hay millones de tutoriales) habilitar el módulo en Apache. Bajar las reglas que más te gusten y trabajar.

No tengas miedo en montar Mod Security y pensar en que vas a parar tráfico legítimo, o que vas a cargar el web server. Mis pruebas dan que Mod Security carga el webserver en un 8%/10%. Las reglas las podemos evaluar antes de que corten, en modo DetectionOnly. Cuando hayamos "trasteado" con las reglas podemos pasar a la acción habilitando las acciones, pero podemos estar tranquilos en que mientras lo analizamos, no estaremos cortando tráfico legítimo.

El conjunto clásico de reglas que todo el mundo se baja de manera gratuita es Owasp Core Rule Set.

Vamos a ver una regla simple para que os hagáis una idea de su simpleza, o quizás de su complejidad xD.

SecRule REQUEST_HEADERS:User-Agent "@pmFromFile modsecurity_35_bad_robots.data" \

"chain,phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,block,msg:'Rogue web site crawler',id:'990012',tag:'OWASP_CRS/AUTOMATION/MALICIOUS',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',severity:'4',capture,logdata:'%{TX.0}'"

Esta regla se engloba en modsecurity_crs_35_bad_robots.conf

Lo que tenemos es un fichero .data que almacena los user_Agent maliciosos conocidos...(actualizar de vez en cuando) y si en el Request Headers detecta alguno en User-Agent hace un BLOCK, con un mensaje concreto en la alerta. Esto es lo más relevante de momento de esta regla. Ya entraremos en detalle con las reglas, simplemente quiero que veáis como se hacen, y que son "asequibles" de programar o interpretar.

Vamos a interpretar una alerta generada por esa regla de arriba.

--e2b5db05-A--

[16/Oct/2014:10:16:06 +0200] VD9@xrIhfmwAADLzPPYAAAAA ip origen 15866 ip destino 80

--e2b5db05-B--

GET /*************/?gclid=*************************** HTTP/1.1

Host: dominio atacado

User-Agent: NIKTO

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3

Accept-Encoding: gzip, deflate

Referer: ******************

Cookie: cookie_****=1; __utma=*******************                                                  971.72.39.utmgclid=CKCyoq3dsMECFSuWtAodRyMAxg|utmccn=(not%20set)|utmcmd=(not%20set); optimizelySegments=%7B%221               

Connection: keep-alive

Cache-Control: max-age=0

--e2b5db05-F--

HTTP/1.1 403 Forbidden

Last-Modified: Wed, 07 Aug 2013 10:59:35 GMT

ETag: "*************"

Accept-Ranges: bytes

Vary: Accept-Encoding,User-Agent

Content-Encoding: gzip

Content-Length: 546

Connection: close

Content-Type: text/html

--e2b5db05-H--

Message: Access denied with code 403 (phase 2). Matched phrase "nikto" at REQUEST_HEADERS:User-Agent. [file "/e                                                         tc/httpd/modsecurity.d/activated_rules/modsecurity_15_customrules.conf"] [line "16"] [id "990002"] [rev "2"] [msg "Request Indicates a Security Scanner Scanned the Site"] [data "nikto"] [severity "CRITICAL"] [ver "OWASP_CR S/2.2.6"] [maturity "9"] [accuracy "9"] [tag "OWASP_CRS/AUTOMATION/SECURITY_SCANNER"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"]

Action: Intercepted (phase 2)

Stopwatch: 1413447366270242 2499 (- - -)

Stopwatch2: 1413447366270242 2499; combined=530, p1=165, p2=356, p3=0, p4=0, p5=8, sr=63, sw=1, l=0, gc=0

Producer: ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/); OWASP_CRS/2.2.6.

Server: Apache

Engine-Mode: "ENABLED"

--e2b5db05-Z--

Para esta regla, he resaltado los campos más relevantes en negrita, que como puedes comprobar, coinciden con la regla comentada.

Tengo que decir que el conjunto de reglas Owasp para mi es como un "Pattern & design". Me explico. Imaginaros un ataque web concreto, con una url asi:  http://dominio/admin.php?user=hygugugu&cmd=cmd.exe.

Es una tontería pero sirve de ejemplo. Tenemos un ataque que mediante una url concreta de un fabricante, con un parámetro concreto de un usuario, nos permite ejecutar una consola de sistema. Mod Security no va a detectar el ataque concreto contra ese fabricante, sino que detecta un "ataque" porque según el conjunto de reglas Owasp, hacer una llamada a CMD.exe es de por si un ataque.

Esto tiene algo bueno y malo. Lo bueno es que detectará los ataques pasados, presentes y futuros que empleen CUALQUIER llamada por url a CMD.exe. Lo malo es si tu usas esta función?

Ese es el trabajo que debemos realizar una vez instalamos Mod Security y las reglas Owasp en modo DetectionOnly. Detectar que comportamientos legítimos de nuestras aplicaciones son detectadas como alertas, y tenemos que o modificar la aplicacion... xD  o hacer whitelist de esa regla para una ip, dominio, vhost o regla concreta.

Pongo otro ejemplo, si en tu aplicación web entras por dominio, pero existen enlaces hacia url por IP, OWASP rules detecta esto como un ataque...

Quería hablar de otro conjunto de reglas, pero me he animado a escribir esta pequeña guia para ver si os animáis a instalar vuestro mod security en cualquier máquina virtual ,en cualquier apache que tengas por ahí, y así poder seguir los artículos. Vamos !!!

Si tenéis alguna duda en la instalación inicial o en el setup, podéis contactar conmigo por correo en minick @ hotmail.com.

Gracias por leerme, espero que os guste !!!.