Esta guía trata la función, los componentes y la implementación práctica de un cortafuegos de aplicaciones web (WAF).
Definición de un cortafuegos de aplicaciones web
Un cortafuegos de aplicaciones web (WAF) es un sistema de seguridad para la supervisión, el filtrado y el bloqueo del tráfico HTTP hacia y desde una aplicación web. A diferencia de un firewall de red tradicional, que opera en las capas de red y de transporte (capa 3 y 4) del modelo OSI y filtra el tráfico principalmente en función de direcciones IP y puertos, un WAF trabaja en la capa de aplicación (capa 7).
Esta posición permite al WAF analizar el contenido de la comunicación. Examina las solicitudes GET y POST en busca de patrones de ataque dirigidos a la lógica de la aplicación. Entre ellos se incluyen, entre otros, Cross-Site Scripting (XSS) e inyección SQL.
Tras describirse el funcionamiento básico de un cortafuegos de aplicaciones web, surge la pregunta de qué estándares y directrices establecidos ofrecen orientación práctica para su implementación. Aquí es donde entra OWASP.
El papel de OWASP
La efectividad de un WAF depende de la calidad de su conjunto de reglas. El Open Web Application Security Project (OWASP) es una organización que establece estándares en el ámbito de la seguridad de aplicaciones web.
- OWASP Top 10: Se trata de un documento actualizado periódicamente que enumera los diez riesgos de seguridad más críticos para aplicaciones web. Un WAF está diseñado para contrarrestar ataques que explotan estas vulnerabilidades.
- OWASP ModSecurity Core Rule Set (CRS): El CRS es un conjunto de reglas de detección de ataques de código abierto para WAF. Proporciona una base estandarizada y revisada por expertos para la detección de amenazas. Un motor WAF como ModSecurity utiliza el CRS para evaluar las solicitudes.
El OWASP Core Rule Set (CRS) ofrece una colección de reglas predefinidas que pretenden reconocer y mitigar ataques típicos como inyección SQL, Cross-Site Scripting o ejecución remota de código. Cada archivo de reglas cubre un vector de ataque o área de seguridad específica y se puede activar o adaptar según sea necesario.
| Regeldatei | Zweck |
|---|---|
| REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example | Este archivo es una plantilla para definir excepciones. Aquí se puede establecer que determinadas solicitudes o parámetros no sean verificados por las reglas. Por ejemplo, se puede excluir campos concretos de un formulario de inicio de sesión, como “password”, si de otro modo se clasificaran erróneamente como sospechosos. |
| REQUEST-910-IP-REPUTATION.conf | Aquí se verifican direcciones IP. Si una IP figura en una lista conocida de orígenes maliciosos, el acceso puede bloquearse inmediatamente. De este modo, se pueden detener pronto los ataques de botnets o de atacantes ya identificados. |
| REQUEST-920-PROTOCOL-ENFORCEMENT.conf | Estas reglas aseguran que las solicitudes HTTP cumplan con el estándar. Se detectan y rechazan las solicitudes erróneas o intencionadamente manipuladas (por ejemplo, métodos no válidos, encabezados incompletos). Esto impone una “comunicación limpia”. |
| REQUEST-930-APPLICATION-ATTACK-LFI.conf | Protege contra Local File Inclusion (LFI). En este ataque, un atacante intenta incluir archivos del servidor que no deberían ser accesibles (p. ej., /etc/passwd). Estas reglas impiden el acceso a archivos del sistema internos. |
| REQUEST-931-APPLICATION-ATTACK-RFI.conf | Protege contra Remote File Inclusion (RFI). En este caso, los atacantes intentan cargar y ejecutar archivos externos desde otros servidores. Las reglas bloquean estos intentos para mantener el código malicioso fuera. |
| REQUEST-932-APPLICATION-ATTACK-RCE.conf | Protección contra Remote Code Execution (RCE). Estos ataques tienen como objetivo ejecutar comandos directamente en el servidor. Las reglas reconocen patrones típicos como exec() o comandos de shell en las solicitudes y así evitan la toma de control del sistema. |
| REQUEST-933-APPLICATION-ATTACK-PHP.conf | Reglas especiales para aplicaciones PHP. Muchos ataques aprovechan vulnerabilidades conocidas o funciones inseguras de PHP. Estas reglas reconocen construcciones peligrosas como manipulaciones de php://input o el uso indebido de variables |
| REQUEST-941-APPLICATION-ATTACK-XSS.conf | Protección contra Cross-Site Scripting (XSS). Los atacantes intentan inyectar código JavaScript malicioso en las páginas web. Estas reglas reconocen patrones típicos como |
| REQUEST-942-APPLICATION-ATTACK-SQLI.conf | Protección contra inyección SQL (SQLi). Los atacantes intentan manipular consultas a la base de datos, por ejemplo escribiendo OR 1=1 en los campos de entrada. Estas reglas reconocen dichos patrones y evitan accesos no deseados a la base de datos. |
| REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf | Protege contra la fijación de sesión (session fixation). Los atacantes intentan insertar una ID de sesión específica a un usuario para luego apoderarse de la misma sesión. Las reglas buscan manipulaciones sospechosas de las IDs de sesión. |
| REQUEST-949-BLOCKING-EVALUATION.conf | Este archivo resume las comprobaciones anteriores y decide si una solicitud debe bloquearse de forma definitiva. Aquí se pondera cuántas infracciones contiene una solicitud y si son lo suficientemente graves como para justificar un bloqueo. |
| RESPONSE-950-DATA-LEAKAGES.conf | Estas reglas inspeccionan las respuestas del servidor en busca de fugas de datos no deseadas. A menudo, los mensajes de error contienen información sensible sobre la aplicación o el sistema. Las reglas detectan estas fugas y pueden bloquear o modificar la salida. |
| RESPONSE-951-DATA-LEAKAGES-SQL.conf | Reglas especializadas para detectar mensajes de error SQL en las respuestas. Estos mensajes a menudo revelan detalles sobre tablas, columnas o bases de datos que un atacante podría explotar. |
| RESPONSE-952-DATA-LEAKAGES-JAVA.conf | Protección contra la salida de errores de Java. Las aplicaciones Java suelen devolver rastros de pila completos en caso de error, lo que revela los detalles internos de la aplicación. Estas reglas impiden que dicha información sensible llegue al usuario. |
| RESPONSE-953-DATA-LEAKAGES-PHP.conf | Similar al caso de Java, pero para PHP. PHP suele revelar rutas de archivos, configuraciones o contenido de variables en caso de error. Estas reglas bloquean o enmascaran dicha información. |
| RESPONSE-954-DATA-LEAKAGES-IIS.conf | Reglas para Microsoft IIS. También aquí se detectan páginas de error típicas que podrían revelar detalles internos del sistema. |
| RESPONSE-959-BLOCKING-EVALUATION.conf | Al igual que con las solicitudes, también para las respuestas hay una evaluación final. Este archivo decide si una respuesta con fugas de datos debe bloquearse o permitirse. |
| RESPONSE-980-CORRELATION.conf | Estas reglas no solo analizan solicitudes o respuestas individuales, sino que correlacionan patrones a lo largo de varios eventos. De este modo, por ejemplo, pueden detectarse pequeñas infracciones repetidas que indican un ataque dirigido. |
El papel de ModSecurity
ModSecurity es uno de los módulos WAF de código abierto más conocidos para servidores web como Apache y Nginx. Funciona con reglas y permite un análisis detallado, registro y bloqueo del tráfico HTTP. En combinación con el OWASP Core Rule Set, ofrece reglas preconfiguradas para patrones de ataque comunes. Así, ModSecurity es apto tanto para entornos de formación como DVWA como para la protección productiva de aplicaciones web.
Mientras que OWASP proporciona principalmente directrices y conjuntos de reglas, ModSecurity ofrece el módulo WAF práctico con el que estas especificaciones pueden implementarse directamente a nivel técnico.
Ventajas y desventajas de un WAF
Ventajas
- Protección contra patrones de ataque conocidos: Un WAF ofrece protección contra los vectores de ataque incluidos en OWASP Top 10 y otros.
- Parcheo virtual: Al detectarse una vulnerabilidad en el código de la aplicación, se puede crear una regla WAF para bloquear ataques contra esta brecha. Esto sirve como medida de protección temporal hasta que se corrija el código fuente.
- Registro y supervisión: Se registran los intentos de ataque. Estos datos son relevantes para análisis de seguridad y detección de patrones de ataque.
- Ayuda en el cumplimiento: El uso de un WAF suele ser parte de estándares de seguridad como PCI DSS (Payment Card Industry Data Security Standard).
Desventajas
- Falsos positivos: Las solicitudes legítimas pueden clasificarse erróneamente como maliciosas y bloquearse. Esto requiere ajustar el conjunto de reglas (“tuning”).
- Falsos negativos: Vectores de ataque complejos o desconocidos pueden no detectarse en ocasiones. Un WAF no ofrece una protección al cien por cien.
- Impacto en el rendimiento: El análisis de las solicitudes introduce una latencia en el procesamiento.
- Esfuerzo de configuración y mantenimiento: Un WAF requiere una configuración cuidadosa y un mantenimiento regular para ser efectivo y minimizar falsos positivos.
Guía para la demostración práctica
Esta sección describe la configuración de un entorno de prueba para la demostración de un WAF.
Componentes necesarios
- Docker: Una plataforma de contenedores para el despliegue aislado y reproducible de componentes de software.
- DVWA (Damn Vulnerable Web Application): Una aplicación web desarrollada para demostraciones de seguridad que contiene vulnerabilidades conocidas.
- Nginx: Un servidor web que se utiliza como proxy inverso para recibir y verificar solicitudes antes de reenviarlas a la aplicación de destino.
- ModSecurity: Un motor WAF de código abierto que se integra como módulo en Nginx.
Paso 1: Inicio de la aplicación de destino (DVWA)
DVWA significa Damn Vulnerable Web Application. Es un proyecto de aplicación web diseñado deliberadamente sin seguridad que sirve como entorno de aprendizaje y prueba de seguridad informática. La aplicación incluye vulnerabilidades típicas como inyección SQL, Cross-Site Scripting o inclusión de archivos. Investigadores de seguridad, desarrolladores y estudiantes usan DVWA en un entorno protegido para practicar ataques y probar medidas de defensa. Dado que el software es intencionalmente vulnerable, solo debe usarse en entornos de prueba aislados, nunca en sistemas productivos.
Con el siguiente comando se inicia un contenedor de DVWA:
La aplicación estará disponible en http://localhost:8080.
Paso 2: Configuración del WAF
En esta configuración, tres archivos de configuración controlan el funcionamiento y la seguridad.
nginx.conf gestiona los ajustes básicos del servidor web y el enrutamiento.
dvwa.conf integra la aplicación de prueba DVWA en el entorno.
rule-exclusion.conf define excepciones para reglas específicas, para permitir pruebas de seguridad dirigidas sin bloqueos.
Configuración de nginx (nginx.conf)
Este bloque de código es una instrucción de configuración para el servidor web Nginx. Define cómo Nginx debe responder a las solicitudes que recibe. Esencialmente, configura Nginx como una estación de reenvío protectora (proxy inverso) con un cortafuegos de aplicaciones web (WAF) integrado.
El código configura Nginx para que funcione en el puerto 80 como cortafuegos de aplicaciones web y proxy inverso. Cada solicitud entrante es primero analizada por ModSecurity (WAF) en busca de patrones de ataque. Si la solicitud se considera segura, Nginx la reenvía a la aplicación web real, que se ejecuta en el puerto 8080.
Configuración del proxy (dvwa.conf)
Se crea un archivo llamado dvwa.conf. Contiene la instrucción para que Nginx reenvíe las solicitudes al contenedor DVWA y active ModSecurity.
Regla de excepción (rule-exclusion.conf)
Se crea un archivo llamado rule-exclusion.conf para corregir un falso positivo provocado, por ejemplo, por una cookie del navegador.
Paso 3: Inicio del contenedor WAF
En la terminal, navega al directorio con los archivos de configuración y arranca el contenedor WAF con el siguiente comando:
docker run –rm -it -p 80:80 -v “%cd%\dvwa.conf:/etc/nginx/conf.d/dvwa.conf” -v “%cd%\rule-exclusion.conf:/etc/modsecurity.d/owasp-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf” owasp/modsecurity-crs:nginx
Realización de la prueba
Tras completar la instalación, el WAF estará disponible en http://localhost.
Prueba sin WAF: Se realiza un ataque contra http://localhost:8080. En la página “XSS (Reflected)”, tras el inicio de sesión y establecer el nivel de seguridad en “low”, se introduce la carga útil (payload). Resultado: se ejecuta una alerta de JavaScript en el navegador.
Prueba con WAF: Se realiza el mismo ataque contra http://localhost. Resultado: el navegador muestra la página de error 403 Forbidden. Los registros del WAF en la terminal muestran un mensaje que registra el ataque XSS detectado.
Desarrollos modernos en el ámbito de los WAF
Actualización automatizada de reglas
Los WAF tradicionales funcionan con conjuntos de reglas estáticos que los administradores deben actualizar manualmente. Este procedimiento es propenso a errores y provoca que a menudo los nuevos patrones de ataque se detecten con retraso. Los sistemas modernos emplean actualizaciones automatizadas que sincronizan continuamente su base de reglas con la información más reciente sobre amenazas. Así se reduce el riesgo de que los ataques de día cero pasen desapercibidos. Además, disminuye el esfuerzo de mantenimiento, ya que se requieren menos intervenciones manuales. Esta automatización es comparable al software antivirus, que actualiza regularmente las bases de datos de firmas, aunque aquí la protección está dirigida específicamente a aplicaciones web
Mejoras con machine learning
Los WAF clásicos detectan ataques principalmente comparándolos con patrones conocidos. Este enfoque presenta limitaciones cuando un ataque es novedoso o está ligeramente modificado. Los sistemas basados en machine learning van un paso más allá: analizan el tráfico típico de una aplicación y aprenden qué comportamiento es normal. Las desviaciones de este patrón pueden detectarse como anomalías, incluso si no están incluidas en las reglas clásicas. De este modo, es posible identificar ataques sigilosos que se desarrollan en pequeños pasos a lo largo de varias solicitudes. Los métodos de ML complementan así las reglas clásicas, pues pueden reaccionar dinámicamente a los cambios.
De WAF a WAAP
Con el término Web Application and API Protection (WAAP) se describe la evolución de los WAF tradicionales hacia plataformas de protección más completas. Dado que las aplicaciones modernas dependen cada vez más de las API, ya no basta con supervisar el tráfico HTTP clásico de una aplicación web. Las soluciones WAAP combinan la funcionalidad de un WAF con la protección de API, la gestión de bots y la defensa contra DDoS en un paquete integrado. De este modo, no solo se protegen los sitios web, sino también las interfaces y los patrones de acceso automatizados. Para las empresas, esto supone una protección más integral que se adapta mejor a la arquitectura actual de las aplicaciones modernas.