Todo es muy malo o un nuevo tipo de intercepción de tráfico.

El 13 de marzo, el Grupo de trabajo contra el abuso de RIPE recibió una propuesta para considerar el secuestro como una violación de la política de RIPE. Si se aceptara la oferta, el proveedor de Internet atacado interceptando el tráfico podría enviar una solicitud especial para llevar al atacante al agua potable. Si el grupo de expertos recolecta suficiente evidencia de respaldo, entonces dicho LIR, que es la fuente de la intercepción de BGP, se consideraría un intruso y podría verse privado del estado de LIR. Hubo algunos argumentos en contra de este cambio.

En esta publicación, queremos mostrar un ejemplo de un ataque cuando no solo el verdadero atacante tenía dudas, sino toda la lista de prefijos afectados. Además, tal ataque nuevamente plantea preguntas sobre los motivos para futuras intercepciones de este tipo de tráfico.

En los últimos años, solo los conflictos como el MOAS (Sistema Autónomo de Origen Múltiple) se han reportado en la prensa como intercepta BGP. MOAS es un caso especial cuando dos sistemas autónomos diferentes anuncian prefijos en conflicto con los números ASN correspondientes en AS_PATH (el primer ASN en AS_PATH, en lo sucesivo denominado ASN de origen). Sin embargo, podemos nombrar al menos 3 tipos adicionales de intercepción de tráfico que permiten a un atacante manipular el atributo AS_PATH para diferentes propósitos, incluso para eludir los enfoques modernos de filtrado y monitoreo. El tipo conocido de ataque de Pilosov-Kapela es el último tipo de intercepción, pero no tiene importancia. Es posible que este sea precisamente el ataque que hemos observado en las últimas semanas. Tal evento tiene un carácter comprensible y consecuencias bastante serias.

Aquellos que buscan una versión TL; DR pueden desplazarse al subtítulo "Perfect Attack".

Fondo de la red

(para que comprenda 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áxima. Si en la tabla de enrutamiento hay varias rutas diferentes para un prefijo, elegirá la mejor (de acuerdo con el mecanismo para elegir la mejor 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 el anuncio. Solo agregar el ASN de propietario al comienzo de AS_PATH (como ASN de origen) puede ser suficiente para omitir los mecanismos de verificación de fuente actuales. Además, si hay una ruta desde el ASN atacado hacia usted, es posible extraer y usar el AS_PATH de esta ruta en sus otros anuncios. Cualquier validación de solo AS_PATH para sus anuncios diseñados será eventualmente aprobada.

Hay varias limitaciones notables. En primer lugar, en caso de que un proveedor superior filtre prefijos, su ruta aún se puede filtrar (incluso con el AS_PATH correcto) si el prefijo no pertenece a su cono de cliente configurado en sentido ascendente. En segundo lugar, un AS_PATH válido puede volverse inválido si la ruta creada se anuncia en las direcciones incorrectas y, por lo tanto, viola la política de enrutamiento. Y lo último: cualquier ruta con un prefijo que viole la longitud del ROA puede considerarse inválida.

Incidente

Hace unas semanas, recibimos una queja de uno de los usuarios. Vimos rutas con su origen ASN y / 25 prefijos, mientras que el usuario afirmó que no las había anunciado.

^{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 a principios de abril de 2019

NTT en tránsito para el prefijo / 25 lo hace particularmente sospechoso. Durante el incidente, el LG NTT no sabía nada sobre esta ruta. Entonces, sí, ¡algún tipo de operador crea un AS_PATH completo para estos prefijos! Las pruebas en otros enrutadores le permiten resaltar 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é 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 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 a la vez. ¿Alguien ha intentado realmente este tipo de intercepción en la práctica? ¿Alguien ha tomado estas rutas? ¿Qué prefijos se vieron afectados?

Aquí es donde comienza nuestra serie de fallas y otra ronda de decepción en la salud actual de Internet.

El camino del fracaso

Lo primero es lo primero. ¿Cómo podemos determinar qué enrutadores han aceptado esas rutas interceptadas y qué tráfico se puede redirigir hoy? Pensamos comenzar con los prefijos / 25, porque "simplemente no pueden tener una distribución global". Como puedes adivinar, estábamos muy equivocados. Esta métrica era demasiado ruidosa y las rutas con dichos prefijos pueden aparecer incluso desde operadores de nivel 1. Por ejemplo, NTT tiene alrededor de 50 prefijos que distribuye entre sus propios clientes. Por otro lado, esta métrica es mala, porque dichos prefijos se pueden filtrar si el operador aplica el filtrado de pequeños prefijos en todas las direcciones. Por lo tanto, este método no es adecuado para buscar todos los operadores cuyo tráfico fue redirigido como resultado de tal incidente.

Otra buena idea que pensamos fue mirar POV . Especialmente en rutas que violan la regla maxLength del ROA correspondiente. Por lo tanto, podríamos encontrar el número de diferentes ASN de origen con estado inválido que eran visibles para este AS. Sin embargo, hay un problema "pequeño". El valor promedio (mediana y moda) de este número (el número de ASN de origen diferente) es de aproximadamente 150 e incluso si filtramos pequeños prefijos, se mantendrá por encima de 70. Esta situación tiene una explicación muy simple: solo hay unos pocos operadores que ya utilizan ROA- se filtra con la política de "restablecer rutas no válidas" en los puntos de entrada, por lo que siempre que aparezca una ruta con una infracción de ROA en el mundo real, puede extenderse en todas las direcciones.

Los dos últimos enfoques nos permiten encontrar los operadores que vieron nuestro incidente (ya que era bastante grande), pero en general no son aplicables. Ok, pero ¿podemos encontrar al atacante? ¿Cuáles son las características comunes de tal manipulación AS_PATH? Hay varios supuestos básicos:

• El prefijo no se ha visto en ninguna parte antes;
• 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 (si su vecino verifica el ASN del vecino en todas las rutas entrantes);
• El ataque proviene de un proveedor.

Si todas las suposiciones son correctas, en todas las rutas incorrectas se presentará el ASN del atacante (excepto el origen de ASN) y, por lo tanto, este es un punto "crítico". Entre los verdaderos secuestradores estaba AS263444, aunque había otros. Incluso cuando dejamos de considerar las rutas del incidente. Por qué Un punto crítico puede seguir siendo crítico incluso para las rutas correctas. Puede ser el resultado de una conectividad deficiente en cualquier región o las limitaciones de nuestra propia visibilidad.

Como resultado: hay una manera de detectar a un atacante, pero solo si se cumplen todas las condiciones anteriores y solo cuando la intercepción es lo suficientemente grande como para pasar los umbrales de monitoreo. Si alguno de estos factores no se respeta, ¿podemos señalar los prefijos afectados por tal intercepción? Para ciertos 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, puede hacer una comparación y encontrar rutas más específicas distorsionadas. Recopilamos esta lista de prefijos utilizando nuestras sesiones BGP, ya que no solo se nos da una 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 la última parte correctamente. En un futuro cercano les notificaremos e intentaremos resolver este problema. Todos los demás pueden unirse a nuestro sistema de monitoreo ahora mismo.

Si volvemos al incidente original, descubrimos el atacante y el área de distribución 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 más específicos para nuestros prefijos, se utilizó el AS_PATH creado especialmente. Sin embargo, este AS_PATH no se pudo tomar de ninguna de nuestras rutas anteriores. Ni siquiera tenemos una conexión con AS6762. Observamos otras rutas en el incidente: algunas de ellas tenían un AS_PATH real, que se utilizó anteriormente, mientras que otras no, incluso si parecen reales. Un cambio adicional a AS_PATH no tiene ningún sentido práctico, ya que en cualquier caso el tráfico se redirigirá al atacante, pero ASPA o cualquier otro mecanismo de verificación pueden filtrar las rutas con un AS_PATH "malo". Aquí pensamos en la motivación del secuestrador. Ahora no tenemos suficientes datos para afirmar que este incidente fue un ataque planificado. Sin embargo, es posible. Tratemos de imaginar una situación hipotética, pero potencialmente bastante real.

Ataque perfecto

Que tenemos Suponga que es un proveedor de tránsito que transmite rutas para sus clientes. Si sus clientes tienen presencia múltiple (hogar múltiple), recibirá solo una parte de su tráfico. Pero cuanto más tráfico, mayores serán sus ingresos. Por lo tanto, si comienza a anunciar prefijos de subred de las mismas rutas con el mismo AS_PATH, recibirá el resto del tráfico. Como resultado, el resto del dinero.

¿ROA ayudará aquí? Quizás sí, si decide abandonar por completo el uso de maxLength . Además, es altamente indeseable tener entradas de ROA con prefijos de intersección. Para algunos operadores, tales restricciones son inaceptables.

Considerando otros mecanismos de seguridad de enrutamiento, ASPA tampoco ayudará en este caso (porque AS_PATH se usa desde una ruta válida). BGPSec todavía no es la mejor opción debido a la baja tasa de aceptación y la posibilidad restante de ataques de degradación.

Por lo tanto, tenemos un beneficio claro para el atacante y una falta de seguridad. Gran mezcla!

Que hacer

El paso obvio y más radical es revisar su política de enrutamiento actual. Divide tu espacio de direcciones en las piezas más pequeñas (sin intersecciones) que solo deseas anunciar. Firme los ROA solo para ellos, sin usar el parámetro maxLength. En este caso, el POV actual puede salvarte 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 del estado actual de ROA y los objetos de ruta se describirán en uno de nuestros materiales futuros.

Además, puede intentar controlar tales intercepciones. Para hacer esto, necesitamos información confiable sobre sus prefijos. Por lo tanto, si establece una sesión de BGP con nuestro recolector y nos brinda información sobre su visibilidad de Internet, también podemos encontrar el área de distribución para otros incidentes. Para aquellos que aún no están conectados a nuestro sistema de monitoreo, para empezar, una lista de rutas con solo sus prefijos será suficiente para nosotros. Si tiene una sesión con nosotros, compruebe que se hayan enviado todas sus rutas. Desafortunadamente, vale la pena recordar esto, ya que algunos operadores olvidan uno o dos prefijos y, por lo tanto, interfieren con nuestros métodos de búsqueda. Si todo se hace correctamente, tendremos datos confiables sobre sus prefijos, lo que en el futuro ayudará a detectar y detectar automáticamente tales (y otros) tipos de intercepción de tráfico para su espacio de direcciones.

Si se entera en tiempo real de tal intercepción de su tráfico, puede intentar contrarrestarlo usted mismo. El primer enfoque es anunciar rutas con estos prefijos más específicos usted mismo. En caso de un nuevo ataque a estos prefijos, repita.

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 haciendo que eviten este AS utilizando el mecanismo de detección de bucle incorporado en BGP para su propio beneficio .