DDoS scrubbing con BGP: cómo funciona la mitigación a nivel de ruteo para operadores
Los ataques DDoS siguen siendo uno de los vectores de interrupción más frecuentes para ISPs e infraestructura crítica en Latinoamérica. La respuesta instintiva de muchos operadores es buscar appliances o servicios de scrubbing cloud, pero la realidad es que la primera línea de defensa efectiva pasa por BGP — el mismo protocolo que mueve el tráfico de internet también puede usarse para desviar, filtrar y bloquear ataques antes de que saturen los enlaces de los clientes.
RIPE Labs publicó en abril 2026 un análisis de los cinco principales scrubbers del mundo visto desde datos de ruteo BGP. Los patrones que muestra ese análisis revelan algo que los operadores LATAM deberían entender: las diferencias entre mitigación always-on y on-demand no son solo operativas, tienen implicancias directas en la visibilidad RPKI y en cómo un ataque se ve (o no se ve) desde afuera de tu red.
El problema que BGP viene a resolver
Cuando llega un ataque volumétrico — 50 Gbps de UDP flood, por ejemplo — el problema no es solo que el servidor destino no puede procesarlo. El problema es que el tráfico ya consumió el enlace antes de llegar al destino. Si el uplink del cliente es de 1 Gbps y el ataque llega a 10 Gbps, los 9 Gbps de exceso están saturando tu red de distribución y afectando a otros clientes.
La única forma de resolver esto es actuar más arriba en la topología: desviar o bloquear el tráfico de ataque antes de que entre a los segmentos congestionados. BGP es el mecanismo natural para hacerlo porque permite señalizar a los routers vecinos que traten un prefijo de una manera específica.
Las tres técnicas principales son RTBH, BGP Flowspec y scrubbing por desvío (sink-then-reinject).
Técnica 1: RTBH — Remote Triggered Black Hole
RTBH (Remotely Triggered Black Hole, RFC 5635) es la técnica más sencilla y la más ampliamente implementada. El principio es simple: cuando un prefijo está siendo atacado, se anuncia una ruta hacia él con una community especial que indica a los routers upstream que descarten ese tráfico en lugar de reenviarlo.
Cómo funciona en la práctica
La mayoría de los upstreams tienen comunidades BGP documentadas para RTBH. Por ejemplo, en el formato clásico:
64496:666 → blackhole el prefijo destino (destination-based RTBH)
64496:9999 → blackhole el prefijo origen (source-based RTBH)
Cuando anunciás el prefijo atacado con esa community, el upstream descarta el tráfico hacia ese destino en sus routers de borde — antes de que entre a tu red.
Destination-based RTBH bloquea todo el tráfico hacia la IP o prefijo atacado. Es efectivo pero también bloquea el tráfico legítimo: el cliente deja de recibir ataques pero también deja de recibir servicio. Para ataques cortos o cuando el cliente está dispuesto a sacrificar disponibilidad temporalmente, es la respuesta más rápida.
Source-based RTBH es más quirúrgico: bloquea tráfico originado desde IPs o prefijos específicos conocidos como fuentes del ataque. Requiere que hayas identificado las fuentes (que en ataques amplificados pueden ser miles de reflectores legítimos) y que tu upstream soporte esta variante.
Configuración básica en IOS-XR
route-policy RTBH-TRIGGER
set community (64496:666) additive
set local-preference 50
set next-hop 192.0.2.1 # null route address
pass
end-policy
router bgp 65000
neighbor 203.0.113.1
address-family ipv4 unicast
route-policy RTBH-TRIGGER out
Lo que hace este ejemplo: cuando un operador quiere activar RTBH para un prefijo, añade manualmente una ruta estática hacia 192.0.2.1 (la dirección de null route), que redistribuye al BGP con la community de blackhole. El upstream recibe la ruta con esa community y descarta el tráfico.
Técnica 2: BGP Flowspec
BGP Flowspec (RFC 5575 / RFC 8955) es una extensión del protocolo BGP que permite distribuir reglas de filtrado de tráfico detalladas como si fueran rutas. A diferencia de RTBH (que trabaja solo con prefijos origen/destino), Flowspec puede filtrar combinando:
- IP origen y destino
- Puerto origen y destino
- Protocolo (TCP, UDP, ICMP)
- Flags TCP
- DSCP
- Longitud del paquete
- Fragmentación
Un caso real: filtrar amplificación DNS
Un ataque de amplificación DNS usa servidores DNS abiertos para amplificar tráfico hacia el destino. El tráfico de ataque tiene características muy específicas: UDP, puerto 53 origen, paquetes de respuesta grandes (>512 bytes). Flowspec puede filtrar exactamente eso sin bloquear el tráfico legítimo al mismo destino:
ip flowspec address-family ipv4 unicast
match destination-prefix 192.0.2.100/32
match source-port 53
match ip protocol 17 # UDP
match packet-length 512-65535
action drop
Esta regla se distribuye via BGP a todos los routers que la soporten y que tengan activado Flowspec. En una red propia o con upstream que lo soporte, esto puede activarse en segundos y bloquear el componente malicioso del ataque sin descartar el servicio completo.
Limitaciones de Flowspec
Flowspec no es universalmente soportado. Los principales upstreams tier-1 y tier-2 tienen soporte variable — algunos lo ofrecen como servicio adicional, otros directamente no lo tienen disponible. En la práctica, Flowspec es más útil dentro de la red propia del ISP que como herramienta para señalizar hacia upstream.
Otro desafío: la complejidad operativa. Las reglas Flowspec mal configuradas pueden bloquear tráfico legítimo con mucha facilidad. Requieren un proceso de activación y validación cuidadoso.
Técnica 3: Scrubbing por desvío (sink-then-reinject)
Esta es la arquitectura que usan los servicios profesionales de scrubbing (Cloudflare, NETSCOUT, Radware, etc.) y que los ISPs más grandes implementan internamente. El concepto: en lugar de descartar el tráfico atacado, se desvía hacia un centro de limpieza (scrubbing center) donde se filtra, y el tráfico legítimo se reinyecta hacia el destino real.
El flujo de la mitigación
- Se detecta el ataque (por anomalías de volumen, tipo de tráfico, o alertas manuales)
- El router de borde anuncia el prefijo atacado con una ruta más específica que lo desvía al scrubbing center
- El scrubbing center recibe todo el tráfico (ataque + legítimo)
- Aplica análisis y filtros: stateful inspection, rate limiting, pattern matching, challenge-response para HTTP
- El tráfico limpio se reinyecta hacia el destino mediante un túnel GRE, MPLS o VPN
Cómo se ve esto en BGP
Desde afuera de la red, el scrubbing por desvío se ve como un cambio de ruta: el prefijo atacado empieza a ser anunciado desde una dirección diferente (el scrubbing center). Si el scrubbing es always-on, esa ruta existe permanentemente. Si es on-demand, la ruta aparece cuando se activa la mitigación.
Aquí aparece la implicancia RPKI que menciona el análisis de RIPE Labs: si el scrubbing center está en un ASN diferente al propietario legítimo del prefijo, el ROA del prefijo puede no cubrir ese ASN. Un observador externo con RPKI activo vería el anuncio del prefijo desde el scrubbing center como RPKI Invalid — lo que puede causar que algunos pares con validación estricta descarten esas rutas.
La solución correcta es que el scrubbing center anuncie el prefijo usando el ASN del cliente (a través de transit directo) o que el cliente cree un ROA adicional que autorice el ASN del scrubbing center como origen válido. Los operadores que despliegan scrubbing de terceros y tienen RPKI activo necesitan coordinar esto explícitamente.
Always-on vs on-demand: qué elegir
| Criterio | Always-on | On-demand |
|---|---|---|
| Latencia de activación | Instantánea | Minutos (manual) o segundos (automático) |
| Costo de tráfico | Alto (todo pasa por scrubbing) | Bajo (solo tráfico bajo ataque) |
| Visibilidad BGP | Estable, siempre desde scrubber | Cambia durante activación |
| Riesgo de RPKI | Requiere ROA coordinado desde el inicio | Riesgo durante la transición |
| Adecuado para | Clientes críticos, bajo umbral de tolerancia | Mayoría de clientes ISP |
Para la mayoría de los ISPs LATAM de tamaño mediano, la arquitectura recomendada es on-demand con activación automática: un sistema de detección (NetFlow + SNMP o solución dedicada como NETSCOUT/NSFOCUS) activa el desvío BGP automáticamente cuando se supera un umbral de tráfico anómalo, sin requerir intervención manual.
El mínimo viable para un ISP LATAM
Si empezás desde cero, el stack de defensa por prioridad:
Nivel 1 — RTBH con upstream (1-2 semanas de implementación)
- Documentar las communities de RTBH de cada upstream
- Crear el proceso operativo para activar blackhole manualmente
- Integrar con el NOC: quién autoriza, cómo se activa, cómo se desactiva
Nivel 2 — RTBH automático (1 mes)
- Agregar monitoreo de volumen por prefijo (NetFlow)
- Script de activación automática de RTBH cuando un prefijo supera umbral
- Alertas y logging del evento
Nivel 3 — Flowspec interno (3-6 meses)
- Validar soporte en plataforma de routers
- Desarrollar playbooks de mitigación por tipo de ataque
- Integrar con sistema de ticketing/NOC
Nivel 4 — Scrubbing dedicado (si la escala lo justifica)
- Evaluar solución propia vs servicio cloud
- Coordinar ROAs con scrubbing ASN si aplica
- Implementar GRE/VPN para reinserción del tráfico limpio
RPKI y scrubbing: la lista de verificación
Si tu red tiene RPKI activo y estás implementando o ya tenés scrubbing, verificá:
- ¿El scrubbing center usa tu mismo ASN o uno diferente?
- ¿Tus ROAs cubren los prefijos que se desvían al scrubbing?
- Si el scrubbing center tiene un ASN propio, ¿creaste ROA con max-length apropiado que lo autorice?
- ¿Tus pares con validación RPKI estricta van a ver el anuncio como Valid o Invalid durante la mitigación?
- ¿Tenés un procedimiento de rollback si la mitigación introduce un estado RPKI inválido?
La interacción entre scrubbing y RPKI es una de las áreas donde más errores de configuración ocurren silenciosamente — el scrubbing funciona pero introduce una validación inválida que puede afectar la accesibilidad del prefijo desde redes con política de rechazo de rutas RPKI Invalid.
¿Tu red tiene RPKI activo pero nunca coordinaste la validación con tu proveedor de scrubbing? Escribinos a [email protected] — hacemos auditorías de configuración BGP/RPKI y te ayudamos a cerrar ese gap antes de que sea un problema durante un incidente real.