Überprüfung der Kabelquelle und Sicherheit der IP-Adresse
Inhalt
Einleitung
Cisco hat Verbesserungen in Produkten des Cisco Cable Modem Termination System (CMTS) implementiert, die bestimmte Arten von Denial-of-Service-Angriffen auf IP-Adressen-Spoofing und IP-Adressdiebstahl in DOCSIS-Kabelsystemen (Data-over-Cable Service Interface Specifications) verhindern. Die Cisco CMTS-Befehlsreferenz für Kabel beschreibt die Befehlssammlung zur Überprüfung der Kabelquelle, die Teil dieser verbesserten IP-Adresssicherheit ist.
Vorbereitungen
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Voraussetzungen
Es sind keine besonderen Voraussetzungen erforderlich, um den Inhalt dieses Dokuments nachzuvollziehen.
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
Ungeschützte DOCSIS-Umgebung
Eine DOCSIS Media Access Control (MAC)-Domäne ähnelt einem Ethernet-Segment. Ungeschützte Benutzer in diesem Segment sind anfällig für viele Arten von Denial-of-Service-Angriffen, die auf Layer 2- und Layer 3-Adressierung basieren. Darüber hinaus kann es vorkommen, dass die Benutzer aufgrund der fehlerhaften Konfiguration der Adressierung auf den Geräten anderer Benutzer einen schlechteren Service-Level erhalten. Beispiele hierfür:
-
Konfigurieren doppelter IP-Adressen auf verschiedenen Knoten
-
Konfigurieren doppelter MAC-Adressen auf verschiedenen Knoten
-
Die nicht autorisierte Verwendung statischer IP-Adressen anstelle von DHCP-zugewiesenen IP-Adressen (Dynamic Host Configuration Protocol).
-
Die unbefugte Nutzung verschiedener Netzwerknummern innerhalb eines Segments.
-
Endknoten wurden falsch konfiguriert, um ARP-Anfragen für einen Teil des Segment-IP-Subnetzes zu beantworten.
Während sich diese Probleme in einer Ethernet-LAN-Umgebung leicht kontrollieren und beheben lassen, indem die defekten Geräte physisch ermittelt und getrennt werden, sind sie in DOCSIS-Netzwerken aufgrund der potenziell großen Größe des Netzwerks möglicherweise schwieriger zu isolieren, zu beheben und zu vermeiden. Darüber hinaus können Endbenutzer, die Geräte am Kundenstandort (Customer Premise Equipment, CPE) steuern und konfigurieren, möglicherweise nicht von einem lokalen IS-Supportteam profitieren, um sicherzustellen, dass ihre Workstations und PCs nicht absichtlich oder unabsichtlich falsch konfiguriert sind.
Die CMTS CPE-Datenbank
Die Cisco Suite von CMTS-Produkten unterhält eine dynamisch ausgefüllte interne Datenbank mit angeschlossenen CPE-IP- und MAC-Adressen. Die CPE-Datenbank enthält außerdem Details zu den entsprechenden Kabelmodems, zu denen diese CPE-Geräte gehören.
Eine Teilansicht der CPE-Datenbank, die einem bestimmten Kabelmodem entspricht, kann angezeigt werden, indem der versteckte CMTS-Befehl show interface cable X/Y modem Z ausgeführt wird. Hierbei ist X die Linecard-Nummer, Y die Downstream-Port-Nummer und Z der Service Identifier (SID) des Kabelmodems. Z kann auf 0 gesetzt werden, um Details zu allen Kabelmodems und CPE an einer bestimmten Downstream-Schnittstelle anzuzeigen. Siehe folgendes Beispiel für eine typische Ausgabe, die durch diesen Befehl generiert wird.
CMTS# show interface cable 3/0 modem 0 SID Priv bits Type State IP address method MAC address 1 00 host unknown 192.168.1.77 static 000C.422c.54d0 1 00 modem up 10.1.1.30 dhcp 0001.9659.4447 2 00 host unknown 192.168.1.90 dhcp 00a1.52c9.75ad 2 00 modem up 10.1.1.44 dhcp 0090.9607.3831
Hinweis: Da dieser Befehl ausgeblendet ist, kann er geändert werden und ist nicht in allen Versionen der Cisco IOS® Software verfügbar.
Im obigen Beispiel wird die Methodenspalte des Hosts mit der IP-Adresse 192.168.1.90 als dhcp aufgeführt. Das bedeutet, dass das CMTS von diesem Host erfahren hat, indem es die DHCP-Transaktionen zwischen dem Host und dem DHCP-Server des Dienstanbieters überwacht hat.
Der Host mit der IP-Adresse 192.168.1.77 wird mit der Methode static aufgelistet. Das bedeutet, dass das CMTS von diesem Host nicht zuerst über eine DHCP-Transaktion zwischen diesem Gerät und einem DHCP-Server erfahren hat. Stattdessen sah das CMTS zunächst andere Arten von IP-Datenverkehr von diesem Host. Bei diesem Datenverkehr kann es sich um das Surfen im Internet, E-Mails oder Ping-Pakete handeln.
Obwohl es den Anschein hat, dass 192.168.1.77 mit einer statischen IP-Adresse konfiguriert wurde, kann es sein, dass dieser Host tatsächlich eine DHCP-Lease erworben hat, das CMTS jedoch möglicherweise seit dem Ereignis neu gestartet wurde und sich daher nicht an die Transaktion erinnert.
Die CPE-Datenbank wird normalerweise mit den CMTS-Reinigungsinformationen gefüllt, die aus den DHCP-Transaktionen zwischen CPE-Geräten und dem DHCP-Server des Service Providers stammen. Darüber hinaus kann das CMTS anderen IP-Datenverkehr von CPE-Geräten abhören, um zu bestimmen, welche CPE-IP- und MAC-Adressen zu welchen Kabelmodems gehören.
Der Befehl "Cable Source-Verify"
Cisco hat den Kabelschnittstellenbefehl "cable source-verify" [DHCP] implementiert. Dieser Befehl veranlasst das CMTS, die CPE-Datenbank zu verwenden, um die Gültigkeit der IP-Pakete zu überprüfen, die das CMTS an seinen Kabelschnittstellen empfängt, und ermöglicht es dem CMTS, intelligente Entscheidungen darüber zu treffen, ob diese weitergeleitet werden sollen oder nicht.
Das nachfolgende Flussdiagramm zeigt die zusätzliche Verarbeitung, die ein IP-Paket, das über eine Kabelschnittstelle empfangen wurde, durchlaufen muss, bevor es über das CMTS weitergeleitet werden kann.
Flussdiagramm 1
Das Flussdiagramm beginnt mit dem Empfang eines Pakets durch einen Upstream-Port am CMTS und endet damit, dass das Paket entweder zur weiteren Verarbeitung weitergeleitet werden darf oder im verworfenen Paket enthalten ist.
Beispiel 1 - Szenario mit doppelten IP-Adressen
Das erste Denial-of-Service-Szenario, mit dem wir uns befassen, betrifft doppelte IP-Adressen. Angenommen, Kunde A ist mit seinem Service Provider verbunden und hat eine gültige DHCP-Lease für seinen PC erhalten. Die IP-Adresse, die Kunde A erhalten hat, wird als X bezeichnet.
Irgendwann, nachdem A sein DHCP-Lease erworben hat, beschließt Kunde B, seinen PC mit einer statischen IP-Adresse zu konfigurieren, die zufällig mit der IP-Adresse übereinstimmt, die derzeit von den Geräten von Kunde A verwendet wird. Die CPE-Datenbankinformationen in Bezug auf die IP-Adresse X würden sich ändern, je nachdem, welches CPE-Gerät zuletzt eine ARP-Anforderung für X gesendet hat.
In einem ungeschützten DOCSIS-Netzwerk könnte Kunde B den Next-Hop-Router (in den meisten Fällen das CMTS) davon überzeugen, dass er zur Verwendung der IP-Adresse X berechtigt ist, indem er einfach eine ARP-Anfrage im Namen von X an den CMTS- oder Next-Hop-Router sendet. Dadurch wird verhindert, dass Datenverkehr vom Service Provider an Kunde A weitergeleitet wird.
Wenn die Überprüfung der Kabelquelle aktiviert ist, kann der CMTS erkennen, dass IP- und ARP-Pakete für die IP-Adresse X vom falschen Kabelmodem stammen. Diese Pakete werden daher verworfen (siehe Flussdiagramm 2). Dies schließt alle IP-Pakete mit der Quelladresse X und ARP-Anforderungen für X ein. Die CMTS-Protokolle zeigen eine Nachricht gemäß folgenden Kriterien an:
%UBR7200-3-BADIPSOURCE: Schnittstellenkabel3/0, IP-Paket von ungültiger Quelle. IP=192.168.1.10, MAC=0001.422c.54d0, Erwartete SID=10, Tatsächliche SID=11
Flussdiagramm 2
Anhand dieser Informationen werden beide Clients identifiziert, und das Kabelmodem mit der verbundenen doppelten IP-Adresse kann deaktiviert werden.
Beispiel 2 - Szenario mit doppelten IP-Adressen - Verwenden einer noch nicht verwendeten IP-Adresse
Ein weiteres Szenario besteht darin, dass ein Benutzer seinem PC statisch eine noch nicht verwendete IP-Adresse zuweist, die in den zulässigen Bereich der CPE-Adressen fällt. Dieses Szenario verursacht keine Unterbrechungen der Services für Personen im Netzwerk. Angenommen, Kunde B hat die Adresse Y für seinen PC zugewiesen.
Das nächste mögliche Problem besteht darin, dass Kunde C seine Workstation mit dem Netzwerk des Dienstanbieters verbindet und eine DHCP-Lease für die IP-Adresse Y erwirbt. Die CPE-Datenbank würde die IP-Adresse Y vorübergehend als Zugehörigkeit zu dem Kabelmodem von Kunde C markieren. Es kann jedoch sein, dass nicht lange vor Kunde B der nicht legitime Benutzer die entsprechende Sequenz von ARP-Datenverkehr sendet, um den Next-Hop davon zu überzeugen, dass er der legitime Eigentümer der IP-Adresse Y war, was zu einer Unterbrechung des Dienstes von Kunde C führt.
Das zweite Problem kann ebenfalls durch Aktivieren von Cable Source-Verify gelöst werden. Wenn die Überprüfung der Kabelquelle aktiviert ist, kann ein CPE-Datenbankeintrag, der durch Bereinigung von Details aus einer DHCP-Transaktion generiert wurde, nicht durch andere Arten von IP-Datenverkehr ersetzt werden. Nur eine andere DHCP-Transaktion für diese IP-Adresse oder der ARP-Eintrag im CMTS-Timeout für diese IP-Adresse kann den Eintrag ersetzen. Dadurch wird sichergestellt, dass sich der Kunde, wenn ein Endbenutzer erfolgreich eine DHCP-Lease für eine bestimmte IP-Adresse erwirbt, keine Sorgen darüber machen muss, dass das CMTS verwirrt wird und glaubt, dass seine IP-Adresse einem anderen Benutzer gehört.
Das erste Problem, Benutzer daran zu hindern, noch nicht verwendete IP-Adressen zu verwenden, kann mit cable source-verify dhcp gelöst werden. Durch Hinzufügen des dhcp-Parameters am Ende dieses Befehls kann der CMTS die Gültigkeit jeder neuen Quell-IP-Adresse überprüfen, von der er hört, indem er eine spezielle Art von DHCP-Meldung namens LEASEQUERY an den DHCP-Server sendet. Siehe Flussdiagramm 3.
Flussdiagramm 3
Für eine bestimmte CPE-IP-Adresse werden in der LEASEQUERY-Nachricht die entsprechenden MAC-Adressen und Kabelmodems abgefragt.
Wenn in diesem Fall Kunde B seine Workstation mit der statischen Adresse Y an das Kabelnetzwerk anschließt, sendet das CMTS eine LEASEQUERY-Nachricht an den DHCP-Server, um zu überprüfen, ob Adresse Y an den PC von Kunde B geleast wurde. Der DHCP-Server kann dem CMTS mitteilen, dass keine Lease für die IP-Adresse Y gewährt wurde und somit Kunde B der Zugriff verweigert wird.
Beispiel 3 - Verwendung einer vom Service Provider nicht bereitgestellten Netzwerknummer
Hinter Kabelmodems können Benutzer Workstations mit statischen IP-Adressen konfigurieren, die nicht mit den aktuellen Netzwerknummern des Service Providers kollidieren dürfen, aber in der Zukunft Probleme verursachen können. Aus diesem Grund kann ein CMTS mithilfe der Überprüfung der Kabelquelle Pakete herausfiltern, die von IP-Quelladressen stammen, die nicht aus dem Bereich stammen, der auf der CMTS-Kabelschnittstelle konfiguriert wurde.
Hinweis: Damit dies ordnungsgemäß funktioniert, müssen Sie auch den Befehl ip verify unicast reverse path konfigurieren, um gefälschte IP-Quelladressen zu verhindern. Siehe Kabelbefehle: Kabel für weitere Informationen.
Manche Kunden verwenden einen Router als CPE-Gerät und arrangieren, dass der Service Provider den Datenverkehr zu diesem Router routet. Wenn das CMTS IP-Datenverkehr vom CPE-Router mit der Quell-IP-Adresse Z empfängt, lässt die Kabelquellenverifizierung dieses Paket durch, wenn das CMTS über dieses CPE-Gerät eine Route zum Netzwerk Z hat, zu dem es gehört. Siehe Flussdiagramm 3.
Betrachten wir nun das folgende Beispiel:
Auf dem CMTS ist die folgende Konfiguration vorhanden:
interface cable 3/0 ip verify unicast reverse-path ip address 10.1.1.1 255.255.255.0 ip address 24.1.1.1 255.255.255.0 secondary cable source-verify ! ip route 24.2.2.0 255.255.255.0 24.1.1.2 Note: This configuration shows only what is relevant for this example
Unter der Annahme, dass ein Paket mit der Quell-IP-Adresse 172.16.1.10 vom Kabelmodem 24.2.2.10 am CMTS angekommen ist, würde das CMTS erkennen, dass 24.2.2.10 nicht in der CPE-Datenbank enthalten ist. int Kabelmodem x/y 0 anzeigen, jedoch ip unicast reverse path überprüfen. Aktiviert Unicast Reverse Path Forwarding (Unicast RPF), das jedes auf einer Schnittstelle empfangene Paket überprüft, um sicherzustellen, dass die Quell-IP-Adresse des Pakets in den Routing-Tabellen der Schnittstelle angezeigt wird. Die Kabelquelle überprüft, um den nächsten Hop für 24.2.2.10 zu ermitteln. In der obigen Konfiguration ist die IP-Route 24.2.2.0 255.255.255.0 24.1.1.2 angegeben, was bedeutet, dass der nächste Hop 24.1.1.2 ist. Wenn nun angenommen wird, dass 24.1.1.2 ein gültiger Eintrag in der CPE-Datenbank ist, stellt das CMTS fest, dass das Paket in Ordnung ist. und verarbeitet das Paket entsprechend Flussdiagramm 4.
Flussdiagramm 4
So konfigurieren Sie die Kabelquelle - Überprüfen
Die Konfiguration der Kabelquellenüberprüfung erfolgt durch Hinzufügen des Befehls cable source-verify zur Kabelschnittstelle, an der die Funktion aktiviert werden soll. Wenn Sie die Bündelung von Kabelschnittstellen verwenden, müssen Sie der Konfiguration der primären Schnittstelle eine Kabelquellenverifizierung hinzufügen.
So konfigurieren Sie die Kabelquelle - überprüfen Sie DHCP
Anmerkung: cable source-verify wurde erstmals in Version 12.0(7)T der Cisco IOS-Software eingeführt und wird von den Cisco IOS-Softwareversionen 12.0SC, 12.1EC und 12.1T unterstützt.
Das Konfigurieren des DHCP-Quellcodes für Kabel erfordert einige Schritte.
Stellen Sie sicher, dass Ihr DHCP-Server die spezielle DHCP LEASEQUERY-Nachricht unterstützt.
Um die DHCP-Funktion zur Überprüfung der Kabelquelle nutzen zu können, muss der DHCP-Server die Nachrichten wie in draft-ietf-dhcp-leasequery-XX.txt angegeben beantworten. Cisco Network Registrar, Version 3.5 und höher, kann diese Nachricht beantworten.
Stellen Sie sicher, dass Ihr DHCP-Server die Verarbeitung von Relay Agent Information Option unterstützt. Weitere Informationen finden Sie im Abschnitt Relay Agent.
Eine weitere Funktion, die von Ihrem DHCP-Server unterstützt werden muss, ist die Verarbeitung der DHCP-Relay-Informationsoptionen. Dies wird auch als Option 82-Verarbeitung bezeichnet. Diese Option wird unter DHCP Relay Information Option (RFC 3046) beschrieben. Die Verarbeitung der Relay Agent Information Option wird von Cisco Network Registrar, Version 3.5 und höher unterstützt. Sie muss jedoch mit der folgenden Befehlsfolge über das Befehlszeilendienstprogramm nrcmd von Cisco Network Registrar aktiviert werden:
nrcmd -U admin -P changeme -C 127.0.0.1 dhcp enable save-relay-agent-data
nrcmd -U admin -P changeme -C 127.0.0.1 save
nrcmd -U admin -P changeme -C 127.0.0.1 dhcp reload
Möglicherweise müssen Sie den entsprechenden Benutzernamen, das Kennwort und die IP-Adresse des Servers ersetzen. Oben werden die Standardwerte angezeigt. Alternativ, wenn Sie an der Eingabeaufforderung nrcmd sind, >nrcmd geben Sie einfach Folgendes ein:
dhcp enable save-relay-agent-data
sparen
DHCP-Neuladen
Aktivieren Sie die Verarbeitung der DHCP-Relay-Informationsoption auf dem CMTS.
Relay-Agent
Das CMTS muss DHCP-Anfragen von Kabelmodems und CPE mit der Option "Relay Agent Information Option" kennzeichnen, damit die DHCP-Überprüfung der Kabelquelle wirksam wird. Die folgenden Befehle müssen auf einem CMTS mit Cisco IOS Software Release 12.1EC, 12.1T oder höheren Versionen von Cisco IOS im globalen Konfigurationsmodus eingegeben werden.
ip dhcp relay information option
Wenn auf Ihrem CMTS Cisco IOS Software Releases 12.0SC Train Cisco IOS ausgeführt wird, verwenden Sie stattdessen den Befehl cable relay-agent-option cable interface.
Achten Sie darauf, die entsprechenden Befehle zu verwenden, je nach der Version von Cisco IOS, die Sie ausführen. Aktualisieren Sie Ihre Konfiguration, wenn Sie Züge von Cisco IOS wechseln.
Die Befehle der Relay-Informationsoption fügen dem weitergeleiteten DHCP-Paket eine spezielle Option mit der Bezeichnung Option 82 oder die Relay-Informationsoption hinzu, wenn das CMTS DHCP-Pakete weiterleitet.
Option 82 enthält eine Unteroption, die Agent Circuit-ID, die auf die physische Schnittstelle auf dem CMTS verweist, auf der die DHCP-Anfrage empfangen wurde. Darüber hinaus wird in einer weiteren Unteroption, der Agent Remote ID, die 6 Byte MAC-Adresse des Kabelmodems eingetragen, von dem die DHCP-Anfrage empfangen oder weitergeleitet wurde.
Wenn z. B. ein PC mit der MAC-Adresse 99:88:77:66:55:44 hinter dem Kabelmodem aa:bb:cc:dd:ee:ff eine DHCP-Anfrage sendet, leitet das CMTS die DHCP-Anfrage zur Einstellung der Suboption "Agent Remote ID" von Option 82 an die MAC-Adresse des Kabelmodems aa:bb:cc weiter.:dd:ee:ff
Wenn die Option Relay Information (Relayinformation) in die DHCP-Anfrage eines CPE-Geräts eingebunden ist, kann der DHCP-Server Informationen darüber speichern, welches CPE zu welchem Kabelmodem gehört. Dies ist besonders dann nützlich, wenn auf dem CMTS die Überprüfung der Kabelquelle DHCP konfiguriert ist, da der DHCP-Server das CMTS zuverlässig darüber informieren kann, nicht nur über welche MAC-Adresse ein bestimmter Client verfügen sollte, sondern auch mit welchem Kabelmodem ein bestimmter Client verbunden werden soll.
Aktivieren Sie den Befehl cable source-verify dhcp unter der entsprechenden Kabelschnittstelle.
Der letzte Schritt besteht darin, den Befehl cable source-verify dhcp unter der Kabelschnittstelle einzugeben, auf der die Funktion aktiviert werden soll. Wenn der CMTS die Bündelung von Kabelschnittstellen verwendet, müssen Sie den Befehl unter der primären Schnittstelle des Bündels eingeben.
Schlussfolgerung
Die Befehlssätze zur Überprüfung der Kabelquelle ermöglichen es einem Service Provider, das Kabelnetzwerk vor Benutzern mit nicht autorisierten IP-Adressen zur Nutzung des Netzwerks zu schützen.
Der Befehl cable source-verify allein stellt eine effektive und einfache Möglichkeit dar, IP-Adresssicherheit zu implementieren. Es deckt zwar nicht alle Szenarien ab, stellt jedoch sicher, dass Kunden mit dem Recht, zugewiesene IP-Adressen zu verwenden, nicht durch die Verwendung ihrer IP-Adresse durch eine andere Person beeinträchtigt werden.
In der einfachsten, in diesem Dokument beschriebenen Form kann ein CPE-Gerät, das nicht über DHCP konfiguriert ist, keinen Netzwerkzugriff erhalten. Dies ist die beste Möglichkeit, IP-Adressraum zu sichern und die Stabilität und Zuverlässigkeit eines Daten-über-Kabel-Services zu erhöhen. Jedoch wollten mehrere Service-Betreiber (MSOs), die kommerzielle Dienste haben, die von ihnen verlangen, statische Adressen zu verwenden, eine strenge Sicherheit des Befehlskabels implementieren: source-verify dhcp.
Cisco Network Registrar, Version 5.5, bietet eine neue Funktion zum Beantworten der Lease-Abfrage nach "reservierten" Adressen, obwohl die IP-Adresse nicht über DHCP abgerufen wurde. Der DHCP-Server enthält Lease-Reservierungsdaten in den DHCPLEASEQUERY-Antworten. In den früheren Versionen von Network Registrar waren die DHCPLEASEQUERY-Antworten nur für geleaste oder zuvor geleaste Clients möglich, für die die MAC-Adresse gespeichert war. Cisco uBR-Relay-Agenten verwerfen beispielsweise DHCPLEASEQUERY-Datagramme ohne MAC-Adresse und Leasedauer (DHCP-Lease-Time-Option).
Network Registrar gibt bei einer DHCPLEASEQUERY-Antwort eine standardmäßige Leasingzeit von einem Jahr (31536000 Sekunden) für reservierte Leasingverträge zurück. Wenn die Adresse tatsächlich geleast wird, gibt Network Registrar die verbleibende Leasedauer zurück.
Feedback