Unicast-RPF am Rande


10

Unicast-RPF soll verhindern, dass Quelladressen von den zulässigen abweichen. Beim Lesen der Dokumentation von Cisco für URPF habe ich festgestellt, dass es Optionen gibt, mit denen die Verwendung auf einer Uplink-Schnittstelle ermöglicht wird, indem sie an der Routing-Tabelle weitergeleitet wird.

Meine Frage ist, ob auf einem Standardweg nicht alle Quelladressen zulässig sind. Welchen Nutzen würde URPF zu diesem Zeitpunkt bringen?

Ich bin mir sicher, dass mir etwas fehlt, also möchte ich wirklich einen Punkt in die richtige Richtung.

Antworten:


15

Unicast Reverse Path Forwarding (RPF) funktioniert in drei verschiedenen Modi und kann möglicherweise dazu beitragen, den Angriffsvektor eines Routers zu reduzieren, insbesondere durch gefälschte IP-Adressen.

strikter Modus

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

Im strengen Modus überprüft und überprüft ein Router die Quell-IP-Adresse eines eingehenden Pakets anhand der FIB-Tabelle (Forwarding Information Base) auf eine übereinstimmende Route. Wenn die Route zu dieser Quell-IP-Adresse über die Schnittstelle erreichbar ist, auf der sie empfangen wurde , wird das Paket empfangen. Standardmäßig wird eine Standardroute im strengen Modus (wie oben konfiguriert) nicht berücksichtigt.

Strenge Modusoptionen:

Nach der Konfiguration des strengen Unicast-RPF-Modus auf einer bestimmten Schnittstelle kann sich ein Router nicht mehr an diese Schnittstelle pingen:

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

Überprüfung von URPF-verworfenen Paketen:

#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

Dieses Verhalten kann durch Hinzufügen der folgenden allow-self-pingSyntax geändert werden :

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

Wie in Ihrer Frage erwähnt, können im strikten Modus außerdem die Quell-IP-Adressen des eingehenden Pakets anhand einer Standardroute überprüft werden. Dies wird durch die Syntax ermöglicht allow-default:

Im strengen Modus verhindert das Hinzufügen der Syntax allow-defaultselbst nur den Empfang von der Quell-IP-Adresse des eingehenden Pakets, die eine Route über eine andere Schnittstelle als die empfangene hat. Dies setzt voraus, dass auf dem Router keine Zugriffslisten oder Nullrouten konfiguriert sind. Alle routingfähigen Quelladressen, die über die empfangene Schnittstelle erreichbar sind, stimmen entweder mit bestimmten Routen oder mit der Standardroute überein.

Wenn Sie jedoch Nullrouten verwenden, wird die spezifischste Route zuerst ausgewertet, bevor die URPF-Prüfung die Standardroute erreicht, und fungiert als schwarze Liste (n) für bekannte böswillige IP-Bereiche.

Beispiel - Der gesamte von 3.0.0.0/8 bezogene Datenverkehr wird durch die URPF-Prüfung gelöscht:

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

Darüber hinaus können Sie eine Zugriffssteuerungsliste (Access Control Control List, ACL) angeben, anstatt die allow-defaultSyntax hinzuzufügen , um eine strukturierte Liste der zulässigen und verweigerten Adressen zu erstellen. Adressen, die über die Schnittstelle erreichbar sind, auf der sie empfangen wurden, und die in einer definierten ACL übereinstimmen, werden entweder gelöscht oder entsprechend zugelassen.

!
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

Schließlich können Sie eine ACL mit der allow-defaultSyntax angeben , die jedoch keine Auswirkungen hat. Die Pakete werden nicht mit den mit der allow-defaultOption angegebenen ACLs verglichen .

#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

Loser Modus

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

Im Loose-Modus überprüft ein Router die Quell-IP-Adresse eines eingehenden Pakets und vergleicht sie anhand der FIB-Tabelle auf eine übereinstimmende Route. Wenn die Route zu dieser Quell-IP-Adresse erreichbar ist, kann das Paket unabhängig von der Schnittstelle empfangen werden, auf der es empfangen wurde. Standardmäßig wird eine Standardroute im losen Modus (wie oben konfiguriert) nicht berücksichtigt.

Der lose Modus und der strikte Modus haben ähnliche Konfigurationsoptionen. Die Hauptunterschiede sind die verwendete Syntax ( anyvs. rx) und ob die Quell-IP-Adresse des eingehenden Pakets über die Schnittstelle erreichbar ist, auf der es empfangen wurde.

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

VRF-Modus

Der VRF-Modus kann den losen oder strengen Modus in einer bestimmten VRF nutzen und bewertet die Quell-IP-Adresse eines eingehenden Pakets anhand der für einen eBGP-Nachbarn konfigurierten VRF-Tabelle.


Referenzen:
Cisco URPF- Whitepaper Grundlegendes zum URPF-Konfigurationshandbuch für die
Weiterleitung von Unicast-Rückwärtspfaden


Was ist mit der praktischen Anwendung? Macht es überhaupt Sinn / Unterschied, es auf Ihren Uplink zu setzen?
Codey

3
@codey Ich würde uRPF nicht bei Uplink ausführen, sondern nur bei kundenseitigen Schnittstellen. Einmal, +1, gute Arbeit, solide Antworten, möchte ich darauf hinweisen, dass die statische Route zu null0 auf einigen Nicht-Cisco-Plattformen nicht dazu führt, dass der "lose" Modus fehlschlägt. Vielleicht sollten Sie anstelle von "geantwortet" "empfangen" verwenden, dh Pakete mit fehlgeschlagenem RPF werden nicht empfangen. Vielleicht sollte auch 'gegen Routing-Tabelle' (RIB) in 'gegen Weiterleitungstabelle' (FIB) geändert werden. Da es eine uRPF-Variante gibt, die als "machbar lose / streng" bezeichnet wird und gegen RIB prüft (Cisco unterstützt dies nicht, sie prüft nur gegen FIB).
7.

@ytti Als ich mir Cisco-Dokumente ansah, stand einfach gegen die Routing-Tabelle. Ich sage nicht, dass das richtig ist, aber seltsam, dass sie das sagen würden, wenn es nur die FIB wäre.
Codey

Stellen Sie sich einen Fall vor, in dem der Kunde das BGP-Präfix 192.0.2.0/24 angekündigt hat. Sie haben auch eine statische Route für diesen Hinweis auf den Kern. Wenn die Kundenschnittstelle uRPF / strict hat, werden Pakete vom Kunden mit der Quelladresse 192.0.2.42 verworfen, obwohl dieser Eintrag in RIB (Routing-Tabelle) vorhanden ist, ist er einfach nicht / best / entry und folglich nicht in FIB. Wenn Sie jedoch das Paket 'uRPF / strict machbar' ausführen, wird es nicht verworfen (JunOS unterstützt machbar, sodass seine Dokumente zusätzliche Informationen enthalten).
ytti
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.