Blackhole routing vs scrubbing | Comparación de mitigación de DDoS

Cuando un ataque DDoS volumétrico impacta a su objetivo, el proveedor de conectividad suele ofrecer una “solución”: el blackhole routing. En marzo de 2013, el ataque contra Spamhaus generó picos reportados cercanos a los 300 Gbps, basados en reflexión y amplificación de DNS. Aplicar blackhole routing a la IP atacada no necesariamente detiene el ataque: descarta, en el edge de la red del operador, tanto el tráfico malicioso como el tráfico legítimo destinado al objetivo. Si bien 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 redes que descarta todo el tráfico destinado a una IP específica al redirigirlo a una interfaz nula. El tráfico de ataque se elimina, pero también todo el tráfico legítimo. El scrubbing, en cambio, es el proceso de inspeccionar y filtrar el tráfico de forma selectiva, descartando solo los paquetes maliciosos y reenviando los legítimos a su destino, manteniendo la disponibilidad incluso durante el ataque.

TL;DR: El blackhole routing descarta todo el tráfico hacia una IP atacada, deteniendo el ataque pero también bloqueando a los usuarios legítimos. El scrubbing de tráfico filtra el tráfico de ataque y reenvía solo el tráfico limpio al origen. El blackhole routing es una medida de último recurso cuando el volumen del ataque supera la capacidad de scrubbing; el scrubbing es el enfoque preferido cuando se requiere mantener la disponibilidad del servicio.

Última actualización: 2026-07-27

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

El blackhole routing, también llamado null routing o RTBH (Remotely Triggered Black Hole), indica a los routers que descarten todos los paquetes destinados a una IP o prefijo específico. La ruta se anuncia vía BGP (RFC 4271) con un next-hop que lleva a una interfaz de descarte, comúnmente etiquetada como “Null0” en dispositivos Cisco o “blackhole” en BIRD/FRR.

Normal routing:
Attacker ──▶ Internet ──▶ Router ──▶ Target server (IP: 203.0.113.1)

Blackhole routing activated:
Attacker ──▶ Internet ──▶ Router ──▶ Null0 (packets discarded)
Legitimate users ──▶ Internet ──▶ Router ──▶ Null0 (also discarded)

El mecanismo más utilizado es RTBH (Remotely Triggered Black Hole), estandarizado por RFC 5635, que permite activar el descarte en múltiples routers remotos a través de una sesión de señalización BGP. En términos operativos, el flujo es el siguiente:

1. El operador detecta un ataque volumétrico dirigido a la IP 192.0.2.10/32.
2. Un router disparador anuncia vía iBGP la ruta 192.0.2.10/32 con el next-hop configurado en 192.0.2.1 (una dirección reservada como disparador de blackhole).
3. Los routers edge, 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 edges de la red del operador — el tráfico de ataque nunca llega al origen, pero el tráfico legítimo tampoco.

RTBH basado en destino (D-RTBH) descarta según la IP de destino. RTBH basado en origen (S-RTBH) descarta según la IP de origen y requiere soporte de uRPF (Unicast Reverse Path Forwarding) en el router; es útil para bloquear fuentes de ataque conocidas, pero poco práctico cuando las fuentes están falsificadas (spoofed) o distribuidas entre millones de IP.

RFC 7999 estandarizó la comunidad BGP well-known BLACKHOLE (65535:666) para señalar 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 prefijo se descarta en toda la red del proveedor. Los atributos NO_ADVERTISE y NO_EXPORT se combinan con frecuencia 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 se activa en segundos y protege la infraestructura upstream (enlaces y routers del ISP) de la saturación. Pero desde una perspectiva de negocio, el efecto es idéntico al del ataque: indisponibilidad total.

Cuándo se usa el blackhole routing

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

• El volumen del ataque supera la capacidad de scrubbing. Si un ataque genera 2 Tbps y el scrubbing center maneja 1 Tbps, el scrubbing no protegerá la red. El blackholing evita que el ataque sature los enlaces upstream.
• La IP atacada no es crítica. Un endpoint de monitoreo, un resolver DNS secundario o un servidor de pruebas se pueden llevar a blackhole sin impacto en el negocio — el mismo razonamiento aplica cuando la IP atacada es secundaria y el servicio principal puede mantenerse mediante otras IP o prefijos.
• Proteger la infraestructura compartida es la prioridad. Los ISP aplican blackhole a la IP de un cliente para evitar congestión en la infraestructura compartida que afecte a todos los clientes; cuando un ataque amenaza con afectar a otros clientes más allá de la víctima, el blackhole aísla el problema y protege la capacidad de enlace compartida.
• La velocidad es crítica. La convergencia de blackhole por BGP ocurre en menos de 30 segundos. La redirección de scrubbing generalmente toma de 1 a 5 minutos, tiempo durante el cual el tráfico de ataque sigue fluyendo.
• Las IP de ataque son conocidas y estáticas. El RTBH basado en origen bloquea fuentes de ataque específicas sin descartar el tráfico legítimo; solo es práctico cuando las fuentes de ataque son pocas y no están falsificadas.
• Medida temporal de emergencia: como respuesta de primeros auxilios mientras se activa y propaga una solución de scrubbing.

Cómo funciona el scrubbing de tráfico

El scrubbing de tráfico redirige todo el tráfico destinado a la IP atacada a través de un scrubbing center (también llamado centro de limpieza). El centro inspecciona los paquetes, descarta el tráfico de ataque y reenvía el tráfico limpio al servidor de origen.

Normal routing:
Internet ──▶ Router ──▶ Target server

Under attack with scrubbing active:
Internet ──▶ Scrubbing Center ──(clean traffic only)──▶ Target server
                    │
                    └──▶ Malicious packets discarded

Técnicas de los scrubbing centers:

• Inyección de rutas BGP o direccionamiento de tráfico basado en DNS para redirigir el tráfico
• Inspección profunda de paquetes (DPI) para identificar firmas de ataque
• Limitación de tasa por IP de origen
• Validación de protocolo (SYN cookies para TCP, limitación de tasa de respuestas DNS)
• Análisis de comportamiento para distinguir bots de usuarios legítimos
• Tunelización GRE o MPLS para entregar el tráfico limpio de vuelta al origen

Los principales proveedores de mitigación operan capacidad de scrubbing en múltiples regiones geográficas. La capacidad de scrubbing distribuida importa porque los ataques DDoS volumétricos pueden superar la capacidad de un solo data center, enlace de ISP o appliance.

Comparación lado a lado

Antes de avanzar hacia las arquitecturas técnicas más avanzadas (FlowSpec, scrubbing centralizado y distribuido), aquí una comparación directa entre los dos enfoques fundamentales:

Cuándo usar el scrubbing de tráfico

El scrubbing de tráfico es apropiado cuando:

• Se requiere disponibilidad del servicio durante el ataque. El e-commerce, los servicios financieros y el SaaS no pueden tolerar interrupciones totales; el scrubbing filtra el tráfico de ataque mientras los usuarios legítimos siguen accediendo al servicio.
• El volumen del ataque está dentro de la capacidad de scrubbing. La mayoría de los ataques DDoS comerciales alcanzan un pico por debajo de 500 Gbps. Los scrubbing centers con capacidad de 1–10 Tbps manejan esto sin problema.
• Los ataques son multivector. Los ataques de capa 7 combinados con inundaciones volumétricas requieren inspección, no descarte ciego. Los scrubbing centers aplican filtros distintos por vector de ataque.
• Los ataques de larga duración requieren una respuesta sostenida. El scrubbing puede operar de forma continua durante horas o días. El blackholing suele ser una medida temporal: la IP objetivo permanece inalcanzable hasta que se desactiva manualmente.

Enfoque híbrido

Muchas organizaciones y proveedores combinan ambas técnicas en una respuesta escalonada:

1. Scrubbing primero: redirigir el tráfico a través del scrubbing para ataques por debajo del umbral de capacidad.
2. Blackhole como último recurso: si el volumen del ataque satura el scrubbing o los enlaces upstream, se aplica blackhole a la IP atacada para proteger el resto de la infraestructura.
3. Blackholing quirúrgico: usar S-RTBH para llevar a blackhole los prefijos de origen del ataque identificados, mientras se continúa haciendo scrubbing del resto del tráfico.

Este enfoque protege la disponibilidad del servicio en ataques moderados, a la vez que mantiene un mecanismo para proteger la red más amplia durante eventos extremos.

BGP FlowSpec — filtrado granular en el plano de control

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

FlowSpec opera mediante tuplas de coincidencia combinadas con acciones vía extended communities:

Campos de coincidencia:

• 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 de QoS)
• Fragmentación de paquetes

Acciones (vía extended communities):

• 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 (mirroring)
• redirect:VRF — desvía el tráfico coincidente a una VRF de scrubbing 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, y IP de destino 198.51.100.0/24 — un patrón de amplificación DNS — se distribuiría a todos los routers edge vía BGP sin intervención manual en cada dispositivo.

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

• Más granular que RTBH: permite descartar solo el tráfico malicioso mientras se preserva el tráfico legítimo.
• Más simple que un scrubbing center: opera en el plano de control de BGP sin necesidad de desviar el tráfico a infraestructura dedicada.
• Tiene limitaciones: no inspecciona el contenido de la capa 7 y no escala bien para reglas altamente 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 hacia el scrubbing center (típicamente mediante una comunidad BGP específica del proveedor).
2. El tráfico de todo internet se redirige al scrubbing center, donde pasa por inspección de capas 3 y 4 (filtrado de IP, puerto, protocolo) e inspección de capa 7 (análisis de comportamiento HTTP, limitación de tasa, 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 cede, el operador revierte el anuncio de BGP y el tráfico regresa a su ruta normal.

Limitaciones del scrubbing centralizado — hairpin y ataques L7

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

Latencia por hairpin: el tráfico de un usuario en São Paulo hacia un servidor en São Paulo puede desviarse a un scrubbing center en Miami o Ámsterdam, aumentando la latencia entre 50 y 150 ms.

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. usan solicitudes HTTP sintácticamente válidas a bajo volumen, invisibles para el filtrado L3/L4.

Aún más crítico: los ataques de agotamiento del 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 masivas y saturar la capacidad criptográfica del servidor de origen antes de saturar la red. Un scrubbing center que no realiza terminación de 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 de la siguiente manera:

1. El tráfico de ataque originado en Europa llega al data center edge europeo más cercano mediante enrutamiento Anycast.
2. El data center europeo aplica inspección L3/L4 (volumétrica), inspección L7 (comportamiento HTTP) e inspecciona las conexiones después de la terminación de TLS.
3. Solo el tráfico que pasa todas las capas de inspección se reenvía al servidor de origen.
4. El mismo proceso ocurre simultáneamente en los data centers regionales 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, sin importar la escala del ataque.

Los beneficios son estructurales:

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

Terminación de TLS en el edge y protección contra el agotamiento criptográfico

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

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

Matriz comparativa de las cuatro arquitecturas

El problema del daño colateral del blackhole

Un aspecto que se pasa por alto con frecuencia: cuando un ISP aplica blackhole routing, la IP de la víctima puede anunciarse como un “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 de CDN.
• Impacto en servicios relacionados: otros servicios en el mismo bloque /24 pueden verse afectados por filtros basados en subred.
• Remoción lenta: retirar el blackhole puede tardar horas en propagarse vía BGP, dependiendo de la topología de red y los temporizadores de los peers.

Señales de que se aplicó 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: exigir SLA 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 en la latencia. Solución: evaluar la distribución geográfica de tus usuarios. Si están distribuidos globalmente, un solo scrubbing center introduce un hairpin inaceptable. Preferir el scrubbing distribuido o FlowSpec para ataques L3/L4 simples.

Error: activar automáticamente el blackhole como primera respuesta ante cualquier ataque. Solución: reservar el blackhole para situaciones en las que la infraestructura upstream esté en riesgo inmediato de saturación. Usar scrubbing o FlowSpec como respuesta predeterminada para preservar la disponibilidad.

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

Preguntas frecuentes

¿Qué es el blackhole routing en la mitigación de DDoS? El blackhole routing es una técnica que descarta todos los paquetes destinados a una IP específica al anunciar esa IP vía BGP con un next-hop nulo. Detiene el ataque de inmediato, pero deja la IP objetivo completamente inalcanzable, incluso para usuarios legítimos.

¿Qué es el scrubbing de tráfico? El scrubbing de tráfico redirige todo el tráfico a través de una infraestructura de filtrado especializada (scrubbing center) que separa los paquetes maliciosos de las solicitudes legítimas. El tráfico limpio se reenvía al origen; el tráfico de ataque se descarta. El servicio continúa durante el ataque.

¿El blackhole routing detiene un ataque DDoS? El blackhole routing evita que el tráfico de ataque llegue al origen, pero también detiene todo el demás tráfico. El ataque en sí puede seguir generando tráfico en la red; el blackhole evita que consuma recursos del origen y capacidad de los enlaces upstream.

¿Qué es RTBH? RTBH (Remotely Triggered Black Hole) es un mecanismo basado en BGP para propagar rutas de blackhole a múltiples routers o proveedores upstream de forma simultánea. Un operador inyecta una ruta host /32 o /128 etiquetada con una comunidad BGP específica, y los routers peer configuran automáticamente el next-hop en descarte.

¿Cuál es la diferencia entre D-RTBH y S-RTBH? D-RTBH (RTBH basado en destino) lleva a blackhole todo el tráfico hacia una IP de destino específica, descartando tanto el tráfico de ataque como el legítimo. S-RTBH (RTBH basado en origen) lleva a blackhole el tráfico proveniente de IP de origen específicas, preservando el servicio para usuarios legítimos mientras bloquea las fuentes de ataque identificadas. S-RTBH es más preciso, pero requiere soporte de uRPF y fuentes de ataque conocidas y no falsificadas.

¿Cuánto tráfico puede manejar un scrubbing center? La capacidad del scrubbing center varía según el proveedor y la arquitectura. Las ubicaciones individuales de scrubbing pueden ir de cientos de Gbps hasta capacidades multi-Tbps, mientras que las arquitecturas anycast distribuidas reparten el tráfico de ataque entre muchas ubicaciones en lugar de forzar a un solo sitio a absorber toda la carga.

¿El scrubbing de tráfico siempre es mejor que el blackholing? No siempre. Si un ataque supera la capacidad de scrubbing, el scrubbing falla y todo el tráfico, incluido el de ataque, se acumula en la red. El blackholing garantiza que el tráfico de ataque no llegue ni sature los enlaces críticos. La elección correcta depende del volumen del ataque y de los requisitos del servicio.

¿Qué es anycast y cómo se relaciona con el scrubbing? Anycast anuncia el mismo prefijo IP desde múltiples ubicaciones geográficas de forma simultánea. El tráfico se enruta hacia la ubicación más cercana. Durante un ataque DDoS, anycast distribuye el tráfico de ataque entre múltiples puntos de scrubbing, evitando que una sola ubicación se sature. Azion usa este modelo distribuido para mantener la mitigación cerca de las fuentes de ataque.

¿Puedo implementar blackhole routing sin la ayuda de mi ISP? Puedes implementar null routing localmente en tus propios routers para descartar el tráfico que llega a tu borde. Sin embargo, el tráfico de ataque sigue fluyendo por tus enlaces upstream hasta llegar a tu router. Para obtener protección upstream, necesitas que tu ISP o proveedor upstream participe en RTBH aceptando tus comunidades BGP de blackhole.

¿Cuánto tiempo permanece activo el blackhole routing? Las rutas de blackhole suelen configurarse con un TTL (time-to-live) o temporizador corto de BGP, comúnmente entre 30 minutos y unas pocas horas, para evitar interrupciones indefinidas del servicio. Los operadores desactivan manualmente el blackhole una vez que el ataque cede.

¿Qué es la comunidad BGP BLACKHOLE (65535:666) y cómo se usa? La comunidad 65535:666, estandarizada por RFC 7999, es una comunidad BGP well-known que indica al receptor que el prefijo anunciado debe llevarse a blackhole. Para usarla, la organización anuncia el prefijo atacado con esta comunidad a su(s) proveedor(es) upstream. Los routers del proveedor 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 la reconocen equipos de múltiples fabricantes e ISP.

¿Cuál es la diferencia entre RTBH (RFC 5635) y BGP FlowSpec (RFC 8955)? RTBH descarta todo el tráfico de un prefijo IP /32 (host-route) sin distinguir protocolo, puerto o comportamiento: es binario, todo o nada. FlowSpec permite crear reglas granulares con múltiples campos de coincidencia (IP, puerto, protocolo, tamaño de paquete, flags TCP, DSCP) y distintas acciones (descarte, limitación de tasa, redirección a VRF). FlowSpec se distribuye vía BGP igual que RTBH, pero actúa como una ACL remota, permitiendo proteger el tráfico legítimo mientras se descartan 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 de la IP. La variante D/RTBH (RTBH basado en destino) permite filtrar por prefijo de origen del atacante, pero requiere inteligencia sobre las IP de ataque. Para filtrar por protocolo, puerto o comportamiento se necesita BGP FlowSpec, que brinda esa granularidad manteniendo la distribución en el plano de control de BGP.

¿El scrubbing centralizado todavía tiene 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 los ataques multivector modernos que combinan inundación volumétrica con HTTP Flood, agotamiento de TLS y Slowloris, el modelo edge distribuido es superior porque opera en todas las capas simultáneamente.

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

¿Un scrubbing center puede saturarse? Sí. Los ataques que superan la capacidad de scrubbing de un proveedor pueden saturar los propios enlaces de entrada del scrubbing center. Los proveedores con scrubbing distribuido cuentan con mayor capacidad agregada total porque reparten 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 forma individual.

Cómo implementarlo en Azion

Azion opera un modelo de scrubbing distribuido siempre activo que aborda todos los vectores discutidos en este artículo:

1. Scrubbing en el edge con una red Anycast global: el tráfico se inspecciona en cada uno de los más de 100 data centers de Azion, cerca de la fuente del ataque. El enrutamiento Anycast garantiza que los usuarios legítimos no experimenten desvíos de ruta ni aumento de latencia; la inspección ocurre en la misma ruta que el tráfico tomaría normalmente.
2. DDoS Protection siempre activo: no se requiere activación manual, redirección BGP ni ajuste de anuncio de rutas durante el ataque. La protección siempre está activa, sin demora en la redirección de tráfico, con mitigación automática que comienza en segundos para ataques volumétricos L3/L4.
3. Terminación de TLS en el edge con inspección L7: las conexiones TLS se terminan en los data centers de Azion, que usan 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. Capas adicionales de defensa en el edge: el Network Shield aplica reglas a nivel de red para bloquear patrones de ataque, y el Firewall permite crear reglas personalizadas para filtrar el tráfico antes de que llegue a tu aplicación.
5. Sin blackhole forzado: Azion no aplica blackhole routing a las IP 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 tráfico legítimo a su destino, sin importar la escala del ataque.

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

Recursos relacionados

• ¿Qué es la protección y mitigación de DDoS?
• ¿Qué es un ataque DDoS?
• Tipos de ataques DDoS
• Azion DDoS Protection
• Azion Network Shield

Fuentes:

• IETF. “A Border Gateway Protocol 4 (BGP-4).” RFC 4271. 2006.
• IETF. “Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF).” RFC 5635. 2009.
• IETF. “BGP Communities Attribute.” RFC 1997. 1996.
• IETF. “BLACKHOLE Community.” RFC 7999. 2016.
• IETF. “Dissemination of Flow Specification Rules.” RFC 5575. 2009.
• IETF. “Dissemination of Flow Specification Rules.” RFC 8955. 2021.
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.
• Cisco Systems. “Remotely Triggered Black Hole Filtering—Destination Based and Source Based.” 2005.