Documentación Web application firewall

IES Gran CapitánDepartamento de Informática

Ciclo Formativo de Grado Superior deAdministración de Sistemas Informáticos

Módulo de Proyecto Integrado

Miguel Ángel López Moyano – 2013/2014

Proyecto: Web Application Firewall

Curso 2013/2014

Índice de contenido

1.- Introducción.....................................................................................................................................22.- Objetivos y requisitos del proyecto.................................................................................................23.- Estudio previo.................................................................................................................................2

3.1.- Estado actual............................................................................................................................23.2.- Estudio de soluciones existentes.............................................................................................23.3.- Solución escogida....................................................................................................................8

4.- Plan de trabajo.................................................................................................................................85.- Diseño..............................................................................................................................................9

5.1.- Diseño general.........................................................................................................................95.2.- Diseño detallado......................................................................................................................9

6.- Implantación..................................................................................................................................137.- Recursos........................................................................................................................................32

7.1.- Herramientas hardware..........................................................................................................327.2.- Herramientas software...........................................................................................................327.3.- Personal.................................................................................................................................337.4.- Presupuesto............................................................................................................................33

8.- Conclusiones.................................................................................................................................348.1.- Grado de consecución de objetivos.......................................................................................348.2.- Problemas encontrados..........................................................................................................348.3.- Futuras mejoras......................................................................................................................34

9.- Referencias / bibliografía..............................................................................................................3510.- Anexos.........................................................................................................................................35

IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- [email protected]

1.- IntroducciónLos firewalls tradicionales trabajan en la capa de red pero no ofrecen ninguna clase de proteccióncontra los ataques especializados en explotar vulnerabilidades web. Por eso existe la necesidad deun Web Application Firewall o WAF.

Un Web Application Firewall es un dispositivo que puede ser hardware o software que analiza eltráfico web (entre el servidor web y la WAN) y protege de diversos ataques como SQL Injection,Cross Site Scripting, etc. Protege de ataques dirigidos al servidor web que los IDS/IPS no pueden.

2.- Objetivos y requisitos del proyectoObjetivos:

• Estudiar las posibles soluciones hardware y software existentes en el mercado para suposible implementación.

• Seleccionar la solución que más se ajuste a las necesidades y presupuesto del centro.

• Implementar la solución elegida en una máquina virtual que sirva de referencia para unafutura implementación.

Requisitos:

• La solución debe a ser aplicable teniendo en cuenta que el servidor web del centro seencuentra alojado en un VPS.

• La solución debe ajustarse a las necesidades y presupuesto del centro.

3.- Estudio previo

3.1.- Estado actualActualmente el servidor web del centro está instalado en un VPS. Al estar en un VPS las solucioneshardware no podrían aplicarse ya que las peticiones web se hacen directamente al VPS. Por tantosolo podría aplicarse algunas de las soluciones software que comentaremos más adelante.

3.2.- Estudio de soluciones existentes

Soluciones HardwareBarracuda Web Application Firewal 360

- Entre 1 y 5 Servidores

- Rendimiento: 25 Mbps

- 3000 Transacciones HTTP por segundo.

- 2000 Transacciones SSL por segundo.


Características:

• Validación de los protocolos HTTP/S, FTP• Validación de metadatos de campos de formulario• Encubrimiento de sitio web• Control de respuesta• Protección contra robo de datos.• Control de subida de archivos.• Registro, supervisión y presentación de informes• Descarga SSL• Autenticación y autorización• Integración de scanner de vulnerabilidad• Gestión centralizada• Reputación de cliente por IP• Cortafuegos de red• Alta disponibilidad : Activo / Pasivo

Cisco ACE Web Application Firewall

Características:

• Proxy inverso

• Modo monitor

• Desbordamiento del búfer

• Bloqueo de byte nulo

• Normalización de codificación de entrada

• Acciones de cortafuegos flexibles.

• Manipulación de cookies y sesiones.

• Cross-site scripting (XSS)

• Inyección de comandos e inyección SQL.

• Modelos de seguridad positiva y negativa.

• Reglas y firmas personalizadas

• Algoritmos criptográficos

• Soporte completo para SSL v2/3 con conjuntos de cifrados configurables.

• Protección contra robo de datos.

• Encubrimiento de sitio web.

• SNMP


Citrix NetScaler Application Firewall

Características:

• Reescritura de comandos entre sitios.

• Falsificación de la solicitud entre sitios.

• Inyección de comandos e inyección SQL.

• Seguridad XML

• Desbordamiento del búfer

• Protección contra robo de datos

• Protección contra ataques conocidos y desconocidos adicionales

• Autenticación y autorización

• Cross-site scripting (XSS)

• Descarga SSL

• Manipulación de cookies y sesiones

• SNMP

• Algoritmos criptográficos

• Filtrado de contenidos.

• Validación de metadatos de campos de formulario

• Transformación de URL.

Soluciones Software

Open Source:


- ModSecurity (Trustwave SpiderLabs)

ModSecurity es uno de los cortafuegos de aplicación de código abierto más antiguo y ampliamenteutilizado. Puede detectar las amenazas a nivel de aplicación en Internet, y proporciona seguridadfrente a una amplia variedad de problemas de seguridad en aplicaciones web.

Se puede integrar con los programas de Apache. Recientemente, ModSecurity lanzó la versión2.6.0 que proporciona funciones para la integración de la API de navegación segura, el seguimientode los datos sensibles y las características de modificación de datos.

Ventajas:

• Puede usarse en “embedded mode” (como un módulo más de Apache).

• Es gratuito.

Inconvenientes:

• En “embedded mode” solo puede proteger el servidor web local y se consumirán recursosdel mismo.

- AQTRONIX WebKnight


Es un WAF de código abierto diseñado específicamente para servidores web e ISS y está licenciadoa través de GNU. Algunas características a destacar son desbordamiento de búfer, recorrido dedirectorio, codificación e inyección SQL para identificar y restringir los ataques.

Ventajas:

• Es gratuito.

Inconvenientes:

• Solo disponible para Windows.

• Está más orientado para uso uso con ISS.

- WebCastellum

WebCastellum es un WAF basado en Java que puede proteger la aplicación contra cross sitescripting, inyecciones SQL, inyección de comandos, manipulación de parámetros, y se puedeintegrar fácilmente en una aplicación basada en Java. Puede usarse código existente paraproporcionar una mayor protección protección.

Ventajas:

• Facilidad en la integración de aplicaciones web existentes o aplicaciones Java nuevas.

Inconvenientes:

• No es gratuito.


- Binarysec

Es un WAF por software que protege las aplicaciones bloqueando solicitudes sospechosas.Proporciona protección contra cross site scripting, inyección de comandos, manipulación deparámetros, desbordamiento de búfer, salto de directorio, inyección de SQL y obstrucción ataque.El software se instala en apenas 10 minutos y la interfaz de usuario puede gestionar Apache y otrosservidores web y muchos sitios en una sola máquina.

Ventajas:

• Instalación rápida y sencilla.

• Gestión de todos los servidores web y sitios mediante un sencillo interfaz.

Inconvenientes:

• No es gratuito.

- [email protected]

[email protected] es un firewall de nivel de aplicación de código abierto para HTTPS /HTTP y se evalúa el tráfico HTTP / HTTPS para proteger la aplicación Web de ataques externos.


[email protected] desconecta de inmediato la conexión TCP cuando la aplicación entraen contacto con una solicitud maliciosa o no autorizada.

Ventajas:

• Es gratuito.

Inconvenientes:

• Escasa información acerca de este WAF.

3.3.- Solución escogida

La solución escogida es Modsecurity. Se ha elegido esta solución por varias razones:

• Es gratuito y de código abierto.

• Puede instalarse como proxy inverso y también en embedded mode, que sería la única formaen la que podríamos aplicarlo al servidor web del centro que como ya dijimos se encuentraalojado en Interdominios.

• Su instalación y configuración son relativamente sencillas y existe mucha información sobreeste WAF.

Esta solución no va a poder ser implementada en el servidor web del centro porque se va a procedera la migración a otro VPN, así que haremos una simulación de como se instalaría en modo proxyinverso con la ayuda de dos máquinas virtuales. Una de ellas hará la vez de servidor web y la otraactuará como WAF.

4.- Plan de trabajo

Semana Trabajo realizado

17/03/14 Recopilación de información sobre el proyecto.

24/03/14 Recopilación de información concreta sobre objetivos, requisitos, soluciones hardwarey soluciones software

31/03/14 Corrección de los objetivos, requisitos y estado actual

07/04/14 Corrección de los objetivos, requisitos y estado actual. Añadir pros y contras ensoluciones existentes.

21/04/14 Revisión del proyecto en el centro para concretar y avanzar el proyecto.

28/04/14 Selección de la solución a implementar.

05/05/14 Busqueda de información de la solución elegida.

12/05/14 Implementación de la solución elegida.


5.- Diseño

5.1.- Diseño generalVamos a ver como sería el diseño de nuestra solución:

Como puede verse en el esquema van a intervenir dos máquinas virtuales. Una hará de servidor weby la otra hará de WAF en modo proxy inverso. Esto significa que el tráfico se redirigirá al WAF quese encargará de evaluar las peticiones al servidor web y en caso de considerarse una amenaza serechazarán.

Vamos a ver con más detalle cada una de las dos máquinas:

• Servidor Web: aquí será donde instalaremos nuestro servidor web (Apache) y dos páginas(un Wordpress y un Joomla) intentando imitar la estructura que hay ahora mismo en elservidor web del centro.

• WAF: aquí será donde instalaremos Modsecurity en modo proxy inverso y aquí será dondese definan las reglas que evaluarán las peticiones al servidor web. Las que se consideren unaamenaza serán rechazadas.

5.2.- Diseño detalladoComo ya se comentó anteriormente esta será la estructura que tendremos:


A continuación detallaremos cada una de las máquinas que intervienen en el diseño:

Servidor Web

Máquina virtual Debian 7 (sin entorno gráfico)

✔ Memoria 384 MB RAM

Se ha asignado esta cantidad de memoria porque es la recomendada para una máquina Debian sin entorno gráfico.

✔ Adaptador de red eth0 en modo red interna (192.168.0.1)

Solo se dispondrá de un adaptador de red en modo red interna para su comunicación con el WAF. No queremos que nadie pueda acceder a él desde “fuera” saltándose el WAF.

Paquetes instalados:

✔ Apache2

Necesitamos instalar Apache ya que será el servidor web donde alojaremos las dos páginas que simularán la estructura que tenemos en el centro.

✔ PHP5


Necesitamos instalar PHP para poder instalar Wordpress y Joomla.

✔ MySQL Server

Es imprescindible su instalación ya que necesitaremos bases de datos para la instalación de Wordpress y Joomla.

✔ PhpMyAdmin

En este caso no es obligatoria su instalación, pero resulta más cómodo para la creación de las bases de datos.

CMS

✔ Joomla (www.iesgrancapitan.org)

Se ha instalado Joomla porque la página principal del centro es también Joomla. En cambio en nuestro proyecto tendremos que ponerle otra URL porque sino entraría en conflicto con elsitio que ya existe. El nuestro se llamará www.waf.gcap.net

✔ Wordpress (www.iesgrancapitan.org/blog04)

Hemos instalado Wordpress porque Sisblog es un Wordpress y nuestra intención es tener una estructura lo más parecida a la del centro. En nuestro caso la URL será: www.waf.gcap.net/blog04

Web Application Firewall

Máquina virtual Debian 7 (sin entorno gráfico)

✔ Memoria 384 MB RAM

Se ha asignado esta cantidad de memoria porque es la recomendada para una máquina Debian sin entorno gráfico.


✔ Adaptador de red eth0 en modo puente (192.168.112.X)

Utilizaremos este adaptador para la comunicación con el “exterior”, es decir, para visitar los sitios alojados en el servidor web tendrán que pasar por el WAF.

✔ Adaptador de red eth1 en modo red interna (192.168.0.2)

Este adaptador permitirá la comunicación entre el WAF y el servidor web.

Paquetes instalados:

✔ Apache2

Necesitaremos instalar Apache ya que Modsecurity es precisamente un módulo de Apache.

✔ PHP5

También necsitaremos instalar PHP.

✔ Bind

En este caso el servidor DNS no era necesario, pero es más correcto usar una URL que una dirección IP.

✔ Libxml2, libxml2-dev y libxml2-utils

Estas librerías son necesarias para la instalación de Modsecurity.

✔ Libaprutil1 y libaprutil1-dev

Al igual que las anteriores estas librerías también son necesarias.


✔ Libapache-mod-security

Este paquete instala Modsecurity, imprescindible en la implementación del proyecto.

6.- Implantación

Servidor Web

Instalación de Apache, PHP, MySQL y PhpMyAdmin.


Ahora siguiendo la estructura que tiene el servidor web del centro instalaremos el CMS Joomla quehará las veces de www.iesgrancapitan.org y un Wordpress que hará de Sisblog(www.iesgrancapitan.org/blog04).

Primero instalaremos Joomla, así que vamos a crear una base de datos con ayuda de phpmyadmin através de un cliente:

Descargamos Joomla:


Descomprimimos el contenido del zip en la carpeta /var/www y empezamos la instalación desde elnavegador del cliente.

Una vez instalado vemos como se quedaría:

Ahora vamos a instalar Wordpress que hará las veces de Sisblog. Primero creamos una base dedatos:


Descargamos Wordpress:

Una vez descargado descomprimos el contenido en la carpeta /var/www/blog04

Iniciamos la instalación de Wordpress desde el cliente:


Una vez instalado vemos como quedaría:

Visto así este Sisblog no se parece al que está en el centro, así que instalaremos el mismo tema:


Con esto tendríamos una estructura similar a la que tiene el servidor web del centro.

Web Application Firewall

Instalación de Apache y PHP.


Instalamos DNS.

Configuramos las zonas.


Instalación de dependencias de Mod Security.

Instalación de Mod Security.


Configuración de reglas básicas:

Ahora tenemos que instalar las reglas de la última actualización de la OWASP. Se instalan todas lasreglas y luego decidimos cuales queremos aplicar metiéndolas en la carpeta Activated Rules.


Ahora crearemos enlaces simbólicos entre las carpetas base rules y activated rules. Tambiéncrearemos enlaces simbólicos entre las carpetas optional rules y activated rules de forma que lasreglas activadas sean las básicas más las opcionales.

Editamos el fichero mod-security.conf


Habilitamos el módulo headers

Reiniciamos Apache

Ahora vamos a configurar la parte del proxy inverso.

Editamos el fichero /etc/apache2/sites/available/default


Reiniciamos Apache e intentamos acceder normalmente a la web, pero nos rechaza la petición. Esoes debido a que algunas de las reglas son demasiado restrictivas. Tendremos que editar dos de ellas:

Editamos el fichero /etc/modsecurity/activated_rules/modsecurity_crs_21_protocol_anomalies.conf

Debemos comentar la línea 98:

Editamos el fichero /etc/modsecurity/activated_rules/modsecurity_crs_55_application_defects.conf

Debemos comentar las líneas 151 y 152:


Reiniciamos Apache y vamos a hacer una pequeña prueba. Vamos a intentar desde el cliente unsencillo ataque de inyección SQL.

Aquí vemos nuestro Sisblog

Ahora si intentamos realizar un ataque de inyección SQL esto es lo que nos sale


Vemos como se rechaza la conexión. Vamos a ver el fichero de log

Lo primero que vemos es el día y la hora del ataque. La IP del atacante y la petición que ha hecho anuestro servidor:

Seguimos mirando la entrada de log y vemos la respuesta a la petición (403 forbidden). Tambienvemos la página que se genera en respuesta a la petición.


Ahora viene la parte más interesante. Aquí podemos ver cuales son las reglas que se han activado yhan detenido el ataque:

En esta captura no se ve bien, pero si nos movemos más a la derecha:


Como bien puede verse la regla que se ha activado es la 41, que hace referencia a los ataques deinyección SQL.

Vamos a realizar una prueba más. Usaremos la herramienta Acunetix Web Vulnerability Scanneraprovechando que nos permite un período de prueba de 14 días.

Dentro del asistente indicamos la URL:

Ahora en Scanning Profile indicamos XSS


Pulsamos sobre Next. Después sobre Next. Y finalmente en Finish.

Una vez realizado el ataque vemos los resultados:


Si nos fijamos vemos que no se han detectado vulnerabilidades XSS y en el informe vemos que lapetición inicial fue rechazada con una respuesta de error 403 forbidden. Otro detalle importante esver la cookie que se ha utilizado para el ataque XSS ya que con toda seguridad aparezca reflejada ennuestro log.

La cookie


Vamos a ver el log. Nos encontraremos con muchísimas líneas en el log pero solo mostraremos lasque tengan información relevante:

Aquí vemos el día y la hora del ataque, la IP del atacante, la web atacada, el producto con el que serealizó el ataque y la respuesta por parte del waf.

Aquí podemos ver además del día y la hora la cookie que se intentó aprovechar para el ataque, quecomo vemos coincide con la que teníamos en el software de Acunetix:


7.- Recursos

7.1.- Herramientas hardwareLa única herramienta hardware necesria ha sido el equipo con el cual he estado trabajando con lasmáquinas virtuales

7.2.- Herramientas software

ModSecurity

ModSecurity es uno de los cortafuegos de aplicación de código abierto más antiguo y ampliamenteutilizado. Puede detectar las amenazas a nivel de aplicación en Internet, y proporciona seguridadfrente a una amplia variedad de problemas de seguridad en aplicaciones web.

Acunetix Web Vulnerability Scanner


Acunetix Web Vulnerability Scanner es un software que nos permite realizar auditorías a páginasweb y aplicaciones web. Es capaz de detectar numerosas vulnerabilidades entre ellas SQL Injection,XSS, etc.

Es un software de pago, pero permite un período de prueba de 14 días, suficiente para realizar laspruebas en nuestro sistema.

7.3.- Personal

7.4.- Presupuesto


8.- Conclusiones

8.1.- Grado de consecución de objetivos

• Estudiar las posibles soluciones hardware y software existentes en el mercado para suposible implementación.

TOTALMENTE TERMINADO.

• Seleccionar la solución que más se ajuste a las necesidades y presupuesto del centro.

TOTALMENTE TERMINADO

• Implementar la solución elegida en una máquina virtual que sirva de referencia para unafutura implementación.

TOTALMENTE TERMINADO

8.2.- Problemas encontrados- Las reglas que utilizamos de la OWASP son demasiado restrictivas impiendo el acceso normal a lapágina.

SOLUCIÓN: comentar la línea 98 del fichero modsecurity_crs_21_protocol_anomalies.conf y laslíneas 151 y 152 del fichero modsecurity_crs_55_application_defects.conf.

8.3.- Futuras mejorasLa configuración actual del proyecto puede ser ideal para CMS tipo Joomla, pero en cambio paraWordpress es demasiado restrictiva y cualquier cambio en la configuración por parte deladministrador se considera un ataque.

La solución es implementar una serie excepciones para cada archivo php implicado en la gestión denuestro Wordpress. Un ejemplo sería éste:

<LocationMatch "/wp-admin/options.php">

SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904

SecRuleRemoveById phpids-17






</LocationMatch>

De esta forma al cambiar cualquier parámetro en el fichero options.php el waf ya no nos impediríarealizar el cambio.

Implementar todas las excepciones resultaría muy laborioso y serían necesarias muchas pruebas. Porfalta de tiempo no se han podido implementar en este proyecto con lo cuál quedaría como futuramejora.

9.- Referencias / bibliografíahttp://www.securitybydefault.com

http://www.blogtecnico.net/web-application-firewall-waf/

https://www.barracuda.com/products/webapplicationfirewall/models

http://www.cisco.com/c/en/us/products/collateral/application-networking-services/ace-web-application-firewall/data_sheet_c78-458627.html

http://www.citrix.es/products/netscaler-appfirewall/overview.html

http://www.fromdev.com/2011/07/opensource-web-application-firewall-waf.html

http://www.root25.com/2012/11/how-to-install-modsecurity-on-apache-ubuntu12-stepbystep-tutorial.html

http://www.root25.com/2012/12/how-to-impelement-reverse-proxy-with-modsecurity.html

10.- AnexosAnexo I: Web Application Firewall


Education

Documentación Web application firewall