WordPress es uno de los gestores de contenidos más utilizados del mundo y, precisamente por eso, también recibe una cantidad enorme de tráfico automatizado, escaneos, intentos de acceso y ataques dirigidos contra plugins, temas y configuraciones vulnerables.
No hace falta tener una web especialmente popular para comprobarlo. Basta con revisar durante unos días los registros de un servidor conectado a Internet para empezar a encontrar peticiones extrañas contra wp-login.php, xmlrpc.php, plugins que ni siquiera tenemos instalados o rutas utilizadas habitualmente por herramientas automáticas de reconocimiento.
Una de las formas que más me gustan de reducir este tipo de ruido es colocar Cloudflare WAF delante de WordPress.
La razón es sencilla: buena parte del tráfico puede analizarse antes de llegar realmente al servidor.
Eso significa que determinadas peticiones maliciosas pueden quedarse fuera antes de consumir recursos de Apache, Nginx, PHP, WordPress o la propia base de datos.
No considero Cloudflare WAF una solución mágica ni mucho menos una excusa para dejar de actualizar WordPress. Lo veo como algo bastante más útil: una capa adicional dentro de una estrategia de seguridad por niveles.
Y esa diferencia es importante.
En esta guía voy a explicar qué puede aportar un firewall de aplicaciones web, qué ataques puede ayudar a frenar, cómo combinar reglas administradas y personalizadas y qué precauciones conviene tener para no terminar bloqueando usuarios legítimos.
Qué es Cloudflare WAF y por qué tiene sentido delante de WordPress
WAF son las siglas de Web Application Firewall, o firewall de aplicaciones web.
Su función consiste, de forma simplificada, en analizar las peticiones web que recibe una aplicación y aplicar reglas sobre ellas.
En una instalación protegida mediante Cloudflare, el tráfico no tiene por qué viajar directamente desde el visitante hasta nuestro servidor de origen. Cuando el dominio utiliza el proxy de Cloudflare, las peticiones pasan primero por su infraestructura.
Es ahí donde podemos aplicar parte de la protección.
Qué ocurre con una petición antes de llegar a WordPress
Podemos visualizarlo de esta forma:
Visitante → Cloudflare → servidor web → PHP → WordPress → base de datos
Sin una capa externa delante del servidor, una gran parte de las peticiones llega hasta nuestra infraestructura y tiene que ser procesada allí.
Con Cloudflare podemos intentar cortar determinados patrones antes.
Por ejemplo, imaginemos un bot realizando miles de solicitudes contra diferentes URLs de plugins vulnerables. Si conseguimos bloquear una parte importante de esas peticiones en Cloudflare, evitamos que todas ellas terminen convirtiéndose en trabajo para nuestro servidor.
Esta es, precisamente, una de las características que más valoro.
En mi caso, no veo únicamente el WAF como una herramienta para “bloquear hackers”. Me interesa también porque puede impedir que determinadas peticiones basura recorran toda la cadena hasta PHP, Apache, Nginx o la base de datos.
Eso puede ser especialmente relevante en WordPress porque muchas solicitudes dinámicas terminan ejecutando código PHP y consultando información en la base de datos.
Cuanto antes podamos descartar tráfico claramente no deseado, mejor.
Qué puede hacer un WAF y qué no puede hacer
Aquí conviene evitar expectativas poco realistas.
Un WAF puede ayudarnos a identificar y bloquear determinados patrones de ataque, pero no convierte una instalación vulnerable en una instalación segura.
Si tenemos un plugin abandonado con una vulnerabilidad crítica, la solución correcta sigue siendo actualizarlo, sustituirlo o eliminarlo.
Si utilizamos la contraseña admin123, Cloudflare tampoco convierte esa contraseña en segura.
Y si el servidor está mal configurado o permite acceder directamente a la IP de origen saltándose completamente Cloudflare, tendremos otro problema distinto.
Por eso prefiero considerar el WAF como una barrera adicional:
- WordPress actualizado.
- Plugins y temas actualizados.
- Usuarios bien protegidos.
- Autenticación de dos factores cuando sea posible.
- Servidor correctamente configurado.
- Copias de seguridad.
- Cloudflare y su WAF delante de la aplicación.
La seguridad funciona mucho mejor cuando depende de varias capas y no de un único control.
Qué ataques puede ayudar a bloquear Cloudflare WAF en WordPress
Una instalación de WordPress está expuesta a muchos tipos de tráfico hostil.
Algunos ataques buscan vulnerabilidades concretas. Otros intentan adivinar credenciales. Otros simplemente recorren Internet probando automáticamente miles de rutas conocidas.
Cloudflare WAF puede ser útil frente a varios de estos escenarios.
Ataques de SQL injection
Una SQL injection intenta introducir instrucciones SQL manipuladas en datos que posteriormente son utilizados por una aplicación para construir consultas contra su base de datos.
En una aplicación correctamente desarrollada, este tipo de entrada debería tratarse de forma segura.
El problema aparece cuando existe una vulnerabilidad en WordPress, un plugin, un tema o cualquier componente que procese esos datos de manera insegura.
Un WAF puede reconocer determinados patrones característicos de este tipo de ataques e impedir que algunas peticiones lleguen a la aplicación.
Eso añade una barrera interesante, especialmente durante el intervalo que puede existir entre la publicación de una vulnerabilidad y su corrección efectiva en todos los sitios afectados.
Y ese intervalo me parece importante.
Una instalación puede estar perfectamente actualizada hoy y descubrir mañana que uno de sus plugins tiene una vulnerabilidad recién publicada. El WAF no sustituye el parche, pero tener una protección adicional delante del servidor puede reducir la exposición frente a determinados intentos de explotación.
Cross-Site Scripting o XSS
Los ataques XSS o Cross-Site Scripting buscan introducir contenido que termine ejecutándose en el navegador de otros usuarios.
De nuevo, el origen del problema suele estar en la aplicación: datos que se aceptan o muestran sin el tratamiento apropiado.
Las reglas de un WAF pueden reconocer ciertos patrones sospechosos y bloquear solicitudes que coincidan con ellos.
No significa que cualquier vulnerabilidad XSS quede automáticamente neutralizada.
Lo que significa es que disponemos de otra capa capaz de interceptar parte de los intentos de explotación conocidos o reconocibles.
Intentos de explotación de plugins y temas vulnerables
Este es probablemente uno de los escenarios más importantes en WordPress.
Los bots no necesitan saber qué plugins tenemos instalados antes de empezar.
Muchos simplemente prueban.
Solicitan rutas pertenecientes a plugins conocidos, intentan ejecutar endpoints vulnerables, buscan archivos expuestos y repiten el proceso contra miles o millones de dominios.
Podemos encontrarnos, por ejemplo, con intentos dirigidos contra componentes que nunca hemos instalado.
Eso ocurre porque el atacante no está investigando nuestra web manualmente. Está automatizando una lista de pruebas.
Las reglas administradas de un WAF pueden ayudarnos frente a determinados patrones conocidos, mientras que las reglas personalizadas nos permiten reaccionar cuando detectamos algo específico en nuestros propios registros.
Bots, escáneres y tráfico automatizado
No todo bot es malicioso.
Los buscadores utilizan bots. Los servicios de monitorización utilizan bots. Algunas integraciones legítimas también funcionan de forma automatizada.
El problema es el tráfico automatizado que escanea rutas agresivamente, busca vulnerabilidades o dispara cantidades desproporcionadas de solicitudes.
Aquí hay que ser prudente.
Bloquear cualquier petición que “parezca un bot” puede terminar perjudicando servicios legítimos.
Por eso, siempre que puedo, prefiero construir las reglas partiendo del comportamiento observado y no de una regla genérica del estilo “bloquear todos los bots”.
Fuerza bruta y ataques contra el acceso de WordPress
wp-login.php es uno de los objetivos más evidentes.
Un atacante puede enviar intentos repetidos de autenticación para probar contraseñas comunes, combinaciones obtenidas de filtraciones o listas automatizadas.
Cloudflare puede convertirse aquí en una primera barrera.
Dependiendo del caso, podemos aplicar restricciones, desafíos o límites sobre determinadas solicitudes antes de que cada intento termine llegando al sistema de autenticación de WordPress.
Eso no elimina la necesidad de utilizar contraseñas fuertes ni autenticación de dos factores.
Lo que hace es reducir la cantidad de tráfico hostil que consigue llegar hasta ese punto.
Cómo empezar a proteger WordPress con Cloudflare WAF
Uno de los errores que veo más fáciles de cometer consiste en entrar al panel y empezar inmediatamente a crear reglas muy agresivas.
Yo prefiero justo lo contrario.
Empiezo con una base razonable, observo y solo después endurezo.
Activa primero las reglas administradas
Las reglas administradas son una de las partes que más me interesan de Cloudflare.
No todo administrador de una web tiene tiempo o conocimientos para analizar manualmente cada petición HTTP y construir desde cero firmas contra SQL injection, XSS o técnicas similares.
Las Managed Rules permiten partir de una base que el proveedor mantiene y actualiza.
Para un proyecto pequeño o mediano me parece especialmente práctico.
No necesitamos convertirnos en especialistas en seguridad ofensiva para disponer de una primera capa de filtrado.
Esto no significa activar absolutamente todo sin mirar.
El comportamiento exacto de las reglas disponibles y las opciones que aparecen en el panel pueden variar según el plan y los cambios que Cloudflare realice en su producto.
Por eso conviene revisar qué reglas están disponibles en nuestra cuenta y observar qué efecto están teniendo.
Cloudflare Managed Rules y reglas orientadas a amenazas web
Las reglas administradas buscan identificar familias conocidas de ataques y patrones sospechosos.
Este tipo de protección es especialmente interesante para amenazas genéricas que no dependen exclusivamente de nuestra propia web.
En lugar de escribir manualmente una regla para cada posible forma de SQL injection, por ejemplo, podemos apoyarnos en conjuntos de reglas diseñados específicamente para detectar ese tipo de actividad.
Después podemos añadir nuestra capa específica para WordPress.
Ahí es donde entran las Custom Rules.
Revisa los eventos antes de endurecer la configuración
No configuraría nunca un WAF con la mentalidad de “cuanto más bloquee, mejor”.
Un firewall demasiado agresivo puede convertirse en un problema operativo.
Podemos bloquear formularios, integraciones, usuarios legítimos o llamadas necesarias para alguna funcionalidad.
Por eso los registros y eventos son fundamentales.
Antes de endurecer una regla intento responder tres preguntas:
- ¿Qué tráfico quiero detener?
- ¿Cómo puedo reconocerlo sin afectar al tráfico legítimo?
- ¿Qué pasaría si mi condición es demasiado amplia?
Cuanto más específica sea la respuesta, mejor será normalmente la regla.
Managed Rules vs Custom Rules: cuándo utilizar cada una
No considero las reglas administradas y las reglas personalizadas opciones enfrentadas.
Para mí, el verdadero potencial aparece cuando utilizamos ambas juntas.
Qué solucionan las reglas administradas
Las reglas administradas funcionan especialmente bien como protección general.
Su ventaja principal es que no necesitamos conocer previamente cada patrón exacto que queremos bloquear.
Podemos pensar en ellas como una capa mantenida externamente contra categorías de ataques conocidas.
Nos proporcionan una base.
Y esa base es especialmente valiosa en instalaciones que no cuentan con una persona dedicada exclusivamente a revisar logs y escribir reglas de firewall.
Cuándo merece la pena crear una regla personalizada
Las reglas personalizadas entran en juego cuando conocemos mejor nuestro caso.
Supongamos que observamos cientos de peticiones contra una URL concreta.
O detectamos un bot que solicita determinadas rutas con un patrón muy identificable.
O queremos proteger una zona administrativa que sabemos que solo utilizan ciertas personas.
En esos escenarios, una regla personalizada permite adaptar el firewall a nuestra instalación.
Eso me parece mucho más interesante que copiar veinte reglas encontradas por Internet.
Una regla personalizada debería responder a una necesidad real.
Por qué combinar ambos tipos de reglas
Mi enfoque sería:
reglas administradas para la protección general + reglas personalizadas para el contexto específico de nuestra web.
Las primeras intentan cubrir ataques que podrían afectar a miles de aplicaciones.
Las segundas responden a lo que sabemos de nuestro WordPress.
Si además utilizamos logs y eventos para alimentar esas decisiones, la configuración mejora bastante.
No necesitamos adivinar constantemente qué está pasando. Podemos observarlo.
Reglas de Cloudflare útiles para proteger WordPress
La sintaxis concreta del panel puede cambiar con el tiempo, por lo que prefiero centrarme en la lógica que debería seguir cada regla.
Copiar una expresión sin comprenderla suele ser peor que aprender qué queremos conseguir.
Cómo proteger wp-login.php
wp-login.php es un candidato evidente para aplicar controles adicionales.
Podemos considerar varias estrategias:
- limitar tráfico sospechoso;
- aplicar desafíos;
- restringir determinados orígenes cuando el contexto lo permita;
- combinar la protección con rate limiting;
- detectar patrones anómalos.
No recomiendo bloquear indiscriminadamente el acceso a todo el mundo salvo que nuestro escenario permita hacerlo.
Por ejemplo, restringir por una única IP puede ser muy efectivo para una instalación administrada exclusivamente desde una oficina con IP fija.
Pero puede ser un desastre si los administradores trabajan desde conexiones móviles o ubicaciones cambiantes.
La configuración debe adaptarse al proyecto.
Cómo proteger wp-admin
/wp-admin/ merece un razonamiento parecido.
Podemos aplicar controles adicionales, aunque hay que recordar que WordPress y sus plugins pueden utilizar rutas relacionadas con el área administrativa para distintas funciones.
Por eso bloquear el directorio completo con una condición demasiado amplia puede romper funcionalidades.
Aquí es especialmente importante probar.
Una regla aparentemente sencilla puede tener efectos secundarios que no son evidentes hasta que alguien intenta editar contenido, subir un archivo o utilizar determinada integración.
Qué hacer con xmlrpc.php
xmlrpc.php lleva años apareciendo en conversaciones sobre seguridad WordPress porque puede utilizarse para determinadas funciones remotas y también ha sido objetivo habitual de abuso automatizado.
¿Hay que bloquearlo siempre?
No necesariamente.
Primero tenemos que saber si nuestra web utiliza alguna funcionalidad que dependa de él.
Si tenemos claro que no lo necesitamos, restringir el acceso puede reducir superficie innecesaria.
Si sí lo utilizamos, habrá que plantear una protección más selectiva.
La regla general aquí vuelve a ser la misma: no bloquear por copiar una recomendación; bloquear porque entendemos nuestro caso.
Cómo filtrar bots y escáneres agresivos
Esta es una de las áreas donde más valor tienen los logs.
Imaginemos que encontramos peticiones continuas contra:
- archivos inexistentes;
- rutas de plugins que no tenemos instalados;
- endpoints conocidos por vulnerabilidades antiguas;
- archivos de configuración;
- patrones repetitivos a gran velocidad.
Podemos estudiar si esas peticiones comparten características útiles para construir una regla.
A veces será la ruta.
Otras veces será la frecuencia.
O el origen.
O varias señales combinadas.
Lo importante es evitar una condición tan genérica que termine bloqueando tráfico legítimo.
Cómo reaccionar ante un patrón de ataque detectado en los logs
Esta es una de las aplicaciones que más me gustan de las reglas personalizadas.
Veo algo extraño en los registros.
Lo analizo.
Compruebo si se repite.
Determino qué característica permite distinguirlo.
Y entonces creo una protección.
Ese flujo me parece mucho más útil que cargar una lista enorme de reglas preventivas sin saber si alguna se aplica realmente a nuestra web.
El WAF pasa así de ser una configuración estática a convertirse en una herramienta que podemos adaptar a medida que cambia el tráfico.
Bloquear, desafiar o permitir: qué acción elegir
No todas las solicitudes sospechosas tienen que terminar con un bloqueo.
Esta distinción es importante porque ayuda a reducir falsos positivos.
Cuándo utilizar Block
El bloqueo tiene sentido cuando estamos suficientemente seguros de que el tráfico no debería permitirse.
Por ejemplo, si detectamos una ruta que no existe en nuestra aplicación y únicamente recibe tráfico de explotación automatizada, la decisión puede ser relativamente sencilla.
Lo mismo ocurre cuando hemos identificado con mucha precisión un patrón malicioso.
Pero cuanto más genérica sea la condición, mayor precaución deberíamos tener antes de aplicar un bloqueo definitivo.
Cuándo es mejor utilizar un Challenge
Un desafío puede resultar interesante cuando queremos elevar la dificultad para el tráfico automatizado sin cerrar inmediatamente la puerta a cualquier usuario legítimo que coincida con la condición.
Eso puede ser especialmente útil cuando trabajamos con señales que no son completamente deterministas.
Por ejemplo, determinado comportamiento puede ser habitual en bots, pero no exclusivo de ellos.
En lugar de bloquear directamente, podemos utilizar una acción menos definitiva y observar resultados.
Cómo evitar bloquear visitantes legítimos
Los falsos positivos no son un detalle menor.
Una regla que bloquea el 99 % del tráfico malicioso pero también impide comprar al 2 % de nuestros clientes puede ser una mala regla.
Por eso prefiero aplicar cambios progresivos.
Primero observar.
Después limitar.
Después revisar.
Y finalmente endurecer, si los datos respaldan la decisión.
La seguridad debe proteger el negocio, no impedir que funcione.
Cómo detectar y corregir falsos positivos
Configurar el WAF es solo una parte del trabajo.
La otra consiste en comprobar qué está haciendo.
Revisar eventos de seguridad
Los eventos de seguridad nos permiten comprender qué solicitudes han activado determinadas protecciones.
Cuando una función deja de responder después de modificar el firewall, este debería ser uno de los primeros lugares que revisemos.
Tenemos que buscar correlaciones:
- hora del error;
- URL afectada;
- regla activada;
- acción aplicada;
- características de la petición.
Con esa información podemos ajustar mucho mejor.
Probar las reglas de forma progresiva
Una buena práctica consiste en evitar introducir muchas reglas agresivas simultáneamente.
Si hacemos diez cambios y algo deja de funcionar, tendremos que descubrir cuál de los diez lo ha provocado.
Si trabajamos de forma progresiva, la causa es mucho más fácil de identificar.
Yo prefiero:
- introducir una protección;
- observar;
- comprobar funcionamiento;
- ajustar;
- continuar.
Es menos espectacular que pegar veinte reglas de golpe, pero suele producir una configuración bastante más fiable.
Qué hacer cuando una regla rompe una función de WordPress
Lo primero es evitar convertir la excepción en un agujero enorme.
Si una regla bloquea una funcionalidad concreta, no deberíamos solucionar el problema desactivando todo el WAF sin investigar.
Hay que identificar:
- qué petición está siendo bloqueada;
- qué regla la detecta;
- por qué coincide;
- si podemos hacer la condición más específica;
- si podemos crear una excepción limitada.
Las excepciones pequeñas son preferibles a las excepciones globales.
Cloudflare WAF no sustituye la seguridad de WordPress
Este es probablemente el punto más importante de toda la guía.
Uno de los errores más fáciles de cometer es pensar que activar Cloudflare WAF convierte automáticamente una web en segura.
No funciona así.
Mantén WordPress, plugins y temas actualizados
Si aparece una actualización de seguridad, hay que aplicarla de acuerdo con nuestra política de mantenimiento y pruebas.
No tiene sentido dejar una vulnerabilidad conocida durante semanas pensando que el WAF bloqueará cualquier forma posible de explotarla.
El firewall es una capa de apoyo.
La corrección del problema sigue siendo prioritaria.
Protege las cuentas administrativas
Las cuentas con permisos elevados necesitan especial cuidado.
Algunas medidas básicas son:
- evitar contraseñas reutilizadas;
- utilizar contraseñas largas y únicas;
- eliminar usuarios administrativos que ya no sean necesarios;
- aplicar el principio de mínimo privilegio;
- revisar accesos cuando sea pertinente.
Muchas intrusiones no necesitan una vulnerabilidad sofisticada si el atacante consigue credenciales válidas.
Añade 2FA y contraseñas seguras
La autenticación en dos pasos añade otra barrera importante.
Incluso si una contraseña termina expuesta, disponer de un segundo factor puede impedir que esa credencial sea suficiente por sí sola.
Cloudflare puede ayudar a reducir intentos hostiles antes de que lleguen a WordPress, pero eso no elimina la necesidad de proteger correctamente las cuentas.
Mantén también protegido el servidor de origen
Hay otro punto que a veces se olvida.
Si colocamos Cloudflare delante pero nuestro servidor de origen sigue siendo fácilmente accesible de forma directa, parte de la estrategia puede perder efectividad.
La configuración de red, servidor web y servicios expuestos sigue importando.
También importa mantener actualizado:
- sistema operativo;
- PHP;
- servidor web;
- base de datos;
- paneles de administración;
- otros servicios instalados.
Cloudflare protege determinadas capas. No reemplaza toda la infraestructura.
Copias de seguridad como última capa de defensa
Una estrategia de seguridad sin copias de seguridad me parece incompleta.
Las copias deben existir antes de necesitarlas.
Y, cuando el proyecto lo justifique, conviene comprobar también que pueden restaurarse.
Si algo termina saliendo mal —una intrusión, un error humano, una actualización defectuosa o cualquier otro incidente— disponer de una recuperación fiable puede marcar la diferencia.
Cuándo merece especialmente la pena usar Cloudflare WAF
¿Necesita absolutamente cualquier WordPress una configuración avanzada de WAF?
No necesariamente.
Pero hay escenarios donde su utilidad se vuelve mucho más evidente.
Sitios con mucho tráfico
A medida que crece el tráfico, también aumenta el impacto potencial del tráfico basura.
Si podemos eliminar parte de ese volumen antes de alcanzar el origen, reducimos trabajo innecesario en nuestra infraestructura.
No todo se trata de seguridad pura.
También estamos hablando de eficiencia.
WordPress atacados constantemente por bots
Hay webs que aparecen constantemente en escáneres automáticos.
Podemos ver intentos contra docenas de vulnerabilidades que ni siquiera afectan a nuestra instalación.
Ese tráfico consume recursos y ensucia los registros.
Tener una barrera delante puede ayudarnos a reducir una parte importante de ese ruido.
Webs que reciben intentos de acceso repetidos
Si wp-login.php está recibiendo intentos constantes, merece la pena estudiar qué controles podemos añadir.
No deberíamos esperar necesariamente a tener un incidente.
Si el patrón ya es visible, podemos responder.
Proyectos con mayor exposición pública
Cuanto mayor sea la importancia de la web, más sentido tiene trabajar con varias capas.
Una tienda online, una web que almacena datos importantes o un proyecto que depende económicamente de su disponibilidad tienen incentivos claros para reducir riesgos.
En sitios WordPress que reciben bastante tráfico, sufren intentos constantes de acceso o empiezan a aparecer repetidamente en el radar de bots y escáneres automáticos es donde, en mi experiencia, una capa como Cloudflare puede marcar una diferencia especialmente interesante.
Errores habituales al configurar Cloudflare WAF en WordPress
Una configuración de seguridad también puede fallar por exceso.
Estos son algunos errores que intentaría evitar.
Activar reglas y olvidarse de revisar los eventos
No basta con configurar el firewall una vez y asumir que todo funciona perfectamente.
El tráfico cambia.
WordPress cambia.
Los plugins cambian.
Nuestra propia web cambia.
Conviene revisar periódicamente qué está ocurriendo, especialmente después de modificaciones importantes.
Copiar reglas de otras webs sin entenderlas
Internet está lleno de colecciones de “las mejores reglas para Cloudflare”.
Algunas pueden ser útiles.
Otras pueden no tener ningún sentido para nuestra instalación.
Copiar una expresión sin saber qué condición está evaluando puede terminar bloqueando funcionalidades importantes.
Antes de aplicar una regla deberíamos ser capaces de explicar con palabras sencillas:
“Quiero bloquear este tráfico porque…”
Si no podemos terminar la frase, probablemente deberíamos estudiar mejor la regla.
Bloquear demasiado tráfico desde el principio
Más bloqueo no significa automáticamente más seguridad.
Una política demasiado agresiva puede generar:
- falsos positivos;
- formularios rotos;
- problemas con APIs;
- usuarios legítimos bloqueados;
- integraciones que dejan de funcionar.
Me parece mucho más sensato endurecer progresivamente.
Pensar que el WAF hace innecesarias las actualizaciones
Este es probablemente el error más peligroso.
El WAF puede ser capaz de impedir ciertos intentos de explotación, pero no debemos utilizarlo como justificación para mantener software vulnerable.
Una vulnerabilidad debe corregirse en su origen siempre que sea posible.
Cloudflare como primera barrera, no como única defensa
Cloudflare WAF me parece una de las herramientas más interesantes que podemos colocar delante de WordPress cuando queremos mejorar la seguridad sin convertir toda la protección en una configuración compleja dentro del servidor.
Su principal ventaja, desde mi punto de vista, es precisamente su posición.
Puede analizar parte del tráfico antes de que llegue a Apache, Nginx, PHP, WordPress o la base de datos.
Además, las reglas administradas ofrecen un punto de partida accesible incluso cuando no queremos construir toda nuestra protección manualmente.
Pero donde veo realmente su potencial es en la combinación:
Managed Rules + Custom Rules + observación de logs.
Las reglas administradas nos proporcionan una base.
Las personalizadas nos permiten adaptar la defensa a nuestra instalación.
Y los registros nos dicen qué está ocurriendo realmente.
Aun así, no confiaría nunca toda la seguridad de WordPress al WAF.
Mantendría WordPress actualizado, revisaría plugins y temas, protegería las cuentas administrativas, utilizaría autenticación en dos pasos, mantendría el servidor correctamente configurado y conservaría copias de seguridad fiables.
Cloudflare no elimina la necesidad de hacer esas cosas.
Añade una barrera más.
Y precisamente por eso me parece tan útil.
Dudas de la comunidad
¿Cloudflare WAF protege completamente WordPress?
No.
Cloudflare WAF puede ayudar a bloquear determinadas peticiones y patrones de ataque, pero debe utilizarse como una capa adicional.
WordPress, plugins, temas, servidor y cuentas de usuario también necesitan mantenerse correctamente protegidos.
¿Qué ataques puede bloquear?
Dependiendo de las reglas y de la configuración, un WAF puede ayudar frente a patrones relacionados con SQL injection, XSS, intentos de explotación de vulnerabilidades y diferentes formas de tráfico automatizado malicioso.
La protección nunca debe interpretarse como una garantía absoluta frente a cualquier ataque de esas categorías.
¿Necesito reglas personalizadas?
No necesariamente para empezar.
Las reglas administradas proporcionan una base interesante.
Las personalizadas empiezan a tener mucho valor cuando queremos proteger elementos específicos de nuestra instalación o responder a comportamientos observados en los logs.
¿Puedo proteger wp-login.php con Cloudflare?
Sí, podemos aplicar controles específicos sobre las solicitudes dirigidas a wp-login.php.
La estrategia adecuada dependerá de cómo utilicemos nuestra web.
Podemos considerar desafíos, restricciones más específicas o controles relacionados con la frecuencia de las solicitudes.
¿Conviene bloquear xmlrpc.php?
Depende.
Si tenemos claro que ninguna funcionalidad de nuestra instalación depende de xmlrpc.php, restringirlo puede reducir superficie de ataque y tráfico innecesario.
Si algún servicio lo utiliza, un bloqueo completo podría romper esa integración.
¿Cloudflare sustituye a un plugin de seguridad?
No necesariamente.
Un plugin de seguridad y Cloudflare pueden trabajar en capas distintas.
Cloudflare puede actuar antes de que el tráfico llegue al servidor, mientras que una solución dentro de WordPress dispone de contexto que solo existe una vez que la petición llega a la aplicación.
Pueden ser complementarios.
¿Qué hago si Cloudflare bloquea usuarios legítimos?
Revisa los eventos de seguridad y determina qué regla está produciendo el bloqueo.
Después intenta hacer la condición más precisa o crear una excepción limitada.
No conviene desactivar todas las protecciones para solucionar un único falso positivo.
¿Cloudflare WAF sirve para ataques de fuerza bruta?
Puede formar parte de la defensa.
Podemos aplicar controles sobre rutas de autenticación y reducir tráfico automatizado antes de que llegue a WordPress.
Aun así, deberíamos combinarlo con contraseñas únicas, 2FA y una buena política de usuarios.
¿Merece la pena Cloudflare WAF para una web pequeña?
Puede merecerla.
No necesitamos esperar a tener una web enorme para recibir bots o escaneos automáticos.
La pregunta no es únicamente cuánto tráfico tiene la web, sino cuál es su exposición, qué valor tiene para nosotros y qué nivel de seguridad necesitamos.
Para una web pequeña, empezar con una configuración sencilla y reglas administradas puede ser una forma razonable de añadir otra capa sin convertir el mantenimiento en un proyecto complejo
Opinión Personal
Cloudflare WAF es una de esas herramientas que merece la pena tener en cuenta cuando gestionamos una web en WordPress y queremos añadir una capa extra de seguridad sin complicar demasiado la infraestructura.
Lo que más valoro es que permite filtrar parte del tráfico malicioso antes de que llegue al servidor. Para mí, eso tiene mucho sentido, sobre todo en webs que reciben intentos constantes de acceso, bots, escaneos automáticos o peticiones contra vulnerabilidades conocidas.
Eso sí, no lo veo como una solución milagrosa. Un WAF no sustituye las actualizaciones, las contraseñas seguras, el 2FA, las copias de seguridad ni una buena configuración del servidor. Funciona mejor cuando forma parte de una estrategia de seguridad por capas.
También creo que el verdadero potencial aparece cuando combinamos las reglas administradas de Cloudflare con reglas personalizadas basadas en lo que realmente estamos viendo en los logs. Esa combinación permite empezar con una protección sólida y, al mismo tiempo, adaptar el firewall a las necesidades concretas de cada WordPress.
En definitiva, para mí Cloudflare WAF no es una herramienta que “haga segura” una web por sí sola, pero sí puede convertirse en una barrera muy útil para reducir exposición, filtrar tráfico no deseado y reaccionar con más rapidez ante determinados ataques.
¿Tú utilizas Cloudflare WAF en tu WordPress? ¿Has creado reglas personalizadas o te apoyas principalmente en las reglas administradas? Me interesa conocer tu experiencia, así que déjala en los comentarios.
