Este artículo fue publicado originalmente en el blog de APNIC.
Hace tiempo que el secuestro de BGP (Border Gateway Protocol) es una de las amenazas de seguridad más persistentes del protocolo. RPKI y ROV se estandarizaron para permitir la autenticación de origen y mitigar la amenaza, pero es probable que el despliegue de validación de origen de ruta (ROV) siga siendo parcial durante la próxima década. Y el despliegue parcial no solo deja brechas evidentes en la protección, sino que también crea una amenaza sutil, a la que nos referimos como secuestro furtivo de BGP relacionado con la ROV (o simplemente secuestro furtivo).
En un secuestro furtivo, el sistema autónomo (AS) afectado nunca ve el origen malicioso en el plano de control, ya que los vecinos que implementan ROV descartan los anuncios no válidos. Sin embargo, el tráfico puede desviarse silenciosamente hacia un atacante a través de AS legados (sin ROV) presentes en el camino del plano de datos. Esto permite que el ataque eluda eficazmente los mecanismos de detección que dependen de la visibilidad del plano de control. En otras palabras, el secuestro de BGP se vuelve más furtivo: las tablas de enrutamiento y las verificaciones de RPKI de la víctima parecen perfectamente normales, incluso mientras se desvía su tráfico.
A continuación, presentamos un caso real que ilustra cómo ocurre un secuestro furtivo.
(Acceso libre, no requiere suscripción)
Figura 1: Incidente de secuestro en 203.127.225.0/24 (visto por última vez el 24 de abril de 2025). Este incidente probablemente se debió a una configuración errónea sin mala intención.
En este caso, AS17894, el supuesto secuestrador, anunció de forma incorrecta un prefijo /24, que forma parte de un /16 que AS3758 posee y origina de forma legítima. Técnicamente, se trata de un clásico secuestro de un prefijo más específico.
La sutileza de este caso es la intervención del ROV. En la Figura 1, solo el AS37100 aplica filtrado basado en ROV. Dado que el AS37100 descartó la ruta no válida del /24, solo mantuvo la ruta válida del /16 completo en su tabla de enrutamiento. Como resultado, el AS37100 y sus clientes no tenían visibilidad de la ruta inválida en el plano de control. En otras palabras, el AS37100 y sus clientes no tenían motivos para sospechar que algo andaba mal. Sin embargo, su tráfico hacia el /24 se desviaba a AS17894 a través del AS6762 legado, que no realizaba ROV y aceptaba la ruta /24 no válida. A menos que se les notificara o que por alguna razón investigaran activamente el /24, seguirían sin saber del secuestro en curso.
Figura 1: Incidente de secuestro en 203.127.225.0/24 (visto por última vez el 24 de abril de 2025). Este incidente probablemente se debió a una configuración errónea sin mala intención.
En este caso, AS17894, el supuesto secuestrador, anunció de forma incorrecta un prefijo /24, que forma parte de un /16 que AS3758 posee y origina de forma legítima. Técnicamente, se trata de un clásico secuestro de un prefijo más específico.
La sutileza de este caso es la intervención del ROV. En la Figura 1, solo el AS37100 aplica filtrado basado en ROV. Dado que el AS37100 descartó la ruta no válida del /24, solo mantuvo la ruta válida del /16 completo en su tabla de enrutamiento. Como resultado, el AS37100 y sus clientes no tenían visibilidad de la ruta inválida en el plano de control. En otras palabras, el AS37100 y sus clientes no tenían motivos para sospechar que algo andaba mal. Sin embargo, su tráfico hacia el /24 se desviaba a AS17894 a través del AS6762 legado, que no realizaba ROV y aceptaba la ruta /24 no válida. A menos que se les notificara o que por alguna razón investigaran activamente el /24, seguirían sin saber del secuestro en curso.
Evidencia del looking glass del AS37100 confirma el incidente. Inspeccionamos manualmente el estado del plano de control y la alcanzabilidad del plano de datos del AS37100 utilizando su looking glass público ‘g-01-ams.nl’. Todas las observaciones se capturaron el 10 de febrero de 2025.
Como se muestra en la Figura 2, al ejecutar show ip bgp para el /16 se obtuvieron dos rutas válidas, ambas originadas por el titular legítimo AS3758:
Figura 2: Rutas del AS37100 a 203.127.0.0/16.
Sin embargo, al ejecutar show ip bgp para el subprefijo /24, no se devolvió ningún resultado (ver Figura 3), lo que significa que el secuestro fue prácticamente invisible para el AS37100 en el plano de control:
Figura 3: Rutas del AS37100 a 203.127.225.0/24.
En el plano de datos se vio una historia diferente. Como se muestra en la Figura 4, un traceroute del AS37100 a 203.127.225.1 se desvió y terminó en el AS17894, confirmando que el tráfico del /24 estaba siendo secuestrado (Figura 4).
Figura 4: Traceroute del AS37100 a 203.127.225.1.
La principal conclusión de este incidente es que, si algún AS intermedio en nuestro camino tiene una visión de los orígenes diferente de la nuestra, podría producirse un desvío del tráfico, incluso cuando nuestra tabla de enrutamiento sea correcta. Más importante aún, el despliegue parcial de ROV está haciendo que estas inconsistencias sean cada vez más frecuentes, lo que potencialmente dificulta la detección de secuestros de BGP.
Además de este caso, realizamos un estudio empírico y analítico a gran escala sobre el riesgo de secuestros furtivos de BGP en la Internet actual. Los resultados completos se presentarán en nuestro próximo paper en NDSS 2026. También hemos creado un sitio web que publica informes diarios de los secuestros furtivos que detectamos.
Con base en lo aprendido, presentamos algunos conocimientos operativos y recomendaciones para los operadores de red:
Primero, seguir impulsando la implementación de RPKI y ROV. Un hallazgo clave de nuestro estudio es que el riesgo de secuestro furtivo sigue una curva de crecimiento y posterior disminución a medida que aumenta el despliegue de ROV. La buena noticia es que los datos actuales sugieren que podríamos estar entrando en la fase de descenso, por lo que una mayor adopción podría reducir el riesgo.
Segundo, prestar atención a lo que se descarta. Las rutas no válidas que se filtran aún pueden contener información valiosa. Monitorearlas y correlacionarlas puede ayudar a identificar posibles eventos de desvío de tráfico. Una estrategia de mitigación más proactiva (aunque agresiva) podría ser que los AS que implementan ROV no solo descarten las rutas no válidas, sino que también vuelvan a ejecutar la selección de rutas y prefieran aquellas que eviten los AS detectados en los anuncios descartados (una política similar se describe en una patente de Cisco).
Por último, colaborar y compartir visibilidad. Los recursos comunitarios, como RouteViews, RIPE RIS y RIPE Atlas, son poderosas herramientas para mejorar la visibilidad colectiva de los eventos de enrutamiento. Los AS que implementan ROV podrían contribuir aún más al compartir compendios de “rutas descartadas” (por ejemplo, a través de listas de correo), ofreciendo así alertas tempranas sobre secuestros furtivos. Animamos a los operadores a participar en los debates, compartir experiencias operativas y ayudar a conformar defensas prácticas. Como primer paso, hemos iniciado un Internet Draft para documentar formalmente esta amenaza e invitar a la comunidad a enviar sus comentarios.
El secuestro furtivo de BGP representa un riesgo sutil pero real en la Internet parcialmente protegida de hoy. La buena noticia es que con mayor adopción de RPKI, mejor monitoreo y mayor colaboración, podemos dificultar significativamente el éxito de estos ataques y facilitar su detección.
Yihao presentó este tema durante la Sesión Técnica N.º 2 de APNIC 60. La grabación de la sesión está disponible ahora, incluido el debate con el público.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
