En la publicación anterior a esta, se ha hablado sobre como configurar MOD_SECURITY en un servidor web Apache, así como también se ha hablado de como funciona este módulo y su ciclo de vida, en esta ocasión se hablará sobre más directivas interesantes y sobre como funciona el motor de reglas de MOD_SECURITY, de esta forma se tendrá una imagen mucho más clara del funcionamiento general de este módulo en servidores web Apache.

Para comenzar se explicarán otras directivas interesantes incluidas en Mod_Security y que no se han mencionado en la publicación anterior.

SecServerSignature

Esta directiva indica la “firma” que será aplicada al servidor web para ocultar el tipo de servidor y su versión en las respuestas que genera el servidor web.

SecServerSignature IIS/6.0

Cuando se utiliza esta directiva, el header “Server” incluido en la respuesta del servidor, tendrá el valor indicado en la directiva.

SecTmpDir

Se trata de una directiva que permite definir la ruta donde se deben almacenar los ficheros temporales que generará MOD_SECURITY durante su ejecución. El valor por defecto de esta directiva (en el caso de que no se especifique en el fichero de configuración es el directorio definido por el sistema operativo).

SecTmpDir /opt/WebServerFull/httpd-2.2.22/modsecurity/var/tmp

SecDataDir

Se trata de una directiva que permite indicar la ruta donde se deben almacenar de forma persistente, ficheros generados por MOD_SECURITY. Evidentemente el directorio que se indique en esta directiva debe ser accesible (con permisos de lectura y escritura) para el usuario que ejecuta el servidor web.

SecDataDir /opt/WebServerFull/httpd-2.2.22/modsecurity/var/data

SecDebugLog

Indica la ruta donde se debe crear el fichero de debug para los eventos producidos por el módulo.

SecDebugLog /opt/WebServerFull/httpd-2.2.22/modsecurity/var/debug

SecUploadDir

Como su nombre lo indica, es una directiva que permite establecer el directorio donde mod_security almacenará los documentos subidos por el cliente (componentes File Upload).

SecUploadDir /opt/WebServerFull/httpd-2.2.22/modsecurity/var/upload

SecUploadKeepFiles

Indica que el módulo no debe interceptar ni almacenar ficheros subidos, los valores posibles de esta directiva son “On” y “Off”. El uso de esta característica, posiblemente puede producir un alto consumo de memoria y de espacio en disco, por este motivo solamente se debería utilizar en situaciones en las que sea exclusivamente necesario.

SecUploadKeepFiles Off

SecUploadFileMode

Permite definir los permisos que serán utilizados para crear los ficheros que serán subidos por los clientes, esto permite tener control sobre lo que los clientes pueden subir y los permisos que tendrán dichos ficheros .

SecUploadFileMode 600

SecUploadFileLimit

Se trata de una directiva que permite especificar el número máximo de ficheros que podrá manejar MOD_SECURITY (Ficheros subidos con un File Upload por ejemplo), el valor por defecto de esta directiva es de 100, sin embargo normalmente este valor suele ser muy alto y es recomendable establecer un valor más pequeño, especialmente para evitar situaciones de denegación de servicio.

SecUploadFileLimit 32

SecChrootDir

Se trata de una característica muy interesante que solamente esta disponible para sistemas Unix,(en el caso de windows no se puede aplicar esta directiva) y permite configurar una CHRoot Jail donde se ejecutará el proceso del servidor web.

SecChrootDir /chroot

En el ejemplo anterior, se ha creado un directorio que será el espacio de trabajo del proceso del servidor web, sin embargo, para usar esta directiva se debe seguir el siguiente procedimiento (partiendo de que se ha creado un directorio con el nombre /chroot)

  1. Crear el directorio /chroot y /chroot/opt/apache
  2. Crear un enlace simbólico desde el directorio de instalación del apache (por ejemplo /opt/apache) apuntando al directorio /chroot/opt/apache
  3. Tener correctamente instalado y configurado Apache en el directorio /opt/apache

En el caso de que se utilicen módulos como mod_fastcgi, mod_fcgid, mod_cgid es necesario tener presente que se pueden hacer ciertas cosas que pueden “romper” la jaula.

SISTEMA DE AUDITORIA DE MOD_SECURITY.

Existen algunas directivas que permiten controlar los registros de auditoria que serán producidos por este módulo, dichos registros estarán asociados con datos de las transacciones que se llevan a cabo. Esta característica es interesante, pero puede tener un costo alto, por este motivo es importante tener muchísimo cuidado con las directivas que se pueden utilizar.

SecAuditEngine

Esta directiva permite activar o desactivar el mecanismo de auditoria incluido en este módulo, sus posibles valores son: On, Off y RelevantOnly. Este último, solamente registra los eventos de error y warning, considerando estos eventos como los más críticos.

SecAuditLogRevelantStatus

Permite auditar las transacciones con códigos de respuestas HTTP definidos.

SecAuditLogRelevantStatus ^5

Con la instrucción anterior, MOD_SECURITY registrará todos los eventos relacionados con códigos HTTP 5XX

SecAuditLogStorageDir

Esta directiva permite definir el directorio donde se almacena el registro de auditoria generado por el módulo.

SecAuditLogStorageDir /opt/modsecurity/var/audit/

REGLAS EN MOD_SECURITY

Una de las características más interesantes en este módulo, es el motor de reglas que permite controlar en todo momento como va a ser el comportamiento del módulo ante determinadas circunstancias y en pasos del ciclo de vida concretos. Este es prácticamente el corazón de MOD_SECURITY, ya que sin este mecanismo, muchas de las amenazas más frecuentes, no podrían ser detectadas por si solas. Ahora bien, para los que conocen Snort, puede compararse este mecanismo, con el mecanismo de alarmas existentes en dicho software, donde se definen una serie de argumentos y de “situaciones” que en el caso de que se lleguen a producir, accionan la regla y dispará automáticamente un evento que hará lo que sea necesario.

Las directivas relacionadas con el motor de reglas de mod_security son las siguientes:

SecRuleEngine

Se encarga de activar o desactivar el motor de reglas del módulo, los posibles valores son On, Off y DetectOnly este ultimo valor se encarga de procesar las reglas pero en ningún caso intercepta las transacciones, aunque existan reglas que se encuentren configuradas para hacerlo.

SecRule

Esta es la directiva principal que permite declarar reglas para análisis de datos y posterior procesamiento. El formato de esta directiva es el siguiente:

SecRule VARIABLES OPERADOR [ACCIONES]

Donde VARIABLES indica los elementos (variables) que serán verificados por la regla. Cada regla puede definir una o varias variables a inspeccionar.

Por otro lado el OPERADOR es el mecanismo que se utilizará para procesar la regla, que puede ser, por ejemplo una expresión regular. El parámetro de ACCIONES es opcional y si es especificado, los resultados de la regla se aplicarán a las acciones que se deben llevar a cabo.

Algunos ejemplos del uso de esta directiva:

SecRule REQUEST_URI “p0rn”

En el caso de que en la URI de la transacción, se incluya la palabra “p0rn” por defecto esta petición será rechazada.

SecRule REQUEST_URI|QUERY_STRING “p0rn”

Esta es igual que la anterior, con la diferencia de que la transacción será examinada tanto en URI como en los parámetros enviados en query string (parámetros por GET).

SecRule ARGS “p0rn”

La variable ARGS es una colección que almacena todos los argumentos de cada petición realizada, en este caso, busca cualquier parámetro enviado por GET o POST que contenga la palabra “p0rn” y en el caso de que lo encuentre, la transacción será rechazada.

SecRule ARGS:param “p0rn”

En este caso, se acceder directamente a un valor simple de la colección ARGS, esto quiere decir, que si el parámetro “param” contiene la palabra “p0rn” en alguna de las peticiones realizadas por el cliente, la petición será rechazada.

SecRule ARGS:/^param_/ “p0rn”

En este caso, se ha utilizado una expresión regular simple que indica que cuando una petición del cliente tiene algún parámetro que comienza con “param_” y dicho parámetro tiene el valor de “p0rn” la petición será rechazada.

SecRule ARGS “@rx ^p0rn|^porn”

En este caso, se ha utilizado en la sección de operador una expresión regular que será validada sobre todos los argumentos de la petición del cliente y en el caso de que la expresión se cumpla, la petición será rechazada.

SecRule ARGS “@rx ^p0rn|^porn” “msg: “Ummm, I see what you are doing, bad girl!” id: 123456, log, pass”

Este ejemplo es igual al anterior con la diferencia de que en esta ocasión, se definen una serie de acciones adicionales que serán mezcladas con el listado de opciones por defecto.

SecRuleInheritance

Con esta directiva se le indica al módulo que debe heredar las reglas definidas en un contexto padre, por ejemplo si esta directiva se encuentra definida en un virtual host con valor de On, heredará las reglas definidas en el contexto de configuración global. Sus posibles valores son “On” y “Off”.

SecRuleRemoveById

En el caso de que se hereden reglas de un contexto padre gracias a la directiva SecRuleInheritance es posible eliminar algunas de dichas reglas para controlar cuales reglas se deben aplicar en un contexto determinado y cuales no. Esta directiva necesita el identificador de la regla, el cual es declarado en la sección de “ACCIONES” de una regla por medio de la palabra “id:”.

SecRuleRemoveById 1 2 10-20 “500-660” 123456

Cada Identificador se separa con espacio y pueden definirse rangos de identificadores.

SecRuleRemoveByMsg

En el caso de que se hereden reglas de un contexto padre gracias a la directiva SecRuleInheritance es posible eliminar algunas de dichas reglas para controlar cuales reglas se deben aplicar en un contexto determinado y cuales no. Esta directiva necesita el mensaje de la regla, el cual es declarado en la sección de “ACCIONES” de una regla por medio de la palabra “msg:”.

SecRuleRemoveByMsg “Ummm, I see what you are doing, bad girl!”