Dieser Beitrag stammt von http://www.linux-magazin.de


Erschienen im Linux

Erschienen im Linux-Magazin 02/2002

Grundlagen: Dynamic Host Configuration Protocol

Zahlen Meister!

Konstantin Agouros


Der Beitrag vermittelt die Grundlagen und das praktisches Know-how, um Linux als DHCP-Client und -Server einzurichten. Außerdem wird gezeigt, wie ein Nameserver zu DHCP-Updates kommt.


Dynamische Adressvergabe ist in größeren Netzen ein praktisches Verfahren, um die Verwaltung von IP-Adressen zu vereinfachen. Clientsysteme sollten zwar im gleichen Netz liegen, aber sie benötigen keine feste IP-Adresse. Zur Vergabe von IP-Adressen wurde früher das BOOTP-Protokoll verwendet, heute in der Regel das bessere DHCP (Dynamic Host Configuration Protocol).

Ein oder mehrere DCHP-Server versorgen die Geräte (DCHP-Clients) eines TCP/IP-basierten Netzwerks mit IP-Adressen und weiteren Informationen wie Default-Route, Netmask, DNS-Server und so weiter. Das DHCP ist in den RFCs 2131[1] und 2132[2] beschrieben. Ergänzend gibt es noch die RFCs 2485[3] und 2489[4], die Erweiterungen des Protokolls beschreiben.

Beim BOOTP (beschrieben in RFC 951[5]) sind Art und Menge der Informationen, die für den Client erhältlich sind, geringer. So kann keine zeitliche Obergrenze für die Gültigkeit einer Adresse mitgegeben werden, ein bootender Rechner ist nicht aufgrund seines Hostnamens, sondern nur anhand der MAC-Adresse identifizierbar. DHCP definiert sich als Erweiterung von BOOTP - technisch sind einige der DHCP-Vorgänge BOOTP zuzuordnen.

Wie funktioniert DHCP?

Beim Start fragt der Client über einen Broadcast im ganzen Netz - gegebenenfalls über Router-Grenzen hinweg - nach (s)einer IP-Adresse. Als Antwort bekommt er die Adresse und

  • Default-Route,
  • DNS-Server-Adresse(n),
  • WINS-Server,
  • Netzmaske,
  • Broadcast-Adresse,
  • Vendor-Optionen.

Vendor-Optionen sind Einträge, die Geräten (etwa Druckern) im Netzwerk spezifische Werte mitgeben. Zusätzlich kann jedem Client eine Ablaufzeit für die vergebene IP-Adresse mitgeteilt werden. Das ist sinnvoll, wenn es mehr Geräte als vergebbare IP-Adressen gibt, etwa bei einem Büro, in dem viele Laptops nur sporadisch am Netz sind.

Abbildung 1 zeigt den Ablauf von der ersten Anfrage bis zum Erhalt der IP-Adresse. Die Kommunikation zwischen Client und Server läuft per UDP auf Port 67 (Server) und Port 68 (Client). Wenn der Client bootet, fragt er mit einem DHCPDISCOVER per Broadcast nach seiner Client-Konfiguration. Der Client hat zu diesem Zeitpunkt noch keine (nutzbringende externe) IP, sondern nur seine MAC-Adresse (weltweit eindeutige, auf der Netzwerkkarte kodierte Ethernet-Adresse). Darum bekommt das Broadcast-Paket die Quelladresse 0.0.0.0 und die Zieladresse 255.255.255.255. Das Ganze funktioniert nur dank kreativer Nutzung der TCP/IP-Software des Clients und liberaler Auslegung des Standards RFC 1122.

Das Antwortpaket des Servers hat als Zieladresse schon die Adresse, die der Client erhalten soll. Dieses Paket kommt beim Client an, weil die MAC-Adresse die des Clients ist. Muss ein solches Paket durch einen Paketfilter, ist es sinnvoll, eine Regel einzurichten, die Pakete mit beliebiger Quelladresse (für manche Filter-Implementierungen ist 0.0.0.0 problematisch) und Zieladresse 255.255.255.255 auf Port 68 zulässt, in der Rückrichtung entsprechend vom DHCP-Server an beliebige Adressen (hier könnte auf den DHCP-Bereich eingeschränkt werden) auf Port 67.

Zurück zum Vergabe-Vorgang: Nun erhält der Client ein Angebot vom Server. Wenn der Client es für akzeptabel hält, schickt er ein DHCPREQUEST nach diesen Daten zum Server, um ihm damit mitzuteilen, dass er gerne diese Konfiguration benutzen möchte. Der Server bestätigt dies mit einem DHCPACK - und der Client hat seine IP-Adresse. Sollte etwas schief gegangen sein, (der Client stellt zum Beispiel fest, dass aufgrund von Konfigurationsfehlern die Adresse jetzt doppelt vergeben ist), schickt er ein DHCPDECLINE an den Server und die Prozedur beginnt aufs Neue.

Abbildung 1: Ablauf einer normalen DHCP-Adressvergabe innerhalb eines Netzwerk.

Clients, die ihre Adresse behalten wollen

Wenn der Client herunterfährt, kann er die Adresse mit einer DHCPRELEASE-Nachricht an den Server wieder freigeben. Ein Client kann sich seine zuletzt zugewiesene IP-Adresse allerdings auch über einen Reboot merken und sie erneut vom Server anfordern. Dann entfallen die ersten Schritte der Konfiguration und der Client schickt direkt die DHCPREQUEST-Nachricht an den Server. Der bestätigt die Adresse oder schickt eine DHCPNAK-Nachricht, um dem Client mitzuteilen, dass er seine gespeicherte Konfiguration vergessen und mit der Anfrage von vorne anfangen soll.

Erhält der Client bei der Frage nach der Bestätigung seiner Adresse keine Antwort, da der DHCP-Server nicht reagiert, so kann er die gespeicherte Adresse weiterhin verwenden. Wenn eine Gültigkeitsdauer übergeben wurde (im DHCP-Jargon: Lease-Time), darf die Adresse nur so lange weiterverwendet werden, wie die Lease-Time noch gültig ist.

Liegt zwischen Client und Server ein Router, dann gehören beide unterschiedlichen Subnetzen an. Der Router kann die DHCP- und BOOTP-Anfragen aber weiterleiten. Er setzt dabei das Feld »giaddr« der DHCP-Message (die Struktur einer Message ist in Abbildung 2 dargestellt) auf die Adresse, die der Router im Netz hat, in dem er die Anfrage entgegennahm. Der DHCP-Server teilt dann eine Adresse zu, wenn er ein passendes Subnetz in seiner Konfiguration findet.

Abbildung 2: Format einer DHCP-Nachricht: Das Feld »op« bestimmt den Message-Typ, »htype«, »hlen« und »chaddr« die Hardware-Adresse des Clients. Die Transaktions-ID »xid« ist bei zusammengehörigen Nachrichten identisch.

Linux als DHCP-Client

Die meisten Linux-Distributionen erlauben es, Linux als DHCP-Client zu betreiben. Auch die PCMCIA-Cardservices sehen die Möglichkeit vor, den Rechner als DHCP-Client zu betreiben. Je nach Distribution sind die ablaufenden Prozesse unterschiedlich, aber der prinzipielle Ablauf ist immer gleich: Ein Programm (»dhclient«) schickt die DHCP-Anfrage ab. In der Antwort des Servers stecken die notwendigen Informationen (Adresse, Netzmaske, Route, DNS-Server). Die notwendigen Schritte laufen dann automatisch ab:

  • »ifconfig« auf die IP-Adresse mit der übermittelten Netzmaske,
  • »route add default«, wenn eine Default-Route übergeben wurde,
  • »/etc/resolv.conf« wird neu erzeugt, die Parameter für die Nameserver und Domains werden eingetragen.

Selbst im Zuge einer Netzwerkinstallation können modernere Distributionen die IP-Adresse schon per DHCP zuweisen. Für Diskless-Linux-Rechner (Kernel-Option »kernel level Autoconfiguration«) ist ebenfalls DHCP als Option wählbar. In diesem Fall werden dem Client auch das NFS-Rootdirectory und der Hostname übergeben.

Abbildung 3: Die Konfigurationshierarchie bei der Datei »dhcpd.conf«. Dunklere Teile überschreiben die Einstellungen in den helleren Bereichen.

Linux als DHCP-Server

Bevor ein Linux-Server in der Lage ist, als DHCP-Server zu arbeiten, muss in der Regel der Kernel modifiziert werden. Das Betriebssystem sollte sich zudem in der Lage sehen, mit Raw-Sockets zu arbeiten. Das bedeutet, dass vollständige Pakete (also nicht nur die Nutzdaten eines IP-Pakets) aus einem geöffneten Socket gelesen werden. Die Pakete enthalten den vollständigen DHCP-Request eines Clients.

Um diese Option zu aktivieren, müssen bei »make menuconfig« beziehungsweise »make xconfig« unter »Network Options« die Schalter »Packet Socket« und »Socket Filtering« aktiviert sein. Lässt man versehentlich den DHCP-Client auf einen Kernel ohne diese Optionen los, gehen die entsprechenden Betriebssystemaufrufe ins Leere und eine Warnung weist auf die fehlende Kernel-Tauglichkeit hin.

Abbildung 4: DNS-Update nach Zuweisung einer DHCP-Adresse.

Die Serversoftware installieren

Die aktuelle Version des DHCP-Daemon des Internet Software Consortiums, das übrigens auch für den Nameserver BIND und den Newsserver INN verantwortlich zeichnet, gibt es unter[6]. Der Artikel behandelt die noch junge Version 3.0 der Software. Nachdem man die Software heruntergeladen hat, geht es mit

./configure

weiter. Hier läuft nicht das gewohnte »autoconf«, sondern ein einfaches Skript. Die Befehlsfolge

make
make install

baut und installiert den Daemon, einen Relay Agent (für Linux-Router, die DHCP-Requests weiterleiten sollen, siehe Abbildung 5) und die Omshell, ein Tool, um in die laufende Datenbank eines DHCP-Daemon zu schauen und diese zu manipulieren.

Abbildung 5: Ein Relay Agent kann DHCP-Anfragen an Server weiterleiten, die in einem anderen Subnetz liegen.

Die Konfiguration

Die Konfigurationsdatei des DHCP-Daemon ist »/etc/dhcpd.conf«. Sie ist hierarchisch aufgebaut. Es werden zunächst allgemein gültige Parameter definiert, die für alle Clients im Netz gelten. Beispiele sind Domainnamen und Log-Server.

Die nächste Hierarchiestufe sind Subnetze. Hier dürfen ebenfalls Parameter für die Clients, die in diesem Subnetz liegen, hinterlegt sein. Jedes Subnetz wird etwa einen eigenen Default-Router besitzen. Parameter innerhalb eines Subnetzes überschreiben globale Parameter. Bei den Subnetzen ist wichtig, dass der DHCP-Daemon nur auf Anfragen aus Subnetzen antwortet, die in der Datei »dhcpd.conf« stehen. Besitzt der Server mehrere Netzwerkkarten oder bekommt er von einem Router einen Request, für den er kein Subnetz verzeichnet hat, wird dieser ignoriert. Innerhalb der Subnetze lassen sich auch die Bereiche definieren, aus denen in diesem Subnetz Adressen vergeben werden.

Eine weitere Hierarchiestufe ist der Pool. Er ist innerhalb eines Subnetzes anzulegen. In ihm können auch Bereiche (Ranges) definiert werden, so dass es innerhalb eines großen Subnetzes (etwa einer ganze Klasse B) möglich ist, DHCP-Bereiche mit unterschiedlichen Parametern zu definieren. Pools werden auch für Hochverfügbarkeitsmechanismen benötigt, doch dazu später.

Schließlich gibt es die Hosts-Stufe. Sie reserviert einzelne Rechner, wenn der Administrator sicherstellen möchte, dass ein Rechner immer die gleiche IP-Adresse bekommt. Obgleich dies dem Ansatz von DHCP zuwiderläuft, kann es dafür Gründe geben, zum Beispiel Zugriffsregeln auf Server (Paketfilter oder Regeln in TCP-Wrappern, bei denen man nur einen Rechner und nicht den ganzen Bereich freischalten möchte). Ein anderes Motiv kann eine Softwarelizenz sein, die sich an die IP-Adresse des Rechners bindet, auf dem sie läuft.

Die vergebenen Adressen sind in der Datei »/var/state/dhcp/dhcp.leases« gespeichert. Vor dem ersten Start des DHCP-Servers muss sie mit dem Kommando »touch /var/state/dhcp/dhcp.leases« angelegt werden, sonst weigert sich der Daemon zu starten. Die Datei ist im Ascii-Format und dient auch dazu, bei einem Reboot des Systems (oder auch nur bei Start und Stopp des DHCP-Servers) die Information über die vergebenen Adressen zu erhalten.

Ein einfaches Konfigurationsbeispiel

Um das Ganze zu veranschaulichen, zeigt Listing 1 eine sehr einfache Konfigurationsdatei. Die erste Zeile setzt die Bezeichnung des DHCP-Servers, die dem Hostnamen des Servers entsprechen sollte. Zeile 2 setzt global für alle Clients die Domain »testnetz.de«, Zeile 3 den Nameserver »dns.testnetz.de« für alle Clients als Nameserver. Wenn an dieser Stelle mit Hostnamen und nicht mit IP-Adressen gearbeitet wird, müssen sie auflösbar sein, denn sonst startet der Server nicht.

Zeile 4 setzt den Default-Router global auf die Adresse 192.168.1.1. Als Nächstes wird das Subnetz 192.168.1.0 festgelegt, innerhalb dessen die IP-Adressen von 192.168.1.10 bis 192.168.1.50 als vergebbarer Bereich definiert sind. Die darauf folgende Zeile stellt einen Bereich für jene Geräte zur Verfügung, die nur BOOTP beherrschen. Für alle Clients in diesem Subnetz gilt die Broadcast-Adresse 192.168.1.255, das bewerkstelligt Zeile 9.

IP-Adressen werden für einen Standardzeitraum von zehn Stunden vergeben, danach muss der Client wieder nachfragen, ob er die Adresse behalten darf. Die Max-Lease-Time mit 20 Stunden setzt die Obergrenze fest, wie lange der Client seine Adresse nutzen darf, falls er keine Antwort vom Server erhält.

Der Host »extrawurst« (immer noch in Listing 1) hat die reservierte IP-Adresse 192.168.1.5, die zudem nicht aus dem Bereich der anderen Clients stammt. Wäre die Adresse aus diesem Bereich, stellte der DHCP-Server automatisch sicher, dass sie kein anderer Host zugeteilt bekommt. Woher weiß jetzt der DHCP-Server, dass »extrawurst« nach (s)einer IP-Adresse fragt? In der Konfiguration des Beispiels erreichen das folgende zwei Parameter:

  • Die Ethernetadresse des Hostes ist hinterlegt und
  • der Hostname selbst wird zu seiner Definition verwendet.

In DHCP-Requests darf bekanntlich der Hostname des Absenders stehen. Erfolgt dies bei dem Client, für den eine Reservierung vorgenommen werden soll, ist die Angabe der MAC-Adresse unnötig. Fordert der Client allerdings seine Adresse per BOOTP an oder ist er eine Diskless-Linux-Maschine mit Kernel-Level-Autoconfiguration, ist zum Zeitpunkt der Anfrage sein Hostname unbekannt - also bleibt das einzige Erkennungsmerkmal die Hardware-Adresse.

Das Beispiel »extrawurst« zeigt auch, dass spezielle Optionen allgemeinere überschreiben. Nach dieser Logik bekommt die Maschine eine andere Default-Route mitgeteilt.

Listing 1: Beispiel für eine Konfigurationsdatei

01 server-identifier dhcp.testnetz.de;
02 option domain-name "testnetz.de";
03 option domain-name-servers dns.testnetz.de;
04 option routers 192.168.1.1;
05
06 subnet 192.168.1.0 netmask 255.255.255.0 {
07   range 192.168.1.10 192.168.1.50;
08   range dynamic-bootp 192.168.1.50 192.168.1.60;
09   option broadcast-address 192.168.1.255;
10   default-lease-time 36000;
11   max-lease-time 72000;
12   option subnet-mask 255.255.255.0;
13 }
14
15 host extrawurst {
16   hardware ethernet 00:11:22:33:44:55;
17   option host-name "extrawurst";
18   option routers 192.168.1.2;
19   fixed-address 192.168.1.5;
20 }

Diskless Linux

Ein eigenes Kapitel sind die Parameter für Diskless Linux-Maschinen. Diese Hosts müssen einen Namen und einen Boot-Pfad mitgeteilt bekommen. Hier ein Beispieleintrag:

host birdcage {
  hardware ethernet aa:bb:cc:dd:ee:ff;
  option root-path "/tftpboot/birdcage";
  option routers 192.168.1.1;
  option host-name "birdcage";
  fixed-address birdcage.testnetz.de;
}

Der Hostname wird über die Option »host-name« und der Boot-Pfad (NFS-Root) mit der Option »root-path« mitgegeben. Wenn bei »fixed-address« ein Hostname steht, wird er beim Start des DHCP-Servers evaluiert. Ändert man den Namen innerhalb der DNS-Konfiguration, dann bekommt der Client eine andere IP-Adresse, wenn er das nächste Mal fragt.

DCHP-Server hält den DNS auf dem Stand der Dinge

Rechner mit festen IP-Adressen sind der Standardfall für DNS, die Zuordnung von Name und IP-Adresse ist hier leicht. Beim Einsatz von DHCP würde der ständige Wandel den Administrator viel Schweiß kosten, wollte er die DNS-Veränderungen manuell einpflegen.

Um dynamisch vergebene Adressen inklusive der Hostnamen durch den für die Domäne zuständigen Nameserver auflösen zu lassen, kann ein DHCP- Server seinem BIND-Kollegen Updates schicken. Damit dies einigermaßen abgesichert passiert, sollte es mit Hilfe eines DNS-Schlüssels geschehen, der in der Datei »named.conf« für eine ACL (Access Control List) benutzt wird. Active Directory von Windows 2000 erzwingt sogar, diese Updates der DNS-Zonen einzusetzen. In der »dhcpd.conf« müssen die Einträge aus Listing 2 in den allgemeinen Bereich eingefügt werden.

Für die zu aktualisierenden Forward- und Reverse-Zonen müssen Einträge definieren, wer der Nameserver ist, der die Updates empfangen soll, und welcher Schlüssel zu verwenden ist. Dieser Schlüssel sollte geheim, die »dhcpd .conf« also nur für Root lesbar sein. Es handelt sich um ein Shared Secret: Die Authentifizierung der Updates basiert darauf, dass beide Partner diesen Schlüssel kennen. Das Programm »dnssec-keygen« - es gehört zu BIND - erzeugt solche Keys.

Innerhalb der Subnetze muss der Administrator jetzt noch eintragen, wie die Vorwärtszone für die Updates heißt. Das geschieht mit Hilfe der Option »ddns-domainname "testnetz.de"«. Die Reverse-Einträge erfolgen automatisch, wenn für die Reverse-Zone des Netzes ein Eintrag vorhanden ist.

Um dem Name-Daemon beizubringen, dass er Updates gestatten soll, ist in die »named.conf« der gleiche Key-Eintrag zu platzieren wie in »dhcpd .conf«. Die Definitionen der Zonen »testnetz.de« und der Reverse-Zone sind in Listing 3 ausführlich zu sehen.

Damit werden Updates laufend wirksam, also neue Einträge hinzugefügt und abgelaufene Leases aus der Zone gelöscht. Die Updates erfolgen, nachdem eine Adresse zugewiesen wurde, wie in Abbildung 4 dargestellt. Verfügt der Nameserver auch über Secondaries, dann sollte der Administrator außerdem auf deren Update-Zyklen achten, da diese sonst der Dynamik der DHCP-Vergabe hinterherhinken.

Listing 2: >>dhcpd.conf<< für den Nameserver-Update

01 ddns-update-style ad-hoc;
02 zone testnetz.de. {
03   primary 192.168.1.1;
04   key "secret";
05 }
06 zone 1.168.192.in-addr.arpa. {
07   primary 192.168.1.1;
08   key "secret";
09 }
10 key "secret" {
11   algorithm hmac-md5;
12   secret "
dnssec-schluessel";
};

Listing 3: Definition der Zonen in >>named.conf<<

01 zone "testnetz.de" {
02   type master;
03   file "named.testnetz";
04   allow-update { key "secret" ; };
05 };
06
07 zone "1.168.192.in-addr.arpa" {
08   type master;
09   file "named.192.168.1";
10   allow-update {
11     localhost;
12     key "secret";
13   };
14 };

Listing 4: >>dhcpd.conf<< für den Primary-Server

01 failover peer "dhcp" {
02   primary;
03   address dhcp.testnetz.de;
04   port 519;
05   peer address reserve.testnetz.de;
06   peer port 519;
07   max-response-delay 60;
08   max-unacked-updates 10;
09   mclt 3600;
10   split 128;
11   load balance max seconds 3;
12 }
13 subnet 192.168.1.0 netmask 255.255.255.0 {
14   option broadcast-address 192.168.1.255;
15   default-lease-time 864000;
16   max-lease-time 864000;
17
18   option routers 192.168.1.1;
19   option subnet-mask 255.255.255.0;
20   ddns-domainname "testnetz.de";
21   pool {
22     range 192.168.1.10 192.168.1.50;
23     failover peer "dhcp";
24   }
25 }

Hochverfügbarkeit

DHCP ist ein kritischer Dienst. Daher bietet der DHCP-Server auch die Möglichkeit der Hochverfügbarkeit: Ein weiterer Server kann aufgestellt werden, der die gleiche Range betreut wie der erste. Dieser ist als Secondary-DHCP (nicht zu verwechseln mit Secondaries bei DNS) definiert. Wenn er startet, holt er sich über ein eigenes Protokoll die Datei »dhcp.leases« des Primaries. Schickt nun ein DHCP-Client eine Anfrage durchs Netz, bilden beide DHCP-Server darüber einen Hash. Je nachdem, ob dieser Hash gerade oder ungerade ist (man kann das sogar noch feiner definieren), antwortet der erste oder der zweite Server, so dass auch noch ein Loadbalancing beider stattfindet.

Wenn einer der beiden DHCP-Server ausfällt (Ausfall ist dadurch definiert, dass keine TCP-Verbindung mehr zwischen beiden existiert), beantwortet der verbliebene alle Anfragen. Meldet sich der verschollene Bruder wieder im Netz, gleichen beide ihre »dhcp.leases« ab. Die Konfiguration zweier Partner bezieht sich immer auf einen Pool-Eintrag. Das macht es sogar möglich, mehr als zwei Server im Spiel zu halten.

Ein Abschnitt aus einer »dhcpd.conf« soll zeigen, wie dies konfiguriert wird (siehe Listing 4). Zunächst muss ein »failover peer« definiert werden. Er hat einen symbolischen Namen, der später im Pool verwandt wird. Der »address«-Eintrag bezeichnet den eigenen Hostnamen (bei Maschinen mit mehreren Adressen werden nur auf dieser Adresse Verbindungen entgegengenommen). Die Port-Anweisung gibt an, auf welchem Port Verbindungen entgegengenommen werden. Mit »peer address« und »peer port« gibt man Hostnamen und Port- Nummer des Partners im Verbund an. Die nächsten drei Parameter dienen zur Definition von Timeouts und zur Lease-Synchronisation.

Eine »split«-Anweisung auf dem Primary-Server definiert, wo die Grenze für das Loadbalancing gezogen wird. »128« bedeutet eine Halbierung. Der letzte Parameter macht den Timeout bekannt, also den Zeitpunkt des Abschaltens vom Loadbalancing. Wenn ein Client im Loadbalancing-Modus eine Anfrage stellt und nach diesem Timeout von der Gegenseite keine Antwort erhält, stellt der andere Server die Hinfälligkeit des Loadbalancing fest und gibt dem Client selbst eine Antwort.

Innerhalb des Subnetzes muss nun ein Pool angelegt werden, dem mit der »failover peer "Name"«-Anweisung die Definition des Partners zugewiesen wird. Auf dem Secondary-Server sieht die Konfiguration wie in Listing 5 aus. Damit ist der Dienst DHCP ausfallsicher konfiguriert und die beiden Server »dhcp« und »reserve« teilen sich die Arbeit. Im realen Betrieb ist es der Beachtung wert, dass die Subnetz-Parameter und die globalen Parameter beider Server möglichst ähnlich gehalten werden. (jk/fjl)

Listing 5: >>dhcpd.conf<< für den Secondary-Server

01 failover peer "reserve" {
02   secondary;
03   address reserve.testnetz.de;
04   port 519;
05   peer address dhcp.testnetz.de;
06   peer port 519;
07   max-response-delay 60;
08   max-unacked-updates 10;
09   load balance max seconds 3;
10 }
11 subnet 192.168.1.0 netmask 255.255.255.0 {
12   option broadcast-address 192.168.1.255;
13   default-lease-time 864000;
14   max-lease-time 864000;
15   option routers 192.168.1.1;
16   option subnet-mask 255.255.255.0;
17   pool {
18     range 192.168.1.10 192.168.1.50;
19     failover peer "reserve";
20   }
21 }
Sicherheitsbedenken gegen DHCP

In den meisten RFCs gibt es ein Kapitel "Security Considerations". RFC 2131 ist keine Ausnahme. Die Autoren des RFC geben zu: "DHCP in der aktuellen Form ist völlig unsicher." Die Ursachen sind: DHCP basiert auf UDP, was es einfach macht, Pakete dazwischenzumogeln. Zudem ist es vergleichsweise simpel, falsche DHCP-Server und gefälschte Clients in ein Netz einzuschleusen. Ein Absichern durch Schlüssel oder Eintragen von MAC-Adressen würde dem Sinn von DHCP, Systeme einfach zu konfigurieren, widersprechen. Mögliche Denial-of-Service-Angriffe könnten darin bestehen, sich alle Adressen eines Ranges zuweisen zu lassen oder auf alle Anfragen mit der gleichen IP-Adresse zu antworten, so dass es lauter doppelte IP-Adressen gibt und damit das Netzwerk aufhört zu funktionieren.

Der Einsatz von DHCP weicht unter Umständen auch auf andere Weise die Sicherheit in einem Netz auf. Wenn Zugriffsregeln auf Systeme (etwa in einer Firewall oder auch nur für einzelne Dienste) aufgrund von IP-Adressen gesetzt werden, muss immer gleich der gesamte DHCP-Bereich freigegeben werden. Ohne eine Reservierung wäre nicht sichergestellt, dass ein Rechner zweimal die gleiche Adresse zugewiesen bekommt. Bei Login-Freischaltung per ».rhosts« kann dies ein offeneres Netz ergeben als beabsichtigt.

Ein weiterer unerwünschter Effekt tritt bei SSH auf: Der SSH-Client merkt sich für jeden Rechner, auf dem er sich einloggt, den Hostkey mit Hostnamen und Adresse. Wenn diese beim nächsten Versuch nicht mehr mit der gespeicherten Version übereinstimmen, wird eine deutliche Warnung ausgegeben und bestimmte Funktionalitäten wie X11- und Port-Forwarding werden abgeschaltet. Für SSH sieht diese Konfigurationsänderung wie ein Angriff aus, bei dem sich ein Host als ein anderer ausgibt.

Tabelle 1: DHCP-Nachrichten
Infos

[1] Dynamic Host Configuration Protocol: [ftp://ftp.isi.edu/in-notes/rfc2131.txt]

[2] DHCP Options and BOOTP Vendor Extensions: [ftp://ftp.isi.edu/in-notes/rfc2132.txt]

[3] DHCP Option for The Open Group's User Authentication Protocol: [ftp://ftp.isi.edu/in-notes/rfc2485.txt]

[4] Procedure for Defining New DHCP Options: [ftp://ftp.isi.edu/in-notes/rfc2489.txt]

[5] Bootstrap Protocol: [ftp://ftp.isi.edu/in-notes/rfc951.txt]

[6] Homepage des ISC-DHCP-Daemon: [http://www.isc.org/products/DHCP/]

[7] Homepage des Nameservers BIND: [http://www.isc.org/products/BIND/]

[8] Ralph Droms, Ted Lemon: "The DHCP Handbook - Understanding, Deploying, and Managing Automated Configuration Services"; New Riders Publishing

Der Autor

Konstantin Agouros beschäftigt sich seit 1989 mit Unix und dem Internet und seit 1994 mit Linux. Er leitet bei der Firma Net Age das Competence Center Security und berät Kunden in Fragen der IT-Security. Ist sein Rat mal nicht gefragt, beschäftigt er sich mit esoterischer Perl-Programmierung oder spielt eine Runde Counter-Strike.

Copyright © 2002 Linux New Media AG

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.