13 marzo al gruppo di lavoro antiabusi del RIPE considerare il dirottamento BGP (hjjack) come una violazione della politica RIPE. Se la proposta venisse accettata, il provider Internet attaccato dall'intercettazione del traffico avrebbe la possibilità di inviare una richiesta speciale per smascherare l'aggressore. Se il gruppo di revisione raccogliesse prove sufficienti a sostegno, il LIR che era la fonte dell’intercettazione BGP sarebbe considerato un intruso e potrebbe essere privato del suo status di LIR. C'erano anche alcune discussioni i cambiamenti.
In questa pubblicazione vogliamo mostrare un esempio di attacco in cui non era in questione solo il vero aggressore, ma anche l'intero elenco dei prefissi interessati. Inoltre, un simile attacco solleva nuovamente interrogativi sui motivi delle future intercettazioni di questo tipo di traffico.
Negli ultimi due anni, solo i conflitti come MOAS (Multiple Origin Autonomous System) sono stati trattati dalla stampa come intercettazioni BGP. MOAS è un caso speciale in cui due diversi sistemi autonomi pubblicizzano prefissi in conflitto con i corrispondenti ASN in AS_PATH (il primo ASN in AS_PATH, di seguito denominato ASN di origine). Tuttavia, possiamo almeno nominare intercettazione del traffico, consentendo a un utente malintenzionato di manipolare l'attributo AS_PATH per vari scopi, incluso aggirare gli approcci moderni al filtraggio e al monitoraggio. Tipo di attacco noto - l'ultimo tipo di tale intercettazione, ma per nulla importante. È del tutto possibile che questo sia esattamente il tipo di attacco a cui abbiamo assistito nelle ultime settimane. Un simile evento ha una natura comprensibile e conseguenze piuttosto gravi.
Chi cerca la versione TL;DR può scorrere fino al sottotitolo "Attacco perfetto".
Sfondo della rete
(per aiutarti a comprendere meglio i processi coinvolti in questo incidente)
Se desideri inviare un pacchetto e nella tabella di routing contenente l'indirizzo IP di destinazione sono presenti più prefissi, utilizzerai il percorso per il prefisso con la lunghezza più lunga. Se nella tabella di routing sono presenti più percorsi diversi per lo stesso prefisso, si sceglierà quello migliore (secondo il miglior meccanismo di selezione del percorso).
Gli approcci di filtraggio e monitoraggio esistenti tentano di analizzare i percorsi e prendere decisioni analizzando l'attributo AS_PATH. Il router può modificare questo attributo su qualsiasi valore durante l'annuncio. La semplice aggiunta dell'ASN del proprietario all'inizio di AS_PATH (come ASN di origine) potrebbe essere sufficiente per aggirare gli attuali meccanismi di controllo dell'origine. Inoltre, se esiste un percorso dall'ASN attaccato a te, diventa possibile estrarre e utilizzare l'AS_PATH di questo percorso negli altri tuoi annunci. Qualsiasi controllo di convalida solo AS_PATH per gli annunci creati alla fine verrà superato.
Ci sono ancora alcune limitazioni che vale la pena menzionare. Innanzitutto, in caso di filtraggio del prefisso da parte del provider upstream, il tuo percorso potrebbe comunque essere filtrato (anche con l'AS_PATH corretto) se il prefisso non appartiene al cono client configurato a monte. In secondo luogo, un AS_PATH valido può diventare non valido se il percorso creato viene pubblicizzato in direzioni errate e, quindi, viola la politica di instradamento. Infine, qualsiasi percorso con un prefisso che viola la lunghezza del ROA potrebbe essere considerato non valido.
Incidente
Alcune settimane fa abbiamo ricevuto un reclamo da uno dei nostri utenti. Abbiamo visto percorsi con il suo ASN di origine e prefissi /25, mentre l'utente ha affermato di non averli pubblicizzati.
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||
Esempi di annunci per l'inizio di aprile 2019
NTT nel percorso del prefisso /25 lo rende particolarmente sospetto. LG NTT non era a conoscenza di questo percorso al momento dell'incidente. Quindi sì, alcuni operatori creano un intero AS_PATH per questi prefissi! Il controllo su altri router rivela un ASN particolare: AS263444. Dopo aver esaminato altri percorsi con questo sistema autonomo, abbiamo riscontrato la seguente situazione:
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||
Prova a indovinare cosa c'è che non va qui
Sembra che qualcuno abbia preso il prefisso dal percorso, lo abbia diviso in due parti e abbia pubblicizzato il percorso con lo stesso AS_PATH per quei due prefissi.
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||
Percorsi di esempio per una delle coppie di prefissi divisi
Sorgono diverse domande contemporaneamente. Qualcuno ha effettivamente provato nella pratica questo tipo di intercettazione? Qualcuno ha fatto questi percorsi? Quali prefissi sono stati interessati?
È qui che inizia la nostra serie di fallimenti e l'ennesimo ciclo di delusioni per l'attuale stato di salute di Internet.
Il percorso del fallimento
Cominciando dall'inizio. Come possiamo determinare quali router hanno accettato tali percorsi intercettati e quale traffico potrebbe essere reindirizzato oggi? Abbiamo pensato di iniziare con i prefissi /25 perché "semplicemente non possono avere una distribuzione globale". Come puoi immaginare, ci sbagliavamo di grosso. Questa metrica si è rivelata troppo rumorosa e percorsi con tali prefissi possono apparire anche da operatori di livello 1. Ad esempio, NTT ha circa 50 prefissi di questo tipo, che distribuisce ai propri clienti. D'altra parte, questa metrica è negativa perché tali prefissi possono essere filtrati se l'operatore li utilizza , in tutte le direzioni. Pertanto, questo metodo non è adatto per trovare tutti gli operatori il cui traffico è stato reindirizzato a seguito di un simile incidente.
Un'altra buona idea che abbiamo pensato era quella di guardare . Soprattutto per i percorsi che violano la regola maxLength del ROA corrispondente. In questo modo potremmo trovare il numero di ASN di origine diversa con stato Non valido visibili a un determinato AS. C’è però un “piccolo” problema. La media (mediana e modale) di questo numero (il numero di ASN di diversa origine) è circa 150 e, anche filtrando piccoli prefissi, rimane superiore a 70. Questo stato di cose ha una spiegazione molto semplice: esistono solo pochi operatori che già utilizzano filtri ROA con una politica di “reset percorsi non validi” nei punti di ingresso, in modo che ovunque appaia nel mondo reale un percorso con una violazione del ROA, possa propagarsi in tutte le direzioni.
Gli ultimi due approcci ci permettono di trovare gli operatori che hanno visto il nostro incidente (visto che era piuttosto grande), ma in generale non sono applicabili. Ok, ma possiamo trovare l'intruso? Quali sono le caratteristiche generali di questa manipolazione AS_PATH? Ci sono alcuni presupposti di base:
- Il prefisso non era mai stato visto prima;
- L'ASN di origine (promemoria: primo ASN in AS_PATH) è valido;
- L'ultimo ASN in AS_PATH è l'ASN dell'attaccante (nel caso in cui il suo vicino controlli l'ASN del vicino su tutte le rotte in entrata);
- L'attacco proviene da un unico provider.
Se tutte le ipotesi sono corrette, allora tutti i percorsi errati presenteranno l'ASN dell'attaccante (eccetto l'ASN di origine) e, quindi, questo è un punto "critico". Tra i veri dirottatori c'era AS263444, sebbene ce ne fossero altri. Anche quando abbiamo scartato dalla considerazione le vie degli incidenti. Perché? Un punto critico può rimanere critico anche per percorsi corretti. Può essere il risultato di una scarsa connettività in una regione o di limitazioni nella nostra visibilità.
Di conseguenza, esiste un modo per rilevare un utente malintenzionato, ma solo se tutte le condizioni di cui sopra sono soddisfatte e solo quando l’intercettazione è sufficientemente ampia da superare le soglie di monitoraggio. Se alcuni di questi fattori non vengono soddisfatti, possiamo identificare i prefissi che hanno subito tale intercettazione? Per alcuni operatori sì.
Quando un utente malintenzionato crea un percorso più specifico, tale prefisso non viene pubblicizzato dal vero proprietario. Se si dispone di un elenco dinamico di tutti i suoi prefissi, diventa possibile fare un confronto e trovare percorsi distorti più specifici. Raccogliamo questo elenco di prefissi utilizzando le nostre sessioni BGP, perché ci viene fornito non solo l'elenco completo delle rotte visibili all'operatore in questo momento, ma anche un elenco di tutti i prefissi che vuole pubblicizzare al mondo. Purtroppo ora ci sono diverse decine di utenti Radar che non completano correttamente l'ultima parte. Li informeremo a breve e proveremo a risolvere questo problema. Tutti gli altri possono unirsi al nostro sistema di monitoraggio adesso.
Se torniamo all'incidente originale, sia l'aggressore che l'area di distribuzione sono stati da noi individuati ricercando i punti critici. Sorprendentemente, AS263444 non ha inviato percorsi fittizi a tutti i suoi clienti. Anche se c'è un momento più strano.
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 recente esempio di tentativo di intercettare il nostro spazio di indirizzi
Quando ne sono stati creati di più specifici per i nostri prefissi, è stato utilizzato un AS_PATH appositamente creato. Tuttavia, questo AS_PATH non può essere stato preso da nessuno dei nostri percorsi precedenti. Non abbiamo nemmeno comunicazione con AS6762. Osservando gli altri percorsi nell'incidente, alcuni di essi avevano un vero AS_PATH precedentemente utilizzato, mentre altri no, anche se sembra quello reale. Modificare ulteriormente AS_PATH non ha alcun senso pratico, poiché il traffico verrà comunque reindirizzato all'aggressore, ma i percorsi con un AS_PATH "cattivo" possono essere filtrati da ASPA o da qualsiasi altro meccanismo di ispezione. Qui pensiamo alla motivazione del dirottatore. Al momento non disponiamo di informazioni sufficienti per confermare che questo incidente fosse un attacco pianificato. Tuttavia è possibile. Proviamo ad immaginare una situazione, anche se ancora ipotetica, ma potenzialmente del tutto reale.
Attacco perfetto
Cosa abbiamo? Supponiamo che tu sia un fornitore di servizi di trasporto pubblico che trasmette percorsi per i tuoi clienti. Se i tuoi clienti hanno presenze multiple (multihome), riceverai solo una parte del loro traffico. Ma maggiore è il traffico, maggiore sarà il tuo reddito. Pertanto, se inizi a pubblicizzare i prefissi di sottorete di questi stessi percorsi con lo stesso AS_PATH, riceverai il resto del loro traffico. Di conseguenza, il resto del denaro.
Il ROA aiuterà qui? Forse sì, se decidi di smettere completamente di usarlo . Inoltre, è altamente indesiderabile avere record ROA con prefissi che si intersecano. Per alcuni operatori tali restrizioni sono inaccettabili.
Considerando altri meccanismi di sicurezza del routing, ASPA non sarà d'aiuto neanche in questo caso (perché utilizza AS_PATH da un percorso valido). BGPSec non è ancora un'opzione ottimale a causa dei bassi tassi di adozione e della restante possibilità di attacchi di downgrade.
Quindi abbiamo un chiaro vantaggio per l’aggressore e una mancanza di sicurezza. Ottimo mix!
Cosa devo fare?
Il passo ovvio e più drastico è rivedere la tua attuale politica di routing. Suddividi lo spazio degli indirizzi nelle parti più piccole (senza sovrapposizioni) che desideri pubblicizzare. Firma il ROA solo per loro, senza utilizzare il parametro maxLength. In questo caso, il tuo attuale POV può salvarti da un simile attacco. Tuttavia, ancora una volta, per alcuni operatori questo approccio non è ragionevole a causa dell’uso esclusivo di rotte più specifiche. Tutti i problemi con lo stato attuale del ROA e degli oggetti del percorso saranno descritti in uno dei nostri materiali futuri.
Inoltre, puoi provare a monitorare tali intercettazioni. Per fare ciò, abbiamo bisogno di informazioni affidabili sui tuoi prefissi. Pertanto, se stabilisci una sessione BGP con il nostro agente di raccolta e ci fornisci informazioni sulla tua visibilità su Internet, possiamo trovare la possibilità per altri incidenti. Per chi non è ancora connesso al nostro sistema di monitoraggio, per cominciare, basterà un elenco di percorsi solo con i vostri prefissi. Se hai una sessione con noi, controlla che tutti i tuoi percorsi siano stati inviati. Sfortunatamente, vale la pena ricordarlo perché alcuni operatori dimenticano uno o due prefissi e quindi interferiscono con i nostri metodi di ricerca. Se fatto correttamente, avremo dati affidabili sui tuoi prefissi, che in futuro ci aiuteranno a identificare e rilevare automaticamente questo (e altri) tipi di intercettazione del traffico per il tuo spazio di indirizzi.
Se vieni a conoscenza di una simile intercettazione del tuo traffico in tempo reale, puoi provare a contrastarla tu stesso. Il primo approccio è pubblicizzare tu stesso i percorsi con questi prefissi più specifici. In caso di un nuovo attacco a questi prefissi, ripetere.
Il secondo approccio è punire l'aggressore e coloro per i quali rappresenta un punto critico (per buoni percorsi) tagliando l'accesso ai vostri percorsi all'aggressore. Questo può essere fatto aggiungendo l'ASN dell'attaccante all'AS_PATH dei tuoi vecchi percorsi e quindi costringendolo a evitare quell'AS utilizzando il meccanismo di rilevamento del loop integrato in BGP .
Fonte: habr.com