Das Radius-Protokoll dient meist dazu, Benutzer an Dial-in-Systemen zu authentifizieren. In Kombination mit 802.1X schützt Radius aber auch lokale Netze: Anwender und deren Rechner müssen sich erst in tiefen Protokollschichten authentifizieren, bevor der Switch ihren Port freigibt.

Angriffe aus dem internen Netz sind gefährlich und schwerer zu unterbinden als Attacken von außen. Wer beispielsweise sein eigenes Notebook an eine Netzdose anschließt, erhält in der Regel guten Zugriff auf fremde Firmendaten. Dagegen hilft eine sichere Authentifizierung auf der OSI-Schicht 2 mit dem Protokoll 802.1X[1]. Ein 802.1X-fähiger Switch und ein Linux-Rechner mit einem Freeradius-Server genügen für diese interne Sicherheitsmaßnahme.

Die Radius-Antworten (Remote Authentication Dial-in User Service Protokoll) des Linux-Servers enthalten gewöhnlich die IP-Adresse und das Default-Gateway für den User. Das Protokoll beherrscht aber mehr: Es ist möglich, dem Switch-Port des Benutzers ein VLAN[7] zuzuweisen. Damit darf das Gesamtnetz flach sein, also ohne aufwändige Router-Infrastruktur, und dennoch bleiben die Broadcast-Domains begrenzt. Außerdem trennen VLANs die Firmenabteilungen logisch voneinander, der Sicherheit im Netz ist das sehr zuträglich. Auch wenn sich Benutzer an beliebigen Arbeitsplätzen einloggen dürfen (etwa in der Cafeteria), sehen sie immer nur ihre eigene Netzwerkumgebung.

802.1X und EAP

Für die Authentifizierung ist der Standard 802.1X zuständig. Als AAA-Server (Authentication, Authorization und Accounting) kommt Freeradius zum Einsatz, das seine Informationen wiederum aus einem OpenLDAP-Verzeichnisserver zieht. Damit sind große Mengen an Benutzerdaten recht einfach zu verwalten. Das Gesamtsystem eignet sich für Linux- und Windows-Clients gleichermaßen und lässt sich für Hochverfügbarkeit redundant auslegen: Beim Radius-Dienst sind dafür Proxysysteme zuständig, bei der LDAP-Datenbank die Replikation des Verzeichnisses.

Mit etwas Zusatzaufwand eignet sich die beschriebene Lösung auch, um WLANs zu sichern (siehe Kasten “802.1X und Wireless LAN”) oder die vielfältigen Accounting-Möglichkeiten des Radius-Servers einzusetzen.

Das IEEE-802.1X-Protokoll dient der Zugangskontrolle auf OSI-Schicht 2 (MAC-Schicht). Es besorgt die Authentifizierung eines Clients, sobald er sich mit dem Netz verbindet, und zwar bevor er über DHCP (Dynamic Host Configuration Protocol) eine IP-Adresse erhält. Der Standard legt unter anderem fest, wie das Authentifizierungsprotokoll (EAP, Extensible Authentication Protocol) über Kabel oder Funknetzwerk in Ethernet-Frames verpackt wird. Deshalb heißt 802.1X auch EAPOL (EAP over LAN). Neben EAP basiert 802.1X zusätzlich auf PPP (Point to Point Protocol). PPP und EAP sind Internetstandards (in RFCs definiert), während 802.1X von der IEEE (Institute of Electrical and Electronics Engineers) stammt.

EAP dient als Rahmen für verschiedene Authentifizierungsmethoden, die mehr als die übliche Kombination aus Benutzername und Passwort übertragen. EAP öffnet einen Tunnel durch den Network Access Server (Authenticator) zum tatsächlichen Authentifizierungsserver. Durch diesen Tunnel laufen dann andere Protokolle. 802.1X verwendet für die beteiligten Instanzen eigene Begriffe, siehe auch Abbildung 1:

• Der zu authentifizierende Client heißt Supplikant.
• Der Server, der die Authentifizierung tatsächlich
  durchführt, heißt Authentication Server.
• Das Netzwerkgerät zwischen diesen beiden Elementen
  heißt Network Authentication Server (NAS) oder
  Authenticator.

Abbildung 1: Das 802.1X-Protokoll besteht aus mehreren Schichten. Zwischen Supplicant und Authenticator ist EAP zuständig, Radius für den Weg vom Authenticator zum Authentication Server. Damit überträgt 802.1X den EAP-Payload und die höheren Protokolle vom Supplikanten zum Authentication Server.

Dieser Aufbau funktioniert in jedem Netz, das Ethernet-Pakete verschickt, also zum Beispiel in WLAN-Funknetzwerken oder normalen Kabelnetzen. Einen guten Überblick geben die Whitepapers der Interopnet Labs[1].

Viele EAP-Varianten

In EAP sind mehrere Authentifizierungsmethoden definiert. Bei EAP/MD5 weist sich der Benutzer mit seinem Usernamen und Passwort aus. Das Protokoll überträgt nur einen Hashwert, in den Name, Passwort und ein Zufallswert einfließen. Der Server kennt das Klartextpasswort und den Zufallswert ebenfalls, berechnet den gleichen Hash und vergleicht die Werte. Diese Methode ist einfach installiert, aber gegen Wörterbuchattacken nicht sicher. Beim Einsatz im Wireless LAN ist es bei EAP/MD5 zudem unmöglich, die WEP-Schlüssel (Wired Equivalent Protocol) dynamisch zu erzeugen. Sie eignet sich daher nur für kabelgebundene Netze.

Bei der zweiten Variante, also EAP/TLS, erhalten der Server sowie der Client oder der Benutzer eigene X.509-Zertifikate. Diese Methode ist wesentlich sicherer, erfordert aber eine komplette PKI (Public Key Infrastructure,[11]).

Protected EAP

Die dritte gängige Methode heißt PEAP, Protected Extensible Authentication Protocol. Hier braucht nur der Server ein Zertifikat, das Protokoll baut damit eine sichere TLS-Verbindung auf und überträgt darüber den Benutzernamen und das Passwort verschlüsselt (MSCHAPv2, Microsoft Challenge Handshake Authentication Protocol). Es genügt, das Zertifikat des Servers auf jedem Client einzuspielen. Falls sich der Client abmeldet oder den Anschluss trennt, erkennt PEAP dies, beendet die Autorisierung und sorgt für ein eindeutiges Ende.

In rein kabelgebundenen Netzen erweist sich EAP/MD5 oft als die beste Variante. Sie reicht aus, um VLANs dynamisch zuzuordnen und wird – im Gegensatz zu PEAP – von vielen Switches unterstützt. Auch ist der Administrationsaufwand deutlich niedriger als bei PEAP oder besonders bei EAP/TLS.

Die NAS-Aufgabe erfüllt meist ein Switch. Er übersetzt das EAPOL-Protokoll (EAP over LAN) des Supplikanten in das Radius-Protokoll, das der Access-Server erwartet. Die meisten Geräte bieten diese Option bei der Konfiguration von 802.1X an. Einzutragen sind die Adresse und das Passwort des Radius-Servers. Oft lassen sich auch mehrere Server konfigurieren, um beim Ausfall eines Geräts auf einen Ersatzserver umzuschalten und damit die Verfügbarkeit zu erhöhen.

01 replyItem Tunnel-Type radiusTunnelType
02 replyItem Tunnel-Medium-Type radiusTunnelMediumType
03 replyItem Tunnel-Private-Group-Id radiusTunnelPrivateGroupId

01 dn:uid=vlan_02,ou=profiles,ou=radius,dc=domain,dc=de
02 uid: vlan_02
03 radiusTunnelMediumType: IEEE-802
04 radiusTunnelType: VLAN
05 radiusTunnelPrivateGroupId: 2
06 objectClass: radiusprofile
07 objectClass: top

01 dn:uid=testuser2,ou=users,ou=radius,dc=domain,dc=de
02 uid: testuser2
03 userPassword: password
04 objectClass: radiusprofile
05 objectClass: top
06 radiusProfileDn: uid=vlan_02,ou=profiles,ou=radius,dc=domain,dc=de

01 modules {
02    ldap {
03       server = "ldap.domain.de"
04       identity = "cn=freeradius,ou=admins,ou=radius,dc=domain,dc=de"
05       password = secret
06       basedn = "ou=users,ou=radius,dc=domain,dc=de"
07       filter = "(&(uid=%{Stripped-User-Name:-%{User-Name}})(objectclass=radiusprofile))"
08       start_tls = no
09       dictionary_mapping = ${raddbdir}/ldap.attrmap
10       password_attribute = userPassword
11    }
12 }
13 
14 authorize {
15    preprocess
16    ldap
17    eap
18    suffix
19    files
20 }
21 
22 authenticate {
23    eap
24 }

Freeradius

Für den Radius-Server ist Freeradius[4] eine gute Wahl. Mitte 2004 erschien Version 1.0, kurz danach 1.0.1. Seit der letzten stabilen Version 0.93 ist die Unterstützung für eine Reihe von EAPs dazugekommen, speziell auch PEAP. Die Entwickler haben die Authentifizierung gegen eine Windows-Domäne neu integriert. Schon länger holt Freeradius die Account-Daten aus den üblichen Quellen »/etc/passwd«, LDAP, MySQL, PostgreSQL oder Oracle-Datenbanken.

Die Installation ist mit dem gewohnten Dreisatz »configure && make && make install« recht einfach. Danach stehen die Konfigurationsdateien des Servers unter »/usr/local/etc/raddb« bereit. Zuerst muss Freeradius den Zugriff für die Radius-Clients (hier den NAS) gestatten. Dafür ist das File »clients.conf« zuständig. Für einen Switch mit der festen IP-Adresse »192.168.200.20« lautet die Konfiguration beispielsweise:

client 192.168.200.20 {
   secret = 
 
  testing123
 
   shortname = switch
}

Das Passwort (»testing123«) muss der Admin auch auf dem Switch eintragen, und zwar bei der Konfiguration des Radius-Servers.

Die erlaubten Client-Adressen versteht Freeradius auch in der CIDR-Notation (Classless Inter-Domain Routing) für ganze Netze: 192.168.200.0/24. In älteren Versionen von Freeradius war noch das Wörterbuch »dictionary.tunnel« für die VLAN-Rückgabewerte anzupassen. Seit Version 1.0 ist dies nicht mehr notwendig. Die komplette Konfiguration für EAP findet sich nicht mehr in der zentralen Konfigurationsdatei »radiusd.conf«, sondern in der Datei »eap.conf«. MD5 ist dort als Standard vorbereitet.

Authentifizierung der Benutzer

In der Datei »users« wird die Art der Benutzerauthentifizierung konfiguriert. Folgender Eintrag genügt für einen ersten Test:

testuser Auth-Type := Local,
   User-Password == "tpasswd"
   Reply-Message = "Hello, %u"

Der Radius-Server sollte vorerst im Debug-Modus laufen: »radiusd -X«, dann gibt er seine Fehler- und Warnmeldungen auf der Konsole aus. Das Kommandozeilenprogramm »radtest« dient als Test-Client, um die Konfiguration auf direktem Weg zu prüfen. Mit den bisherigen Einstellungen lautet der Aufruf »radtest testuser tpasswd localhost 0 testing123«. Die hinteren drei Parameter bezeichnen den Radius-Server – damit das klappt, muss »localhost« als erlaubter Radius-Client in »clients.conf« eingetragen sein. Den Aufruf sollte Freeradius dann mit »Access-Accept« quittieren.

Abbildung 2: Neue Clients müssen sich erst am NAS (also am Switch) authentifizieren. Der Switch arbeitet als Vermittler zum Radius-Server, der seine Daten wiederum aus einem LDAP-Verzeichnis zieht. Den authentifizierten Clients weist der Switch ein VLAN zu.

Das Radius-Protokoll kann mehr als nur eine kleine Meldung zurückgeben, zum Beispiel die Nummer eines VLAN. Der Switch wertet diese Nummer aus, um den Client in das gewünschte VLAN aufzunehmen. Dazu ist obige Radius-Antwort in der Konfiguration des Test-Users zu ergänzen. Achtung: Die Rückgabewerte mit Kommata trennen und mit Leerzeichen einrücken:

testuser Auth-Type := Local,
   User-Password == "tpasswd"
   Reply-Message = "Hello, %u",
   Tunnel-Medium-Type = IEEE-802,
   Tunnel-Private-Group-Id = 1,
   Tunnel-Type = VLAN

Somit weist der Switch dem Benutzer »testuser« das VLAN 1 zu, sobald er authentifiziert ist. Bei einer überschaubaren Anzahl an Benutzern genügt das schon, der Admin kann alle anderen User ebenfalls manuell konfigurieren. In größeren Netzen ist das allerdings unpraktikabel.

OpenLDAP

Als Backend für Freeradius bietet sich OpenLDAP[8] an. Damit entsteht die in Abbildung 2 gezeigte Architektur. Eine gutes Howto über die Zusammenarbeit von Freeradius und OpenLDAP gibt es bei Dustin Doris[5]. Eine Konfiguration ist auch in der Freeradius-Dokumentation im Textdokument »doc/rlm_ldap« beschrieben.

Eine kleine Falle steckt allerdings in dem LDAP-Schema »RADIUS-LDAPv3.schema« (es befindet sich ebenfalls im »doc«-Verzeichnis). Dieses Schema ist nicht structural, funktioniert also nur zusammen mit einen anderen Schema, zum Beispiel »inetorgperson.schema«. Das Schema von[5] ist hingegen ausschließlich für den Einsatz bei Radius gedacht. Es kennt keine Erweiterungen, die der normale Betrieb häufig erfordert.

Damit Freeradius die Antworten der LDAP-Datenbank bezüglich der VLANs auch versteht, ist noch eine Ersetzungshilfe in »ldap.attrmap« in der Radius-Konfiguration erforderlich (Listing 1).

VLAN im LDAP-Profil

Der Aufbau des LDAP-Verzeichnisses ist in Abbildung 3 zu sehen. Die Profile (»ou=profiles«) erhalten die Konfiguration der VLANs; Listing 2 zeigt das LDIF-File für »uid=vlan_02« (Zeile 1). Bei der Konfiguration der Benutzer (»ou=users«) genügt ein Verweis auf das Profil mit dem richtigen VLAN (Listing 3, Zeile 6). Jetzt muss der Radius-Server noch wissen, dass er auf die Benutzerverwaltung des LDAP zurückgreifen soll. Dafür ist eine Konfiguration in »radiusd.conf« nötig.

Das Beispiel in Listing 4 veranlasst Radius dazu, sich beim LDAP-Server »ldap .domain.de« (Zeile 3) unter der konfigurierten »identity« mit dem eingetragenen »password« anzumelden (Zeilen 4 und 5) und den Benutzer »filter« mit dem Passwort aus »password_attribute« zu authentifizieren (Zeilen 7 und 10). Falls dies gelingt, gibt der LDAP-Server die Parameter im zugehörigen Profil zurück (verbunden durch »radiusProfileDn« des Users).

Abbildung 3: In dieser LDAP-Verzeichnisstruktur sind neben Usern und Admins weitere Profile abgelegt, um die VLANs zu konfigurieren. In jedem User-Profil verweist ein »radiusProfileDn«-Eintrag zum passenden VLAN-Profil.

Ein neuer »DEFAULT«-Eintrag in der Benutzerverwaltung von Radius (File »users«) sorgt dafür, dass der Server Authentifizierungsversuche mit EAP richtig verarbeitet:

DEFAULT Auth-Type == EAP
   Fall-Through = yes

Jetzt bleibt noch, die Clients für die Authentifizierung mit 802.1X vorzubereiten. Für Linux programmiert das Open-1X-Projekt passende Software[2]. In Windows 2000 SP4 und WinXP SP1 ist diese Authentifizierungstechnik bereits eingebaut. Unter Windows 2000 muss dazu der Dienst »Drahtloskonfiguration« gestartet sein.

Windows-Client

Im Eigenschaften-Dialog des Netzwerkanschlusses taucht das Feld »Authentifikation« auf. Dort ist EAP mit den gewünschten Eigenschaften (MD5, PEAP oder TLS) zu bestimmen. Zusätzlich kann der User das Verhalten seines Systems festlegen, wenn keine Benutzerdaten zur Verfügung stehen. Das ist zum Beispiel vor dem Einloggen der Fall. Bei Anwahl dieses Punktes versucht der Computer sich am Netzwerk mit seinem Client-Namen anzumelden.

Im Gegensatz zur Auswahl von EAP/MD5 gibt es bei PEAP und TLS weitere Einstellmöglichkeiten: Der User muss das Zertifikat der CA angeben, das sein Rechner akzeptieren soll. Windows kann auch den Benutzernamen und das Passwort aus der Windows-Anmeldung für die Authentifizierung mit PEAP verwenden, der Eintrag dafür findet sich bei den erweiterten Möglichkeiten der Authentifizierung.

Das System benutzt aber in diesem Fall eine Kombination aus Domäne und Benutzernamen in der Form »Domain/ Username«. Wer unsicher ist: Die genaue Variante steht nach dem ersten Versuch im Logfile des Radius-Dienstes. Um dieses Format zu verstehen, braucht Radius entsprechende Hinweise (Hints). Interessierten sei das Radius-Buch[3] empfohlen.

Wer zu spät kommt …

Die 802.1X-Clients von Microsoft haben ein grundsätzliches Problem: Sie melden sich erst an ihrer Domäne an und authentifizieren sich danach am Netzwerk. Während der Client versucht sich an der Domäne anzumelden, ist das Netzwerk noch nicht verfügbar und die Anmeldung schlägt fehl. Der Domänenserver müsste ein einem immer offenen Standard-VLAN stehen, damit der Windows-eigene Supplikant funktioniert. Das widerspricht aber meist den Sicherheitsbedürfnissen.

Abhilfe schafft Zusatzsoftware von Fremdfirmen, die eigene 802.1X-Supplikanten anbieten. Diese Clients lassen sich meist viel genauer konfigurieren – beispielsweise so, dass der Client sich in den Domänen-Loginprozess einklinkt. Die Anmeldung beginnt dann mit der Authentifizierung am Netzwerk per 802.1X, erst danach läuft die normale Windows-Anmeldung. Allerdings benehmen sich viele Programme noch wie Betaversionen; vor dem Einsatz ist daher ausführliches Testen angeraten.

Für Linux-Clients gibt es ausgereifte 802.1X-Software unter[2]. Das Projekt hat inzwischen den Status 1.0 erreicht und bietet eine ausführliche Dokumentation. Damit ist es kein Problem, auch mit Linux-Rechnern Zugang zum Netz zu bekommen.

Skalierbares Konzept

Der Freeradius-Server bietet eine Vielzahl an Möglichkeiten, Benutzer zu authentifizieren und je nach Anwendung den Zugang passend zu konfigurieren. Der beschriebene Einsatz ist nur ein Beispiel. Durch den Einsatz eines Verzeichnisdienstes zur Benutzerverwaltung eignet sich das Sicherheitskonzept auch für sehr große Umgebungen, bei denen die Gefahr durch Angriffe von innen besonders groß ist. (fjl)