El 13 de marzo, se recibió una propuesta en el grupo de trabajo de RIPE para combatir abusos en contra de esto En esta publicación, queremos mostrar un ejemplo de ataque en el que no solo el verdadero infractor estaba en la mira, sino también toda la lista de prefijos afectados. Además, este tipo de ataque vuelve a plantear preguntas sobre las motivaciones de futuras interceptaciones de tráfico de este tipo.
En los últimos años, la prensa ha informado sobre interceptaciones BGP solo en conflictos del tipo MOAS (Multiple Origin Autonomous System). MOAS es un caso particular en el que dos sistemas autónomos diferentes anuncian prefijos en conflicto con sus respectivos números ASN en AS_PATH (el primer ASN en AS_PATH, en adelante, se denomina origin ASN). Sin embargo, podemos mencionar al menos
tres tipos adicionales de Pilasova-Kapela Aquellos que buscan una versión TL;DR pueden desplazarse hasta el subtítulo "El ataque perfecto".
Antecedentes de red
(para que comprendas mejor los procesos involucrados en este incidente)
Si deseas enviar un paquete y tienes varios prefijos en la tabla de enrutamiento que contienen la dirección IP de destino, utilizarás la ruta del prefijo con la longitud máxima. Sin embargo, si hay varias rutas diferentes para un único prefijo en la tabla de enrutamiento, seleccionarás la mejor (de acuerdo con el mecanismo de selección de la mejor ruta).
Si desea enviar un paquete y tiene varios prefijos en la tabla de enrutamiento que contienen la dirección IP de destino, utilizará la ruta del prefijo con la longitud máxima. Si hay varias rutas diferentes para un mismo prefijo en la tabla de enrutamiento, elegirá la mejor (de acuerdo con el mecanismo de selección del mejor camino).
Los enfoques existentes para la filtración y el monitoreo intentan analizar las rutas y tomar decisiones analizando el atributo AS_PATH. Un enrutador puede cambiar este atributo a cualquier valor durante el anuncio. Simplemente agregar el ASN del propietario al comienzo de AS_PATH (como ASN de origen) puede ser suficiente para eludir los mecanismos actuales de verificación de origen. Además, si existe una ruta desde el ASN atacado hasta usted, hay una posibilidad de extraer y utilizar AS_PATH de esa ruta en otros de sus anuncios. Cualquier verificación de autenticidad solo de AS_PATH para sus anuncios maliciosos eventualmente será superada.
También hay algunas limitaciones dignas de mención. En primer lugar, en el caso de la filtración de prefijos por parte de un proveedor superior, su ruta aún puede ser filtrada (incluso con un AS_PATH correcto), si el prefijo no pertenece a su cono de clientes configurado con el upstream. En segundo lugar, un AS_PATH válido puede volverse inválido si la ruta creada se anuncia en direcciones incorrectas y, por lo tanto, viola la política de enrutamiento. Y por último, cualquier ruta con un prefijo que viole la longitud de ROA puede considerarse inválida.
Incidente
Hace unas semanas recibimos una queja de uno de los usuarios. Vimos rutas con su ASN de origen y prefijos /25, mientras que el usuario afirmaba que no los anunció.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
Ejemplos de anuncios a principios de abril de 2019
NTT en el camino para el prefijo /25 lo hace especialmente sospechoso. Durante el incidente, LG NTT no sabía nada sobre esta ruta. Así que sí, algún operador está creando todo un AS_PATH para estos prefijos. La verificación en otros enrutadores revela un ASN especial: AS263444. Al observar 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é está mal aquí
Parece que alguien tomó un prefijo de una ruta, lo dividió en dos partes y anunció una ruta con el mismo AS_PATH para estos 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||
Ejemplos de rutas para uno de los pares de prefijos divididos
Surgen varias preguntas. ¿Realmente alguien ha intentado en la práctica este tipo de intercepción? ¿Alguien ha aceptado estas rutas? ¿Qué prefijos fueron afectados?
Aquí es donde comienza nuestra serie de fracasos y otro round de decepción en el estado actual de salud de Internet.
El camino de los fracasos
Todo en orden. ¿Cómo podemos determinar qué enrutadores han aceptado rutas interceptadas y de quién puede redirigirse el tráfico ya hoy? Pensamos en comenzar con prefijos /25, porque «simplemente no pueden tener distribución global». Como puedes imaginar, nos equivocamos gravemente. Esta métrica resultó estar demasiado ruidosa y las rutas con tales prefijos pueden aparecer incluso de operadores de nivel 1. Por ejemplo, NTT tiene alrededor de 50 de esos prefijos que distribuye entre sus propios clientes. Por otro lado, esta métrica es mala porque tales prefijos pueden ser filtrados si el operador aplica , en todas las direcciones. Por lo tanto, este método no es útil para encontrar todos los operadores cuyo tráfico se ha redirigido como resultado de un incidente similar.
Otra buena idea que se nos ocurrió fue mirar . En particular, en rutas que violan la regla de maxLength del ROA correspondiente. De esta manera, podríamos encontrar la cantidad de diferentes ASN de origen con estado inválido que fueron visibles para este AS. Sin embargo, hay un «pequeño» problema. El valor medio (mediana y moda) de este número (la cantidad de diferentes ASN de origen) es de alrededor de 150 y, incluso si filtramos los pequeños prefijos, seguirá siendo superior a 70. Esta situación tiene una explicación bastante simple: solo hay unos pocos operadores que ya aplican filtros ROA con una política de “descartar rutas inválidas” en los puntos de entrada, por lo que dondequiera que en el mundo real aparezca una ruta que viole el ROA, puede propagarse en todas las direcciones.
Los últimos dos enfoques permiten identificar a los operadores que han visto nuestro incidente (ya que fue lo suficientemente grande), pero en general son inaplicables. Bien, pero ¿podemos encontrar al atacante? ¿Cuáles son las características generales de tal manipulación de AS_PATH? Hay algunas suposiciones básicas:
- El prefijo no se había visto anteriormente en ningún lugar;
- 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 compruebe el ASN del vecino en todas las rutas entrantes);
- El ataque proviene de un solo proveedor.
Si todas las suposiciones son correctas, entonces en todas las rutas incorrectas se presentará 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 hubo otros. Incluso cuando descartamos las rutas del incidente. ¿Por qué? Un punto crítico puede seguir siendo crítico incluso para rutas correctas. Puede ser el resultado de una mala conectividad en alguna región, o de las limitaciones de nuestra propia visibilidad.
Como resultado: hay una forma de detectar al atacante, pero solo si se cumplen todas las condiciones mencionadas anteriormente y solo cuando la intercepción es lo suficientemente grande como para pasar los umbrales de monitoreo. Si alguno de estos factores no se cumple, ¿podemos identificar los prefijos afectados por dicha intercepción? Para ciertos operadores, sí.
Cuando el atacante crea una ruta más específica, ese prefijo no es anunciado por el verdadero propietario. En caso de que tenga una lista dinámica de todos sus prefijos, se presenta la oportunidad de comparar y encontrar rutas más específicas distorsionadas. Recopilamos esta lista de prefijos a través de nuestras sesiones BGP, ya que se nos envía no solo la lista completa de rutas visibles por el operador en este momento, sino también la lista de todos los prefijos que desea anunciar al mundo. Desafortunadamente, actualmente hay varios usuarios de Radar que no ejecutan esta última parte de manera completamente correcta. En breve, les informaremos y trataremos de resolver este problema. Todos los demás pueden unirse a nuestro sistema de monitoreo ahora mismo.
Si regresamos al incidente inicial, tanto el atacante como el área de difusión fueron detectados por nosotros mediante la búsqueda de puntos críticos. Es sorprendente, pero AS263444 enviaba rutas falsificadas a no todos sus clientes. Aunque hay un aspecto aún 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 secuestro de nuestro espacio de direcciones.
Cuando se crearon los more specific para nuestros prefijos, se utilizó un AS_PATH creado específicamente. Sin embargo, este AS_PATH no podía ser tomado de ninguna de nuestras rutas anteriores. Ni siquiera tenemos conexión con AS6762. Observando otras rutas en el incidente: algunas de ellas tenían un AS_PATH real que se había utilizado anteriormente, mientras que otras no, incluso si parecían reales. Cambiar AS_PATH no tiene ningún sentido práctico, ya que de todas maneras el tráfico será redirigido al atacante, pero las rutas con un AS_PATH 'malo' pueden ser filtradas por ASPA o cualquier otro mecanismo de verificación. Aquí nos preguntamos sobre la motivación del secuestrador. Ahora mismo nos faltan datos para afirmar que este incidente fue un ataque planeado. Sin embargo, es posible. Intentemos imaginar al menos una situación hipotética, pero potencialmente bastante real.
Ataque ideal
¿Qué tenemos? Supongamos que usted es un proveedor de tránsito, transmitiendo rutas para sus clientes. Si sus clientes tienen presencia múltiple (multihome), solo obtendrá una parte de su tráfico. Pero cuanto mayor sea el tráfico, mayor será su ingreso. Por lo tanto, si comienza a anunciar los prefijos de subredes de estas mismas rutas con el mismo AS_PATH, obtendrá el resto de su tráfico. Como consecuencia, el resto del dinero.
¿Ayudará aquí ROA? Posiblemente, sí, si decide renunciar por completo al uso . Además, es extremadamente indeseable tener registros ROA con prefijos que se superponen. Para algunos operadores, tales restricciones son inaceptables.
Al considerar otros mecanismos de seguridad de enrutamiento, en este caso ASPA tampoco ayudará (porque se utiliza un AS_PATH de una ruta permitida). BGPSec sigue siendo una opción no óptima debido al bajo porcentaje de adopción y a la posibilidad de ataques de degradación que persiste.
Por lo tanto, tenemos una clara ganancia para el atacante y una falta de seguridad. ¡Una combinación excelente!
¿Qué se debe hacer?
El paso más obvio y radical 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 el ROA solo para ellos, sin usar el parámetro maxLength. En este caso, el POV actual podría salvarlo de un ataque similar. Sin embargo, nuevamente, para algunos operadores, este enfoque no es razonable debido al uso exclusivo de rutas más específicas. Todos los problemas del estado actual del ROA y los objetos de ruta se describirán en uno de nuestros futuros materiales.
Además, se puede intentar monitorear tales interceptaciones. Para ello, necesitamos información confiable sobre sus prefijos. De esta manera, si establece una sesión BGP con nuestro colector y nos proporciona información sobre su visibilidad en Internet, podemos encontrar el alcance de la propagación y de otros incidentes. Para aquellos que aún no están conectados a nuestro sistema de monitoreo, inicialmente solo necesitaremos una lista de rutas con sus propios prefijos. Si ya tiene una sesión con nosotros, por favor verifique que se hayan enviado todas sus rutas. Desafortunadamente, es un tema que vale la pena recordar, ya que algunos operadores olvidan uno o dos prefijos y, de este modo, crean interferencias en nuestros métodos de búsqueda. Si todo se hace correctamente, tendremos datos confiables sobre sus prefijos, que ayudarán a identificar y detectar automáticamente tal (y otros) tipos de interceptaciones de tráfico para su espacio de direcciones en el futuro.
Si se entera en tiempo real de tal interceptación de su tráfico, puede intentar contrarrestarlo usted mismo. El primer enfoque es anunciar las rutas con esos prefijos más específicos por su cuenta. En caso de un nuevo ataque a estos prefijos, repítalo.
El segundo enfoque es castigar al atacante y a aquellos que son un punto crítico para él (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, de este modo, obligarlos a evitar ese AS, utilizando el mecanismo incorporado de detección de bucles en BGP. .
Fuente: habr.com
