DHCP und RADIUS

DHCP

• Anschluß über einen Ethernet-Hub oder -Switch
• Zugang durch drahtlose Netze (und evtl. einen Router zum drahtlosen Subnetz)
• Zugang vom Internet über eine Firewall
• Modemzugang über einen Modemserver

Günstig wäre es, wenn der Zugang eines Rechners zum Netz folgenden Anforderungen genügen würde:

• automatisiert, d. h. ohne manuellen Eingriff
• authentifiziert, d. h. nur zugelassene Systeme erhalten Zugriff
• vollständig (Netz-, System- und Anwendungskonfiguration)
• standardisiert, d. h. für alle Systeme in einheitlicher Form

Eine Lösung für dieses Problem bietet DHCP (Dynamic Host Configuration Protocol). Dieser Dienst ermöglicht es, einem Client dynamisch eine IP-Nummer und andere Netzwerkparameter, wie den Netzwerknamen, die Gatewayadresse, etc., zuzuweisen, ohne daß der Administrator den Rechner überhaupt zu Gesicht bekommt. DHCP ist dabei völlig unabhängig von der eingesetzten Plattform. Das heißt, es kann sowohl Windows-Maschinen wie auch zum Beispiel Unix-Rechner mit den Netzwerkeinstellungen versorgen. Um ein Mindestmaß an Verfügbarkeitsanforderungen zu erfüllen, sollte natürlich mehr als nur ein DHCP-Server vorhanden sein, da sonst dessen Ausfall die Funktion sämtlicher Clienten beeinträchtigt.

Das in RFC 2131 definierte Protokoll DHCP arbeitet nach dem Client-Server-Modell. Als Server wird ein Programm bezeichnet, das den Pool der zu vergebenden Nummern verwaltet und sich darum kümmert, daß eine Nummer nicht zweimal vergeben wird. Der Client ist ein Programm auf dem lokalen Rechner, das zunächst den Server selbsttätig im Netz suchen muß und ihn anschließend darum bittet, eine IP-Nummer zuzuteilen. Die Grundfunktion des Servers ist recht einfach aufgebaut: über eine Konfigurationsdatei teilt der Administrator ihm mit, welche Adreßbereiche er für die Weitergabe an Client zur Verfügung hat. Fragt ein Client nach einer IP-Adresse, dann muß der Server zunächst nachsehen, ob noch eine Adresse frei ist. Diese freie IP-Nummer liefert er an den Client aus. Gleichzeitig muß er eine Datei (Leases-File) führen, in der er protokolliert, welche Adresse bereits an wen vergeben ist. Bei der Adreßvergabe sind drei verschiedene Modi einstellbar:

• Automatic Allocation: Fordert ein Client eine IP-Nummer an, wird sie ihm auf unbegrenzte Zeit zugeteilt, solange noch Adressen zur Verfügung stehen. Sind alle Adressen verbraucht, kann kein neuer Client mehr konfiguriert werden, auch wenn ein Teil der zuvor bedienten Rechner im Moment gar nicht eingeschaltet ist.
• Manual Allocation: In dieser Betriebsart geht es nur darum, Verwaltungsaufwand zu minimieren. In der Konfigurationsdatei ist für jeden Client im Netzwerk eine IP-Nummer fest zugeordnet. Der Server ist lediglich für die Auslieferung der Adresse an den Client verantwortlich.
• Dynamic Allocation: Jeder Client bekommt auf Anfrage eine IP-Nummer, solange im definierten Pool noch Einträge frei sind. Der Unterschied gegenüber der Automatic Allocation besteht darin, daß die IP-Nummer nur für eine bestimmte, maximale Zeitspanne (Lease-Time) gültig ist und vom Client innerhalb dieser Zeit zurückgegeben werden kann, wenn sie nicht mehr benötigt wird. Als einzige der drei Betriebsarten erlaubt Dynamic Allocation, kleine IP-Nummern-Pools mit einer großen Anzahl von Rechnern zu teilen. Einzige Voraussetzung: nicht alle Maschinen dürfen gleichzeitg laufen. Damit lassen sich auch Computer, die eher selten ins Netzwerk integriert werden, wie Laptops, zuverlässig mit einer IP-Nummer versorgen. Wird der Rechner vom Netz getrennt, kann die Adresse für eine andere Station verwendet werden. In dieser Betriebsart werden die meisten DHCP-Server betrieben.

DHCP ist eine Erweiterung des BOOTP-Protokolls und konkurriert in seiner Basisfunktionalität mit RARP. Gegenüber BOOTP zeichnet es sich vor allem durch die Flexibilität bzüglich der abfragbaren Konfigurationsparameter und durch das Konzept der Lease aus, d. h. die Möglichkeit eine Information dem Client gegenüber als nur begrenzt gültig zu markieren. Damit wird die Flexibilität bei Veränderungen der Netztopologie und weiterer Konfigurationsparameter gewahrt. Ferner ist die Unterstützung von großen Netzen, in denen nichts stets alle Systeme zugleich aktiv sind, mit limitierten Pools von Adressen möglich. Durch die Rückwärtskompatibilität zum PDU-Format von BOOTP ist die Verwendung existierender BOOTP-Relay-Agents in Subnetzen ohne DHCP-Server gewahrt.

Beim Start des Systems schickt der Client ein DHCPDISCOVER-Paket in Form eines Broadcasts an 255.255.255.255 (Phase 1). Anhand der Identifikation des Client im Paket können sich einige (oder ein einzelner) DHCP-Server entscheiden, dem Client die gewünschte IP-Adresse sowie andere Konfigurationsinformation in Form eines DHCPOFFER-Pakets zuzuteilen. (Vor der Vergabe können und sollten die Server die Konfliktfreiheit bzgl. der Adresse mittels ICMP-Ping oder ARP prüfen.) Der Client kann sich in Phase 2 aus den Antworten eine für ihn geeignete aussuchen und bestätigt dies gegenüber dem Server durch ein DHCPREQUEST-Paket (Phase 3). Entscheidungsparameter können z.B. die Leasedauer (t_l) oder die Menge der angebotenen Konfigurationsinformation Bei korrekter Information im DHCPREQUEST bestätigt der Server die Lease durch ein DHCPACK-Paket, womit die Konfiguration abgeschlossen ist Bevor die IP-Adresse verwendet wird, sollte der Client ihre Einzigartigkeit durch ein Gratuitious ARP prüfen. Sollte der Client die angebotene Adresse ablehnen wollen, teilt er dies durch DHCPDECLINE-Paket dem Server und beginnt nach einer kurzen Wartefrist erneut mit Phase 1. Sobald der Client die Bestätigung durch DHCPACK erhalten hat, ist er für die Ü berwachung der Lease-Dauer selbst verantwortlich. Insbesondere kennt das Protokoll auch keine Methode, einem Client die Lease zu entziehen. Vor Ablauf der Lease-Dauer (meist nach der Hälfte der Zeit = 0,5 * t_l) sollte der Client durch einen erneuten Durchgang durch Phase 3 versuchen, die Lease vom selben DHCP-Server verlängert zu bekommen. Gelingt ihm das nicht, kann er vor endgültigem Ablauf der Lease-Dauer (meist nach ca. 0,8 * t_l) die Phase 1 nochmals durchlaufen, um eine Verlängerung bzw. Neuausstellung der Lease (eventuell von einem anderen Server) zu erhalten. Die vorzeitige Aufgabe einer Lease sollte der Client dem Server durch ein DHCPRELEASE mitteilen, um den Pool freier Adressen möglichst groß und den Vergabestand im Server möglichst akkurat zu halten. Alle Zustandsübergange im Client sind in folgender Abbildung zusammengefaßt. Die Komplexität hat in der Vergangenheit zu einigen Fehlimplementierungen mancher Client-Software geführt, die jedoch aufgrund der großen "Toleranz" im Protokoll meist keine kritischen Auswirkungen hatten.

Der Vorgang "Lease erneuen" kann beliebig oft wiederholt werden, solange der Client die Adresse noch braucht und der Server nichts dagegen hat. Unter Umständen verweigert der DHCP-Server die Erneuerung. Falls die gewünschte Adresse für den DHCP-Server inakzeptabel ist, schickt er dem Client ein ablehnendes DHCPNAK. Der Client beginnt dann von Neuem.

Was passiert, wenn der Client den DHCP-Server nicht mehr erreichen kann, der ihm seine IP-Adresse zugeteilt hat? Bevor sein Lease verfällt, soll der Client den DHCPREQUEST nicht mehr direkt an den DHCP-Server schicken, sondern es broadcasten. Somit hören alle DHCP-Server wieder mit. Wenn Failover richtig funktioniert, wird der Backup-Server jetzt das Lease erneuen. Kommt hingegen nichtskeine Antwort oder nur ein DHCPNAK, muß der Client wieder von vorne beginnen, und ein DHCPDISCOVER broadcasten usw. Das ist insofern schlecht, als er nun höchstwahrscheinlich eine ganz andere IP-Adresse bekommt. Bestehende Verbindungen, die noch die alte IP-Adresse verwenden, müssen abgebaut werden.

Es darf natürlich nicht jeder beliebige Rechner Zugang zum LAN erhalten. Deshalb kann der DHCP-Server auch eingeschränkt werden - bis hin zu einer Liste von "erlaubten" MAC-Adressen. Man kann auch eine gemischte Versorgung der Rechner im Netz vorsehen, teils mit festen IP-Adresse (z. B. Server mit "Außenwirkung"), teils mit dynamisch zugewiesenen Adressen.

Remote-Zugang mit RADIUS

Ein spezieller Terminalserver-Modus gestattet es, sich mit einem normalen Terminalprogramm (z.B. Hyperterminal, Kermit, usw.) auf dem Access-Server anzumelden und von dort aus Telnetverbindungen aufzubauen. IP-Adressen werden normalerweise aus einem IP-Adresspool vergeben. Oft werden auch "virtuelle Verbindungen" unterstützt. Diese erlauben den physikalischen Abbau von Verbindungen, wenn gerade keine Daten übertragen werden, ohne daß die logische Verbindung verloren geht. Die Verbindung wird automatisch mit den gleichen Parametern wie vorher wieder aufgebaut, wenn Daten wieder übertragen werden müssen.

Für die standardisierte Authentifizierung am Modem- und Internetzugang setzt sich zunehmend das RADIUS-Protokoll (Remote Authentication and Dial-In User Service) durch. Seine Client-Proxy-Server-Architektur erlaubt die flexible Positionierung an Netzzugangspunkten und wird von fast allen Herstellern von Modemservern unterstützt. In Kombination mit DHCP und PPP ist die Aufgabe der Konfiguration der anwählenden Endsysteme in automatisierter Weise gelöst. Der Radius-Server ist ein zentraler Authentifizierungs-Server, an den sich alle RA-Server wenden. Auf diese Weise lassen sich unabhängig von der Netz-Infrastruktur alle Remote-User zentral verwalten und Benutzerprofile mit Zugangsrestriktionen definieren, aber auch zusätzliche Sicherheitsverfahren vorsehen. Beispielsweise kann festgelegt werden, dass der Nutzer nur nach einem Rückruf durch den Einwahlknoten an eine zuvor vereinbarte Rufnummer Zugriff auf das Unternehmensnetzwerk bekommen darf. Diese Informationen übergibt der Radius-Server an den RA-Server, der das weitere Login entsprechend koordiniert. Der Vorteil dieses Verfahrens liegt in den einmalig generierten Zugangsdaten der Nutzer, die auch in verteilten Netzwerken jederzeit aktuell verfügbar sind und mit einfachen administrativen Eingriffen an zentraler Stelle definiert und verändert werden können. Darüber hinaus ist die innerbetriebliche Abrechnung der Nutzung des Systems durch ein entsprechendes Accounting möglich.

Das Radius-Protokoll setzt auf UDP auf. Die Struktur eines Radius-Pakets ist ausgesprochen einfach. Es besteht aus fünf grundlegenden Elementen: einem Radius-Code, einem Identifier, einer Angabe zur Paketlänge, einem Authenticator und gegebenenfalls aus einer Reihe von Attributen. Der Radius-Code beschreibt die Aufgabe des Datenpakets.

Aufbau des Radius-Pakets

Die Codes 1, 2 und 3 verwalten den reinen Access vom Request bis zur Bestätigung oder Abweisung. Die Codes 4 und 5 dienen dem Accounting. Der Identifier ist acht Bit lang und dient der Zuordnung von Anfragen und Antworten. Das sicherheitstechnisch wichtigste Feld eines Radius-Rahmens ist der Authenticator, der eine Länge von 16 Oktetts beziehungsweise vier 32-Bit-Worten hat. Dabei wird zwischen dem Request Authenticator und dem Response Authenticator unterschieden. Inhalt des Request Authenticators ist eine Zufallszahl, die das gesamte Feld ausfüllt. Die Länge dieser Zufallszahl gewährleistet mit einer sehr hohen Wahrscheinlichkeit die Einmaligkeit dieses Wertes. Damit bietet das System einen gewissen Schutz vor Hackerattacken. Mit dem Versand des Request Authenticators werden die Zugangsdaten des Nutzers, der sich im gesicherten Netzwerk anmelden möchte, als Attribute übergeben. Der Radius-Server wird diese Anfrage entweder mit einer Access-Accept-, Access-Reject- oder Access-Challenge-Nachricht beantworten, die ihrerseits mit einem 16 Oktett langen Response Authenticator versehen ist. Dieser ist ein MD5-Hash-Fingerprint setzt sich zusammen aus dem empfangenen Radius-Paket einschließlich der Attribute sowie den geheimen Zugangsdaten, die auf dem Server abgelegt sind, zusammensetzt. Die Attribute eines Radius-Pakets beinhalten alle wichtigen Informationen, die zwischen dem RAS und dem Radius-Server ausgetauscht werden müssen.

Attribute sind sehr einfach aufgebaut

Attribute werden in einer Liste mit variabler Länge im Anschluss an den Authenticator übertragen. In den Attributen können natürlich Nutzernamen und Passwörter, aber auch IP-Adresse, Service-Typen, Status-Meldungen, Filter-IDs und - wichtig beim CHAP - ein entsprechender Challenge-Wert übergeben werden. Attribute werden in Datensätzen variabler Länge übertragen, die jeweils aus drei Feldern bestehen. Das erste aus acht Bit bestehende Feld benennt die Art des Attributes. Da nicht nur die Liste aller Attribute, sondern auch jeder einzelne Datensatz selbst in der Länge variabel ist, gibt das zweite Oktett die Länge des Attributes an. Erst ab dem dritten Oktett werden die eigentlichen Informationen übertragen.

Im einfachsten Fall wird ein Radius-Request mit einer Legitimierung des Nutzers oder dessen Abweisung beantwortet. Dazu folgt auf dem Access-Request eine Access-Accept- oder eine Access-Reject-Nachricht vom Radius-Server. Die Art der Antwort wird mit dem Radius-Code angezeigt. Das Verfahren harmonisiert mit PAP und CHAP.

Zurück

Inhaltsverzeichnis

Nächste

Diplomarbeiten zum Runterladen: