DDoS: defensa en capas para tu negocio

Un ataque de denegación de servicio distribuida no intenta robar datos: intenta que tus clientes no puedan entrar. Lo consigue agotando el recurso que se acabe primero, ya sea el ancho de banda, la tabla de conexiones, la CPU o el conjunto de conexiones a base de datos. Por eso ningún producto suelto resuelve el problema: cada familia de ataque consume un recurso distinto y cada capa de defensa tapa un fallo concreto.

Lo que sigue es el orden real en el que las capas frenan un ataque, desde la capacidad que no es tuya hasta el momento en que ya está ocurriendo.

Qué agota realmente un ataque DDoS

Familia	Ejemplos	Qué satura	Dónde hay que frenarlo
Volumétrico	Inundaciones UDP, amplificación DNS y NTP, barrido de rangos	El enlace de red	Aguas arriba, en el proveedor o en una red de limpieza
Protocolo	SYN flood, ACK flood, floods de conexiones	Tablas de conexiones de servidores y balanceadores	Límites en el borde, ajuste del núcleo y SYN cookies
Capa de aplicación (L7)	HTTP flood, cache busting, slowloris, abuso de API	CPU, procesos y conexiones a base de datos	CDN y WAF, caché y límites por ruta

La consecuencia es incómoda: si el ataque supera el tamaño de tu enlace, nada de lo que configures en el servidor importa. Los paquetes han ganado antes de que una regla local los vea, así que la mitigación volumétrica tiene que vivir aguas arriba. El resto sí puedes endurecerlo tú.

Por qué las pymes son el objetivo rentable

El objetivo clásico era la gran empresa; hoy el cálculo del atacante es otro. Alquilar capacidad de ataque es barato y no exige saber de redes: los paneles de estrés se anuncian como pruebas de carga y se pagan por horas, de modo que el coste de intentarlo es mínimo.

Una pyme reúne justo lo que ese atacante busca. No hay guardia: un ataque lanzado un viernes por la noche tiene doce horas de ventaja. No hay margen para improvisar: el mismo proveedor aloja la web, el correo y la facturación, así que si cae el enlace se cae la operación entera. Y hay urgencia comercial: una tienda que lleva tres días sin vender acepta conversaciones que una empresa con centros de datos propios ni escucharía. En alojamiento compartido hay además un factor que casi nadie valora: el vecino atacado te arrastra, y muchos barridos masivos no eligen a nadie en concreto, solo recorren rangos enteros de direcciones. El informe anual del panorama de ciberseguridad apunta en la misma dirección: menos barreras de entrada y más incidentes pequeños.

Capa 1: mitigación aguas arriba con CDN y anycast

Toda defensa seria empieza por capacidad que no es tuya. Una red de limpieza reparte el tráfico de ataque entre decenas de ubicaciones, lo filtra y solo reenvía las peticiones legítimas a tu servidor.

Coloca el tráfico público detrás de una CDN o un proxy inverso con mitigación incluida (Cloudflare, CloudFront con Shield, Azure Front Door, Gcore, Bunny o Fastly).
Pregunta a tu proveedor cuánta capacidad de mitigación hay delante de tu IP y si está siempre activa o solo se enciende al detectar el ataque. La protección bajo demanda deja un hueco justo en el minuto en que empieza el problema.
Prefiere anycast: diluye las inundaciones volumétricas por geografía en lugar de pedirle a un solo centro de datos que las absorba.

El error habitual es creer que la CDN, por sí sola, resuelve el asunto. Es la primera capa, no la única.

Capa 2: cerrar la IP de origen

Este es el paso que casi todos los equipos se saltan, y deshace en silencio el anterior. Si el atacante descubre la dirección real del servidor, rodea la CDN y golpea el origen directamente; la técnica se llama direct-to-origin y no requiere nada sofisticado.

Las direcciones de origen se filtran por vías previsibles: historial DNS, con registros antiguos de antes de mover el dominio detrás del proxy; registros de transparencia de certificados, donde quedan los certificados del nombre de origen; subdominios como mail., vpn., ftp. o dev., que suelen resolver a la misma máquina; cabeceras de correo, porque el correo saliente puede llevar la IP en las líneas Received:; y registros heredados MX, SPF o TXT que apuntan fuera de la CDN.

Qué hacer: rota la IP del origen cuando la CDN esté en producción, limita el cortafuegos a los rangos publicados por la CDN en los puertos 80 y 443 y revisa tu exposición cada trimestre. Diez minutos de comprobación valen más que cualquier regla nueva.

Capa 3: WAF y límites de peticiones

Un cortafuegos de red ve una conexión TCP válida y la deja pasar. Un WAF lee la petición HTTP, que es donde vive el ataque de aplicación: peticiones malformadas, intentos de explotación y oleadas de bots contra el formulario de acceso o el buscador.

Activa primero las reglas gestionadas (OWASP más la inteligencia del proveedor) y añade después reglas propias: bloquear cuerpos sobredimensionados en las rutas de subida, exigir un reto en administración y limitar por ruta en lugar de por sitio.

El límite de peticiones es el control más rentable y el peor configurado. Un tope solo en el servidor web no sirve contra el tráfico que primero satura la red, y un tope que solo mira la IP hace poco contra una botnet con miles de orígenes. Escalona: en el borde, por IP, ASN y, si procede, país; en la aplicación, por sesión, clave de API y usuario; por ruta, con topes estrechos en acceso, recuperación de contraseña, búsqueda y pago. Usa cubos de fichas o ventanas deslizantes y devuelve 429 con Retry-After para que el cliente legítimo se retire en vez de insistir.

Capa 4: caché, capacidad contratada y contacto en el proveedor

Una petición servida desde caché nunca llega al origen, así que no consume ni un proceso ni una conexión a base de datos. Todo lo que pueda ser estático debería serlo: imágenes, CSS, JavaScript y el HTML de los visitantes anónimos.

Dos detalles importan durante el ataque. El cache busting es una técnica de ataque: cadenas de consulta aleatorias fuerzan cada petición hasta el origen, así que configura la CDN para ignorar parámetros irrelevantes en rutas cacheables. Y la tasa de acierto es una métrica de seguridad: si cae del 85 % al 20 % en plena incidencia, estás pagando coste de origen por tráfico de ataque.

La capacidad se compra con contrato, no con optimismo. Si cada hora de caída te cuesta dinero, exige un SLA de limpieza, un umbral definido, contactos de escalado con nombre y un soporte que conteste durante el ataque; guarda el número de cuenta donde la persona de guardia lo encuentre sin buscarlo. Y si el ataque es de estado, no olvides lo aburrido: SYN cookies activas, tcp_max_syn_backlog y somaxconn ajustados a tu concurrencia real, y un límite de conexiones por origen en el borde.

Cómo se ve un ataque en los registros

No puedes defender lo que no ves. Antes del incidente, anota tu normalidad: peticiones por segundo, bytes de entrada y salida, proporción de 4xx y 5xx, latencia p95, conexiones abiertas y URL más pedidas. Después alerta sobre la desviación, no sobre el valor absoluto: un pico de cinco veces el tráfico con la tasa de errores estable suele ser una campaña de marketing funcionando, mientras que un volumen plano con latencia y conexiones subiendo huele a agotamiento de estado.

Los patrones que verás son las mismas tácticas y técnicas de los atacantes que se documentan en cualquier informe de incidente. Señales que aparecen casi siempre:

Una sola URL concentrando una parte anormal del tráfico: buscador, acceso o un punto de conexión de API.
Miles de direcciones distintas con la misma firma de agente de usuario, o con ninguna.
Latencia al alza mientras los usuarios únicos no se mueven.
Tráfico entrante muy por encima de lo que el servidor dice haber servido.
Errores 499, 502 y 504 en el balanceador y tiempos de espera agotados en la base de datos.

Secuencia de incidente: detectar, contener, comunicar, revisar

Detectar. Confirma que es un ataque y no una campaña que funciona. Mira la composición del tráfico antes de bloquear nada.

Contener. Abre el ticket con el proveedor o con el soporte de la CDN de inmediato: la mitigación aguas arriba tarda en activarse. Después enciende el modo bajo ataque, las reglas gestionadas, límites más estrictos y un reto de JavaScript en las rutas castigadas, y comprueba que el origen solo acepta tráfico de la CDN.

Comunicar. Primero la página de estado, después los canales de soporte. El silencio hace más daño que el ataque: un cliente informado espera, uno desinformado se va.

Revisar. En frío, reconstruye la cronología, identifica qué capa falló primero y cuánto costó la hora de caída. Actualiza el runbook y conserva registros, capturas de paquetes y marcas de tiempo: sirven para el proveedor, para el seguro y para cualquier reclamación.

Lista de comprobación previa al ataque

Control	Estado esperado	Cómo comprobarlo
Mitigación aguas arriba	CDN o limpieza delante de todo el tráfico público	Consulta de DNS desde fuera de la red
IP de origen	Rotada y con cortafuegos limitado a la CDN	Escaneo externo y revisión del historial DNS
WAF	Reglas gestionadas más reglas propias	Prueba controlada en una ruta protegida
Límites	Borde, aplicación y rutas caras	Prueba de carga con umbral conocido
Visibilidad	Alertas de RPS, errores, latencia y conexiones	Simulacro de alerta
Runbook	Una página, actualizada y con responsables	Lectura en voz alta por quien no lo escribió

Cada casilla vacía es una grieta concreta. Si prefieres no improvisar la siguiente, hablemos de tu caso y revisamos la exposición antes del próximo pico.

Denuncia: qué exige la ley española

Un DDoS no es una travesura: es un delito de daños informáticos. El artículo 264 del Código Penal castiga a quien, sin autorización y de forma grave, borra, daña, altera, suprime o hace inaccesibles datos o programas informáticos ajenos, y dificultar el acceso a un sistema encaja en ese tipo. La vía penal existe, pero pide documentación en lugar de indignación.

El orden correcto es siempre el mismo: primero se preserva la evidencia —registros con marcas de tiempo, capturas de paquetes, copia del correo de extorsión si lo hay— y después se notifica. Si el servicio trata datos personales, el RGPD obliga a valorar la notificación a la Agencia Española de Protección de Datos en un máximo de 72 horas desde que se conoce la brecha. En paralelo, INCIBE-CERT atiende y coordina incidentes de empresas y ciudadanos, y la denuncia formal se presenta en las unidades de delitos telemáticos de la Policía Nacional o de la Guardia Civil.

Nada de esto detiene el ataque por sí solo. Lo que hace es convertir la incidencia en un expediente útil para el seguro, para la relación con el proveedor y para explicar ante un cliente qué ocurrió y cuándo.

Preguntas frecuentes

¿Se puede evitar por completo un ataque DDoS?

No. Cualquiera puede enviar tráfico hacia un servicio público y esa asimetría no se cierra. El objetivo realista es absorberlo y filtrarlo sin que los usuarios legítimos se caigan.

¿Basta con una CDN para frenar un ataque DDoS?

Absorbe las inundaciones volumétricas y buena parte del abuso de capa 7, pero no arregla la exposición del origen ni el agotamiento de estado. Es una capa, no la solución.

¿Cómo distingo un ataque de un pico legítimo?

Mira la composición, no el volumen. Un pico concentrado en una geografía o una sola URL, con agentes de usuario raros, latencia al alza y conversión plana, es un ataque; uno repartido entre tus fuentes habituales suele ser una campaña que funciona.

¿Qué debería hacer primero una pyme?

Poner el tráfico detrás de una CDN con mitigación, cerrar la IP de origen, activar las reglas gestionadas del WAF y escribir un runbook de una página.

¿Necesito un proveedor dedicado de mitigación?

Solo si cada hora de caída cuesta más que el contrato. Empieza con el nivel de CDN, mide tu exposición y sube cuando los números lo justifiquen.

Lecturas relacionadas

Si quieres que alguien revise tu configuración de borde, tus límites y tu runbook antes del próximo incidente, hablemos de tu caso.