Mostrando entradas con la etiqueta Mod Security. Mostrar todas las entradas
Mostrando entradas con la etiqueta Mod Security. Mostrar todas las entradas

jueves, 23 de octubre de 2014

Reglas para Mod Security Free. Comodo y Atomic.

Como vimos en la pequeña introducción del anterior capítulo, cuando hablamos de Mod Security debemos hablar de un conjunto de reglas que sirvan de patrón al WAF para detectar intrusiones.

En esta entrada os voy a comentar simplemente un par de recursos disponibles, de manera gratuita, para nuestras implementaciones de Mod Security.


La primera es el conjunto de reglas del firewall Comodo para Mod Security.
Debes realizar el registro para descargar las reglas.

Si en tu fichero de configuración de Mod Security tienes algo como así:

<IfModule mod_security2.c>
    # ModSecurity Core Rules Set configuration
        Include modsecurity.d/*.conf
        Include modsecurity.d/activated_rules/*.conf

    # Default recommended configuration
    SecRuleEngine DetectionOnly

Pues simplemente copia los ficheros en esa ruta y realiza un service httpd reload (o similar) para que cargue las reglas.

Os recomiendo realizar esta gestión en un entorno de pre-producción o testing, para no cortar el tráfico legítimo.

Si simplemente estas jugando, puedes habilitar el DetectionOnly para revisar el comportamiento de Mod Security, sin cortar tráfico. repito, SIN CORTAR TRAFICO !!!.


El otro conjunto de reglas que vamos a incorporar es la versión de trial de 30 días de Atomic Corp.
Podemos registrarnos y descargar el conjunto de reglas. Podremos usarlas ilimitadamente, pero no podremos actualizarlas pasados los 30 días.

El link de descarga es este.

Algunas de las utilidades que empleo es apachectl configtest Cuando haces un restart del servicio Apache puedes ver los errores que pueden producir que no arranque Apache, como por ejemplo un problema con alguna de las reglas. Cuando realizas un reload, el comando no tira ninguna opción, por lo que si tienes algún problema debes usar apachectl configtest para delimitar el problema.

Por ejemplo, si cargas las reglas Atomic, una buena recomendación es hacerlo de fichero en fichero, para ir haciendo Reload y validando reglas. Si copias el fichero 10_asl_rules.conf, el de mas tamaño, tendrás un problema al hacer Reload.

service httpd reload
Reloading httpd: not reloading due to configuration syntax error
                                                           [FAILED]

Con el comando:

apachectl configtest
Syntax error on line 241 of /etc/httpd/modsecurity.d/activated_rules/10_asl_rules.conf:
Error creating rule: Could not open phrase file "/etc/httpd/modsecurity.d/activated_rules/sql.txt": No such file or directory

Vamos a hacerle caso y a copiar tambien el fichero en cuestión. Hacemos service httpd reload y bingo, recarga apache.

Ahora a mi me gusta hacer un tail  y revisar el log que tira, buscando las nuevas reglas.
tail -F /var/log/httpd/modsec_audit.log |grep -A8 -B17 10_asl_rules


Con la salida del grep A8 y b17 saco las lineas after y before de encontrar el nombre de la regla, para ver la IP, y el resto de reglas que han podido saltar. Lanzo un Nikto y veo que ocurre.

Como podéis apreciar, me saltan 3 reglas, las de Comodo, las de Atomic, y una regla custom que yo tenía creada "parecida". Ya que no vamos a actualizar las reglas Comodo/Atomic por su restricción "trial", podemos modificar directamente el fichero de reglas y comentar las que no nos interesen. Recuerda que cuantas menos reglas procese Apache, mas ligero correrá. Aparte, me hace difícil gestionar esa regla en mi consola OSSIM.

Mando el tail a un fichero, y lanzo Nikto, w3af, openvas, wpscan, joomscan, o cualquiera de las tools que quieras comprobar. Con esta gestión, podemos depurar las reglas para darles un poco mas de coherencia al uso de 3 motores de reglas.


El siguiente paso sería realizar varios circuitos funcionales, para detectar falsos positivos. Realizar una compra, escribir un post, subir una imagen, cualquier proceso que ocurre legítima en tu aplicación web.

Recuerda que como trabajamos en DetectionOnly no estaremos cortando tráfico legítimo.

Una de las inquietudes que se plantean con este sistema es en entornos de producción en los cuales se trabaja directamente con el entorno, sin pre-producción o testing, corremos el riesgo de modificar cualquier comportamiento en nuestra aplicación que haga que alguna regla haga MATCH, días después de haber validado la regla, por lo que se hace casi imprescindible tener con un entorno de validación, algo lógico pero no siempre puesto en práctica por la mayoría de PYMES.

Tanto si te toca defender tus aplicaciones, como si realizas labores de pentesting, recomiendo contar con un entorno de WAF para comprobar como se detectan los ataques que sufrimos/producimos.

Como siempre, espero que os guste y gracias por leerme !!!










jueves, 16 de octubre de 2014

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 !!!.

jueves, 9 de octubre de 2014

Prevención de fugas de información en logs. Campo Passwords y Mod security

Cuando un atacante pretende comprometer un sistema, una de las ubicaciones que debe observar son los logs. Imaginaros el caso de un sistema comprometido, en el que el atacante accede a los logs del sistema, en el que se muestran en claro los usuarios y contraseñas de nuestros usuarios. Se lo pondríamos muy fácil.


En algún cliente me ha ocurrido la situación de  presentar una solución tipo Snort, Mod Security e incluso un simple Squid Proxy para proporcionar elementos de seguridad, y ser la propia gerencia la que descartaba este tipo de soluciones por la exposición de información sensible, y casi siempre personal, al departamento IT o el departamento que accede a los logs ( redundante, los informáticos lo vemos todo, desde el de micro-informática hasta el sysadmin-boss).

Con un proxy podemos ver los hábitos de navegación de nuestros director de ventas, que son muy decorosos...Con Snort podemos detectar aplicaciones prohibidas, como pueda ser el famoso BroadCast de Dropbox...

Para proporcionar un nivel de seguridad y confianza en la gestión de logs de Mod Security, vamos a crear una pequeña regla al respecto.

Lo que hacemos es crear una regla tan sencilla como la siguiente. Con ella simplemente lo que hacemos es que en fase 5,la parte de logging, sanitice !*"!^·*!^"*·! (limpie los caracteres de un campo con asteriscos).

SecRule &ARGS:password "@eq 1" "phase:5,t:none,id:123458,nolog,pass,sanitiseArg:password"


Esta regla de por sí no generará alarma, simplemente que en nuestras reglas existentes, cuando detecte un campo password, "limpiará" el registro con ****.

Veamos un ejemplo. Lanzo un "ataque" ficticio sobre una aplicación, para que salte cualquiera de las alarmas que tenemos configuradas ( en este caso salta una alarma por hacer match de la palabra UNION).


Como puedes ver, aparece la contraseña en claro.
Sin embargo una vez activada nuestra nueva regla, podemos comprobar que el mismo ataque, genera la misma alerta, pero limpia el campo.


Como puedes ver, esta simple regla puede propiciar que gerencia vea con buenos ojos tu medida de seguridad, y no estés viendo todas las passwords de los clientes. Pobres ilusos xD pero bueno, creo que todo el mundo es consciente de que este tipo de información es manejada por el departamento IT.

Como siempre, espero que os guste, gracias por leerme !!!