Me encontre de interes para todos y para variar sobro la gripe porcina, bueno leanlo y me diran
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, 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.
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 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.
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.; y 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.
En la segunda parte del artículo veremos más información sobre todos los usos que tiene un Web Application Firewall, así como también veremos Arquitecturas de despliegue, Soluciones WAF comerciales y la parte más interesante, Implementación con ModSecurity para Apache.
Fuente: PartnerZone | Seguridad
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, 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.
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 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.
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.; y 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.
En la segunda parte del artículo veremos más información sobre todos los usos que tiene un Web Application Firewall, así como también veremos Arquitecturas de despliegue, Soluciones WAF comerciales y la parte más interesante, Implementación con ModSecurity para Apache.
Fuente: PartnerZone | Seguridad
