Unicast RPF On the Edge


10

Si suppone che Unicast RPF prevenga indirizzi di origine diversi da quelli che dovrebbero essere autorizzati. Durante la lettura della documentazione di Cisco per URPF, ho notato che esistono opzioni che consentono di utilizzarlo su un'interfaccia di uplink lasciandolo andare dalla tabella di routing.

La mia domanda è: se sta seguendo una rotta predefinita, non sono ammessi tutti gli indirizzi di origine? Quali benefici porterebbe URPF a quel punto?

Sono sicuro che mi manca qualcosa, quindi mi piacerebbe davvero un punto nella giusta direzione.

Risposte:


15

Unicast Reverse Path Forwarding (RPF) funziona in tre modalità distinte e può potenzialmente aiutare a ridurre il vettore di attacco di un router, in particolare da indirizzi IP contraffatti.

Modalità rigorosa

(config-if)#ip verify unicast source reachable-via rx

In modalità rigorosa, un router ispezionerà e controllerà l'indirizzo IP di origine di un pacchetto in entrata rispetto alla sua tabella FIB (Forwarding Information Base) per un percorso corrispondente. Se il percorso verso quell'indirizzo IP di origine è raggiungibile tramite l'interfaccia su cui è stato ricevuto , il pacchetto verrà ricevuto. Per impostazione predefinita, una route predefinita non viene considerata in modalità rigorosa (come configurato sopra).

Opzioni modalità rigorosa:

A seguito della configurazione della modalità rigorosa Unicast RPF su una determinata interfaccia, un router non può più eseguire il ping su tale interfaccia:

#sh ip int bri | ex unas|Int
FastEthernet0/0            11.0.11.1

#ping 11.0.11.1                                    
.....
Success rate is 0 percent (0/5)

Verifica dei pacchetti rilasciati URPF:

#show ip int fa0/0 | i ^  [1-9]+ verification drops
     5 verification drops
#show ip traffic | i unicast
     0 no route, 5 unicast RPF, 0 forced drop

Questo comportamento può essere modificato aggiungendo la allow-self-pingsintassi:

(config-if)#ip verify unicast source reachable-via rx allow-self-ping

Inoltre, come indicato nella domanda, la modalità rigorosa può consentire di verificare gli indirizzi IP di origine del pacchetto in arrivo rispetto a una route predefinita. Questo è abilitato dalla sintassi allow-default:

In modalità rigorosa, l'aggiunta della sintassi allow-defaultda sola impedirà la ricezione dall'indirizzo IP di origine del pacchetto in entrata che ha un percorso di uscita attraverso un'interfaccia diversa da quella ricevuta. Ciò presuppone che sul router non siano presenti elenchi di accesso o route null. Tutti gli indirizzi di origine instradabili raggiungibili dall'interfaccia che ricevono corrisponderanno a route specifiche o route predefinite.

Tuttavia, se si dovessero utilizzare route nulle, la route più specifica verrà valutata prima, prima che il controllo URPF arrivi alla route predefinita e fungerà da black list per gli intervalli IP dannosi noti.

Esempio: tutto il traffico proveniente da 3.0.0.0/8 verrà eliminato dal controllo URPF:

(config-if)#ip verify unicast source reachable-via rx allow-default
(config)#ip route 3.0.0.0 255.0.0.0 null 0

Bad-Source-RTR#ping 11.0.11.1 so l1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.0.11.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3 
.....
Success rate is 0 percent (0/5)

Inoltre, è possibile specificare un Elenco controllo accessi (ACL) anziché aggiungere la allow-defaultsintassi per realizzare un elenco strutturato di indirizzi consentiti e negati. Gli indirizzi raggiungibili dall'interfaccia su cui sono stati ricevuti e corrispondenti in un ACL definito vengono eliminati o consentiti di conseguenza.

!
access-list 23 permit 3.0.0.0 0.255.255.255
access-list 23 deny   4.0.0.0 0.255.255.255 log
access-list 23 permit any
!
(config)#int fa0/0                                 
(config-if)#ip verify unicast source reachable-via rx 23

Infine, puoi specificare un ACL con la allow-defaultsintassi, ma non avrà alcun effetto. I pacchetti non verranno verificati rispetto agli ACL specificati con l' allow-defaultopzione.

#ip verify unicast source reachable-via rx allow-default ? 
  <1-199>          A standard IP access list number
  <1300-2699>      A standard IP expanded access list number

Modalità sciolta

R1(config-if)#ip verify unicast source reachable-via any

In modalità libera, un router ispezionerà l'indirizzo IP di origine di un pacchetto in entrata e lo verificherà rispetto alla sua tabella FIB per un percorso corrispondente. Se il percorso verso quell'indirizzo IP di origine è raggiungibile, è possibile ricevere il pacchetto, indipendentemente dall'interfaccia su cui è stato ricevuto. Per impostazione predefinita, un percorso predefinito non è considerato in modalità libera (come configurato sopra).

La modalità loose e la modalità rigorosa hanno opzioni di configurazione simili; Le differenze principali sono la sintassi utilizzata ( anyvs. rx) e se l'indirizzo IP di origine del pacchetto in entrata è raggiungibile o meno tramite l'interfaccia su cui è stato ricevuto.

(config-if)#ip verify unicast source reachable-via any ?
  <1-199>          A standard IP access list number
  <1300-2699>      A standard IP expanded access list number
  allow-default    Allow default route to match when checking source address
  allow-self-ping  Allow router to ping itself (opens vulnerability in
                   verification)

Modalità VRF

La modalità VRF può sfruttare la modalità allentata o rigorosa in un dato VRF e valuterà l'indirizzo IP di origine di un pacchetto in entrata rispetto alla tabella VRF configurata per un vicino eBGP.


Riferimenti:
white paper Cisco URPF
Informazioni sulla guida alla configurazione di URPF per l' inoltro del percorso inverso Unicast


Che dire dell'applicazione pratica? Ha davvero senso / una differenza metterlo sul tuo uplink?
codice

3
@codey Non avrei eseguito uRPF su uplink, ma solo su interfacce rivolte al cliente. one.time, +1, buon lavoro, risposte solide, vorrei sottolineare che il percorso statico a null0 in alcune piattaforme non Cisco non farà fallire la modalità "loose". Forse invece di "risposto" dovresti usare "ricevi", cioè i pacchetti RPF falliti non verranno ricevuti. Forse anche "contro tabella di routing" (RIB) dovrebbe essere cambiato in "contro tabella di inoltro" (FIB). Dal momento che c'è un sapore di uRPF chiamato 'fattibile sciolto / rigoroso', che controlla contro RIB (Cisco non lo supporta, controllano solo contro FIB).
ytti,

@ytti Quando ho guardato i documenti Cisco, ho semplicemente detto contro la tabella di routing. Non sto dicendo che sia corretto, ma strano che lo direbbero se fosse solo la FIB.
codice

Immagina il caso in cui il cliente abbia annunciato il prefisso BGP 192.0.2.0/24, hai anche un percorso statico per questo puntamento al core. Se l'interfaccia del cliente ha uRPF / strict, eliminerai i pacchetti dal cliente con l'indirizzo di origine 192.0.2.42, anche se in RIB (tabella di instradamento) questa voce esiste, non è / best / voce e di conseguenza non è in FIB. Tuttavia, se si esegue il pacchetto 'uRPF / rigoroso fattibile' non verrà eliminato (JunOS supporta fattibile, quindi i suoi documenti forniranno ulteriori informazioni).
ytti,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.