Seguridad en Aplicaciones Web (III)

En el artículo anterior analizamos las herramientas de auditoría de aplicaciones web ZAP y Vega.

En esta parte, analizaremos la tecnologías que podemos implementar para mejorar la Seguridad en Aplicaciones Web desde el lado del servidor, haciendo foco en el Web Application Firewall (WAF) de ModSecurity, para comprobar qué tan fácil es implementarla y cuáles son los beneficios que nos aporta. Para esto vamos a utilizar el mismo laboratorio de pruebas del artículo anterior, a fin de lograr un buen punto de comparación de los resultados.

Introducción a ModSecurity

ModSecurity (www.modsecurity.org) es un firewall de aplicaciones web que se ejecuta como módulo de Apache (aunque ahora es compatible con IIS y Nginx, generalmente se recomienda su instalación en Apache, por ser la configuración más probada y estable.

Provee protección contra diversos ataques y permite monitorizar tráfico HTTP, así como realizar análisis en tiempo real sin necesidad de hacer cambios a la infraestructura existente.

Algunas de las funcionalidades más importantes son:

Filtrado de Peticiones: los pedidos HTTP entrantes son analizados por el módulo mod_security antes de pasarlos al servidor Web Apache, a su vez, estos pedidos son comparados contra un conjunto de reglas predefinidas para realizar las acciones correspondientes. Para realizar este filtrado se pueden utilizar expresiones regulares, permitiendo que el proceso sea flexible.

Técnicas antievasión: las rutas y los parámetros son normalizados antes del análisis para evitar técnicas de evasión.

Comprensión del protocolo HTTP: al comprender el protocolo HTTP, puede realizar filtrados específicos y granulares.

Análisis Post Payload: intercepta y analiza el contenido transmitido a través del método POST.

Log de Auditoría: es posible dejar traza de auditoría para un posterior análisis forense.

Filtrado HTTPS: al estar embebido como módulo, tiene acceso a los datos después de que estos hayan sido descifrados.

Verificación de rango de Bytes: permite detectar y bloquear shellcodes, limitando el rango de los bytes.

Soporte para ranking de anomalías y correlación básica de eventos: los contadores pueden ser automáticamente decrementados con el paso del tiempo, las variables pueden expirar.

Instalación de ModSecurity

NOTA: Para lectores que no busquen detalles técnicos de ModSecurity y les interese únicamente ver los resultados, pueden directamente saltar a la siguiente sección del artículo.
Si bien se va a detallar la instalación en Ubuntu Server, el proceso es muy similar en cualquier distribución de GNU/Linux.
Primero, debemos descargar los paquetes necesarios:

    apt-get install libapache-mod-security
    (esto va a instalar todas las dependencias necesarias)

Una vez hecho esto, tendremos que descargar las reglas de filtrado. Debemos recordar que, ModSecurity en sí es un motor para la aplicación de reglas y por sí sólo no realiza ninguna acción sobre el tráfico.

NOTA: Las reglas de filtrado van a depender de qué versión de ModSecurity vayamos a utilizar. En las pruebas que yo realicé, utilicé la versión de ModSecurity 2.6.6, que es compatible únicamente hasta la versión 2.2.5 de las reglas, por lo que descargué dicha versión desde el repositorio:
https://github.com/SpiderLabs/owasp-modsecurity-crs/releases

Descargamos el archivo de reglas en el directorio temporal y lo descomprimimos (los nombres de archivo pueden cambiar en las diferentes versiones de las reglas):

    cd /tmp
    wget

Ahora copiamos el contenido dentro del directorio ‘/etc/modsecurity’:

    cp /tmp/archivo/* /etc/modsecurity/

Movemos el archivo de la configuración recomendada de ModSecurity, para volverla productiva:

    mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Movemos el archivo general de la configuración de reglas para volverlo productivo:

    cd /etc/modsecurity
    mv modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf

Editamos la opción “SecRuleEngine” y la ponemos en “On” para habilitar la utilización del motor de reglas, así:

    SecRuleEngine On

Como las reglas están divididas en diferentes secciones en base a su nivel de madurez (Base, Optional, Experimental), vamos a habilitar únicamente las reglas más probadas, que son las que suelen traer menos problemas:

    cd /etc/modsecurity/base_rules
    for f in * ; sudo ln -s /etc/modsecurity/base_rules/$f /etc/modsecurity/activated_rules/$f ; done

(El comando anterior crea un enlace simbólico desde cada archivo que está dentro del directorio “base_rules” y lo almacena en el directorio “activated_rules”. De esta forma, configuramos cuáles reglas van a quedar activadas).

Una vez hecho esto, le decimos a ModSecurity que deb cargar todos los achivos que están presentes dentro del directorio ‘/etc/modsecurity/activated_rules’, editando el archivo ‘/etc/apache2/mods-available/mod-security.conf’ para que contenga la siguiente línea:

    Include "/etc/modsecurity/activated_rules/*.conf"

Esta línea debe quedar inmediatamente después de la línea:

    Include "/etc/modsecurity/*.conf"

Habilitamos el módulo mod-security en Apache:

    a2enmod mod-security

Reiniciamos el servicio:

    service apache2 restart

Ahora ya tenemos ModSecurity instalado y configurado, podemos pasar a probarlo.

Primeras Pruebas y Correcciones

NOTA: Para lectores que no busquen detalles técnicos de ModSecurity y les interese únicamente ver los resultados, pueden directamente saltar a la siguiente sección del artículo.

Una vez realizada la configuración básica de ModSecurity es probable que nos encontremos con que algunas de las reglas definidas interfieren con el correcto funcionamiento de nuestra aplicación. Para esto, recomiendo directamente deshabilitar las reglas conflictivas. En el caso de que sean muchas, deberemos verificar si no estamos teniendo un problema de configuración o una incompatibilidad entre la versión de ModSecurity y las reglas que tenemos instaladas.

Por ejemplo, en mi laboratorio de pruebas, ModSecurity no me permite acceder a mi sitio porque detecta que estoy tratando de acceder a través de la dirección IP y no a través del nombre de host. Obviamente, podría solucionar esto creando un nombre de host, pero prefiero mostrar cómo se deshabilita una regla en la configuración.

Primero, debemos identificar en el archivo de log de ModSecurity (por defecto: ‘/var/log/apache2/modsec_audit.log’, y puede cambiarse con la opción ‘SecAuditLog’ del archivo de configuración ‘/etc/modsecurity/modsecurity.conf’).

Podremos ver una línea de error como la siguiente:

    Message: Warning. Pattern match "^[\d.:]+$" at REQUEST_HEADERS:Host. [file "/etc/modsecurity/activated_rules/modsecurity_crs_21_protocol_anomalies.conf"] [line "98"] [id "960017"] [rev "2.2.5"] [msg "Host header is a numeric IP address"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [tag "http://technet.microsoft.com/en-us/magazine/2005.01.hackerbasher.aspx"]

Ahí podemos observar que la regla conflictiva se encuentra en la línea 98 del archivo:

    /etc/modsecurity/activated_rules/modsecurity_crs_21_protocol_anomalies.conf  

Lo único que tenemos que hacer es editar ese archivo y comentar la línea 98. Luego, reiniciamos el servicio de Apache con:

    service apache2 restart

Ahora probamos el acceso y funcionará correctamente.

Antes y Después de ModSecurity

Ahora, volvemos a correr las herramientas ZAP y Vega, que utilizamos en el artículo anterior para realizar la auditoría de seguridad de nuestra aplicación. A continuación veremos las imágenes de cada reporte, antes y después de ModSecurity:

ZAP sin ModSecurity

ZAP con ModSecurity

Vega sin ModSecurity

Vega con ModSecurity

Observamos que, en general, el número de vulnerabilidades encontradas ha caído enormemente luego de la implementación de ModSecurity. Salvando algunos detalles extraños, que habría que verificar (por ejemplo, Vega, antes de ModSecurity marcaba dos SQL Injection y con ModSecurity marca seis, pero es probable que eso sea un error de interpretación de Vega).

Resumen Comparativo

En resumen, podemos observar lo siguiente:

Claramente, la visibilidad de vulnerabilidades se ha reducido, lo cual no quiere decir que las vulnerabilidades no sean explotables pero, por lo menos, ya no son tan fáciles de detectar, lo que, a priori, podría evitar mucho ataques, porque nuestra aplicación ya no sería tan atractiva para atacantes que busquen alguna tarea sencilla de realizar.

De todos modos, debemos aclarar que un Web Application Firewall no debe, ni puede, suplantar las buenas prácticas de programación.También hemos visto que un Web Application Firewall no tiene que ser necesariamente difícil de implementar. Con dedicación y equipos dedicados para realizar pruebas, podemos lograr implementarlo exitosamente en poco tiempo.

En la próxima parte

En la próxima parte de esa serie de artículos analizaremos cómo mitigar los ataques de Denegación de Servicios (DoS) en nuestras aplicaciones web.)