Unicast Reverse Path Forwarding (uRPF)

Unicast Reverse Path Forwarding (uRPF)

uRPF est une feature permettant d'éviter l'IP Spoofing.
Lorsque urpf est activé sur une interface, le routeur examine chaque paquet reçu en entrée.
Il vérifie ensuite que les paquets arrivent bien par l'interface représentant la 'best return path' vers la source.
Pour cela, urpf effectue un reverse lookup dans la table CEF.

- Si le paquet arrive par la bonne interface, il est forwarded.
- Si le paquet arrive par une interface autre que l'interface inscrite dans la FIB, le paquet est détruit.

Il est possible de créer des exceptions via une acl.

Strict Mode uRPF
Configuration d'uRPF 'strict'
Router(config)# ip cef
Router(config-if)# interface type
Router(config-if)# ip verify unicast source ip verify unicast source reachable-via list

'list' correspond à une acl.
Si cette acl permet une plage d'ip, cette plage à le 'droit' d'être spoofée, le paquet est donc forwardé.
Si cette acl deny une plage d'ip, cette plage ne peut être spoofée, le paquet est détruit (comportement normal).

Pour permettre au routeur de répondre à ses propres requêtes icmp:
ip verify unicast source reachable-via rx allow-self-ping

Loose Mode uRPF
Avec strict mode uRPF, un problème apparait que lorsque le trafic est asymétrique (internet).
Pour éviter cela, on utilise loose mode uRPF.
Dans ce mode, il suffit que la source soit présente dans la table de routage pour que le paquet soit forwardé (quelque soit l'interface de sortie).
Dans le cas contraire, il est détruit.

Configuration d'uRPF 'loose'
Router(config)# ip cef
Router(config-if)# interface type
Router(config-if)# ip verify unicast source reachable-via any

Ici, à partir du moment où une entrée pour joindre l'adresse IP source se trouve dans la table de routage, le trafic est forwardé.
En option, il est possible de spécifier une acl.

ip verify unicast source reachable-via {rx | any} [allow-default] [allow-self-ping] [list] [l2-src] [phys-if]

Divers timers sont configurables pour le calcul du 'drop rate':
ip verify drop-rate compute interval
ip verify drop-rate compute window
ip verify drop-rate notify hold-down
Pour être notifié en cas de dépassement du seuil de paquets détruit:
ip verify unicast notification threshold
(Default is 1000)

Remotely-Triggered Black Hole - RTBH

RTBH est une technique permettant d'éviter qu'une attaque DDoS surcharge la capacité du réseau opérateur.

La technique consiste à envoyer l'ensemble du trafic à destination d'un routeur client vers un black hole.

R2 et R4 constituent le cœur de réseau de l'opérateur.

R5 est le client.
R3 est le routeur permettant l'injection de routes.
R1 représente internet.

Les routeurs R2, R3 et R4 sont dans le même IGP.
Une session iBGP existe entre R2 et R3 et entre R2 et R4. R2 est RR.

R1 et R2 possèdent une session eBGP permettant l'échange des préfixes 150.1.1.1 et 150.5.1.1.

Un DDoS est effectué vers R5, 150.5.1.1.

Les étapes pour effectuer le RTBH sont:
1\ Création d'une route vers Null0 pour un préfixe 'bidon', en général, le TEST-NET (RFC3330), 192.0.2.0/24.
Cette route est présente sur l'ensemble des routeurs de Cœur.

ip route 192.0.2.0 255.255.255.0 Null0 name RTBH

2\ Sur le routeur injectant la route, R3, il faut installer une route statique vers le préfixe attaqué et la faire pointer vers Null0 ( de manière à pouvoir annoncer ce network).
Un tag est ajouté sur la route pour pouvoir effectuer un match dans une route-map.
R3:

ip route 150.5.1.1 255.255.255.255 Null0 tag 666

3\ Toujours sur R3, il faut redistribuer cette route vers le préfixe attaqué.
Une route-map est configurée de manière à modifier le next-hop en 192.0.2.1, qui ira donc pointer vers Null0 pour chaque routeur de coeur.
Cette route-map permet également de faire préférer cette route par rapport à l'originale:

!
route-map RTBH permit 10
match tag 666
set local-preference 700
set origin igp
set ip next-hop 192.0.2.1
!
route-map RTBH permit 20
!

Enfin,

router bgp 3352
redistribute static route-map RTBH

!
Résultat:
Sur R4, à l'origine, la route était apprise correctement:

R4#sh ip route 150.5.1.1
Routing entry for 150.5.1.1/32
Known via "bgp 3352", distance 20, metric 0
Tag 65535, type external
Last update from 150.1.45.5 01:10:58 ago
Routing Descriptor Blocks:
* 150.1.45.5, from 150.1.45.5, 01:10:58 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65535

Suite aux modifications, elle est apprise de la manière suivante:
R4#sh ip route 150.5.1.1
Routing entry for 150.5.1.1/32
Known via "bgp 3352", distance 200, metric 0, type internal
Last update from 192.0.2.1 00:00:08 ago
Routing Descriptor Blocks:
* 192.0.2.1, from 150.2.1.1, 00:00:08 ago
Route metric is 0, traffic share count is 1
AS Hops 0

Et ce, sur chaque routeur de cœur.
L'interêt réside dans le fait que l'action n'est pas effectuée sur l'ensemble des routeurs de cœur, mais bien à partir d'un point centralisé.

L'inconvénient est que le DDoS à réussi, tout le trafic à destination du client est black-holed.