Defaults.Exposed › Soluciones › CDN / WAF y hosting

Cómo arreglar CDN / WAF y hosting

Dos lecturas de la fontanería que hay detrás de tu sitio web: si te sitúas detrás de un escudo protector (un CDN con un cortafuegos de aplicaciones web, como Cloudflare) que filtra ataques y absorbe picos de tráfico, y un mapa de quién gestiona realmente tu DNS, tu sitio web y tu correo. Ambas son informativas en nuestra puntuación —no mueven tu nota—, pero describen cuán expuesto está tu servidor de origen a ataques y caídas, y cuán enredados están tus proveedores. Un escudo delante y un conjunto de proveedores sensatamente repartido es como se ven los negocios resilientes.

En resumen, para tu negocio: Un sitio web sin un escudo delante recibe cada ataque y cada pico de tráfico directamente en el servidor de origen, así que una avalancha de bots, una oleada del día del lanzamiento o un solo ataque automatizado puede dejarte fuera de línea durante horas, y la recuperación es cosa tuya. Poner un CDN/WAF delante (hay nivel gratuito) filtra la inmensa mayoría de los ataques automatizados, absorbe las oleadas y acelera el sitio en todo el mundo, normalmente una tarde de trabajo para tu informático, sin coste de licencia. Aparte, si tu DNS, tu sitio web y tu correo viven todos con un solo proveedor, una sola caída o brecha ahí derriba toda tu presencia en línea a la vez; conocer tu mapa de proveedores es lo primero que necesitas en un incidente. Ninguna de las dos comprobaciones cambia tu nota, pero ambas describen una exposición real a tiempo de inactividad, ventas perdidas y una recuperación lenta y dolorosa.

Lo que esto te puede costar

• Una ráfaga de tráfico de bots o un pequeño DDoS golpea tu servidor sin escudo la mañana de una gran promoción: el sitio se arrastra o se cae, los clientes reciben errores en el pago, y pierdes las ventas del día mientras tu hosting forcejea. Un CDN/WAF delante lo habría absorbido.
• Tu DNS, tu sitio web y tu correo funcionan todos a través de un solo proveedor; ese proveedor tiene una caída y tu sitio, tu sistema de reservas Y tu correo se apagan todos en el mismo momento: ni siquiera puedes enviar un «somos conscientes del problema» porque el buzón también está caído.
• Un ataque automatizado sondea tu sitio toda la noche —scripts de inyección SQL y de adivinación de inicios de sesión machacando tu origen directamente porque no hay capa de cortafuegos que los filtre— y solo te enteras cuando algo se rompe. Un WAF bloquea el grueso de ese ruido antes de que llegue siquiera a tu código.
• Llega un incidente y nadie puede responder a la pregunta básica «¿a quién llamamos siquiera?»: ¿está el sitio web en el mismo hosting que el correo? ¿Quién lleva el DNS? Las horas se desangran solo mapeando la fontanería mientras el sitio sigue caído.
• El equipo de informática de un cliente potencial te analiza antes de firmar y ve un servidor de origen pelado sin CDN/WAF y una cabecera de versión de servidor con fugas anunciando exactamente qué software (y versión) ejecutas: una pequeña señal de «esta gente no ha endurecido lo básico» en el peor momento posible.

Por qué importa. Ambas comprobaciones aquí son informativas en nuestra metodología —están registradas con cero puntos y nunca cambian tu nota— porque describen tu infraestructura en lugar de probar un control de seguridad de aprobado/suspenso. Las mostramos porque mapean una exposición real del negocio. Un sitio sin CDN/WAF recibe cada ataque y cada pico de tráfico en el origen directamente, sin filtrado y sin absorción de oleadas; añadir uno (el nivel gratuito de Cloudflare es la vía común) es una de las mejoras de resiliencia de mayor palanca y menor coste que una empresa pequeña puede hacer. Y un mapa de proveedores claro —saber si tu DNS, web y correo están repartidos o apilados en un solo proveedor— es lo primero que necesitas cuando algo va mal y la diferencia entre un incidente contenido y un apagón total.

Qué es esto, en palabras llanas

Todo sitio web funciona en un servidor en algún lugar. La pregunta que responde esta página es: ¿qué hay entre el internet abierto y ese servidor, y quién gestiona realmente las piezas de tu presencia en línea?

Hay dos partes:

1. CDN / WAF — el escudo de delante. Un CDN (red de distribución de contenidos) es una red global que se sitúa delante de tu sitio, sirve tu contenido rápido a visitantes de cualquier parte y absorbe oleadas de tráfico. Un WAF (cortafuegos de aplicaciones web) es un filtro que inspecciona las peticiones entrantes y bloquea las maliciosas antes de que lleguen a tu servidor. Los servicios populares (Cloudflare, AWS CloudFront, Fastly, Akamai, Sucuri y otros) los juntan. Miramos las respuestas de tu sitio e informamos de si podemos ver un escudo delante, y anotamos también qué servidor web ejecutas.

2. Mapa de hosting / proveedores — quién lleva tu fontanería. Leemos los registros públicos que dicen quién gestiona tu DNS (el directorio que convierte tu dominio en una dirección) y quién gestiona tu correo. A partir de ahí podemos saber si tu DNS, tu sitio web y tu correo están repartidos entre proveedores (resiliente) o apilados en uno (cómodo, pero un punto único de fallo).

Lo más importante que hay que saber de entrada: en nuestra puntuación, ambas son informativas. No afectan a tu nota. Las mostramos porque describen cuán expuesto está tu negocio a tiempo de inactividad y a ataques, que es una pregunta distinta, y muy práctica, de la nota.

Lo que esto puede costarte

No son riesgos abstractos: son las formas cotidianas en que una configuración sin escudo y enredada convierte un problema pequeño en un mal día.

• Fuera de línea el día que más importa. Tu sitio está en el servidor de origen sin nada delante. La mañana de un lanzamiento o una promoción, el tráfico se dispara —o golpea una avalancha de bots modesta— y el servidor no puede con ello. Las páginas dan tiempo de espera agotado, el pago da error y pierdes los ingresos del día mientras tu hosting apaga fuegos. Un CDN absorbe las oleadas y un WAF filtra el tráfico basura; juntos son la diferencia entre «día ajetreado» y «caído toda la mañana».

• Todo se apaga a la vez. Tu DNS, tu sitio web y tu correo funcionan todos a través de un solo proveedor. Ese proveedor tiene una caída (les pasa a todos tarde o temprano) y tu sitio, tu sistema de reservas y tu correo se desvanecen simultáneamente. No puedes procesar pedidos, y ni siquiera puedes enviar un correo a los clientes para decir que eres consciente, porque el buzón también está caído. Repartir proveedores significa que un fallo queda contenido, no total.

• Tu código recibe cada ataque directamente. Sin WAF, cada sondeo automatizado —intentos de inyección, adivinación de inicios de sesión, escáneres de exploits conocidos— golpea el código de tu aplicación sin filtrado. Estás apostando a que tu software es impecable y está totalmente parcheado, para siempre. Un WAF bloquea la abrumadora mayoría de ese ruido automatizado antes de que llegue a ti, convirtiendo «ataque de fondo constante» en «mayormente filtrado».

• Un incidente lento y presa del pánico porque nadie tiene el mapa. Algo se rompe y la primera hora se desperdicia en «espera, ¿quién lleva nuestro DNS? ¿Está el correo en el mismo hosting? ¿A quién llamamos?». Cuando tu mapa de proveedores no está claro, cada incidente empieza de cero. Conocer el mapa de antemano convierte un caos en una llamada de teléfono.

• Una mala primera impresión ante un comprador cuidadoso. El equipo de informática de un cliente potencial te analiza antes de firmar y ve un origen pelado sin CDN/WAF, y una cabecera de servidor anunciando abiertamente tu software y versión exactos. Es una señal pequeña, pero te coloca en la columna de «no ha endurecido lo básico» en exactamente el momento equivocado.

Qué es en realidad

CDN / WAF — la capa protectora

Cuando un visitante (o un atacante) solicita tu sitio, la petición puede ir directa a tu servidor de origen, o puede ir a través de un CDN/WAF primero. Si hay un escudo delante, ese escudo puede:

• Filtrar peticiones maliciosas (la parte WAF): bloquear intentos de inyección, ataques de bots y patrones de exploit conocidos antes de que lleguen siquiera a tu código.
• Absorber tráfico (la parte CDN): servir contenido cacheado desde servidores cerca de cada visitante y absorber oleadas, para que un pico —legítimo u hostil— no aplaste tu origen.
• Acelerar el sitio: el contenido servido desde un servidor de borde cercano carga más rápido para visitantes de todo el mundo.

Detectamos un escudo mirando las huellas que estos servicios dejan en las cabeceras de respuesta de tu sitio: por ejemplo, una cabecera cf-ray (Cloudflare), x-amz-cf-id (Amazon CloudFront), x-served-by (Fastly), x-akamai-transformed (Akamai) o x-sucuri-id (Sucuri). También leemos la cabecera Server para identificar tu servidor web subyacente (nginx, Apache, IIS, LiteSpeed, Caddy, etc.) y señalamos cualquier cabecera X-Powered-By que comparta de más.

Cómo es lo «bueno»: un CDN/WAF detectado delante de tu origen, y una cabecera Server que no anuncie un número de versión concreto.

Mapa de hosting / proveedores — tus dependencias de infraestructura

Tu dominio apunta sin ruido a varios servicios distintos:

• DNS — el directorio que convierte tunegocio.com en la dirección de servidor real. Leemos tus registros de servidor de nombres (NS) y reconocemos proveedores comunes (Cloudflare, AWS Route 53, Azure DNS, GoDaddy, Namecheap, DigitalOcean, Hetzner, Linode y registradores regionales entre ellos).
• Correo — donde se gestiona tu correo. Leemos tus registros MX y reconocemos proveedores comunes (Google Workspace, Microsoft 365, Proofpoint, Mimecast, Barracuda, Zoho y otros).

A partir de esto podemos ver si estas responsabilidades están repartidas entre proveedores (un fallo en uno no derriba los demás) o apiladas en un solo proveedor (cómodo, pero una caída o brecha se lo lleva todo).

Cómo es lo «bueno»: como mínimo, el DNS en manos de un proveedor dedicado y fiable, en lugar de incluido en la misma cuenta que todo lo demás, para que el directorio de tu dominio no comparta destino con tu sitio web y tu buzón.

Cómo solucionarlo (gratis, ~1 tarde)

Pásale esto a tu informático o a tu desarrollador web: la solución es gratuita. Poner un CDN/WAF delante de tu sitio no cuesta nada en los niveles gratuitos comunes, y suprimir la versión de tu servidor es un ajuste de una línea. No hay licencia que comprar. (Las opciones de pago aquí son solo monitorización, seguimiento de cartera y auditorías, nunca la solución en sí.) La única decisión del dueño es: sí, pon un escudo delante del sitio.

Como ambas comprobaciones son informativas, nada de esto está puntuado, pero un CDN/WAF es una de las mejoras de resiliencia de mayor valor que una empresa pequeña puede hacer, así que merece la pena.

1. Pon un CDN/WAF delante de tu sitio

La vía más común y gratuita es Cloudflare:

1. Crea una cuenta gratuita de Cloudflare y añade tu dominio.
2. Cloudflare lee tus registros DNS existentes; comprueba que se importaron correctamente.
3. Cambia los servidores de nombres de tu dominio (en tu registrador) a los dos que te da Cloudflare. Este es el cambio que enruta el tráfico a través de Cloudflare.
4. Pon el modo SSL/TLS en Full (strict) para que el cifrado se mantenga de extremo a extremo entre visitante → Cloudflare → tu origen. (Evita «Flexible», que deja el último tramo sin cifrar.)
5. El CDN y un WAF de base ya están activos. Puedes afinar las reglas del WAF más tarde, pero los valores por defecto ya filtran mucho.

Otras vías, según tu stack:

• AWS CloudFront — crea una distribución apuntando a tu origen; combínalo con AWS WAF para el filtrado. Lo mejor si ya estás en AWS.
• Sucuri WAF — basado en DNS, no requiere cambios en tu servidor; bueno si no puedes tocar el origen.
• Fastly / Akamai — CDN/WAF de grado empresarial, normalmente para sitios más grandes o de más tráfico.

Tras cambiar, prueba el sitio, confirma que HTTPS funciona en todas partes y vigílalo un día. No caches de forma agresiva páginas que deban mantenerse personales o en vivo (áreas con sesión iniciada, carritos, pagos).

2. Deja de anunciar la versión de tu servidor

Añadas o no un CDN, suprime la versión que anuncia tu servidor: es información gratis que estás entregando a los atacantes.

Nginx:

server_tokens off;

Apache (en la configuración principal):

ServerTokens Prod
ServerSignature Off

Quita una cabecera X-Powered-By que comparta de más (p. ej. de PHP o de un framework de aplicación) a nivel de servidor o CDN; en Cloudflare puedes eliminarla con una regla de transformación de cabecera de respuesta.

3. Comprobación de cordura de tu mapa de proveedores (opcional, ~10 minutos)

Mira dónde viven realmente tu DNS, tu sitio web y tu correo:

• Si los tres están en una sola cuenta de proveedor, plantéate al menos mover el DNS a un proveedor dedicado (el DNS de Cloudflare es gratis y rápido). Ese único reparto significa que el directorio de tu dominio sobrevive a una caída del hosting.
• Anota el mapa: proveedor de DNS, hosting web, proveedor de correo, registrador y el contacto de inicio de sesión/soporte de cada uno. Esta única página es lo más útil que puedes tener delante durante un incidente.

Notas por plataforma

• Google Workspace / Microsoft 365: estos son tus proveedores de correo, no tu sitio web. Poner un CDN/WAF delante del sitio web no toca el correo, y viceversa: son decisiones separadas. (Tener el correo en Google/Microsoft y el sitio web detrás de Cloudflare es una configuración perfectamente buena y deliberadamente repartida.)
• Constructores de sitios gestionados (Wix, Squarespace, Shopify): estos incluyen su propio CDN y un nivel de protección WAF como parte de la plataforma, así que puede que ya estés con escudo aunque nuestra comprobación de cabeceras no nombre un proveedor. Normalmente no puedes añadir tu propio Cloudflare delante; no pasa nada, la plataforma se encarga.
• WordPress en tu propio hosting: candidato ideal para una capa gratuita de Cloudflare delante. Combínalo con el cortafuegos de un plugin de seguridad para las reglas a nivel de aplicación.

Errores habituales

• Tener un origen pelado «porque el sitio es pequeño». Los sitios pequeños reciben los mismos ataques automatizados y avalanchas de bots que los grandes: los bots no comprueban tus ingresos primero. El nivel gratuito de CDN/WAF existe precisamente para los sitios pequeños; no usarlo es dejar una victoria fácil sobre la mesa.
• Usar el SSL «Flexible» de Cloudflare. Muestra un candado pero deja sin cifrar la conexión entre Cloudflare y tu origen. Usa siempre Full (strict) para que esté cifrado de extremo a extremo.
• Cachear las cosas equivocadas. Cachear de forma agresiva páginas con sesión iniciada, carritos o pagos puede mostrar a un cliente el contenido de otro o precios obsoletos. Cachea el contenido estático; deja sin cachear las páginas personalizadas y transaccionales.
• Apilar todo en un solo proveedor sin darse cuenta. La comodidad está bien si es una elección consciente, pero muchos negocios solo descubren que el DNS, la web y el correo comparten una cuenta durante la caída que se lleva los tres. Que sea una decisión, no un descubrimiento.
• Dejar la versión del servidor a la vista. Es un paso de endurecimiento gratuito de una línea que es fácil de olvidar. Apágalo.

Una nota sobre la nota

Para ser del todo claros: ninguna de estas comprobaciones afecta a tu nota. Están registradas en nuestra metodología como informativas, con cero puntos, y nunca te penalizamos por un origen sin escudo o una configuración de un solo proveedor. Las informamos porque describen una exposición real a tiempo de inactividad, ataques y recuperación lenta de incidentes, y porque añadir un CDN/WAF gratuito es una de las mejoras de mejor relación calidad-precio que una empresa pequeña puede hacer. Si no haces nada aquí, tu nota no cambia. Si pones un escudo delante de tu sitio y repartes tu DNS, has hecho el negocio significativamente más resiliente gratis. Esa es la forma correcta de leer esta página: no un número que defender, sino una mejora de resiliencia que merece la pena aprovechar.

Preguntas frecuentes