13 de marzo ao grupo de traballo contra o abuso RIPE considerar o secuestro de BGP (hjjack) como unha violación da política RIPE. Se a proposta fose aceptada, o provedor de Internet atacado pola interceptación do tráfico tería a oportunidade de enviar unha solicitude especial para expor ao atacante. Se o equipo de revisión recollese suficientes probas de apoio, o LIR que foi a fonte da intercepción BGP sería considerado un intruso e podería ser desposuído do seu estado LIR. Tamén houbo algúns argumentos cambios.
Nesta publicación queremos mostrar un exemplo de ataque onde non só se trataba do atacante real, senón tamén de toda a lista de prefixos afectados. Ademais, tal ataque volve suscitar dúbidas sobre os motivos das futuras interceptacións deste tipo de tráfico.
Durante os últimos dous anos, só conflitos como o MOAS (Sistema Autónomo de Origen Múltiple) foron tratados na prensa como interceptacións BGP. MOAS é un caso especial no que dous sistemas autónomos diferentes anuncian prefixos en conflito cos ASN correspondentes en AS_PATH (o primeiro ASN en AS_PATH, en diante denominado ASN de orixe). Non obstante, podemos nomear polo menos interceptación de tráfico, permitindo que un atacante manipule o atributo AS_PATH para varios propósitos, incluído omitir os enfoques modernos de filtrado e vixilancia. Tipo de ataque coñecido - o último tipo de interceptación, pero nada en importancia. É moi posible que este sexa exactamente o tipo de ataque que vimos nas últimas semanas. Tal evento ten unha natureza comprensible e consecuencias bastante graves.
Aqueles que busquen a versión TL;DR poden desprazarse ata o subtítulo "Perfect Attack".
Fondo de rede
(para axudarche a comprender mellor os procesos implicados neste incidente)
Se queres enviar un paquete e tes varios prefixos na táboa de enrutamento que contén o enderezo IP de destino, empregarás a ruta para o prefixo de maior lonxitude. Se hai varias rutas diferentes para o mesmo prefixo na táboa de encamiñamento, escollerá a mellor (segundo o mecanismo de selección de mellor ruta).
Os enfoques de filtrado e seguimento existentes tentan analizar rutas e tomar decisións mediante a análise do atributo AS_PATH. O router pode cambiar este atributo a calquera valor durante a publicidade. Simplemente engadir o ASN do propietario ao comezo de AS_PATH (como ASN de orixe) pode ser suficiente para evitar os mecanismos actuais de verificación de orixe. Ademais, se hai unha ruta desde o ASN atacado ata ti, faise posible extraer e utilizar o AS_PATH desta ruta nos teus outros anuncios. Calquera comprobación de validación só de AS_PATH para os teus anuncios elaborados finalmente pasará.
Aínda hai algunhas limitacións que merecen mención. En primeiro lugar, en caso de filtrado de prefixos por parte do provedor ascendente, a túa ruta aínda se pode filtrar (mesmo co AS_PATH correcto) se o prefixo non pertence ao teu cono de cliente configurado na parte superior. En segundo lugar, un AS_PATH válido pode ser inválido se a ruta creada se anuncia en direccións incorrectas e, polo tanto, infrinxe a política de rutas. Por último, calquera ruta cun prefixo que infrinxa a lonxitude do ROA pode considerarse non válida.
Incidente
Hai unhas semanas recibimos unha queixa dun dos nosos usuarios. Vimos rutas cos seus prefixos ASN de orixe e /25, mentres que o usuario afirmou que non as publicou.
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||
Exemplos de anuncios para principios de abril de 2019
NTT no camiño para o prefixo /25 fai que sexa especialmente sospeitoso. LG NTT descoñecía esta ruta no momento do incidente. Entón, si, algún operador crea un AS_PATH completo para estes prefixos. A comprobación doutros enrutadores revela un ASN particular: AS263444. Despois de analizar outras rutas con este sistema autónomo, atopámonos coa seguinte 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||
Tenta adiviñar o que está mal aquí
Parece que alguén tomou o prefixo da ruta, dividiuno en dúas partes e anunciou a ruta co mesmo AS_PATH para eses dous prefixos.
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||
Exemplos de rutas para un dos pares de prefixos divididos
Varias preguntas xorden á vez. Alguén tentou realmente este tipo de interceptación na práctica? Alguén fixo estas rutas? Que prefixos foron afectados?
Aquí é onde comeza a nosa serie de fallos e unha nova rolda de decepción co estado actual da saúde de Internet.
O camiño do fracaso
Primeiro primeiro. Como podemos determinar que routers aceptaron tales rutas interceptadas e cuxo tráfico podería desviarse hoxe? Pensamos comezar con /25 prefixos porque "simplemente non poden ter distribución global". Como podes supoñer, estabamos moi equivocados. Esta métrica resultou ser demasiado ruidosa e as rutas con tales prefixos poden aparecer mesmo dos operadores de nivel 1. Por exemplo, NTT ten uns 50 prefixos deste tipo, que distribúe aos seus propios clientes. Por outra banda, esta métrica é mala porque estes prefixos pódense filtrar se o operador utiliza , en todas as direccións. Polo tanto, este método non é adecuado para atopar todos os operadores cuxo tráfico foi redirixido como resultado de tal incidente.
Outra boa idea que pensamos foi mirar . Especialmente para rutas que infrinxen a regra maxLength do ROA correspondente. Deste xeito poderiamos atopar o número de ASN de orixe diferentes con estado Inválido que eran visibles para un determinado AS. Non obstante, hai un "pequeno" problema. A media (media e moda) deste número (o número de ASN de orixe diferente) é duns 150 e, aínda que filtremos pequenos prefixos, mantense por encima dos 70. Este estado de cousas ten unha explicación moi sinxela: só hai un poucos operadores que xa usan filtros de ROA cunha política de "reiniciar rutas non válidas" nos puntos de entrada, de xeito que sempre que apareza unha ruta cunha infracción do ROA no mundo real, pode propagarse en todas as direccións.
Os dous últimos enfoques permítennos atopar operadores que viron o noso incidente (xa que foi bastante grande), pero en xeral non son aplicables. Está ben, pero podemos atopar o intruso? Cales son as características xerais desta manipulación AS_PATH? Hai algunhas suposicións básicas:
- O prefixo non fora visto por ningures antes;
- ASN de orixe (recordatorio: primeiro ASN en AS_PATH) é válido;
- O último ASN en AS_PATH é o ASN do atacante (no caso de que o seu veciño comprobe o ASN do veciño en todas as rutas de entrada);
- O ataque orixínase dun único provedor.
Se todas as suposicións son correctas, entón todas as rutas incorrectas presentarán o ASN do atacante (excepto o ASN de orixe) e, polo tanto, este é un punto "crítico". Entre os verdadeiros secuestradores estaba AS263444, aínda que houbo outros. Mesmo cando descartamos as rutas do incidente da consideración. Por que? Un punto crítico pode seguir sendo crítico mesmo para as rutas correctas. Pode ser o resultado dunha mala conectividade nunha rexión ou de limitacións na nosa propia visibilidade.
Como resultado, hai unha forma de detectar un atacante, pero só se se cumpren todas as condicións anteriores e só cando a interceptación é o suficientemente grande como para superar os limiares de vixilancia. Se non se cumpren algúns destes factores, podemos identificar os prefixos que sufriron tal interceptación? Para certos operadores - si.
Cando un atacante crea unha ruta máis específica, tal prefixo non é anunciado polo verdadeiro propietario. Se tes unha lista dinámica de todos os seus prefixos, é posible facer unha comparación e atopar rutas máis específicas distorsionadas. Recollemos esta lista de prefixos usando as nosas sesións BGP, porque non só se nos dá a lista completa de rutas visibles para o operador agora mesmo, senón tamén unha lista de todos os prefixos que quere anunciar para o mundo. Desafortunadamente, agora hai varias ducias de usuarios de Radar que non completan correctamente a última parte. Notificarémolos en breve e tentaremos resolver este problema. Todos os demais poden unirse ao noso sistema de vixilancia agora mesmo.
Se volvemos ao incidente orixinal, tanto o atacante como a área de distribución foron detectados por nós buscando puntos críticos. Sorprendentemente, AS263444 non enviou rutas fabricadas a todos os seus clientes. Aínda que hai un momento estrañ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 exemplo recente dun intento de interceptar o noso espazo de enderezos
Cando se crearon outros máis específicos para os nosos prefixos, utilizouse un AS_PATH especialmente creado. Non obstante, este AS_PATH non puido ser tomado de ningunha das nosas rutas anteriores. Nin sequera temos comunicación con AS6762. Mirando as outras rutas do incidente, algunhas delas tiñan un AS_PATH real que se usaba anteriormente, mentres que outras non, aínda que pareza a real. Cambiar AS_PATH ademais non ten ningún sentido práctico, xa que o tráfico será redirixido ao atacante de todos os xeitos, pero as rutas cun AS_PATH "malo" pódense filtrar mediante ASPA ou calquera outro mecanismo de inspección. Aquí pensamos na motivación do secuestrador. Actualmente non temos información suficiente para confirmar que este incidente foi un ataque planificado. Con todo, é posible. Intentemos imaxinar, aínda que aínda hipotética, pero potencialmente bastante real, unha situación.
Ataque perfecto
Que temos? Digamos que es un provedor de transporte público que transmite rutas para os teus clientes. Se os teus clientes teñen presenza múltiple (multihome), entón só recibirás unha parte do seu tráfico. Pero canto máis tráfico, máis ingresos. Polo tanto, se comezas a anunciar prefixos de subrede destas mesmas rutas co mesmo AS_PATH, recibirás o resto do seu tráfico. Como resultado, o resto do diñeiro.
Axudará a ROA aquí? Quizais si, se decides deixar de usalo por completo . Ademais, é moi indesexable ter rexistros de ROA con prefixos que se cruzan. Para algúns operadores, tales restricións son inaceptables.
Tendo en conta outros mecanismos de seguridade de enrutamento, ASPA tampouco axudará neste caso (porque utiliza AS_PATH desde unha ruta válida). BGPSec aínda non é unha opción óptima debido ás baixas taxas de adopción e á posibilidade restante de ataques de degradación.
Así que temos unha clara ganancia para o atacante e unha falta de seguridade. Gran mestura!
Que temos que facer?
O paso obvio e máis drástico é revisar a túa política de enrutamento actual. Divide o teu espazo de enderezos nos anacos máis pequenos (sen superposicións) que queiras anunciar. Asina ROA só para eles, sen utilizar o parámetro maxLength. Neste caso, o teu POV actual pode salvarte dun ataque deste tipo. Non obstante, de novo, para algúns operadores este enfoque non é razoable debido ao uso exclusivo de rutas máis específicas. Todos os problemas co estado actual do ROA e os obxectos da ruta describiranse nun dos nosos futuros materiais.
Ademais, podes tentar controlar tales intercepcións. Para iso, necesitamos información fiable sobre os teus prefixos. Así, se estableces unha sesión BGP co noso colector e nos proporcionas información sobre a túa visibilidade en Internet, podemos atopar o alcance para outras incidencias. Para aqueles que aínda non estean conectados ao noso sistema de vixilancia, para comezar, abondará cunha lista de rutas só cos seus prefixos. Se tes unha sesión connosco, comproba que todas as túas rutas foron enviadas. Desafortunadamente, vale a pena lembralo porque algúns operadores esquecen un ou dous prefixos e, polo tanto, interfiren cos nosos métodos de busca. Se se fai correctamente, teremos datos fiables sobre os teus prefixos, que no futuro axudaranos a identificar e detectar automaticamente este (e outros) tipos de interceptación de tráfico para o teu espazo de enderezos.
Se tes coñecemento de tal interceptación do teu tráfico en tempo real, podes tentar contrarrestala ti mesmo. O primeiro enfoque é anunciar rutas con estes prefixos máis específicos. No caso dun novo ataque a estes prefixos, repita.
O segundo enfoque é castigar o atacante e aqueles para os que é un punto crítico (para boas rutas) cortando o acceso das túas rutas ao atacante. Isto pódese facer engadindo o ASN do atacante ao AS_PATH das túas antigas rutas e, así, obrigándoos a evitar ese AS usando o mecanismo de detección de bucles integrado en BGP .
Fonte: www.habr.com