23. Sicherheitsüberlegungen
Die Bedrohung für DHCP ist grundsätzlich eine Insider-Bedrohung (unter der Annahme eines ordnungsgemäß konfigurierten Netzwerks, bei dem DHCPv6-Ports an den Perimeter-Gateways des Unternehmens blockiert sind). Unabhängig von der Gateway-Konfiguration sind jedoch die potenziellen Angriffe durch Insider und Außenstehende dieselben.
Die Verwendung manuell konfigurierter vorab geteilter Schlüssel für IPsec zwischen Relay-Agents und Servern schützt nicht vor wiederholten DHCP-Nachrichten. Wiederholte Nachrichten können einen DOS-Angriff durch Erschöpfung von Verarbeitungsressourcen darstellen, aber nicht durch Fehlkonfiguration oder Erschöpfung anderer Ressourcen wie zuweisbarer Adressen.
Ein spezifischer Angriff auf einen DHCP-Client ist die Einrichtung eines bösartigen Servers mit der Absicht, dem Client falsche Konfigurationsinformationen bereitzustellen. Die Motivation dafür kann darin bestehen, einen "Man-in-the-Middle"-Angriff durchzuführen, der dazu führt, dass der Client mit einem bösartigen Server anstatt mit einem gültigen Server für einen Dienst wie DNS oder NTP kommuniziert. Der bösartige Server kann auch einen Denial-of-Service-Angriff durch Fehlkonfiguration des Clients durchführen, der dazu führt, dass die gesamte Netzwerkkommunikation vom Client fehlschlägt.
Es gibt eine weitere Bedrohung für DHCP-Clients durch fälschlicherweise oder versehentlich konfigurierte DHCP-Server, die auf DHCP-Client-Anfragen mit unbeabsichtigt falschen Konfigurationsparametern antworten.
Ein DHCP-Client kann auch durch den Empfang einer Reconfigure-Nachricht von einem bösartigen Server angegriffen werden, die dazu führt, dass der Client falsche Konfigurationsinformationen von diesem Server erhält. Beachten Sie, dass, obwohl ein Client seine Antwort (Renew- oder Information-request-Nachricht) über einen Relay-Agent sendet und diese Antwort daher 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 einer angemessenen Verzögerung) von einer Reply-Nachricht, die vom Client akzeptiert würde. Daher kann ein bösartiger Server, der sich nicht auf dem Netzwerkpfad zwischen dem Client und dem Server befindet, möglicherweise dennoch einen Reconfigure-Angriff auf einen Client durchführen. Die Verwendung von Transaktions-IDs, die kryptographisch sicher sind und nicht leicht vorhergesagt werden können, verringert auch die Wahrscheinlichkeit, dass ein solcher Angriff erfolgreich ist.
Die spezifische Bedrohung für einen DHCP-Server ist ein ungültiger Client, der sich als gültiger Client ausgibt. Die Motivation dafür kann Dienstdiebstahl sein oder die Umgehung der Überwachung für eine Reihe von bösartigen Zwecken.
Die gemeinsame Bedrohung für Client und Server ist der Ressourcen-"Denial-of-Service" (DoS)-Angriff. Diese Angriffe beinhalten typischerweise die Erschöpfung verfügbarer Adressen oder die Erschöpfung von CPU oder Netzwerkbandbreite und sind immer dann vorhanden, wenn es eine gemeinsam genutzte Ressource gibt.
In dem Fall, in dem Relay-Agents zusätzliche Optionen zu Relay-Forward-Nachrichten hinzufügen, können die zwischen Relay-Agents und Servern ausgetauschten Nachrichten verwendet werden, um einen "Man-in-the-Middle"- oder Denial-of-Service-Angriff durchzuführen.
Dieses Bedrohungsmodell betrachtet die Vertraulichkeit des Inhalts von DHCP-Nachrichten nicht als wichtig. DHCP wird nicht verwendet, um Authentifizierungs- oder Konfigurationsinformationen auszutauschen, die vor anderen Netzwerkknoten geheim gehalten werden müssen.
Die DHCP-Authentifizierung bietet Authentifizierung der Identität von DHCP-Clients und -Servern sowie der Integrität von Nachrichten, die zwischen DHCP-Clients und -Servern übermittelt werden. Die DHCP-Authentifizierung bietet keine Vertraulichkeit für den Inhalt von DHCP-Nachrichten.
Das in Abschnitt 21.4 beschriebene Delayed Authentication Protocol verwendet einen geheimen Schlüssel, der zwischen einem Client und einem Server geteilt wird. Die Verwendung eines "DHCP-Realm" im gemeinsam genutzten Schlüssel ermöglicht die Identifizierung administrativer Domänen, sodass ein Client den geeigneten Schlüssel oder die geeigneten Schlüssel beim Roaming zwischen administrativen Domänen auswählen kann. Das Delayed Authentication Protocol definiert jedoch keinen Mechanismus für die Freigabe von Schlüsseln, sodass ein Client möglicherweise separate Schlüssel für jede administrative Domäne benötigt, auf die er trifft. Die Verwendung gemeinsam genutzter Schlüssel skaliert möglicherweise nicht gut und bietet keine Widerlegung kompromittierter Schlüssel. Dieses Protokoll konzentriert sich auf die Lösung des Intradomänen-Problems, bei dem der Out-of-Band-Austausch eines gemeinsam genutzten Schlüssels machbar ist.
Aufgrund der Möglichkeit eines Angriffs über die Reconfigure-Nachricht MUSS ein DHCP-Client jede Reconfigure-Nachricht verwerfen, die keine Authentifizierung enthält oder den Validierungsprozess für das Authentifizierungsprotokoll nicht besteht.
Das in Abschnitt 21.5 beschriebene Reconfigure Key Protocol bietet Schutz vor der Verwendung einer Reconfigure-Nachricht durch einen bösartigen DHCP-Server, um einen Denial-of-Service- oder Man-in-the-Middle-Angriff auf einen Client durchzuführen. Dieses Protokoll kann von einem 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-Agent sowie die Kommunikation zwischen Relay-Agents kann durch die Verwendung von IPSec gesichert werden, wie in Abschnitt 21.1 beschrieben. Die Verwendung manueller Konfiguration und Installation statischer Schlüssel ist in diesem Fall akzeptabel, da Relay-Agents und der Server zur selben administrativen Domäne gehören und die Relay-Agents neben der IPSec-Konfiguration auch andere spezifische Konfigurationen (z. B. Konfiguration der DHCP-Serveradresse) benötigen.