© Gordon Bussiek, Fotolia.com

Ö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.

Es ist ein Kreuz mit den Ethernet-Ports: Hängt an dem Kabel aus der Bürodecke nun das Produktivnetz oder das Test-Segment? Der Kollege vom anderen Ressort will am Notebook eine Anwendung vorführen, braucht aber Zugriff auf das Netz seiner Abteilung. Bisher blieb geplagten Anwendern dann nur ein Anruf im Serverraum mit der Bitte, doch schnell den einen oder anderen Switchport in ein neues Netz umzupatchen.

Sicherheitsbeauftragte und Admins haben zusätzliche Sorgen: Wer kann schon ausschließen, dass in einem Büro mit regem Besuchsverkehr ein Gast sich nicht – sei es unabsichtlich oder mit Vorsatz – in das Allerheiligste des Firmennetzes einklinkt? MAC-based Port Authentication ist da ein wenig wirksamer Schutz – zu einfach sind MAC-Adressen abgehört und gefälscht, vom Alptraum der Verwaltung durch den Admin mal ganz abgesehen.

So überrascht es, dass die Client-Authentifizierung nach IEEE 802.1X nach wie vor ein Schattendasein fristet [1]. Viele schreiben den Standard der Wireless-Welt zu und wissen gar nicht, dass sich damit schon seit einiger Zeit eine einfache Form von Network Access Control (NAC) bewerkstelligen lässt: Zugangskontrolle für Geräte am Netzwerk – noch lange bevor Login-Bildschirm oder Webbrowser gestartet sind [2].

Port freischalten

Dabei spielt ein IEEE 802.1X-fähiger Switch eine wichtige Rolle. Er ist der Network Access Server (NAS). Bevor er überhaupt irgendwelchen Datenverkehr über einen seiner Ports – der Standard nennt sie Port Access Entity (PAE) – zulässt, muss das anfragende Gerät – also in der Regel ein Desktop oder Notebook – seine Berechtigung nachweisen. Das passiert über das Extensible Authentication Protocol (EAP) auf dem Verbindungslayer. Das anschlusssuchende Gerät betreibt dazu einen kleinen Client, den Supplikanten, der einen Ausweis in Form eines speziellen Ethernet-Frame vorlegt, das sich EAPoL nennt.

EAP erlaubt eine Vielzahl an Berechtigungsnachweisen, als praktisch haben sich in diesem Umfeld X.509v3-Client-Zertifikate erwiesen: Sie haben einen hohen kryptographischen Standard, vermeiden zu einfache Passwörter und lassen sich sowohl einzeln als auch in größerer Zahl bei Bedarf in einer PKI verwalten. Dazu kommt noch, dass sie sich mit einem Token gut schützen lassen und auch anderen Anwendungen noch von Nutzen sind, etwa einem VPN.

Die Proktokollerweiterung dazu heißt EAP-TLS [3]. Neben der Authentisierungsmethode, die wie bei einem SSL-Webserver funktioniert, gibt es theoretisch eine Reihe weitere, etwa One Time Password (OTP), Protected EAP (PEAP) oder getunneltes TLS (TTLS).

Abbildung 1: Die Zugangsberechtigung bei IEEE 802.1X erhält ein beantragender Client (Supplikant), indem er über Bande spielt: Er sendet per EAP-TLS einen Antrag an den Switch, der legt ihn per Radius-Anfrage einem RAS-Server vor. Nickt der die Anfrage ab, schaltet der Switch die zugehörige Port Access Entity (PAE) frei.

Kommt eine EAP-Anfrage vom Typ »EAP-Response/Identity« beim Switch an, leitet dieser sie zu einem Remote-Access-Server (RAS) weiter. Der kennt alle Berechtigten und teilt dem Switch das Ergebnis der Prüfung mit. War sie erfolgreich, öffnet der Switch die PAE und der Client holt sich beispielsweise eine IP-Adresse per DHCP oder konfiguriert sein Interface statisch (siehe Abbildung 1). Das Tandem aus Switch und RAS-Server kann aber noch mehr: Beherrscht der erste IEEE 802.1q, darf der andere zum Beispiel ein VLAN mitteilen, in das der Switch den Antragsteller steckt.

Authentifizierung an Bord

Ein Großteil der administrierbaren Switches ab einer bestimmten Größe kennt IEEE 802.1X, darunter etwa der Netgear FSM726 Managed Switch für 200 Euro mit zwei Gigabit-Ports [4], der 3Com 2924-SFP Plus für 270 Euro [5] oder der Level One GSW-2494 für rund 340 Euro [6]. Alle Geräte haben 24 Ports und unterscheiden sich in einzelnen Ausstattungsmerkmalen, etwa einer stackbaren Backplane.

Abbildung 2: Viele Switches bringen ein Webfrontend zum Konfigurieren mit. Der Netgear FSM726 Managed Switch hat 24 Ports, die sich einzeln für den IEEE-802.1X-Betrieb »Auto« konfigurieren lassen.

Fast alle kommen mit einem Webinterface (Abbildung 2), einige lassen sich über ein Command Line Interface wie Ciscos IOS konfigurieren. Artikel 5.1 des 802.1X-Standards legt fest, welchen Anforderungen die Switches genügen müssen. Einige, wie die IOS-basierten, stellen zusätzliche Features zur Verfügung, etwa ein Gast-VLAN, in das der NAS den Supplikanten steckt, wenn er sich nicht ausweisen konnte – praktisch für Besucher oder in Konferenzräumen.

Um Network Access Control zu aktivieren, verbindet sich der Systemverwalter mit dem Switch. Er stellt die betroffenen PAEs von »Authorized« auf den Modus »Auto« und teilt dem Netzgerät das Passwort und die IP-Adresse für den Remote-Access-Server mit. Den schließt er optimalerweise in einem separaten VLAN mit getrenntem Admin-Subnetz an. Um ein Henne-Ei-Problem zu vermeiden, stellt er den zugehörigen Port auf »Authorized«.

Switches konfigurieren

Im Cisco IOS aktiviert der Befehl »dot1x system-auth-control« 802.1X im ganzen Switch (Listing 1). Mittels »radius-server host Radius-IP« trägt der Admin den Radius-Server, mit »key« als Radius »secret« ein. Wozu ein »aaa authentication« die Gruppe »radius« zuweist. Die Befehle »dot1x pae authenticator« und »dot1x port-control auto« verwandeln dann das gewählte Interface in ein 802.1X-Interface. Das Gast-VLAN, das bei fehlgeschlagenen Autorisierungsversuchen den Client in ein unkritisches Netz schaltet, konfiguriert der Admin mit »dot1x guest-vlan vlan-id«. Bei weiteren Fragen helfen der IOS-Configuration-Guide [7] oder das Free-Radius-Wiki [8].

Switch# configure terminal  
Switch(config)# dot1x system-auth-control  
Switch(config)# aaa new-model  
Switch(config)# aaa authentication dot1x default radius  
Switch(config)# radius-server host 192.168.123.23 auth-port 1812 key secret  
Switch(config)# interface fa1/10  
Switch(config-if)# switchport mode access  
Switch(config-if)# dot1x pae authenticator  
Switch(config-if)# dot1x port-control auto  
Switch(config-if)# end  
Switch# show dot1x interface fa1/10 details 

Radius verwaltet Benutzer

Mit dem RAS-Server, der alle berechtigten Supplikanten kennt, spricht der Switch das in RFC 2865 definierte Radius-Protokoll. Dessen Kommunikation schützt ein Shared Secret, das der Admin beispielsweise mit »pwgen -s -1« generiert und zunächst im Switch hinterlegt. Damit ist das Netzgerät vorbereitet. Alle weiteren Server-seitigen Einstellungen nimmt der Systemverwalter auf dem RAS-Server vor. Dort verwaltet er auch die Zertifikate, es sei denn, er möchte diese Aufgabe aus besonderen Sicherheitsgründen auf einen separaten Rechner verlagern.

Als Remote-Access-Server ist Free Radius die richtige Wahl [9]. Mit ein paar Anpassungen in den Standard-Konfigurationsdateien unter »/etc/raddb/« (Open Suse) oder »/etc/freeradius/« (Ubuntu) aktiviert der Admin EAP-TLS. Die Grundeinstellungen von Free Radius lassen sich in vielfältiger Weise in einer Reihe von Einzeldateien erweitern. So kann die Software ihre Benutzerliste auch aus einer Datenbank oder einem Verzeichnisdienst beziehen oder Benutzern Zeitbeschränkungen auferlegen.

Allgemeine Einstellungen beherbergt »radius.conf«: Da der Server nur authentisieren soll, ist die Sektion »listen« mit »type=auth« relevant. Der Admin setzt die IP-Adresse beim Schlüssel »ipaddr«, anderfalls lauscht die Software auf allen Interfaces nach Anfragen auf UDP-Port 1812. Eventuell passt der Systemverwalter daher seine Firewallregeln an. Um später Anfragen besser nachzuvollziehen, hilft in der Sektion »log« die Einstellung »auth = yes« – sie protokolliert insbesondere fehlgeschlagene Versuche.

Die Datei »clients.conf« legt das Admin-Segment zwischen Server und Radius-Server fest, aus dem Letzterer Anfragen entgegennimmt. Der Eintrag »secret« enthält das gemeinsame Geheimnis zwischen den Partnern:

client 192.168.123.0/24 {
        secret     = hEoLw6DC
        shortname  = uebelhackers
}

Die Datei »radius.conf« bindet »eap.conf« ein. Dort setzt der Admin den Schlüssel »default_eap_type« auf »tls«. In der gleichnamigen Untersektion hinterlegt er noch bei »private_key_password« das Passwort, das ein noch zu erzeugendes Server-Zertifikat freischaltet. Es weist dem Supplikanten später nach, dass der RAS-Server authentisch ist.

Zertifikate erzeugen

Einige Distributionen haben ein Makefile im Verzeichnis »/etc/raddb/certs«. Damit bauen sie mittels OpenSSL drei Arten von Zertifikaten: Erstens das einer kleinen CA, die später die Urkunden sowohl für (zweitens) den Server und (drittens) die Clients unterzeichnet. Ist dieses Verzeichnis jedoch wie bei Ubuntu 9.04 leer, bezieht der Admin die Dateien aus dem Github von Free Radius unter »raddb/certs/« [10]. Für jedes Zertifikat kennt das Paket eine Konfigurationsdatei sowie ein steuerndes gemeinsames Makefile. Um ein neues CA-Zertifikat anzulegen, bearbeitet der Admin »ca.cnf«. Den Abschnitt »[certificate_authority]« passt er wie in Listing 2 an. Identische Werte setzt er bei »input_password« und »output_password«.

[certificate_authority] 
countryName             = DE
stateOrProvinceName     = Hamburg
localityName            = Hamburg
organizationName        = UebelHacker 
emailAddress            = ca@uebelhacker.de 
commonName              = "UebelHacker Certificate Authority

Analog editiert der Admin die Sektion »[server]« in »server.cnf«, wählt aber dort einen anderen »commonName«, damit sich die Zertifikate unterscheiden (siehe Listing 3). An der Stelle für das Passwort fügt er das in der »eap.conf« festgelegte »private_key_password« ein. Schließlich erzeugt »make all« neben den CA- und Server-Zertifikaten auch die nötige Diffie-Hellman-Datei »dh« und die »random«-Datei, beides wichtige Bestandteile des Protokoll-Handshake von SSL/TLS.

[server] 
countryName             = DE
stateOrProvinceName     = Hamburg 
localityName            = Hamburg
organizationName        = UebelHacker
emailAddress            = radius@uebelhacker.de
commonName              = "UebelHacker Radius Server" 

Benutzerzertifikate

Bei EAP-TLS benötigt jedes Gerät ein eigenes Client-Zertifikat, das der Systemverwalter mit der Datei »client.cnf« erzeugt. Das Makefile von Free Radius signiert diese Ausweise jedoch mit dem Server-Zertifikat. Damit stattdessen die CA signiert, ändert der Admin die Zeilen aus Listing 4 im Makefile und achtet auf das führende Tab in Zeile 2. So kann er dem Supplikanten später direkt das CA-Zertifikat mitgeben.

client.crt: client.csr ca.pem ca.key index.txt serial
         openssl ca -batch -keyfile ca.key -cert ca.pem
   -in client.csr -key $(PASSWORD_CA) -out client.crt
   -extensions xpclient_ext -extfile xpextensions
   -config ./client.cnf

In der Sektion »[client]« legt der »commonName« den Benutzernamen für Berechtigungen und weitere Einstellungen unter Radius fest. Auch dieses Zertifikat schützt ein Passwort, das der Admin in »input_password« und »output_password« setzt:

[client]
countryName         = DE
stateOrProvinceName = Hamburg
localityName        = Hamburg
organizationName    = UebelHacker
emailAddress        = s@uebelhacker.de
commonName          = uebelacker

Anders als für CA und Server muss der Admin hier mehrere Zertifikate ausstellen – für jeden User eins. Da »make client« immer nur eins erzeugt, empfiehlt es sich, diese Aufgabe zu skripten. Die fertigen Zertifikate übergibt er den Benutzern zusammen mit ihrem Passwort und dem CA-Zertifikat auf sicherem Weg, beispielsweise per USB-Stick oder auf einer Smartcard.

Benutzer einrichten

Als Nächstes benötigt der RAS-Server Angaben über die zugelassenen Benutzer. Will es sich der Systemverwalter ganz einfach machen, stattet er jeden Anwender einfach mit einem von der CA unterzeichneten Client-Zertifikat aus. Wenn er die Radius-Konfigurationsdatei »users« nicht anfasst, gewährt der RAS jedem Zugang, der ein gültiges vorweisen kann. Der Switch weist dem Antragsteller dann das dort hinterlegte VLAN zu.

Möchte der Systemverwalter dem RAS-Server jedoch noch zusätzliche Informationen über die User mitgeben, hat er mehrere Optionen: Am schnellsten gelingt es, die Berechtigten und Unberechtigten in der Datei »users« zu erfassen. Listing 5 gibt ein Beispiel.

01 dau Auth-Type := Reject
02 
03 DEFAULT Auth-Type := EAP, Login-Time := "Wk0800-2000"
04     Tunnel-Type = 13,
05     Tunnel-Medium = 6,
06     Tunnel-Private-Group-Id = 23,
07     Fall-Through = Yes
08 
09 uebelacker Auth-Type := EAP, Login-Time = "Any"
10     Tunnel-Private-Group-Id = 42

Die Vorgabe für jeden Antragsteller, der per EAP ein gültiges Zertifikat vorlegt, definiert der Systemverwalter ab Zeile 3. Die Angaben zu »Tunnel-Type« und »Tunnel-Medium« schreibt der Standard vor, wenn der Switch ein VLAN vergeben soll, beispielsweise »23« für das Benutzer-Segment. Weitere Radius-Extensions definiert RFC 2869, so dürfen sich Anwender nur werktags zwischen 8 und 20 Uhr anmelden, um nächtliches Hacking zu unterbinden.

Die erste Zeile sperrt den Benutzer »dau« aus, der das Unternehmen verlassen hat, aber noch ein gültiges Zertifikat besitzt. Alternativ lässt sich diese Logik auch mit Certificate Revocation Lists (CRLs) mit etwas mehr Aufwand realisieren. Für die Datei gilt die First-Match-Regel, es sei denn, der Admin setzt das Attribut »Fall-Through« wie in Zeile 7. Auf diese Weise überschreiben die zusätzlichen Attribute die Einstellungen für den Administrator mit dem Namen »uebelacker«: Er erhält keine Zeitbegrenzung und findet sich direkt im Admin-Segment wieder.

Mit »radiusd -X« startet der RAS im Debug-Modus, der mögliche Fehlkonfigurationen einfach erkennbar macht. Hat der Start keine hervorgebracht, zeigt Radius an, dass er nun Anfragen beantwortet:

Listening on authentication address 192.168.123.23 port 1812
Ready to process requests.

Es ist ratsam, den Daemon bis zur erfolgreichen Freischaltung eines Netzwerk-Ports im Debug-Modus laufen zu lassen, da er alle Aktivitäten ausführlich auf die Standardausgabe schreibt.

Client einrichten

Im späteren Produktivbetrieb verfolgt der Admin diese Angaben mit »tail -f /var/log/radius/radius.log«:

Info: Ready to process requests.
Auth: Login OK: [uebelacker] (from client uebelhackers port 13 cli 00:19:e0:18:38:5c)

Aus dieser Angabe erkennt er, dass sich der Besitzer des Zertifikats, ausgestellt auf »uebelacker«, am Switchport 13 angemeldet hat. Dazu sendet der Client dem Switch EAPoL-Pakete. Diese Funktionalität liefern sowohl Xsupplicant aus dem Open1X-Projekt [11] der OpenSEA Alliance [12] als auch das etwas bekanntere »wpa_supplicant« [13]. Nicht alle Distributionen stellen beide Supplikanten zur Verfügung. Als grafisches Frontend für »wpa_supplicant« dient unter Ubuntu 9.04 der Network-Manager (siehe Abbildungen 3 und 4).

Abbildung 3: Der Network-Manager unter Ubuntu kennt bereits EAP-TLS und konfiguriert es grafisch.

Abbildung 4: Einmal eingerichtet, bekommen Anwender von der Anmeldung am Switch nichts mehr mit.

In der »/etc/xsupplicant/xsupplicant.conf« konfiguriert der Benutzer sein 802.1X-Profil (siehe Listing 6) und testet mit dem folgenden Aufruf den Supplikanten:

xsupplicant -D wired -i eth0 -d 5 -f -c /etc/xsupplicant/xsupplicant.conf

Nach erfolgreicher 802.1X-Authentifizierung und Freischaltung am Netzwerk-Port, die das Tool mit »Changing from AUTHENTICATING to AUTHENTICATED« quittiert, vergibt das Startskript die IP-Adresse wie gewohnt statisch oder per DHCP. Wenn der Xsupplicant per »/etc/init.d/xsupplicant start« im Hintergrund läuft und mit »chkconfig xsupplicant on« den Reboot übersteht, findet die 802.1X-Authentifizierung automatisch statt.

01 default_netname = intranet
02 intranet {
03   type = wired
04   allow_types = eap_tls
05   identity = uebelacker
06   eap_tls {
07      user_cert = "/path/to/s@uebelhacker.de.pem"
08      user_key  = "/path/to/s@uebelhacker.de.pem"
09      user_key_pass = "Usercert-Passwort"
10      root_cert = "/path/to/ca.pem"
11      chunk_size = 1398
12      random_file = /dev/urandom
13   }
14 }

Supplikanten spielen auf

Das Paket »wpa_supplicant« richtet der Benutzer analog ein und testet es mit:

wpa_supplicant -i eth0 -D wired -c /etc/wpa_supplicant/wired.conf  

Die Konfigurationsdatei »wired.conf« richtet er dazu neu ein, wie im Listing 7 angegeben. Da die 802.1X-Authentifizierung kabelgebunden stattfindet, kann er die »eapol_version« mit Version 2 verwenden und deaktiviert das Scannen nach Accesspoints.

01 eapol_version=2
02 ap_scan=0
03 fast_reauth=1
04 network={
05     key_mgmt=IEEE8021X
06     eap=TLS
07     identity="uebelacker"
08     ca_cert="/path/to/ca.pem"
09     client_cert="/path/to/s@uebelhacker.de.pem"
10     private_key="/path/to/s@uebelhacker.de.pem"
11     private_key_passwd="Usercert-Passwort"
12     eapol_flags=0
13 }

Die Authentifizierung war erfolgreich, wenn der Supplikant »CTRL-EVENT-EAP-SUCCESS« meldet. Damit er permanent im Hintergrund läuft und bei 802.1X-Ports automatisch den Client authentifiziert, passt der Benutzer unter Debian »/etc/network/interfaces« wie in Listing 8 an, wenn er DHCP verwendet. Ansonsten ändert er »dhcp« in »static« und setzt eine feste IP-Adresse. »/etc/init.d/networking restart« aktiviert die Einstellungen. Falls der Client an einen Port ohne IEEE 802.1X im Modus »authorized« gerät, läuft der Anmeldeversuch zwar ins Leere, der Client arbeitet aber wie gewohnt.

Zum Abschluss überführt der Admin den Radius-Server in den Produktivbetrieb: Er aktiviert das Init-Skript mit »service freeradius start« und merkt mit »chkconfig freeradius on« den Start für den nächsten Bootvorgang vor.

Ausbau möglich

Die Komponenten für eine gerätebasierte Authentifizierung von Endgeräten an Switches sind vielerorts vorhanden. Es liegt am Administrator, sie miteinander zu kombinieren. Unter Network Access Control verstehen einige noch zusätzliche Aspekte, etwa technisch überprüfte Versionsstände oder aktuelle Virensignaturen, die einer Security Policy genügen. Insofern bietet NAC noch viele Optionen zum Ausbau: Neben der Anbindung an LDAP oder eine SQL-Datenbank lohnt sich in komplexeren Umgebungen eine PKI, etwa mit Tiny CA [14]. Smartcards wie das E-Token von Aladdin schützen private Benutzerzertifikate [15].

IPv6 stellt Free Radius ab Version 2 vor keine Probleme, jedoch manchen 802.1X-fähigen Switch. Wer mit IKEv2 experimentiert, dem sei die »experimental.conf« des Projekts ans Herz gelegt, aber auch ein gleichnamiges Sourceforge-Projekt forscht daran [16]. Außerdem dürfen sich dank Hostapd-Projekt [17] Admins bald auf EAP2 genannte Neu-Implementierungen von EAP in Free Radius freuen.