(Bueno, dado que debo incluirlo en el pequeño curso que daré esta tarde, he pensado ¿y porqué no lo subo al blog? ;-)
Web Aplication Firewall (WAF)
1 Porqué
Los cortafuegos de aplicaciones web o WAF son cada vez más populares por el hecho de poder proteger nuestras aplicaciones web sin la necesidad de modificar código ni tener un ámplio conocimiento sobre seguridad. En este artículo trataremos de explicar en qué se basan estas soluciones; y plantearemos la instalación de un WAF ModSecurity en Apache Server.
Teniendo en cuenta que las aplicaciones web se han convertido en un pilar de las empresas, del mismo modo los ataques han ido en aumento. Las infraestructuras con información corporativa, los datos confidenciales de clientes,etc.; se han convertido en un material valiosísimo al qué hay que proteger a toda costa. Con la llegada de la LOPD, podemos decir casi que, esta protección ha pasado de ser una práctica opcional, a ser una obligatoriedad en el día a día de nuestra organización.
Se debe pensar seriamente en los ataques que se puedan recibir en la parte pública de la aplicación, y por lo tanto asumir que los ataques estarán enfocados en los accesos HTTP, HTTPS y FTP. Estos accesos, son susceptibles de recibir todo tipo de ataques como desbordamiento de búfer, Cross-Site Scripting (XSS), SQL Injection, spy-cookies, etc. Por lo tanto, si no se implantan medidas de seguridad, dejamos abiertas estas puertas para que hackers y gusanos intenten acceder y atacar nuestra parte privada; y eso es un auténtico problema cuando además asumimos que la información privada irá siempre en aumento.
Los firewalls tradicionales, utilizan la capa de red y transporte, pero no necesariamente tienen que dejar el puerto 80 abierto para el acceso a/desde Internet. Así pues, no pueden ofrecer ninguna protección frente a los ataques especializados anteriormente mencionados. Antes de que aparecieran los WAF (Web Aplication Firewall), la protección se llevaba a cabo mediante una auditoría técnica de forma manual; y después revisar el código de las aplicaciones. Mediante un WAF, esto se simplifica a un proceso automático; pero además debemos tener en cuenta que será el WAF el que podremos adaptar a las necesidades, sin tener que modificar las aplicaciones.
2 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, a veces, lento. 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 nuevas se crean), la plataforma cambia (se aplican parches de seguridad, se instalan nuevos módulos, nuevas máquinas) y, en definitiva, con el tiempo el informe de auditoría va perdiendo vigencia a medida que la aplicación en su conjunto evoluciona. Además, una vez identificadas, las vulnerabilidades deben corregirse, implicando más tiempo de desarrollo y horas de programación, redundando por tanto en un mayor coste. Nuevos agujeros podrían surgir al tapar los antiguos. Incluso puede darse el caso de que algunos problemas no puedan resolverse porque se trata de aplicaciones heredadas, escritas hace muchos años, que ya nadie sabe cómo funcionan y no se atreven a tocar o de cuyo código fuente se carece porque fueron desarrolladas por empresas que han desaparecido o programadores que se marcharon.
También puede ocurrir que la auditoría, o lo que es peor, un hacker, descubra vulnerabilidades para las que no existe parche o el cual, tras ser aplicado, restaría funcionalidad u obligaría a detener servicios críticos, todas ellas opciones inaceptables, por lo que, en definitiva, la aplicación queda sin parchear y, por tanto, vulnerable.
En todos los casos anteriores existe una alternativa de protección mucho más barata, inmediata y muy eficaz: los cortafuegos de aplicaciones web (WAF). Aunque no existe un claro consenso con respecto a su definición, todo el mundo está de acuerdo en que se trata de una herramienta para filtrar las peticiones HTTP/HTTPS que llegan al servidor web de manera que se bloqueen aquellas consideradas como dañinas, dejando pasar todas las demás. A partir de esta definición básica da comienzo la divergencia de soluciones: pueden ser hardware o software, desplegadas como un dispositivo de red o como un módulo instalado en el propio servidor web, basadas en reglas que definen la firma de los ataques o basadas en la definición del tráfico normal.
3 Funciones
El WAF puede desempeñar numerosas funciones, entre las que se pueden citar:
1) dispositivo de auditoría, capaz de registrar todas las transacciones o solamente aquellas que ajusten a los criterios definidos en las firmas;
2) dispositivo de control de acceso, para controlar si las peticiones pasan o no al servidor web;
3) dispositivo de red, cuando funciona como proxy inverso, usado para centralizar el acceso, aislar respecto del exterior, distribuir la funcionalidad, mejorar el rendimiento, etc.;
4) herramienta de bastionado de la aplicación web, mediante la protección frente a debilidades identificadas en el servidor o mediante la aplicación de parches virtuales, es decir, que no se parchean realmente en el servidor sino a través de las reglas del WAF.
Un determinado WAF puede proporcionar alguna o todas de las funcionalidades anteriores. En función de las necesidades de la organización, deberá instalarse el WAF que verifique sus expectativas. Se trata de una forma de llevar a la práctica el principio de seguridad conocido como defensa en profundidad: si falla un control de seguridad introducido en la aplicación, puede que el WAF detecte el ataque y globalmente el servicio prestado siga siendo seguro.
4 Arquitecturas de despliegue
Existen dos grandes tipos de arquitecturas a la hora de desplegar un WAF: como dispositivo de red o como módulo de servidor.
Dispositivo de red
En el primer caso, el WAF es un dispositivo más de la red, que puede a su vez funcionar dentro o fuera de línea. En modo fuera de línea, el WAF está conectado a un puerto espejo del conmutador de red, de manera que recibe una copia de todo el tráfico que entra y sale del servidor web. Lo analiza y si detecta ataques puede registrarlo en un log e incluso reconfigurar las reglas del cortafuegos de red para impedir el acceso a ciertas IP maliciosas. El inconveniente de este esquema es que los ataques pueden llegar a los servidores web, ya que no se filtran las peticiones, sino que simplemente se analizan en busca de actividad sospechosa. No obstante, permite realizar otras muchas funciones de gran utilidad como se describe en el recuadro ¿Para qué sirve un WAF?
El funcionamiento en línea se produce cuando el WAF actúa como un proxy inverso que recibe todo el tráfico dirigido a los servidores web, con la posibilidad de analizarlo en busca de ataques antes de volverlo a expedir. La mayor ventaja de usar un dispositivo de red trabajando como proxy inverso es la centralización de la seguridad en un único punto de acceso, lo que permite definir reglas de aplicación a todos los servidores protegidos, aplicar controles de acceso comunes, descifrar las comunicaciones SSL para todos ellos, y concentrar los registros de auditoría en una sola máquina. Otra ventaja es la mejora del rendimiento, ya que se descarga a los servidores web de la necesidad de filtrar las peticiones y si se usa SSL se descarga asimismo a los servidores web de las costosas operaciones criptográficas. Se consigue también un mayor aislamiento de red, en la medida en que, en lugar de exponerse al exterior las direcciones de los servidores web, se utiliza únicamente la del WAF de cara al exterior. De la anterior ventaja se deduce que tiene lugar un ocultamiento al exterior de la topología de red, con la doble ganancia de proporcionar menor información a los atacantes y desacoplar la arquitectura interna de red de su interfaz con el exterior. El WAF tiene una única dirección constante de cara al exterior, sin importar los cambios internos que se realicen en la infraestructura de red.
El mayor inconveniente de un dispositivo de red como el descrito es que al tratarse de un único punto de acceso constituye un punto único de fallo. Existen varias posibilidades para paliar esta debilidad. Pueden utilizarse dos WAF en un cluster en alta disponibilidad, lo que eleva aún más la complejidad de red, o un único WAF operando en modo transparente con una tarjeta de red dual con bypass, de modo que incluso si el WAF se cae, el tráfico seguirá pasando de un puerto a otro de la tarjeta, claro que sin ningún tipo de filtrado de seguridad. En definitiva, utilizar un WAF como dispositivo de red añade una complejidad que puede llegar a ser considerable, aunque también pueden serlo sus beneficios.
Módulo servidor
En el segundo caso de arquitectura planteado, el WAF funciona en realidad como un módulo software especial para el tipo de servidor a proteger, mayoritariamente Apache o IIS. Este módulo se instala en todos y cada uno de los servidores que se deseen proteger y se configura adecuadamente. Por consiguiente, debido a su simplicidad, esta solución resulta ideal cuando sólo desea proteger un servidor web.
Para IIS existe una variedad inmensa de productos comerciales que cumplen esta función. Dentro de esta categoría podría incluirse también una solución tan elemental como la herramienta URLScan para IIS, ofrecida gratuitamente por Microsoft en www.microsoft.com/technet/security/tools/urlscan.mspx. si bien resulta tan limitada que sólo protegería frente a un puñado de ataques sencillos. Otros productos más sofisticados para IIS son SecureIIS de eEye (www.eeye.com/html/Products/SecureIIS), ThreatSentry de PrivacyWare (www.privacyware.com/intrusion_prevention.html), dotDefender de Applicure tanto para IIS como para Apache (www.applicure.com), NGSecureWeb de NGSEC para IIS, Apache e iPlanet (www.ngsec.com/ngproducts/ngsw/?lang=es).
Una solución gratuita para IIS, es WebKnight, basado en XML.
Una opción accesible para Apache es ModSecurity (www.modsecurity.org), que será discutida más adelante. Otra opción para Apache, además de las ya mencionadas, es BinarySEC (www.binarysec.com), un WAF basado en técnicas de Inteligencia Artificial para discriminar el tráfico legítimo del malicioso.
Pasaros por http://wanlinksniper.blogspot.com/ para aprender mucho más!!!
1 Porqué
Los cortafuegos de aplicaciones web o WAF son cada vez más populares por el hecho de poder proteger nuestras aplicaciones web sin la necesidad de modificar código ni tener un ámplio conocimiento sobre seguridad. En este artículo trataremos de explicar en qué se basan estas soluciones; y plantearemos la instalación de un WAF ModSecurity en Apache Server.
Teniendo en cuenta que las aplicaciones web se han convertido en un pilar de las empresas, del mismo modo los ataques han ido en aumento. Las infraestructuras con información corporativa, los datos confidenciales de clientes,etc.; se han convertido en un material valiosísimo al qué hay que proteger a toda costa. Con la llegada de la LOPD, podemos decir casi que, esta protección ha pasado de ser una práctica opcional, a ser una obligatoriedad en el día a día de nuestra organización.
Se debe pensar seriamente en los ataques que se puedan recibir en la parte pública de la aplicación, y por lo tanto asumir que los ataques estarán enfocados en los accesos HTTP, HTTPS y FTP. Estos accesos, son susceptibles de recibir todo tipo de ataques como desbordamiento de búfer, Cross-Site Scripting (XSS), SQL Injection, spy-cookies, etc. Por lo tanto, si no se implantan medidas de seguridad, dejamos abiertas estas puertas para que hackers y gusanos intenten acceder y atacar nuestra parte privada; y eso es un auténtico problema cuando además asumimos que la información privada irá siempre en aumento.
Los firewalls tradicionales, utilizan la capa de red y transporte, pero no necesariamente tienen que dejar el puerto 80 abierto para el acceso a/desde Internet. Así pues, no pueden ofrecer ninguna protección frente a los ataques especializados anteriormente mencionados. Antes de que aparecieran los WAF (Web Aplication Firewall), la protección se llevaba a cabo mediante una auditoría técnica de forma manual; y después revisar el código de las aplicaciones. Mediante un WAF, esto se simplifica a un proceso automático; pero además debemos tener en cuenta que será el WAF el que podremos adaptar a las necesidades, sin tener que modificar las aplicaciones.
2 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, a veces, lento. 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 nuevas se crean), la plataforma cambia (se aplican parches de seguridad, se instalan nuevos módulos, nuevas máquinas) y, en definitiva, con el tiempo el informe de auditoría va perdiendo vigencia a medida que la aplicación en su conjunto evoluciona. Además, una vez identificadas, las vulnerabilidades deben corregirse, implicando más tiempo de desarrollo y horas de programación, redundando por tanto en un mayor coste. Nuevos agujeros podrían surgir al tapar los antiguos. Incluso puede darse el caso de que algunos problemas no puedan resolverse porque se trata de aplicaciones heredadas, escritas hace muchos años, que ya nadie sabe cómo funcionan y no se atreven a tocar o de cuyo código fuente se carece porque fueron desarrolladas por empresas que han desaparecido o programadores que se marcharon.
También puede ocurrir que la auditoría, o lo que es peor, un hacker, descubra vulnerabilidades para las que no existe parche o el cual, tras ser aplicado, restaría funcionalidad u obligaría a detener servicios críticos, todas ellas opciones inaceptables, por lo que, en definitiva, la aplicación queda sin parchear y, por tanto, vulnerable.
En todos los casos anteriores existe una alternativa de protección mucho más barata, inmediata y muy eficaz: los cortafuegos de aplicaciones web (WAF). Aunque no existe un claro consenso con respecto a su definición, todo el mundo está de acuerdo en que se trata de una herramienta para filtrar las peticiones HTTP/HTTPS que llegan al servidor web de manera que se bloqueen aquellas consideradas como dañinas, dejando pasar todas las demás. A partir de esta definición básica da comienzo la divergencia de soluciones: pueden ser hardware o software, desplegadas como un dispositivo de red o como un módulo instalado en el propio servidor web, basadas en reglas que definen la firma de los ataques o basadas en la definición del tráfico normal.
3 Funciones
El WAF puede desempeñar numerosas funciones, entre las que se pueden citar:
1) dispositivo de auditoría, capaz de registrar todas las transacciones o solamente aquellas que ajusten a los criterios definidos en las firmas;
2) dispositivo de control de acceso, para controlar si las peticiones pasan o no al servidor web;
3) dispositivo de red, cuando funciona como proxy inverso, usado para centralizar el acceso, aislar respecto del exterior, distribuir la funcionalidad, mejorar el rendimiento, etc.;
4) herramienta de bastionado de la aplicación web, mediante la protección frente a debilidades identificadas en el servidor o mediante la aplicación de parches virtuales, es decir, que no se parchean realmente en el servidor sino a través de las reglas del WAF.
Un determinado WAF puede proporcionar alguna o todas de las funcionalidades anteriores. En función de las necesidades de la organización, deberá instalarse el WAF que verifique sus expectativas. Se trata de una forma de llevar a la práctica el principio de seguridad conocido como defensa en profundidad: si falla un control de seguridad introducido en la aplicación, puede que el WAF detecte el ataque y globalmente el servicio prestado siga siendo seguro.
4 Arquitecturas de despliegue
Existen dos grandes tipos de arquitecturas a la hora de desplegar un WAF: como dispositivo de red o como módulo de servidor.
Dispositivo de red
En el primer caso, el WAF es un dispositivo más de la red, que puede a su vez funcionar dentro o fuera de línea. En modo fuera de línea, el WAF está conectado a un puerto espejo del conmutador de red, de manera que recibe una copia de todo el tráfico que entra y sale del servidor web. Lo analiza y si detecta ataques puede registrarlo en un log e incluso reconfigurar las reglas del cortafuegos de red para impedir el acceso a ciertas IP maliciosas. El inconveniente de este esquema es que los ataques pueden llegar a los servidores web, ya que no se filtran las peticiones, sino que simplemente se analizan en busca de actividad sospechosa. No obstante, permite realizar otras muchas funciones de gran utilidad como se describe en el recuadro ¿Para qué sirve un WAF?
El funcionamiento en línea se produce cuando el WAF actúa como un proxy inverso que recibe todo el tráfico dirigido a los servidores web, con la posibilidad de analizarlo en busca de ataques antes de volverlo a expedir. La mayor ventaja de usar un dispositivo de red trabajando como proxy inverso es la centralización de la seguridad en un único punto de acceso, lo que permite definir reglas de aplicación a todos los servidores protegidos, aplicar controles de acceso comunes, descifrar las comunicaciones SSL para todos ellos, y concentrar los registros de auditoría en una sola máquina. Otra ventaja es la mejora del rendimiento, ya que se descarga a los servidores web de la necesidad de filtrar las peticiones y si se usa SSL se descarga asimismo a los servidores web de las costosas operaciones criptográficas. Se consigue también un mayor aislamiento de red, en la medida en que, en lugar de exponerse al exterior las direcciones de los servidores web, se utiliza únicamente la del WAF de cara al exterior. De la anterior ventaja se deduce que tiene lugar un ocultamiento al exterior de la topología de red, con la doble ganancia de proporcionar menor información a los atacantes y desacoplar la arquitectura interna de red de su interfaz con el exterior. El WAF tiene una única dirección constante de cara al exterior, sin importar los cambios internos que se realicen en la infraestructura de red.
El mayor inconveniente de un dispositivo de red como el descrito es que al tratarse de un único punto de acceso constituye un punto único de fallo. Existen varias posibilidades para paliar esta debilidad. Pueden utilizarse dos WAF en un cluster en alta disponibilidad, lo que eleva aún más la complejidad de red, o un único WAF operando en modo transparente con una tarjeta de red dual con bypass, de modo que incluso si el WAF se cae, el tráfico seguirá pasando de un puerto a otro de la tarjeta, claro que sin ningún tipo de filtrado de seguridad. En definitiva, utilizar un WAF como dispositivo de red añade una complejidad que puede llegar a ser considerable, aunque también pueden serlo sus beneficios.
Módulo servidor
En el segundo caso de arquitectura planteado, el WAF funciona en realidad como un módulo software especial para el tipo de servidor a proteger, mayoritariamente Apache o IIS. Este módulo se instala en todos y cada uno de los servidores que se deseen proteger y se configura adecuadamente. Por consiguiente, debido a su simplicidad, esta solución resulta ideal cuando sólo desea proteger un servidor web.
Para IIS existe una variedad inmensa de productos comerciales que cumplen esta función. Dentro de esta categoría podría incluirse también una solución tan elemental como la herramienta URLScan para IIS, ofrecida gratuitamente por Microsoft en www.microsoft.com/technet/security/tools/urlscan.mspx. si bien resulta tan limitada que sólo protegería frente a un puñado de ataques sencillos. Otros productos más sofisticados para IIS son SecureIIS de eEye (www.eeye.com/html/Products/SecureIIS), ThreatSentry de PrivacyWare (www.privacyware.com/intrusion_prevention.html), dotDefender de Applicure tanto para IIS como para Apache (www.applicure.com), NGSecureWeb de NGSEC para IIS, Apache e iPlanet (www.ngsec.com/ngproducts/ngsw/?lang=es).
Una solución gratuita para IIS, es WebKnight, basado en XML.
Una opción accesible para Apache es ModSecurity (www.modsecurity.org), que será discutida más adelante. Otra opción para Apache, además de las ya mencionadas, es BinarySEC (www.binarysec.com), un WAF basado en técnicas de Inteligencia Artificial para discriminar el tráfico legítimo del malicioso.
Pasaros por http://wanlinksniper.blogspot.com/ para aprender mucho más!!!
1 comentaris:
Yo encantado de que vengais, pero si lo que quereis es aprender de WAFs, no os molesteis en ir a mi blog, quedaros aquí y convenzamos entre todos a JOS para que escriba más artículos como éste. Estupenda música. Un abrazo.
Publicar un comentario