Apache: guardar peticiones POST en los logs

De un tiempo a esta parte muchos de los ataques que sufren los portales web se materializan en peticiones POST. Inyecciones SQL, inclusión de ficheros remotos o envenenamiento de parámetros son sólo algunos de los ataques en los que intervienen peticiones POST.

El problema es que por regla general la información de las peticiones POST no se guarda en los logs, por lo que al hacer un análisis forense a un equipo atacado, generalmente nos falta información para poder esclarecer el origen del compromiso o la información que se ha podido ver comprometida.

Por ello vamos a ver, centrados en el servidor web Apache, las posibilidades que existen para guardar el contenido de las peticiones POST que se hacen a nuestro servidor web.

Antes de continuar debemos tener en cuenta que activar estos logs puede llegar a consumir una gran cantidad recursos en el servidor web, por lo que debemos monitorizar muy de cerca el consumo de recursos de la máquina, sobre todo el espacio en disco, para evitar saturaciones.

La primera de las opciones que tenemos es utilizar mod_dumpio. Este módulo, desarrollado y mantenido por la fundación Apache y disponible a partir de la versión 2.1.3 de la aplicación, está pensado para tareas de depuración y guarda toda la entrada/salida que genera el servidor web en el log de error. Su configuración es muy sencilla ya que únicamente consta de las siguientes directivas:

# Salva todos los datos de entrada en el log de error.
DumpIOInput On|Off
# Salva todos los datos de salida en el log de error.
DumpIOOutput On|Off
# Define el nivel de criticidad que tendrán los datos generados por este módulo.
DumpIOLogLevel level

Esta opción es muy sencilla y ligera, pero tiene a mi juicio dos problemas: que guarda más información de depuración además del contenido de las peticiones POST y que no se puede configurar dónde se quieren guardar los registros que se generan.

La segunda opción es mod_dumpost. Este pequeño módulo, desarrollado por Hoang-Vu Dang, está específicamente diseñado para guardar el contenido de las peticiones POST. Por defecto se guardan en el log de error, pero se puede configurar la salida a otro fichero sin problemas. En la página de GitHub del módulo se pueden encontrar los requisitos, instrucciones para compilar el módulo, y los parámetros de configuración de que dispone, todos ellos opcionales.

A pesar de ser otra opción ligera y de facil configuración, el hecho de tener que compilarla puede ser un problema en determinados entornos.

Por último tenemos ModSecurity, uno de los cortafuegos a nivel de aplicación (WAF – Web Application Firewalls) más conocidos de la actualidad. Es una aplicación muy completa y potente, que soporta además de Apache otros servidores web como Nginx e IIS, y que con la configuración correcta puede cortar el tráfico relativo a ataques para que no lleguen a nuestra aplicación web, mientras que con una configuración básica puede utilizarse para simplemente guardar el contenido de las peticiones POST.

ModSecurity está disponible de paquete en la mayoría de distribuciones Linux, por lo que su instalación es muy sencilla, y puede servir para nuestros propósitos añadiendo las siguientes líneas al fichero de configuración por defecto (en Debian/Ubuntu /etc/modsecurity/modsecurity.conf):

SecDefaultAction "nolog,noauditlog,allow,phase:2"

SecRule REQUEST_METHOD "POST" "allow,phase:2,auditlog"

Con esto obtendremos el contenido completo de las peticiones POST en el log por defecto de ModSecurity (en Debian/Ubuntu /var/log/apache2/modsec_auditlog.log).

Como hemos indicado, ModSecurity es muy potente, y trae por defecto un conjunto de reglas para diferentes propósitos, disponibles en el directorio /usr/share/modsecurity/crs/. En este artículo (en inglés) se puede encontrar un ejemplo de instalación y configuración de esta aplicación en Ubuntu utilizando el conjunto de reglas por defecto para parar ataques más comunes. Adicionalmente, para los usuarios de administraciones públicas españolas existe una guía del Centro Criptológico Nacional (la CCN-STIC 661), que trata la instalación y configuración de esta aplicación.

Como punto “negativo”, indicar que su versatilidad y potencia lo hacen un producto más pesado que el resto de alternativas, cuyo rendimiento debe ser tomado en cuenta en entornos con carga elevada.

Mi recomendación, una vez presentadas todas las opciones, es que, si el tiempo y los recursos disponibles nos lo permiten, optemos por implantar ModSecurity por su versatilidad y potencia. Las otras opciones son útiles en entornos más pequeños donde queremos tener resultados rápidamente, pero para entornos de producción siempre es recomendable contar con el nivel de protección adicional que puede ofrecer ModSecurity.

Sea cual sea la opción que se elija, recordar que se deben tener muy en cuenta los recursos que consumen todas las alternativas, tanto en lo que respecta al espacio en disco ocupado como a la capacidad de procesamiento de la máquina, ya que cualquiera de estas opciones puede llegar a saturar el sistema en poco tiempo, con los problemas que esto conlleva.

Trackbacks

  1. […] De un tiempo a esta parte muchos de los ataques que sufren los portales web se materializan en peticiones POST. Inyecciones SQL, inclusión de ficheros remotos o envenenamiento de parámetros son sól…  […]