BGP & SDN : Seconda puntata - BGP RTBH

Una funzionalità di sicurezza molto interessante, tipicamente utilizzata nelle reti ISP ed Enterprise, è il meccanismo RTBH (Remote Triggered Black-Hole). RTBH utilizza il BGP per contrastare attacchi di tipo DoS (o DDoS, Distributed DoS) verso un Cliente dell’ISP, bloccando il traffico dell’attaccante ai bordi della rete. Questo traffico, oltre a provocare danni all'attaccato, provoca anche danni collaterali alla rete dell'ISP, consumando banda, risorse di elaborazione e potenzialmente provocando il fuori servizio di qualche apparato della rete.

La prima contromisura contro questo tipo di attacchi è l’identificazione dell’attaccante, in particolare dell’indirizzo IP da cui provengono i pacchetti strumento dell’attacco, e l’identificazione dell’Host attaccato. Una volta identificati attaccante e attaccato, tramite un controller centralizzato (es. un controller SDN) si informano i router di edge, da qui in poi indicati come router PE, che il traffico proveniente dall’attaccante (o dagli attaccanti), e/o il traffico diretto all’attaccato, deve essere scartato. In questo modo il traffico strumento dell’attacco, non entra nella rete dell’ISP. L'informazione da controller ai PE, viene veicolata attraverso messaggi BGP UPDATE. L'idea è riassunta nella figura seguente.

Si noti che il controller dovrebbe avere una sessione iBGP con ciascun router PE. Per maggiore scalabilità, poiché le reti ISP utilizzano in modo pervasivo i Route Reflector, è sufficiente avere solo sessioni iBGP tra controller e Router Reflector.

Vi sono due differenti versioni del RTBH:

• Destination-based RTBH: in questa versione, il traffico verso l’indirizzo IP del Cliente oggetto di attacco, viene scartato dai router PE. Si noti che questo approccio fa in un certo senso il gioco dell’attaccante, il cui scopo è mettere in difficoltà il Cliente (e non l’ISP). Il meccanismo salvaguarda infatti la sola rete dell’ISP. Comunque, una volta capita la sorgente dell’attacco, l’ISP può investigare più a fondo l’attacco e mettere in campo ulteriori contromisure per contrastarlo.
• Source-based RTBH: in questa versione, il traffico proveniente dall’indirizzo IP (o da un insieme di indirizzi IP) dell’attaccante viene scartato dai router PE. Questa versione del RTBH richiede, come vedremo sotto, l’utilizzo del controllo uRPF (unicast Reverse Path Forwarding), tipicamente nella versione loose, ma può essere utilizzata anche la versione strict.

Il vantaggio del source-based RTBH rispetto a quello destination-based, è che il traffico "legittimo" verso il target dell'attacco può continuare a fluire regolarmente. Lo svantaggio è che purtroppo in molti attacchi di tipo DDoS, è difficile capire le sorgenti dell’attacco, che sono molte e cambiano continuamente.

Nelle prossime due sezioni vedremo due esempi di RTBH, uno per ciascuna versione. RTBH utilizza funzionalità ordinarie del BGP ossia, non vi è bisogno di funzionalità BGP particolari per il suo supporto. Il funzionamento del BGP RTBH è stato descritto, per la versione destination-based, nella RFC 3882 - Configuring BGP to Block Denial-of-Service Attacks, Settembre 2004, mentre la versione source-based è descritta nella RFC 5635 - Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF), Agosto 2009, dove è anche possibile trovare una breve storia e degli esempi di configurazione nei router Cisco e Juniper. Nella RFC 3882 è descritto un interessante approccio basato sull'attributo BGP Community, concettualmente analogo a quanto illustrerò nel seguito.

DESTINATION-BASED RTBH

Nella configurazione del destination-based RTBH, tre sono i passi principali da svolgere, di cui uno va effettuato una volta rilevato l’attacco.

• Prima dell’attacco, tutti i router PE devono essere configurati con una route statica verso un prefisso non utilizzato (ad esempio, un indirizzo martian o privato della RFC 1918). Negli esempi seguenti, utilizzerò per questo il prefisso martian 192.0.2.0/24. La route statica deve avere come next-hop l’interfaccia virtuale bit bucket (null0 nel linguaggio Cisco, discard/reject nel linguaggio Juniper). Un indirizzo IP del prefisso 192.0.2.0/24, in particolare il 192.0.2.1 verrà utilizzato come next-hop per il traffico che deve essere bloccato. In luogo del prefisso 192.0.2.0/24, riservato dallo IANA a scopo di test, è anche possibile utilizzare un qualsiasi prefisso martian o anche i prefissi (privati) della RFC 1918. Qualche anno fa, vedi RFC 6666, A Discard Prefix for IPv6, Agosto 2012, IANA ha definito un prefisso analogo per IPv6, da utilizzare, ad esempio per il RTBH. Il prefisso in questione è 0100::/64.
• Il controller centralizzato, una volta rilevato l’attacco, ossia una volta rilevato l’indirizzo IP destinazione oggetto dell’attacco, avrà il compito di comunicare agli altri router di bloccare il traffico diretto verso l'indirizzo oggetto di attacco. Su questo router, sotto il processo BGP viene configurata una redistribuzione di route statiche nel BGP, controllata da una route-policy. La route-policy, a partire da route statiche configurate con un determinato valore di tag, crea annunci BGP del prefisso a cui punta la route statica, con gli attributi NEXT_HOP = un indirizzo del prefisso martian scelto nel punto precedente (es. 192.0.2.1), LOCAL_PREF = un valore molto elevato (es. 5000) e COMMUNITY = no-export. Il valore di LOCAL_PREF è scelto molto grande per fare in modo che l’annuncio generato sia preferito rispetto ad altri annunci dello stesso prefisso. Nell’annuncio è presente anche la COMMUNITY = no-export, per evitare che questo annuncio venga esportato al di fuori dell’AS dell’ISP.
• Una volta rilevato l’attacco, sul controller va configurata una route statica verso la destinazione dell’attacco, con next-hop l’interfaccia virtuale bit bucket e valore di tag identico a quello specificato nel punto precedente.

A seguito della configurazione di quest’ultima route statica, il controller redistribuisce, attraverso una opportuna configurazione, la route statica a tutti i router PE, creando un annuncio del prefisso destinazione dell'attacco, con gli attributi BGP descritti nel secondo passo di configurazione. I router PE, alla ricezione dell'annuncio, installeranno nella propria FIB (non RIB !) un entry per la destinazione dell'attacco, con next-hop il bit bucket. La ragione per cui avviene questo è che, come specificato nel primo punto sopra, sui PE viene configurata preliminarmente una route statica verso il prefisso martian utilizzato (es. 192.0.2.0/24) con next-hop l’interfaccia virtuale bit bucket. Componendo l'annuncio BGP del secondo punto con questa route statica, si ottiene l'entry sulla FIB per la destinazione dell'attacco, con next-hop il bit bucket.

A questo punto, quando un router riceverà traffico diretto verso la destinazione dell'attacco, effettuerà un lookup sulla FIB, che restituirà come next-hop l’interfaccia virtuale bit bucket. Ne consegue che tutti i pacchetti diretti verso la rete 195.31.0.0/24 oggetto dell’attacco verranno scartati.

La figura seguente riporta una prova di laboratorio che ho effettuato in ambiente Cisco. Il controller è simulato da un router che utilizza l'IOS XR. I router RR, PE1 e PE2 utilizzano il classico IOS. Il router RR svolge anche la funzione di Route Reflector. 

I parametri utilizzati sono i seguenti:

• prefisso martian : 192.0.2.0/24;
• tag = 100;
• local preference = 5000.

Su tutti i router (inclusi RR e controller) è configurata la seguente route statica:

ip route 192.0.2.0 255.255.255.0 null0

Si noti che questa route statica è necessaria anche sul RR e sul controller solo per fare in modo che il BGP Next-Hop 192.0.2.1 sia raggiungibile (vedi nota sotto). 

Le configurazioni rilevanti sul controller sono le seguenti:

route-policy DB-RTBH

  if tag is 100 then

    set next-hop 192.0.2.1

    set community (no-export)

    set local-preference 5000

  endif

end-policy

!

router bgp 3269

  address-family ipv4 unicast

   redistribute static route-policy DB-RTBH

!

Dopo aver rilevato la destinazione dell'attacco, nella figura un host della LAN 195.31.0.0/24, sul controller si aggiunge la seguente route statica:

router static

  address-family ipv4 unicast

    195.31.0.0/24 null0 tag 100

Se l'attacco fosse a un Host specifico, ad esempio 195.31.0.1, per evitare di bloccare il traffico verso gli altri Host della LAN si potrebbe, in alternativa, configurare una route statica specifica verso l'Host attaccato, come segue:

router static

  address-family ipv4 unicast

    195.31.0.1/32 null0 tag 100

NOTA: La presenza della route statica "ip route 192.0.2.0 255.255.255.0 null0" sul controller fa si che il comando di redistribuzione statica abbia effetto. Sul controller infatti, poiché la rete 195.31.0.0/24 viene inserita nella tabella BGP, grazie alla route-policy, con BGP Next-Hop 192.0.2.1, è necessario in tabella di routing un percorso per raggiungere l'indirizzo 192.0.2.1; senza di questo il BGP non elegge il percorso locale verso la rete 195.31.0.0/24 come best path, e quindi non è in grado di propagarlo via iBGP al RR. Allo stesso modo, sul RR la route statica consente di inserire in tabella di routing un percorso verso il BGP Next-Hop 192.0.2.1, senza del quale l'annuncio della rete 195.31.0.0/24 ricevuto dal controller non diverrebbe best path e quindi non potrebbe essere propagato ai router PE.

Per verificare che la configurazione abbia avuto effetto, di seguito riporto l'entry della tabella CEF sul router PE2, ossia il router da dove entra il traffico dell'attaccante, relativo alla rete attaccata 195.31.0.0/24, prima e dopo aver rilevato l'attacco.

PRIMA DELL'ATTACCO

PE2# show ip cef 195.31.0.0
195.31.0.0/24, version 25, epoch 0, cached adjacency 172.16.2.11
0 packets, 0 bytes
  via 192.168.0.1, 0 dependencies, recursive
    next hop 172.16.2.11, FastEthernet2/1 via 192.168.0.1/32
    valid cached adjacency

DOPO L'ATTACCO

PE2# show ip cef 195.31.0.0
195.31.0.0/24, version 24, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.0/24
    valid null adjacency

Come si può notare, prima dell'attacco sul router PE2 è presente una adiacenza CEF valida con next-hop effettivo 172.16.2.11. Dopo aver rilevato l'attacco e dopo che il controller prende la sua contromisura, la stessa adiacenza diventa "null adjacency", che indica che i pacchetti diretti verso la rete 195.31.0.0/24 vengono scartati.

SOURCE-BASED RTBH

L'implementazione della versione source-based è in parte identica a quella già vista per la versione destination-based. Le configurazioni sul controller da eseguire prima della rilevazione dell'attacco sono assolutamente identiche a quelle della versione destination-based. Le differenze sono due:

• Su ciascuna interfaccia da dove ci si aspetta un attacco (ad esempio, su tutte le interfacce dei router PE lato esterno all'AS), si implementa il controllo uRPF di tipo strict o loose. Ricordiamo che il controllo uRPF di tipo loose consiste nell’effettuare un lookup della tabella FIB basato sull’indirizzo IP sorgente, e accettare un pacchetto se e solo se l’indirizzo IP sorgente è raggiungibile attraverso un entry della tabella FIB. Nel caso in cui un entry sia assente o vi è un entry con next-hop il bit bucket, il pacchetto viene scartato. Il controllo uRPF di tipo strict consiste sempre nell’effettuare un lookup della tabella FIB basato sull’indirizzo IP sorgente, ma in questo caso un pacchetto viene accettato se e solo se l’indirizzo IP sorgente è raggiungibile attraverso la stessa interfaccia da cui si riceve il pacchetto. Si noti che la versione strict non sempre funziona in caso di routing asimmetrico, per cui si preferisce spesso utilizzare la versione loose.
• Una volta rilevato l’attacco, sul controller va configurata una route statica verso la sorgente dell’attacco, con next-hop l’interfaccia virtuale bit bucket e valore di tag come specificato nella versione destination-based.

Adattando l’esempio visto per la versione destination-based alla versione source-based, la configurazione della route-policy sul controller rimane identica.  Le modifiche da apportare sono le seguenti:

• Su tutte le interfacce dei router PE lato esterno all'AS, si abilita la versione loose di uRPF, con il comando a livello interfaccia "ipv4 verify unicast source reachable-via any".
• Dopo aver rilevato la sorgente dell'attacco, nella figura un Host della LAN 2.1.1.0/24, sul controller si aggiunge la seguente route statica:

        router static

            address-family ipv4 unicast

                 2.1.1.0/24 null0 tag 100

La conseguenza è che questo traffico viene scartato proprio perché il controllo uRPF da esito negativo, a causa della presenza nella FIB dei router PE, di un entry verso la sorgente dell'attacco (Host della rete 2.1.1.0/24), con next-hop il bit bucket.  Questo è confermato dalla visualizzazione dell'entry della tabella CEF sul router PE2, ossia il router da dove entra il traffico dell'attaccante, relativo alla sorgente dell'attacco 2.1.1.0/24, prima e dopo aver rilevato l'attacco.

PRIMA DELL'ATTACCO

PE2# show ip cef 2.1.1.0
2.1.1.0/24, version 25, epoch 0, cached adjacency 10.2.21.2
0 packets, 0 bytes
  via 10.2.21.2, 0 dependencies, recursive
    next hop 10.2.21.2, FastEthernet0/0 via 10.2.21.2/32
    valid cached adjacency

DOPO L'ATTACCO

PE2# show ip cef 2.1.1.0
2.1.1.0/24, version 24, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.0/24
    valid null adjacency

Come si può notare, dopo aver rilevato l'attacco e dopo che il controller prende la sua contromisura, l'adiacenza relativa all'entry 2.1.1.0/24 diventa "null adjacency". Quindi, a causa di quanto detto sopra, i pacchetti provenienti dalla rete 2.1.1.0/24 vengono scartati a causa del controllo uRPF.

CONCLUSIONI
RTBH è una vecchia conoscenza del mondo degli ISP, ampiamente utilizzato da tempo per contrastare attacchi di tipo DDoS. E' stato accostato recentemente al concetto di SDN poiché, come visto in questo post, l'idea di fondo utilizza un controller centralizzato per inviare ai router di edge (PE) di una rete, un trigger che consente di bloccare il traffico generato da un attaccante verso un Host attaccato. 

Il trigger viene viene inviato via BGP, ma in teoria potrebbe tranquillamente essere inviato come una "regola OpenFlow" da un OpenFlow controller. A quanto mi risulta è stato fatto un tentativo di utilizzare RTBH congiuntamente a OpenFlow, utilizzando la versione 1.0 di quest'ultimo (vedi questo link). Per il resto nulla (commenti su questo sono benvenuti). Resta il fatto che se volete una soluzione iper-collaudata, semplice e supportata da tutti maggiori vendor di apparati (Cisco, Juniper e tutti gli altri), non vi resta che il BGP RTBH, o ... la sua evoluzione BGP Flowspec, che sarà l'oggetto del prossimo post. Il BGP RTBH ha un funzionamento molto "brutale", ossia ha una sola opzione a disposizione, scartare il traffico verso l'attaccato (versione destination-based) o proveniente dall'attaccante (versione source-based). BGP Flowspec offre invece anche altre opzioni, per cui ... arrivederci alla prossima (terza) puntata.