DHCPv6-Client-MAC-Adressüberprüfung zur Verhinderung von Session-Hijacking
Ab Junos OS Version 18.2R1 gibt es einen nicht konfigurierbaren Mechanismus für lokale DHCPv6-Server und Relay-Agenten, um Pakete von einem Client mit einer unbekannten MAC-Adresse zu verwerfen, um zu verhindern, dass ein bösartiger Client eine Sitzung übernimmt. Wenn ein lokaler DHCPv6-Server oder -Relay-Agent eine Nachricht erhält, in der er aufgefordert wird, eine Sitzung einzurichten, extrahiert er die Client-MAC-Adresse (Link-Layer-Adresse) aus der Nachricht und fügt sie einer lokalen Tabelle hinzu, die MAC-Adressen Client-IPv6-Adressen oder -Präfixen zuordnet. Der Server oder Relay-Agent verwendet diese Tabelle, um MAC-Adressen zu vergleichen, die in nachfolgenden Nachrichten vom Client empfangen wurden, um zu überprüfen, ob der Client bekannt ist. Ist dies nicht der Fall, wird davon ausgegangen, dass es bösartig ist, und das Kontrollpaket wird verworfen. Da die MAC-Validierung des Pakets fehlgeschlagen ist, wird der Validierungszähler der Client-MAC-Validierung inkrementiert.
Hier wird davon ausgegangen, dass der Client, der die anfängliche Anfragenachricht sendet, gutartig ist. In diesem Fall schützt die Überprüfung der Client-MAC-Adresse vor dem Versuch eines böswilligen Clients, eine Clientsitzung zu kapern, die bereits eingerichtet wurde oder gerade eingerichtet wird. Die Überprüfung der MAC-Adresse des Clients schützt nicht vor einem bösartigen Client, der die anfängliche Anforderungsnachricht sendet.
Wenn kein Relay-Agent vorhanden ist; Der lokale Server teilt sich eine Verbindung oder einen Zugriffsknoten mit dem Client. In diesem Fall extrahiert der lokale Server die Client-MAC-Adresse direkt aus dem Layer-2-Header des DHCPv6-Steuerpakets und validiert die Adresse anhand der Tabelle.
Wenn ein Relay-Agent vorhanden ist, wird die Validierung vom Relay-Agent durchgeführt. RFC 6939, Client Link-Layer Address Option in DHCPv6, ermöglicht es DHCPv6-Relay-Agenten, die mit derselben Verbindung wie ein DHCPv6-Client verbunden sind, die Client-MAC-Adresse aus dem Ethernet-Header (Layer 2) im empfangenen DHCPv6-Steuerpaket zu extrahieren. Das Paket enthält die Link-Layer-Adresse des Clients als MAC-Adresse der Quelle in seinem Ethernet-Header. Der Relay-Agent vergleicht die MAC-Adresse mit dem Wert für diesen Client, der in der lokalen Tabelle gespeichert ist. Wenn die Adresse nicht übereinstimmt, wird das Paket verworfen.
Wenn die Adresse vom Relay-Agent überprüft wird und das Paket nicht verworfen wird, nimmt der Relay-Agent diese MAC-Adresse auch in Option 79 (Client-Link-Layer-Adresse) in den Header der DHCPv6-Relayweiterleitungsnachricht auf, die der Relay-Agent an den lokalen Server sendet. Wenn der lokale DHCPv6-Server eine Relay-Forward-Nachricht von einem Relay-Agent empfängt, untersucht der Server die Nachricht automatisch auf das Vorhandensein von Option 79. Wenn die Option vorhanden ist, extrahiert der lokale Server die MAC-Adresse und vergleicht sie mit dem Wert, der in der Tabelle für diesen Client gespeichert ist. Wenn Option 79 nicht vorhanden ist, kann der lokale Server die Validierung nicht durchführen.
Da der Relay-Agent die Adresse jedoch bereits überprüft hat, sollte der lokale Server keine Adressabweichungen feststellen.
In den folgenden Szenarien werden mögliche Relay-Agent-Konfigurationen und ihre Auswirkungen auf die Servervalidierung beschrieben:
Ein einzelner Lightweight DHCPv6 Relay Agent (LDRA; Schicht 2) ist zwischen dem Client und dem Server verbunden. Falls LDRA die Option 79 nicht zum Header hinzugefügt hat, dann extrahiert der lokale Server die Client-MAC-Adresse direkt aus dem Layer-2-Header des DHCPv6-Steuerpakets und validiert die Adresse anhand der Tabelle.
Ein oder mehrere Layer 3 DHCPv6 Relay Agents sind zwischen dem Client und dem Server verbunden. In diesem Fall prüft der Server auf Option 79 im Header der innersten Relay-Forward-Nachricht, die vom Relay-Agent gesendet wird. Der innerste Header wird angezeigt, da es sich um den Header handelt, der vom ersten Relay-Agent geändert wurde, den der Client erreicht. Andere Header werden von nachfolgenden Relay-Agents im Pfad hinzugefügt. Diese Agents fügen Option 79 nicht hinzu und können die MAC-Adresse nicht aus dem Layer-2-Header des ersten Relay-Agenten extrahieren, da dieser Agent die Adresse in seine eigene Adresse ändert, ebenso wie jeder nachfolgende Relay-Agent.
Zwischen dem Client und dem Server ist eine Kombination aus einem clientseitigen Layer 2 (LDRA) Relay-Agenten, gefolgt von einem oder mehreren Layer 3 DHCPv6 Relay Agenten, verbunden. Der Server prüft, ob Option 79 im innersten Header der vom Relay-Agent gesendeten Relay-Weiterleitungsnachricht vorhanden ist. Falls LDRA die Option 79 nicht zum Header hinzugefügt hat, ist es wahrscheinlich nicht in der Lage, die MAC-Adresse im Header in seine eigene zu ändern. Folglich prüft der Server als nächstes den zweitinnersten Header für die Option, da der erste Layer-3-Relay-Agent die MAC-Adresse extrahiert und die Option 79 hinzugefügt haben kann, um die Adresse zu übermitteln.
Es ist keine Konfiguration erforderlich, um die Validierung von Client-MAC-Adressen zu aktivieren. Sie können anzeigen, wie viele Steuerpakete aufgrund eines Validierungsfehlers verworfen wurden, indem Sie den show dhcpv6 server statistics Befehl ausgeben.
Vorteile der Client-MAC-Adressenvalidierung
Mit der Überprüfung der Client-MAC-Adresse können Sie verhindern, dass ein DHCPv6-Client mit einer unbekannten MAC-Adresse eine von einem bekannten Client eingerichtete Sitzung übernimmt. Die Verwendung von DHCPv6-Client-MAC-Adressen wird wahrscheinlich zunehmen, da sie für die Korrelation von DHCPv4- und DHCPv6-Clients in einer Dual-Stack-Umgebung praktisch sind.
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Funktionen entdecken , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.