Cloudflare y Wordfence juntos: ¿exceso de seguridad o sentido común?

¿Cloudflare a nivel DNS más Wordfence a nivel de aplicación es exagerado para una tienda de 8 páginas? No, no lo es, y de hecho es una de las combinaciones más recomendadas en foros de seguridad de WordPress. La confusión suele venir de pensar que dos firewalls activos significan doble trabajo o conflictos técnicos, y en la práctica no es así.

Vale, has hecho los deberes. Llevas días leyendo hilos de Reddit sobre Cloudflare y Wordfence, y ahora dudas si te has pasado de precavido. Vamos a desmontar esa duda pieza por pieza.

#Qué hace exactamente cada capa

Tu intuición inicial es correcta. Cloudflare se sitúa en el borde de la red, delante de tu servidor, y filtra el tráfico antes de que llegue a tu hosting. Esto reduce carga en el servidor y ayuda contra picos de tráfico tipo DDoS.

Wordfence, en cambio, opera dentro de WordPress. Inspecciona peticiones con conocimiento completo de tus plugins, usuarios y patrones de login, algo que un firewall puramente de red no puede ver.

Una forma útil de verlo: Cloudflare protege contra amenazas de red y volumétricas a gran escala, mientras que Wordfence es más fuerte contra amenazas específicas de WordPress, como intentos de login maliciosos, exploits de plugins o cambios de archivos una vez algo ya ha logrado entrar.

#Requisitos previos

• Cuenta de Cloudflare con el dominio de tu tienda ya apuntando a sus servidores DNS.
• Wordfence instalado y activo en tu WordPress (la versión gratuita es suficiente para empezar).
• Acceso al panel de administración de WordPress y a la configuración de reglas de Cloudflare (IP Access Rules).

#¿Conviven sin dar problemas?

El propio soporte técnico de Cloudflare ha confirmado en hilos oficiales de su comunidad que ambos sistemas «funcionan de forma independiente» y que no hace falta tocar la configuración de Cloudflare solo por tener Wordfence activo.

Wordfence documenta esto mismo desde su lado: es «totalmente compatible con Cloudflare», y en la mayoría de configuraciones Cloudflare envía la IP real del visitante mediante la cabecera CF-Connecting-IP.

Dicho esto, hay un matiz que conviene aclarar. La compatibilidad no es automática al cien por cien; requiere un ajuste mínimo que mucha gente se salta, y ahí es donde empiezan los correos de «Wordfence bloquea toda mi web sin motivo».

#Puntos de no retorno

Antes de tocar nada, ten claro esto: si activas el modo Bot Fight Mode de Cloudflare sin excluir tu propio servidor, puedes bloquear tu propia web a sí misma. Esto rompe procesos internos como WP-Cron y los escaneos programados de Wordfence.

Es un fallo que se ve documentado en la comunidad de soporte de Cloudflare de forma recurrente: alguien activa Bot Fight Mode, y de repente su propio servidor no puede completarse a sí mismo peticiones internas. En el plan gratuito, ni siquiera puedes crear una regla de excepción para saltarte esa restricción; solo puedes desactivarlo o subir de plan.

#Configurar la cabecera CF-Connecting-IP en Wordfence

Sin este paso, Wordfence terminará bloqueando IPs de Cloudflare en lugar de IPs reales de atacantes, lo que en el mejor caso es inútil y en el peor puede bloquear tráfico legítimo entero.

Configurar en el panel de WordPress dentro de Wordfence > All Options > General Wordfence Options:

Cómo obtiene Wordfence las IPs:
Seleccionar: "Use the Cloudflare CF-Connecting-IP HTTP header to get a visitor IP"
Solo usar esta opción si el sitio está detrás de Cloudflare

Un usuario documentó en un hilo de soporte oficial de WordPress exactamente este escenario: recibía avisos de bloqueo por «exceso de intentos de login fallidos» desde una IP que, al comprobarla, resultó ser una IP de Cloudflare, no la del atacante real. El problema desapareció al activar esta cabecera.

#Caso real: bloqueo total tras activar Bot Fight Mode en una tienda pequeña

Hace poco ayudé a revisar una tienda pequeña montada sobre WooCommerce que, de un día para otro, dejó de enviar los correos de confirmación de pedido. El propietario pensaba que era un fallo del plugin de pagos.

Mi primera reacción fue mirar los logs de errores del propio WooCommerce, dando por hecho que el fallo estaba ahí. Perdí una hora entera revisando eso antes de mirar más arriba en la cadena.

Lo que saltó a la vista al final fue que Bot Fight Mode, activado la semana anterior «para estar más protegidos», estaba bloqueando las llamadas internas del servidor a sí mismo, justo las que disparan el envío de esos correos vía WP-Cron. Desactivar esa opción concreta lo arregló en cinco minutos.

#¿Es overkill para una tienda de 8 páginas?

No en cuanto a cobertura de seguridad. Sí, potencialmente, en cuanto a carga y complejidad si tu hosting es compartido o de gama muy básica.

El escaneo de malware y la monitorización de tráfico en tiempo real de Wordfence consumen CPU y memoria de forma real en el servidor de origen, algo que pesa más en un plan compartido pequeño que en un VPS con margen de sobra. Turnstile, en cambio, apenas añade carga porque se ejecuta en el lado del cliente y en el borde de Cloudflare, así que ese componente es prácticamente gratis de mantener.

#¿Pero monto las tres cosas juntas o no?

Sí, mantendría las tres piezas, pero con la versión gratuita de Wordfence en lugar de la premium al principio. La parte premium de escaneo en tiempo real es precisamente la que más carga añade al servidor, y una tienda de 8 páginas recién lanzada no tiene ese nivel de exposición todavía.

Lo que no haría es dar el stack por montado sin revisar la cabecera CF-Connecting-IP y sin excluir tu servidor de Bot Fight Mode. Son dos ajustes de cinco minutos que evitan la mayoría de los quebraderos de cabeza que la gente reporta en foros después de «activarlo todo a la vez».