Cómo proteger un sitio web con un WAF

Qué es un WAF (Web Application Firewall)

Un Web Application Firewall (WAF) es un sistema de seguridad que filtra, supervisa y bloquea el tráfico HTTP malicioso dirigido a tu aplicación web. A diferencia de un cortafuegos de red clásico, que opera a nivel de dirección IP y puerto, un WAF entiende el protocolo HTTP y puede analizar el contenido de las peticiones: parámetros de la URL, datos POST, cookies, cabeceras HTTP y el cuerpo de la petición. Esto le permite detectar y bloquear ataques que pasarían a través de un cortafuegos clásico.

Imagina un WAF como el control de seguridad a la entrada de un restaurante que revisa a cada invitado. Un cortafuegos clásico solo comprueba si el invitado tiene invitación (la IP y el puerto correctos). El WAF comprueba si el invitado lleva armas, documentos falsos o malas intenciones: analiza el comportamiento, no solo la identidad. En un mundo en el que se producen unos 2.800 ciberataques cada día, un WAF es una capa de protección crítica para cualquier sitio web.

Cómo funciona un WAF

Un WAF se sitúa entre el usuario y el servidor web y analiza cada petición HTTP antes de que llegue a tu aplicación. Las decisiones se toman a partir de reglas y algoritmos predefinidos.

Modelos de detección

Un WAF utiliza dos modelos principales para detectar ataques. El modelo de seguridad negativa (lista negra) bloquea las peticiones que contienen patrones maliciosos conocidos: cadenas de inyección SQL, payloads XSS, secuencias de path traversal, etc. Es el enfoque más habitual porque resulta más fácil de implementar, pero no puede detectar ataques nuevos y desconocidos (zero-day). El modelo de seguridad positiva (lista blanca) define lo que está permitido y bloquea todo lo demás. Este modelo es más seguro, pero requiere una configuración detallada para cada aplicación, porque tienes que definir cada parámetro, URL y formato de datos legítimo.

Frente a qué protege el WAF

El WAF protege frente a los ataques web más comunes definidos en la lista OWASP Top 10: SQL Injection (inyectar código SQL a través de formularios y parámetros de la URL para acceder a la base de datos o modificarla), Cross-Site Scripting - XSS (inyectar código JavaScript malicioso que se ejecuta en el navegador de otros usuarios), Cross-Site Request Forgery - CSRF (forzar a un usuario autenticado a realizar una acción no deseada), Local/Remote File Inclusion (cargar archivos maliciosos a través del mecanismo include de PHP), Path Traversal (acceder a archivos fuera de la raíz web usando secuencias ../), Command Injection (ejecutar comandos del sistema a través de una aplicación web) y ataques de fuerza bruta sobre los formularios de inicio de sesión.

Acciones que puede tomar el WAF

Cuando el WAF detecta una petición sospechosa, puede tomar diversas acciones: bloquear la petición y devolver un error 403 Forbidden, permitir la petición pero registrarla para un análisis posterior (modo de monitorización), activar una comprobación CAPTCHA para determinar si el usuario es una persona o un bot, limitar la tasa de peticiones (rate limit) desde una determinada dirección IP, o bloquear temporalmente una dirección IP que envía muchas peticiones maliciosas. Los sistemas WAF modernos combinan estas acciones en función de la gravedad de la amenaza.

Tipos de WAF

Las soluciones WAF se diferencian según dónde se implementan y según su arquitectura.

WAF en la nube (cloud-based)

Un WAF en la nube se implementa cambiando los registros DNS: el tráfico se enruta a través de un proveedor en la nube que filtra las peticiones maliciosas antes de que lleguen a tu servidor. Ejemplos: Cloudflare WAF, Sucuri, AWS WAF, Akamai. Ventajas: implementación sencilla (no requiere cambios en el servidor), escalabilidad (la infraestructura en la nube absorbe los ataques DDoS), actualización automática de reglas y ventajas de CDN (carga más rápida del sitio). Inconvenientes: dependencia de un tercero, posible latencia (un salto adicional) y costes mensuales.

WAF basado en host (host-based)

Un WAF basado en host se instala directamente en el servidor web como módulo o aplicación. El ejemplo más conocido es ModSecurity, que se integra con los servidores web Apache, Nginx y LiteSpeed. Ventajas: control total sobre la configuración, sin salto de red adicional, acceso a registros detallados en el servidor y ningún coste mensual por un servicio en la nube. Inconvenientes: requiere conocimientos técnicos para su configuración y mantenimiento, consume recursos del servidor para analizar las peticiones y la actualización de las reglas es responsabilidad tuya.

Enfoque híbrido

La mejor protección es la combinación de un WAF en la nube y uno basado en host. Un WAF en la nube (Cloudflare) filtra los ataques volumétricos y las amenazas conocidas antes de que lleguen al servidor, mientras que un WAF basado en host (ModSecurity) ofrece una inspección profunda de las peticiones que pasan a través de la capa en la nube. Esta estrategia de defensa en profundidad garantiza que, aunque una capa pase por alto un ataque, la otra lo detecte.

Cloudflare WAF - configuración

Cloudflare es el WAF en la nube más popular para sitios pequeños y medianos gracias a su plan gratuito, que incluye protección básica, y a sus asequibles planes de pago con funciones WAF avanzadas.

Configuración básica

Para usar Cloudflare WAF necesitas crear una cuenta de Cloudflare, añadir tu dominio y cambiar los servidores de nombres (nameservers) a los de Cloudflare. Tras la propagación de DNS (normalmente 24-48 horas), todo el tráfico hacia tu sitio pasa por la red de Cloudflare. El plan gratuito ofrece protección DDoS, un certificado de cifrado gratuito, CDN y protección básica frente a bots. Las reglas WAF están disponibles a partir del plan Pro (20 €/mes).

Managed Rules

Las Managed Rules de Cloudflare son reglas preconfiguradas que protegen frente a vulnerabilidades conocidas. El Cloudflare Managed Ruleset cubre los ataques del OWASP Top 10, el Cloudflare WordPress Ruleset está diseñado específicamente para vulnerabilidades de WordPress, y Cloudflare Leaked Credentials Detection comprueba si los usuarios están utilizando contraseñas comprometidas. Estas reglas se actualizan automáticamente cuando se descubren nuevas amenazas.

Custom Rules

Además de las reglas gestionadas, puedes crear reglas WAF personalizadas para las necesidades concretas de tu sitio. Por ejemplo: bloquear el acceso a la página wp-admin para todos excepto para tu dirección IP, restringir el acceso a xmlrpc.php, bloquear peticiones procedentes de determinados países, exigir un CAPTCHA en la página de inicio de sesión, o bloquear los user agents de bots y escáneres conocidos. Las reglas personalizadas se crean a través del panel de Cloudflare mediante un editor visual o con la sintaxis de expresiones Wire Format.

Rate Limiting

Cloudflare Rate Limiting permite limitar el número de peticiones por dirección IP en un periodo de tiempo determinado. Es una defensa eficaz frente a los ataques de fuerza bruta y el abuso de API. Por ejemplo: limitar la página de inicio de sesión a 5 peticiones por minuto por dirección IP, limitar los endpoints de la API a 100 peticiones por minuto. Las peticiones que superan el límite pueden bloquearse, activar un CAPTCHA o redirigirse a una página de error.

ModSecurity - configuración

ModSecurity es un motor WAF de código abierto que se ejecuta como módulo en servidores Apache, Nginx y LiteSpeed. Es el WAF basado en host más extendido en el sector del hosting.

Instalación y configuración básica

En servidores con cPanel, ModSecurity se instala a través de WHM (Web Host Manager) con un solo clic. En servidores Linux sin cPanel, se instala desde paquetes (apt install libapache2-mod-security2 en Ubuntu/Debian). Tras la instalación, ModSecurity se ejecuta en modo Detection Only: registra las peticiones sospechosas pero no las bloquea. Esto se recomienda al principio para identificar los falsos positivos antes de pasar al modo de aplicación (enforcing).

OWASP Core Rule Set (CRS)

ModSecurity por sí solo no contiene reglas: necesita un conjunto de reglas. El OWASP Core Rule Set (CRS) es el conjunto de reglas más utilizado y cubre las vulnerabilidades del OWASP Top 10. El CRS utiliza un sistema de puntuación de anomalías en el que cada elemento sospechoso de la petición suma puntos, y una petición solo se bloquea cuando la puntuación total supera el umbral (5 por defecto). Esto reduce los falsos positivos, porque un único elemento sospechoso no basta para bloquear: debe haber varios indicios de comportamiento malicioso.

Ajuste fino de las reglas

Las reglas de ModSecurity suelen generar falsos positivos, es decir, bloquean peticiones legítimas. Los ejemplos más habituales son: el editor de WordPress enviando código HTML/CSS (parece XSS), los plugins de cortafuegos cuyos formularios del panel de control contienen términos de seguridad, y los formularios de contacto con contenido específico. Para corregir los falsos positivos puedes: desactivar una regla concreta para una URL o directorio determinado, elevar el umbral de puntuación de anomalías, o añadir una regla de lista blanca para peticiones seguras conocidas. Revisa el registro de auditoría de ModSecurity para identificar qué reglas generan falsos positivos.

ModSecurity en LiteSpeed

LiteSpeed Web Server tiene soporte integrado para las reglas de ModSecurity sin necesidad de un módulo externo. LiteSpeed procesa las reglas de ModSecurity más rápido que Apache porque utiliza un motor optimizado diseñado para la arquitectura basada en eventos de LiteSpeed. La configuración es idéntica a la de Apache (las mismas reglas, las mismas directivas), pero con mejor rendimiento.

WAF para WordPress - reglas específicas

Los sitios WordPress son el objetivo más frecuente de los ataques y requieren reglas WAF específicas además de las genéricas.

Protección del área de administración

Restringe el acceso a /wp-admin/ y /wp-login.php a direcciones IP conocidas o exige una autenticación adicional. Bloquea el acceso a archivos sensibles: wp-config.php, xmlrpc.php, wp-cron.php (permite solo el acceso desde el lado del servidor). Evita la enumeración de usuarios bloqueando las peticiones con el parámetro ?author=, que revela los nombres de usuario.

Protección frente a vulnerabilidades de plugins

Los plugins de WordPress son el vector de ataque más frecuente. Las reglas WAF deberían bloquear: el acceso directo a archivos PHP en el directorio wp-content/plugins/ (excepto los manejadores AJAX), la subida de tipos de archivo maliciosos (.php, .phtml, .pht camuflados como imágenes) y la explotación de vulnerabilidades conocidas en plugins populares (Cloudflare y el CRS de ModSecurity tienen reglas específicas para vulnerabilidades de plugins de WordPress).

Protección frente a bots

Un gran porcentaje del tráfico de los sitios WordPress procede de bots: buenos (Google bot, Bing bot) y malos (escáneres de vulnerabilidades, scrapers de contenido, bots de fuerza bruta). El WAF debería: permitir los bots buenos conocidos según su user agent y sus rangos de IP, bloquear o limitar la tasa de los bots malos conocidos, activar un CAPTCHA para los bots sospechosos y limitar la tasa de rastreo de todos los bots para que no sobrecarguen el servidor.

Monitorización y mantenimiento del WAF

Un WAF no es una solución de "configúralo y olvídate". Requiere monitorización y ajustes periódicos.

Análisis de registros

Revisa periódicamente los registros del WAF para identificar: falsos positivos que bloquean a usuarios legítimos (y ajustar las reglas), patrones de ataque que puedan indicar un ataque dirigido, direcciones IP o rangos que generan muchas peticiones maliciosas, y nuevos tipos de ataque que quizá no estén cubiertos por las reglas existentes. Cloudflare ofrece un panel visual para el análisis, mientras que ModSecurity utiliza archivos de registro de texto que puedes analizar con herramientas como GoAccess o el stack ELK.

Actualización de las reglas

Cada día se descubren nuevas vulnerabilidades y las reglas del WAF deben actualizarse para cubrirlas. Las soluciones WAF en la nube (Cloudflare) actualizan las reglas automáticamente. En el caso de ModSecurity con OWASP CRS, actualiza el conjunto de reglas al menos una vez al mes. Sigue los boletines de seguridad de WordPress, los plugins y los temas que utilizas, y añade reglas específicas para vulnerabilidades recién descubiertas antes de que esté disponible un parche (virtual patching).

Errores habituales con el WAF

• Reglas demasiado agresivas: un WAF que bloquea a usuarios legítimos es peor que no tener WAF, porque ahuyenta a visitantes y clientes. Empieza en modo de monitorización y endurece las reglas de forma gradual.
• Confiar únicamente en el WAF: el WAF es una capa de protección, no un sustituto del software actualizado, las contraseñas robustas, una configuración segura y las copias de seguridad. Una estrategia de defensa en profundidad es el único enfoque correcto.
• Ignorar los registros: los registros del WAF valen oro, te muestran exactamente quién intenta qué en tu sitio. Ignorarlos significa perderte señales importantes de amenazas.
• Reglas obsoletas: un WAF con reglas de hace un año es como un antivirus con una base de datos desactualizada: no reconoce las nuevas amenazas.
• No probar tras los cambios: cada cambio en una regla del WAF debe probarse para confirmar que no bloquea funcionalidades legítimas del sitio.

Conclusión

Un WAF es una capa de protección imprescindible para cualquier sitio web, especialmente para los sitios WordPress, que son el objetivo más frecuente de los ataques. La combinación de un WAF en la nube (Cloudflare) para la protección volumétrica y frente a DDoS con un WAF basado en host (ModSecurity) para la inspección profunda de las peticiones ofrece una protección integral. Empieza en modo de monitorización, sigue los registros, ajusta las reglas a tu sitio y actualiza los conjuntos de reglas con regularidad. En BeoHosting, todos los planes de hosting incluyen un WAF ModSecurity preconfigurado con el OWASP Core Rule Set optimizado para WordPress, junto con nuestra recomendación de usar el plan gratuito de Cloudflare como capa de protección adicional y por las ventajas de CDN.