Cómo verificar si un host o CDN realmente protege contra DDoS (guía práctica)

Ves dashboards llamativos y la promesa de "protección DDoS" en el panel del proveedor, pero lo que importa para el negocio es saber si eso mantiene operativo el checkout durante una oleada maliciosa, preserva sesiones de login y evita la pérdida de llamadas críticas a la API de facturación. Esta guía muestra cómo, sin solicitar privilegios administrativos al proveedor, puedes obtener evidencias operacionales replicables y decidir entre confiar en la capa perimetral (CDN/edge) o contratar mitigación DDoS gestionada.

Tesis práctica: no te fíes de los slogans; valida con señales observables — headers de borde, patrones de error, tiempos de failover y comportamiento de rate limiting. Cuando estas señales faltan o son inconsistentes, la mitigación gestionada suele ser necesaria. A continuación se detallan escenarios, pruebas ejecutables, interpretación de evidencias, límites y una checklist para negociar SLAs y cláusulas contractuales.

Qué journeys críticos probar primero y por qué

Prioriza flujos que provoquen impacto financiero o reputacional inmediato: checkout de e‑commerce, login/autenticación, APIs de facturación y endpoints de webhook. Estos caminos combinan sesiones de usuario, autenticación y llamadas con estado que tienden a fallar ante bloqueos generales aplicados en la periferia.

• Checkout: fallos generan abandono de carrito y problemas contables.
• Login/autenticación: bloqueos afectan acceso y recuperación de cuentas.
• APIs de facturación y webhooks: confirmaciones perdidas afectan conciliaciones.

Qué cubre normalmente una CDN y qué no

Una CDN o servicio de borde reduce la exposición de la origin, suministra rate limiting básico y aplica reglas estáticas o basadas en comportamiento. Esto mitiga muchos vectores simples, pero tiene límites operativos: ataques L7 sofisticados que simulan usuarios legítimos, saturación L3/L4 antes del borde y intentos de descubrir o sortear headers y cachés.

La mitigación gestionada aporta visibilidad global del tráfico, playbooks operativos y escalado humano durante eventos complejos — capacidades que no siempre aparecen en un panel de CDN.

Pruebas que puedes ejecutar sin acceso root al proveedor

Realiza pruebas controladas apuntando a endpoints públicos y recoge respuestas desde el cliente. No lleves a cabo pruebas que infrinjan políticas del proveedor o leyes locales; los pasos a continuación sirven como diagnóstico básico en entornos controlados.

1. Checks sintéticos: realiza solicitudes periódicas que simulen el checkout y registra códigos, latencia y headers.
2. Pruebas de tasa progresivas: aumenta la tasa de requests por IP o por sesión en incrementos pequeños y observa dónde se disparan latencia y errores.
3. Failover y origen: simula cambios temporales en DNS local o proxy para evaluar tiempo de failover y rutas de recuperación.
4. Validación de origen directa: cuando esté autorizado, realiza requests vía IP directa para comprobar si la origin responde sin pasar por la periferia.

Cómo ejecutar un rate test seguro

Define un objetivo de prueba corto y controlado, usando IPs de prueba y ventanas breves. Registra timestamps, headers y códigos. No aumentes el volumen hasta tener logs que permitan distinguir 429 (too many requests) de 5xx (fallo de servidor/origin).

Cómo recolectar e interpretar evidencias: headers, logs y patrones de error

Sin acceso a los logs del proveedor, céntrate en evidencias que el cliente puede recoger: headers HTTP, códigos de estado, tiempos de respuesta y patrones de repetición. Solicita al proveedor logs detallados tras la prueba — más abajo describo los campos recomendados.

Headers útiles y qué indican

• X‑Edge‑Request‑ID o similar: confirma que la petición pasó por el borde.
• X‑RateLimit‑Remaining y X‑RateLimit‑Reset: indican políticas de rate limiting activas.
• X‑Cache‑Status: muestra si el contenido se sirvió desde cache o fue proxied a origin.
• Server / Via: cambios pueden indicar proxies intermedios o reroutes.

Los nombres son ilustrativos — lo clave es detectar headers que prueben la presencia del edge, la aplicación de límites y el caching. La ausencia no prueba falta de mitigación, pero exige evidencia adicional.

Errores 4xx vs 5xx y su interpretación

Respuestas 4xx (especialmente 429) durante incrementos controlados normalmente indican filtrado activo o rate limiting. Errores 5xx persistentes apuntan a saturación de la origin o fallos internos. En incidentes reales, un patrón de 429 seguido por 5xx a medida que la origin se sobrecarga es habitual.

Señales de que la periferia está siendo eludida

Busca estas señales durante y después de las pruebas:

• Respuesta directa de la origin al hacer petición por IP o manipular el header Host (solo en pruebas autorizadas).
• Headers inconsistentes entre regiones (una región muestra headers de borde y otra no).
• Latencia en la origin que aumenta mientras la periferia muestra latencia baja — señal de tráfico malicioso alcanzando la origin por otra ruta.
• Logs de origin mostrando tráfico desde IPs que deberían haber sido filtradas.

Si aparecen estas señales, solicita evidencias correlacionadas por timestamps al proveedor y, si procede, escala a equipos de respuesta a incidentes.

Criterios para decidir cobertura de L7 y L3

Evalúa con criterios objetivos:

• Mitigación L7: rate limiting por sesión, bloqueo por fingerprinting y tasa de éxito de flujos críticos; evidencia: 4xx de filtrado en el borde y logs de borde con firma del evento.
• Mitigación L3/L4: capacidad de absorción volumétrica y failover de red; evidencia: métricas de throughput en el borde y registros de filtrado de rutas — normalmente entregados por el proveedor en informes post‑evento.

Sin logs BGP o métricas volumétricas, solo observarás síntomas; evita conclusiones absolutas.

Compensaciones: cuándo basta la CDN y cuándo contratar mitigación gestionada

Opta por una CDN cuando el tráfico es mayormente estático, los flujos críticos toleran rate limiting simple y tu equipo puede validar headers y comportamientos. Contrata mitigación gestionada cuando las jornadas críticas requieren disponibilidad constante, ataques anteriores evidenciaron evasión del borde, o requieres playbooks operativos y remediación en tiempo real.

Recuerda que la mitigación gestionada complementa, y no sustituye, las buenas prácticas de ingeniería como WAF, validación de entrada y arquitectura resiliente.

Checklist operativo para negociar con proveedores

1. Pide cláusula de visibilidad: acceso a logs de borde y muestras por timestamps durante pruebas.
2. Define indicadores observables (headers, códigos de estado, tiempos de failover) como criterios de aceptación.
3. Exige playbooks de escalamiento y SLAs de respuesta a incidentes.
4. Solicita pruebas coordinadas: evalúa el comportamiento durante una ventana y alcance acordados.

Preguntas frecuentes

¿Una CDN garantiza protección total contra DDoS?

No. Una CDN reduce exposición y bloquea vectores básicos, pero puede no detener ataques L7 sofisticados que simulan tráfico legítimo ni evitar rutas alternativas hasta la origin. Valida con las pruebas y evidencias descritas.

¿Cómo diferenciar tráfico legítimo de ataque en mis métricas?

Compara patrones: aumentos súbitos de requests sin incremento de conversión, user‑agents repetitivos, ausencia de cookies esperadas y aumento de errores 4xx/5xx. Logs de sesión y correlación por fingerprint ayudan a separar ruido de ataque.

¿Qué es el failover de origin y por qué importa?

El failover de origin es el tiempo y proceso para redirigir o recuperar servicio cuando la origin está inaccesible. Importa porque los cache hits pueden ocultar fallas de la ruta de escritura — checkout y facturación dependen de la origin, por eso ventanas largas de failover significan pérdida transaccional.

¿Qué logs pedir al proveedor para validar mitigación?

Pide logs de borde con timestamps: campos de request (IP, Host, User‑Agent), acciones ejecutadas (bloqueo, challenge, rate limit) y muestras de tráfico descartado. Para mitigación de red, solicita métricas de pico y registros de cambios de ruta/filtrado.

Qué puede coordinar MVX Shield y qué queda para tu equipo

MVX Shield puede ejecutar una evaluación técnica coordinada con pruebas controladas y entregar un informe de evidencias y recomendaciones de hardening para flujos críticos L7. No sustituimos la ingeniería segura de la aplicación: los equipos internos deben aplicar las correcciones derivadas del informe.

Siguiente paso

Solicita una evaluación técnica de protección DDoS y recibe un informe de evidencias accionables. Inicia una evaluación vinculada a L7 Hardening y Website Security, y contacta Incident Response si necesitas soporte en la respuesta a incidentes. Solicita una evaluación técnica de protección DDoS y obtén un reporte de evidencias accionables.