Los cortafuegos de aplicaciones web o WAF permiten proteger sus aplicaciones web de ataques sin necesidad de modificar la aplicación ni tocar una sola línea de código. En este artículo se explica cómo instalar una solución WAF de fuentes abiertas basada en Apache y ModSecurity.

Actualmente los ataques contra aplicaciones web se han convertido en una de las amenazas más serias para las infraestructuras de seguridad informática al poner en peligro la información corporativa y los datos confidenciales de los clientes. Tras normativas gubernamentales cada vez más estrictas en todo el mundo, y la LOPD en particular para España, proteger las aplicaciones ha dejado de ser una tarea opcional para convertirse en una obligación de toda organización que manipule datos de carácter personal.

Las aplicaciones web desplegadas en la parte pública de internet atraen ataques de hackers y gusanos, constituyendo a menudo el punto más vulnerable de las infraestructuras de red. Por consiguiente, si no se implantan fuertes medidas de seguridad a nivel de los flujos de transacciones HTTP, HTTPS y FTP, pueden llegar a erigirse en punto de entrada a las redes corporativas, desde las cuales robar información confidencial o atacar otros servidores internos. Bajo la amenaza de ataques siempre más sofisticados, como inyección de SQL, manipulación de parámetros, envenenamiento de cookies, Cross-Site Scripting (XSS), desbordamiento de búfer, entre otros, estas aplicaciones representan eslabones débiles en organizaciones sometidas a la presión de hacer crecer sus servicios web internos y externos.

Los cortafuegos tradicionales trabajan en la capa de red y de transporte, pero al dejar el puerto 80 abierto no ofrecen ninguna clase de protección para la aplicación frente a estos ataques especializados en explotar vulnerabilidades web. Hasta la aparición de los cortafuegos de aplicaciones web (Web Application Firewall o WAF), este tipo de protección sólo se podía realizar manualmente mediante una auditoría técnica y posterior revisión del código de las aplicaciones examinadas. Gracias a los WAF, este nivel de protección puede alcanzarse mediante un proceso automático y de mayor fiabilidad, sin necesidad de involucrar a los desarrolladores ni modificar las aplicaciones.

En este artículo se ofrecen distintas alternativas a la hora de decantarse por el modelo más adecuado de WAF para su organización y se explica con mayor detalle la configuración de un WAF basado en una solución de fuentes abiertas: ModSecurity para Apache.

Qué son los cortafuegos de aplicaciones

La protección de las aplicaciones web plantea un verdadero reto para las organizaciones. Los mecanismos tradicionales de protección perimetral como los cortafuegos o los IDS de red normalmente sirven de poco o de nada a la hora de frenar los ataques web. Hay que tener en cuenta que para ofrecer al exterior servicios web el cortafuegos debe dejar abiertos el puerto 80 para el protocolo HTTP y el puerto 443 para el protocolo HTTPS en caso de utilizarse el cifrado de datos con SSL. En ambos casos, los ataques dirigidos contra el servidor web están codificados en los mensajes de los protocolos HTTP/HTTPS y, por lo tanto pasan tranquilamente a través del cortafuegos. ¿Significa esta limitación que el cortafuegos no sirve de nada? ¡En absoluto! El cortafuegos de red es fundamental para proteger frente a otros tipos de ataques que también pueden ir dirigidos contra el servidor web, como ataques de denegación de servicio, o dirigidos contra otros posibles servicios del servidor web no ofrecidos al exterior. Pero eso sí, no sirven de nada contra los ataques específicos de HTTP/HTTPS.

Por otro lado, los sistemas de detección de intrusiones (Intrusion Detection System o IDS) están especializados en la detección de ataques de red, monitorizando el tráfico TCP/IP en busca de paquetes maliciosos, pero sin entrar a analizar tráfico dentro del protocolo HTTP, ya que no entienden su significado, por lo que también a ellos les pasan desapercibidos los ataques web, más aún si viajan cifrados a través de HTTPS. Aunque pueden configurarse ciertas reglas para detectar estos ataques, los NIDS no resultan apropiados ya que fueron concebidos con otra finalidad en mente.

Ni siquiera el uso de SSL protege frente a ataques web, ya que su función reside en cifrar el tráfico. En otras palabras, protege su confidencialidad e integridad, pero nada impide que las peticiones que llegan al servidor cifradas con SSL contengan ataques. A pesar de la publicidad presente en algunos sitios web que activan SSL, este protocolo no protege en absoluto frente a los ataques dirigidos contra el servidor web. ¿Entonces no sirve SSL para nada? ¡Por supuesto que sirve! Para proteger el tráfico entre cliente y servidor contra ataques de intercepción o manipulación, pero no para proteger al servidor mismo ni a su información.

¿Cómo proteger entonces las aplicaciones web? La solución evidente y a primera vista más sencilla consiste en implantar la seguridad desde el inicio en el ciclo de vida de la aplicación, es decir, diseñar y desarrollar aplicaciones web seguras. Sin embargo, este enfoque choca con grandes problemas: si bien los administradores de sistemas y de redes suelen estar formados y concienciados en materia de seguridad, no así los programadores, quienes normalmente no han recibido ninguna formación específica previniéndoles contra las vulnerabilidades habituales en aplicaciones web. En la mayoría de los casos, cuando un atacante consigue penetrar en un servidor web e incluso más allá en la red tras el servidor, lo hace gracias a vulnerabilidades en el código de la aplicación, rara vez debido a vulnerabilidades en la configuración de la plataforma (sistema operativo, servidor web) o de la red (cortafuegos, routers). Es decir, la vulnerabilidad se origina en un pobre diseño de la aplicación o en una codificación deficiente. En la práctica, la casi totalidad de problemas de seguridad derivan de una falta de validación adecuada de los datos de entrada. Aunque en los últimos años ha aumentado drásticamente el nivel de concienciación entre los desarrolladores, todavía queda un largo camino por recorrer. Por otro lado, nunca hay que perder de vista el hecho de que el cien por cien de seguridad no puede alcanzarse jamás. Los arquitectos, analistas, diseñadores y programadores son al fin y al cabo personas humanas y pueden cometer errores.

Una auditoría técnica de seguridad puede identificar las vulnerabilidades de una aplicación web, pero se trata de un proceso lento y muy costoso, normalmente subcontratado a una empresa externa especializada en prestar este servicio. A pesar de todo, una auditoría no garantiza que vayan a detectarse todos los problemas de seguridad. Es más, por muy buena que sea la auditoría, incluso aunque identificase el cien por cien de vulnerabilidades presentes en la aplicación, no deja de ser una revisión efectuada en un instante concreto en el tiempo. Sin embargo, las aplicaciones van evolucionando (unas páginas desaparecen, otras nueva