WLAN mit WPA(2)-Enterprise absichern

Hier soll eine Zusammenfassung der, im Verlauf meiner Odyssee bezüglich eines sicheren WLAN-Zugangs mittels WPA(2)-Enterprise und RADIUS-Server, gesammelten Erfahrungen und Erkenntnisse entstehen.

(Erst mal muss ich aber wohl den Umgang mit diesem Wiki lernen. ;-) )

Einleitung

Bedingt durch mangelnde Lust weiterhin ein dezentrales PSK-Management auf allen AP's, Notebooks, Netbooks, Tablets, Smartphones, etc. durchzuführen habe ich mich mal mit den Themen RADIUS (Remote Authentication Dial-In User Service) und IEEE 802.1X auseinandergesetzt. (Dank Wikipedia weis ich nun auch das bei der Schreibweise laut IEEE ein Großbuchstabe zu verwenden ist, da IEEE 802.1X ein allein stehender Standard und keine Ergänzung eines bestehenden Standards ist.)

Während die technischen Komponenten nach kurzer (hahaha) Zeit in den Griff zu bekommen sind, muss ich mir aber nochmal ein paar Grundsatzüberlegungen zum Sinn des Ganzen machen. In dem gewählten Ansatz authentisiert sich ein 'User' mittels 'identity' (RADIUS-Username) und Zertifikat via EAP-TLS gegenüber einem RADIUS-Server. Bei positiver Authentisierung (gültiges Zertifikat, bekannter User, gültige Login-Time, etc.) erfolgt eine Assoziation zwischen dem WLAN-Adapter des Clients und dem AP.

(Frage: Ist zum Zeitpunkt der EAPOL Kommunikation zwischen Supplicant und Authentication-Server der WLAN-Adapter schon mit dem AP assoziiert? )

Somit steht, nach einer erfolgreichen Authentisierung, auf einem Client mit Multi-User-OS, allen User die Netzwerkverbindung zur Verfügung. Eigentlich kann man deshalb nicht von einer User-Authentisierung sprechen, sondern muss dies als Authentisierung des Client-PC sehen. (Was eine spätere Authentisierung des Users über diese Verbindung natürlich nicht ausschließt.)

In wie weit und mit welchem Aufwand sich diese Client-Authentisierung später benutzerspezifisch ändern lässt, um z.B. einem Administrator ausserhalb der regulären Zeiten ein Wartungsfenster zu eröffnen, ist hierbei eines der Themen welche noch zu klären wären.

Um im Rahmen dieser Dokumentation die Verwendung einzelner Passphrasen zu verdeutlichen, habe ich mich entschieden 'sprechende' Passwörter zu verwenden. Für eine produktive Umgebung sind diese selbstverständlich entsprechend abzuändern!!!

Grundsätzliches

Die Authentisierung mittels IEEE 802.1X involviert drei Komponenten.

• Den Supplicant – als Antragsteller (User oder Client), welcher sich authentisieren möchte.
• Den Authenticator - welcher den Zugang zur Verfügung stellt und den Antrag des Supplicanten entgegen nimmt.
• Den Authentication Server - welcher den Authentifizierungsdienst zur Verfügung stellt.

Im WLAN wären dies typischerweise:

• der WLAN-Client als Supplicant welcher sich authentisieren möchte.
• der AP (Access-Point) als Authenticator welcher die Anmeldeinformationen des Supplicanten vom Authentisierungsdienst überprüfen lässt, entsprechend den Zugang ermöglicht und bei Bedarf eine Reauthentisierung bzw. das Abschalten des Zuganges durchführt.
• ein RADIUS-Server als Authentication Server welcher dem Authenticator die Richtigkeit (oder auch nicht) der Anmeldeinformationen bestätigt und weitere Verbindungsinformationen (z.B. VLAN) mitteilen kann.

Das Szenario

Mit meinem kleinen heterogenen Netzwerk verbinden sich diverse eigene Clients als auch Gäste mit unterschiedlicher Hardware (Notebooks, Netbooks, Tablets, Smartphones, Spielekonsolen, etc.) und verschiedensten Betriebssystemen via WLAN. Ein ganz normaler Familienhaushalt eben. ;-) Der Wunsch, den zukünftigen Aufwand zur Verwaltung des Netzzugangs zu minimieren und nicht bei allen Änderungen den PSK auf allen Clients ändern zu müssen, veranlasst mich die Verwendung von IEEE 802.1X im Folgenden zu untersuchen.

Zertifikate

Für Einsteiger sicher der komplexeste Teil des ganzen Themas. EAP-TLS nutzt für die gegenseitige Authentisierung von Authentication Server und Supplicant digitale Zertifikate. Ein digitales Zertifikat ist durch eine digitale Signatur der Zertifizierungsstelle (Certificate Authority, CA) geschützt, welche mit dem Zertifikat der Zertifizierungsstelle überprüft werden kann. Die enthaltenen Informationen eines jeden digitalen Zertifikats sind mit einem öffentlichen Schlüssel (public key) verknüpft, welcher einem privaten Schlüssel (private key) zugeordnet ist. Der private Schlüssel wiederum kann zusätzlich mit einer Passphrase geschützt (verschlüsselt) werden. Dieser private Schlüssel sollte sich ausschließlich in der Kontrolle / im Besitz des Zertifikatsinhaber befinden, sowie die Passphrase nur ihm bekannt sein.

Zu einem Zertifikat gehören also

• das Zertifikat (public key, als Datei)
• der Schlüssel (private key, als Datei)
• die Passphrase (das 'Passwort' für den Schlüssel)
• das Zertifikat der ausstellenden oder einer übergeordneten CA (public key, als Datei)

Das Zertifikat einer CA kann wiederum von einer 'übergeordneten' CA signiert sein. Somit lässt sich eine Zertifizierungskette aufbauen, wobei wir zumindest einer der CA's 'blind' vertrauen müssen um dem eigentlichen Zertifikat zu vertrauen.

Sollte jemand die Kontrolle über ein zertifiziertes CA-Zertifikat haben, kennt er sicherlich den geschilderten Zusammenhang und hat, mit großer Wahrscheinlichkeit, diesen Text bereits übersprungen. Für alle Anderen bietet sich die Möglichkeit sich kostenpflichtig bei einer CA zertifizieren zu lassen oder sich selbst ein CA-Zertifikat auszustellen und dies selbst zu signieren. (Wenn wir uns nicht selbst vertrauen, wem dann?)

Zum Beantragen, Erzeugen und Verwalten von Zertifikaten kommt in der Regel OpenSSL zum Einsatz. Da OpenSSL unter Debian bereits als Abhängigkeit von FreeRADIUS installiert wird, gibt es eigentlich keinen Grund es nicht zu verwenden. ;-)

Die Verwaltung der Zertifikate erfolgt mehr oder weniger in einer Verzeichnisstruktur. Es ist deshalb unbedingt notwendig sich Gedanken über die Zugriffsrechte und Sicherheit der Zertifikat- und Schlüsseldateien zu machen. Während der Verbleib der CA-Verzeichnisstrucktur und der darin enthaltenen Dateien auf dem RADIUS-Server nicht zwingend notwendig ist, macht eine Aufbewahrung auf einem Memorystick, der selbst nicht gesichert aufbewahrt wird, auch nicht wirklich Sinn.

Sowohl FreeRADIUS als auch OpenSSL stellen Scripts zur Verfügung, welche die Erstellung einer CA und weiterer Zertifikate unterstützen.

FreeRADIUS-Script

Das FreeRADIUS Script bootstrap im Verzeichnis /usr/share/doc/freeradius/examples/certs/ erstellt ein komplettes Set von Zertifikaten in genau diesem Verzeichnis. Die Vorgaben hierfür holt sich das Script aus den Dateien ca.cnf, server.cnf und client.cnf. Sollen die Zertifikate in einem anderen Verzeichnis erstellt werden, können alle Dateien aus /usr/share/doc/freeradius/examples/ in das gewünschte Verzeichnis kopiert und bootstrap dort ausgeführt werden. Ist auf dem Host das Paket make installiert, wird dies mit 'make all' für die Erstellung der Zertifikate aufgerufen. Es besteht dann allerdings auch die Möglichkeit durch Aufruf von 'make ca' , 'make server' oder 'make client' gezielt einzelne Zertifikate zu erstellen.

OpenSSL-Script

Auch das OpenSSL Script CA.sh im Verzeichnis /usr/lib/ssl/misc/ ermöglich das Erstellen und signieren von Zertifikaten. Eine kurze Übersicht über die Benutzung gibt './CA.sh -h' . Jedoch sollten hier zuerst die Zuweisungen des Verzeichnisses für die CA, im Script und in /etc/ssl/openssl.cnf entsprechend den eigenen Vorstellungen abgeändert werden.

in /usr/lib/ssl/misc/CA.sh
  if [ -z "$CATOP" ] ; then CATOP=/pfad/verzeichnis ; fi

in /etc/ssl/openssl.cnf
  dir = /pfad/verzeichnis

per pedes

Natürlich kann OpenSSL auch direkt genutzt werden um die Benötigten Zertifikate zu erstellen. Um die Eingabe der für die Zertifikate benötigten Informationen zu vereinfachen können in /etc/ssl/openssl.cnf entsprechende Vorgaben (default) gesetzt werden. Folgende Einträge sind hierfür abzuändern.

countryName_default            = DE
stateOrProvinceName_default    = Bundesland
0.organizationName_default     = Firma
organizationalUnitName_default = Abteilung

Zusätzlich können noch folgende Vorgaben an geeigneter Stelle zur Konfigurationsdatei /etc/ssl/openssl.cnf hinzugefügt werden.

localityName_default      = Stadt
emailAddress_default      = name@domain.tld
challengePassword_default = ChallengePW
unstructuredName_default  = OptCompName

Alternativ können die benötigten Informationen bei dem Aufruf von openssl auch als Parameter übergeben werden.

-subj /C=DE/ST=Bundesland/L=Stadt/O=Firma/OU=Abteilung/CN=hostname.domain.tld/emailAddress=name@domain.tld

Im nächsten Schritt wird als User 'root' eine geeignete Verzeichnisstruktur erstellt.

sudo su - 
# In einem Script sollte man hier erst einmal prüfen ob das Verzeichnis schon existiert und dann entsprechend verfahren. 
mkdir myCA 
mkdir -p myCA/certs
mkdir -p myCA/crl
mkdir -p myCA/newcerts
mkdir -p myCA/private
mkdir -p myCA/requests
cd myCA 
openssl rand -out .rnd 5120
openssl rand -out private/.rand 5120
openssl dhparam -check -text -5 -out dh 1024
touch index.txt

Weiterhin wird die Datei xpextensions mit folgendem Inhalt im Verzeichnis der CA ('myCA') benötigt.

[xpclient_ext]
extendedKeyUsage=1.3.6.1.5.5.7.3.2

[xpserver_ext]
extendedKeyUsage=1.3.6.1.5.5.7.3.1

Das CA-Zertifikat

Als nächstes ist das Zertifikat für die eigene CA zu erstellen Hierfür kann nun mittels openssl das Zertifikat der CA 'beantragt' werden.

openssl req -batch -newkey rsa:2048 \
        -subj /C=DE/ST=Bundesland/L=Stadt/O=Firma/OU=Abteilung/CN=EigeneCA.domain.tld/emailAddress=name@domain.tld
        -out requests/ca.req.pem \
        -passout pass:ca_key_passphrase \
        -keyout private/cakey.pem

Da wir uns auch selbst vertauen, kann der Antrag auch gleich 'genehmigt' werden.

openssl ca -batch -create_serial -days 1461 \
        -in requests/ca.req.pem \
        -passin pass:ca_key_passphrase \
        -keyfile private/cakey.pem \
        -selfsign -extensions v3_ca \
        -out certs/cacert.pem

Das 'Server'-Zertifikat

Als nächstes kann das Zertifikat für den RADIUS-Server erstellt werden. Eigentlich würde hier ein 'normales' Zertifikat genügen, würde Windows bei den Zertifikaten keinen Unterschied zwischen einem NAS (Network Access Server) und einem Client (Host der sich an einem NAS anmeldet) machen. (Siehe xpextensions) Ein Windows-Client, welcher sich mit einem NAS verbindet, scheint diese Server-Extensions, unabhängig von dem tatsächlich auf dem NAS installierten OS, zu erwarten.

Im ersten Schritt wird das Zertifikat beantragt.

openssl req -batch -newkey rsa:2048 \
        -subj /C=DE/ST=Bundesland/L=Stadt/O=Firma/OU=Abteilung/CN=server.domain.tld/emailAddress=name@domain.tld
        -out requests/new.server.req.pem \
        -passout pass:server_cert_key_passphrase \
        -keyout private/new.server.key.pem

Im zweiten Schritt wird das Zertifikat von der CA 'genehmigt/beglaubigt'.

openssl ca -batch -days 730 \
        -in requests/new.server.req.pem \
        -cert certs/cacert.pem \
        -passin pass:ca_key_passphrase \
        -keyfile private/cakey.pem \
        -extfile xpextensions \
        -extensions xpserver_ext \
        -out certs/new.server.cert.pem

Es macht durchaus Sinn die in dieser Dokumentation verwendeten Beispiele auf die eigene Umgebung anzupassen. Hierzu gehört insbesondere die Änderung des jeweiligen Common Name (CN=...). OpenSSL 'merkt' sich die vergebenen Zertifikate und weigert sich in der Standardeinstellung mehrere Zertifikate für den gleichen Common Name zu vergeben. Auch die Dateinamen der Zertifikate sollten entsprechend eindeutig sein. Eine gute Vorgehensweise ist es die Dateinamen und den CN dem Hostname bzw. dem FQDN (Fully Qualified Domain Name) des Servers/Clients anzupassen Bsp.:

CN=radius01.home.local 
Dateiname für Zertifikat: radius01.crt.pem
                    Key : radius01.key.pem

Das 'Client'-Zertifikat

Scheinbar hat das Einbinden bzw. das nicht Einbinden der 'Windows Extensions' keinen Einfluss auf den Verbindungsaufbau eines none-Windows-Client mit einem none-Windows-NAS. Da sie aber anscheinend auch nicht stören, erleichtert es den Verwaltungsaufwand erheblich wenn die Extensions grundsätzlich eingebunden werden. Auch Client-Zertifikate werden im ersten Schritt 'beantragt' ...

openssl req -batch -newkey rsa:2048 \
        -subj /C=DE/ST=Bundesland/L=Stadt/O=Firma/OU=Abteilung/CN=client.domain.tld/emailAddress=name@domain.tld
        -out requests/new.client.req.pem \
        -passout pass:client_cert_key_passphrase \
        -keyout private/new.client.key.pem

... und im zweiten Schritt 'genehmigt/beglaubigt'.

openssl ca -batch -days 730 \
        -in requests/new.client.req.pem \
        -cert certs/cacert.pem \
        -passin pass:ca_key_passphrase \
        -keyfile private/cakey.pem \
        -extfile xpextensions \
        -extensions xpclient_ext \
        -out certs/new.client.cert.pem

Es macht durchaus Sinn die in dieser Dokumentation verwendeten Beispiele auf die eigene Umgebung anzupassen. Hierzu gehört insbesondere die Änderung des jeweiligen Common Name (CN=...). OpenSSL 'merkt' sich die vergebenen Zertifikate und weigert sich in der Standardeinstellung mehrere Zertifikate für den gleichen Common Name zu vergeben. Auch die Dateinamen der Zertifikate sollten entsprechend eindeutig sein. Eine gute Vorgehensweise ist es die Dateinamen und den CN dem Hostname bzw. dem FQDN (Fully Qualified Domain Name) des Servers/Clients anzupassen Bsp.:

CN=schlepptop01.home.local 
Dateiname für Zertifikat: schlepptop01.crt.pem
                    Key : schlepptop01.key.pem

Der Authenticator

Als Authenticator kommen mehrere Netgear WG602 in der Version v3 und v4 zum Einsatz. (Einem geschenkten Barsch ...) Die original Firmware der AP's wurde, aufgrund mangelnder IEEE 802.1X Funktionalität, durch eine Firmware von dd-wrt ersetzt. Profifunktionalität auf einem 08/15 Device. Ein Hammer was die Entwickler in die Firmware gezaubert haben!!

Neben der üblichen Konfiguration (IP, DHCP, SSID, etc.) auf die hier nicht im Detail eingegangen werden, wurde unter Wireless->Wireless Security folgende Einstellungen gewählt:

• Security Mode : WPA Enterprise, WPA2 Enterprise oder WPA2 Enterprise Mixed
• WPA Algorithms : TKIP, AES oder TKIP+AES
• IP-Adresse des Radius-Servers : die IP-Adresse des Hosts auf dem der radiusd Deamon läuft
• Port des Radius-Dienstes auf dem Radius Server : 1812 (default)
• Radius Shared Secret : radius_shared_secret
• Key renewal interval : 300

Zum Einstieg fiel die Wahl auf WPA Enterprise mit TKIP, da ich hier erst einmal die wenigsten Probleme mit den Clients zu erwarten sind. Später sollte dies, wenn mit allen Clients möglich, auf WPA2 Enterprise und AES hochgeschraubt werden.

Der EAP Datenverkehr zwischen Supplicant (Client-PC) und Authenticator (AP) wird in EAPOL Frames eingepackt und zwischen Authenticator und Authentication Server mittels des RADIUS oder DIAMETER-Protokols übertragen. Das Radius Shared Secret wird zur Verschlüsselung der Datenübertragung zwischen Authenticator und Authentication Server (RADIUS) verwendet und muss dementsprechend beiden Seiten bekannt sein.

Der Authentication Server

Als Authentication Server kommt eine rudimentäre (ohne GUI) Debian GNU/Linux 6.0 (Squeeze) Installation mit FreeRADIUS 2.1.10 zur Verwendung. Die Installation des FreeRADIUS erfolgt unspektakulär mittels

:# apt-get install freeradius 

und sollte alle benötigten Abhängigkeiten (z.B. OpenSSL) auflösen.

Nach der Installation ist zu beachten das Debian, im Rahmen der Installation, den installierten Dienste in die Startup-Routine des Systems (z.b. SystemV Init-Scripte) einbindet und den Dienst auch sofort startet. Deshalb sollte der RADIUS-Server für den Verlaufe der Konfiguration und das Testen gestoppt werden.

~# sudo /etc/init.d/freeradius stop 

Im Verlaufe der Konfiguration und dem anschließenden Testen kann der Dienst, mit nachfolgendem Befehl auf der Kommandozeile, im Debugmode gestartet werden.

~# sudo freeradius -X 

Nach der Konfiguration und dem erfolgreichen Testen derselben kann der Dienst wieder mit folgendem Befehl gestartet werden.

~# sudo /etc/init.d/freeradius start 

Hinweis: Sollte sich später der Supplicant (Client) nicht mit dem WLAN verbinden sollte überprüft werden ob der FreeRADIUS Dienst auch wirklich aktiviert ist !!!

Die Installation legt die die Konfigurationsdateien in folgendem Verzeichnis ab:

/etc/freeradius/ 

/etc/freeradius/radiusd.conf

In der Konfigurationsdatei des radiusd Daemon sollte zuerst überprüft werden dass 'freerad' als User und als Gruppe eingetragen ist. Bei Bedarf die folgenden Einträge anpassen:

user = freerad 
group = freerad 

/etc/freeradius/proxy.conf

Unter home_server localhost{ wird der Eintrag für das Radius Shared Secret angepasst.

secret = radius_shared_secret 

/etc/freeradius/clients.conf

In der clients.conf werden die Informationen betreffend der Authenticator, welche für den RADIUS-Server Clients darstellen, konfiguriert. Als Erstes ist im Abschnitt für localhost der Eintrag 'secret' mit dem Radius Shared Secret anzupassen. Dies ermöglicht eine Kommunikation zwischen den in freeradius-utils mitgelieferten und auf dem lokalen Host installierten Utilities und dem RADIUS-Server. Der folgende Abschnitt für localhost ist nur zur Übersicht gedacht.

Der Abschnitt für localhost sollte schon existieren. Also hier nur den Eintrag 'secret' anpassen!!!

client localhost { 
        ipaddr = 127.0.0.1 
        secret = radius_shared_secret 
        require_message_authenticator = no 
        nastype = other 
} 

Des weiteren ist auch für jeden Authenticator ein entsprechender Abschnitt zu erstellen.

client AP_HOSTNAME {                   # z.B. dd-wrt unter Setup->Basic Setup->Optional Settings->Router Name eingetragene Name 
        ipaddr = xxx.xxx.xxx.xxx       # IP-Adresse des Authenticators (Access-Point) 
        secret = radius_shared_secret 
        require_message_authenticator = no 
        nastype = other 
} 

/etc/freeradius/users

Wenn der RADIUS-Server, wie in diesem Beispiel, ohne Anbindung an eine Datenbank (z.B. LDAP) aufgesetzt ist, werden in der Datei /etc/freeradius/users alle Konfigurationen zur Authentisierung von Benutzer verwaltet. Der Aufbau eines Eintrages beginnt mit dem username am Anfang einer Zeile, gefolgt von ein oder mehreren check items. Wenn mehrere check items angegeben werden, sind diese mit einem Komma zu trennen. Nachfolgende Zeilen, welche mit einem 'tab' beginnen, können ein oder mehrere reply items enthalten. Werden mehrere reply items angegeben sind diese, auch bei einer Verteilung über mehrere Zeilen, mit Kommas zu trennen.

username   name = wert[, name = wert][, name = wert][, \ ] 
           [name = wert][, name = wert]                    # zählt durch Zeilenumbruch mit '\' noch zur vorhergehenden Zeile 
<tab>      name = wert[, name = wert], 
<tab>      name = wert[, name = wert]                      # Abschließende Zeile mit reply items ohne abschließendes Komma!

In dem hier vorgestellten Ansatz ist jedoch kein Benutzer sondern ein Client-PC der Supplicant. (Treffender wäre also ein Dateiname 'supplicants'.) Trotzdem nutzen wir die Datei und tragen einfach den FQDN (Fully Qualified Domain Name) des Clients als username ein. (z.B. schlepptop01.home.local)

schlepptop01.home.local   Cleartext-Password := "\!none\!" 

INFO: Das 'Cleartext-Password' ist hier erstmal ohne Funktion 
INFO: Die Angabe verhindert aber eine Fehlermeldung bezüglich eines fehlenden Passwortes beim debugen. 

Später wird dann für jeden Client, der sich am WLAN anmelden möchte/darf, ein entsprechender Eintrag benötigt.

/etc/freeradius/eap.conf

In der eap.conf gilt es als erstes im Abschnitt 'eap {' den Eintrag 'default_eap_type = md5' abzuändern.

default_eap_type = tls 

Als nächstes sollten im Abschnitt 'tls {' folgende Einträge angepasst werden.

private_key_password = radius1_pass_phrase 
private_key_file = ${certdir}/radius01.key.pem 
certificate_file = ${certdir}/radius01.cert.pem 
CA_file = ${cadir}/myCA.cert.pem 

Wie zu sehen ist werden hier die Pfade und Dateinamen der für TLS benötigten Zertifikat.- und Schlüsseldateien eingetragen. Um dem Server die Nutzung seines eigenen Zertifikates zu ermöglichen, sollte natürlich auch die bei der Erstellung des Schlüssels benutzte Passphrase eingetragen werden.

Installation der Zertifikate

Mit den Informationen aus radius.conf

raddbdir = /etc/freeradius 
confdir = ${raddbdir} 

und eap.conf

certdir = ${confdir}/certs 
cadir = ${confdir}/certs 

ist nun klar das der RADIUS-Server die Zertifikate und Schlüssel im Verzeichnis /etc/freeradius/certs erwartet. Das Erzeugen der benötigten Zertifikate und Schlüssel wird beispielhaft im Kapitel 'Zertifikate' erklärt. Die entsprechenden Dateien für das CA-Zertifikat (z.B. cacert.pem), das Server-Zertifikat (z.B. radius01.crt.pem) und den zum Server-Zertifikat zugehörigen Key (z.B. radius01.key.pem) Dateien müssen in das von FreeRADIUS vorgesehene Verzeichnis verbracht werden. Um zumindest einen gewisse Sicherheit zu gewährleisten, sollten die Benutzer und Recht der Dateien entsprechend angepasst werden. Zertifikate haben einen 'public' Status und sollten also für alle lesbar sein. Schlüsseldateien (Keys) dagegen haben einen 'private' Status und sollten also nur für berechtigte Personen und Dienste lesbar sein. Es empfiehlt sich also folgende Einstellung:

chown root:freerad cacert.pem radius01.crt.pem radius01.key.pem
chmod 444 cacert.pem radius01.crt.pem
chmod 440 radius01.key.pem

ls -l
-r--r--r-- 1 root freerad 4828 Jul 20 16:41 cacert.pem
-r--r--r-- 1 root freerad 4148 Jul 20 16:45 radius01.crt.pem
-r--r----- 1 root freerad 1718 Jul 20 16:45 radius01.key.pem

Der Supplicant

Als Supplicants sollen letztendlich ein ganzer Zoo an WLAN-fähigen Geräten (Notebooks, Netbooks, Tablets, Smartphones, Spielekonsolen, WebCams, etc.) zum Einsatz kommen. Zug um Zug wird also dieser Abschnitt um die entsprechenden Devices und deren Konfiguration erweitert.

Debian GNU/Linux mit wpa_supplicant

Die vorhandenen Linux-PCs verwenden im Normallfall Debian GNU/Linux 6.0 (Squeeze) oder Debian GNU/Linux Wheezy und steuern das WLAN über die Dateien /etc/network/interfaces und /etc/wpa_supplicant/wpa_supplicant.conf. Vor den Änderungen an den Konfigurationsdateien empfiehlt es sich das WLAN_Interface zu stoppen.

sudo ifdown wlan0 

# relevante Einstellungen für das WLAN-Interface in 
# /etc/network/interfaces 

allow-hotplug wlan0 
iface wlan0 inet manual 
        wpa-driver              wext 
        wpa-roam                /etc/wpa_supplicant/wpa_supplicant.conf 
        wpa-roam-default-iface  wlan.dhcp 
#       wpa-roam-default-iface  wlan.static 

iface wlan.dhcp inet dhcp 
        pre-up                  /sbin/ip link set $IFACE mtu 1492 

iface wlan.static inet static 
        address                 192.168.1.10 
        broadcast               192.168.1.255 
        network                 192.168.1.0 
        netmask                 255.255.255.0 
#       gateway                 192.168.1.1 
        pre-up                  /sbin/ip link set $IFACE mtu 1492 

# relevante Einstellungen für das WLAN-Interface in 
# /etc/wpa_supplicant/wpa_supplicant.conf 

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev 
eapol_version=2 
ap_Scan=1 
fast_reauth=1 

network={ 
        ssid="your-(e)ssid" 
        scan_ssid=1 
        key_mgmt=WPA-EAP 
        pairwise=TKIP 
        group=TKIP 
        eap=TLS 
        identity="schlepptop01.home.local" 
        ca_cert="/etc/wpa_supplicant/certs/cacert.pem" 
        client_cert="/etc/wpa_supplicant/certs/schlepptop01.crt.pem" 
        private_key="/etc/wpa_supplicant/certs/schlepptop01.key.pem" 
        private_key_passwd="client_cert_key_passphrase" 
        priority=10 
} 

Nachdem die Konfigurationsdateien entsprechend angepasst wurden, wird unter /etc/wap_supplicant ein weiteres Verzeichnis certs erstellt. Prinzipiell können die Zertifikate und Keys in fast jedem beliebigen Verzeichnis liegen, aber hier gibt es zumindest einen Bezug zum Thema. Nun werden die Dateien 'cacert.pem', 'schlepptop01.crt.pem' und 'schlepptop01.key.pem' in das Verzeichnis /etc/wpa_supplicant/certs/ verbracht sowie die Benutzer und Rechte entsprechend angepasst um zumindest einen gewisse Sicherheit zu gewährleisten. Zertifikate haben einen 'public' Status und sollten also für alle lesbar sein. Schlüsseldateien (Keys) dagegen haben einen 'private' Status und sollten also nur für berechtigte Personen und Dienste lesbar sein. Es empfiehlt sich also folgende Einstellung:

chown root:root cacert.pem schlepptop01.crt.pem schlepptop01.key.pem 
chmod 444 cacert.pem schlepptop01.crt.pem 
chmod 440 schlepptop01.key.pem 

ls -l 
-r--r--r-- 1 root root 4828 Jul 20 16:41 cacert.pem 
-r--r--r-- 1 root root 4175 Jul 20 16:47 schlepptop01.crt.pem 
-r--r----- 1 root root 1723 Jul 20 16:47 schlepptop01.key.pem 

Nach dem aktivieren des WLAN-Interfaces sollte sich der Client mit dem WLAN verbinden.

sudo ifup wlan0

Windows XP

(Work in progress)