Documentación Web application firewall

IES Gran Capitán
Departamento de Informática
Ciclo Formativo de Grado Superior de
Administració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.....................................................................................................................................2
2.- Objetivos y requisitos del proyecto.................................................................................................2
3.- Estudio previo.................................................................................................................................2
3.1.- Estado actual............................................................................................................................2
3.2.- Estudio de soluciones existentes.............................................................................................2
3.3.- Solución escogida....................................................................................................................8
4.- Plan de trabajo.................................................................................................................................8
5.- Diseño..............................................................................................................................................9
5.1.- Diseño general.........................................................................................................................9
5.2.- Diseño detallado......................................................................................................................9
6.- Implantación..................................................................................................................................13
7.- Recursos........................................................................................................................................32
7.1.- Herramientas hardware..........................................................................................................32
7.2.- Herramientas software...........................................................................................................32
7.3.- Personal.................................................................................................................................33
7.4.- Presupuesto............................................................................................................................33
8.- Conclusiones.................................................................................................................................34
8.1.- Grado de consecución de objetivos.......................................................................................34
8.2.- Problemas encontrados..........................................................................................................34
8.3.- Futuras mejoras......................................................................................................................34
9.- Referencias / bibliografía..............................................................................................................35
10.- Anexos.........................................................................................................................................35
IES Gran Capitán -- C/. Arcos de la Frontera, S/N -- 14014 Córdoba -- 957-379710
http://www.iesgrancapitan.org – http://www.iesgrancapitan.org/blog04 -- informatica@iesgrancapitan.org

1.- Introducción
Los firewalls tradicionales trabajan en la capa de red pero no ofrecen ninguna clase de protección
contra los ataques especializados en explotar vulnerabilidades web. Por eso existe la necesidad de
un Web Application Firewall o WAF.
Un Web Application Firewall es un dispositivo que puede ser hardware o software que analiza el
trá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 proyecto
Objetivos:
• Estudiar las posibles soluciones hardware y software existentes en el mercado para su
posible 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 una
futura implementación.
Requisitos:
• La solución debe a ser aplicable teniendo en cuenta que el servidor web del centro se
encuentra alojado en un VPS.
• La solución debe ajustarse a las necesidades y presupuesto del centro.
3.- Estudio previo
3.1.- Estado actual
Actualmente el servidor web del centro está instalado en un VPS. Al estar en un VPS las soluciones
hardware no podrían aplicarse ya que las peticiones web se hacen directamente al VPS. Por tanto
solo podría aplicarse algunas de las soluciones software que comentaremos más adelante.
3.2.- Estudio de soluciones existentes
Soluciones Hardware
Barracuda 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 ampliamente
utilizado. Puede detectar las amenazas a nivel de aplicación en Internet, y proporciona seguridad
frente a una amplia variedad de problemas de seguridad en aplicaciones web.
Se puede integrar con los programas de Apache. Recientemente, ModSecurity lanzó la versión
2.6.0 que proporciona funciones para la integración de la API de navegación segura, el seguimiento
de 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 recursos
del mismo.
- AQTRONIX WebKnight

Es un WAF de código abierto diseñado específicamente para servidores web e ISS y está licenciado
a través de GNU. Algunas características a destacar son desbordamiento de búfer, recorrido de
directorio, 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 site
scripting, inyecciones SQL, inyección de comandos, manipulación de parámetros, y se puede
integrar fácilmente en una aplicación basada en Java. Puede usarse código existente para
proporcionar 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 de
pará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 otros
servidores 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.
- Guardian@JUMPERZ.NET
Guardian@JUMPERZ.NET 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.

Guardian@JUMPERZ.NET desconecta de inmediato la conexión TCP cuando la aplicación entra
en 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 forma
en la que podríamos aplicarlo al servidor web del centro que como ya dijimos se encuentra
alojado en Interdominios.
• Su instalación y configuración son relativamente sencillas y existe mucha información sobre
este WAF.
Esta solución no va a poder ser implementada en el servidor web del centro porque se va a proceder
a la migración a otro VPN, así que haremos una simulación de como se instalaría en modo proxy
inverso con la ayuda de dos máquinas virtuales. Una de ellas hará la vez de servidor web y la otra
actuará 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 hardware
y 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 en
soluciones 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 general
Vamos 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 web
y la otra hará de WAF en modo proxy inverso. Esto significa que el tráfico se redirigirá al WAF que
se encargará de evaluar las peticiones al servidor web y en caso de considerarse una amenaza se
rechazará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 el
servidor web del centro.
• WAF: aquí será donde instalaremos Modsecurity en modo proxy inverso y aquí será donde
se definan las reglas que evaluarán las peticiones al servidor web. Las que se consideren una
amenaza serán rechazadas.
5.2.- Diseño detallado
Como 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 el
sitio 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 que
hará 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 a
través de un cliente:
Descargamos Joomla:

Descomprimimos el contenido del zip en la carpeta /var/www y empezamos la instalación desde el
navegador 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 de
datos:

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 las
reglas 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én
crearemos enlaces simbólicos entre las carpetas optional rules y activated rules de forma que las
reglas 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. Eso
es 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 un
sencillo 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 a
nuestro servidor:
Seguimos mirando la entrada de log y vemos la respuesta a la petición (403 forbidden). Tambien
vemos 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 y
han 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 de
inyección SQL.
Vamos a realizar una prueba más. Usaremos la herramienta Acunetix Web Vulnerability Scanner
aprovechando 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 la
petición inicial fue rechazada con una respuesta de error 403 forbidden. Otro detalle importante es
ver la cookie que se ha utilizado para el ataque XSS ya que con toda seguridad aparezca reflejada en
nuestro log.
La cookie

Vamos a ver el log. Nos encontraremos con muchísimas líneas en el log pero solo mostraremos las
que 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 se
realizó 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, que
como vemos coincide con la que teníamos en el software de Acunetix:

7.- Recursos
7.1.- Herramientas hardware
La única herramienta hardware necesria ha sido el equipo con el cual he estado trabajando con las
máquinas virtuales
7.2.- Herramientas software
ModSecurity
ModSecurity es uno de los cortafuegos de aplicación de código abierto más antiguo y ampliamente
utilizado. Puede detectar las amenazas a nivel de aplicación en Internet, y proporciona seguridad
frente 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áginas
web 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 las
pruebas 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 su
posible 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 una
futura implementación.
TOTALMENTE TERMINADO
8.2.- Problemas encontrados
- Las reglas que utilizamos de la OWASP son demasiado restrictivas impiendo el acceso normal a la
página.
SOLUCIÓN: comentar la línea 98 del fichero modsecurity_crs_21_protocol_anomalies.conf y las
líneas 151 y 152 del fichero modsecurity_crs_55_application_defects.conf.
8.3.- Futuras mejoras
La configuración actual del proyecto puede ser ideal para CMS tipo Joomla, pero en cambio para
Wordpress es demasiado restrictiva y cualquier cambio en la configuración por parte del
administrador se considera un ataque.
La solución es implementar una serie excepciones para cada archivo php implicado en la gestión de
nuestro 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ía
realizar el cambio.
Implementar todas las excepciones resultaría muy laborioso y serían necesarias muchas pruebas. Por
falta de tiempo no se han podido implementar en este proyecto con lo cuál quedaría como futura
mejora.
9.- Referencias / bibliografía
http://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.- Anexos
Anexo I: Web Application Firewall

Documentación Web application firewall

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Documentación Web application firewall

Similar a Documentación Web application firewall (20)

Más de Miguel Angel López Moyano

Más de Miguel Angel López Moyano (20)

Último

Último (20)

Documentación Web application firewall