DHCPv6-Client-MAC-Adressvalidierung zur Verhinderung von Sitzungs-Hijacking
Ab Junos OS Version 18.2R1 gibt es einen nicht konfigurierbaren Mechanismus für lokale DHCPv6-Server und -Relay-Agents, um Pakete von einem Client mit einer unbekannten MAC-Adresse zu verwerfen, um zu verhindern, dass ein böswilliger Client eine Sitzung entführt. Wenn ein lokaler DHCPv6-Server oder Relay-Agent eine Solicit-Nachricht von einem Client empfängt, um 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 oder -Präfixe des Clients zuordnet. Der Server oder Relayagent 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. Wenn nicht, wird davon ausgegangen, dass es bösartig ist, und das Kontrollpaket wird verworfen. Da das Paket die MAC-Validierung nicht bestanden hat, wird der Client-MAC-Validierungsindikator erhöht.
Hier wird davon ausgegangen, dass der Client, der die erste Anfragenachricht sendet, gutartig ist. In diesem Fall schützt die Client-MAC-Adresse vor dem Versuch eines böswilligen Clients, eine Client-Sitzung zu kapern, die bereits eingerichtet wurde oder gerade eingerichtet wird. Die Überprüfung der Client-MAC-Adresse schützt nicht vor einem böswilligen Client, der die erste Request-Nachricht sendet.
Wenn kein Relaisagent vorhanden ist; Der lokale Server teilt 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 Relaisagent vorhanden ist, wird die Validierung vom Relaisagenten durchgeführt. RFC 6939, Client Link-Layer Address Option in DHCPv6, ermöglicht es DHCPv6-Relay-Agents, 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 Quell-MAC-Adresse in seinem Ethernet-Header. Der Relay-Agent validiert die MAC-Adresse anhand des Werts für diesen Client, der in seiner lokalen Tabelle gespeichert ist. Wenn die Adresse nicht übereinstimmt, wird das Paket verworfen.
Wenn die Adresse vom Relay-Agent validiert wird und das Paket nicht verworfen wird, fügt der Relay-Agent diese MAC-Adresse auch in Option 79 (Client-Link-Layer-Adresse) in den Header der DHCPv6-Relay-Forward-Nachricht ein, die der Relay-Agent an den lokalen Server sendet. Wenn der lokale DHCPv6-Server eine Relayweiterleitungsnachricht von einem Relay-Agent empfängt, prüft der Server die Nachricht automatisch auf das Vorhandensein von Option 79. Wenn die Option vorhanden ist, extrahiert der lokale Server die MAC-Adresse und validiert sie mit dem in der Tabelle für diesen Client gespeicherten Wert. 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 Adresskonflikte erkennen.
In den folgenden Szenarien werden mögliche Relay Agent-Konfigurationen und ihre Auswirkungen auf die Servervalidierung beschrieben:
Ein einzelner Lightweight DHCPv6 Relay Agent (LDRA; Layer 2) ist zwischen dem Client und dem Server verbunden. Wenn der LDRA dem Header keine Option 79 hinzugefügt hat, 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 vom Client erreichten Relayagenten geändert wurde. Andere Header werden von nachfolgenden Relayagenten 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.
Eine Kombination aus einem clientseitigen Layer 2 (LDRA)-Relay-Agenten, gefolgt von einem oder mehreren Layer 3 DHCPv6-Relay-Agenten, ist zwischen dem Client und dem Server verbunden. Der Server prüft auf Option 79 im innersten Header der vom Relay-Agent gesendeten Relay-Forward-Nachricht. Wenn der LDRA dem Header nicht Option 79 hinzugefügt hat, ist er 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 auf die Option, da der erste Layer-3-Relay-Agent möglicherweise die MAC-Adresse extrahiert und Option 79 hinzugefügt hat, 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-Adressen-Validierung
Mit der Client-MAC-Adressen-Validierung können Sie verhindern, dass ein DHCPv6-Client mit einer unbekannten MAC-Adresse eine Sitzung entführt, die von einem bekannten Client eingerichtet wurde. Die Verwendung von DHCPv6-Client-MAC-Adressen wird wahrscheinlich zunehmen, da dies für die Korrelation von DHCPv4- und DHCPv6-Clients in einer Dual-Stack-Umgebung praktisch ist.
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie den Feature-Explorer , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.