Blackhole Routing vs. Scrubbing en el Edge | Mitigación de DDoS

Cuando un ataque DDoS volumétrico alcanza su objetivo, el proveedor de conectividad frecuentemente ofrece una “solución”: blackhole routing. En marzo de 2013, el ataque contra Spamhaus generó picos reportados cercanos a los 300 Gbps, basado en reflexión y amplificación DNS. Aplicar blackhole routing a la IP atacada no detiene necesariamente el ataque: descarta, en la red del operador, tanto el tráfico malicioso como el legítimo destinado al objetivo. Aunque protege la infraestructura adyacente de la saturación, sacrifica temporalmente la disponibilidad del servicio y puede producir exactamente el efecto de denegación de servicio que el atacante buscaba.

El blackhole routing (o null routing) es una técnica de ingeniería de red que descarta todo el tráfico destinado a una dirección IP específica, redirigiéndolo a una interfaz nula. El tráfico de ataque se elimina — pero también todo el tráfico legítimo. El scrubbing, por su parte, es el proceso de inspección y filtrado selectivo del tráfico, descartando solo el malicioso y enviando el legítimo a su destino.

Cómo funciona el blackhole routing — RTBH y RFC 7999

El blackhole routing opera mediante BGP (RFC 4271). El mecanismo más utilizado es el RTBH (Remotely Triggered Black Hole), estandarizado por la RFC 5635, que permite activar el descarte en múltiples routers remotos a través de una sesión BGP de señalización.

Operacionalmente, el flujo se produce de la siguiente manera:

1. El operador detecta un ataque volumétrico dirigido a la IP 192.0.2.10/32.
2. Un router de señalización anuncia via iBGP la ruta 192.0.2.10/32 con el next-hop configurado como 192.0.2.1 (dirección reservada como trigger de blackhole).
3. Los routers perimetrales, al recibir este anuncio, consultan su tabla estática y redirigen el prefijo a la interfaz null0.
4. Todo el tráfico destinado a la IP de la víctima se descarta en los perímetros de la red del operador.

La RFC 7999 estandarizó la comunidad BGP bien conocida BLACKHOLE (65535:666) para señalizar rutas de blackhole de forma interoperable entre sistemas autónomos. Cuando una organización anuncia un prefijo con esta comunidad a su proveedor upstream, el prefixo se descarta en toda la red del proveedor. Los atributos NO_ADVERTISE y NO_EXPORT se combinan frecuentemente para limitar la propagación del anuncio:

• NO_ADVERTISE (comunidad 0xFFFFFF02): impide que el router receptor propague el anuncio a cualquier peer.
• NO_EXPORT (comunidad 0xFFFFFF01): impide la propagación a peers eBGP fuera de la confederación, conteniendo el blackhole dentro del AS receptor.

El resultado en términos de disponibilidad es inequívoco: el blackhole activa en segundos y protege la infraestructura upstream de la saturación. Pero desde la perspectiva del negocio, el efecto es idéntico al del ataque: indisponibilidad total.

Cuándo se usa el blackhole routing

A pesar de sus limitaciones, el blackhole tiene casos de uso válidos:

• Protección de infraestructura compartida: Cuando un ataque amenaza con impactar a otros clientes del ISP más allá de la víctima, el blackhole aísla el problema y protege la capacidad colectiva del enlace.
• IP sacrificada: Cuando la IP atacada es secundaria y el servicio principal puede mantenerse a través de otras IPs o prefijos.
• Medida de emergencia temporal: Como respuesta de primeros auxilios mientras se activa y propaga una solución de scrubbing.
• IP no crítica bajo ataque: Cuando la IP atacada no es necesaria para la continuidad operacional del servicio.

BGP FlowSpec — filtrado granular en el plano de control

El BGP FlowSpec, definido originalmente por la RFC 5575 y actualizado por la RFC 8955, representa una evolución significativa sobre el RTBH: en lugar de descartar todo el tráfico de un prefijo, permite crear reglas de ACL granulares distribuidas a través del plano de control BGP.

El FlowSpec opera mediante tuplas de correspondencia combinadas con acciones a través de comunidades extendidas:

Campos de correspondencia (match):

• Dirección IP de origen y destino (prefijo)
• Protocolo de transporte (TCP, UDP, ICMP)
• Puertos de origen y destino (rangos y listas)
• Flags TCP (SYN, ACK, RST, FIN)
• Tamaño de paquete (rango)
• Valor DSCP (marcado QoS)
• Fragmentación de paquetes

Acciones (vía comunidades extendidas):

• traffic-rate:AS:rate — descarta (rate=0) o limita la tasa de reenvío en bits/s
• traffic-action — marca o redirige para análisis (espejado)
• redirect:VRF — desvía el tráfico coincidente a una VRF de limpieza dedicada
• redirect-to-NH — redirige a un next-hop específico (scrubbing center)

Ejemplo de regla FlowSpec:

Una regla que descarta paquetes UDP con puerto de destino 53, tamaño entre 60 y 80 bytes e IP de destino 198.51.100.0/24 — patrón de amplificación DNS — se distribuiría a todos los routers perimetrales vía BGP sin intervención manual en cada equipo.

El FlowSpec se posiciona como una técnica intermedia entre el blackhole total y el scrubbing center:

• Más granular que el RTBH: permite descartar solo el tráfico malicioso mientras preserva el legítimo.
• Más simple que un scrubbing center: opera en el plano de control BGP sin requerir el desvío del tráfico a infraestructura dedicada.
• Tiene limitaciones: no inspecciona contenido de capa 7 y no escala bien para reglas muy dinámicas o de alta cardinalidad.

Cómo funciona el scrubbing centralizado

El scrubbing centralizado desvía el tráfico a un centro de limpieza dedicado donde se inspecciona en múltiples capas. El proceso ocurre en cuatro pasos:

1. Durante un ataque, el operador anuncia vía BGP que el prefijo afectado debe enrutarse al scrubbing center (normalmente mediante una comunidad BGP específica del proveedor de mitigación).
2. El tráfico de toda internet se redirige al scrubbing center, donde pasa por inspección de capas 3 y 4 (filtrado de IPs, puertos, protocolos) y capa 7 (análisis de comportamiento HTTP, rate limiting, detección de firmas).
3. El tráfico limpio se reenvía de vuelta al servidor de origen vía túnel GRE o MPLS.
4. Cuando el ataque cesa, el operador revierte el anuncio BGP y el tráfico retorna al camino normal.

Limitaciones del scrubbing centralizado — hairpin y ataques L7

El modelo de scrubbing center centralizado tiene dos problemas estructurales críticos.

Latencia de desvío (hairpin): El tráfico de un usuario en Ciudad de México a un servidor en México puede ser desviado a un scrubbing center en Miami, aumentando la latencia en 50–150ms.

Ataques de capa 7 y agotamiento criptográfico: Los scrubbing centers tradicionales operan principalmente en las capas 3 y 4. Los ataques de HTTP Flood, Slowloris y R.U.D.Y. utilizan solicitudes HTTP sintácticamente válidas a bajo volumen — invisibles para el filtrado L3/L4.

Más crítico aún: los ataques de agotamiento de handshake TLS/SSL como THC-SSL-DoS explotan la asimetría computacional del protocolo TLS, donde establecer una sesión TLS cuesta aproximadamente 15 veces más CPU en el servidor que en el cliente. Un atacante con hardware modesto puede iniciar renegociaciones en masa y saturar la capacidad criptográfica del servidor de origen antes de saturar la red. Un scrubbing center que no realiza terminación TLS pasa estas conexiones al servidor de origen sin inspeccionarlas, dejándolo vulnerable.

Scrubbing distribuido en el edge

El modelo más moderno elimina el hairpin y resuelve las limitaciones de L7 y TLS: en lugar de desviar el tráfico a un scrubbing center centralizado, el scrubbing ocurre en cada data center de la red de distribución, cerca de la fuente del ataque.

El flujo de protección con scrubbing distribuido funciona así:

1. El tráfico de ataque originado en Europa alcanza el data center edge europeo más cercano vía enrutamiento Anycast.
2. El data center europeo aplica inspección L3/L4 (volumétrica), L7 (comportamiento HTTP) e inspecciona las conexiones tras la terminación TLS.
3. Solo el tráfico que supera todas las capas de inspección se reenvía al servidor de origen.
4. El mismo proceso ocurre simultáneamente en data centers de EE. UU., APAC y otras regiones para el tráfico generado en esas ubicaciones.
5. El servidor de origen recibe exclusivamente solicitudes completas, válidas e inspeccionadas — independientemente de la escala del ataque.

Los beneficios son estructurales:

• Tráfico de ataque filtrado cerca de la fuente, reduciendo la carga transportada en la red.
• Los usuarios legítimos no sufren desvío de ruta y mantienen su latencia original.
• La terminación TLS en el edge permite la inspección de capa 7 sobre el tráfico descifrado, sin exponer al servidor de origen a la carga de procesamiento criptográfico.

Edge TLS Termination y protección contra el agotamiento criptográfico

La terminación TLS en el edge resuelve específicamente el vector de agotamiento criptográfico. El proceso funciona de la siguiente manera:

1. Las conexiones TLS de los clientes se terminan en los data centers edge, que operan con hardware de aceleración criptográfica dedicada (AES-NI, Intel QAT).
2. Tras completarse el handshake TLS en el edge, la solicitud HTTP se descifra y se somete a inspección de WAF y análisis de comportamiento en tiempo real.
3. Solo las solicitudes aprobadas se reenvían al servidor de origen — en una conexión separada que puede ser HTTP plano o TLS con handshake ya establecido.
4. El servidor de origen nunca procesa handshakes TLS de clientes externos, eliminando completamente el vector de agotamiento criptográfico.

Matriz comparativa de las cuatro arquitecturas

El problema del collateral damage del blackhole

Un aspecto frecuentemente ignorado: cuando el ISP aplica blackhole, la IP de la víctima puede anunciarse como “agujero negro” en múltiples routers BGP. Esto puede causar:

• Daño a la reputación: Los sistemas de reputación de IP registran la IP como problemática, afectando la entrega de correo electrónico y la confianza en CDNs.
• Impacto en servicios relacionados: Otros servicios en el mismo bloque /24 pueden verse afectados por filtros basados en subred.
• Retirada lenta: Retirar el blackhole puede tardar horas en propagarse vía BGP según la topología de red y los timers de cada peer.

Señales de que se ha aplicado blackhole a tu IP

Errores comunes y soluciones

Error: Aceptar el blackhole como “solución de mitigación” del ISP sin cuestionar alternativas. Solución: Exige SLAs de scrubbing con preservación del tráfico legítimo. El blackhole protege la infraestructura del ISP — no es una solución para el negocio de la víctima.

Error: Implementar scrubbing centralizado sin considerar el impacto de latencia. Solución: Evalúa la distribución geográfica de tus usuarios. Si están distribuidos globalmente, un único scrubbing center introduce un hairpin inaceptable. Prefiere scrubbing distribuido o FlowSpec para ataques L3/L4 simples.

Error: Activar automáticamente el blackhole como primera respuesta a cualquier ataque. Solución: Reserva el blackhole para situaciones donde la infraestructura upstream esté en riesgo inmediato de saturación. Usa scrubbing o FlowSpec como respuesta estándar para preservar la disponibilidad.

Error: Asumir que el scrubbing centralizado resuelve los ataques de capa 7 y el agotamiento TLS. Solución: El scrubbing L3/L4 es efectivo contra ataques volumétricos. Los ataques L7 como HTTP Flood, Slowloris y el agotamiento de handshake TLS requieren terminación TLS en el edge e inspección integrada de capa 7.

Preguntas frecuentes

¿Qué es la comunidad BGP BLACKHOLE (65535:666) y cómo se usa? La comunidad 65535:666, estandarizada por la RFC 7999, es una comunidad BGP bien conocida que indica al receptor que el prefijo anunciado debe descartarse (blackholed). Para usarla, la organización anuncia el prefijo atacado con esta comunidad a su(s) proveedor(es) upstream. Los routers de los proveedores que reconocen la comunidad descartan el tráfico antes de reenviarlo a la red de la víctima. Es más interoperable que las soluciones propietarias, ya que es reconocida por equipos de múltiples fabricantes e ISPs.

¿Cuál es la diferencia entre RTBH (RFC 5635) y BGP FlowSpec (RFC 8955)? El RTBH descarta todo el tráfico para un prefijo IP /32 (host-route) sin distinción de protocolo, puerto o comportamiento — es binario: todo o nada. El FlowSpec permite crear reglas granulares con múltiples campos de correspondencia (IP, puerto, protocolo, tamaño de paquete, flags TCP, DSCP) y diferentes acciones (descarte, limitación de tasa, redirección a VRF). El FlowSpec se distribuye vía BGP como el RTBH, pero actúa como una ACL remota, permitiendo proteger el tráfico legítimo mientras descarta solo los patrones maliciosos.

¿El blackhole routing puede ser parcial, solo para ciertos tipos de tráfico? El blackhole BGP tradicional vía RTBH descarta todo el tráfico para la IP. La variación D/RTBH permite filtrar por prefijo de origen del atacante, pero requiere inteligencia sobre las IPs de ataque. Para filtrado por protocolo, puerto o comportamiento, se necesita BGP FlowSpec — que ofrece esa granularidad manteniendo la distribución vía plano de control BGP.

¿El scrubbing centralizado sigue teniendo sentido en 2026? Sí, en escenarios específicos: cuando el scrubbing center está geográficamente cerca de los usuarios, cuando el ataque es exclusivamente volumétrico L3/L4 y cuando la organización no tiene acceso a una red edge distribuida. Para ataques modernos multi-vector que combinan flood volumétrico con HTTP Flood, agotamiento TLS y Slowloris, el modelo distribuido en el edge es superior porque opera en todas las capas simultáneamente.

¿Por qué los ataques Slowloris y R.U.D.Y. pasan por los scrubbing centers tradicionales sin ser bloqueados? Los ataques low and slow como Slowloris y R.U.D.Y. utilizan conexiones HTTP sintácticamente válidas transmitidas a ritmo extremadamente lento. Desde la perspectiva del volumen de red (paquetes por segundo, bits por segundo), son invisibles para los filtros L3/L4. La detección requiere inspección de capa 7 con análisis de comportamiento: conexiones abiertas por IP, tasa de completitud de solicitudes, tiempo de transmisión de headers y fingerprinting de cliente (JA3/JA4). Esto solo es posible tras la terminación TLS y con capacidad de análisis L7 en el punto de inspección.

¿Puede saturarse un scrubbing center? Sí. Los ataques que superen la capacidad de scrubbing del proveedor pueden saturar los propios enlaces de entrada del scrubbing center. Los proveedores con scrubbing distribuido tienen mayor capacidad total agregada porque distribuyen la carga entre decenas de data centers. Un ataque de 1 Tbps que saturaría un único scrubbing center de 500 Gbps se diluye entre 20 data centers de 100 Gbps cada uno sin saturar ninguno de ellos individualmente.

Cómo implementar en Azion

Azion opera un modelo de scrubbing distribuido always-on que aborda todos los vectores discutidos en este artículo:

1. Scrubbing en el edge con red Anycast global: El tráfico se inspecciona en cada uno de los 100+ data centers de Azion, cerca de la fuente del ataque. El enrutamiento Anycast garantiza que los usuarios legítimos no sufran desvío de ruta ni aumento de latencia — la inspección ocurre en el mismo camino que el tráfico tomaría normalmente.
2. DDoS Protection always-on: Sin activación manual, redirección BGP ni ajuste de anuncios de rutas durante el ataque. La protección está siempre activa, con mitigación automática que comienza en segundos para ataques volumétricos L3/L4.
3. Edge TLS Termination con inspección L7: Las conexiones TLS se terminan en los data centers de Azion, que utilizan hardware con aceleración criptográfica. El servidor de origen nunca procesa handshakes TLS de clientes externos, eliminando el vector de agotamiento criptográfico (THC-SSL-DoS y similares). Sobre el tráfico descifrado, el WAF integrado aplica inspección de capa 7 en tiempo real, detectando HTTP Flood, Slowloris, R.U.D.Y. y otros ataques low and slow.
4. Sin blackhole forzado: Azion no aplica blackhole routing a las IPs de los clientes como respuesta predeterminada. El objetivo es mantener el servicio disponible durante el ataque, no solo proteger la infraestructura de red. La política es filtrar el tráfico malicioso y reenviar el legítimo a su destino — independientemente de la escala del ataque.

Aprende más en la documentación de DDoS Protection de Azion.