Instalación y configuración de Mod Security

Lunes, 30 de Mayo de 2011 23:29

Quizás uno de los engendros más recomendables si administramos nuestro propio servidor web, siempre y cuando este basado en LAMP, es sin duda el mod_security.

Mod Security es un módulo de Apache, que mediante del filtrado de los distintos métodos HTTP (GET, POST, etc) adquiere un comportamiento de Firewall Web, filtrando ataques potenciales a nuestros sitios web.

Mod Security trabaja con sets de reglas especializadas y personalizables, que podemos cargar o excluir según virtualhost o directorio. Estas reglas trabajan filtrando ataques por Cross Scripting o XSS, inyecciones SQL, anomalías en protocolos, Robots maliciosos, Trojanos, inclusión de archivos (LFI), etc y recientemente se incorpora un set de reglas especificas (slr_rules) para CMS como Joomla, Wordpress o PHPBB.

La potencialidad de dicha herramienta es incuestionable, ya que no sólo permite proteger los sitios web desplegados en Apache sino los sitios que se puedan estar redirigidos a través de Mod Proxy, por lo que podemos proteger múltiples aplicaciones web desplegadas en diversos servidores tras nuestro Apache equipado con Mod Proxy y Mod Security.

Instalación de mod security

Además de útil esta aplicación, su instalación es francamente intuitiva y amigable.
A continuación voy a describir algunos de los principios de instalación de mod_security 2.6 sobre Apache 2 en Debian o Ubuntu.

Podemos hacer las descargas necesarias desde la web oficial en: www.modsecurity.org

Si estamos en Debian, lo más práctico será descargarlo y compilarlo nosotros mismos, en Ubuntu, ya esta disponible en los repositorios.

Primeramente descargarnos las fuentes y desempaquetamos:

wget http://www.modsecurity.org/download/modsecurity-apache_2.6.0.tar.gz
tar -zxvf modsecurity-apache_2.6.0.tar.gz

Antes de proceder a la compilación hay que cumplir algunos requisitos, si es que ya no están ya instalados:

   apt-get install apache2-threaded-dev
   apt-get install libxml2-dev
   apt-get install libcurl4-gnutls-dev

Tras esto ya podemos entrar en el directorio modsecurity-apache_2.6.0 y hacer los pertinentes pasos para la compilación:

   ./configure
   make
   make install

En este punto podemos optar por las siguientes opciones:

./configure --with-apxs=/usr/bin/apxs2
make CFLAGS=-DMSC_TEST test

En particular "CFLAGS=-DMSC_TEST test" es útil si detectamos algún error durante make. APache eXtenSion (apxs) es un cargador de módulos para apache contenido en apache2-threaded-dev, no es imprescindible pero si recomendable.

Una vez finalizada la compilación y tras el make install, deberiamos tener el modulo: mod_security2.so en la siguiente ruta: /usr/lib/apache2/modules/

Para cargar el modulo debemos crear el siguiente fichero:

vim /etc/apache2/mods-available/mod-security2.load

con el siguiente contenido:

LoadFile /usr/lib/libxml2.so
LoadFile /usr/lib/liblua5.1.so.0
LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so

Este procedimiento podemos realizarlo también a través del apache2.conf aunque para mantener la organización de Apache es mejor usar el mod-security2.load

Antes de activar mod_security hay que activar unique_id con un:

a2enmod unique_id

Y ya estamos listos para un:

a2enmod mod-security2

Desde Ubuntu, tenemos a mod security ya en los repositorios, por lo que basta con un:

apt-get install libapache2-mod-security2

Sin embargo es conveniente asegurarnos que cumplimos igualmente los requisitos citados anteriormente. La propia instalación ya se encargará de crear el archivo mod-security2.load y cargar mod-security2, sin embargo debemos asegurarnos de que unique_id esta cargado.

Con estos sencillos pasos ya tenemos a mod_security funcionando, si hacemos un:

cat /var/log/apache2/error.log | grep ModSecurity

Vamos a encontrarnos con las credenciales de ModSecurity:

   [Mon May 30 10:45:15 2011] [notice] ModSecurity for Apache/2.6.0 (http://www.modsecurity.org/) configured.
   [Mon May 30 10:45:15 2011] [notice] ModSecurity: APR compiled version="1.2.12"; loaded version="1.2.12"
   [Mon May 30 10:45:15 2011] [notice] ModSecurity: PCRE compiled version="7.6"; loaded version="7.6 2008-01-28"
   [Mon May 30 10:45:15 2011] [notice] ModSecurity: LIBXML compiled version="2.6.32"

Si al reiniciar Apache nos encontramos con algun error en las reglas relativo a los Headers, del tipo:

Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration

Es que no tenemos el modulo mod_headers habilitado en nuestro apache, para solucionar este error basta con:

a2enmod mod_headers

Si no nos interesa habilitar mod_headers, tenemos que crear una exclusión de dichas reglas en nuestro virtualhost.

Configuración de mod security

Sin embargo, hasta este punto no nos serviría de nada si no instalamos la reglas que establezcan las condiciones del filtrado de métodos y urls:

 wget "http://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/modsecurity-crs_2.2.0.zip/download" -O modsecurity-crs_2.2.0.zip
 unzip modsecurity-crs_2.2.0.zip 

Una vez inflado el archivo descargado, veremos varios directorios:

Los contenedores de reglas: base_rules, experimental_rules, optional_rules y slr_rules, además de diversas utilidades y el archivo modsecurity_crs_10_config.conf.example de mod_security.

Para una primera toma de contacto bastará con renombrar modsecurity_crs_10_config.conf.example a modsecurity_crs_10_config.conf

Para finalizar debemos añadir a apache2.conf lo siguiente

   <IfModule security2_module>
   SecRuleEngine On
   SecRequestBodyAccess On
   SecResponseBodyAccess Off
   SecDebugLog /var/log/apache2/modsec_debug.log
   SecDebugLogLevel 1
   SecAuditEngine RelevantOnly
   SecAuditLogRelevantStatus ^5
   SecAuditLogParts ABIFHZ
   SecAuditLogType Serial
   SecAuditLog /var/log/apache2/modsec_audit.log
   SecRequestBodyLimit 131072
   SecRequestBodyInMemoryLimit 131072
   SecResponseBodyLimit 524288
   SecDataDir  /tmp/
   SecUploadDir /tmp/
   SecTmpDir /tmp/
   Include modsecurity_crs_10_config.conf
   Include modsecurity-crs/2.2.0/base_rules/*.conf
   Include modsecurity-crs/2.2.0/optional_rules/*.conf
   Include modsecurity-crs/2.2.0/slr_rules/*.conf
   </IfModule>

Hay que ser cuidadoso con SecDataDir, SecUploadDir y SecTmpDir ya que las aplicaciones que suban ficheros y usen temporales no van a funcionar.

De forma similar, hay que prestar atención a posibles configuraciones de los atributos SecRequestBodyLimit, SecRequestBodyInMemoryLimit, SecResponseBodyLimit que se suelen definir en el archivo apache2.conf. Estas configuraciones nos va determinar las características de subida de archivos a través de nuestras aplicaciones web.

Lo realmente importante de este fragmento son las rutas al archivo de configuración y reglas:

   Include modsecurity_crs_10_config.conf
   Include modsecurity-crs/2.2.0/base_rules/*.conf
   Include modsecurity-crs/2.2.0/optional_rules/*.conf
   Include modsecurity-crs/2.2.0/slr_rules/*.conf

Para este caso yo he almacenado mis archivos de configuración y reglas bajo la ruta /etc/apache2/ sin embargo podemos elegir cualquier otra. El uso del asterisco como comodín nos permite cargar todas la reglas de cada set. Cuidado con escribir correctamente "*.conf" ya que de lo contrario no se cargará ninguna regla, y mod security aunque estará activo no realizará tareas de filtrado.

Si todo ha ido bien, pronto comenzaremos a ver en nuestro archivo de logs de Apache, decenas por no decir centenares de logs de este tipo:

[client 192.168.1.34] ModSecurity: Access denied with code 403 (phase 2). 
Pattern match "^[\\\\d.:]+$" at REQUEST_HEADERS:Host. 
[file "/etc/apache2/modsecurity-crs/2.2.0/base_rules/modsecurity_crs_21_protocol_anomalies.conf"] 
[line "98"] [id "960017"]

Si nos encontramos entre nuestros logs con alertas del tipo "Execution failed while reading output" hay que sospechar que algun paquete de reglas o regla en particular esta causando errores. Para depurar dicha situación es interesante ir comentando los paquetes de reglas y observar si deja de producirse.

Es tremendamente probable que nos encontremos a priori con un filtrado especialmente agresivo y necesitemos realizar exclusiones para que nuestras aplicaciones funcionen normalmente.

Por ejemplo si queremos excluir o hacer un bypass en una regla tenemos que detectar la excepción en los logs y localizar su id en forma de [id "960017"]. De esta manera podemos añadir la directiva SecRuleRemoveById a nuestro virtualhost como sigue en el ejemplo:

   <Directory /var/www/>
   Options Indexes FollowSymLinks MultiViews
   AllowOverride None
   Order allow,deny
   allow from all
   SecRuleRemoveById 960017
   </Directory>

Por ejemplo para hacer funcionar un Joomla 1.5 normalmente tras mod_security vamos a necesitar las siguientes exclusiones:

   SecRuleRemoveById 910006
   SecRuleRemoveById 970009
   SecRuleRemoveById 970015
   SecRuleRemoveById 950004
   SecRuleRemoveById 950117
   SecRuleRemoveById 950020

Si queremos ampliar el potencial de filtrado de nuestro módulo podemos acudir a: http://www.gotroot.com/mod_security+rules y descargarnos libremente sus colecciones de reglas propias.

Si observamos que aunque a pesar de haber declarado nuestras exclusiones estas son ignoradas, hay que buscar posibles alertas de alguna malfucción en su interpretación, ya que esta situación puede ser causante de que la directiva SecRuleRemoveById no funcione correctamente.

Actualización de Reglas

Dentro del paquete de reglas que nos descargamos, en el directorio util, tenemos un archivo llamado rules-updater.pl

Para hacer funcionar este archivo necesitamos tener instalado previamente los siguientes paquetes de perl:

   apt-get install libwww-perl
   apt-get install liblwp-useragent-determined-perl libcrypt-ssleay-perl

rules-updater.pl permite descargar de forma más o menos programada las últimas versiones del paquete de reglas. Su uso quizás sea un poco tosco:

./rules-updater.pl -rhttp://www.modsecurity.org/autoupdate/repository/ -p/tmp 
                          -s/etc/apache2/crs/ -u -Smodsecurity-crs 

   -r Nos indica la URL del repositorio
   -p El directorio temporal de descarga
   -S El directorio donde se va a descomprimir
   -u Que se va a descomprimir
   -S El nombre del ultimo paquete de reglas estable

Esto descargará nuestro paquete de reglas y lo descomprimirá en /etc/apache2/modsecurity-crs/2.2.0.

Próximo >