Unicast RPF On the Edge


10

Unicast RPF est censé empêcher les adresses source qui diffèrent de ce qu'elles devraient être autorisées. En lisant la documentation de Cisco pour URPF, j'ai remarqué qu'il existe des options pour lui permettre d'être utilisé sur une interface de liaison montante en le laissant passer par la table de routage.

Ma question est, si elle passe par une route par défaut, toutes les adresses source ne seraient-elles pas autorisées? Quel avantage l'URPF ferait-il à ce stade?

Je suis sûr que je manque quelque chose, donc j'aimerais vraiment un point dans la bonne direction.

Réponses:


15

Unicast Reverse Path Forwarding (RPF) fonctionne dans trois modes distincts et peut potentiellement aider à réduire le vecteur d'attaque d'un routeur, en particulier à partir d'adresses IP usurpées.

Mode strict

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

En mode strict, un routeur inspectera et vérifiera l'adresse IP source d'un paquet entrant par rapport à sa table FIB (Forwarding Information Base) pour une route correspondante. Si la route vers cette adresse IP source est accessible via l'interface sur laquelle elle a été reçue , le paquet sera reçu. Par défaut, un itinéraire par défaut n'est pas considéré en mode strict (comme configuré ci-dessus).

Options du mode strict:

Suite à la configuration du mode strict Unicast RPF sur une interface donnée, un routeur ne peut plus se cingler sur cette interface:

#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)

Vérification des paquets abandonnés 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

Ce comportement peut être modifié en ajoutant la allow-self-pingsyntaxe:

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

De plus, comme mentionné dans votre question, le mode strict peut permettre de vérifier les adresses IP source des paquets entrants par rapport à une route par défaut. Ceci est activé par la syntaxe allow-default:

En mode strict, l'ajout de la syntaxe allow-defaulten elle-même n'empêchera que la réception de l'adresse IP source du paquet entrant qui a une route via une interface différente de celle reçue. Cela suppose qu'il n'y a aucune liste d'accès ou route nulle configurée sur le routeur. Toutes les adresses source routables qui sont accessibles via l'interface qu'elles ont reçues correspondront à des routes spécifiques ou à la route par défaut.

Cependant, si vous deviez utiliser des routes nulles, la route la plus spécifique sera évaluée en premier, avant que la vérification URPF n'atteigne la route par défaut, et agira comme une liste noire pour les plages IP malveillantes connues.

Exemple - Tout le trafic provenant de 3.0.0.0/8 sera supprimé par la vérification 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)

De plus, vous pouvez spécifier une liste de contrôle d'accès (ACL) au lieu d'ajouter la allow-defaultsyntaxe pour accomplir une liste structurée d'adresses autorisées et refusées. Les adresses accessibles depuis l'interface sur laquelle elles ont été reçues et mises en correspondance dans une ACL définie sont supprimées ou autorisées en conséquence.

!
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

Enfin, vous pouvez spécifier une ACL avec la allow-defaultsyntaxe, mais cela n'aura aucun effet. Les paquets ne seront pas vérifiés par rapport aux ACL spécifiées avec l' allow-defaultoption.

#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

Mode lâche

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

En mode lâche, un routeur inspectera l'adresse IP source d'un paquet entrant et la comparera à sa table FIB pour un itinéraire correspondant. Si la route vers cette adresse IP source est accessible, le paquet peut être reçu, quelle que soit l'interface sur laquelle il a été reçu. Par défaut, un itinéraire par défaut n'est pas considéré en mode lâche (comme configuré ci-dessus).

Le mode lâche et le mode strict ont des options de configuration similaires; Les principales différences sont la syntaxe utilisée ( anyvs. rx) et si l'adresse IP source du paquet entrant est accessible via l'interface sur laquelle il a été reçu.

(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)

Mode VRF

Le mode VRF peut tirer parti du mode lâche ou strict dans un VRF donné et évaluera l'adresse IP source d'un paquet entrant par rapport à la table VRF configurée pour un voisin eBGP.


Références:
Livre blanc Cisco URPF
Comprendre le guide de configuration URPF pour le transfert de chemin inverse Unicast


Qu'en est-il de l'application pratique? Cela a-t-il vraiment un sens / une différence de le mettre sur votre liaison montante?
codé

3
@codey Je n'exécuterais pas uRPF sur la liaison montante, uniquement sur les interfaces orientées client. one.time, +1, bon travail, réponses solides, je voudrais souligner que la route statique vers null0 sur certaines plates-formes non Cisco n'entraînera pas l'échec du mode `` lâche ''. Peut-être qu'au lieu de «répondu», vous devriez utiliser «recevoir», c'est-à-dire que les paquets échoués RPF ne seront pas reçus. Peut-être aussi que «contre table de routage» (RIB) devrait être remplacé par «contre table de transfert» (FIB). Puisqu'il existe une saveur de uRPF appelée «faisable lâche / stricte», qui vérifie contre RIB (Cisco ne le prend pas en charge, ils vérifient uniquement contre FIB).
ytti

@ytti Quand j'ai regardé les documents Cisco, il a simplement dit contre la table de routage. Je ne dis pas que c'est correct, mais bizarre qu'ils diraient que si c'était juste le FIB.
codé

Imaginez le cas où le client a annoncé le préfixe BGP 192.0.2.0/24, vous avez également un itinéraire statique pour ce pointage vers le noyau. Si l'interface client a uRPF / strict, vous supprimerez les paquets du client ayant l'adresse source 192.0.2.42, même si dans RIB (table de routage) cette entrée existe, ce n'est tout simplement pas / best / entry, et par conséquent, ce n'est pas dans FIB. Cependant, si vous exécutez le paquet 'uRPF / strict faisable' ne sera pas abandonné (JunOS prend en charge faisable, donc ses documents donneront des informations supplémentaires).
ytti
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.