Open Source im professionellen Einsatz
Linux-Magazin 01/2005

Netzzugang auf Layer 2 sichern: 802.1X im LAN und WLAN mit Radius und LDAP

Schutz in der Tiefe

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.

945

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]).

802.1X und Wireless
LAN

Freeradius hilft zusammen mit 802.1X auch bei der Authentifizierung im Wireless LAN. Diese Kombination begrenzt die Gültigkeitsdauer der unsicheren WEP-Keys (Wired Equivalent Protocol) für einen Client zum Beispiel auf 30 Minuten. Das klappt aber nur im PEAP- Modus (Protected Extensible Authentication Protocol) oder im so genannten TLS-Modus (Transport Layer Security), da sich mit MD5-Hashes keine Schlüssel erzeugen lassen. Ein gutes Howto (wenn auch nicht mehr ganz aktuell) ist unter[6] zu finden.

PEAP und TLS verhandeln WEP-Schlüssel

Für PEAP muss der Admin ein Radius-Server-Zertifikat generieren. Windows-Clients brauchen das Zertifikat allerdings mit einer ganz bestimmten OID (Object ID) als Verwendungszweck. Im Verzeichnis »scripts« der Freeradius-Quellen befindet sich das Skript »CA.all«. Es generiert Beispielzertifikate für Server und Client. Das Zertifikat für den Client ist nur beim Einsatz von EAP/TLS nötig.

Wer beim Verwalten der Zertifikate die Annehmlichkeiten eines GUI nicht missen will, greift auf TinyCA[10] ab Version 0.6.4 zurück. Seit dieser Version ist es möglich, im erweiterten Verwendungszweck der Zertifikate die passende OID (zum Beispiel 1.3.6.1.5.5.7.3.1 für den Server) einzutragen.

Zertifikate für PEAP verteilen

Das neue Server-Zertifikat (das Skript verwendet »srv-cert.pem«) muss der Admin in das »certs«-Verzeichnis im Konfigurationsverzeichnis des Radius-Servers kopieren, ebenfalls das Zertifikat der CA »root.pem«. Beim Einsatz der TinyCA ist zusätzlich die Datei mit dem privaten Schlüssel zu kopieren. Windows-Benutzer installieren das CA-Zertifikat »root.der« einfach per Doppelklick auf die Datei. Das Gleiche geschieht mit dem Zertifikat des Radius-Servers »srv-cert.p12« (im Format PKCS#12).

Die Abschnitte »tls« und »peap« der EAP-Konfiguration des Radius-Servers sind entsprechend[6] einzurichten. Die Standardkonfiguration enthält diese Zeilen bereits, sie sind aber auskommentiert. Im Debug-Modus gestartet (»radiusd -X«) produziert Radius ausführliche Meldungen, was sich bei der Fehlerkontrolle als sehr hilfreich erweist.

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Hartes Türregime

    Öffentlich zugängliche Netzwerkdosen eröffnen trotz Firewall & Co. Angriffsvektoren. IEEE 802.1X bietet auch im kabelgebundenen Netz eine Lösung und macht aufwändiges Umpatchen überflüssig. Free Radius und Supplikant-Clients sichern mittels EAP-TLS und Benutzerzertifikaten den Zugang zum Switch.

  • Schutzwall

    Ein internes Netz ohne virenverseuchte oder einbruchsgefährdete Rechner ist die Idealvorstellung der Network Access Control (NAC). Um das zu erreichen, macht sie für die abgeschottete Produktivumgebung einen Zugangstest obligatorisch. Praktisch durchgesetzt hat sich die Idee jedoch noch nicht.

  • Besser abgesichert

    Wer seinen Rechner richtig absichern will, muss zu Einmalpasswörtern greifen. Da finden sich diverse proprietäre Backends, die mit Radius kommunizieren. Feature-technisch ist Lin OTP das einzige freie Pendant. Auch wenn es noch in einem frühen Stadium ist, hat es doch das Zeug zur ernsthaften Alternative.

  • Patchen ohne Kabel

    Mit einem VLAN können Netzwerk-Administratoren ihre Subnetze jederzeit neu aufteilen, ohne Kabel umzustecken, und an ihren Linux-Router wesentlich mehr Netze anschließen, als dieser Netzwerkkarten besitzt.

  • LDAP Account Manager 3.6 kann Free Radius

    LDAP Account Manager (LAM), ein Webfrontend zum Verwalten von Benutzerkonten, ist in Version 3.6 erhältlich.

comments powered by Disqus

Ausgabe 09/2017

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.