13 marzo nel gruppo di lavoro RIPE per la lotta contro gli abusi di considerare l'hijack BGP come una violazione della politica RIPE. Se la proposta fosse accettata, il fornitore di servizi Internet attaccato attraverso l'intercettazione del traffico avrebbe la possibilità di inviare una richiesta speciale per far emergere il responsabile. Se il gruppo di esperti raccogliesse abbastanza prove a sostegno, tale LIR, fonte dell'hijack BGP, sarebbe considerato un trasgressore e potrebbe essere privato dello stato di LIR. Sono stati sollevati anche alcuni argomenti modifiche.
In questa pubblicazione vogliamo mostrare un esempio di attacco in cui non solo il vero colpevole era sotto esame, ma anche l'intero elenco di prefissi colpiti. Inoltre, tale attacco riaccende interrogativi sui motivi dei futuri hijack di traffico di questo tipo.
Negli ultimi due anni, la stampa ha riportato solo conflitti tipo MOAS (Multiple Origin Autonomous System) come hijack BGP. MOAS è un caso specifico in cui due diverse autonome sistemi annunciano prefissi in conflitto con i rispettivi numeri ASN nell'AS_PATH (il primo ASN nell'AS_PATH è indicato come origin ASN). Tuttavia, possiamo nominare almeno di intercettazione del traffico che consentono ai malintenzionati di manipolare l'attributo AS_PATH per vari scopi, incluso il bypass delle attuali tecniche di filtraggio e monitoraggio. Un noto tipo di attacco è l'ultimo tipo di tale intercettazione, ma non per importanza. È molto probabile che sia questo tipo di attacco che abbiamo osservato nelle ultime settimane. Tale evento ha una natura spiegabile e conseguenze piuttosto gravi.
Coloro che cercano una versione TL;DR possono scorrere fino al sottotitolo 'Attacco ideale'.
Contesto di rete
(per aiutarti a comprendere meglio i processi coinvolti in questo incidente)
Se desideri inviare un pacchetto e hai diversi prefissi nella tabella di routing contenenti l'IP di destinazione, utilizzerai il percorso per il prefisso con la massima lunghezza. Se ci sono diversi percorsi per lo stesso prefisso nella tabella di routing, sceglierai il migliore (in base al meccanismo di selezione del miglior percorso).
Le attuali tecniche di filtraggio e monitoraggio cercano di analizzare i percorsi e prendere decisioni analizzando l'attributo AS_PATH. Il router può modificare questo attributo a qualunque valore durante l'annuncio. L'aggiunta semplice dell'ASN del proprietario all'inizio dell'AS_PATH (come origin ASN) può essere sufficiente per aggirare i meccanismi di verifica della fonte correnti. Inoltre, se esiste un percorso dall'ASN attaccato a te, c'è la possibilità di estrarre e utilizzare l'AS_PATH di quel percorso nei tuoi altri annunci. Qualsiasi verifica di validità solo dell'AS_PATH per i tuoi annunci contraffatti alla fine sarà superata.
Ci sono anche alcuni limiti degni di nota. In primo luogo, in caso di filtraggio di prefissi da parte di un fornitore superiore, il tuo percorso potrebbe comunque essere filtrato (anche con un AS_PATH corretto) se il prefisso non appartiene al tuo cono clienti configurato presso l'upstream. In secondo luogo, un AS_PATH valido può diventare non valido se il percorso creato viene annunciato in direzioni non corrette, violando così la politica di routing. E infine, qualsiasi percorso con un prefisso che viola la lunghezza ROA può essere considerato non valido.
Incidente
Alcune settimane fa abbiamo ricevuto una segnalazione da un utente. Abbiamo visto percorsi con il suo ASN di origine e prefissi /25, mentre l'utente ha affermato 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 transito per il prefisso /25 rende particolarmente sospettoso. Durante l'incidente, LG NTT non era a conoscenza di questo percorso. Quindi sì, un operatore sta creando un intero AS_PATH per questi prefissi! Un controllo 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 da un percorso, lo abbia diviso in due parti e abbia annunciato un 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
Subito sorgono diverse domande. Qualcuno ha davvero provato nella pratica questo tipo di intercettazione? Qualcuno ha accettato questi percorsi? Quali prefissi sono stati colpiti?
Qui inizia la nostra serie di sventure e un altro giro di delusione nella salute attuale di Internet.
La strada delle sventure
Iniziamo con ordine. Come possiamo identificare quali router hanno accettato percorsi intercettati e quale traffico può già essere reindirizzato oggi? Abbiamo pensato di partire dai prefissi /25, poiché sembrano "non poter avere una diffusione globale". Come potrete immaginare, ci siamo completamente sbagliati. Questa metrica si è rivelata troppo rumorosa e i percorsi con such prefissi possono apparire anche da operatori Tier-1. Ad esempio, NTT ha circa 50 prefissi di questo tipo che distribuisce tra i propri clienti. D'altra parte, questa metrica è scarsa, poiché tali prefissi possono essere filtrati se l'operatore applica , in tutte le direzioni. Pertanto, questo metodo non è adatto per identificare tutti gli operatori il cui traffico è stato reindirizzato a seguito di tale incidente.
Un'altra buona idea è sembrata quella di esaminare . In particolare, i percorsi che violano la regola maxLength del relativo ROA. In questo modo, potremmo trovare il numero di diversi ASN origin con stato Invalid, visibili da questo AS. Tuttavia, c'è un "piccolo" problema. La media (mediana e moda) di questo numero (il numero di diversi ASN origin) è di circa 150 e, anche considerando il filtraggio dei piccoli prefissi, rimarrà oltre 70. Questa situazione ha una spiegazione abbastanza semplice: ci sono solo pochi operatori che già applicano filtri ROA con la politica di "resettare i percorsi Invalid" ai punti di ingresso, quindi, doveunque nel mondo reale un percorso che viola il ROA appaia, può diffondersi in tutte le direzioni.
Gli ultimi due approcci consentono di trovare operatori che hanno visto il nostro incidente (poiché era abbastanza grande), ma in generale non sono applicabili. Bene, ma possiamo trovare l'autore dell'attacco? Quali sono le caratteristiche comuni di tale manipolazione AS_PATH? Ci sono alcune ipotesi di base:
- Il prefisso non era mai stato notato prima;
- L'ASN origin (ricordate: il primo ASN nell'AS_PATH) è valido;
- L'ultimo ASN nell'AS_PATH è l'ASN dell'attaccante (nel caso in cui il suo vicino controlli l'ASN del vicino su tutti i percorsi in ingresso);
- L'attacco proviene da un solo fornitore.
Se tutte le ipotesi sono vere, allora su tutti i percorsi non validi sarà rappresentato l'ASN dell'attaccante (escluso l'ASN origin) e, pertanto, questo è un "punto critico". Tra i veri rapitori c'era anche l'AS263444, anche se ce ne sono stati altri. Anche quando abbiamo escluso i percorsi dell'incidente dalla considerazione. Perché? Il punto critico può rimanere critico anche per i percorsi validi. Può essere il risultato di una scarsa connettività in qualche regione o di limitazioni nella nostra visibilità.
Di conseguenza: esiste un modo per rilevare l'attaccante, ma solo se soddisfa tutte le condizioni sopra elencate e solo quando l'intercettazione è sufficientemente grande per superare le soglie di monitoraggio. Se alcuni di questi fattori non sono rispettati, possiamo identificare i prefissi colpiti da tale intercettazione? Per alcuni operatori - sì.
Quando l'attaccante crea un percorso more specific, tale prefisso non è annunciato dal legittimo proprietario. Se disponete di una lista dinamica di tutti i suoi prefissi, si presenta l'opportunità di effettuare un confronto e trovare i percorsi more specific distorti. Raccogliamo questo elenco di prefissi tramite le nostre sessioni BGP, poiché ci vengono forniti non solo l'elenco completo dei percorsi visibili dall'operatore in questo momento, ma anche l'elenco di tutti i prefissi che desidera annunciare al mondo. Sfortunatamente, attualmente esistono diverse decine di utenti di Radar che non eseguono correttamente quest'ultima parte. Presto li informeremo e cercheremo di risolvere questo problema. Tutti gli altri possono unirsi al nostro sistema di monitoraggio già adesso.
Tornando all'incidente iniziale, sia l'attaccante che l'area di diffusione sono stati scoperti grazie alla ricerca di punti critici. Sorprendentemente, l'AS263444 ha diffuso 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 intercettare il nostro spazio indirizzi
Quando sono stati creati i more specific per i nostri prefissi, è stato utilizzato un AS_PATH appositamente creato. Tuttavia, questo AS_PATH non poteva essere preso da nessuno dei nostri percorsi precedenti. Non abbiamo nemmeno collegamenti con AS6762. Guardiamo altri percorsi nell'incidente: alcuni di essi avevano un vero AS_PATH che era stato utilizzato precedentemente, mentre altri no, anche se apparivano come veri. Un ulteriore cambiamento dell'AS_PATH non ha alcun senso pratico, poiché in ogni caso il traffico verrebbe reindirizzato all'autore dell'attacco, ma i percorsi con un 'cattivo' AS_PATH possono essere filtrati da ASPA o da qualsiasi altro meccanismo di verifica. Qui ci siamo chiesti quali potessero essere le motivazioni dell'attaccante. Attualmente ci mancano dati per affermare che questo incidente fosse un attacco pianificato. Tuttavia, è possibile. Proviamo a immaginare una situazione, seppur ipotetica, ma potenzialmente realistica.
Attacco ideale
Cosa abbiamo? Supponiamo di essere un fornitore di transito che trasmette percorsi per i propri clienti. Se i vostri clienti hanno una presenza multipla (multihome), riceverete solo una parte del loro traffico. Ma più traffico c'è, maggiore è il vostro guadagno. Quindi, se iniziate ad annunciare i prefissi delle sotto-reti di questi stessi percorsi con lo stesso AS_PATH, otterrete il resto del loro traffico. Di conseguenza, anche il resto del denaro.
Aiuterà qui il ROA? Forse sì, se decidete di rinunciare completamente all'uso . Inoltre, in questo caso è estremamente indesiderabile avere registrazioni ROA con prefissi sovrapposti. Per alcuni operatori tali restrizioni sono inaccettabili.
Considerando altri meccanismi di sicurezza per il routing, in questo caso ASPA non aiuta nemmeno (poiché utilizza l'AS_PATH da un percorso autorizzato). BGPSec rimane comunque non ottimale a causa della bassa percentuale di adozione e della possibilità rimanente di attacchi di downgrade.
Pertanto, abbiamo un chiaro vantaggio per l'attaccante e una mancanza di sicurezza. Una miscela eccellente!
Cosa bisogna fare?
Il passo ovvio e più radicale è rivedere la vostra attuale politica di routing. Suddividete il vostro spazio indirizzi in pezzi più piccoli (senza sovrapposizioni) che solo volete annunciare. Firmate il ROA solo per essi, senza utilizzare il parametro maxLength. In questo caso, l'attuale POV potrebbe salvarvi da un attacco simile. Tuttavia, ancora una volta, per alcuni operatori questo approccio non è razionale a causa dell'uso esclusivo di percorsi more specific. Tutti i problemi dell'attuale stato del ROA e degli oggetti di routing saranno descritti in uno dei nostri futuri materiali.
Inoltre, si può tentare di monitorare tali intercettazioni. Per questo abbiamo bisogno di informazioni affidabili sui vostri prefissi. Pertanto, se stabilite una sessione BGP con il nostro collettore e ci inviate informazioni sulla vostra visibilità su Internet, possiamo individuare l'area di diffusione e per altri incidenti. Per coloro che non sono ancora collegati al nostro sistema di monitoraggio, per iniziare ci basterebbe un elenco di percorsi con solo i vostri prefissi. Se invece avete stabilito una sessione con noi, vi preghiamo di verificare che tutti i vostri percorsi siano stati inviati. Purtroppo è necessario ricordarlo, poiché alcuni operatori dimenticano uno o due prefissi e, in questo modo, creano interferenze nei nostri metodi di ricerca. Se tutto viene fatto correttamente, avremo dati affidabili sui vostri prefissi che in futuro aiuteranno a identificare automaticamente e rilevare tali (e altri) tipi di intercettazioni di traffico per il vostro spazio indirizzi.
Se scoprite in tempo reale un'intercettazione del vostro traffico, potete tentare di reagire autonomamente. Il primo approccio è annunciare percorsi con questi prefissi more specific da soli. In caso di un nuovo attacco su questi prefissi, ripetere.
Il secondo approccio è punire l'attaccante e coloro che sono un punto critico per lui (per buoni percorsi), tagliando l'accesso dei vostri percorsi all'attaccante. Questo può essere fatto aggiungendo l'ASN dell'attaccante all'AS_PATH dei vostri percorsi vecchi e, in questo modo, costringerli a evitare quest'AS, utilizzando il meccanismo di rilevamento dei cicli incorporato nel BGP. .
Fonte: habr.com
