1 2 3 4 5 6

Implementación de un Firewall de Aplicación Web con ModSecurity

Esta guía cubre sólo los aspectos básicos de instalación y configuración del Firewall de Aplicación Web ModSecurity en su versión 2.9.0, por lo cual no debes olvidar llevar a cabo un proceso de hardening en tu sistema antes de implementar ésta tecnología en un entorno de producción. Recuerda que un sistema es tan fuerte como lo es su eslabón más débil.

Nota: Se recomienda la instalación de la versión 2.9.0 de ModSecurity debido a que se encontró una vulnerabilidad en las versiones 2.6.5 y anteriores.

https://community.qualys.com/blogs/securitylabs/2012/06/15/modsecurity-and-modsecurity-core-rule-set-multipart-bypasses

 

1. Configuración previa del equipo

 

Características del ambiente de pruebas

Sistema Operativo

GNU/Linux Debian 8 Jessie

Versión de ModSecurity

ModSecurity 2.9.0

 

 

ModSecurity tiene una serie de requisitos de instalación, a continuación el listado:

 

Requerimiento

Versión usada en esta guía

GCC (Compilador de lenguaje C)

GCC 4.9.2

make

GNU Make 4.0

PCRE

pcre 8.37 (pcre2 no es compatible)

Python

2.7.9

APR

apr 1.5.2

APR-Util

apr-util 1.5.4

Curl

curl 7.45.0

Libxml

libxml 2-2.9.2

Lua

lua 5.3.2

OpenSSL

openssl 1.0.2d

(Se presentaron problemas de compatibilidad con openssl 1.0.0g)

 

Bibliotecas adicionales requeridas:

Las siguientes bibliotecas no se mencionan en la documentación de ModSecurity pero son requeridas durante el proceso de instalación.

Requerimiento

Versión usada en esta guía

Expat

expat 2.1.0

Zlib

zlib 1.2.8

 

Para poder instalar las bibliotecas de programación (GCC y Python-dev) de las cuales dependen algunos de los requisitos se utiliza el siguiente comando:

apt-get install build-essential python-dev

Nota: Las recomendaciones y sugerencias para las ubicaciones de directorios descritas a continuación fueron determinadas con fines de ejemplificación. El administrador puede elegir una configuración diferente si lo desea, esto no afectará al funcionamiento de ModSecurity, salvo que alguna indicación especifique lo contrario.

 

Recomendaciones

Una vez descargadas las dependencias necesarias para la instalación de ModSecurity se recomienda crear un par de directorios para almacenarlas.

De igual forma fungen como repositorio o respaldo de nuestros archivos necesarios para realizar otra instalación de ModSecurity en otros equipos.

Para este laboratorio de prácticas se creó el siguiente directorio:

# mkdir -p /tmp/install

Crear el directorio tar/ para alojar los archivos “.tar.gz” que contienen los códigos fuente comprimidos de las bibliotecas y módulos.

Crear el directorio source/ para almacenar su código fuente sin comprimir. Esto con la finalidad de centralizar los archivos de código fuente y de esta manera ubicarlos rápidamente en caso de que se tenga que compilar de nuevo alguna biblioteca o módulo.

 

1.1) Instalación de PCRE (Perl Compatible Regular Expressions)

 

Sitio: http://www.pcre.org/

Descarga: ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/

Descripción: La biblioteca PCRE comprende un conjunto de funciones que implementan la búsqueda y coincidencia de patrones usando la misma semántica y sintaxis que Perl 5.

Apache tiene incluida una versión de la biblioteca PCRE pero la usa de tal forma que no permite a otros módulos hacer uso de ella. Para resolver esta situación, instala PCRE de forma separada e indica a Apache que haga uso de la instalación externa. Actualmente se tiene una versión de PCRE2 la cual no es compatible aún con Apache 2.4.x.

Se recomienda realizar una instalación independiente de PCRE en su versión más reciente, puede ser desde paquetes (depende del sistema operativo) o desde código fuente. Para la guía se contempló la instalación desde código fuente.

# tar xvfz pcre-8.37.tar.gz
# cd pcre-8.37/
# ./configure
# make
# make install

 

1.2) Instalación de Expat

 

Sitio: http://expat.sourceforge.net/

Descarga: http://sourceforge.net/projects/expat/files/expat/

Descripción: La función principal de la biblioteca “Expat” es el análisis orientado a flujos de contenido XML.

Esta biblioteca no está listada en la documentación de ModSecurity como requerimiento pero de no implementarse pueden presentarse algunos errores durante el proceso de instalación, por lo cual se recomienda su instalación previa.

# tar xvfz expat-2.1.0.tar.gz
# cd expat-2.1.0/ 
# ./configure 
# make 
# make install

 

1.3) Instalación de zlib

 

Sitio y Descarga: http://zlib.net/

Descripción: “Zlib” es una biblioteca de compresión sin pérdida de datos y es también un componente crucial de muchas plataformas de software. Las funciones de este módulo permiten la compresión y descompresión.

Hay incompatibilidades conocidas entre el módulo de Python y versiones de la biblioteca “zlib” antes de la versión 1.1.3, la cual también tiene una vulnerabilidad de seguridad, por lo que recomendamos el uso de versiones posteriores.

Esta biblioteca no se encuentra listada en los requerimientos de ModSecurity, pero de no contarse con ella, podría provocar problemas durante la instalación del mismo.

# tar xvfz zlib-1.2.8.tar.gz
# cd zlib-1.2.8/
# ./configure
# make
# make install
	

 

1.4) Instalación de APR (Apache Portable Runtime)

 

Sitio: http://apr.apache.org/

Descarga: http://apr.apache.org/download.cgi

Descripción: APR es un API para que desarrolladores de software aseguren que sus aplicaciones funcionen de forma estandarizada en diversas de plataformas.

Los desarrolladores de software pueden codificar y tener la seguridad de que el comportamiento será idéntico independientemente de la plataforma sobre la que se construye su software.

De forma similar a la biblioteca PCRE, se recomienda instalar una instancia de APR por separado, de la que ya se incluye en Apache en el código fuente.

# mkdir /usr/local/apr-1.5.2
# tar xvfz apr-1.5.2.tar.gz
# cd apr-1.5.2/
# ./configure --prefix=/usr/local/apr-1.5.2
# make
# make install
	

 

1.5) Instalación de APR-Util

 

Sitio: http://apr.apache.org/

Descarga: http://apr.apache.org/download.cgi

Descripción: Biblioteca que forma parte del API de APR.

Se recomienda instalar una instancia de APR-Util por separado de la que ya se incluye en Apache desde su descarga.

# mkdir /usr/local/apr-util-1.5.4
# tar xvfz apr-util-1.5.4.tar.gz
# cd apr-util-1.5.4/
# ./configure --prefix=/usr/local/apr-util-1.5.4 \
  --with-apr=/usr/local/apr-1.5.2/bin/apr-1-config
# make
# make install
	

 

1.6) Instalación de Libxml

 

Sitio: http://www.xmlsoft.org/

Descarga: ftp://xmlsoft.org/libxml2/

Descripción: También denominada Libxml2, es una biblioteca que ofrece la posibilidad de analizar el lenguaje de marcado XML.

# mkdir /usr/local/libxml2-2.9.2
# tar xvfz libxml2-2.9.2.tar.gz
# cd libxml2-2.9.2/
# ./configure --prefix=/usr/local/libxml2-2.9.2
# make
# make install

	

 

1.7) Instalación de Curl

 

Sitio: http://curl.haxx.se/

Descarga: http://curl.haxx.se/download.html

Descripción: Es una biblioteca que permite transferir datos con sintaxis de URL, soporta FTP, FTPS, HTTP, HTTPS, IMAP, LDAP, entre otros.

# mkdir /usr/local/curl-7.45.0
# tar xvfz curl-7.45.0.tar.gz
# cd curl-7.45.0/
# ./configure --prefix=/usr/local/curl-7.45.0
# make
# make install

	

 

1.8) Instalación de openssl

 

Sitio: www.openssl.org

Descarga: ftp://ftp.openssl.org/source/

Descripción: Biblioteca que implementa seguridad mediante criptografía con los protocolos SSL (Secure Sockets Layer) y TLS (Transport Layer Security).

Con la versión 1.0.0g (openssl 1.0.0g) se presentaron problemas de compatibilidad al tratar de vincularse con Apache 2.4.17, por lo tanto se usó la versión 1.0.2d (openssl 1.0.2d). Esta versión es la más recomendada ya que en ella se arreglan defectos de seguridad que estaban clasificados como de severidad alta.

# mkdir /usr/local/openssl-1.0.2d
# tar xvfz openssl-1.0.2d.tar.gz
# cd openssl-1.0.2d/
# ./config shared--prefix=/usr/local/openssl-1.0.2d -fPIC
# make
# make install
	

Una vez contando con todos los requerimientos de bibliotecas se debe configurar Apache para cargarlas.

 

2. Instalación de ModSecurity 2.9.0

 

ModSecurity 2.x sólo funciona con versiones de Apache 2.0.x o superior. Se recomiendan las versiones 2.2.x, o bien la 2.4.x.

En esta guía se contempla la instalación desde cero del servidor web Apache. Si ya cuenta con un servidor Apache en funcionamiento, entonces puede omitir esta sección, pero debe cerciorarse de contar con las bibliotecas anteriormente mencionadas en la sección 1. Configuración previa del equipo.

Se debe descargar el código fuente del servidor web Apache y del Firewall de Aplicaciones Web ModSecurity, además del conjunto de reglas de ModSecurity.

Servidor Web Apache: http://httpd.apache.org/

Descarga: http://httpd.apache.org/download.cgi#apache24

httpd-2.4.17.tar.gz

 

ModSecurity: http://www.modsecurity.org/

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

modsecurity-2.9.0.tar.gz

 

Reglas de ModSecurity (CRS - Core Rules Set): http://www.modsecurity.org/rules.html

Descarga: https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

modsecurity-crs_2.2.9.orig.tar.gz

 

2.1) Instalación de Apache HTTPD

 

Asegúrate de indicar a Apache la ubicación correcta donde están localizadas las bibliotecas necesarias para la instalación de ModSecurity.

# mkdir /usr/local/apache2
# tar xvfz httpd-2.4.17.tar.gz
# cd httpd-2.4.17/
# ./configure --prefix=/usr/local/apache2 \
--with-apr=/usr/local/apr-1.5.2/bin/apr-1-config \
--with-apr-util=/usr/local/apr-util-1.5.4/ \
--with-ssl=/usr/local/openssl1-1.0.2d/ \
--with-pcre=/usr/local/bin/pcre-config \
--with-z=/usr/local/zlib-1.2.8/ \
--enable-module=so \
--enable-ssl \
--enable-unique-id \
--enable-proxy \
--enable-proxy-ftp \
--enable-proxy-http \
--enable-proxy-connect \
--enable-headers \
--enable-deflate
# make
# make
# install
	

 

2.2) Instalación de ModSecurity

 

Hay que cerciorarse de vincular las mismas bibliotecas que fueron configuradas para tu instancia de Apache, de no hacerlo pueden ocurrir errores durante la ejecución de ModSecurity.

# tar xvfz modsecurity-2.9.0.tar.gz
# cd modsecurity-2.9.0
# ./configure \
--with-apxs=/usr/local/apache2/bin/apxs \
--with-pcre=/usr/local/bin/pcre-config \
--with-apr=/usr/local/apr-1.5.2/ \
--with-apu=/usr/local/apr-util-1.5.4/ \
--with-libxml=/usr/local/libxml2-2.9.2/ \
--with-curl=/usr/local/curl-7.45.0/
# make
# make install
	

Al finalizar la instalación de ModSecurity se encontrará el archivo binario de ModSecurity en /usr/local/modsecurity/lib/mod_security2.so. Se copia al directorio de módulos de Apache.

cp /usr/local/modsecurity/lib/mod_security2.so /usr/local/apache2/modules/

***OJO: Te ofrecemos otra forma de instalación, para que te ahorres la compilación de todas las bibliotecas anteriores a través del paquete “apache2-prefork-dev”, si te interesa puedes consultar el Anexo 1. Además podrás hacer uso del Script ConfiguraModSec.txt que también te podrá ser de utilidad para instalar las bibliotecas descargas ***

 

3. Configuración de Apache y ModSecurity

 

Una vez que se tienen todos los componentes instalados ahora sólo resta configurar el servidor web Apache y ModSecurity.

 

3.1 Configuración de ModSecurity

 

Para facilitar la administración del Firewall de Aplicación Web se recomienda crear la siguiente estructura de directorios para alojar sus archivos de configuración, bitácoras y archivos temporales. De esta forma podremos tener toda esta información centralizada en un sólo lugar.

Crear la siguiente estructura de directorios:

 

bin

Se ubicarán manualmente los archivos binarios de ModSecurity.

etc

Se ubicarán manualmente los archivos de configuración de ModSecurity y conjunto de reglas.

data

Datos persistentes (Creación de variables temporales).

log

Bitácoras de auditoría y pruebas (debug).

tmp

Archivos temporales.

upload

Almacenamiento de archivos interceptados por ModSecurity.

Una vez creada la estructura de directorios, desempaquetar el conjunto de reglas y copiar los directorios: activated_rules, base_rules, optional_rules, experimental_rules y slr_rules bajo el directorio /opt/modsec/etc/rules/

# tar xvfz modsecurity-crs_2.2.9.orig.tar.gz
# cd owasp-modsecurity-crs_2.2.9/
# cp –r *_rules/ /opt/modsec/etc/rules/

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

Para una etapa inicial, se recomienda unicamente 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 se pueden usar las reglas contenidas en los directorios optional_rules, experimental_rules y slc_rules. Se debe tener cuidado con algunas de estás reglas ya que tienen algunos requerimientos extra para poder usarlas

# cd /opt/modsec/etc/rules
# cd activated_rules/
# ln –s ../base_rules/*

---------- Opcionales --------------

# ln –s ../optional_rules/*
# ln –s ../experimental_rules/*
# ln –s ../slr_rules/*

	

Notas:

Si se desea omitir algún archivo de reglas solo se debe eliminar o excluir la creación de su liga simbólica.

El uso del conjunto de reglas experimental_rules y slc_rules es útil pero se recomienda implementarlas inicialmente en un entorno de pruebas o con ModSecurity funcionando en modo pasivo con la finalidad de evitar gran cantidad de falsos positivos.

Al mostrar el contenido de los directorios de reglas se puede observar una lista de archivos similar a la siguiente:

modsecurity_35_bad_robots.data
modsecurity_35_scanners.data
modsecurity_40_generic_attacks.data
modsecurity_41_sql_injection_attacks.data
modsecurity_50_outbound.data
modsecurity_50_outbound_malware.data
modsecurity_crs_20_protocol_violations.conf
modsecurity_crs_21_protocol_anomalies.conf
modsecurity_crs_23_request_limits.conf
modsecurity_crs_30_http_policy.conf
modsecurity_crs_35_bad_robots.conf
modsecurity_crs_40_generic_attacks.conf
modsecurity_crs_41_sql_injection_attacks.conf
modsecurity_crs_41_xss_attacks.conf
modsecurity_crs_42_tight_security.conf
modsecurity_crs_45_trojans.conf
modsecurity_crs_47_common_exceptions.conf
modsecurity_crs_48_local_exceptions.conf.example
modsecurity_crs_49_inbound_blocking.conf
modsecurity_crs_50_outbound.conf
modsecurity_crs_59_outbound_blocking.conf
modsecurity_crs_60_correlation.conf

Donde:

* Los archivos con extensión .data contienen información adicional que complementa a las reglas a manera de diccionarios de datos.

* Los archivos con extensión .conf son los que contienen las definiciones de las reglas.

* El número que se encuentra en cada nombre de archivo indica el orden en el que el servidor Apache cargará los archivos de reglas.

 

Nota: El orden en que se cargan los archivos de configuración y de reglas es muy importante para el correcto funcionamiento de ModSecurity.

 

3.2 Archivo principal de configuración de ModSecurity

 

Dentro del directorio del código fuente de ModSecurity modsecurity-2.9.0/ se encuentra el archivo modsecurity.conf-recommended, este archivo es una plantilla que contiene las directivas de configuración principales para el funcionamiento de ModSecurity.

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

  • 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.
  • Entre otros.

Para generar el archivo principal de configuración de ModSecurity se debe copiar el archivo modsecurity.conf-recommended al directorio /opt/modsec/etc/ excluyendo la parte final de su nombre -recommended.

cp  modsecurity.conf-recommended /opt/modsec/etc/modsecurity.conf

 

3.3 Archivo principal de reglas

 

Dentro del directorio de reglas recién desempaquetado modsecurity-crs_2.2.5/ se encuentra el archivo modsecurity_crs_10_config.conf.example, este archivo es una plantilla que contiene 

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

  • Modos de detección (Tradicional o Anomaly Scoring / Self-Contained o Collaborative Detection).
  • Niveles para el modo de “Collaborative Detection”..
  • Límites para el modo de “Collaborative Detection”..
  • 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.

Para generar el archivo principal de reglas se debe copiar el archivo modsecurity_crs_10_config.conf.example al directorio /opt/modsec/etc/ excluyendo la extensión .example.

# cp modsecurity_crs_10_config.conf.example
# /opt/modsec/etc/modsecurity_crs_10_config.conf
    

Nota: Debido a la importancia de los archivos modsecurity.conf y modsecurity_crs_10_config.conf, es recomendable generar archivos de respaldo antes de aplicar cambios significativos en su contenido.

 

3.4 Configuración de Apache HTTPD para cargar ModSecurity

 

A pesar de que ModSecurity ya se encuentra instalado es necesario indicarle al servidor web Apache dónde se encuentra el módulo de ModSecurity y la ubicación de sus archivos de configuración.

Editar archivo de configuración principal de Apache, /usr/local/apache2/conf/httpd.conf y agregar las siguientes líneas:

### Cargando Modulos ###

# Cargando libxml
LoadFile /usr/local/libxml2-2.9.2/lib/libxml2.so

# Cargando modsecurity
LoadModule security2_module /usr/local/apache2/modules/mod_security2.so

# Cargando mod_unique_id
LoadModule unique_id_module /usr/local/apache2/modules/mod_unique_id.so

### Cargado reglas de modsecurity ###

# Reglas

	Include /opt/modsec/etc/modsecurity.conf
	Include /opt/modsec/etc/modsecurity_crs_10_config.conf
	Include /opt/modsec/etc/rules/activated_rules/*.conf

Si se compiló Apache para su instalación, dentro del archivo de configuración /usr/local/apache2/conf/httpd.conf, quitar el comentario de la siguiente línea, de lo contrario Apache arrojará un error al reiniciar:

#LoadModule slotmem_shm_module modules/mod_slotmem_shm.so

LoadModule slotmem_shm_module modules/mod_slotmem_shm.so

 

Después de realizar todas las configuraciones pertinentes reiniciar el servidor web o recargar los archivos de configuración.

/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.

 

4.Aspectos principales de configuración

 

Nota: Los archivos de configuración cuentan con breves descripciones que indican el  funcionamiento de cada directiva de ModSecurity, tomate tu tiempo para leerlas y entender cómo funcionan las directivas.

Revisa el contenido del archivo principal de configuración de ModSecurity /opt/modsec/etc/modsecurity.conf y configúralo de acuerdo a tus necesidades de seguridad,  a continuación se describen algunos aspectos importantes de configuración de este archivo.

 

Inicialización del motor de reglas

 

En esta sección se le indica al Firewall de Aplicación Web su modo de operación (activo o pasivo). Para cambiar del modo pasivo a modo activo cambia el valor de DetectionOnly por On:

# -- 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

 

 Manejo de cuerpo de peticiones

 

En esta sección se le indica al Firewall de Aplicación Web la forma en que debe tratar a las peticiones HTTP. Para permitir el análisis del cuerpo de la petición el valor de la directiva debe ser On, si deseas omitir el análisis del cuerpo de las peticiones entonces comenta la línea.

# -- 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

 

Manejo de cuerpo de respuestas

 

En esta sección se le indica al Firewall de Aplicación Web la forma en que debe tratar las respuestas HTTP. Para permitir el análisis del cuerpo de la respuesta el valor de la directiva debe ser On, si deseas omitir el análisis del cuerpo de las respuestas entonces comenta la línea.

# -- 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


 

Ubicación de archivos temporales

 

Se especifica la ubicación de los archivos temporales que genere ModSecurity durante su operación. Se recomienda especificar un directorio que sea privado. En este caso se usa la estructura de directorios generada con anterioridad. Cambiamos el valor de la directiva SecTempDir /tmp/ por SecTempDir /opt/modsec/var/tmp/:

# -- 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/
SecTmpDir /opt/modsec/var/tmp/

 

Ubicación de datos persistentes

 

Se especifica la ubicación donde los datos persistentes serán creados y almacenados temporalmente (datos de direcciones IP, datos de sesión, etcétera). Cambiamos el valor de la directiva SecDataDir /tmp/ por /opt/modsec/var/data/:

# 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/
SecDataDir /opt/modsec/var/data/

 

Configuración de archivos interceptados

 

En esta sección se especifica la ubicación donde los archivos interceptados serán almacenados. Para esta guía no se contempla el uso de esta directiva.

# -- 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


 

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

 

En esta sección se indica 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. Ajusta la ubicación de almacenado de la bitácora con la directiva 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 se especifica la ubicación donde se almacenará la bitácora de auditoría. Este 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 (por ejemplo 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, sólo 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.5 Gb en una semana aproximadamente).

Para obtener mayor información sobre este tipo de bitácoras, consultar la sección 6. Literatura recomendada.

# -- 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/


 

 Otras configuraciones

 

Dentro del archivo de configuración principal se pueden encontrar algunas directivas para casos especiales, por ejemplo se puede indicar el símbolo separador de valores en una URL o el formato de las cookies.

Estas directivas son de utilidad si tu aplicación web usa un tipo de separador y un tipo de cookie diferentes a los usados convencionalmente.

# -- 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

 

 

 Anexo 1

Instalación de paquete “apache2-prefork-dev”.

 Si deseamos reducir tiempo en el proceso de instalación, podemos descargar un paquete llamado apache2-prefork-dev ese paquete nos proporciona las bibliotecas necesarias para que ModSecurity funcione correctamente como un módulo extra de Apache y así ahorrarnos el tiempo de compilar librería por librería, teniendo todas conjugadas en un solo paquete. 

Para instalar el paquete antes descrito basta con un: apt-get install apache2-prefork-dev

Nos pide permiso para usar espacio adicional en el disco al hacer la instalación del paquete y le decimos que sí (S).

Instalación de ModSecurity 2.9.0

No olvides que se debe descargar el código fuente del servidor web Apache y del Firewall de Aplicaciones Web ModSecurity, además del conjunto de reglas de ModSecurity.

Servidor Web Apache: http://httpd.apache.org/

Descarga: http://httpd.apache.org/download.cgi#apache24

httpd-2.4.17.tar.gz

 

ModSecurity: http://www.modsecurity.org/

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

modsecurity-2.9.0.tar.gz

 

Reglas de ModSecurity (CRS - Core Rules Set): http://www.modsecurity.org/rules.html

Descarga: https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

modsecurity-crs_2.2.9.orig.tar.gz

 

Instalación de Apache HTTPD

 

# mkdir /usr/local/apache2
# tar xvfz httpd-2.4.17.tar.gz
# cd httpd-2.4.17/
# ./configure --prefix=/usr/include/apache2 \
--enable-module=so \
--enable-ssl \
--enable-unique-id \
--enable-proxy \
--enable-proxy-ftp \
--enable-proxy-http \
--enable-proxy-connect \
--enable-headers \
--enable-deflate
# make
# make install

 

Instalación de ModSecurity

 

# tar xvfz modsecurity-2.9.0.tar.gz
# cd modsecurity-2.9.0
# ./configure \
--with-apxs=/usr/bin/apxs2 \
# make
# make install

Al finalizar la instalación de ModSecurity encontrarás el archivo binario de ModSecurity en /usr/local/modsecurity/lib/mod_security2.so. Cópialo al directorio de módulos de Apache.

cp /usr/local/modsecurity/lib/mod_security2.so /usr/local/apache2/modules/

***Nota: Si tienes algún problema, puedes probar compilando y configurando las bibliotecas tú mismo, como se realiza en los puntos anteriores. No olvides que una vez que realices la instalación de Modsecurity y Apache con el paquete “apache2-prefork-dev” deberás seguir los pasos de configuración de Apache y Modsecurity del punto 3. ***

 

5.Probando la instalación de ModSecurity 

 

En un navegador web se consulta una aplicación alojada en un 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 Web 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 se tiene una instalación de ModSecurity  completa (en modo embebido).

Solo resta que se adecue a tu entorno de trabajo. 

Nota: Recuerda que al implementarse ModSecurity se requiere de un periodo de prueba para su adecuación y monitoreo.

En la primera etapa de implementación puede que surjan falsos positivos que impidan el correcto funcionamiento de la aplicación web, en cuyo caso el administrador deberá tomar las medidas necesarias, nuestra recomendación es la siguiente:

1) Desactivar la regla que causa conflictos.

Solo se recomienda esta medida cuando la vulnerabilidad o tipo de ataque al cual hace frente la regla no es crítica. Ver directiva SecRuleRemoveById.

2) Manipular los límites de anomalías en el archivo principal de reglas

Se pueden configurar los límites de bloqueo para que sean más permisivos. 

Para mayor información consultar el siguiente artículo:

https://www.trustwave.com/Resources/SpiderLabs-Blog/ModSecurity-Advanced-Topic-of-the-Week--(Updated)-Exception-Handling/

 

6.Literatura recomendada y documentación relacionada

 

ModSecurity HandBook - First 80 Pages Free.

Contiene información muy útil para entender cómo funciona ModSecurity, así como  la descripción de todas las directivas de configuración del mismo.  No es la documentación más actual pero es un buen marco de referencia.

 

Liga:https://www.feistyduck.com/books/modsecurity-handbook/gettingStarted.html

 

Manual de referencia

Sitio que contiene información detallada sobre cada una de las directivas de configuración de ModSecurity 

Liga: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual

 

Información sobre bitácoras de ModSecurity

Sitio que contiene una descripción más detallada sobre el registro en bitácoras de ModSecurity.

Liga: https://github.com/SpiderLabs/ModSecurity/wiki/ModSecurity-2-Data-Formats#Audit_Log

 

Matriz de migración

Si ya está en uso una versión antigua de ModSecurity y se planea actualizar a la versión más reciente hay algunos aspectos que se deben considerar. El siguiente sitio indica cuales.

Liga: https://github.com/SpiderLabs/ModSecurity/wiki/ModSecurity-Migration-Matrix

 

Modo de operación de ModSecurity

Explica a grandes rasgos cómo funciona el sistema de puntaje de anomalías de ModSecurity. 

Liga: https://www.trustwave.com/Resources/SpiderLabs-Blog/Advanced-Topic-of-the-Week--Traditional-vs--Anomaly-Scoring-Detection-Modes/

Revisión histórica

  • Liberación original: Viernes, 11 Diciembre 2015
  • Última revisión: Viernes, 11 Diciembre 2015

La Coordinación de Seguridad de la Información/UNAM-CERT agradece el apoyo en la elaboración y revisión de este documento a:

  • Andrés Hernández
    Sayonara Díaz
    Octavio Domínguez
    Mario Vasquez

Para mayor información acerca de este documento contactar a:

UNAM-CERT: Equipo de Respuesta a Incidentes UNAM
Coordinación de Seguridad de la Información
Dirección General de Cómputo y Tecnologías de Información y Comunicación
Universidad Nacional Autónoma de México
E-Mail: seguridad@seguridad.unam.mx
http://www.cert.org.mx
http://www.seguridad.unam.mx
ftp://ftp.seguridad.unam.mx
Tel: 56 22 81 69
Fax: 56 22 80 43


Universidad Nacional Autonoma de México Aviso legal |  Créditos |  Staff |  Administración
Copyright © Todos los derechos reservados
UNAM - CERT