La funzionalità principale di un router è il forwarding dei pacchetti e non il filtraggio degli stessi.
Un modo alternativo alle ACL per applicare un filtro sui pacchetti basato sulla destinazione consiste nel creare una serie di rotte statiche facendole puntare a Null0, questa tecnica viene comunemente definita come black hole routing o forwarding a null0.
Null0 è una pseudo-interfaccia che funziona in maniera molto simile ai null device di alcuni sistemi operativi ( i.e. /dev/null ), è sempre attiva e non può inoltrare o ricevere traffico. Essendo una pseudo-interfaccia, per il CEF rappresenta una interfaccia non valida, perciò una rotta che punta a null0 viene scartata direttamente a livello di forwarding, CEF o dCEF, senza impatto sul processore del router.
Vediamo un esempio:
interface Null0 no icmp unreachables ! ip route 127.0.0.0 255.0.0.0 null 0 ip route 193.121.1.254 255.255.255.255 null 0
in questo caso il no icmp unreachables serve a prevenire risposte non necessarie quando il traffico viene passato alla null0.
Possiamo quindi affermare che la tecnica del black hole routing sfrutta le capacità di forwarding del router per effettuare il drop dei pacchetti destinati alle reti che vogliamo proteggere.
[NdA Non va confuso con l’uso delle route a null0 utilizzato per l’annuncio delle proprie network nei front-end BGP.]
Supponiamo di essere un ISP. Avremo quindi molti punti di ingresso alla nostra rete: possiamo sfruttare velocemente il metodo del forwarding a null0 per rispondere ad attacchi DoS o DDoS? Esiste un metodo veloce per impostare, ad esempio su tutti i router del front-end internet, una route a null0 per una determinata destinazione, magari la rete di un cliente sotto attacco? Utilizzando i protocolli di routing possiamo attivare le rotte a null0 per mezzo di un aggiornamento della tabella di routing, aggiornamento innescato attraverso la sessione iBGP di un apposito trigger router, remote triggered black hole routing.
Prendiamo come esempio la semplice rete riportata in Figura1, il trigger router è per noi 1720-gllabs-noc (che si comporta anche come destinatario dell’attacco, un semplice ping dal pc, visto lo scopo puramente educativo dell’esperienza ).
Innescando un update della routing table via iBGP, annunciando una route specifica avente un next-hop che punta a null0 e con metrica opportuna, in maniera tale da risultare la rotta preferita, otteniamo il risultato di filtrare l’attacco sugli edge-router della rete in maniera molto veloce.
Per far questo occorre configurare una rete a null0, su tutti i dispositivi che vogliamo innescare, che non sia già presente nei prefissi della nostra rete. Allo scopo può essere utilizzata la rete 192.0.2.0/24:
ip route 192.0.2.0 255.255.255.0 Null0
ovvero la TEST-NET definita nell’ RFC1918 come una IANA Designated Special Use Addresses (DUSA) che non deve essere annunciata su internet, rendendola perciò ottima per l’uso nel black hole routing.
Nella configurazione BGP del trigger router inseriremo:
redistribute static route-map ddos-bh
Il metodo descritto può essere usato anche per il black list filtering, si veda ad esempio l’inibizione a livello IP per l’oscuramento dei siti pedopornografici richiesta agli ISP dal “decreto Gentiloni”.
Tuttavia presenta anche alcuni svantaggi, essendo un filtro destination-based applicare questa metodologia alla network di un nostro cliente – supponendo di essere un ISP – causa l’oscuramento dello stesso. Verrebbe infatti filtrato tutto il traffico, lecito e non , diretto a lui e paradossalmente l’attacco DoS/DDoS avrebbe successo lo stesso, il cliente risulterebbe offline.
Se l’edge router non ha una entry valida nella FIB per l’ip sorgente o questa punta a null0, il pacchetto viene scartato.
Vediamo ora le configurazioni dei due router e i risultati del semplice esempio di figura per bloccare il ping.
Configurazioni
! hostname 1720-gllabs-noc ! interface Loopback200 ip address 200.200.200.200 255.255.255.0 ! interface Loopback888 description BGP-LP ip address 10.10.10.1 255.255.255.255 ! interface Serial0 ip address 10.10.10.250 255.255.255.252 clockrate 4000000 no fair-queue ! router bgp 60888 no synchronization bgp router-id 10.10.10.1 bgp log-neighbor-changes network 200.200.200.0 redistribute static route-map ddos-bh neighbor 10.10.10.249 remote-as 60888 no auto-summary ! ip route 192.0.2.0 255.255.255.0 Null0 ! route-map ddos-bh permit 10 match tag 666 set ip next-hop 192.0.2.1 set local-preference 250 set origin igp set community no-export ! ############################################################################################## hostname 2610-gllabs-isp-edge ! ip cef ! interface Loopback1 ip address 193.121.1.254 255.255.255.0 ! interface Loopback888 description BGP-LP ip address 10.10.10.2 255.255.255.255 ! interface FastEthernet0/0 ip address 192.168.41.25 255.255.255.252 ip verify unicast source reachable-via any duplex auto speed auto ! interface Serial0/1 ip address 10.10.10.249 255.255.255.252 ! router bgp 60888 no synchronization bgp router-id 10.10.10.2 bgp log-neighbor-changes network 193.121.1.0 redistribute connected route-map RedConnBGP neighbor 10.10.10.250 remote-as 60888 ! ip route 192.0.2.0 255.255.255.0 Null0 ! ip access-list standard ACL-RedConnBGP permit 192.168.41.24 0.0.0.3 route-map RedConnBGP permit 5 match ip address ACL-RedConnBGP !
Verifichiamo il corretto ping della destinazione 200.200.200.200 dal pc:
Reply from 200.200.200.200: bytes=32 time=1ms TTL=254 Reply from 200.200.200.200: bytes=32 time=1ms TTL=254 Reply from 200.200.200.200: bytes=32 time=1ms TTL=254
facciamo partire l’innesco con la rotta statica:
1720-gllabs-noc(config)#ip route 192.168.41.26 255.255.255.255 Null0 tag 666
(blocchiamo i pacchetti con ip sorgente uguale a quello del pc, il tag serve per innescare l’update bgp, si veda la route-map ddos-bh).
e vediamo che succede al ping:
[...] Reply from 200.200.200.200: bytes=32 time=1ms TTL=254 Reply from 200.200.200.200: bytes=32 time=1ms TTL=254 Reply from 200.200.200.200: bytes=32 time=1ms TTL=254 Request timed out. Request timed out. Request timed out. [...]
Siamo riusciti nel nostro intento! Per far tornare le cose alla normalità basta annullare l’annuncio via BGP eliminando la statica:
1720-gllabs-noc(config)#no ip route 192.168.41.26 255.255.255.255 Null0 tag 666
La metodologia qui descritta è solo una delle molteplici tecniche che contribuiscono a mitigare attacchi DoS/DDoS e in generale contribuiscono all’infrastructure hardening di un ISP, molto altro lo potete trovate guardando i riferimenti allegati all’articolo.
Concludo citando Barry Raveendran Greene, bgreene AT cisco DOT com:
“As some say, if it can work at UUNET, then 99% of the deployment issues have been covered.“
Riferimenti
ISP Security – Real World Techniques
Remote Triggered Black Hole Filtering and Backscatter Traceback
Barry Raveendran Greene, Cisco Christopher L. Morrow and Brian W. Gemberling, UUNET
Tutorial Abstract: ISP Security 101 Primer
Barry Greene and Roland Dobbins, Cisco
ISP Essentials
ftp://ftp-eng.cisco.com/cons/isp/essentials/Remote%20Triggered%20Black%20Hole%20Filtering-02.pdf
Cisco Unicast Reverse Path Forwarding Loose Mode [PDF]
Cisco Remotely triggered black hole filtering – destination based and source based [White Paper PDF]
