Recibes una alerta por tráfico anómalo, revisas Cloudflare y el WAF ha bloqueado miles de peticiones. La portada carga rápido, el candado SSL aparece correcto y la caché responde. Sin embargo, una consulta al DNS histórico o un escaneo básico revela que la IP del servidor sigue respondiendo directamente por HTTP, HTTPS o puertos de administración.
Una CDN mal configurada que debilita la seguridad puede proteger WordPress en el proxy y dejar expuesto el origen, las respuestas privadas o las rutas administrativas. Basta una IP pública o un puerto accesible para sortear el WAF. La revisión debe validar DNS, TLS, caché, reglas de firewall y acceso al servidor con evidencias y pruebas controladas, cerrando el origen sin bloquear tráfico legítimo.
Índice
Anuncio
Resumen del proceso
Una CDN mal configurada que debilita la seguridad puede proteger la portada de WordPress y dejar el servidor real abierto a cualquiera, por lo que debes comprobar que el origen no acepte peticiones directas.
Sigue este orden de revisión
- Localiza el origen: revisa registros DNS, IPv6, subdominios y respuestas directas de la IP.
- Mide la exposición: compara los accesos que ve el servidor con los que registra la CDN.
- Prioriza el daño: separa un fallo de caché de un bypass que permite atacar WordPress directamente.
- Cierra por fases: autoriza primero los flujos legítimos y limita después el origen a la CDN.
- Prueba y vigila: valida compra, acceso, API, redirecciones y errores 4xx o 5xx antes de dar el cambio por bueno.
Prepara una ventana segura
Haz las pruebas en una franja de menor venta o menor actividad y evita campañas, cierres de mes o envíos masivos de correo.
Guarda antes una captura de las reglas actuales de Cloudflare, Akamai o Fastly, exporta la zona DNS si el proveedor lo permite y anota cómo revertir cada regla. Un rollback consiste en volver al estado anterior si algo falla, como deshacer una modificación antes de que afecte a todos los clientes.
Paso 1: detecta el origen expuesto
Comprueba si el servidor responde fuera de la CDN para verificar que la IP del origen no sirva WordPress a visitantes anónimos.
Revisa DNS, IPv6 y subdominios
Abre el panel DNS de tu proveedor y crea una lista de todos los registros A, AAAA y CNAME. Un registro A apunta un nombre a una IP IPv4; un AAAA hace lo mismo con una IP IPv6, que suele olvidarse con más facilidad.
Prueba la respuesta de la IP
Obtén la IP del origen desde el panel de hosting, la configuración del servidor o un registro DNS que sepas que no usa proxy. Desde un terminal, ejecuta este comando y sustituye los valores entre comillas:
bash curl -I --resolve tudominio.es:443:IP_DEL_ORIGEN https://tudominio.es/
El comando conecta con la IP indicada, pero conserva el nombre de tu dominio para que Nginx o Apache entregue la web correcta. Si devuelve 200, 301 o 302 y muestra tu sitio, el origen acepta tráfico directo; anota fecha, IP, código y cabeceras.
Compara los registros disponibles
Compara los logs de acceso de Nginx, Apache o el hosting con los eventos de seguridad de tu CDN. Si el servidor registra visitas cuya IP de cliente no pertenece a rangos de la CDN, hay acceso directo o una dependencia externa sin documentar.
Además de revisar los registros DNS en el panel, comprueba qué nameservers son autoritativos y consulta la zona desde varios resolutores públicos para detectar propagación incompleta, registros antiguos o respuestas distintas según la red. Verifica uno a uno los registros A y AAAA, los CNAME y los subdominios sin proxy: un hostname como staging, mail, origin o api puede revelar la misma IP de producción aunque www esté protegido. La IPv6 expuesta merece una prueba independiente, porque bloquear solo IPv4 no impide el tráfico directo al servidor.
Documenta el TTL, el estado de proxy inverso y la IP resuelta antes y después de cada cambio; así podrás distinguir una caché DNS temporal de una configuración publicada que debilita la seguridad de la CDN.
Anuncio
Paso 2: prioriza el riesgo real
Clasifica cada hallazgo antes de tocar reglas para corregir primero los fallos que permiten eludir el proxy o exponer datos.
Usa esta matriz de decisión
| Fallo detectado | Evidencia verificable | Impacto probable | Corrección inicial |
|---|---|---|---|
| Origen web público | 200, 301 o 302 al usar la IP con Host correcto | Bypass de WAF, fuerza bruta y DDoS | Permitir solo CDN y accesos inventariados |
| Caché con sesión | Set-Cookie o datos personales en HIT | Fuga de datos o sesión cruzada | Bypass de caché por cookie y ruta |
| TLS flexible | CDN conecta por HTTP al origen | Tráfico interno sin cifrar y bucles | TLS completo con validación |
| CORS abierto | Origen reflejado o comodín indebido | Lectura indebida en APIs | Lista exacta de orígenes autorizados |
Un origen público que entrega WordPress debe tratarse como prioridad alta. Un atacante no necesita romper Cloudflare si puede comunicarse con el servidor sin pasar por Cloudflare.
Distingue caché insegura y ataque de caché
Una respuesta con Set-Cookie, Authorization, datos de pedido o una sesión no debe convertirse en una copia pública compartida. La Agencia Española de Protección de Datos recuerda que el RGPD exige medidas acordes al riesgo cuando se tratan datos personales.
Separa el coste técnico del legal
La recomendación de activar el proxy y una caché agresiva es incompleta para WooCommerce: puede mezclar carrito, moneda, consentimiento o datos de cuenta si no existen exclusiones precisas.
Paso 3: cierra el origen con control
Restringe el origen a tráfico autorizado y conserva una vía de vuelta para que las visitas públicas solo lleguen a WordPress mediante la CDN.
Haz un inventario de entradas
Crea una hoja con cuatro columnas: servicio, dirección de llegada, puerto y responsable. Incluye pasarelas como Redsys, Stripe o PayPal, ERP, CRM, formularios, webhooks, copias de seguridad, monitorización y trabajos cron.
Autoriza CDN y administración
En el firewall del hosting, servidor o proveedor cloud, permite los rangos IP oficiales de tu CDN para los puertos 80 y 443. Copia los rangos desde la documentación oficial del proveedor el mismo día del cambio; estas listas cambian y no conviene reutilizar una lista guardada hace meses.
Cloudflare publica sus rangos en su página oficial de IPs. Para Akamai o Fastly, usa la documentación oficial del contrato o del panel, porque los rangos y métodos de autenticación pueden variar.
Aplica y verifica por fases
Primero crea reglas de permitir para la CDN y para los flujos inventariados. Después añade una regla final de denegación para 80 y 443 desde el resto de Internet, manteniendo el acceso de emergencia separado del dominio público.
El cierre del origen reduce el bypass del WAF, pero no sustituye los controles contra DDoS y abuso en el borde. Configura límites de tasa para rutas que reciben ataques frecuentes, como wp-login.php, xmlrpc.php, búsquedas internas y endpoints de API costosos, sin aplicar el mismo umbral a todo el sitio. Por ejemplo, un límite temporal por IP para intentos de inicio de sesión, combinado con desafíos gestionados ante patrones anómalos, puede frenar la fuerza bruta sin bloquear la navegación normal.
Revisa también que las reglas de firewall de la CDN protejan URLs dinámicas y no solo archivos estáticos. Durante un incidente, correlaciona solicitudes, país, ASN, URI, códigos 429 y consumo del origen para decidir si conviene endurecer una regla, activar mitigación específica o escalar al proveedor.
Paso 4: excluye datos privados de caché
Define qué URLs y respuestas no pueden compartirse para que cada visitante reciba su propia sesión, carrito y datos.
Excluye rutas con identidad
Crea reglas de bypass de caché para /wp-admin/, /wp-login.php, /cart/, /checkout/ y /my-account/, adaptando los slugs si tu tienda está en castellano. Excluye también APIs autenticadas, paneles de membresía y URLs de plugins que muestren facturas, reservas o expedientes.
Revisa cookies y cabeceras
Una respuesta con cookie de sesión no debe aparecer como HIT público. Un HIT significa que la CDN la entregó desde una copia guardada; puede ser correcto para una imagen, no para una cuenta de cliente.
Prueba sin tocar datos reales
Crea dos cuentas de prueba con correos internos, añade un producto distinto a cada carrito y verifica en una ventana privada que ninguna cuenta vea el nombre, pedido, dirección o descuento de la otra.
Anuncio
Paso 5: endurece TLS, DNS y cabeceras
Mantén HTTPS cifrado desde el navegador hasta el origen para impedir que el salto interno se trate como tráfico HTTP normal.
Valida el certificado del origen
En el panel de la CDN, selecciona un modo que cifre y valide el certificado del origen, llamado habitualmente Full (strict) o equivalente. Instala en el servidor un certificado válido para el nombre del dominio, emitido por una entidad reconocida o por la propia CDN cuando el modelo lo admita.
Prueba la cadena con:
bash curl -Iv --resolve tudominio.es:443:IP_DEL_ORIGEN https://tudominio.es/
Audita DNS registro a registro
Elimina registros antiguos de staging si ya no se usan. Si debes conservarlos, protégelos con autenticación, VPN o una lista de IPs y evita reutilizar la misma IP pública de producción.
Las guías de OWASP recomiendan reducir la superficie expuesta y controlar el acceso a los servicios. En este caso, reducir la superficie expuesta significa que el origen no debe estar disponible para Internet sin una razón documentada.
Ajusta cabeceras sin romper servicios
Activa HSTS solo cuando todo el dominio y sus subdominios necesarios funcionen por HTTPS. Empieza una Content Security Policy (CSP) en modo informe, no bloqueante, durante entre 7 y 14 días, y restringe CORS a los dominios que realmente necesiten leer respuestas de tu API.
Evita errores que reabren el riesgo
Controla los cambios y delimita responsabilidades para que una regla nueva, un plugin vulnerable o un proveedor externo no reabra la exposición.
No improvises reglas WAF
Activa reglas gestionadas y revisa los eventos bloqueados antes de crear excepciones. Una excepción amplia para que “funcione el formulario” puede abrir de nuevo rutas sensibles a todo Internet.
Mantén WordPress y terceros actualizados
Actualiza núcleo, temas y plugins desde fuentes legítimas, elimina extensiones abandonadas y aplica autenticación multifactor a todas las cuentas con permisos altos. Un WAF puede frenar ataques conocidos, pero un plugin vulnerable sigue siendo una puerta dentro de la casa.
Vigila y conserva un rollback
Configura alertas para cambios DNS, modificación de reglas CDN, picos de 403, 429 y 5xx, fallos de certificado y peticiones directas al origen. Tras cada cambio, prueba portada, formulario, login, área de cliente, carrito, checkout, webhook y administración antes de confirmar el resultado.
Un origen correctamente oculto no corrige un WordPress comprometido ni un plugin manipulado. Separa ambos escenarios: una mala configuración de CDN se corrige con DNS, proxy, TLS y firewall; una posible intrusión exige preservar logs, poner en mantenimiento solo si es necesario, escanear archivos y base de datos, comparar el código con versiones oficiales y revocar credenciales expuestas. Revisa especialmente plugins descargados fuera de repositorios o fabricantes confiables, cuentas administrativas desconocidas, tareas programadas inesperadas y modificaciones recientes en wp-config.php o en los directorios de extensiones.
Tras actualizar o eliminar un componente vulnerable, rota contraseñas, claves de API y secretos de webhooks cuando exista indicio de acceso no autorizado. La CDN puede limitar la explotación pública, pero no debe usarse como prueba de que la cadena de suministro está íntegra.
Resuelve tus dudas
¿Cómo sé si mi CDN deja expuesta la IP del origen?
Tu origen está expuesto si responde a su IP con tu dominio en la cabecera Host y sin pasar por la CDN. Confírmalo con curl --resolve y compara los logs del servidor con los eventos del proxy.
¿Puedo bloquear el origen y seguir usando webhooks?
Puedes bloquear el origen si autorizas antes cada webhook, pasarela o monitorización que necesite llegar directamente. Prueba pagos y eventos durante entre 15 y 30 minutos después del cambio.
¿Debo desactivar la caché en toda mi tienda?
No debes desactivar toda la caché: excluye carrito, checkout, cuenta, administración y respuestas con sesión o cookies. Las fichas públicas pueden seguir en caché si no incluyen datos personales ni precios variables por usuario.
¿El modo TLS flexible de Cloudflare es seguro?
El modo TLS flexible no protege el tramo entre la CDN y el servidor de origen. Usa cifrado completo con validación del certificado para evitar tráfico HTTP interno y errores de redirección.
- Una CDN no bloquea ataques directos si el origen acepta HTTP o HTTPS desde cualquier IP.
- El cierre seguro exige permitir CDN y dependencias legítimas antes de denegar el acceso público al servidor.
- Las rutas con sesiones, pedidos, cookies o credenciales requieren bypass de caché y pruebas con dos usuarios.
- HTTPS debe mantenerse hasta el origen con certificado validado, DNS revisado y cambios reversibles.
Anuncio
Para saber más
Si deseas profundizar, aquí tienes algunos recursos de interés:
- ¿Qué es un CDN y cómo utilizarlo en una Web ... — webempresa.com
- WordPress no carga por DNS mal configurado qué hacer — reparawordpress.com
- Ataque a CDN compromete plugins de WordPress — ciberseguridad.castillalamancha.es
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.