23. Sicherheitsaspekte (Security Considerations)
- Sicherheitsaspekte
Die Bedrohung für DHCP ist von Natur aus eine Insider-Bedrohung (vorausgesetzt ein ordnungsgemäß konfiguriertes Netzwerk, in dem die DHCPv6-Ports an den Perimetergateways des Unternehmens blockiert sind). Unabhängig von der Gateway-Konfiguration sind die möglichen Angriffe durch Insider und Außenstehende jedoch dieselben.
Die Verwendung manuell konfigurierter vorab geteilter Schlüssel für IPsec zwischen Relay-Agenten und Servern schützt nicht gegen erneut abgespielte DHCP-Nachrichten. Erneut abgespielte Nachrichten können einen DoS-Angriff durch Erschöpfung von Verarbeitungsressourcen darstellen, aber nicht durch Fehlkonfiguration oder Erschöpfung anderer Ressourcen wie etwa zuweisbarer Adressen.
Ein Angriff, der spezifisch gegen einen DHCP-Client gerichtet ist, ist das Aufsetzen eines bösartigen Servers in der Absicht, dem Client falsche Konfigurationsinformationen zu liefern. Der Beweggrund hierfür kann sein, einen "Man-in-the-Middle"-Angriff durchzuführen, der den Client dazu veranlasst, mit einem bösartigen Server anstelle eines gültigen Servers für einen Dienst wie DNS oder NTP zu kommunizieren. Der bösartige Server kann zudem einen Denial-of-Service-Angriff durch Fehlkonfiguration des Clients ausführen, die bewirkt, dass jede Netzwerkkommunikation vom Client fehlschlägt.
Eine weitere Bedrohung für DHCP-Clients geht von irrtümlich oder versehentlich konfigurierten DHCP-Servern aus, die auf DHCP-Client-Anfragen mit unbeabsichtigt falschen Konfigurationsparametern antworten.
Ein DHCP-Client kann zudem einem Angriff durch den Empfang einer Reconfigure-Nachricht von einem bösartigen Server ausgesetzt sein, die den Client veranlasst, falsche Konfigurationsinformationen von jenem Server zu beziehen. Beachten Sie, dass, obwohl ein Client seine Antwort (Renew- oder Information-request-Nachricht) über einen Relay-Agenten sendet und daher jene Antwort nur von Servern empfangen wird, an die DHCP-Nachrichten weitergeleitet werden, ein bösartiger Server eine Reconfigure-Nachricht an einen Client senden könnte, gefolgt (nach angemessener Verzögerung) von einer Reply-Nachricht, die vom Client akzeptiert würde. So könnte ein bösartiger Server, der sich nicht auf dem Netzwerkpfad zwischen Client und Server befindet, dennoch einen Reconfigure-Angriff auf einen Client ausführen. Die Verwendung kryptografisch solider und nicht leicht vorhersehbarer Transaktions-IDs wird zudem die Wahrscheinlichkeit verringern, dass ein solcher Angriff erfolgreich ist.
Die spezifisch gegen einen DHCP-Server gerichtete Bedrohung ist ein ungültiger Client, der sich als gültiger Client ausgibt. Der Beweggrund hierfür kann Diebstahl von Diensten sein oder die Umgehung der Nachverfolgbarkeit für eine beliebige Anzahl übler Absichten.
Die beiden, sowohl für den Client als auch den Server gemeinsame Bedrohung ist der Ressourcen-"Denial of Service"-Angriff (DoS). Diese Angriffe beinhalten typischerweise die Erschöpfung verfügbarer Adressen oder die Erschöpfung von CPU- oder Netzwerkbandbreite und sind überall dort vorhanden, wo eine gemeinsam genutzte Ressource existiert.
Im Fall, dass Relay-Agenten Relay-Forward-Nachrichten zusätzliche Optionen hinzufügen, können die zwischen Relay-Agenten und Servern ausgetauschten Nachrichten für einen "Man-in-the-Middle"- oder Denial-of-Service-Angriff verwendet werden.
Dieses Bedrohungsmodell betrachtet die Vertraulichkeit der Inhalte von DHCP-Nachrichten als nicht wichtig. DHCP wird nicht verwendet, um Authentifizierungs- oder Konfigurationsinformationen auszutauschen, die vor anderen Netzwerkknoten geheim gehalten werden müssen.
Die DHCP-Authentifizierung bietet die Authentifizierung der Identität von DHCP-Clients und -Servern sowie die Integrität der zwischen DHCP-Clients und -Servern zugestellten Nachrichten. Die DHCP-Authentifizierung bietet keinerlei Vertraulichkeit für die Inhalte von DHCP-Nachrichten.
Das in Abschnitt 21.4 beschriebene Delayed Authentication-Protokoll verwendet einen zwischen Client und Server geteilten geheimen Schlüssel. Die Verwendung eines "DHCP-Bereichs" (DHCP realm) im geteilten Schlüssel erlaubt die Identifizierung administrativer Domänen, sodass ein Client den geeigneten Schlüssel oder die geeigneten Schlüssel auswählen kann, wenn er zwischen administrativen Domänen roamingt. Das Delayed Authentication- Protokoll definiert jedoch keinen Mechanismus für den Schlüsselaustausch, sodass ein Client für jede administrative Domäne, der er begegnet, getrennte Schlüssel benötigen kann. Die Verwendung geteilter Schlüssel skaliert möglicherweise nicht gut und bietet keine Abstreitbarkeit kompromittierter Schlüssel. Dieses Protokoll konzentriert sich auf die Lösung des Intradomänenproblems, bei dem der Out-of-band-Austausch eines geteilten Schlüssels machbar ist.
Wegen der Möglichkeit eines Angriffs über die Reconfigure-Nachricht MUSS ein DHCP-Client jede Reconfigure-Nachricht verwerfen, die keine Authentifizierung enthält oder die den Validierungsprozess für das Authentifizierungsprotokoll nicht besteht.
Das in Abschnitt 21.5 beschriebene Reconfigure Key-Protokoll bietet Schutz gegen die Verwendung einer Reconfigure-Nachricht durch einen bösartigen DHCP-Server, um einen Denial-of-Service- oder Man-in-the-Middle- Angriff auf einen Client auszuführen. Dieses Protokoll kann durch einen Angreifer kompromittiert werden, der die anfängliche Nachricht abfangen kann, in der der DHCP-Server den Schlüssel an den Client sendet.
Die Kommunikation zwischen einem Server und einem Relay-Agenten sowie die Kommunikation zwischen Relay-Agenten kann durch die Verwendung von IPsec abgesichert werden, wie in Abschnitt 21.1 beschrieben. Die Verwendung manueller Konfiguration und Installation statischer Schlüssel ist in diesem Fall akzeptabel, da die Relay-Agenten und der Server derselben administrativen Domäne angehören und die Relay-Agenten andere spezifische Konfiguration (beispielsweise Konfiguration der DHCP-Server-Adresse) sowie die IPsec-Konfiguration benötigen.