Per un'Internet più sicura: l'architettura BGP RPKI - parte I

PREMESSA: questo è il primo di tre post scritti congiuntamente dal sottoscritto e da Flavio Luciani, Chief Innovation Officer di NaMeX, che ringrazio per la sua disponibilità a collaborare a questo blog.

Qualsiasi trattazione di aspetti di sicurezza, non può non iniziare con una illustrazione dei possibili tipi di attacco e una analisi delle vulnerabilità. È chiaro che l’intera Internet è vulnerabile ad attacchi ai suoi protocolli di routing. Il BGP, da questo punto di vista non fa eccezione, ed essendo sicuramente il protocollo più importante, è quello su cui focalizzare maggiormente l’attenzione in termini di protezione. 

Le modalità di attacco sono molteplici. Una classificazione grossolana ne individua i seguenti due tipi  fondamentali:

• Attacchi a livello di sessione: possono essere attacchi tendenti ad alterare il flusso dei messaggi BGP, come ad esempio, modifica, inserzione, eliminazione di messaggi; attacchi tendenti ad abbattere la sessione tra due BGP peer; attacchi tendenti a dedurre informazioni confidenziali dall’intercettazione dei messaggi BGP. Tra gli attacchi a livello di sessione è possibile anche annoverare, tutti gli attacchi tipici al protocollo TCP.
• Attacchi Denial of Service (DoS): sono tipi di attacco che tendono a negare il funzionamento di un servizio, ad esempio saturando le risorse di un router (memoria, CPU), o impedire l'accesso a determinati contenuti, propagando informazioni di routing false. 

Vi sono poi comportamenti “non etici” da parte degli amministratori delle reti, che possono essere considerati alla stregua di attacchi. Ricade tra questi, ad esempio, la possibilità di “rubare” banda a un AS, facendo ad esempio transitare il traffico tra due router del proprio AS utilizzando risorse di un altro (ignaro) AS, oppure impedire l'accesso a determinati contenuti, propagando informazioni di routing false.

ATTACCHI DENIAL OF SERVICE (DOS) 

Alcuni degli attacchi citati in precedenza, come ad esempio quelli che portano all’abbattimento fraudolento di una sessione BGP, possono essere considerati come attacchi tendenti a negare il funzionamento del servizio (attacchi DoS). 

Vi sono molti altri tipi di attacco che impediscono lo svolgimento dei servizi offerti dal protocollo BGP. Una lista esaustiva è difficile da compilare per cui ci limiteremo solamente a un paio di esempi. 

Un primo esempio è la negazione del servizio “raggiungibilità degli Host di un prefisso” (prefix hijacking). L’idea è molto semplice. Supponiamo si voglia dirottare il traffico diretto a un determinato prefisso verso il proprio router, per poi scartarlo o analizzarlo. È sufficiente annunciare via BGP il prefisso, e se un BGP peer scegliesse l’annuncio inviato come best-path, il traffico verso il prefisso verrebbe dirottato dal BGP peer verso il router “non etico”, creando di fatto un “buco nero”, ossia un punto della rete dove questo traffico viene scartato per mancanza di un percorso valido. Nel prossimo paragrafo. illustreremo un paio di esempi

Un secondo esempio si ha nei router che implementano il BGP Route Flap Damping. Simulando dei route flap, è possibile mantenere congelato un annuncio per molto tempo, alterando il corretto instradamento del traffico.

Classici attacchi di tipo DoS sono anche quelli tendenti a saturare le risorse di memoria e/o CPU di un router. Ad esempio, inondando un router di annunci BGP, è possibile saturare la memoria di un router; oppure, durante la fase di three-way-handshake della connessione TCP, un attaccante potrebbe inviare una gran quantità di TCP Syn (Syn flooding), senza mai inviare il TCP ACK successivo (ossia, il terzo segmento del three-way-handshake), portando ad un alto utilizzo della CPU, fino al fuori servizio del router. Queste tipologie di attacco esulano però dall'argomento trattato in questa serie di post.

PREFIX HIJACKING

Il Prefix Hijacking è una delle pratiche "malevoli" più in voga per deviare il traffico in un black-hole, o ancor peggio, analizzarlo per scopi non etici (es. spionaggio industriale, spionaggio militare, ecc.). 

Vi sono stati in passato e ancor oggi, migliaia di casi di Prefix Hijacking, qualcuno che ha fatto storia, come ad esempio quello descritto in questo link, avvenuto il 24 Febbraio 2008, quando Pakistan Telecom (AS 17557), ha iniettato, non autorizzato, un annuncio BGP del prefisso 208.65.153.0/24, parte del prefisso 208.65.152.0/22, assegnato da un Regional Internet Registry, al celebre YouTube. Uno degli Upstream Provider di Pakistan Telecom, PCCW Global (AS 3491), ha propagato il prefisso al resto di Internet, permettendo a Pakistan Telecom di attrarre, su scala mondiale parte del traffico diretto a YouTube.

Alla radice di ciò c’è una vulnerabilità insita nel BGP, e cioè che non vi è alcun controllo sull’identità di chi immette i prefissi nell’Internet. In altre parole, non vi è alcun controllo se l’ente che origina un prefisso, è autorizzato a farlo, ossia se ha ricevuto quel prefisso da un Regional Internet Registry.

L’esempio della figura seguente esemplifica il fenomeno. 

L’AS 1 ha ricevuto da un Regional Internet Registry il prefisso 195.31.16.0/20, e quindi è l’unico autorizzato ad annunciarlo nell’Internet. Supponiamo ora che l’AS 5, che non ha questa autorizzazione, vuoi per un errore di configurazione o per comportamento "non etico", annunci lo stesso prefisso. Un generico AS dell’Internet riceverà così due annunci del prefisso 195.31.16.0/20, e se per caso il processo di selezione BGP dovesse scegliere come best path l’annuncio originato dall’AS non autorizzato, il traffico diretto verso quel prefisso verrebbe dirottato in un black-hole, e potenzialmente analizzato. Ad esempio, l’AS 4 della figura, a causa dell’AS_PATH più breve (a parità di Local Preference, come sovente accade in questi casi), sceglierà come best path per il prefisso 195.31.16.0/20, proprio il percorso verso l’AS 5 che ha originato (senza autorizzazione!) l’annuncio.

Quella appena descritta non è l’unica modalità di Prefix Hijacking, anche se una delle più comuni. Un altro esempio di Prefix Hijacking si ha quando, vuoi per un (improbabile) errore di configurazione o per comportamento "non etico", un AS non autorizzato annuncia una subnet di un prefisso che un Regional Internet Registry ha assegnato ad un altro AS. Questa tipologia di Prefix Hijacking è proprio quella all’origine dell’incidente citato sopra e riguardante YouTube.

La figura seguente riporta un esempio. 

Come nell’esempio precedente, l’AS 1 ha ricevuto da un Regional Internet Registry il prefisso 195.31.16.0/20, e quindi è l’unico autorizzato ad annunciarlo nell’Internet. Delle subnet di questo prefisso, previa autorizzazione dell’AS 1, potrebbero essere annunciate da altri AS, ma un AS potrebbe annunciare una subnet anche se non autorizzato.

Ad esempio, nella figura, l’AS 5, senza alcuna autorizzazione annuncia la subnet 195.31.20.0/24. Un AS dell’Internet, nella figura esemplificato dall’AS 4, riceverà così due annunci, uno dell’intero prefisso 195.31.16.0/20, originato dall’AS 1, e uno della subnet 195.31.20.0/24, originato dall’AS 5. Il BGP considera questi due prefissi come diversi e quindi eleggerà due best path, che entrambi andranno nella Tabella di Routing IP (RIB) del router di interconnessione dell’AS 4. Per la regola del Longest Match Prefix, una porzione del traffico diretto al prefisso 195.31.16.0/20, quello diretto verso la subnet 195.31.20.0/24, sarà deviata verso l’AS 5, anche qui finendo in un black-hole.

Alla radice del problema, anche qui vi è il fatto che il BGP non esercita alcun controllo sull’identità di chi immette i prefissi nell’Internet. L’unico strumento possibile è l’implementazione di filtri, che però non tutti utilizzano, e poi aumenterebbe di molto la complessità delle configurazioni e non risolverebbe il problema. Ad esempio, come fa un AS intermedio a sapere se un AS remoto è autorizzato o meno ad annunciare un prefisso? 

L’unica soluzione possibile per risolvere il problema, è quella di metter su un sistema di autorizzazioni, gestito da una o più entità centrali (ad esempio, i Regional Internet Registries), che attraverso l’utilizzo di certificati digitali, consenta di verificare con ragionevole certezza se un AS è o meno autorizzato ad annunciare un determinato prefisso nell’Internet.

Questi aspetti sono l’oggetto dell'architettura BGP RPKI che tratteremo in dettaglio in questi tre post. Prima di passare alla teoria e alla pratica, vediamo di illustrarne i concetti fondamentali.

L'ARCHITETTURA BGP RPKI - INTRODUZIONE

Molti degli incidenti nell’Internet sono causati dalla propagazione di incorrette informazioni di routing. Le più comuni minacce (o errori), come ad esempio prefix hijacking o route leak, sfruttano una vulnerabilità di fondo del protocollo BGP: l’impossibilità di verificare se gli Autonomous System (AS) che propagano gli annunci sono realmente legittimati nel farlo. Infatti, le informazioni sulle proprietà delle risorse Internet (numeri di AS e prefissi) sono contenute all’interno di database pubblici chiamati Internet Routing Registry (IRR), gestiti e mantenuti dai Regional Internet Registry (RIR). Non risiedono quindi all’interno del protocollo BGP.

NOTA: sulla definizione e le tipologie di route leak il lettore interessato può consultare la RFC 7908 - Problem Definition and Classification of BGP Route Leaks, di cui in questo post su questo blog, trovate un riassunto degli aspetti più importanti.

Solo per dare un'idea della dimensione del fenomeno, nel 2018 si sono verificati circa 12.600 incidenti, che hanno interessato il 4,4% di tutti gli AS mondiali. Sono stati circa 3.000 gli AS vittime di almeno un incidente e circa 1.300 gli AS che hanno causato almeno un incidente (Dati RIPE NCC basati su una elaborazione dell'elenco degli incidenti contenuto in http://www.bgpstream.com/). 

Il BGP non ha alcuno strumento per verificare se un AS che annuncia un determinato prefisso nell’Internet sia autorizzato a farlo, ossia se il prefisso annunciato gli è stato assegnato effettivamente da un RIR. Dato che ogni prefisso può essere annunciato e originato da ogni AS, indipendentemente dal suo diritto nel farlo, è necessario un meccanismo out-of-band per aiutare il BGP a verificare quale AS può annunciare quale prefisso.

Questo meccanismo esiste. E’ parte del sistema IRR. Come accennato in precedenza esistono dei database pubblici che contengono le informazioni sulla proprietà dei prefissi, alcuni gestiti dai grandi operatori, altri gestiti dai RIR stessi. E’ ormai ampiamente diffuso generare i filtri a partire dalle informazioni presenti negli IRR. Esiste però un limite a questo sistema: possiamo fidarci di queste informazioni? Purtroppo il sistema IRR è ben lontano dall’essere completo, gli oggetti che rappresentano le informazioni <Prefissi; AS autorizzati> non sono del tutto affidabili, questo perché spesso non vengono aggiornati o contengono informazioni errate.

Per ovviare a questo problema, il gruppo SIDR (Secure Inter Domain Routing) di IETF ha sviluppato nel 2012 un'architettura standard (RFC 6481 - A Profile for Resource Certificate Repository Structure) basato su una struttura pubblica (RPKI, Resource Public Key Infrastructure) con dei database distribuiti (RPKI repository) dove sono contenute le associazioni <Prefissi; AS autorizzati>. A ciascuna associazione è legato un Certificato Digitale, che consente a chi consulta i database, di verificare che le associazioni siano corrette. Tali attestati (prefissi, numeri di AS e certificati digitali) vengono denominati ROA (Route Origin Authorization).

RPKI utilizza il formato dei certificati digitali X.509 con l’estensione per indirizzi IP e ASN (RFC 3779 - X.509 Extensions for IP Addresses and AS Identifiers). I certificati non includono le informazioni di identità ma il loro scopo è solo quello di trasferire il diritto all’uso delle risorse Internet. I RIR svolgono la funzione di Certification Authority (CA) e si occupano dell’emissione dei certificati digitali. L’utilizzo principale dei certificati digitali è quello di validare le chiavi pubbliche e la legittimità di un AS a iniettare nel BGP un determinato blocco di prefissi e di utilizzare un determinato numero di AS.

Per il momento ci fermiamo qui. Arrivederci alla Parte II (la teoria ...).