13 marzo nel gruppo di lavoro RIPE per la lotta contro gli abusi per considerare l'intercettazione BGP (hjjack) come violazione delle politiche RIPE. In caso di approvazione della proposta, il provider Internet colpito dall'intercettazione del traffico avrebbe la possibilità di inviare una richiesta speciale per mettere in luce l'autore dell'abuso. Se il gruppo di esperti raccogliesse prove sufficienti, tale LIR, fonte dell'intercettazione BGP, sarebbe considerato in violazione e potrebbe perdere lo status di LIR. Ci sono stati anche alcuni argomenti cambiamenti.
In questa pubblicazione vogliamo mostrare un esempio di attacco, in cui non solo il reale autore dell'abuso è stato messo in discussione, ma anche l'intero elenco dei prefissi danneggiati. Inoltre, tale attacco solleva nuovamente interrogativi sui motivi di futuri eventi di intercettazione del traffico di tale tipo.
Negli ultimi due anni, la stampa ha trattato soltanto conflitti di tipo MOAS (Multiple Origin Autonomous System) come intercettazioni BGP. Il MOAS è un caso particolare, in cui due diverse sistemi autonomi annunciano prefissi conflittuali con numeri ASN corrispondenti in AS_PATH (il primo ASN in AS_PATH, d'ora in poi — origin ASN). Tuttavia, possiamo elencare almeno di intercettazione del traffico che consentono agli autori di manipolare l'attributo AS_PATH con vari obiettivi, incluso quello di eludere gli approcci moderni di filtraggio e monitoraggio. Un tipo noto di attacco è l'ultimo tipo di tale intercettazione, ma non per importanza. È del tutto possibile che abbiamo assistito a tale attacco nelle ultime settimane. Questo evento è caratterizzato da motivazioni chiare e conseguenze piuttosto serie.
Coloro che cercano una versione TL;DR possono scorrere fino al sottotitolo "Attacco perfetto".
Contesto di rete
(affinché tu possa comprendere meglio i processi coinvolti in questo incidente)
Se desideri inviare un pacchetto e hai diversi prefissi nella tabella di routing contenenti l'indirizzo IP di destinazione, utilizzerai la rotta per il prefisso con la lunghezza massima. Se nella tabella di routing esistono più rotte diverse per uno stesso prefisso, sceglierai la migliore (secondo il meccanismo di selezione del miglior percorso).
Gli approcci esistenti per la filtrazione e il monitoraggio cercano di analizzare i percorsi e prendere decisioni esaminando l'attributo AS_PATH. Il router può cambiare questo attributo in qualsiasi valore durante l'annuncio. Aggiungere semplicemente l'ASN del proprietario all'inizio dell'AS_PATH (come ASN di origine) può essere sufficiente per bypassare gli attuali meccanismi di verifica della fonte. Inoltre, se esiste un percorso dall'ASN attaccato a te, si presenta la possibilità di estrarre e utilizzare l'AS_PATH di quel percorso in altri tuoi annunci. Qualsiasi verifica di autenticità solo dell'AS_PATH per i tuoi annunci falsificati alla fine verrà superata.
Ci sono anche diverse limitazioni degne di nota. In primo luogo, nel caso in cui un provider più in alto filtri i prefissi, il tuo percorso potrebbe comunque essere filtrato (anche con un AS_PATH corretto), se il prefisso non appartiene al tuo cono cliente, impostato upstream. In secondo luogo, un AS_PATH valido può diventare non valido se il percorso creato è annunciato in direzioni errate, violando così la politica di instradamento. Infine, qualsiasi percorso con un prefisso che viola la lunghezza del ROA può essere considerato non valido.
Incidente
Alcune settimane fa abbiamo ricevuto una lamentela da uno degli utenti. Abbiamo visto percorsi con il suo ASN di origine e prefissi /25, mentre l'utente sosteneva di non averli annunciati.
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 all'inizio di aprile 2019
NTT in rotta per il prefisso /25 lo rende particolarmente sospetto. Durante l'incidente, LG NTT non sapeva nulla di questo percorso. Quindi sì, qualche operatore sta creando un intero AS_PATH per questi prefissi! La verifica su altri router evidenzia un ASN particolare: AS263444. Esaminando altri percorsi con questo sistema autonomo, ci siamo trovati nella 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 non va qui
Sembra che qualcuno abbia preso un prefisso dal percorso, l'abbia diviso in due parti e abbia annunciato il percorso con lo stesso AS_PATH per questi 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||
Esempi di percorsi per una delle coppie di prefissi divisi
Sorgono subito diverse domande. Qualcuno ha davvero provato in pratica questo tipo di intercettazione? Qualcuno ha accettato questi percorsi? Quali prefissi sono stati interessati?
Qui inizia la nostra sfilza di insuccessi e un altro giro di delusioni sulla attuale salute di Internet.
Il cammino degli insuccessi
Partiamo dall'inizio. Come possiamo determinare quali router hanno accettato questi percorsi intercettati e quale traffico potrebbe essere reindirizzato già oggi? Abbiamo pensato di iniziare con i prefissi /25, perché "semplicemente non possono avere diffusione globale". Come potete immaginare, ci siamo sbagliati di grosso. Questa metrica si è rivelata eccessivamente rumorosa e percorsi con tali prefissi possono apparire anche da operatori di Tier-1. Ad esempio, NTT ha circa 50 di questi prefissi che distribuisce ai propri clienti. D'altra parte, questa metrica è scarsa, perché tali prefissi possono essere filtrati se l'operatore applica , in tutte le direzioni. Pertanto, questo metodo non è adatto per trovare tutti gli operatori il cui traffico è stato reindirizzato a causa di un incidente di questo tipo.
Un'altra buona idea ci è sembrata quella di guardare a . In particolare ai percorsi che violano la regola maxLength del ROA corrispondente. In questo modo, potremmo trovare il numero di diversi origin ASN con stato Invalid, che erano visibili a questo AS. Tuttavia, esiste un "piccolo" problema. Il valore medio (mediana e moda) di questo numero (quantità di diversi origin ASN) è di circa 150 e, anche se filtriamo i piccoli prefissi, rimarrà sopra 70. Questa situazione ha una spiegazione piuttosto semplice: ci sono solo pochi operatori che già applicano filtri ROA con politica di "scartare i percorsi Invalid" ai punti di ingresso, quindi, ovunque nel mondo reale possa apparire un percorso che viola il ROA, esso può diffondersi in tutte le direzioni.
Le ultime due strategie ci consentono di trovare operatori che hanno visto il nostro incidente (poiché era abbastanza grande), ma nel complesso non sono applicabili. Va bene, ma possiamo trovare l'aggressore? Quali sono le caratteristiche generali di tale manipolazione AS_PATH? Ci sono alcune ipotesi di base:
- Il prefisso non era mai stato visto prima;
- L'Origin ASN (ricorda: il primo ASN nell'AS_PATH) è valido;
- L'ultimo ASN nell'AS_PATH è l'ASN dell'aggressore (nel caso in cui il suo vicino controlli l'ASN del vicino su tutti i percorsi in ingresso);
- L'attacco proviene da un unico fornitore.
Se tutte le ipotesi sono corrette, in tutti i percorsi errati sarà rappresentato l'ASN dell'attaccante (tranne l'ASN di origine) e, quindi, questo rappresenta un 'punto critico'. Tra i veri hijacker è emerso anche AS263444, anche se ce ne sono stati altri. Anche quando abbiamo escluso i percorsi dell'incidente dalla considerazione. Perché? Un punto critico può rimanere critico anche per percorsi corretti. Può essere il risultato di una cattiva connettività in una certa area, o di limitazioni della nostra stessa visibilità.
Come risultato: c'è un modo per rilevare l'attaccante, ma solo se si soddisfano tutte le condizioni sopra elencate e solo quando l'intercettazione è abbastanza grande da superare le soglie di monitoraggio. Se alcune di queste condizioni non sono rispettate, possiamo identificare i prefissi colpiti da tale intercettazione? Per certi operatori — sì.
Quando un attaccante crea un percorso più specifico, quel prefisso non è annunciato dal vero proprietario. Se hai un elenco dinamico di tutti i suoi prefissi, hai la possibilità di effettuare un confronto e identificare i percorsi più specifici distorti. Raccogliamo questo elenco di prefissi tramite le nostre sessioni BGP, poiché ci viene fornito non solo un elenco completo dei percorsi visibili all'operatore in questo momento, ma anche un elenco di tutti i prefissi che desidera annunciare al mondo. Sfortunatamente, attualmente ci sono diverse decine di utenti di Radar che non completano correttamente quest'ultima parte. A breve li avviseremo e cercheremo di risolvere questo problema. Tutti gli altri possono unirsi al nostro sistema di monitoraggio in questo momento.
Tornando all'incidente iniziale, sia l'attaccante che l'area di diffusione sono stati identificati tramite la ricerca di punti critici. Stranamente, AS263444 ha inviato percorsi falsificati non a tutti i suoi clienti. Anche se c'è un aspetto ancora 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 intercettazione del nostro spazio indirizzamento
Quando sono stati creati more specific’ e per i nostri prefissi, è stato utilizzato un AS_PATH creato ad hoc. Tuttavia, questo AS_PATH non poteva essere preso da nessuno dei nostri percorsi precedenti. Non abbiamo nemmeno alcun collegamento con AS6762. Esaminiamo altri percorsi nell'incidente: alcuni di essi avevano un vero AS_PATH che era stato utilizzato in precedenza, mentre altri no, anche se sembravano veri. Una modifica aggiuntiva dell'AS_PATH non ha alcun senso pratico, poiché in ogni caso il traffico verrà reindirizzato all'attaccante, ma i percorsi con un AS_PATH “cattivo” possono essere filtrati da ASPA o da qualsiasi altro meccanismo di verifica. Qui ci siamo chiesti quale fosse la motivazione dell'hacker. Attualmente ci mancano i dati per affermare che questo incidente fosse un attacco pianificato. Tuttavia, è possibile. Proviamo a immaginare una situazione che, anche se ipotetica, è potenzialmente molto reale.
Attacco ideale
Cosa abbiamo? Supponiamo che tu sia un fornitore di transito che pubblicizza percorsi per i propri clienti. Se i tuoi clienti hanno una presenza multipla (multihome), riceverai solo una parte del loro traffico. Ma più traffico hai, più il tuo reddito aumenta. Pertanto, se inizi a pubblicizzare i prefissi delle subnet di questi stessi percorsi con lo stesso AS_PATH, otterrai il resto del loro traffico. Di conseguenza, il resto dei soldi.
Può aiutare qui il ROA? Forse sì, se decidi di rinunciare completamente all'uso . Inoltre, è estremamente sconsigliabile avere registrazioni ROA con prefissi sovrapposti. Per alcuni operatori tali limitazioni sono inaccettabili.
Considerando altri meccanismi di sicurezza della routing, in questo caso ASPA non aiuterà (poiché viene utilizzato un AS_PATH dal percorso consentito). BGPSec rimane comunque un'opzione non ottimale a causa del basso tasso di adozione e della possibilità di attacchi di downgrade.
Quindi abbiamo un chiaro profitto per l'attaccante e una mancanza di sicurezza. Una miscela perfetta!
Cosa bisogna fare?
Un passo ovvio e radicale è rivedere la vostra attuale politica di instradamento. Suddividete il vostro spazio indirizzi in pezzi più piccoli (senza sovrapposizioni) che volete annunciare. Firmate il ROA solo per loro, senza utilizzare il parametro maxLength. In questo caso, l'attuale POV può salvarvi da un attacco simile. Tuttavia, di nuovo, per alcuni operatori, questo approccio non è sensato a causa dell'uso esclusivo di rotte more specific. Tutti i problemi dell'attuale stato degli oggetti ROA e route saranno descritti in uno dei nostri futuri materiali.
Inoltre, si può cercare di monitorare tali intercettazioni. Per questo abbiamo bisogno di informazioni affidabili sui vostri prefissi. Così, se stabilite una sessione BGP con il nostro collettore e ci inviate informazioni sulla vostra visibilità su Internet, possiamo individuare l'area di diffusione anche per altri incidenti. Per coloro che non sono ancora connessi al nostro sistema di monitoraggio, per iniziare ci basterebbe un elenco di rotte con i vostri prefissi. Se invece avete già una sessione con noi, vi preghiamo di controllare che siano stati inviati tutti i vostri percorsi. Sfortunatamente, vale la pena ricordarlo, poiché alcuni operatori dimenticano uno o due prefissi, creando così problemi ai nostri metodi di ricerca. Se tutto viene fatto correttamente, avremo dati affidabili sui vostri prefissi che in futuro aiuteranno a identificare e rilevare automaticamente tali (e altri) tipi di intercettazione del traffico per il vostro spazio indirizzi.
Se in tempo reale venite a conoscenza di una tale intercettazione del vostro traffico, potete tentare di contrastarla da soli. Il primo approccio è annunciare percorsi con questi prefissi more specific da soli. In caso di un nuovo attacco a questi prefissi, ripetere.
Il secondo approccio è punire l'attaccante e coloro per cui rappresenta un punto critico (per le buone rotte), interrompendo l'accesso dei vostri percorsi all'attaccante. Questo può essere fatto aggiungendo l'ASN dell'attaccante nel AS_PATH delle vostre vecchie rotte, costringendoli così a evitare questo AS, utilizzando il meccanismo di rilevamento dei cicli incorporato in BGP. .
Fonte: habr.com
