Protección de aplicaciones web mediante WAF (Web Application Firewalls) - Episodio I

Mucho se ha hablado en este blog sobre diversos mecanismos de protección de aplicaciones web programadas en PHP, como PHPIDS incluso sobre herramientas relacionadas. Este tipo de aplicaciones que se ejecutan en los propios servidores web proveen de una funcionalidad bastante interesante, desde el punto de vista de la protección de las aplicaciones web ante algunos tipos de ataque de nivel 7 como el que mencionaba Yago en el post de ayer.

Sin embargo, herramientas del tipo PHPIDS o URLScan proveen de protección de forma muy focalizada y dedicada al tipo de lenguaje de programación de las aplicaciones (PHP en caso de PHPIDS) o para el tipo de servidor Web (en el caso de URLScan sólo se integra con Microsoft IIS). No hemos mencionado en este blog aún otras posibilidades como mod_security, herramienta libre que permite integrarse en servidores Apache de forma embebida para proteger las aplicaciones servidas por ellos.

Existe, sin embargo, alternativas que proveen de un nivel de seguridad mucho más genérico ante cualquier tipo de servidor web, y ante cualquier tipo de aplicación, sin importar el lenguaje en el que estén escritas: los WAF o Web Application Firewalls. Este tipo de plataforma se integra dentro de la arquitectura de red de la organización (generalmente en la DMZ) de manera que se altera la ruta del tráfico web (HTTP y/o HTTPS) para que atraviese este dispositivo. En general se trata de una máquina que simula ser, a ojos del cliente final que solicita un recurso web (página o servicio web) el servidor final. En realidad es lo que se denomina Proxy Inverso, puesto que la petición web del cliente es analizada más o menos inteligentemente por el software WAF y, si la considera "sana", genera él una petición contra el servidor Web final (no enrruta el tráfico ni lo NATea, sino que se hacen dos peticiones diferentes, una desde el cliente hasta el WAF y una nueva desde el WAF hasta el servidor web final). Lo que viene siendo un proxy convencional, pero hacia dentro.

Con nombre y apellidos, dentro del mundo libre podemos mencionar como más conocido a mod_security. Aunque antes lo hemos mentado como módulo integrado para Apache, también puede configurarse conjuntamente con mod_proxy, de manera que se realice un análisis con mod_security y se reenvíe la petición al servidor web final que corresponda mediante mod_proxy. Como herramientas comerciales, podemos mencionar a F5 (su módulo ASM para plataformas BIG-IP), rWeb o sProxy de DenyAll, Imperva, IBM DataPower (exclusivamente para servicios Web), Barracuda (que absorbió a NetContinuum), Citrix (después de comprar Teros)

Si bien nos gustaría detallar las capacidades de unos y otros, quizá nos posicionaremos (de momento) de forma más genérica al explicar lo que todos en conjunto son capaces de hacer, indicando las características diferenciadoras entre ellos.

El funcionamiento de un WAF se basa en un proxy inverso, por lo que nos obligará a efectuar cambios en las tablas de DNS o de NAT de los cortafuegos, de manera que el tráfico que antes iba a las granjas de servidores web o de aplicaciones, ahora se direccionará a nuestro nuevo dispositivo. En la configuración del WAF habremos de indicar el servidor correspondiente al que enviamos el tráfico. Se puede virtualizar, de manera que podemos analizar varios dominios o aplicaciones con un único dispositivo, de manera que dependiendo del dominio donde vaya, se reenvíe a un servidor físico u otro. Existen WAFs que permiten interactuar en modo transparente, de manera que no es necesario hacer cambios en la topología de red ni en el flujo del tráfico, tienen como pega ante el WAF basado en proxy inverso que los despliegues requieren una parada de servicio mucho mayor, obligando además a comenzar siendo muy poco restrictivos en la política de seguridad e ir endureciéndola progresivamente, no permitiendo hacer suficientes pruebas iniciales con las aplicaciones en producción desde un primer momento sin correr riesgos como en los basados en proxy inverso.

En líneas generales, las peticiones al servidor web son analizadas por diferentes motores que llevarán a cabo comprobaciones sobre las mismas. Cada motor suele intentar evitar un conjunto de ataques según una determinada filosofía.

Por no hacer tan duro de leer de un solo viaje este análisis sobre los diferentes mecanismos de protección de los WAF, publicaré en una entrega posterior el resto del artículo.

Etiquetas: firewall