{"id":31415,"date":"2019-10-31T21:41:08","date_gmt":"2019-10-31T18:41:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vse-ochen-ploho-ili-novyj-vid-perehvata-trafika\/"},"modified":"2019-10-31T21:41:08","modified_gmt":"2019-10-31T18:41:08","slug":"vse-ochen-ploho-ili-novyj-vid-perehvata-trafika","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/vse-ochen-ploho-ili-novyj-vid-perehvata-trafika","title":{"rendered":"Todo est\u00e1 muy mal o un nuevo tipo de interceptaci\u00f3n de tr\u00e1fico","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

El 13 de marzo, se recibi\u00f3 una propuesta en el grupo de trabajo de RIPE para combatir abusos para considerar la interceptaci\u00f3n BGP (hjjack) como una violaci\u00f3n de la pol\u00edtica de RIPE. En caso de que se acepte la propuesta, el proveedor de internet atacado mediante interceptaci\u00f3n de tr\u00e1fico tendr\u00eda la opci\u00f3n de enviar una solicitud especial para exponer al infractor. Si el grupo de expertos recopila suficientes pruebas que lo confirmen, dicho LIR, que es la fuente de la interceptaci\u00f3n BGP, ser\u00eda considerado un infractor y podr\u00eda perder su estatus de LIR. Tambi\u00e9n hubo algunos argumentos<\/a><\/noindex> en contra de esto .<\/a><\/noindex> En esta publicaci\u00f3n, queremos mostrar un ejemplo de ataque en el que no solo el verdadero infractor estaba en la mira, sino tambi\u00e9n toda la lista de prefijos afectados. Adem\u00e1s, este tipo de ataque vuelve a plantear preguntas sobre las motivaciones de futuras interceptaciones de tr\u00e1fico de este tipo.<\/p>\n

En los \u00faltimos a\u00f1os, 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\u00f3nomos diferentes anuncian prefijos en conflicto con sus respectivos n\u00fameros ASN en AS_PATH (el primer ASN en AS_PATH, en adelante, se denomina origin ASN). Sin embargo, podemos mencionar al menos
\n<\/a><\/noindex>
\ntres tipos adicionales de interceptaci\u00f3n de tr\u00e1fico, que permiten a un atacante manipular el atributo AS_PATH con diferentes fines, incluyendo eludir enfoques modernos de filtrado y monitoreo. Un conocido tipo de ataque<\/a><\/noindex> de Pilasova-Kapela es el \u00faltimo tipo de interceptaci\u00f3n, aunque no menos importante. Es bastante posible que hayamos estado observando exactamente este tipo de ataque en las \u00faltimas semanas. Este evento es explicable y tiene consecuencias bastante serias.<\/a><\/noindex> Aquellos que buscan una versi\u00f3n TL;DR pueden desplazarse hasta el subt\u00edtulo \"El ataque perfecto\".<\/p>\n

Antecedentes de red<\/p>\n

(para que comprendas mejor los procesos involucrados en este incidente)<\/h3>\n

Si deseas enviar un paquete y tienes varios prefijos en la tabla de enrutamiento que contienen la direcci\u00f3n IP de destino, utilizar\u00e1s la ruta del prefijo con la longitud m\u00e1xima. Sin embargo, si hay varias rutas diferentes para un \u00fanico prefijo en la tabla de enrutamiento, seleccionar\u00e1s la mejor (de acuerdo con el mecanismo de selecci\u00f3n de la mejor ruta).<\/i><\/p>\n

Si desea enviar un paquete y tiene varios prefijos en la tabla de enrutamiento que contienen la direcci\u00f3n IP de destino, utilizar\u00e1 la ruta del prefijo con la longitud m\u00e1xima. Si hay varias rutas diferentes para un mismo prefijo en la tabla de enrutamiento, elegir\u00e1 la mejor (de acuerdo con el mecanismo de selecci\u00f3n del mejor camino).<\/p>\n

Los enfoques existentes para la filtraci\u00f3n 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\u00f3n de origen. Adem\u00e1s, 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\u00f3n de autenticidad solo de AS_PATH para sus anuncios maliciosos eventualmente ser\u00e1 superada.<\/p>\n

Tambi\u00e9n hay algunas limitaciones dignas de menci\u00f3n. En primer lugar, en el caso de la filtraci\u00f3n de prefijos por parte de un proveedor superior, su ruta a\u00fan 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\u00e1lido puede volverse inv\u00e1lido si la ruta creada se anuncia en direcciones incorrectas y, por lo tanto, viola la pol\u00edtica de enrutamiento. Y por \u00faltimo, cualquier ruta con un prefijo que viole la longitud de ROA puede considerarse inv\u00e1lida.<\/p>\n

Incidente<\/h3>\n

\nHace 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\u00f3.<\/p>\n

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0\/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128\/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128\/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0\/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128\/25|265466 262761 263444 6762 2914 9121|INCOMPLETO|xxx|0|0||NAG||<\/code>
\nEjemplos de anuncios a principios de abril de 2019<\/i><\/p>\n

NTT en el camino para el prefijo \/25 lo hace especialmente sospechoso. Durante el incidente, LG NTT no sab\u00eda nada sobre esta ruta. As\u00ed que s\u00ed, alg\u00fan operador est\u00e1 creando todo un AS_PATH para estos prefijos. La verificaci\u00f3n en otros enrutadores revela un ASN especial: AS263444. Al observar otras rutas con este sistema aut\u00f3nomo, nos encontramos con la siguiente situaci\u00f3n:<\/p>\n

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0\/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128\/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0\/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0\/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0\/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||<\/code>
\nIntenta adivinar qu\u00e9 est\u00e1 mal aqu\u00ed<\/i><\/p>\n

Parece que alguien tom\u00f3 un prefijo de una ruta, lo dividi\u00f3 en dos partes y anunci\u00f3 una ruta con el mismo AS_PATH para estos dos prefijos.<\/p>\n

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||
\nTABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0\/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
\nTABLE_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||
\nTABLE_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||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0\/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0\/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
\nTABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0\/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||<\/code>
\nEjemplos de rutas para uno de los pares de prefijos divididos<\/i><\/p>\n

Surgen varias preguntas. \u00bfRealmente alguien ha intentado en la pr\u00e1ctica este tipo de intercepci\u00f3n? \u00bfAlguien ha aceptado estas rutas? \u00bfQu\u00e9 prefijos fueron afectados?<\/p>\n

Aqu\u00ed es donde comienza nuestra serie de fracasos y otro round de decepci\u00f3n en el estado actual de salud de Internet.<\/p>\n

El camino de los fracasos<\/h3>\n

\nTodo en orden. \u00bfC\u00f3mo podemos determinar qu\u00e9 enrutadores han aceptado rutas interceptadas y de qui\u00e9n puede redirigirse el tr\u00e1fico ya hoy? Pensamos en comenzar con prefijos \/25, porque \u00absimplemente no pueden tener distribuci\u00f3n global\u00bb. Como puedes imaginar, nos equivocamos gravemente. Esta m\u00e9trica result\u00f3 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\u00e9trica es mala porque tales prefijos pueden ser filtrados si el operador aplica filtraci\u00f3n de prefijos peque\u00f1os<\/a><\/noindex>, en todas las direcciones. Por lo tanto, este m\u00e9todo no es \u00fatil para encontrar todos los operadores cuyo tr\u00e1fico se ha redirigido como resultado de un incidente similar.<\/p>\n

Otra buena idea que se nos ocurri\u00f3 fue mirar POV<\/a><\/noindex>. En particular, en rutas que violan la regla de maxLength del ROA correspondiente. De esta manera, podr\u00edamos encontrar la cantidad de diferentes ASN de origen con estado inv\u00e1lido que fueron visibles para este AS. Sin embargo, hay un \u00abpeque\u00f1o\u00bb problema. El valor medio (mediana y moda) de este n\u00famero (la cantidad de diferentes ASN de origen) es de alrededor de 150 y, incluso si filtramos los peque\u00f1os prefijos, seguir\u00e1 siendo superior a 70. Esta situaci\u00f3n tiene una explicaci\u00f3n bastante simple: solo hay unos pocos operadores que ya aplican filtros ROA con una pol\u00edtica de \u201cdescartar rutas inv\u00e1lidas\u201d 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.<\/p>\n

Los \u00faltimos 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 \u00bfpodemos encontrar al atacante? \u00bfCu\u00e1les son las caracter\u00edsticas generales de tal manipulaci\u00f3n de AS_PATH? Hay algunas suposiciones b\u00e1sicas:<\/p>\n