22. Sicherheitsueberlegungen
Dieser Abschnitt bewahrt den RFC-Text zu DHCPv6, einschliesslich Nachrichtenaustausch, Relay-Verhalten, DUIDs, IA_NA, IA_TA, IA_PD, DHCP-Optionen, RKAP-Authentifizierung, IANA-Registern, normativen Anforderungen und der Optionsvorkommensmatrizen im Anhang.
Originaler RFC-Text
22. Sicherheitsueberlegungen
Dieser Abschnitt behandelt Sicherheitsueberlegungen, die nicht mit
Datenschutz zusammenhaengen. Siehe Section 23 fuer eine dem
Datenschutz gewidmete Diskussion.
Die Bedrohung fuer DHCP ist ihrem Wesen nach eine Insider-Bedrohung
(unter der Annahme eines ordnungsgemaess konfigurierten Netzes, in dem
DHCP-Ports an den Perimeter-Gateways des Unternehmens blockiert sind).
Unabhaengig von der Gateway-Konfiguration sind die potenziellen Angriffe
durch Insider und Aussenstehende jedoch gleich.
DHCP verfuegt nicht ueber End-to-End-Verschluesselung zwischen Clients
und Servern; daher sind Hijacking-, Manipulations- und
Abhoerangriffe als Folge alle moeglich. Einige Netzumgebungen (unten
diskutiert) koennen durch verschiedene Mittel abgesichert werden, um
diese Angriffe zu minimieren.
Die gemeinsame Bedrohung fuer Client und Server ist der
"resource-exhaustion"-DoS-Angriff. Typischerweise beinhalten diese
Angriffe die Erschoepfung verfuegbarer zugewiesener Adressen oder
delegierbarer Praefixe oder die Erschoepfung von CPU oder
Netzwerkbandbreite, und sie treten immer dann auf, wenn es eine
gemeinsam genutzte Ressource gibt. Einige Formen dieser
Erschoepfungsangriffe koennen durch geeignete Serverrichtlinien
teilweise gemildert werden, z.B. durch Begrenzung der maximalen Anzahl
von Leases, die ein einzelner Client erhalten kann, durch Begrenzung der
Anzahl von Leases, die ein Client ablehnen kann, und durch Begrenzung
der Anzahl von Nachrichten, die ein einzelner Client in einem Zeitraum
senden kann.
22.1. Sicherheitsueberlegungen fuer Clients
Ein Angriff, der spezifisch einen DHCP-Client betrifft, ist die
Einrichtung eines boesartigen Servers mit der Absicht, dem Client
falsche Konfigurationsinformationen bereitzustellen. Die Motivation
dafuer kann sein, einen "man-in-the-middle"-Angriff durchzufuehren, der
den Client dazu veranlasst, fuer einen Dienst (wie DNS oder NTP) mit
einem boesartigen Server statt mit einem gueltigen Server zu
kommunizieren. Der boesartige Server kann auch einen DoS-Angriff durch
Fehlkonfiguration des Clients durchfuehren; dieser Angriff wuerde dazu
fuehren, dass jede Netzkommunikation vom Client fehlschlaegt.
Ein boesartiger DHCP-Server koennte einen Client dazu bringen, seine
Parameter SOL_MAX_RT und INF_MAX_RT mit den Optionen SOL_MAX_RT (siehe
Section 21.24) und INF_MAX_RT (siehe Section 21.25) auf einen
unangemessen hohen Wert zu setzen; dies kann zu einer ungebuehrlichen
Verzoegerung fuehren, bis ein Client seine DHCP-Protokolltransaktion
abschliesst, falls keine andere gueltige Antwort empfangen wird. Unter
der Annahme, dass der Client auch eine Antwort von einem gueltigen
DHCP-Server erhaelt, haben grosse Werte fuer SOL_MAX_RT und INF_MAX_RT
keine Wirkung.
Eine weitere Bedrohung fuer DHCP-Clients stammt von versehentlich oder
irrtuemlich konfigurierten DHCP-Servern, die DHCP-Client-Anfragen mit
unbeabsichtigt falschen Konfigurationsparametern beantworten.
Wenn eine Client-Implementierung den reconfigure-Mechanismus
unterstuetzt, siehe Section 22.3.
22.2. Sicherheitsueberlegungen fuer Server
Die spezifische Bedrohung fuer einen DHCP-Server ist ein ungueltiger
Client, der sich als gueltiger Client ausgibt. Die Motivation dafuer
kann Diebstahl von Diensten oder die Umgehung von Auditierung fuer eine
Vielzahl boesartiger Zwecke sein.
Die zwischen Relay Agents und Servern ausgetauschten Nachrichten koennen
verwendet werden, um einen man-in-the-middle- oder DoS-Angriff
durchzufuehren. Kommunikation zwischen einem Server und einem Relay
Agent sowie Kommunikation zwischen Relay Agents kann durch Verwendung von
IPsec authentifiziert und verschluesselt werden, wie in [RFC8213]
beschrieben.
Die Verwendung manuell konfigurierter Pre-Shared Keys fuer IPsec
zwischen Relay Agents und Servern schuetzt jedoch nicht gegen
wiederholte DHCP-Nachrichten. Wiederholte Nachrichten koennen einen
DoS-Angriff durch Erschoepfung von Verarbeitungsressourcen darstellen,
jedoch nicht durch Fehlkonfiguration oder Erschoepfung anderer
Ressourcen wie zuweisbarer Adressen und delegierbarer Praefixe.
Wenn eine Server-Implementierung den reconfigure-Mechanismus
unterstuetzt, siehe Section 22.3.
22.3. Sicherheitsueberlegungen zu Reconfigure
RKAP, beschrieben in Section 20.4, bietet Schutz gegen die Verwendung
einer Reconfigure-Nachricht durch einen boesartigen DHCP-Server, um
einen DoS- oder man-in-the-middle-Angriff auf einen Client
durchzufuehren. Dieses Protokoll kann durch einen Angreifer
kompromittiert werden, der die initiale Nachricht abfangen kann, in der
der DHCP-Server den Schluessel als Klartext an den Client sendet.
Aufgrund der Angriffsmoeglichkeit ueber die Reconfigure-Nachricht MUST
ein DHCP-Client jede Reconfigure-Nachricht verwerfen, die keine
Authentifizierung enthaelt oder den Validierungsprozess fuer das
Authentifizierungsprotokoll nicht besteht.
Ein DHCP-Client kann auch durch den Empfang einer Reconfigure-Nachricht
von einem boesartigen Server angegriffen werden, die den Client dazu
veranlasst, falsche Konfigurationsinformationen von diesem Server zu
beziehen. Obwohl ein Client seine Antwort (Renew-, Rebind- oder
Information-request-Nachricht) ueber einen Relay Agent sendet und diese
Antwort daher nur von Servern empfangen wird, an die DHCP-Nachrichten
weitergeleitet werden, koennte ein boesartiger Server eine
Reconfigure-Nachricht an einen Client senden, gefolgt (nach einer
geeigneten Verzoegerung) von einer Reply-Nachricht, die vom Client
akzeptiert wuerde. Daher kann ein boesartiger Server, der sich nicht
auf dem Netzpfad zwischen Client und Server befindet, dennoch in der Lage
sein, einen Reconfigure-Angriff auf einen Client durchzufuehren. Die
Verwendung kryptographisch solider und nicht leicht vorhersagbarer
Transaction IDs verringert ebenfalls die Wahrscheinlichkeit, dass ein
solcher Angriff erfolgreich ist.
22.4. Ueberlegungen zur Minderung
Verschiedene Netzumgebungen bieten ebenfalls Sicherheitsniveaus, wenn
sie wie unten beschrieben bereitgestellt werden.
* In Unternehmens- und Fabriknetzen kann die Verwendung von
Authentifizierung gemaess [IEEE8802.1x] verhindern, dass unbekannte
oder nicht vertrauenswuerdige Clients eine Verbindung zum Netz
herstellen. Dies stellt jedoch nicht notwendigerweise sicher, dass
der verbundene Client ein guter DHCP- oder Netzakteur ist.
* Bei drahtgebundenen Netzen, in denen Clients typischerweise mit einem
Switch-Port verbunden sind, wird das Abhoeren von DHCP-Multicast-
(oder Unicast-)Verkehr schwierig, da Switches den an einen Port
gelieferten Verkehr begrenzen. Die DHCP-Nachrichten des Clients
(Multicast an All_DHCP_Relay_Agents_and_Servers) werden nur an den
Switch-Port des DHCP-Servers (oder Relays) weitergeleitet, nicht an
alle Ports. Ebenso werden die Unicast-Antworten des Servers (oder
Relays) nur an den Port des Ziel-Clients geliefert, nicht an alle
Ports.
* In oeffentlichen Netzen (wie einem Wi-Fi-Netz in einem Cafe oder
Flughafen) ist es fuer andere innerhalb der Funkreichweite moeglich,
DHCP und anderen Verkehr abzuhoeren. In diesen Umgebungen laesst sich
jedoch sehr wenig, wenn ueberhaupt etwas, aus dem DHCP-Verkehr selbst
lernen (entweder vom Client zum Server oder vom Server zum Client),
wenn die Datenschutzueberlegungen in Section 23 befolgt werden.
Selbst bei Geraeten, die die Datenschutzueberlegungen nicht befolgen,
gibt es wenig zu lernen, was nicht ohnehin aus nachfolgenden
Kommunikationen verfuegbar waere (wie die Media Access Control
(MAC)-Adresse des Geraets). Da ausserdem alle Clients typischerweise
aehnliche Konfigurationsdetails erhalten, kann ein boesartiger Akteur,
der selbst eine DHCP-Anfrage initiiert, einen grossen Teil dieser
Informationen erfahren. Wie oben erwaehnt, besteht eine Bedrohung
darin, dass der RKAP-Schluessel fuer einen Client gelernt werden kann
(wenn der initiale Solicit/Advertise/Request/Reply-Austausch
ueberwacht wird) und eine vorzeitige Rekonfiguration ausloest; dies
laesst sich jedoch relativ leicht verhindern, indem direkte
Client-to-Client-Kommunikation in diesen Netzen untersagt oder
[RFC7610] und [RFC7513] verwendet werden.
Viele Angriffe durch Rogue-Server koennen durch Nutzung der in [RFC7610]
und [RFC7513] beschriebenen Mechanismen gemindert werden.