1C_C15010: Instalación de mod_security

Instalación de mod_security

Esta actividad práctica corresponde a este tema.

Para la instalación de mod_security es necesario seguir cuidadosamente una serie de pasos que se muestran a continuación. En Ubuntu Server 10.04 el uso de este mod en la fecha de escritura de esta sección (Agosto de 2010) es bastante complejo y pueden manifestarse bugs, por lo que conviene proceder con un cuidado extremo:

Primero se debe instalar el entorno necesario para el mod añadiendo al sistema una serie de aplicaciones necesarias para que éste pueda funcionar. Esto se hace con el siguiente comando: sudo apt-get install apache2-prefork-dev libxml++2.6-dev liblua5.1-0 liblua5.1-0-dev libcurl3-dev.

El siguiente paso es descargar el mod de http://modsecurity.org/download/direct.html (hay un enlace directo de descarga, que es http://www.modsecurity.org/download/modsecurity-apache_2.5.12.tar.gz, para poder usarlo con wget).
El fichero descargado está empaquetado, pero se puede extraer fácilmente con herramientas como ark (herramienta grafica) o tar, con las opciones xvf. Al desempaquetarlo en algún directorio debería aparecernos una estructura de directorios como la siguiente:

A continuación debemos parar antes de proceder con la instalación del mod Apache: /etc/init.d/apache2 stop

El siguiente paso es instalar g++, al ser necesario para compilar mod_security. Esto se puede hacer mediante el comando: apt-get install g++

Una vez hecho esto, ya podemos comenzar la instalación. Para ello se debe entrar al directorio apache2 dentro de la carpeta donde se extrajo mod_security y ejecutar ./configure

Cuando esta orden finalice, se deben ejecutar 3 más en este orden: make, make test, make install.

Con esto finaliza la instalación del módulo en sí. Ahora es necesario habilitar un conjunto de software adicional necesario para que pueda trabajar correctamente. El primero de ellos es mod unique_id: a2enmod unique_id

Posteriormente es necesario hacer que Apache cargue el mod y lo ponga en marcha. Esto se consigue añadiendo estas líneas al fichero apache2.conf:

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

<Ifmodule mod_security2.c>

#Este debe ser el path donde hemos descomprimido el #mod. Ojo con la version instalada y con los permisos #que posee este path. Apache (el usuario www-data) debe #poder acceder al mismo

Include /home/mainuser/modsecurity-apache_2.5.12/rules/*.conf

</Ifmodule>

Con estos pasos el módulo ya está listo para arrancar correctamente. Sólo quedan una serie de tareas adicionales, entre las cuales está el configurar adecuadamente las core rules para que se adapten a nuestro sistema:

Ir al directorio donde se descomprimió todo y encontrar el fichero modsecurity_crs_10_config.conf (normalmente estará en el directorio /rules de esta localización, como se estableció en el fichero que mostramos antes).

Editar estas líneas (o añadirlas si no estuviesen presentes) para poner los logs en el lugar del sistema de ficheros correcto según nuestra instalación. Por ejemplo:

SecAuditLog /var/log/apache2/modsec_audit.log
SecDebugLog /var/log/apache2/modsec_debug.log

Reiniciar Apache y probar alguna web instalada en el mismo (como por ejemplo la web del máster que estamos usando de ejemplo durante este curso) desde el cliente XP).
El funcionamiento del mod se debería ver en los logs de Apache, apareciendo información como la siguiente en el archivo /var/log/apache2/error.log

En nuestra instalación particular, con mod_security iniciado y en función de la versión del mod, Apache o Ubuntu que poseamos, una simple petición a una página cualquiera podría denegarse. Esto no es algo malo, es señal de que mod_security funciona y de que simplemente nuestra instalación tiene algo que choca contra las reglas establecidas en el mismo. En concreto, el problema es que una de las reglas evita el acceso vía IP a los sitios web. Como nuestra instalación de pruebas no tiene DNS, usamos la IP de la máquina directamente para acceder a ella, causando este conflicto. Nótese que futuras revisiones del mod y de sus reglas pueden cambiar este comportamiento.

Esto podemos evitarlo editando el fichero modsecurity_crs_21_protocol_anomalies.conf, buscando una regla cuyo comentario es "Check that the host header is not an IP address". Debemos comentarla y reiniciar Apache para que sea tenido en cuenta este cambio o bien desactivarla con el procedimiento que el mod posee para ello (ver enlaces posteriormente).
Finalmente, podemos comprobar si mod_security está en funcionamiento si los logs correspondientes al mod del servidor o bien los del propio servidor se llenan de contenido relacionado con el mismo (que no sean errores). Si es así, lo hemos hecho bien y el mod está protegiendo el servidor. Podemos entonces pasar a probar la web de forma intensiva para comprobar que no hay ningún efecto no deseado adicional.

En caso de no lograr hacer funcionar el mod en primera instancia, hay una serie de cosas que podemos probar:

Asegurarse de que Apache puede acceder y escribir sobre los archivos de log de mod_security, estableciendo para ellos permisos idénticos al resto de archivos de log del servidor
Completar la configuración del mod añadiendo las líneas que se muestran en la imagen siguiente:

SecRuleEngine: Directiva que controla si se procesan las reglas que controlan el comportamiento de mod_security ante peticiones. Se debe poner en On si la versión del mod instalada no lo hiciera ya por defecto
SecDataDir: Directva que establece un path donde mod_security guardará información que le es necesaria. Debe ser accesible por el servidor, de la misma manera que los logs, lo que requiere permiso de ejecución hasta la carpeta usada como almacén de datos y capacidad de escritura en la misma.
SecDefaultAction: El conjunto de acciones por defecto que el mod usará en caso de que una de las reglas de seguridad case con una petición. Son una serie de acciones que se toman en orden y que mod_security usará en caso de que la regla en si no establezca una concreta
Includes: Algunas distribuciones tienen un bug que hace que no se lean todos los archivos .conf existentes en la localización que se dio en el archivo que creamos anteriormente. Esto quiere decir que aunque se lea el .conf primario, no se accederán a los subdirectorios para ver si poseen más archivos .conf. Para solucionar este problema, en caso de sospechar que no se están procesando las reglas, hay que incluir las rutas explicitas a los subdirectorios de la localización de las reglas (/rules), como se ve en la imagen. NOTA: La versión de las core rules actual tiene un error de sintaxis en un archivo de la carpeta optional_rules que impide que las reglas de la misma se procesen, así que permanece desactivado en el fichero mostrado.

No debemos olvidarnos de reiniciar Apache con cada cambio de configuración que hagamos para que sea tenido en cuenta.

Para terminar con este tema resta aclarar una serie de aspectos:

La distribución de Ubuntu Server posee un procedimiento más sencillo de instalación de mod_security que se muestra en este enlace: http://ubuntusur.org/?p=570. No obstante actualmente, aunque mod_security se instala rápida y fácilmente, la versión instalada falla a la hora de procesar las core rules más modernas debido a un error de sintaxis, por lo que se recomienda tener cautela a la hora de usarlo. Como posible solución, se puede probar a incluir los paths explicitos de las reglas tal y como se comentó anteriormente. Es incluso recomendable hacer un Include por cada .conf existente en las core rules, aunque esto puede ser un proceso tedioso y propenso a fallos. La ventaja del procedimiento que hemos usado nosotros es que nos permite usar la última versión disponible tanto de mod_security como de las core rules, que no tienen por qué ser las que posee la distribución de Ubuntu usada.
Hemos contemplado solo una instalación básica de mod_security dada la orientación que tiene este curso, pero se pueden hacer configuraciones más complejas y adaptadas a necesidades concretas. Una de las primeras cosas que se pueden hacer es estudiar y modificar sus directivas, cuya descripción y funcionamiento puede encontrarse en este enlace: http://www.modsecurity.org/documentation/modsecurity-apache/2.1.0/html-multipage/03-configuration-directives.html
Es recomendable también estudiar qué acciones llevar a cabo ante una petición concreta, modificando las core rules si es necesario. Una descripción de las acciones posibles podemos encontrarla en: http://www.modsecurity.org/documentation/modsecurity-apache/1.9.3/html-multipage/05-actions.html

A continuación se proporcionan enlaces con información adicional de los diversos aspectos vistos:

Last modified: Thursday, 26 August 2010, 2:42 AM