Ataques DDoS explicados: formas comunes y cómo protegerte

Primero la respuesta: ninguna capa por sí sola detiene un DDoS

Un ataque de denegación de servicio distribuido es un intento de agotar un recurso del que dependes (tu ancho de banda, la tabla de conexiones de tu servidor, o la capacidad de tu aplicación para responder solicitudes) usando tráfico procedente de muchas fuentes a la vez. Lo más útil que puedes entender es que distintas formas de ataque agotan distintos recursos, y una defensa que funciona contra una familia no sirve de nada contra otra:

• Los ataques volumétricos llenan tu conexión de red. En cuanto tu uplink se satura, ya no importa nada de lo que configures en el servidor; el tráfico tiene que absorberse o descartarse upstream, mediante la mitigación de tu proveedor de hosting o un servicio de scrubbing.
• Los ataques de protocolo (agotamiento de estado) llenan las tablas de seguimiento de conexiones de servidores, firewalls y balanceadores de carga. Se combaten con SYN cookies, timeouts sensatos y límites de tasa, en parte en el propio host, en parte en el edge.
• Los ataques de capa de aplicación agotan tu aplicación con solicitudes que parecen legítimas. Necesitan defensas de capa 7: caché, limitación de tasa, un WAF o CDN, y el endurecimiento de la aplicación.

La protección eficaz es, por tanto, por capas: scrubbing a nivel de proveedor contra el volumen, ajustes de edge y de kernel contra el estado, y controles a nivel de aplicación contra la capa 7, más una base de reglas de firewall que reduce tu superficie de ataque desde el principio. El resto de este artículo recorre cada familia en detalle y luego ensambla las capas en una defensa práctica.

Las tres familias de ataques DDoS

Los proveedores de seguridad clasifican los ataques DDoS de una docena de formas distintas, pero casi todo lo que te encontrarás en la práctica cae dentro de tres familias, diferenciadas por el recurso que agotan.

Ataques volumétricos: llenar la conexión

El objetivo es la fuerza bruta: enviar más tráfico del que tu enlace puede soportar. La forma más común es un simple UDP flood (datagramas sin sentido a line rate), que la telemetría de Cloudflare situó a la cabeza de la lista de vectores de capa de red a finales de 2025, con un crecimiento del 231% trimestre a trimestre.

La variante más interesante es el ataque de reflexión/amplificación. El atacante envía solicitudes pequeñas a servicios de internet abiertos (resolvers DNS, servidores NTP, instancias de memcached expuestas) con la dirección de origen falsificada para parecer la de tu servidor. Esos servicios entonces te "responden" a ti, y para la solicitud adecuada, la respuesta es muchísimo mayor que la pregunta. Los factores de amplificación clásicos del aviso de la CISA sobre amplificación basada en UDP muestran por qué a los atacantes les encanta esta técnica:

Con memcached, un megabit de tráfico upstream del atacante puede convertirse en decenas de gigabits que llegan a tu dirección. Los ataques de reflexión también explican por qué el tráfico que capturas durante un ataque a menudo parece proceder del puerto 53, 123, 389 o 11211; los reflectores son servidores legítimos que responden a lo que creen que son tus consultas. (Nuestra guía complementaria sobre cómo analizar un ataque DDoS con Wireshark muestra cómo identificar estas firmas en una captura.)

Un patrón volumétrico más reciente que conviene conocer es el carpet bombing: en lugar de concentrarse en una sola IP, el atacante reparte volúmenes moderados por toda una subred o por miles de puertos de destino, manteniéndose bajo los umbrales de detección por IP mientras satura igualmente la capacidad conjunta. NETSCOUT contabilizó entre 750 y 830 ataques de carpet bombing al día en la segunda mitad de 2025.

¿Cuán grandes pueden llegar a ser los ataques volumétricos? El récord público ha escalado a un ritmo sorprendente: de 3.8 Tbps a finales de 2024, pasando por un ataque de 7.3 Tbps en junio de 2025, hasta un ataque de 31.4 Tbps y 14.100 millones de paquetes por segundo en diciembre de 2025, impulsado por botnets IoT descendientes de Mirai (Aisuru y sus derivados) construidas a partir de routers, cámaras y cajas Android TV comprometidos. Son récords frente a las mayores redes de mitigación del planeta, no eventos habituales, pero incluso un flood multigigabit sin nada de especial supera el uplink de la mayoría de los servidores individuales, que es precisamente el sentido de la regla "upstream primero" de la siguiente sección.

Ataques de protocolo: agotar el estado de conexión

En lugar de ancho de banda puro, estos ataques apuntan a las tablas de estado que servidores, firewalls y balanceadores de carga mantienen para cada conexión.

El clásico es el SYN flood. El handshake de TCP hace que el servidor asigne estado en cuanto llega un SYN, mientras espera el ACK final que nunca llega. Con suficientes conexiones semiabiertas, la listen queue se llena: los clientes legítimos no pueden conectar aunque el ancho de banda y la CPU vayan perfectamente. Los SYN floods siguen siendo uno de los tres principales vectores de capa de red según los datos de Cloudflare, décadas después de que se describieran por primera vez; son baratos, eficaces y fáciles de generar con fuentes falsificadas.

La defensa estándar, las SYN cookies, codifica el estado de la conexión directamente en el número de secuencia del propio SYN-ACK, de modo que el servidor no asigna nada hasta que el handshake se completa. Linux las activa por defecto (net.ipv4.tcp_syncookies = 1) y deben permanecer activas en cualquier servidor expuesto a internet.

Otros miembros de esta familia son los ACK/RST floods (paquetes basura que fuerzan búsquedas en conntrack), los ataques de fragmentación (fragmentos incompletos que acaparan los buffers de reensamblado), y los connection floods, que completan el handshake y luego permanecen inactivos para ocupar slots. Ten en cuenta que un firewall con estado (incluidas las reglas basadas en conntrack de tu propio servidor) es en sí mismo una tabla de estado a la que un atacante puede apuntar, una de las razones por las que las reglas de firewall de los servidores muy expuestos evitan deliberadamente rastrear cierto tráfico. Nuestra guía de reglas de firewall por defecto explica dónde está ese equilibrio.

Ataques de capa de aplicación: solicitudes que parecen legítimas

Los ataques de capa 7 se saltan la fontanería y agotan la aplicación en sí: HTTP request floods contra endpoints costosos, cache-busting (query strings aleatorizadas que fuerzan que cada solicitud llegue hasta el origin), ataques al estilo slowloris que mantienen las conexiones abiertas enviando cabeceras un byte cada vez, y trucos a nivel de protocolo como HTTP/2 Rapid Reset (CVE-2023-44487), que abusó de la cancelación de streams para generar cientos de millones de solicitudes por segundo en 2023, antes de que las implementaciones añadieran controles de tasa sobre los resets.

Son los ataques más difíciles de filtrar porque cada solicitud, tomada individualmente, es válida; la malicia está en el volumen y en la distribución. Los HTTP floods modernos proceden mayoritariamente de botnets y navegadores headless que presentan huellas TLS y user agents creíbles. La mitigación, en consecuencia, tiene que ser consciente de la aplicación: caché agresiva para que las solicitudes nunca lleguen al origin, límites de tasa por cliente y por endpoint, un WAF o CDN que puntúe a los clientes según su comportamiento, y hacer que tus endpoints costosos (búsqueda, login, generación de informes) sean baratos o estén protegidos por una barrera.

¿Qué tan frecuente es todo esto?

Lo bastante frecuente como para tratarlo como una certeza operativa y no como un riesgo residual. Solo Cloudflare bloqueó 47.1 millones de ataques DDoS en 2025, un 121% más interanual, y NETSCOUT contabilizó más de 16 millones de ataques en todo el mundo a lo largo del año, más de la mitad de ellos multivector: combinaciones de las familias anteriores lanzadas de forma simultánea.

Dos estadísticas son las más importantes a la hora de planificar tu defensa:

• Los ataques son cortos. El 89% de los ataques de capa de red y el 71% de los ataques HTTP terminan en menos de diez minutos; incluso el récord de 31.4 Tbps duró 35 segundos. Una mitigación que depende de que una persona note el ataque, abra un ticket y active el scrubbing suele terminar de desplegarse cuando el ataque ya ha acabado. La mitigación automatizada always-on es hoy el estándar operativo, no el scrubbing on-demand.
• Los ataques son multivector. NETSCOUT encontró que aproximadamente el 42% de los ataques usaba de dos a cinco vectores. Defenderte de una sola familia e ignorar las demás solo le indica al atacante qué botón pulsar.

La pila de mitigación, capa por capa

Piensa en la defensa como cuatro capas, desde internet hacia dentro. Cada capa detiene lo que las capas de debajo no pueden.

Capa 1: mitigación upstream (la única respuesta al volumen)

La física ineludible: si el ataque es mayor que tu conexión, solo alguien upstream de esa conexión puede detenerlo. Un servidor en un puerto de 10 Gbit/s no puede salir a base de firewall de un flood de 50 Gbit/s; los paquetes ya han ganado para cuando llegan a la interfaz en la que corren tus reglas.

Las defensas upstream funcionan porque disponen de más capacidad y mejor perspectiva que cualquier servidor individual:

• Absorción anycast y scrubbing, el enfoque de las grandes redes de mitigación y los hostings protegidos contra DDoS: el tráfico de ataque se atrae hacia la más cercana de muchas ubicaciones, se reparte, se filtra, y solo se entrega el tráfico limpio. Así es como se absorbieron los récords multiterabit, de forma autónoma y sin intervención humana.
• RTBH (remotely triggered blackhole): una herramienta de operador de red que descarta todo el tráfico hacia un prefijo objetivo en el borde de la red. Protege al resto de la red, pero le hace el trabajo al atacante en lo que respecta al host en blackhole; la práctica actual lo trata como una primera respuesta contundente, refinada después con reglas BGP FlowSpec que igualan y descartan solo la firma del ataque (protocolo, puertos, tamaño de paquete) en lugar de todo.

Como cliente, no operas nada de esto tú mismo; eliges un proveedor de hosting o de mitigación que lo haga, y confirmas que la protección es always-on en lugar de reactiva. Dado que nueve de cada diez ataques terminan en menos de diez minutos, en esa distinción está la mayor parte del valor.

Capa 2: filtrado en el edge y limitación de tasa

Entre el scrubber upstream y tu aplicación hay defensas que cuestan poco y suavizan la parte media del modelo de amenazas:

• ACL de red / reglas de firewall en el edge: si tu servidor solo sirve HTTPS, el tráfico hacia UDP 11211 o TCP 23 no tiene nada que hacer ahí. Descartar el tráfico que no es de servicio antes de que toque el conntrack de tu servidor elimina clases enteras de ataques. Un firewall de network-edge self-service (que ofrecemos en nuestros servidores dedicados) hace este filtrado en la red, upstream de tu puerto.
• Limitación de tasa por origen: los límites en nuevas conexiones por segundo y por IP absorben la parte baja de los connection floods y el ruido de fuerza bruta. Rudimentario pero eficaz contra ataques poco sofisticados; ineficaz contra los muy distribuidos, y no pasa nada, para eso están las capas 1 y 4.

Capa 3: el propio host

Los ajustes en el host no te van a salvar de un flood volumétrico, pero sí determinan con qué elegancia sobrevives a todo lo que sea más pequeño:

• SYN cookies activadas (por defecto en Linux, verifica con sysctl net.ipv4.tcp_syncookies).
• Una base de firewall default-deny para que solo tus servicios reales acepten tráfico; nuestro artículo sobre reglas de firewall por defecto sensatas ofrece un conjunto de reglas completo y anotado, y si todavía estás decidiendo con qué herramienta escribirlas, consulta iptables vs nftables.
• Dimensionamiento de conntrack y timeouts: en servidores con mucha carga, sube net.netfilter.nf_conntrack_max y acorta agresivamente los timeouts para que el estado basura expire rápido, o excluye por completo del tracking tus puertos de servicio de alto volumen.
• Sin reflectores accidentales. La otra cara de la tabla de amplificación de arriba: asegúrate de que no sea tu servidor el que está amplificando. No ejecutes un resolver abierto, desactiva monlist de NTP (corregido desde ntpd 4.2.7, pero revisa cualquier cosa antigua), y no expongas nunca memcached por UDP a internet.

Capa 4: defensas de capa de aplicación

Para los HTTP floods y sus parientes: pon un CDN o un reverse proxy con caché delante de las aplicaciones dinámicas, limita la tasa de los endpoints costosos por separado de los baratos, mantén parcheadas las implementaciones de HTTP/2 (Rapid Reset y su sucesor de 2025, "MadeYouReset", quedan neutralizados por servidores actualizados), y diseña tu sistema para que las solicitudes anónimas sean cacheables por defecto. Si gestionas tu propio reverse proxy en un servidor dedicado, limit_req y limit_conn de nginx cubren una parte sorprendente del problema.

Detectar un ataque: las señales

La mayoría de los ataques se anuncian como una anomalía repentina en exactamente un recurso. Merece la pena vigilar (y alertar sobre):

• Ancho de banda: el tráfico entrante clavado a la velocidad de tu puerto es la firma volumétrica. Si tu proveedor grafica el tráfico antes y después de la mitigación, la diferencia es el ataque.
• Tasa de paquetes: millones de paquetes pequeños por segundo con un ancho de banda modesto apuntan a ataques de tasa de paquetes (SYN/ACK floods) más que a ataques de ancho de banda.
• Conexiones semiabiertas: si ss -s muestra contadores de synrecv del orden de los miles, hay un SYN flood en curso.
• Saturación de la aplicación con carga de sistema normal: worker pools llenos, tiempos de respuesta que se disparan, pero red y CPU sin nada destacable, la firma L7.
• Patrones de puerto de origen: floods entrantes desde el puerto 53/123/389/11211 significan que estás recibiendo tráfico reflejado.

Cuando necesites saber con precisión qué te está atacando (para escribir un filtro al estilo FlowSpec o darle a tu proveedor detalles accionables), captura una muestra y analízala; ese es el tema de nuestra guía de análisis de DDoS con Wireshark.

Un manual de respuesta a incidentes

Cuando ocurre, el orden de las operaciones importa más que el heroísmo:

1. Confirma que es un ataque, no una caída ni un lanzamiento. Comprueba si el tráfico es anómalo en su naturaleza (puertos raros, fuentes con pinta de falsificadas, una sola URL machacada) y no solo en volumen.
2. Identifica el vector: desde el dashboard de mitigación de tu proveedor o con una muestra de paquetes de 30 segundos. La familia determina la respuesta: volumétrico → upstream; estado → ajustar y limitar tasa; L7 → cachear y filtrar.
3. Activa la mitigación que ya tienes. Si la protección de tu proveedor es always-on, verifica que esté actuando (gráficas de tráfico scrubbeado); si algo es self-service (reglas de firewall en el edge, perfiles de mitigación), aplica la regla que coincida con el vector.
4. Reduce tu superficie en pleno ataque. Desactiva temporalmente los listeners no esenciales, activa un cacheo agresivo, pon los endpoints costosos detrás de un challenge si tienes un WAF.
5. Habla con tu proveedor con datos concretos. "SYN flood, ~4 Mpps, fuentes falsificadas, dirigido a 203.0.113.10:443" consigue una respuesta útil mucho más rápido que "nos están atacando".
6. Después, anota qué funcionó. Los ataques se repiten. El filtro que detuvo este debería quedar como un perfil guardado, no como un recuerdo.

Preguntas frecuentes

¿Puede un firewall en mi servidor detener un ataque DDoS?

Puede detener algunos tipos y otros no, y saber cuáles es todo el juego. Un firewall en el propio servidor frena eficazmente los SYN floods pequeños, los connection floods y el tráfico basura dirigido a puertos que no usas. No sirve de nada contra un ataque volumétrico que satura tu uplink: esos paquetes ya han cruzado el enlace que hay detrás de tu firewall, así que el filtrado tiene que ocurrir upstream, en el edge o en la capa de scrubbing de tu proveedor.

¿Cuál es la diferencia entre DoS y DDoS?

Un ataque DoS viene de una sola fuente; la D adicional significa "distributed" (distribuido): muchas fuentes a la vez, hoy en día normalmente una botnet IoT o una flota de proxies. Esa distribución es lo que hace que los ataques sean a la vez enormes (una botnet de un millón de cajas Android TV generó el récord actual de 31.4 Tbps) y difíciles de filtrar por dirección de origen, ya que no hay una única dirección que bloquear; la mitigación tiene que adaptarse a la forma del ataque.

¿Cuánto duran los ataques DDoS?

Menos de lo que la mayoría espera: aproximadamente nueve de cada diez ataques de capa de red terminan en menos de diez minutos, e incluso los ataques récord han durado menos de un minuto. Esa brevedad juega a favor del atacante (las ráfagas cortas esquivan la mitigación on-demand, que tarda minutos en activarse), y por eso la protección always-on ha desplazado como buena práctica al scrubbing de "llámanos cuando pase".

¿Necesito protección DDoS para un sitio pequeño?

Sí, en el sentido de que deberías elegir una infraestructura donde la protección venga incluida en lugar de comprarla más tarde como solución de emergencia. Los sitios pequeños reciben ataques por motivos poco glamurosos: un usuario descontento con una suscripción de $20 a un servicio de booter, un competidor, o simplemente ser un vecino de subred que sufre daños colaterales de un carpet bombing. Como lanzar un ataque sale barato y la protección ahora viene incluida sin coste extra en los buenos proveedores, la lógica económica favorece tenerla antes de necesitarla.

Desplegar en Serverside

Todos los servidores de nuestra red están protegidos por mitigación DDoS always-on; los ataques se detectan y se scrubbean automáticamente en el borde de la red, que (como este artículo espera haber dejado claro) es el único lugar donde se pueden detener los ataques volumétricos. Además, nuestros servidores dedicados incluyen un firewall self-service en el borde de la red, para que puedas descartar el tráfico que no es de servicio antes de que llegue siquiera a tu puerto, así como controles de mitigación self-service para ajustar la protección a tu carga de trabajo. El aprovisionamiento tarda menos de un minuto, en nuestra propia red ASN 55285.

Para la mitad de la defensa que ocurre en el propio host, empieza con nuestras reglas de firewall por defecto para un servidor Linux, elige tus herramientas con iptables vs nftables, y aprende a identificar exactamente qué te está atacando con cómo capturar y analizar un ataque DDoS en Wireshark. Si estás configurando una máquina nueva, nuestra guía de distribuciones Linux cubre la elección del sistema operativo base.