Ataques de capa 3, capa 4 y capa 7
Los ataques de capa 3 atacan la capa de red (IP, ICMP); ejemplos: ICMP flood y ataques de fragmentación IP. Los ataques de capa 4 atacan la capa de transporte (TCP, UDP); ejemplos: SYN flood y amplificación UDP/DNS. Los ataques de capa 7 atacan la capa de aplicación (HTTP, HTTPS); ejemplos: HTTP GET/POST flood y Slowloris. Cada capa requiere mitigación distinta.
Los ataques volumétricos de capas 3 y 4 buscan saturar el propio enlace de red. Los mayores ataques divulgados públicamente han superado los varios terabits por segundo: Cloudflare informó de la mitigación de un ataque de 7,3 Tbps en mayo de 2025 y AWS Shield reportó uno de 2,3 Tbps en febrero de 2020. Estos ataques funcionan porque protocolos de amplificación (DNS, NTP, memcached, CLDAP) permiten que una pequeña consulta falsificada provoque una respuesta mucho mayor enviada a la víctima: se han documentado factores de amplificación de 50x para DNS, 200x para NTP y 50.000x para memcached. Los ataques de protocolo en capa 4 —SYN flood, ACK flood, fragmentación de paquetes— agotan el estado de seguimiento de conexiones en cortafuegos y balanceadores en lugar de saturar ancho de banda. Los ataques de capa 7 son los más pequeños en bytes pero los más difíciles de filtrar: una inundación HTTP desde una botnet de 100.000 nodos parece bit a bit como tráfico real, y solo la lógica con conocimiento de la aplicación puede distinguirlos.
Blackhole BGP y RTBH (remote-triggered black hole)
El blackholing BGP es la mitigación brutal pero efectiva de último recurso: el operador de red anuncia una ruta /32 para la IP atacada en una community BGP especial de "blackhole", indicando a todos los peers upstream que descarten todo el tráfico hacia esa IP. El objetivo queda offline, pero el resto de la red se mantiene en pie. RTBH está estandarizado en RFC 5635 y lo soportan todos los operadores Tier 1.
RTBH se documenta en RFC 5635 (agosto de 2009) y funciona etiquetando una ruta con un atributo de community que los peers upstream interpretan como "descarte todo el tráfico destinado a este prefijo". La mitigación es total —la IP protegida queda inalcanzable desde toda Internet, incluso para usuarios legítimos— pero protege al resto de la flota del cliente del daño colateral. Por su brusquedad, RTBH es apropiado cuando una sola IP está siendo saturada por un ataque de varios cientos de gigabits y el coste de una caída más amplia supera al de mantener esa IP online. Muchos planes VPS de "protección DDoS" de bajo nivel se reducen exactamente a esto: el proveedor null-routea su IP bajo ataque para mantener a salvo el resto de su flota. Eso es, por definición, mitigación de denegación de servicio, pero el recurso protegido es la red del proveedor, no la suya.
Centros de scrubbing y desvío de tráfico
Un centro de scrubbing es un emplazamiento de red endurecido donde se filtra el tráfico de ataque y se reenvía el tráfico limpio al origen. El tráfico se desvía allí mediante anuncio BGP (siempre activo o bajo demanda) o apuntando DNS. La capacidad de scrubbing por Tbps es la métrica titular: los proveedores más grandes operan más de 200 Tbps agregados, mientras que los proveedores especializados de hosting suelen anunciar entre 1 y 10 Tbps.
Los centros de scrubbing ejecutan equipos especializados —Arbor TMS, Radware DefensePro, A10 Thunder, NSFOCUS ADS o pipelines Linux/DPDK a gran escala— que inspeccionan cada paquete, clasifican patrones benignos y maliciosos y reenvían solo la fracción limpia al origen. El desvío suele hacerse mediante BGP: el prefijo del cliente se anuncia desde la red anycast del proveedor de scrubbing durante un ataque, atrayendo todo el tráfico al sitio de scrubbing más cercano. Tras la limpieza, el tráfico se tunela (GRE, IPSec, cross-connect dedicado o peering directo) de vuelta al servidor de origen. La latencia añadida por el scrubbing suele ser de 1-3 ms en la región, más cualquier salto adicional del desvío. El scrubbing siempre activo mantiene el desvío permanente, eliminando el tiempo de activación de la mitigación a costa de un coste de latencia constante. El scrubbing bajo demanda solo desvía durante ataques detectados, lo que es más barato pero introduce una ventana de activación de 30-180 segundos durante la cual el ataque impacta.
Mitigación siempre activa frente a bajo demanda
La mitigación siempre activa enruta todo el tráfico por la capa de scrubbing 24/7: cero retardo de activación, pero cada paquete paga un pequeño coste de latencia (1-5 ms típicos). La mitigación bajo demanda se activa solo al detectar un ataque, eliminando la latencia en estado estable pero exponiendo el origen durante la ventana de activación (típicamente 30-180 segundos). Las configuraciones híbridas combinan ambas: siempre activa para HTTP/HTTPS, bajo demanda para tráfico IP en bruto.
Elegir entre siempre activa y bajo demanda es un compromiso entre latencia en estado estable y vulnerabilidad durante la ventana de ataque. Los servicios sensibles a la latencia —servidores de juego multijugador, trading de baja latencia, voz/vídeo— suelen elegir bajo demanda y aceptan la ventana de activación porque cada milisegundo de RTT en estado estable les cuesta. Los servicios web de cara al público, las APIs y las apps SaaS suelen optar por siempre activa o por una topología totalmente proxiada estilo CDN donde la IP del origen ni siquiera es pública, eliminando la ventana de ataque por completo. Los proveedores cloud-edge modernos (Cloudflare, Fastly, AWS Shield Advanced, Google Cloud Armor) tienden a siempre activa por defecto porque su red ya termina el tráfico en cientos de ubicaciones de borde y el "desvío" es esencialmente cero.
Limitación de tasa, WAF y defensa en capa de aplicación
La limitación de tasa pone tope al número de peticiones por IP de origen, sesión o URL, atenuando inundaciones de capa 7 sin afectar al tráfico legítimo. Un Web Application Firewall (WAF) inspecciona peticiones HTTP frente a reglas: protecciones OWASP Top 10, reglas de tasa personalizadas, geo-bloqueo, retos JS y CAPTCHA. Juntos manejan los ataques de capa 7 que el scrubbing volumétrico por sí solo no puede.
El scrubbing volumétrico se detiene en la frontera IP-puerto. Para detener un HTTP flood que parece tráfico real de Chrome se necesitan reglas que operen sobre URLs, cabeceras, cookies y comportamiento. La limitación de tasa es el control de capa 7 más simple y efectivo: tope a una sola IP, por ejemplo, en 60 peticiones por minuto en /login y descarte el resto. Un WAF va más allá con reglas conscientes del contenido: bloquea peticiones con patrones de inyección SQL, user agents anómalos, referrers ausentes, orígenes geográficos fuera de su área de servicio o tamaños de carga muy fuera del rango legítimo. Los WAFs modernos (AWS WAF, Cloudflare WAF, Fastly Next-Gen WAF, ModSecurity con OWASP Core Rule Set) también ejecutan retos de JavaScript, hCaptcha y heurísticas de huella digital de bots que reducen la tasa de impactos de una botnet en más del 99 % sin molestar a los navegadores reales.
Lo que los proveedores de hosting suelen incluir frente a lo que cobran aparte
Los niveles incluidos o gratuitos suelen cubrir ataques volumétricos de capas 3-4 hasta un tope en gigabits por segundo (a menudo 10-100 Gbps) usando limitación de tasa básica y blackhole BGP. Los add-ons de pago suelen incluir scrubbing siempre activo, WAF, mitigación de capa 7, autoría de reglas personalizadas y garantías de mitigación con SLA. Lea el contrato: "protección DDoS ilimitada" suele significar "le null-rutearemos por encima de X Gbps".
El marketing DDoS de los proveedores de hosting varía enormemente. Una protección genuinamente útil incluye tres cosas: (1) una capacidad declarada clara en Gbps o Tbps, (2) cobertura de capa 3 a capa 7, incluida la mitigación de HTTP flood, y (3) un SLA escrito con compromiso de tiempo de inicio de mitigación y de pérdida de tráfico. Una protección menos útil es una insignia única de "protección DDoS" sin número de capacidad, que normalmente significa solo blackhole BGP: su IP se null-routea bajo ataque y queda offline durante la duración. Al evaluar, pregunte: ¿cuál es la capacidad declarada por IP? ¿Es siempre activa o bajo demanda? ¿Cubre la capa 7? ¿Cuál es el SLA de tiempo de activación de la mitigación? ¿Qué ocurre si el ataque supera el tope de su nivel? Las respuestas revelan si está comprando protección real o una etiqueta de marketing.