Esta guía se encarga de mostrarte la instalación y configuración de ModSecurity en su versión 2.7.2 como un Firewall de Aplicación Web.

Hoy en día existen paquetes necesarios para llevar a cabo toda la instalación de este módulo sobre Apache, nos beneficia de manera que podemos ahorrarnos estar configurando algunas partes.

NOTA: Dentro de esta guía encontrarás dos formas de instalación,  si deseas consultar la 2ª opción dirígete al anexo 1, donde también puedes despejar dudas sobre los paquetes que se instalarán y otras configuraciones que aplican para las dos formas de instalación. 

Puedes comenzar la instalación con un apt-get install:

# apt-get install libapache-mod-security
	

Este paquete se encargará de instalar todas las dependecnias necesarias para que modsecurity pueda funcionar como un módulo adicional de apache.

Una vez que hayamos instalado el paquete de los repositorios es importante que habilitemos los 2 módulos que utilizaremos:

# a2enmod mod_security
# a2enmod unique_id

Dentro del paquete que hemos instalado ya nos incluyen las reglas, las cuales serán configuradas de la siguiente manera:

En el directorio activated_rules/ debes crear las ligas simbólicas suaves (con el comando ln -s) de las reglas que desees implementar en el análisis y detección de intrusiones.

Se recomienda para una etapa inicial, solamente crear ligas simbólicas de todas las reglas contenidas en el directorio base_rules, pues estas proporcionan protección básica contra la mayoría de los ataques web.

En etapas futuras de implementación puedes usar las reglas contenidas en los directorios optional_rules y experimental_rules.

Este archivo lo localizaremos en la siguiente ruta:

#cd /usr/share/doc/libapache-mod security/examples/rules/modsecurity_crs/activated_rules

Una vez que estemos posicionados en la ruta donde activaremos las reglas crearemos las ligas simbólicas hacía este archivo, como se indica a continuación:

# cd activated_rules/
# ln –s ../base_rules/*
---------- Opcionales --------------
# ln –s ../optional_rules/*
# ln –s ../experimental_rules/*

Otro archivo muy importante que encontraremos en el paquete instalado es el de modsecurity.conf-recommended, regularmente se aloja en el siguiente directorio:

/usr/share/doc/libapache-mod-security

Es muy importante que este archivo se copie en la siguiente ruta para que los cambios puedan tener efecto:

cp modsecurity.conf-recommended  /etc/apache2/conf.dmodsecurity.conf

Este archivo es donde configuraremos los parámetros importantes para que  modsecurity funcione de una forma personalizada; es decir, aquí implica el criterio de cada uno y los resultados que deseamos obtener con las configuraciones finales:

# -- Rule engine initialization ----------------------------------------------
# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
#
SecRuleEngine DetectionOnly

# -- Request body handling ---------------------------------------------------

# Allow ModSecurity to access request bodies. If you don't, ModSecurity
# won't be able to see any POST parameters, which opens a large security
# hole for attackers to exploit.
#
SecRequestBodyAccess On


# Enable XML request body parser.
# Initiate XML Processor in case of xml content-type
#
SecRule REQUEST_HEADERS:Content-Type "text/xml" \
     "id:'200000',phase:1,t:none,t:lowercase,pass,nolog, \
      ctl:requestBodyProcessor=XML" \

# Maximum request body size we will accept for buffering. If you support
# file uploads then the value given on the first line has to be as large
# as the largest file you are willing to accept. The second value refers
# to the size of data, with files excluded. You want to keep that value as
# low as practical.
#
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

# Store up to 128 KB of request body data in memory. When the multipart
# parser reachers this limit, it will start using your hard disk for
# storage. That is slow, but unavoidable.
#
SecRequestBodyInMemoryLimit 131072

# What do do if the request body size is above our configured limit.
# Keep in mind that this setting will automatically be set to ProcessPartial
# when SecRuleEngine is set to DetectionOnly mode in order to minimize
# disruptions when initially deploying ModSecurity.
#
SecRequestBodyLimitAction Reject

# Verify that we've correctly processed the request body.
# As a rule of thumb, when failing to process a request body
# you should reject the request (when deployed in blocking mode)
# or log a high-severity alert (when deployed in detection-only mode).
#
SecRule REQBODY_ERROR "!@eq 0" \
"id:'200001', phase:2,t:none,log,deny,status:400, \
msg:'Failed to parse request body.', \
logdata:'%{reqbody_error_msg}',severity:2" \

# By default be strict with what we accept in the multipart/form-data
# request body. If the rule below proves to be too strict for your
# environment consider changing it to detection-only. You are encouraged
# _not_ to remove it altogether.
#
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:'200002',phase:2,t:none,log,deny,status:44, \
msg:'Multipart request body failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

# Did we see anything that might be a boundary?
#
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"id:'200003',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"

# PCRE Tuning
# We want to avoid a potential RegEx DoS condition
#
SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000

# Some internal errors will set flags in TX and we will need to look for these.
# All of these are prefixed with "MSC_".  The following flags currently exist:
#
# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.
#
SecRule TX:/^MSC_/ "!@streq 0" \
        "id:'200004',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"


# -- Response body handling --------------------------------------------------

# Allow ModSecurity to access response bodies. 
# You should have this directive enabled in order to identify errors
# and data leakage issues.
# 
# Do keep in mind that enabling this directive does increases both
# memory consumption and response latency.
#
SecResponseBodyAccess On

# Which response MIME types do you want to inspect? You should adjust the
# configuration below to catch documents but avoid static files
# (e.g., images and archives).
#
SecResponseBodyMimeType text/plain text/html text/xml

# Buffer response bodies of up to 512 KB in length.
SecResponseBodyLimit 524288

# What happens when we encounter a response body larger than the configured
# limit? By default, we process what we have and let the rest through.
# That's somewhat less secure, but does not break any legitimate pages.
#
SecResponseBodyLimitAction ProcessPartial


# -- Filesystem configuration ------------------------------------------------

# The location where ModSecurity stores temporary files (for example, when
# it needs to handle a file upload that is larger than the configured limit).
# 
# This default setting is chosen due to all systems have /tmp available however, 
# this is less than ideal. It is recommended that you specify a location that's private.
#
SecTmpDir /tmp/

# The location where ModSecurity will keep its persistent data.  This default setting 
# is chosen due to all systems have /tmp available however, it
# too should be updated to a place that other users can't access.
#
SecDataDir /tmp/


# -- File uploads handling configuration -------------------------------------

# The location where ModSecurity stores intercepted uploaded files. This
# location must be private to ModSecurity. You don't want other users on
# the server to access the files, do you?
#
#SecUploadDir /opt/modsecurity/var/upload/

# By default, only keep the files that were determined to be unusual
# in some way (by an external inspection script). For this to work you
# will also need at least one file inspection rule.
#
#SecUploadKeepFiles RelevantOnly

# Uploaded files are by default created with permissions that do not allow
# any other user to access them. You may need to relax that if you want to
# interface ModSecurity to an external program (e.g., an anti-virus).
#
#SecUploadFileMode 0600


# -- Debug log configuration -------------------------------------------------

# The default debug log configuration is to duplicate the error, warning
# and notice messages from the error log.
#
#SecDebugLog /opt/modsecurity/var/log/debug.log
#SecDebugLogLevel 3


# -- Audit log configuration -------------------------------------------------

# Log the transactions that are marked by a rule, as well as those that
# trigger a server error (determined by a 5xx or 4xx, excluding 404,  
# level response status codes).
#
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

# Use a single file for logging. This is much easier to look at, but
# assumes that you will use the audit log only ocassionally.
#
SecAuditLogType Serial
SecAuditLog /var/log/modsec_audit.log

# Specify the path for concurrent audit logging.
#SecAuditLogStorageDir /opt/modsecurity/var/audit/


# -- Miscellaneous -----------------------------------------------------------

# Use the most commonly used application/x-www-form-urlencoded parameter
# separator. There's probably only one application somewhere that uses
# something else so don't expect to change this value.
#
SecArgumentSeparator &

# Settle on version 0 (zero) cookies, as that is what most applications
# use. Using an incorrect cookie version may open your installation to
# evasion attacks (against the rules that examine named cookies).
#
SecCookieFormat 0

# Specify your Unicode Code Point.
# This mapping is used by the t:urlDecodeUni transformation function
# to properly map encoded data to your language. Properly setting
# these directives helps to reduce false positives and negatives.
#SecUnicodeCodePage 20127
#SecUnicodeMapFile unicode.mapping

Dentro del directorio que contiene las reglas se encuentra otro archivo importante con el siguiente nombre “modsecurity_crs_10_config.conf”.

De igual forma será modificado según las necesidades requeridas.

Esta es la otra opción descargando el .deb.

Pero, ¿qué es un paquete “.deb”?

 Un paquete “.deb”, es un archivo empaquetado y comprimido que contiene toda la información necesaria para instalar un software mediante cualquiera de las herramientas compatibles dpkg o apt. Está compuesto por tres archivos que contienen la información que guarda el paquete. Estos archivos son el control.tar.gz, el data.tar.gz y el debian-binary. Los dos primeros son archivos comprimidos que contienen uno información y otro los archivos que componen el programa empaquetado respectivamente, mientras que el último indica el número de versión del paquete DEB construido. [1]

Ahora que ya sabemos el potencial de los paquetes y lo útil que pueden ser,  vamos a descargar el “paquete.deb” que incluye los archivos necesarios para montar el módulo.

http://packages.debian.org/search?searchon=sourcenames&keywords=modsecurity-apache

Una vez accediendo a la liga seleccionaremos el paquete binario “libapache2-modsecurity”.

En esta parte selecciona el paquete que se acople a la arquitectura que maneja tu equipo.

Ahora descarga e instala las dependencias necesarias para que el paquete anterior pueda funcionar:

• APR: La biblioteca ejecutable adaptable de Apache: http://packages.debian.org/squeeze/libapr1
• APR-Util: La biblioteca de Utilidades del Entorno de ejecución de Apache: http://packages.debian.org/squeeze/libaprutil1
• Curl: Biblioteca multiprotocolo de Transferencia de Archivos: http://packages.debian.org/squeeze/libcurl3-gnutls
• PCRE: Biblioteca de Expresiones Regulares compatibles con Perl 5: http://packages.debian.org/squeeze/libpcre3
• Libxml2: Biblioteca de XML de GNOME: http://packages.debian.org/squeeze/libxml2

Existe otra forma de hacer la instalación y configuración de ModSecurity,  a continuación los pasos:

En esta parte vas a descargar el paquete que incluye el módulo de ModSecurity:

http://packages.debian.org/squeeze-backports/libapache2-modsecurity

Con el siguiente comando podrás ver el contenido del paquete:

# dpkg -c nombrePaquete.deb

Una vez que estés colocado sobre el paquete DEB vas a instalarlo con el siguiente comando:

# dpkg -i nombrePaquete.deb

ModSecurity proporciona protecciones importantes contra intrusos,  las reglas que contiene se centran en la identificación de ataques, esto con el fin de proporcionar una protección de día cero y vulnerabilidades desconocidas o conocidas sobre aplicaciones web.

Las reglas básicas utilizan las siguientes técnicas: validación de solicitud HTTP, HTTP anomalías de protocolo, restricciones globales, la política de uso de HTTP, detección de software malicioso cliente, detección de ataques genérico (inyección de SQL, Cross Site Scripting, OS Inyección de comandos, ColdFusion, PHP y ASP inyección, etc .), troyanos y puertas traseras de detección, detección de errores, Protección, Monitoreo XML motor de búsqueda.

Descargarlas en la siguiente liga:

http://packages.debian.org/wheezy/modsecurity-crs

Dentro del paquete encontrarás las reglas que van a ser activadas, así como el archivo de configuración de las mismas.

Configuración de reglas.

En el directorio activated_rules/  debes crear las ligas simbólicas suaves (con el comando ln -s) de las reglas que desees implementar en el análisis y detección de intrusiones.

Se recomienda para una etapa inicial, solamente crear ligas simbólicas de todas las reglas contenidas en el directorio base_rules,pues estas proporcionan protección básica contra la mayoría de los ataques web.

En etapas futuras de implementación puedes usar las reglas contenidas en los directorios optional_rules y experimental_rules.

# cd /usr/share/modsecurity-crs/
# cd activated_rules/
# ln –s ../base_rules/*
---------- Opcionales --------------
# ln –s ../optional_rules/*
# ln –s ../experimental_rules/*

Dentro del directorio del paquete “libapache2-modsecurity_2.6.6-5_i386.deb” vas a encontrar el archivo de configuración de ModSecurity, normalmente ubicado en “/etc/modsecurity/modsecurity.conf-recommended”, éste archivo es una plantilla que contiene las directivas de configuración principales para el funcionamiento de ModSecurity.

Este archivo podrá ser modificado a tu manera, según las necesidades que desees cubrir, puedes hacer las siguientes configuraciones:

• Inicialización del motor de reglas (Modo de operación Activo  o Pasivo).
• Partes de la transacción HTTP sujetas a análisis (cabecera de petición, cuerpo de petición, cabecera de respuesta, cuerpo de respuesta).
• Ubicación de archivos temporales.
• Ubicación de datos persistentes.
• Ubicación de archivos enviados interceptados.
• Configuración de bitácoras de Debugging.
• Configuración de bitácoras de Auditoría.

En el directorio de reglas “modsecurity-crs_2.2.5_all.deb” se encuentra el archivo “modsecurity_crs_10_setup.conf” éste archivo es una plantilla que contiene directivas de configuración que son usadas para controlar el conjunto de reglas para ModSecurity.

Estos son los aspectos de configuración que cubre este archivo:

• Modos de detección (Tradicional o por puntajes).
• Niveles para el modo de detección.
• Límites para el modo de detección.
• Geo-localización por dirección IP.
• Políticas del protocolo HTTP.
• Configuración inicial contra ataques de Fuerza Bruta.
• Configuración inicial contra ataques de DoS.
• Análisis de contenido XML.
• Inicialización de variables necesarias para la operación del conjunto de reglas.

Una vez que tengas instaladas todas las dependencias necesarias (libapr, aprutil, curl, pcre y libxml)  para que ModSecurity pueda funcionar sin problema alguno vamos a prender nuestro servidor Apache.

# /etc/init.d/apache2 start 

También lo puedes iniciar de la siguiente manera:

#/usr/local/apache2/bin/apachectl restart
	

Si no ocurrió ningún error durante el reinicio de Apache entonces ya tienes ModSecurity integrado a tu servidor web.

Configuración de bitácoras ModSecurity.

Recuerda tener activado el módulo en tu servidor es el 1er paso, también es necesario tener bitácoras activadas, las cuales te serán de gran utilidad para interpretar los datos que te arroja ModSecurity, estas las puedes  activar en la ubicación que desees.

Sitúate dentro del archivo contenido en el paquete de “libapache2-2-modsecurity_2.6.6-5_i386.deb”  y ahí localiza el archivo de configuración de ModSecurity para configurar tus bitácoras  “/etc/modsecurity/modsecurity.conf-recommended”.

Configuración de bitácora de pruebas (Debug Log)

En esta sección indicarás la ubicación en donde será almacenada y registrada la bitácora de pruebas. Adicionalmente se puede ajustar la sensibilidad de la bitácora, mientras mayor sea el valor de la directiva SecDebugLogLevel la bitácora será registrada con mayor detalle (Los valores permitidos son del 0 al 9). En un entorno de producción se recomienda mantener el valor de la directiva en 0.

SecDebugLog.

# -- Debug log configuration -----------

# The default debug log configuration is to duplicate the error, warning
# and notice messages from the error log.
#
#SecDebugLog /opt/modsecurity/var/log/debug.log
#SecDebugLogLevel 3

SecDebugLog /opt/modsec/var/log/debug.log
SecDebugLogLevel 0

Configuración de bitácora de auditoría

En esta sección especificarás la ubicación donde se almacenará tu bitácora de auditoría. Éste tipo de bitácora tiene la función de registrar por completo (depende de la configuración de esta sección) las transacciones HTTP (tanto peticiones como respuestas HTTP) que procesa el Firewall de Aplicación Web, esto con la finalidad de implementar una consola de monitoreo (ej. AuditConsole, WAFFLE) que interprete la bitácora y muestre a los administradores de forma gráfica lo que sucede en tiempo real.

En un entorno de producción solo se habilita si se tiene implementada una consola de monitoreo, de lo contrario se debe desactivar pues genera una gran cantidad de registros y emplea mucho espacio en disco duro en un periodo de tiempo breve (1.5Gb en una semana aproximadamente).

# -- Audit log configuration -----------

# Log the transactions that are marked by a rule, as well as those that
# trigger a server error (determined by a 5xx or 4xx, excluding 404,  
# level response status codes).
#
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

# Use a single file for logging. This is much easier to look at, but
# assumes that you will use the audit log only ocassionally.
#
SecAuditLogType Serial
SecAuditLog /opt/modsec/var/audit/modsec_audit.log

# Specify the path for concurrent audit logging.
#SecAuditLogStorageDir /opt/modsec/var/audit/

Resumen de instalación:

1. Instalar ModSecurity:

# apt-get install libapache-mod-security

2. Revisión de módulos habilitados:

# a2enmod mod_security
# a2enmod unique_id

3. Activar reglas:

#cd/usr/share/doc/libapache –modsecurity/examples/rules/modsecurity_crs/activated_rules

# cd activated_rules/
# ln –s ../base_rules/*

4. Archivo de configuración ModSecurity:

#/usr/share/doc/libapache-mod-security

# cp modsecurity.conf-recommended  /etc/apache2/conf.dmodsecurity.conf

5. Configurar reglas:

# vi /usr/share/doc/libapache-mod-security/examples/rules/modsecurity_crs_10_config.conf

Probando la instalación de ModSecurity.

En tu navegador web consulta una aplicación alojada  en tu servidor protegido con ModSecurity. Las aplicaciones web que tengas alojadas en el servidor deberán observarse y comportarse de forma normal, la implementación del firewall de aplicación debe pasar desapercibida para los usuarios.

La siguiente imagen ejemplifica la vista de una aplicación web protegida con ModSecurity (1).

1.       Aplicación web protegida con ModSecurity.

Cuando un usuario malicioso pretende realizar un ataque a tu aplicación web o hacer pruebas en busca de vulnerabilidades usualmente recurre a técnicas de inyección de código para hacerlo.  En la siguiente ilustración se muestra un ejemplo de una prueba básica de inyección de código JavaScript (2).

2.       Prueba básica de inyección de código

Cuando ModSecurity se encuentra operando en modo activo bloquea las peticiones maliciosas mostrando un mensaje similar al que se muestra en la ilustración (3).

3.       Mensaje de bloqueo de ModSecurity

Hasta este punto ya tienes una instalación de ModSecurity  completa (en modo embebido).

Solo resta que la adecues a tu entorno de trabajo.

Referencias:

1. ¿Cómo crear un paquete .deb?:

http://120linux.com/crear-un-paquete-deb/

2. Sitio de ModSecurity:

http://www.modsecurity.org/download/

3. Descarga paquetes debian:

http://packages.debian.org/search?searchon=sourcenames&keywords=modsecurity-apache

4. Información adicional de reglas y funcionamiento de ModSecurity:

http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html