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í:
# 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 !!!
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í:
# ModSecurity Core Rules Set configuration
Include modsecurity.d/*.conf
Include modsecurity.d/activated_rules/*.conf
# Default recommended configuration
SecRuleEngine DetectionOnly
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 !!!
