13 de marzo al grupo de trabajo antiabuso RIPE considere el secuestro de BGP (hjjack) como una violación de la política de RIPE. Si se aceptara la propuesta, el proveedor de Internet atacado mediante la interceptación del tráfico tendría la oportunidad de enviar una solicitud especial para exponer al atacante. Si el equipo de revisión recopiló suficiente evidencia de respaldo, el LIR que fue la fuente de la intercepción BGP sería considerado un intruso y podría ser despojado de su estatus LIR. También hubo algunos argumentos cambios
En esta publicación queremos mostrar un ejemplo de un ataque donde no sólo estaba en cuestión el atacante real, sino también toda la lista de prefijos afectados. Además, un ataque de este tipo vuelve a plantear dudas sobre los motivos de futuras interceptaciones de este tipo de tráfico.
En los últimos años, sólo conflictos como el MOAS (Sistema Autónomo de Origen Múltiple) han sido cubiertos en la prensa como intercepciones de BGP. MOAS es un caso especial en el que dos sistemas autónomos diferentes anuncian prefijos en conflicto con los ASN correspondientes en AS_PATH (el primer ASN en AS_PATH, en lo sucesivo denominado ASN de origen). Sin embargo, podemos nombrar al menos interceptación de tráfico, lo que permite a un atacante manipular el atributo AS_PATH para diversos fines, incluido eludir los enfoques modernos de filtrado y monitoreo. Tipo de ataque conocido - el último tipo de interceptación, pero sin ninguna importancia. Es muy posible que este sea exactamente el tipo de ataque que hemos visto en las últimas semanas. Un evento así tiene un carácter comprensible y consecuencias bastante graves.
Aquellos que busquen la versión TL;DR pueden desplazarse hasta el subtítulo "Perfect Attack".
Fondo de red
(para ayudarle a comprender mejor los procesos involucrados en este incidente)
Si desea enviar un paquete y tiene varios prefijos en la tabla de enrutamiento que contiene la dirección IP de destino, utilizará la ruta para el prefijo con la longitud más larga. Si hay varias rutas diferentes para el mismo prefijo en la tabla de enrutamiento, elegirá la mejor (según el mejor mecanismo de selección de ruta).
Los enfoques de filtrado y monitoreo existentes intentan analizar rutas y tomar decisiones analizando el atributo AS_PATH. El enrutador puede cambiar este atributo a cualquier valor durante la publicidad. Simplemente agregar el ASN del propietario al principio de AS_PATH (como ASN de origen) puede ser suficiente para evitar los mecanismos de verificación de origen actuales. Además, si hay una ruta desde el ASN atacado hacia usted, es posible extraer y utilizar el AS_PATH de esta ruta en sus otros anuncios. Cualquier verificación de validación exclusiva de AS_PATH para sus anuncios elaborados eventualmente se aprobará.
Todavía existen algunas limitaciones que vale la pena mencionar. En primer lugar, en caso de filtrado de prefijos por parte del proveedor ascendente, su ruta aún puede filtrarse (incluso con el AS_PATH correcto) si el prefijo no pertenece a su cono de cliente configurado en el ascendente. En segundo lugar, un AS_PATH válido puede dejar de ser válido si la ruta creada se anuncia en direcciones incorrectas y, por lo tanto, viola la política de enrutamiento. Por último, cualquier ruta con un prefijo que viole la longitud del ROA puede considerarse inválida.
Incidentes
Hace unas semanas recibimos una queja de uno de nuestros usuarios. Vimos rutas con su origen ASN y prefijos /25, mientras que el usuario afirmó que no las anunciaba.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
Ejemplos de anuncios para principios de abril de 2019
NTT en la ruta del prefijo /25 lo hace especialmente sospechoso. LG NTT desconocía esta ruta en el momento del incidente. Entonces sí, ¡algún operador crea un AS_PATH completo para estos prefijos! La verificación de otros enrutadores revela un ASN en particular: AS263444. Después de mirar otras rutas con este sistema autónomo, nos encontramos con la siguiente situación:
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
Intenta adivinar qué pasa aquí.
Parece que alguien tomó el prefijo de la ruta, lo dividió en dos partes y anunció la ruta con el mismo AS_PATH para esos dos prefijos.
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
Rutas de ejemplo para uno de los pares de prefijos divididos
Surgen varias preguntas a la vez. ¿Alguien ha probado realmente este tipo de interceptación en la práctica? ¿Alguien ha tomado estas rutas? ¿Qué prefijos se vieron afectados?
Aquí es donde comienza nuestra serie de fracasos y otra ronda más de decepción con el estado actual de la salud de Internet.
El camino del fracaso
Lo primero es lo primero. ¿Cómo podemos determinar qué enrutadores aceptaron dichas rutas interceptadas y cuyo tráfico podría redirigirse hoy? Pensamos que comenzaríamos con los prefijos /25 porque "simplemente no pueden tener distribución global". Como puedes imaginar, estábamos muy equivocados. Esta métrica resultó ser demasiado ruidosa y las rutas con tales prefijos pueden aparecer incluso en operadores de nivel 1. Por ejemplo, NTT tiene alrededor de 50 prefijos de este tipo, que distribuye a sus propios clientes. Por otro lado, esta métrica es mala porque dichos prefijos se pueden filtrar si el operador usa , en todas direcciones. Por lo tanto, este método no es adecuado para encontrar todos los operadores cuyo tráfico fue redirigido como resultado de dicho incidente.
Otra buena idea que pensamos fue mirar . Especialmente para rutas que violan la regla maxLength del ROA correspondiente. De esta manera podríamos encontrar la cantidad de ASN de origen diferente con estado Inválido que eran visibles para un AS determinado. Sin embargo, existe un "pequeño" problema. La media (mediana y moda) de este número (el número de ASN de diferente origen) es de unos 150 y, aunque filtramos los prefijos pequeños, se mantiene por encima de 70. Esta situación tiene una explicación muy sencilla: sólo hay un Son pocos los operadores que ya utilizan filtros ROA con una política de “restablecer rutas no válidas” en los puntos de entrada, de modo que dondequiera que aparezca una ruta con una infracción de ROA en el mundo real, pueda propagarse en todas las direcciones.
Los dos últimos enfoques nos permiten encontrar operadores que vieron nuestro incidente (ya que fue bastante grande), pero en general no son aplicables. Bien, pero ¿podemos encontrar al intruso? ¿Cuáles son las características generales de esta manipulación AS_PATH? Hay algunas suposiciones básicas:
- El prefijo no se había visto antes en ninguna parte;
- El ASN de origen (recordatorio: el primer ASN en AS_PATH) es válido;
- El último ASN en AS_PATH es el ASN del atacante (en caso de que su vecino verifique el ASN del vecino en todas las rutas entrantes);
- El ataque proviene de un único proveedor.
Si todas las suposiciones son correctas, entonces todas las rutas incorrectas presentarán el ASN del atacante (excepto el ASN de origen) y, por lo tanto, este es un punto "crítico". Entre los verdaderos secuestradores se encontraba AS263444, aunque había otros. Incluso cuando descartamos las rutas del incidente de nuestra consideración. ¿Por qué? Un punto crítico puede seguir siendo crítico incluso para rutas correctas. Puede ser el resultado de una mala conectividad en una región o de limitaciones en nuestra propia visibilidad.
Como resultado, existe una manera de detectar a un atacante, pero solo si se cumplen todas las condiciones anteriores y solo cuando la interceptación es lo suficientemente grande como para superar los umbrales de monitoreo. Si algunos de estos factores no se cumplen, ¿podemos identificar los prefijos que sufrieron dicha interceptación? Para determinados operadores, sí.
Cuando un atacante crea una ruta más específica, el verdadero propietario no anuncia dicho prefijo. Si tiene una lista dinámica de todos sus prefijos, entonces es posible hacer una comparación y encontrar rutas más específicas distorsionadas. Recopilamos esta lista de prefijos usando nuestras sesiones BGP, porque no solo recibimos la lista completa de rutas visibles para el operador en este momento, sino también una lista de todos los prefijos que quiere anunciar al mundo. Desafortunadamente, ahora hay varias docenas de usuarios de Radar que no completan correctamente la última parte. Les notificaremos en breve e intentaremos resolver este problema. Todos los demás pueden unirse a nuestro sistema de seguimiento ahora mismo.
Si volvemos al incidente original, tanto el atacante como el área de distribución fueron detectados por nosotros buscando puntos críticos. Sorprendentemente, AS263444 no envió rutas fabricadas a todos sus clientes. Aunque hay un momento más extraño.
BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
Un ejemplo reciente de un intento de interceptar nuestro espacio de direcciones.
Cuando se crearon otros más específicos para nuestros prefijos, se utilizó un AS_PATH especialmente creado. Sin embargo, este AS_PATH no se pudo haber tomado de ninguna de nuestras rutas anteriores. Ni siquiera tenemos comunicación con AS6762. Al observar las otras rutas del incidente, algunas de ellas tenían un AS_PATH real que se había utilizado anteriormente, mientras que otras no, aunque parezca real. Cambiar AS_PATH además no tiene ningún sentido práctico, ya que el tráfico será redirigido al atacante de todos modos, pero las rutas con un AS_PATH "malo" pueden filtrarse mediante ASPA o cualquier otro mecanismo de inspección. Aquí pensamos en la motivación del secuestrador. Actualmente no tenemos suficiente información para confirmar que este incidente fue un ataque planificado. Sin embargo, es posible. Intentemos imaginar una situación, aunque todavía hipotética, pero potencialmente bastante real.
ataque perfecto
¿Que tenemos? Digamos que usted es un proveedor de tránsito que transmite rutas para sus clientes. Si tus clientes tienen presencia múltiple (multihome), entonces recibirás solo una parte de su tráfico. Pero cuanto más tráfico, mayores serán tus ingresos. Entonces, si comienza a anunciar prefijos de subred de estas mismas rutas con el mismo AS_PATH, recibirá el resto de su tráfico. Al final el resto del dinero.
¿Ayudará ROA aquí? Quizás sí, si decides dejar de usarlo por completo . Además, es muy indeseable tener registros ROA con prefijos que se cruzan. Para algunos operadores, estas restricciones son inaceptables.
Considerando otros mecanismos de seguridad de enrutamiento, ASPA tampoco ayudará en este caso (porque usa AS_PATH de una ruta válida). BGPSec todavía no es una opción óptima debido a las bajas tasas de adopción y la posibilidad restante de ataques de degradación.
Así que tenemos una clara ganancia para el atacante y una falta de seguridad. ¡Gran mezcla!
¿Qué debería hacer?
El paso obvio y más drástico es revisar su política de enrutamiento actual. Divida su espacio de direcciones en las partes más pequeñas (sin superposiciones) que desee anunciar. Firme ROA solo para ellos, sin utilizar el parámetro maxLength. En este caso, su punto de vista actual puede salvarlo de tal ataque. Sin embargo, nuevamente, para algunos operadores este enfoque no es razonable debido al uso exclusivo de rutas más específicas. Todos los problemas con el estado actual del ROA y los objetos de ruta se describirán en uno de nuestros materiales futuros.
Además, puede intentar controlar dichas interceptaciones. Para ello, necesitamos información fiable sobre sus prefijos. Por lo tanto, si establece una sesión BGP con nuestro recopilador y nos proporciona información sobre su visibilidad en Internet, podemos encontrar el margen para otras incidencias. Para aquellos que aún no están conectados a nuestro sistema de seguimiento, para empezar, una lista de rutas sólo con sus prefijos será suficiente. Si tienes una sesión con nosotros, por favor comprueba que todas tus rutas hayan sido enviadas. Desafortunadamente, vale la pena recordar esto porque algunos operadores olvidan uno o dos prefijos y, por lo tanto, interfieren con nuestros métodos de búsqueda. Si se hace correctamente, tendremos datos confiables sobre sus prefijos, que en el futuro nos ayudarán a identificar y detectar automáticamente este (y otros) tipos de intercepción de tráfico para su espacio de direcciones.
Si se da cuenta de una interceptación de su tráfico en tiempo real, puede intentar contrarrestarla usted mismo. El primer enfoque es anunciar usted mismo las rutas con estos prefijos más específicos. En caso de un nuevo ataque a estos prefijos, repetir.
El segundo enfoque es castigar al atacante y a aquellos para quienes es un punto crítico (para buenas rutas) cortando el acceso de sus rutas al atacante. Esto se puede hacer agregando el ASN del atacante al AS_PATH de sus rutas antiguas y así obligarlo a evitar ese AS usando el mecanismo de detección de bucle incorporado en BGP. .
Fuente: habr.com