Ataques DDoS: tipos, síntomas y mitigación

17 de febrero de 2026 • 8 min read

Un DDoS no es un fenómeno nuevo, pero se ha vuelto mucho más fácil, barato y escalable. Antes, unos cuantos servidores mal configurados o un botnet pequeño bastaban para interrumpir un servicio. Hoy vemos ataques que pueden saturar enlaces en fracciones de segundo, abrumar firewalls o tumbar aplicaciones con solicitudes que parecen “normales”.

Este artículo no pretende asustar. Se trata de poner las cosas en contexto: qué es realmente un DDoS, qué clases de ataques importan en la práctica, cómo detectarlos en operación y qué contramedidas merecen la pena.

¿Qué es (D)DoS?

En un ataque de denegación de servicio (DoS), el atacante intenta que un servicio deje de estar disponible no robando datos, sino sobrecargándolo o agotando sus recursos. El objetivo es la disponibilidad: tu web ya no carga, tu API hace timeout, tu gateway VPN deja de aceptar sesiones o tus resolvers DNS no dan abasto.

La “D” de Distributed significa que el tráfico no viene de una sola fuente, sino de muchas. Puede ser un botnet de dispositivos comprometidos, infraestructura legítima (reflection/amplification) o una combinación de ambas. Para ti como operador, el resultado se ve igual: no estás lidiando con un solo atacante, sino con una inundación distribuida.

Motivación: ¿por qué se lanzan ataques DDoS?

Los motivos suelen ser poco glamorosos, pero efectivos:

Extorsión: “Paga o te tiramos otra vez”.
Activismo/política: visibilidad, mensajes, interrupción.
Distracción: un DDoS puede ocupar a tu equipo mientras ocurre otra cosa en paralelo.
Competencia/sabotaje: en momentos críticos (ticketing, releases, lanzamientos), incluso una caída corta duele.
Presión de costes: no todos los ataques buscan un outage total; a veces el objetivo es subir gasto en cloud, carga de soporte o estrés operativo.

Las capas importantes (y por qué importan)

A menudo se habla de DDoS por capas porque la capa te dice qué señales mirar y qué defensas son posibles.

Capa 3 (IP): de dónde viene y adónde va.
Capa 4 (TCP/UDP): puertos, conexiones, handshakes, estado.
Capa 7 (Aplicación): requests HTTP(S), APIs, endpoints de negocio.
“Capa 8” (Lógica de negocio): no es oficial, pero es real: lógica cara en tu app que se puede abusar.

La idea clave: una defensa que funciona perfecto en capa 3/4 puede fallar igual ante ataques de capa 7, porque los requests pueden parecer legítimos y solo se vuelven caros cuando llegan a tu aplicación.

Clase de ataque 1: volumen y amplificación (a menudo UDP)

Los ataques volumétricos buscan saturar ancho de banda o procesamiento de paquetes (pps). Un amplificador clásico es reflection/amplification:

El atacante envía requests pequeños a servidores públicamente accesibles (por ejemplo, resolvers DNS abiertos).
Hace spoofing de la IP de origen y pone la IP de la víctima como “source”.
Esos servidores responden con respuestas mucho más grandes hacia la víctima.

Si un request de 100 bytes dispara una respuesta de 1.000 bytes, ya tienes un factor 10. Según el protocolo y el payload, el factor puede ser bastante mayor. Lo feo: desde el punto de vista de la víctima, el tráfico viene de servicios “normales” que no quieres bloquear.

Punto importante: la amplificación suele depender del spoofing de IP de origen. Por eso el ingress filtering (BCP 38) es tan importante. Si los proveedores bloquean de forma consistente direcciones de origen falsificadas en el edge, este vector se vuelve mucho más difícil.

Clase de ataque 2: agotamiento de protocolo y estado (TCP/capa 4)

No todo DDoS va de máximo ancho de banda. A menudo es más eficiente crear estado en el objetivo hasta llenar tablas o agotar recursos.

Un ejemplo clásico es un SYN flood contra TCP:

Normalmente, TCP establece una conexión con el three-way handshake (SYN -> SYN/ACK -> ACK).
En un SYN flood, el atacante envía enormes cantidades de paquetes SYN, pero el ACK final nunca llega.
El servidor mantiene muchas conexiones a medio abrir (state) y reintenta hasta que entran los timeouts.

Esto consume memoria, CPU y también puede impactar el ancho de banda de salida. Y aunque tengas ancho de banda de sobra: cuando la tabla de sesiones se llena, el “down” está muy cerca.

Una categoría relacionada son los ataques low and slow: el atacante abre conexiones reales y las mantiene abiertas con tráfico mínimo hasta que tu web server o load balancer alcanza límites de conexiones. Esto puede ser mucho menos visible que un pico grande de tráfico.

Clase de ataque 3: capa 7 y “capa 8” (HTTP, APIs, endpoints costosos)

Los ataques de capa 7 suelen ser los más molestos porque cuesta más diferenciarlos de tráfico legítimo. Algunos ejemplos:

HTTP floods: muchos requests a páginas dinámicas, endpoints de búsqueda o flujos de login.
Slowloris/slow headers: se mantienen conexiones abiertas enviando headers o bodies muy lentamente.
Lógica de negocio “cara”: endpoints que disparan queries a base de datos, llamadas a APIs externas, generación de PDF, criptografía o incluso flujos de AI/agents.

El truco no es necesariamente “más tráfico”, sino más trabajo por request. Una pequeña cantidad de tráfico bien elegido puede ser más cara que una ola grande de GETs estáticos cacheados.

¿Cómo detectas un DDoS en producción?

Si solo miras CPU y RAM, verás algunos ataques demasiado tarde. En la práctica, una baseline más unas métricas robustas ayudan mucho:

Tráfico: bps y pps en el edge (router, firewall, load balancer).
Métricas de conexión: nuevas conexiones/s, sesiones abiertas, SYN backlog, handshakes TLS/s.
Métricas HTTP: RPS, latencias (p95/p99), ratios 4xx/5xx, timeouts.
Síntomas upstream: packet loss, RTT más alto, enlaces saturados, eventos BGP.
Señales en logs y WAF: paths inusuales, headers inválidos, muchos requests sin completarse, user agents/patrones sospechosos.

La parte más importante es simple: necesitas una baseline. Sin baseline, todo es “más o menos mucho”. Con baseline, de repente ves que, por ejemplo, “paquetes pequeños” o “requests incompletos” se desvían fuertemente de lo normal.

Mitigación: lo que realmente funciona en la práctica

Hay dos enfoques básicos: make (construirlo tú) o buy (usar un servicio). Para la mayoría de equipos, “buy” es más realista, porque la mitigación DDoS se convierte rápido en un problema que no puedes operar como side project.

1) Poner algo delante de la app: CDN/WAF/proveedor anti-DDoS

Para webs y APIs, suele ser la medida más efectiva:

Anycast distribuye el tráfico en muchas ubicaciones.
Reglas WAF pueden filtrar patrones obvios de capa 7.
Bot management, rate limits y challenge/response reducen ataques “baratos”.

Importante: no todo ataque es HTTP. Si expones servicios como VPN, VoIP, servidores de juegos u otros protocolos basados en UDP, necesitarás otras capas de protección según tu setup.

2) Ajustar bien rate limiting y timeouts

Simple, pero efectivo si se implementa bien:

ICMP/“ping”: límitalo, no lo prohíbas del todo (lo necesitas para troubleshooting).
HTTP: limita por IP/token/ruta, especialmente en endpoints caros.
Requests lentos: timeouts duros para headers/bodies incompletos.

Ejemplo (Nginx, muy simplificado) de límites por ruta:

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

No es una bala de plata, pero cambia la economía: los ataques “baratos” se vuelven más difíciles.

3) Arquitectura: desacoplar trabajo caro

Un DDoS de capa 7 muchas veces no golpea tu ancho de banda. Golpea las partes donde un solo request es desproporcionadamente caro. Y en setups normales sobran ejemplos: login, búsqueda, exportaciones a PDF, informes, uploads, cualquier cosa con queries complejas o que llame a APIs externas.

Ejemplo típico: un portal de clientes tiene un botón de exportación (“factura en PDF”, “generar informe”, “descargar todo como ZIP”). En operación normal alguien lo usa cada pocos minutos. En un ataque, alguien dispara ese endpoint cientos o miles de veces por minuto. El problema no es el ancho de banda; es CPU (rendering), base de datos (queries) y pools de workers (threads/connections). Desde fuera parece que “la web va lenta”. Por dentro ves timeouts, colas y una base de datos que ya no da abasto.

La buena noticia: no tienes que rehacerlo todo para mejorar. A menudo basta con algunas decisiones de arquitectura para separar la parte cara del request path y poner un freno:

Caching (incluyendo páginas de error), TTLs sensatos, edge caching.
Procesamiento asíncrono (colas) para trabajos caros: en lugar de “PDF ya”, lanzar un job y entregar después.
Validación estricta y abort temprano: limitar complejidad, límites duros por request.
Protección separada para login, búsqueda, upload y export: rate limits y timeouts dedicados, y si hace falta pools de workers separados.
“Modo degradado” (feature flags): desactivar temporalmente funciones sin el estrés de un deploy.

4) Opciones upstream: filtrado, scrubbing, planes de emergencia

Si se pone muy grande, tienes que filtrar tráfico antes de que llegue a tu enlace:

Filtrado del proveedor / scrubbing center
Reglas temporales de bloqueo (por ejemplo: “¿por qué hay UDP llegando a mi web server?”)
Emergency routing (por ejemplo, mover tráfico a una IP “protegida”)

Esto solo funciona si lo has hablado con tu proveedor por adelantado. Empezar “ad hoc” en medio de un incidente es caro y lento.

Una checklist pragmática (para equipos sin especialistas en DDoS)

Inventario: ¿qué servicios son públicos? HTTP, DNS, VPN, mail, gaming, VoIP?
Single points of failure: DNS-Provider, reverse proxy, load balancer, ¿una sola región?
Observabilidad: bps/pps, RPS, latencias, errores, conexiones, alertas con baseline.
Endurecer defaults: timeouts, límites, tamaño máximo de headers, límites de conexiones, backpressure.
Plan con el proveedor: quién hace scrubbing, quién puede filtrar, cómo escalar.
Runbook: “si pasa X, entonces Y”, con contactos, umbrales y switches (feature flags).
Practicar: load tests controlados y drills de incidentes (legales y coordinados).

Para terminar: prueba, pero mantenlo legal y útil

Probar DDoS es un tema sensible. Todo lo que toque la internet pública, sistemas de terceros o infraestructura sin permiso explícito está fuera de juego. Lo que sí puedes y deberías hacer:

Load tests en tu staging (por ejemplo para endpoints caros).
Chaos tests de dependencias (cache caída, DB lenta, rate limits más estrictos).
Ensayar el proceso de respuesta: alertas, comunicación, escalado al proveedor, medidas de emergencia.

Fuentes y lecturas recomendadas

Hasta la próxima, Joe