Eliminando oportunidades para secuestro de tráfico

^{Hermoso esquema para la conexión BGP a la red de filtrado Qrator}

Un pequeño resumen histórico

• Secuestros BGP: cuando un ISP origina un anuncio de espacio de direcciones que no le pertenece;
• Fugas de ruta BGP: cuando un ISP anuncia prefijos recibidos de un proveedor o par a otro proveedor o par.

Esta semana han pasado 11 años desde el memorable incidente de YouTube BGP , provocado por la propagación global de un anuncio de prefijo más específico, originado por Pakistan Telecom, que condujo a una interrupción del tráfico de casi 2 horas de duración en la forma de redirigir el tráfico de legítimo camino al falso. Podríamos adivinar si ese evento fue intencional, e incluso una respuesta correcta no nos ayudaría a prevenir por completo que tales incidentes ocurran hoy. Mientras lees esto, una fuga de ruta o un secuestro se está extendiendo por las redes. Por qué Debido a que BGP no es fácil, y configurar una configuración correcta y segura es aún más difícil (todavía).

En estos once años, el secuestro de BGP se convirtió en un vector de ataque bastante dañino debido al emplazamiento de BGP en la arquitectura de Internet moderna. Gracias a BGP, los enrutadores no solo adquieren información de pares y, por lo tanto, todas las rutas de Internet, sino que también pueden calcular la mejor ruta para el tráfico a su destino a través de muchas redes intermedias (tránsito), cada una representando un AS individual. Un único AS es solo un grupo de redes IPv4 y / o IPv6 que funcionan bajo una única política de enrutamiento externo.

Y gracias a BGP en su estado actual, los atacantes son capaces de realizar robos masivos de tráfico, secuestrar eficientemente los prefijos de la red objetivo y colocarse en el medio. Y eso es solo el comienzo: en la era de los ciber-actores patrocinados por el estado, es evidente que la piedra angular del Protocolo Border Gateway, que es la confianza, ya no es suficiente para evitar que ocurran brotes maliciosos de incidentes de enrutamiento, deliberados o no. . Dado que BGP desempeña un papel tan esencial en la existencia de Internet tal como la conocemos (es el único protocolo de puerta de enlace exterior para controlar el flujo de tráfico entre diferentes proveedores de servicios de Internet en todo el mundo), durante una década hemos visto intentos de parchear cosas arriba

Definición del problema

La complejidad general de administrar un AS que funciona con el protocolo BGP no disminuye con el tiempo y el esfuerzo. Los operadores en mercados en desarrollo, donde los mercados de ISP y operadores crecen dramáticamente cada año, no estiman correctamente las posibles consecuencias de un AS mal ajustado. Ninguna medida de seguridad podría defenderse contra tal error interno. La ausencia de automatización dentro del BGP hace que sea imposible para los nuevos jugadores, con menos experiencia, manejar adecuadamente el AS en situaciones de alto estrés, como después de la creación de la fuga de ruta o bajo el secuestro.

Desafortunadamente, debido al lugar en la vida humana que ocupaba Internet, es difícil para muchos operadores de AS mantenerse al día con el creciente número. Ejemplo simple: en 1997, el número de sistemas autónomos era de 3000, en 2005 - 17000, a principios de 2019 - 63678. Las tablas de enrutamiento (que se almacenan dentro de los enrutadores BGP) crecieron de 50k entradas en 1997 y 180k en 2005 a asombrosas 850k a principios de 2019.

Tanto las filtraciones de ruta como los secuestros tienen efectos similares en las operaciones de ISP: redirigen el tráfico, lo que resulta en una mayor latencia, pérdida de paquetes o posibles ataques MITM. Sin embargo, el nivel de riesgo depende significativamente de la propagación de estas anomalías de BGP. Por ejemplo, un secuestro que se propaga solo a los clientes puede concentrar el tráfico del cono de un cliente de un ISP en particular. Si la anomalía se propaga a través de pares, aguas arriba o llega a redes de Nivel 1, distribuyéndose globalmente, el tráfico puede ser redirigido a nivel de países enteros y / o proveedores globales. La capacidad de restringir la propagación de las anomalías BGP a los contracorrientes y pares, sin requerir el apoyo de la fuente de la anomalía (que es fundamental si una fuente tiene intenciones maliciosas), debería mejorar significativamente la seguridad del enrutamiento entre dominios y resolver la mayoría de los problemas. .

Simplemente echando un vistazo rápido a los eventos citados en Wikipedia relacionados con "Secuestro de BGP" , vemos un aumento de su frecuencia en los últimos dos años. Por qué Porque hay muchas maneras de organizar un ataque contra el BGP y muy pocas probabilidades de desconectarse. Sin embargo, esas compañías que son conocidas como malos actores están perdiendo sus conexiones ascendentes al final, ya que perjudica la reputación. Y aún así, tales incidentes ocurren ya que (todavía) no hay forma de evitar una fuga de ruta o un secuestro de prefijo con una precisión del 100%.

Cientos de incidentes de enrutamiento ocurren diariamente, la mayoría de los cuales es el resultado de una simple configuración incorrecta. Esos secuestros realmente peligrosos y maliciosos suelen ser engañosos y dirigidos con precisión, lo que los hace más difíciles de encontrar y solucionar. Y solo un pequeño porcentaje de ellos recibió cobertura de los medios porque, debido a la naturaleza de BGP, cada incidente tiene que propagarse a un nivel más significativo (a nivel nacional) para hacerse notar, y las compañías que monitorean sus redes podrían detener dicha propagación.

Dado que el concepto de secuestro de BGP gira en torno a la localización de un ISP que no está filtrando los anuncios de BGP (y hay muchos de estos proveedores), siempre hay un sospechoso. Para todos y cada uno de los incidentes de BGP de los últimos dos años, hubo uno o varios ASes específicos responsables.

Debería pensar que, debido a un enorme potencial de daño colateral a una parte tan vital de las empresas de la vida moderna, debería tener miedo a la muerte y tomar todas las medidas posibles para prevenir tales eventos en primer lugar. Bueno, esto suena demasiado bueno para ser verdad IRL.

A finales de 2018, el 7% de los ISP de tránsito en IPv4 y el 1% de los ISP de tránsito en el mundo de enrutamiento IPv6 aceptaron fugas fuera de su cono de clientes. Puede decir que los números no son tan altos, pero echemos un vistazo más de cerca a los resultados ordenados por el "tamaño" del ISP:



Como era de esperar, todos los Tier-1 se ven afectados, con más del 50% de los ISP TOP 400 IPv4. IPv6 se ve un poco más saludable, solo no olvidemos que tiene menos prefijos y admite ISP. Entonces, el problema existe y no se está solucionando de manera suficientemente eficiente; trataremos de explicar por qué.

Intenta aplicar un parche

En realidad, ha habido un esfuerzo significativo para mejorar la seguridad de BGP. Actualmente, la técnica más común es utilizar filtros de entrada (entrantes), basados ​​en datos de registros de enrutamiento de Internet . La idea es simple: utilice objetos de ruta "aprobados" y AS-SET para crear filtros en los enlaces de los clientes. Un problema subyacente es que tanto los AS-SET como los objetos de ruta varían de una IRR a otra, y a veces pueden existir diferentes objetos con el mismo identificador en IRR separadas. Y, por supuesto, las políticas de TIR no son obligatorias: son de implementación voluntaria, lo que nos lleva a una situación en la que muchos de los IPv4 e IPv6 no tienen ningún objeto registrado o son incorrectos. Además de esos equivocados. Por lo tanto, muchos de los objetos IRR se mantienen de manera deficiente e incluso algunas redes enormes de nivel 2 no pueden configurar sus filtros correctamente.


^{Jerarquía de certificados de recursos RPKI}

Existe otra opción emocionante para filtrar anuncios incorrectos: la validación de origen basada en ROA podría usarse para detectar y filtrar errores de origen accidentales. Si bien estas actualizaciones de BGP son bastante útiles, todavía se basan en atributos de BGP transitivos, AS_Path, que el atacante puede y manipulará.

RPKI (ROA Foundation ) se basa en una jerarquía de certificados de recursos, alineados con la estructura de asignación de Recursos de Número de Internet. El certificado de recursos está vinculado, por ejemplo, al registro RIPE NCC . Esto se debe a que solo mientras alguien sea miembro de RIPE NCC y tenga una relación contractual con RIPE NCC puede declararse con autoridad quién es el titular de un recurso de número de Internet individual. El certificado tiene una validez de 18 meses, pero se renueva automáticamente cada 12 meses. RPKI está estructurado de tal manera que cada certificado de recursos actual coincide con una asignación o asignación de recursos actual, un momento crucial, también para ASPA.

Vale la pena señalar que 2018 fue un año esencial para la seguridad de BGP con muchos eventos notables. BGPSec es finalmente un estándar, aunque nadie espera que se implemente completamente debido a sus complejos requisitos de soporte. Con una tasa de adopción del 100%, BGPSec resuelve secuestros maliciosos con una precisión muy alta, pero los costos de cálculo de la estricta validación criptográfica de AS_Path son insoportables para la mayoría de los jugadores, excepto quizás para los operadores de AS más ricos del mundo. Y, de nuevo, para que funcione correctamente, BGPSec debe implementarse en cada red que administra su propia ruta.

Todos los eventos recientes hacen evidente que el genio de la manipulación de BGP está fuera de la botella, haciendo realidad los deseos de alguien. No podemos esperar a que otra década llegue a una conclusión que tuvimos hace 10 años; esto debería detenerse ahora, proporcionando medidas técnicas efectivas para la validación de prefijos, tanto la entrada como la salida.

Enfoque ASPA

Anteriormente, nuestra compañía apuntaba a mejoras de protocolo para disminuir errores y errores, y en 2018 nos concentramos en combatir la actividad maliciosa, específicamente los secuestros de BGP. Este vector es potente como ya hemos visto en varias ocasiones, y los atacantes no dudan en emplearlo en un intento de interrumpir el servicio o robar datos de los usuarios. El principal problema es que, a excepción del monitoreo, actualmente no hay nada que evite los secuestros de ruta en el protocolo mismo. Como ya hemos dicho, BGPSec no cambiará nada hasta que se implemente en los proveedores de red más importantes (o, reformulando, en la mayoría de las redes), lo que podría haber sucedido si el protocolo fuera adecuado.

Nuestra respuesta es el enfoque de piratas informáticos: ASPA, donde las herramientas actuales se utilizan para combatir los problemas más graves en el mundo del enrutamiento BGP. La implementación es fácil, aunque la solución resultante responde a casi todas las amenazas relacionadas. El hecho de que no haya necesidad de esperar la adopción completa de la ZAEP es la razón principal que respalda nuestro enfoque. En 2018 vimos fugas de ruta significativas, secuestros graves y muchos otros eventos relacionados con BGP, que es la razón principal por la que necesitamos encontrar algo que funcione en los meses más cercanos, sin esperar 10 años para la implementación de BGPSec.

La mejora de la Autorización de ruta del sistema autónomo al protocolo BGP en el que nuestros ingenieros están trabajando, en colaboración con otros, podría resolver de manera eficiente y, lo que es más importante, resolver rápidamente el problema de los secuestros globales. ASPA se enfoca en automatizar la detección y prevención de secuestros maliciosos (en pareja con ROA) y las fugas de ruta.

Para lograr este objetivo específico, se define un nuevo procedimiento de verificación AS_PATH, que ayuda a detectar automáticamente AS_PATH con formato incorrecto en los anuncios que se reciben tanto de clientes como de pares. El procedimiento en sí utiliza una base de datos compartida y firmada de relaciones de cliente a proveedor (C2P), que se construye con un nuevo objeto RPKI: Autorización de proveedor de sistema autónomo (ASPA). Es ligero y rápido de implementar, ya que detecta AS_PATH no válidos justo después de la implementación.

Las ZAEP son objetos firmados digitalmente que atestiguan que un titular AS del cliente (CAS) ha autorizado a un proveedor AS (PAS) particular para propagar los anuncios de ruta IPv4 o IPv6 BGP del cliente en adelante, a los proveedores o pares aguas arriba del proveedor. Para profundizar en los detalles, debe echar un vistazo al perfil de registro ASPA.

Entonces, si se recibe una ruta válida de un cliente o par, DEBE tener solo pares C2P en su AS_PATH. Después, si tenemos una base de datos validada de pares de cliente a proveedor, ¡podemos verificar las rutas recibidas de clientes y pares! Por supuesto, esto no es una bala de plata: es solo una herramienta útil para evitar que la anomalía se propague más cerca de su origen.



Este esquema simple muestra cómo funciona dicha verificación basada en ASPA. Los AS verdes representan pares firmados, y el rojo representa al atacante. En este ejemplo, AS1 tiene un objeto RPKI ROA en su lugar.

AS_PATH: AS4
La esquina 1 muestra que si el AS más cercano en AS_PATH no es el ASN vecino del receptor, entonces el procedimiento se detiene con el resultado "inválido". Además, si en uno de los segmentos AS_SEQ hay un par "no válido", el procedimiento también se detiene con el resultado "no válido";

AS_PATH: AS4 AS1
La esquina 2 muestra que lo mismo sucede si el atacante intenta hacer un nuevo par no validado, el resultado también sería "inválido";

AS_PATH: AS4 AS2 AS1
La esquina 3 ilustra que cualquier intento de anunciar un par no validado resultaría como una ruta "inválida" y, por lo tanto, descartada.

AS_PATH: AS2 AS1
En la última esquina 4 , volvemos a la condición inicial bajo la cual si el AS más cercano en el AS_PATH no es el ASN vecino del receptor, dicho procedimiento se mantiene como "no válido".

Se pueden encontrar detalles detallados sobre el procedimiento de verificación AS_PATH dentro del borrador correspondiente de IETF . Puede parecer un poco complicado, pero es liviano, funciona con la infraestructura RPKI existente y tiene efecto en el estado de una adopción parcial, rentable. En otras palabras, podría funcionar ahora, ¡ayudándonos a llevar las pérdidas y secuestros de rutas BGP al borde de la extinción!

¿Por qué debería apoyarnos para mejorar la seguridad de BGP?

¿Cómo sabemos, en primer lugar, que el RPKI ROA es adecuado para este papel? Echemos un vistazo más de cerca a las estadísticas actuales sobre su adopción.

En el IPv4 para los prefijos 938526, 95272 tienen entradas válidas de RPKI ROA o ~ 10%. En el mundo IPv6, los prefijos 80480 10593 tienen entradas válidas de RPKI ROA o ~ 12%

Esos dígitos no son tan altos como desearíamos, ¡pero crecen cada día! Dado que el número de ROA validados no es muy grande, es evidente que solo los más responsables los mantienen diariamente. Y aunque no confiamos completamente en los datos de IRR, firmar el anuncio de BGP con ROA ya es útil y está en su lugar. Hay progreso entre los operadores de Intercambio de Internet, así como los proveedores de servicios de Internet más grandes de todo el mundo. Y con respecto a los "usuarios comunes de Internet", su propio ISP podría ser el próximo si está lo suficientemente motivado para mantener sus datos seguros.

Si usted está tan interesado en eliminar las oportunidades de secuestro de tráfico como nosotros, firme ROA y apoye la adopción de ASPA en la lista de correo de IETF como esperamos en su transición a la etapa de RFC en un futuro observable.