Dieser Artikel erschien zuerst auf Bents Blog.
Kürzlich habe ich in unserem Unternehmen ein sicheres WLAN aufgebaut – eigentlich zu Evaluierungszwecken gedacht, hat sich die Lösung doch recht schnell zu einer praktikablen und sicheren Variante zur Nutzung für unsere Mitarbeiter etabliert. Bei der Übertragung von Daten steht nach wie vor das Thema Sicherheit im Vordergrund – gerade was das Thema WLAN angeht, sollte die Sensibilität für sichere Verbindungen vorhanden sein. Der folgende Artikel beschreibt, wie ich das Thema umgesetzt habe, stellt aber ganz sicher nicht die praktikabelste Lösung für alle denkbaren Einsatzzwecke dar. Allein die Tatsache, dass mit Hilfe von Windows-Bordmitteln die Umsetzung einen relativ geringen Aufwand verursachte, macht diese Möglichkeit meiner Meinung nach sehr interessant.
Anforderungen an Funknetzwerke
Bevor man sich an die Umsetzung eines WLANs macht, sollte man sich im Vorfeld mit den gängigen, möglichen Sicherheitsstandards vertraut machen. Auch für Betreiber eines bereits eingerichteten Funknetzwerkes sollte die regelmäßige Prüfung der Konfiguration in Bezug auf Sicherheit und Stabilität in gewissen Abständen kontrolliert und ggf. angepasst werden. Da ein offenes Funknetz für den Betreiber ein rechtliches Risiko darstellt, sollte eine sichere Authentifizierung und Verschlüsslung des Datenverkehrs hohe Priorität besitzen.
Die Entscheidung für das im Titel genannte Verfahren fiel auf Grund der in einer Evaluation untersuchten Möglichkeit, Funk-Verbindungen für Benutzer mit individuellen Zugangsdaten zu ermöglichen, deren Zugriffe nicht nur verschlüsselt, sondern auch hinreichend protokolliert werden sollten. Diese Anforderungen lassen sich sehr gut mit der Funktion WPA2-Enterprise umsetzen. Da ich hier nicht die vollständige Funktionsweise des Authentifizierungsverfahrens 802.1X erläutern will, verweise ich für Interessierte an dieser Stelle auf den sehr guten Artikel von Stefan Krecher bei heise Netze: WLAN und LAN sichern mit IEEE 802.1X und Radius.
Sicherheit
Grundsätzlich wird bei 802.1X das Extensible Authentication Protocol (EAP) verwendet, welches im OSI-Modell auf Ebene 2 arbeitet und dabei lediglich Authentifizierungs-Anfragen und Antworten überträgt. Da diese Daten teilweise unverschlüsselt übertragen werden, gibt es verschiedene Varianten, die die Sicherheit von EAP erhöhen.
Im folgenden Beispiel beziehe ich mich auf den Einsatz des Protected EAP (EAP-MSCHAP-v2). Diese Methode ist relativ leicht zu konfigurieren und stellt ein Mittelmaß an Aufwand und Sicherheit dar. Wer absolute Sicherheit verlangt, muss sich zwangsläufig mit der Methode PEAP mit Zertifikaten (EAP-TLS)auseinandersetzen, der Aufwand für die Einrichtung ist allerdings sehr groß. Da sich bei meiner Umsetzung die WLAN-Endgeräte (sowie der DHCP-Server für die IP-Adressvergabe) in einem abgetrennten, durch eine Firewall geschützten, Netzwerkabschnitt befinden, ist die Methode EAP-MSCHAP-v2 für uns ausreichend sicher.
Voraussetzungen
Hardware
Um ein WLAN aufzubauen, benötigt man selbstverständlich die entsprechenden Hardwarekomponenten. Im einfachsten Fall – eine vorhandene Netzwerkinfrastruktur vorausgesetzt – genügt hierfür bereits ein einzelner Access Point, abhängig von der Abdeckung des zu versorgenden Bereichs. Das Gerät sollteWPA2 beherrschen, die Konfiguration sollte auf das verkabelte Netzwerk beschränkbar und durch eine Authentifizierung schützbar sein. Die Clientgeräte müssen natürlich ebenfalls den verwendeten Standard WPA2 unterstützen – dazu aber später mehr.
Windows Server: Softwarekomponenten
Ich war erstaunt, was mit Hilfe der im Windows Server integrierten Komponenten, ohne Zukauf bzw. Einsatz von weiteren Produkten, realisierbar ist. In folgenden Beispiel gehe ich von der "kleinsten" Umgebung aus, sowohl was die Betriebssystemversion als auch die Edition betrifft. Benötigt wird:
- eine Domäne mit mindestens Windows Server 2003, Standard Edition
- eine eingerichtete Microsoft Stammzertifizierungsstelle (Root Certificate Authority)
- einen Microsoft DHCP Server
- einen Microsoft Internet Authentication Server (IAS), der RADIUS Server
Es ist durchaus denk- und machbar, die drei letzteren Rollen auf dem Domänencontroller zu installieren, in größeren Umgebungen sollte man diese aber auf eigenen Servern installieren. Die Lösung ist auch unter Windows Server 2008 (R2) umsetzbar, lediglich der Name der Rolle des IAS hat sich in Network Policy Server (NPS) geändert. Selbiger bietet in Verbindung mit NAP (Network Access Protection) eine Fülle von neuen Funktionen, die allerdings nur bei reiner Nutzung von Windows Clientgeräten wirklich sinnvoll ist. In der Standard Edition von Windows Server werden vom IAS maximal 50 Clientgeräte und 2 Remote-RADIUS-Servergruppen unterstützt, was für die meisten, kleineren Umgebungen ausreichend sein sollte, mit der Enterprise Version ist diese Limitierung aufgehoben.
Einrichtung
Access Point
Abhängig vom Hersteller weicht die Konfiguration des Gerätes in der Menüführung ab. Unabhängig davon gibt es aber für die Umsetzung der Lösung folgende zu konfigurierende Werte:
- Netzwerkkonfiguration des Access Points: IP Adresse, DNS Server, NTP Server und Default Gateway
- SSID (Service Set Identifier): Bezeichner bzw. Name des Funknetzwerkes
(die Möglichkeit die SSID "unsichtbar" zu machen ist trotz oftmals gegenteiliger Behauptung weitgehend nutzlos: Artikel bei heise.de) - Funkkanal: abhängig von bereits existierenden Netzwerken sollte hier möglichst ein unbenutzter, freier Kanal genutzt werden, um Störquellen auszuschließen
- Sicherheitsmodus: hier ist WPA2-Enterprise auszuwählen (auch WPA2-802.1.X oder WPA2-1Xgenannt)
- RADIUS Server: IP Adresse oder DNS-Name des Internet Authentication Servers (IAS)
- RADIUS Server Port: im Standard 1812, bei Änderung auch im IAS einzustellen
- Verschlüsselung: sollte bei WPA2 automatisch auf AES eingestellt sein
- Shared Secret: Passwort für die verschlüsselte Kommunikation zwischen Access Point und IAS
Es existieren außerdem noch viele weitere Einstellmöglichkeiten, die sich aber fast ausschließlich auf die Qualität der Funkverbindungen beziehen.
Zertifikat durch interne Zertifizierungsstelle
Damit der IAS später eine sichere, verschlüsselte Verbindung zur Authentifizierung des WLAN Clients aufbauen kann, benötigt dieser beim Verfahren Geschütztes EAP (PEAP) ein Computerzertifikat (Zweck: Serverauthentfizierung). Ist noch keine interne, private Zertifizierungsstelle vorhanden, muss diese zuvor installiert werden (entweder auf einem Domänencontroller oder Domänenmitgliedserver, über Windows-Komponenten).
Auf dem späteren IAS-Server muss das Computerzertifikat nun beantragt werden. Der einfachste Weg (wenn nur ein Zertifikat benötigt wird), stellt die Anforderung eines neuen Zertifikates auf dem IAS Server im MMC Zertifikate (Snap-In hinzufügen, Hinzufügen, Zertifikate für lokalen Computer) dar.
Wesentlich eleganter – da hier bei Ablauf des Zertifikates selbiges automatisch erneuert wird – ist die Ausstellung von Zertifikaten über Gruppenrichtlinien. Dafür sind innerhalb der Gruppenrichtlinie die folgenden Einstellungen zu treffen:
Unter Computerkonfiguration, Windows-Einstellungen, Sicherheitseinstellungen, Richtlinien öffentlicher Schlüssel kann die Einstellung der automatischen Zertifikatsregistrierung vorgenommen werden. In der Einstellung für die automatische Anforderung des Zertifikats muss nun noch eine neue Vorlage für den Typ Computer hinzugefügt werden:
Danach muss noch das Zertifikat der Zertifizierungsstelle unter dem Punkt Vertrauenswürdige Stammzertifizierungsstellen importiert werden, damit alle von ihr ausgestellten Zertifikate auf den von der GPO betroffenen Computern als vertrauenswürdig behandelt werden:
Wird die Gruppenrichtlinie nun auf den IAS Server angewendet, erhält dieser automatisch ein Computerzertifikat, welches bei Ablauf auch erneuert wird. Damit sind Voraussetzungen für den IAS Server geschaffen, eine verschlüsselte Verbindung für die Authentifizierungsmethode PEAP herzustellen.
Internet Authentication Server (IAS) – RADIUS Server
Wird der IAS auf einem eigenständigen Server installiert, so muss dieser Mitglied der Domäne sein (Grund: Computerzertifikat und lokale Authentifizierung – siehe unten). Unter Windows Server 2003 wird der Internetauthentifizierungsdienst als Netzwerkdienst der Windows-Komponenten installiert:
Seit Windows Server 2008 (R2) heißt diese Option nun Network Policy Server (Netzwerk-Richtlinien-Server) und lässt sich als Rolle nachträglich hinzufügen – der Funktionsumfang ist zwar wesentlich erweitert wurden, es handelt sich aber auch hier um einen RADIUS Server zur Authentifizierung und Kontoführung.
Nach der Installation kann der IAS über die MMC Internetauthentifizierungsdienst administriert werden.
In den Einstellungen des IAS können außer der Beschreibung des Servers und der im Ereignisprotokoll einzutragenden Authentifizierungsanforderungen auch die Ports für Authentifizierung und Kontoführung geändert werden:
Hier ist der gleiche Port (wie im Access Point definiert) zu verwenden (siehe RADIUS Server Port). Anschließend kann im Bereich RADIUS-Clients ein neuer Eintrag erstellt werden:
Neben dem Anzeige-Namen wird hier die IP-Adresse (bzw. DNS-Name) des Access Points eingetragen. Für die sichere, verschlüsselte Kommunikation zwischen RADIUS-Client (Access Point) und IAS muss das Shared Secret verwendet werden, welches ebenfalls zuvor im Access Point hinterlegt wurde.
Im nächsten Schritt kann eine neue Verbindungsanforderungsrichtlinie erstellt werden. Diese Richtlinie definiert, ob der IAS eine Authentifizierungs-Anforderung (Request) lokal (in der Domäne in der sich der IAS befindet) authentifiziert oder ob er als Proxy diese Anfrage an einen Remote-RADIUS-Server (bspw. an einen IAS in einer anderen Domäne) weiterleiten soll. In meinem Beispiel soll der IAS lokal in der selben Domäne authentifizieren, weswegen der IAS im Active Directory zunächst registriert wird (Server muss Domänenmitglied sein):
Durch diese Einstellung erhält der IAS das Recht, die RAS-Eigenschaften der Benutzerkonten innerhalb der Domäne zu lesen. Befindet sich der IAS in einer anderen Domäne als in der, die die Benutzerkonten für die Authentifizierung enthält, so kann die Registrierung über den folgenden Befehl auf der Kommandozeile umgesetzt werden (Beispiel: Der IAS befindet sich in der Root-Domäne der Gesamtstruktur, die Benutzerkonten in einer Sub-Domäne.):
netsh ras add registeredserver Domäne IASServer
Anschließend wird nun eine neue Verbindungsanforderungsrichtlinie erstellt:
Wie im obigen Beispiel erkennbar, kann durch die Konfiguration der Bedingungen (hier Client-IP und Name des Access Points) festgelegt werden, welche Anforderungen durch diese Richtlinie verarbeitet werden sollen. Im Profil dieser Richtlinie wird wiederum eingestellt, wo die Anforderungen authentifiziert werden sollen – im meinem Beispiel lokal innerhalb der Domäne:
Nun muss im IAS noch definiert werden, wer sich wann und wie einwählen darf.
Dies geschieht über die Definition einer neuen RAS-Richtlinie:
Im obigen Beispiel wird die Einwahl nur für Mitglieder einer bestimmte Sicherheitsgruppe erlaubt, die sich über IEEE 802.11 (also WLAN) einwählen und authentifizieren sollen. Die Sicherheitsgruppe muss selbstverständlich innerhalb der Domäne existieren. Deren Mitglieder (Benutzerkonten) werden später auf den Clientgeräten für die Authentifizierung verwendet.
Wichtig: Diese Richtlinie nur beachtet, wenn auch die Bedingungen der Verbindungsanforderungsrichtlinie zutreffen.
Im Profil der RAS-Richtlinie können nun weitere granulare Einstellungen für den Zugriff der WLAN Teilnehmer getroffen werden:
Ist im Netzwerk des Access Points ein DHCP-Server vorhanden, kann durch die obige Einstellung erlaubt werden, dass dieser dem WLAN-Client eine IP-Adresse zuweist. Im Reiter Authentifizierung kann nun (auf Basis des zuvor erstellten Computerzertifikats) die Einstellung für das Verfahren PEAP (Protected EAP) getroffen werden:
In den Einwähleinschränkungen der RAS-Richtlinie kann der Zugriff für die W-LAN Teilnehmer weiter eingegrenzt und gesichert werden. Über den NAS-Porttyp (Network Access Server, RADIUS Attribut 61) wird der Zugriff auf das Medium WLAN beschränkt :
Außerdem lässt sich in diesem Reiter auch die Uhrzeit für den Zugriff einstellen.
Achtung: Doch aufgepasst, Microsoft hat (bei der Deutschen Version) einen Fehler im Fenster für die Auswahl der Einwählzeiten "versteckt". Möchte man beispielsweise den Zugriff nur an Wochentagen (Montag bis Freitag) in den Zeiten von 7:00 Uhr bis 22:00 Uhr zulassen und wählt diese Felder aus, so werden die Tage als Sonntag bis Donnerstag gespeichert. Um die richtigen Wochentage einzustellen, sind folgende Felder (Dienstag bis Samstag) zu markieren:
Nach Abschluss dieser Einstellungen ist der IAS Server bereit, W-LAN Clientbenutzer über 802.1X mit PEAP zu authentifizieren.
Konfiguration der Clientgeräte
Abschließend fehlt noch die Konfiguration der entsprechenden Clientgeräte, die abhängig von dem verwendeten Betriebssystem entsprechend durchgeführt werden muss. Für das oben beschriebene Authentifizierungs- und Verschlüsselungsverfahren konnte ich in meinen Tests mit den folgenden Clients (die allesamt WPA2 beherrschen) erfolgreich eine Verbindung herstellen:
- HTC Desire (Android 2.2, Android 1.6 unterstützt noch kein WPA2-Enterprise)
- Apple iPhone 3G und 4G
- Apple iPad
- Ubuntu (Desktop Edition 10.10)
- Windows XP (ab Service Pack 2)
- Windows 7
Da die Einstellung für Windows 7 am aufwändigsten war, möchte ich die dort notwendigen Einstellungen hier noch dokumentieren. Es ist sinnvoll, die neue Drahtlosnetzwerk-Konfiguration manuell durchzuführen, da der Wizard von Windows 7 sonst zu viele automatische Einstellungen vornimmt:
In den Eigenschaften dieser Verbindung sind im Reiter Sicherheit die folgenden Einstellungen vorzunehmen:
Die folgenden Einstellungen für die Authentifizierungsmethode sind zu wählen:
Besitzt der Client das Zertifikat für die interne Stammzertifizierungsstelle noch nicht in seinem Speicher für die vertrauenswürdigen Stammzertifizierungsstellen, so muss dieses zuvor importiert werden. Im Anschluss ist die Authentifizierungsmethode EAP-MSCHAP-v2 auszuwählen und zu konfigurieren:
Der Haken, welcher hier standardmäßig gesetzt ist, muss dann zwingend entfernt werden, wenn die lokale Anmeldung am Clientcomputer nicht dem Benutzerkonto der Sicherheitsgruppe in der Domäne entspricht, die in der RAS-Richtlinie auf dem IAS Server hinterlegt ist. Andernfalls schlägt die Authentifizierung fehl.
In den erweiterten Einstellungen innerhalb der Sicherheitskonfiguration sollte man noch als Authentifizierungsmodus die Benutzerauthentifizierung auswählen, da Windows sonst ebenfalls versucht, das Computerkonto zu verwenden:
Wird das Drahtlosnetzwerk im Anschluss gestartet, so wird man zur Eingabe seiner Authentifizierungsdaten (Benutzername und Kennwort) aufgefordert, welche in den Formen (Username@FQDN oder NETBIOS-Domain-Name\Username) eingeben kann.
Selbstverständlich kann die WLAN Konfiguration auch über Gruppenrichtlinien auf Windows-Clients verteilt werden (Computerkonfiguration, Windows-Einstellungen, Sicherheitseinstellungen, Drahtlosnetzwerkrichtlinien (802.1X)). Mit dieser Gruppenrichtlinie könnte bspw. auch das Zertifikat der Stammzertifizierungsstelle automatisch auf die Clients verteilt werden. In meinem Fall handelt es vorwiegend um Smartphones und einige wenige Notebooks, weswegen ich hier auf eine eigene Anleitung verzichte.
Ablauf der Verbindungsherstellung bei 802.1X
Der Verbindungsaufbau einer authentifizierten, verschlüsselten WLAN-Verbindung ist auf Grund der beschriebenen, vielschichtigen Konfiguration relativ komplex. Ich möchte deshalb an dieser Stelle auf den guten TechNet-Artikel von Microsoft verweisen, in dem der Ablauf beschrieben wird: Grundlegendes zur 802.1X-Authentifizierung für drahtlose Netzwerke.
Protokollierung der Verbindungen
Schon aus Gründen des Nachweises als auch zu Analysezwecken bei eventuell auftauchenden Problemen empfiehlt es sich, die Verbindungs- und Authentifizierungsversuche zu protokollieren. Der IAS Server schreibt im Standard diese Informationen automatisch in sein eigenes Protokoll (Konfiguration unter RAS-Protokollierung), wenn konfiguriert (Eigenschaften des IAS) aber auch im Ereignisprotokoll des IAS Servers:
Das Standard-Protokoll ist umständlich auszuwerten, zumal es keine Beschreibungen sondern nur Werte enthält. Gerade zur Fehleranalyse ist es sinnvoll, das Ereignisprotokoll zu verwenden. Diese Einträge haben das folgende Aussehen (Ausschnitt):
Bei einer ungültigen Authentifizierung hat der Administrator aber auch hier schlechte Karten, da als Ursache für einen Fehler lediglich Fehlercodes protokolliert werden. Erst mit der Tabelle des folgenden TechNet-Artikels von Microsoft Analysieren von Protokolldateien im IAS-Format kann man den Fehler eingrenzen und mit der Behebung beginnen.
Zusätzlich bietet der IAS Server die Möglichkeit alle Informationen über eine ODBC-Verbindung in einer Microsoft SQL Datenbank abzulegen. Dafür muss die entsprechende Datenbank existieren und die Verbindungsdaten konfiguriert werden. Allerdings legt der IAS keinerlei Datenstrukturen automatisch innerhalb der Datenbank an, weswegen alle Versuche einen Eintrag zu schreiben fehlschlagen und alle Verbindungen abgelehnt werden. Microsoft bietet aber zum Download ein Dokument an welches nicht nur das Verfahren detailliert beschreibt, sondern auch alle SQL Befehle für die Erstellung der notwendigen Datenbankstruktur enthält. Danach funktionierte bei mir die Protokollierung einwandfrei. Vorteil dieser Lösung ist, dass man zu Auswertungszwecken relativ schnell Berichte (bspw. über Report-Services des SQL Server) erzeugen kann.
Fazit
Nachdem ich den Artikel noch einmal überflogen habe, muss ich feststellen, dass er ganz schön umfangreich ist – und das liegt klar an der Komplexität des Themas. Allerdings zeigt der Artikel auch, dass mit beherrschbarem Aufwand eine relativ sichere Möglichkeit geschaffen werden kann, um WLAN-Endgeräten den Zugriff auf ein internes Netzwerk zu ermöglichen. Mittlerweile sind mit den Funktionen von Windows Server 2008 (R2) dank Network Protection Server und Network Access Control noch wesentlich mehr Einstellungen möglich, das grundsätzliche Verfahren bleibt jedoch das Gleiche.
Back to the top
