13 de març al grup de treball antiabús RIPE considereu el segrest de BGP (hjjack) com una violació de la política RIPE. Si s'accepta la proposta, el proveïdor d'Internet atacat per la intercepció del trànsit tindria l'oportunitat d'enviar una sol·licitud especial per exposar l'atacant. Si l'equip de revisió recopilava proves de suport suficients, el LIR que va ser la font de la intercepció de BGP es consideraria un intrús i es podria despullar del seu estat de LIR. També hi havia alguns arguments canvis.
En aquesta publicació volem mostrar un exemple d'atac on no només es va qüestionar l'atacant real, sinó també tota la llista de prefixos afectats. A més, aquest atac torna a plantejar preguntes sobre els motius de les futures intercepcions d'aquest tipus de trànsit.
Durant els darrers dos anys, només s'han tractat a la premsa conflictes com el MOAS (Sistema Autònom d'Origen Múltiple) com a intercepcions de BGP. MOAS és un cas especial en què dos sistemes autònoms diferents anuncien prefixos conflictius amb els ASN corresponents a AS_PATH (el primer ASN a AS_PATH, d'ara endavant anomenat ASN d'origen). No obstant això, podem dir com a mínim interceptació del trànsit, que permet a un atacant manipular l'atribut AS_PATH per a diversos propòsits, inclòs eludir els enfocaments moderns de filtratge i supervisió. Tipus d'atac conegut - l'últim tipus d'intercepció, però gens important. És molt possible que aquest sigui exactament el tipus d'atac que hem vist durant les darreres setmanes. Aquest esdeveniment té una naturalesa comprensible i conseqüències força greus.
Aquells que busquen la versió TL;DR poden desplaçar-se fins al subtítol "Perfect Attack".
Fons de xarxa
(per ajudar-vos a entendre millor els processos implicats en aquest incident)
Si voleu enviar un paquet i teniu diversos prefixos a la taula d'encaminament que conté l'adreça IP de destinació, utilitzareu la ruta per al prefix amb la longitud més llarga. Si hi ha diverses rutes diferents per al mateix prefix a la taula d'encaminament, triareu la millor (segons el mecanisme de selecció de la millor ruta).
Els enfocaments de filtratge i monitoratge existents intenten analitzar rutes i prendre decisions mitjançant l'anàlisi de l'atribut AS_PATH. L'encaminador pot canviar aquest atribut a qualsevol valor durant l'anunci. Simplement afegir l'ASN del propietari al principi d'AS_PATH (com a ASN d'origen) pot ser suficient per evitar els mecanismes de comprovació de l'origen actuals. A més, si hi ha una ruta des de l'ASN atacat fins a vosaltres, serà possible extreure i utilitzar l'AS_PATH d'aquesta ruta en els vostres altres anuncis. Qualsevol comprovació de validació només d'AS_PATH per als vostres anuncis elaborats acabarà aprovada.
Encara hi ha algunes limitacions que val la pena esmentar. En primer lloc, en cas de filtratge de prefix per part del proveïdor d'amunt, la vostra ruta encara es pot filtrar (fins i tot amb l'AS_PATH correcte) si el prefix no pertany al vostre con de client configurat a l'amunt. En segon lloc, un AS_PATH vàlid pot no ser vàlid si la ruta creada s'anuncia en direccions incorrectes i, per tant, infringeix la política d'encaminament. Finalment, qualsevol ruta amb un prefix que infringeixi la longitud del ROA es pot considerar no vàlida.
Incident
Fa unes setmanes vam rebre una queixa d'un dels nostres usuaris. Vam veure rutes amb el seu origen ASN i prefixos /25, mentre que l'usuari va afirmar que no les va anunciar.
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||
Exemples d'anuncis per a principis d'abril de 2019
NTT al camí del prefix /25 fa que sigui especialment sospitós. LG NTT desconeixia aquesta ruta en el moment de l'incident. Així que sí, algun operador crea un AS_PATH sencer per a aquests prefixos! La comprovació d'altres encaminadors revela un ASN particular: AS263444. Després de mirar altres rutes amb aquest sistema autònom, ens trobem amb la següent situació:
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 endevinar què passa aquí
Sembla que algú va agafar el prefix de la ruta, el va dividir en dues parts i va anunciar la ruta amb el mateix AS_PATH per a aquests dos 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||
Rutes d'exemple per a un dels parells de prefixos dividits
Es plantegen diverses preguntes alhora. Algú ha provat aquest tipus d'intercepcions a la pràctica? Algú ha fet aquestes rutes? Quins prefixos es van veure afectats?
Aquí és on comença la nostra sèrie de fracassos i una altra ronda de decepció amb l'estat actual de la salut d'Internet.
El camí del fracàs
El primer és el primer. Com podem determinar quins encaminadors van acceptar aquestes rutes interceptades i el trànsit de qui es podria desviar avui? Vam pensar que començaríem amb /25 prefixos perquè "simplement no poden tenir distribució global". Com podeu suposar, ens hem equivocat molt. Aquesta mètrica va resultar ser massa sorollosa i les rutes amb aquests prefixos poden aparèixer fins i tot dels operadors de nivell 1. Per exemple, NTT té uns 50 prefixos d'aquest tipus, que distribueix als seus propis clients. D'altra banda, aquesta mètrica és dolenta perquè aquests prefixos es poden filtrar si l'operador els utilitza , en totes direccions. Per tant, aquest mètode no és adequat per trobar tots els operadors el trànsit dels quals s'hagi redirigit com a conseqüència d'un incident d'aquest tipus.
Una altra bona idea que vam pensar va ser mirar . Especialment per a rutes que infringeixen la regla maxLength del ROA corresponent. D'aquesta manera podríem trobar el nombre d'ASN d'origen diferents amb l'estat No vàlid que eren visibles per a un AS determinat. Tanmateix, hi ha un "petit" problema. La mitjana (mediana i modalitat) d'aquest nombre (el nombre d'ASN d'origen diferent) és d'uns 150 i, encara que filtrem els prefixos petits, es manté per sobre dels 70. Aquest estat de coses té una explicació molt senzilla: només hi ha un pocs operadors que ja utilitzen filtres ROA amb una política de "restabliment de rutes no vàlides" als punts d'entrada, de manera que allà on apareix una ruta amb una infracció de ROA al món real, es pot propagar en totes direccions.
Les dues últimes aproximacions ens permeten trobar operadors que han vist el nostre incident (ja que era bastant gran), però en general no són aplicables. D'acord, però podem trobar l'intrus? Quines són les característiques generals d'aquesta manipulació AS_PATH? Hi ha uns quants supòsits bàsics:
- El prefix no s'havia vist enlloc abans;
- L'ASN d'origen (recordatori: primer ASN a AS_PATH) és vàlid;
- L'últim ASN a AS_PATH és l'ASN de l'atacant (en cas que el seu veí comprovi l'ASN del veí a totes les rutes entrants);
- L'atac prové d'un sol proveïdor.
Si totes les suposicions són correctes, llavors totes les rutes incorrectes presentaran l'ASN de l'atacant (excepte l'ASN d'origen) i, per tant, aquest és un punt "crític". Entre els autèntics segrestadors hi havia AS263444, tot i que n'hi havia d'altres. Fins i tot quan vam descartar les rutes incident de la consideració. Per què? Un punt crític pot seguir sent crític fins i tot per a rutes correctes. Pot ser el resultat de la mala connectivitat d'una regió o de les limitacions de la nostra pròpia visibilitat.
Com a resultat, hi ha una manera de detectar un atacant, però només si es compleixen totes les condicions anteriors i només quan la intercepció és prou gran per superar els llindars de control. Si no es compleixen alguns d'aquests factors, podem identificar els prefixos que van patir aquesta intercepció? Per a determinats operadors, sí.
Quan un atacant crea una ruta més específica, aquest prefix no és anunciat pel veritable propietari. Si teniu una llista dinàmica de tots els seus prefixos, serà possible fer una comparació i trobar rutes més específiques distorsionades. Recopilem aquesta llista de prefixos utilitzant les nostres sessions BGP, perquè ens donen no només la llista completa de rutes visibles per l'operador ara mateix, sinó també una llista de tots els prefixos que vol anunciar al món. Malauradament, ara hi ha diverses desenes d'usuaris de Radar que no completen correctament l'última part. Els avisarem en breu i intentarem resoldre aquest problema. Tothom pot unir-se al nostre sistema de monitoratge ara mateix.
Si tornem a l'incident original, tant l'atacant com l'àrea de distribució van ser detectats per nosaltres mitjançant la recerca de punts crítics. Sorprenentment, AS263444 no va enviar rutes fabricades a tots els seus clients. Encara que hi ha un moment estrany.
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 exemple recent d'un intent d'interceptar el nostre espai d'adreces
Quan es van crear-ne de més específics per als nostres prefixos, es va utilitzar un AS_PATH especialment creat. Tanmateix, aquest AS_PATH no s'ha pogut agafar de cap de les nostres rutes anteriors. Ni tan sols tenim comunicació amb AS6762. Mirant les altres rutes de l'incident, algunes d'elles tenien un AS_PATH real que s'utilitzava anteriorment, mentre que d'altres no, encara que sembli l'autèntic. Canviar AS_PATH, a més, no té cap sentit pràctic, ja que de totes maneres el trànsit es redirigirà a l'atacant, però les rutes amb un AS_PATH "dolent" es poden filtrar per ASPA o qualsevol altre mecanisme d'inspecció. Aquí pensem en la motivació del segrestador. Actualment no tenim prou informació per confirmar que aquest incident va ser un atac planificat. No obstant això, és possible. Intentem imaginar una situació, encara que encara hipotètica, però potencialment força real.
Atac perfecte
Què tenim? Suposem que sou un proveïdor de transport públic que transmet rutes per als vostres clients. Si els vostres clients tenen presència múltiple (multihome), només rebreu una part del seu trànsit. Però com més trànsit, més ingressos. Per tant, si comenceu a anunciar prefixos de subxarxa d'aquestes mateixes rutes amb el mateix AS_PATH, rebreu la resta del seu trànsit. Com a resultat, la resta dels diners.
ROA ajudarà aquí? Potser sí, si decidiu deixar d'utilitzar-lo completament . A més, és molt indesitjable tenir registres de ROA amb prefixos que s'intersequen. Per a alguns operadors, aquestes restriccions són inacceptables.
Tenint en compte altres mecanismes de seguretat d'encaminament, ASPA tampoc ajudarà en aquest cas (perquè utilitza AS_PATH des d'una ruta vàlida). BGPSec encara no és una opció òptima a causa de les baixes taxes d'adopció i de la possibilitat restant d'atacs a la baixa.
Així doncs, tenim un clar guany per a l'atacant i una manca de seguretat. Gran barreja!
Què fer?
El pas obvi i més dràstic és revisar la vostra política d'encaminament actual. Divideu el vostre espai d'adreces en els trossos més petits (sense superposicions) que vulgueu anunciar. Signeu ROA només per a ells, sense utilitzar el paràmetre maxLength. En aquest cas, el vostre PDV actual us pot salvar d'aquest atac. Tanmateix, de nou, per a alguns operadors aquest enfocament no és raonable a causa de l'ús exclusiu de rutes més específiques. Tots els problemes amb l'estat actual del ROA i els objectes de ruta es descriuran en un dels nostres futurs materials.
A més, podeu intentar controlar aquestes intercepcions. Per fer-ho, necessitem informació fiable sobre els vostres prefixos. Així, si estableixes una sessió BGP amb el nostre col·lector i ens facilita informació sobre la teva visibilitat a Internet, podem trobar l'abast d'altres incidències. Per a aquells que encara no estiguin connectats al nostre sistema de monitorització, per començar, n'hi haurà prou amb una llista de rutes només amb els vostres prefixos. Si teniu una sessió amb nosaltres, comproveu que totes les vostres rutes s'han enviat. Malauradament, val la pena recordar-ho perquè alguns operadors obliden un o dos prefixos i, per tant, interfereixen amb els nostres mètodes de cerca. Si es fa correctament, tindrem dades fiables sobre els vostres prefixos, que en el futur ens ajudaran a identificar i detectar automàticament aquest (i altres) tipus d'intercepció de trànsit per al vostre espai d'adreces.
Si prens consciència d'aquesta intercepció del teu trànsit en temps real, pots intentar contrarestar-la tu mateix. El primer enfocament és anunciar rutes amb aquests prefixos més específics. En cas d'un nou atac a aquests prefixos, repeteix.
El segon enfocament és castigar l'atacant i aquells per als quals és un punt crític (per a bones rutes) tallant l'accés de les vostres rutes a l'atacant. Això es pot fer afegint l'ASN de l'atacant a l'AS_PATH de les vostres rutes antigues i, per tant, obligar-los a evitar aquest AS mitjançant el mecanisme de detecció de bucles integrat a BGP. .
Font: www.habr.com