Hoy le toca el turno a ModSecurity.
ModSecurity es un módulo para servidores HTTP (Apache, NGINX y Microsoft IIS) cuyo propósito es reforzar la seguridad de las aplicaciones Web. Es efectivamente un sistema de prevención y detección de intrusos para servidores Web, técnicamente hablando es un Firewall a nivel de Aplicación WAF.
Es de multiplataforma y de código abierto, y lo que nos permite es implementar protecciones avanzadas. Esto significa que es posible filtrar tráfico HTTP, directamente en el servidor Web, según el contenido de las peticiones de los clientes, lo cual permite detectar y bloquear ataques de tipo XSS (Cross Site Scripting), SQLi (SQL injection), session hijacking, etc.
Las características principales de ModSecurity son su capacidad de log y filtrado. El log de auditoría permite almacenar el detalle de cada petición en un archivo de log, incluyendo los
payloads de los POST HTTP.
En el post anterior, indicaba cómo podemos configurar un
Proxy Inverso con Apache si bien es cierto que hablando con Kino
@kinomakino sobre la mejor forma de implementar un WAF, me recomendaba montar el proxy inverso con
nginx tal y cómo el lo explica en su blog (
http://kinomakino.blogspot.com.es - Ya podrías comprar el dominio Kino :D ) , que tiene bastantes entradas dedicadas a este tema y, todo hay que decirlo, del que estoy aprendiendo a manejarlo y configurar bien las reglas, así que gracias Kino :)
Dicho esto, al lío:
Lo primero que tenemos que hacer es instalar modsecurity, como recordatorio indico que estoy sobre un sistema Debian y la forma de instalarlo en otras distribuciones puede variar, en mi caso:
#apt-get install libapache2-modsecurity
Para verificar que realmente se ha instalado:
#apachectl -M | grep --color security
Una vez ejecutado el comando anterior, nos tiene que devolver algo como:
...security2_module(shared)
Nos indicará que el módulo se ha instalado correctamente, antes de "recargar" la configuración de apache, vamos a hacer un par de cositas más.
Ahora toca descargar dichas reglas, así que lo primero que voy a hacer es crearme un directorio para las reglas dentro de /etc/apache2 llamado crs y es ahí donde voy a descargar mis reglas owasp:
# wget https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master
# tar xzf master
# mv SpiderLabs-owasp-modsecurity-crs-ebe8790 owasp-modsecurity-crs
El siguiente paso es hacer una copia del fichero de configuración:
# cp modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf
Ahora hay que decirle a apache que use el módulo de mod_security. Vuelvo a hacer hincapié en que estoy sobre un sistema debían y que la configuración difiere de algún que otro sistema, en este caso para decirle a apache que use el módulo hay que modificar el fichero ports.conf ubicado dentro del directorio /etc/apache2 y hemos de añadirle las siguiente líneas:
<IfModule security2_module>
Include /etc/apache2/crs/owasp-modsecurity-crs/modsecurity_crs_10_setup.conf
Include /etc/apache2/crs/owasp-modsecurity-crs/base_rules/*.conf
</IfModule>
Bien, ya tenemos la instalación del módulo casi lista, ahora nos queda recargar el servicio apache. Así que:
# service apache2 reload
Para comprobar que todo ha ido bien, listaremos el directorio log de apache:
# ls /var/log/apache2
Y veremos que existe un nuevo fichero llamado modsec_audit.log
Hasta ahora hemos instalado y puesto en marcha modsecurity sobre apache y le hemos cargado las reglas de OWASP. Ahora le toca el turno de configuración al propio modsecurity.
Por defecto modsecurity viene configurado en modo DetectionOnly esto que quiere decir, pues que sólo va a ir recogiendo las peticiones sin realizar ningún bloqueo, esta es la opción recomendada para ir viendo cómo funcionan las reglas antes de pasarlo a producción.
Para ver las distintas opciones que nos permite la configuración de modsecurity, editaremos su fichero de configuración que está alojado en /etc/modsecurity y se llama modsecurity.conf
Al editar el fichero veremos una serie de parámetros, los cuales voy a intentar explicar:
- SecureRuleEngine DetectionOnly (esta la comenté anteriormente, así que cuando tengamos todo preparado la cambiamos a On)
- SecuResponseBodyAccess esta directiva es usada para almacenar de forma temporal (yo entiendo que es a modo de cache), lo cual habilita la protección de fuga de datos y demás, lo malo es que el tamaño del registro aumenta. Sus modos de trabajo son On y Off, por defecto está en On
- SecRequestBodyLimit esta directiva indica el tamaño máximo de los POST, si se intenta subir un fichero con mayor tamaño, nos devolverá un error 413 Request Entity Too Large. Para qué nos vale esto, fácil, si nuestra web no trabaja con ningún tipo de formulario de subida de fichero y demás lo podemos bajar. El valor por defecto es de SecRequestBodyLimit 13107200 que son 12.5Mb así que la podemos reducir. Esta directiva trabaja conjuntamente con:
- SecRequestBodyNoFilesLimit que sería el tamaño mínimo de fichero que podemos subir, viene predefinida con 131072 que son 128Kb
- SecRequestBodyInMemoryLimit puedo decir que está es más directa, con ella podemos especificar que cantidad de datos vamos a almacenar en las peticiones (POSTed data) y será almacenada en la memoria ram de nuestra máquina, por defecto viene marcada con 131072 que son 128Kb, un dato a tener muy en cuenta dependiendo de la RAM de nuestra máquina.
Estos parámetros lo podemos modificar a nuestro antojo hasta que demos con la configuración idónea a nuestras necesidades.
Con estas pautas ya tendremos nuestro WAF funcionando.
En el siguiente post lo pondremos a prueba y además, para seguir fortaleciendo nuestro servidor, veremos como funcionan las reglas y analizaremos las mismas con más detalle.
