[[Vorlage(Getestet, bionic)]] [[Vorlage(Fortgeschritten)]] {{{#!vorlage Wissen [:Pakete installieren: Installation von Programmen] [:Terminal: Ein Terminal öffnen] [:sudo: Root-Rechte] }}} [[Inhaltsverzeichnis()]] [[Bild(Wiki/Icons/service.png, 48, align=left)]] Der Server-Dienst [http://freeradius.org/ FreeRADIUS] {en} ist laut eigener Angabe „der am häufigsten genutzte RADIUS-Server der Welt“ und unterstützt neben dem [wikipedia:Extensible_Authentication_Protocol:EAP]- natürlich auch das [wikipedia:Remote_Authentication_Dial-In_User_Service:RADIUS]-Protokoll. Im Kern geht es beim "'''R'''emote '''A'''uthentication '''D'''ial-'''I'''n '''U'''ser '''S'''ervice" um das sogenannte [wikipedia:Triple-A-System:AAA]: * '''A'''uthentisierung - Ist der Client berechtigt auf das Netzwerk zuzugreifen? * '''A'''utorisierung - In welchem Umfang darf der Client zugreifen? * '''A'''ccounting - Welche Ressourcen hat der Client während des Netzwerkzugriffs in Anspruch genommen? Clients, die auf ein Netzwerk zugreifen möchten, müssen sich zuerst am RADIUS-Server anmelden, noch bevor eine Verbindung zum gewünschten Netzwerk aufgebaut wird. Das erhöht die Sicherheit und sorgt für eine einfachere Verwaltung von Netzwerken. Für die Authentisierung benutzt der Client das [wikipedia:IEEE_802.1X:IEEE 802.1X]-Protokoll, weswegen dieser Begriff häufig als Synonym für diese Art der Netzwerkanmeldung verwendet wird. = Einführung = == Begriffsklärung == Der Einstieg in das Thema wird durch eine ganze Reihe an Begriffen erschwert, die speziell im Umfeld von RADIUS und 802.1X verwendet werden. [[Vorlage(Bildunterschrift, 802.11X-Prinzip.png, 400 "Übersicht 802.1X ([wikimedia::][http://de.wikipedia.org/w/index.php?title=Datei:8021X-Overview.svg Bildquelle])", right)]] '''Supplicant''' - Hierbei handelt es sich um den Client, der Zugriff auf das Netzwerk erhalten möchte. Also z.B. ein Laptop, Smartphone, Tablet, PC, etc. Wird daher auch häufig als STA (Client Station) bezeichnet. '''Authenticator''' - Das phys. Gerät das den Zugriff zum Netzwerk ermöglicht. Wird daher auch häufig als NAS (Network Access Server) bezeichnet. Es entscheidet darüber, ob ein Client Zugriff erhält oder nicht. Bei kabelgebundenen Netzwerken (Ethernet / IEEE 802.3) handelt es sich i.d.R. um einen Switch. Bei WLAN-Netzwerken (IEEE 802.11 a/b/g/n/ac) übernimmt das der [wikipedia:Wireless_Access_Point:Access Point] (im Folgenden häufig mit AP abgekürzt). '''Authentication Server''' - Der Server auf dem der RADIUS-Dienst läuft. Der Dienst überprüft Benutzername und Kennwort, und liefert ggf. noch weitere Informationen an den Authenticator. Erst dieser entscheidet dann darüber, ob und in welchem Umfang der Client auf das Netzwerk zugreifen darf. [[Bild(radius-protocols.png, 320, align=right)]] '''802.1X''' - Protokoll zwischen Supplicant und Authenticator (rote Pfeile in der rechten Grafik). Das Protokoll setzt direkt auf Ethernet (802.3) bzw. WLAN (802.11) auf, noch bevor eine TCP/IP-Verbindung aufgebaut wird. Wird von allen modernen Betriebssystemen unterstützt (Linux, Windows, macOS, iOS, Android, etc.). '''RADIUS''' - Protokoll zwischen Authenticator und Authentication Server (grüne Pfeile in der rechten Grafik). Das Protokoll setzt auf TCP/IP auf (UDP/1812, UDP/1813). Authenticator und Authentication Server teilen sich ein gemeinsames "Secret", mit dem die Kommunikation verschlüsselt und signiert wird. '''EAP''' - Protokoll zwischen Supplicant und Authentication Server. Des Protokoll setzt sowohl auf 802.1X als auch auf RADIUS auf, und dient hauptsächlich der Authentisierung (mittels Benutzername + Passwort oder Client-Zertifikat). Es ist Aufgabe des Authenticators, die EAP-Daten vom 802.1X-Protokoll (rote Pfeile) in das RADIUS-Protokoll (grüne Pfeile) zu übersetzen (und zurück). == Verfahrensprinzip == Das IEEE 802.1X-Protokoll beschreibt ein Verfahren, bei dem ein Endgerät (Laptop, PC, etc.) authentisiert werden kann, bevor es in das Netzwerk gelassen wird. Dazu müssen der Zugangspunkt (Switch, WLAN-AP) und das Endgerät das 802.1X-Protokoll unterstützen. Das Endgerät (Supplicant) verbindet sich zunächst mit dem Zugangspunkt (Authenticator). Dieser reicht dann die Informationen an einen RADIUS-Server (Authentication Server) weiter. Die Kommunikation zwischen Endgerät und RADIUS-Server kann [wikipedia:Transport_Layer_Security:TLS]-verschlüsselt erfolgen, also auch über "unsichere“ Netze. Wichtig dabei ist: Das Endgerät kommuniziert nie direkt mit dem RADIUS-Server, sondern mit dem Zugangspunkt (über IEEE 802.1X), da es zu diesem Zeitpunkt ja noch keine IP-Adresse hat. Der Zugangspunkt setzt die Pakete dann um und kommuniziert seinerseits mit dem RADIUS-Server. Die gesamte Sicherheit basiert deshalb auf der Vertrauenswürdigkeit von Zugangspunkt und RADIUS-Server. Nach dem initialen „Handshake“ zwischen Endgerät, Zugangspunkt und RADIUS-Server kommt das "Extensible Authentication Protocol" (EAP) zum Einsatz. Hinter EAP stecken, je nach Implementierung auf RADIUS- und Client-Seite, verschiedene Verfahren. Das zu verwendende Verfahren kann während des Verbindungsaufbaus zwischen Client und RADIUS-Server ausgehandelt werden. Die Kommunikation ist in 2 Phasen aufgeteilt. Zunächst wird der äußere Tunnel aufgebaut (Phase 1), der für die TLS-Verschlüsselung sorgt: * EAP-TLS: Der Client wird über Zertifikate durch einen gesicherten TLS-Tunnel authentisiert * EAP-TTLS: Passwort-Abfrage durch einen gesicherten TLS-Tunnel * EAP-PEAP: Passwort-Abfrage (Challenge-Response) durch einen gesicherten TLS-Tunnel (hauptsächlich für Windows-Umgebungen) * EAP-MD5: Unverschlüsselte Verbindung. Das Passwort wird zwar nicht im Klartext übertragen, sondern über ein Challenge-Response-Verfahren abgeglichen, das eine MD5-Hashfunktion verwendet. Das Verfahren gilt allerdings als überholt und nicht mehr sicher. * ... Anschließend wird über den äußeren Tunnel der innere Tunnel aufgebaut (Phase 2), über den auch die eigentliche Authentisierung des Clients stattfindet: * PAP: Das Passwort wird im Klartext übertragen. * MD5: Challenge-Response-Verfahren mit einer MD5-Hashfunktion (überholt und nicht mehr sicher) * MSCHAPv2: Challenge-Response-Verfahren (hauptsächlich für Windows-Umgebungen) * ... (s. Kapitel [#RADIUSPasswort Passwort]) Ist die Authentisierung des Clients abgeschlossen, schickt der RADIUS-Server eine Autorisierung an den Zugangspunkt und der Client wird freigeschaltet (oder abgelehnt). Dies geschieht zum Beispiel dadurch, dass an einem Switch die entsprechende phys. Buchse (Port) freigeschaltet wird, oder bei einem AP die temporären Schlüssel für die Verbindung ausgehandelt werden (s. Kapitel [#RADIUSWLAN WLAN]). == Einsatzgebiete == [[Anker(RADIUSWLAN)]] === WLAN === Möchte man Daten über ein WLAN übertragen, hat man immer das Problem des Schlüsselaustauschs. [wikipedia:WPA2:WPA2] setzt auf den symmetrischen (schnellen) auf AES-basierten Verschlüsselungsalgorithmus CCMP und benutzt 2 unterschiedliche Schlüssel: * ''PTK'' ("Pairwise Transient Key") - Verschlüsselt den Datenverkehr der nur für einen einzelnen WLAN-Client bestimmt ist (Unicast) und ist für jeden Client unterschiedlich * ''GTK'' ("Group Transient Key") - Verschlüsselt den Datenverkehr der für alle WLAN-Clients des APs bestimmt ist (Multicast/Broadcast) und ist für alle Clients identisch Diese beiden symmetrischen Schlüssel werden dazu verwendet, den eigentlichen Netzwerkverkehr zu verschlüsseln. Zum Austausch der symmetrischen Schlüssel kommt dabei das 802.11i-Protokoll zum Einsatz. Dieses setzt auf das sogenannte PSK-Verfahren ([wikipedia:Pre-shared_key:Pre-shared key]) auf: Alle Clients initiieren den Verbindungsaufbau mit demselben PSK, und erhalten daraufhin die zwei symmetrischen Schlüssel als Ergebnis. Die Reihenfolge ist ungefähr wie folgt: 1. AP und Client stellen sicher, dass beide über denselben PSK verfügen, ohne dass dieser selbst über das Netzwerk übertragen wird. 1. Aus dem PSK wird der PTK auf dem AP und auf dem Client generiert. Auch der PTK wird selbst nicht über das Netzwerk übertragen. 1. Mit dem PTK wird der GTK verschlüsselt vom AP an den Client übertragen. Auch bei 802.1X werden PTK und GTK für die Verschlüsselung des Netzwerkverkehrs genutzt. Der einzige Unterschied besteht darin, dass bei RADIUS der PTK aus EAP-Parametern generiert wird. Ansonsten sind beide Verfahren bzgl. 802.11i-Protokoll und Verschlüsselung des eigentlichen Netzwerkverkehrs identisch (s. [wikipedia_en:IEEE 802.11i-2004:IEEE 802.11i-2004]). Das PSK-Verfahren hat allerdings mehrere Probleme: * Der PSK ist ein gemeinsames 8 - 63-stelliges Passwort, das sowohl auf dem AP als auch auf allen WLAN-Clients im Klartext vorliegen muss. Je mehr Clients im Netzwerk unterwegs sind, umso mehr wird dieses „Geheimnis“ geteilt. In der Folge wird es immer wahrscheinlicher, dass der PSK bald kein Geheimnis mehr ist. * Spätestens bei Wegfall / Austausch / Verlust / Diebstahl eines Gerätes muss der PSK auf allen verbleibenden Geräten geändert werden. Das kann je nach Fluktuation und wachsender Anzahl von Endgeräten beliebig schwierig werden. * Der PSK muss immer auf allen Endgeräten gleichzeitig geändert werden. Das kann z.B. dann zum Problem werden, wenn der Verantwortliche eines Endgeräts zum Zeitpunkt der PSK-Änderung nicht erreicht werden kann ("Die Security-Kamera hat Kollege Mustermann eingerichtet, der ist gerade im Urlaub."). * Einzelne Clients sind in den Logs nicht unterscheidbar (MAC-Adressen lassen sich leicht ändern). Bei 802.1X kann man genau nachvollziehen, welcher Benutzer sich auf welchem Zugangspunkt angemeldet hat. ("Am Wochenende hat sich Kollege Mustermann am WLAN im Konferenzraum angemeldet." "Moment mal, Herr Mustermann ist doch im Urlaub?") * Der AP lässt sich vom Client nicht eindeutig identifizieren. SSID und BSSID können von einem Angreifer leicht auf einem eigenen AP (mit einem stärkeren Signal) konfiguriert werden, der dann für einen [wikipedia:Man-in-the-Middle-Angriff:] genutzt wird. Damit lassen sich dann unverschlüsselte TCP- oder UDP-Verbindungen manipulieren, wie z.B. DNS-Abfragen. Ein RADIUS-Server wird hingegen anhand seines eindeutigen Server-Zertifikats identifiziert (sofern TLS-Verschlüsselung eingesetzt wird, s. Kapitel [#RADIUSZertifikate Zertifikate]). === Festnetz === RADIUS-Authentisierung wird auch häufig in [wikipedia:Ethernet:Ethernet]-Netzwerken eingesetzt. Durch die Unterstützung unterschiedlicher Backend-Datenbanken können beliebige Organisationsstrukturen im Netzwerk abgebildet werden. So können Clients unabhängig von Standort oder Verbindungstechnik (Kabel, WLAN) immer ins gleiche Zielnetz eingebunden werden (per [wikipedia:Virtual_Local_Area_Network:VLAN]). Diese Funktion wird standardmaßig von Switchen/APs der Enterprise-Klasse angeboten, ist aber auch immer häufiger bei Geräten für Heimnetzwerke zu finden. Außerdem hat 802.1X einen Sicherheitsvorteil: Switche öffnen nicht mehr jedem beliebigen Endgerät ihre Netzwerkports. Nur noch „bekannte“ Clients bekommen Zugang zum Netz. Auch das Abstecken eines validen Clients und Ersetzen durch einen unbekannten Client ist nicht mehr möglich. Voraussetzung dafür ist allerdings, dass alle Switche richtig konfiguriert sind und alle Endgeräte 802.1X und die vom RADIUS-Server vorgegebene Authentisierungsmethode unterstützen. {{{#!vorlage Hinweis Zusätzlich bietet RADIUS die Möglichkeit des Accountings für Abrechnungs- oder Monitoring-Zwecke, was in diesem Artikel aber nicht weiter behandelt wird. }}} == Authentisierung == Die Wahl der Verfahren für Phase 1 und Phase 2 hängt hauptsächlich davon ab, in welcher Form ein Passwort (oder Zertifikat) dem RADIUS-Server zur Verfügung steht. ||<-4 cellstyle="text-align: center;" rowclass="titel">Gängige EAP-Verfahren zur Authentisierung || ||<- rowclass="kopf">'''Phase 1''' ||'''Phase 2''' ||'''Einsatz''' || '''Beschreibung ''' || ||EAP-TLS ||- ||Gemischte Umgebungen (Windows, Linux, macOS, ...) ||Authentisierung ohne Passwort, sondern mit Client-Zertifikat || ||EAP-TTLS ||PAP ||Gemischte Umgebungen (Windows, Linux, macOS, ...) ||Passwort liegt auf dem RADIUS-Server nur verschlüsselt vor und muss daher im Klartext übertragen werden || ||EAP-PEAP ||MSCHAPv2 ||Windows-Umgebungen ||Passwort liegt im Klartext vor, oder in einem NTLM-Passwortspeicher (Windows AD) || In Phase 1 sollte eigentlich immer eine TLS-verschlüsselte Verbindung aufgebaut werden, wie das bei EAP-TLS, EAP-TTLS oder EAP-PEAP der Fall ist. Verfahren ohne Verschlüsselung wie z.B. EAP-MD5 sollten nur dann verwendet werden, wenn der Client keine TLS-Verschlüsselung unterstützt. Dies kann bei älteren Geräten oder einfacheren Appliances notwendig sein, wie z.B. IP-Telefonen. === Client-Zertifikat === Beim Einsatz des 802.1X-Protokolls in Kombination mit EAP-TLS muss auf allen Clients ein CA-Zertifikat hinterlegt werden. Der RADIUS-Server selbst verfügt über ein Server-Zertifikat, Clients über ein Client-Zertifikat, welches jeweils von dieser CA signiert wurde. Beim initialen Handshake wird mit Hilfe dieser Zertifikate eine [wikipedia:Transport_Layer_Security:TLS]-Verbindung aufgebaut. Der RADIUS-Server überprüft die Gültigkeit des Client-Zertifikats und gibt den Client dann frei. Prinzipbedingt kann der RADIUS-Server aber nur überprüfen, ob ein Zertifikat korrekt signiert wurde – nicht aber ob das Zertifikat zum jeweiligen Client passt. So ist es beispielsweise möglich, allen Clients mit nur einem einzigen Zertifikat Zugriff auf das Netzwerk zu gewähren. Besser ist es, jedem Client ein eigenes Zertifikat auszustellen. Bei Verlust eines Gerätes muss dann nur das entsprechende Zertifikat auf dem RADIUS-Server gesperrt werden, und nicht auf allen Clients ein neues Zertifikat installiert werden. [[Anker(RADIUSPasswort)]] === Passwort === Der zusätzliche Aufwand für den Betrieb einer eigenen CA darf allerdings nicht unterschätzt werden. Sollte es daher bereits eine Benutzerdatenbank im Netzwerk geben ([:Archiv/OpenLDAP_ab_Precise:OpenLDAP], [wikipedia:Active_Directory:Windows AD], etc.), kann auch diese zur Authentisierung von Endgeräten verwendet werden (EAP-TTLS, EAP-PEAP, etc.). Das hat den Vorteil, dass neue Benutzer automatisch über 802.1X authentisiert werden können (mit Benutzername und Passwort), bzw. gelöschte oder deaktivierte Benutzer automatisch keinen physischen Zugriff mehr auf das Netzwerk haben. Im einfachsten Fall werden Benutzername und Passwort aber direkt in eine FreeRADIUS-Konfigurationsdatei eingetragen (Datei '''users'''). Das Passwort steht dort aber im Klartext, daher sollte diese Methode nur für Testzwecke verwendet werden. Für den Abgleich des Passworts zwischen Supplicant und Authentication Server sind prinzipiell zwei Möglichkeiten zu unterscheiden: * [wikipedia:Challenge-Response-Authentifizierung:] - Das Passwort selbst wird nicht zwischen beiden Seiten übertragen. Stattdessen stellt der Authentication Server eine kryptographische Anfrage an den Supplicant. Dieser kann die Anfrage nur dann richtig beantworten, wenn er im Besitz des korrekten Passworts ist. Das Problem dabei ist allerdings, dass der RADIUS-Server entweder ebenfalls im Besitz des Klartextpassworts sein muss, oder der Passwortspeicher diese Art der Authentifizierung speziell unterstützen muss, wie das z.B. bei Windows AD der Fall ist (MSCHAPv2). Unter Linux gibt es daher nur die Möglichkeit das Passwort im Klartext auf dem RADIUS-Server abzulegen, wie z.B. in der '''users'''-Datei. In der Regel dürften Passwörter aber über eine [:Hashfunktionen:Hashfunktion] verschlüsselt im LDAP oder einer MySQL-Datenbank abgespeichert sein. * Passwort wird im Klartext übertragen - Alternativ wird das Passwort im Klartext über eine TLS-gesicherte Verbindung übertragen (EAP-TTLS und PAP). Dies ist dann genauso sicher wie z.B. eine Anmeldung mit Benutzername und Passwort auf einer HTTPS-Webseite, und daher für die meisten Fälle ausreichend. Da das vom Client gesendete Passwort jetzt im Klartext vorliegt, hat der RADIUS-Server die Möglichkeit Benutzername und Passwort in allen möglichen angeschlossenen Benutzerdatenbanken zu überprüfen (OpenLDAP, MySQL, PostgreSQL, etc.), auch wenn das Passwort dort verschlüsselt gespeichert ist. = Installation = Die Server-Komponente von FreeRADIUS ist in den offiziellen Paketquellen enthalten [1]. {{{#!vorlage Paketinstallation freeradius }}} Zusätzlich zum eigentlichen FreeRADIUS-Paket muss noch jeweils ein Paket für den Zugriff auf einen Passwortspeicher installiert werden. Hier eine Auswahl (in der Regel ist nur eines davon notwendig): {{{#!vorlage Paketinstallation freeradius-ldap freeradius-krb5 freeradius-mysql freeradius-postgresql freeradius-redis }}} Während der Installation wird der Server automatisch gestartet. Unabhängig davon sollte man den Server erstmal wieder stoppen und in einer getrennten Konsole im Debugmodus hochfahren. So lassen sich Anmeldevorgänge leichter debuggen. {{{#!vorlage Befehl sudo systemctl stop freeradius sudo -u freerad freeradius -fxX ... STRG+C }}} = Konfiguration = FreeRADIUS bietet sehr komplexe Konfigurations-Möglichkeiten. Ähnlich der [:Apache:]-Konfiguration gibt es eine Hauptdatei '''/etc/freeradius/3.0/radiusd.conf''', die ihrerseits weitere Konfig-Dateien direkt oder indirekt einliest. ||<-2 cellstyle="text-align: center;" rowclass="titel">Wichtige Konfigurationsdateien und -Verzeichnisse || ||<- rowclass="kopf">'''Datei / Verzeichnis''' ||'''Beschreibung''' || ||'''/etc/freeradius/3.0/''' ||Basisverzeichnis unterhalb dessen alle Konfigurationsdateien liegen || ||'''./radiusd.conf''' ||Hauptkonfigurationsdatei || ||'''./users''' ||lokale Benutzerkonten || ||'''./certs/''' ||Zertifikatsverzeichnis mit CA-, Server- und Client-Zertifikaten || ||'''./mods-available/''' ||Verzeichnis mit allen verfügbaren Modulen || ||'''./mods-enabled/''' ||Verzeichnis mit symbolischen Links auf diejenigen Module die tatsächlich geladen werden sollen || ||'''./sites-available/''' ||Verzeichnis mit allen verfügbaren virtuellen Servern || ||'''./sites-enabled/''' ||Verzeichnis mit symbolischen Links auf diejenigen virtuellen Server die tatsächlich geladen werden sollen || Laut Aussage der Entwickler wird FreeRADIUS mit einer „Best-Practice“-Konfiguration ausgeliefert, die so wenig wie möglich geändert werden sollte – bzw. nur, wenn man genau weiß, was man macht. Weiter wird empfohlen, eine Versionsverwaltung einzusetzen, um Änderungen schnell rückgängig machen zu können. In vielen Konfigurationsdateien (z.B. '''users''', '''sites-available/*''') kommt eine eigene Skriptsprache zum Einsatz: [https://wiki.freeradius.org/glossary/Unlang unlang] {en}. Die Verwendung der Sprache ist allerdings gewöhnungsbedürftig und nur für erfahrene Benutzer zu empfehlen. Einsteiger sollten sich daher besser an vordefinierte Beispiele halten um eine Fehlkonfiguration zu vermeiden. Hier die wichtigsten Sprachelemente: ||<-3 cellstyle="text-align: center;" rowclass="titel">Elemente der Sprache "unlang" || ||<- rowclass="kopf">'''Element''' ||'''Beschreibung''' ||'''Beispiel''' || ||:= ||Zuweisung zu einem Attribut, um dieses beispielsweise zum Authenticator zurückzusenden. Ein bereits bestehender Wert des Attributs wird ggf. überschrieben. ||{{{Auth-Type := Reject}}} Authentisierung wird abgelehnt. {{{Cleartext-Password := "12345"}}} Definiert das unverschlüsselte Klartextpasswort für einen Benutzer in der Datei '''users'''. || ||= ||Zuweisung zu einem Attribut. Im Gegensatz zu := wird ein bereits bestehender Wert nicht überschrieben. ||{{{Reply-Message = "Your account has been disabled."}}} Fehlernachricht an den Supplicant || ||== ||Ein Konfigurationsausdruck wird nur dann angewendet, wenn dieser Vergleich zutrifft. Bei "if"-Anweisungen muss man darauf achten, dem linken Operanden ein & voranzustellen. ||{{{Huntgroup-Name == "aps-chefetage"}}} {{{if(&Huntgroup-Name == "aps-chefetage") {...} }}} Folgender Ausdruck gilt nur für Anwender die sich über APs der Chefetage anmelden. || ||!= ||Negierung von == ||{{{Huntgroup-Name != "aps-chefetage"}}} Folgender Ausdruck gilt nur für Anwender die sich nicht über APs der Chefetage anmelden. || ||ok ||Die Authentisierung ist abgeschlossen. Sagt nichts darüber aus, ob der Benutzer sich anmelden darf. Dies wird mit "Auth-Type := Accept" oder "Auth-Type := Reject" ausgedrückt. "ok" kann sowohl eigenständiger Ausdruck als auch Rückgabewert eines Moduls sein. || || ||if(...) {...} ||Bedingte Verzweigung wie bei anderen Programmiersprachen. ||{{{if (&User-Name == 'bob') {...} }}} Falls der Benutzername "bob" ist, ... || Im Folgenden wird nur auf Dateien eingegangen, die für Änderungen vorgesehen sind. [[Anker(RADIUSZertifikate)]] == Zertifikate === Als Basis setzt FreeRADIUS auf eine funktionierende Zertifikatskette. Teil der Installation sind daher Skripte für eine lokale Certification Authority (CA) ('''/etc/freeradius/3.0/certs'''). Zur Verwaltung wird über ein [:Makefile:] auf [wikipedia:OpenSSL:] zurückgegriffen. Alternativ kann man aber auch auf eine bereits bestehende CA wechseln (wie im Artikel [:CA:] beschrieben). Die Standardkonfiguration verwendet selbstsignierte Dummy-Zertifikate unter dem Namen '''snakeoil'''. Diese sollten so schnell wie möglich durch gültige Server-Zertifikate ersetzt werden. Als erstes müssen die Konfigurationsdateien '''ca.cnf''' und '''server.cnf''' angepasst werden. '''/etc/freeradius/3.0/certs/ca.cnf''' {{{ ... [ req ] input_password = output_password = ... [certificate_authority] countryName = DE stateOrProvinceName = Berlin localityName = Berlin organizationName = Radius-Beispiel emailAddress = admin@example.org commonName = "Radius Beispiel CA" ... }}} '''/etc/freeradius/3.0/certs/server.cnf''' {{{ ... [ req ] input_password = output_password = ... [server] countryName = DE stateOrProvinceName = Berlin localityName = Berlin organizationName = Radius-Beispiel emailAddress = admin@example.org commonName = "Radius Beispiel Server" ... }}} {{{#!vorlage Befehl cd /etc/freeradius/3.0/certs sudo openssl rand -out .rand 2048 sudo make ca sudo make server }}} Anschließend muss die Konfiguration in '''mods-enabled/eap''' entsprechend angepasst und FreeRADIUS neu gestartet werden. '''/etc/freeradius/3.0/mods-enabled/eap''' {{{ ... tls-config tls-common { private_key_password = private_key_file = /etc/freeradius/3.0/certs/server.key certificate_file = /etc/freeradius/3.0/certs/server.pem ca_file = /etc/freeradius/3.0/certs/ca.pem ... }}} {{{#!vorlage Befehl sudo systemctl restart freeradius }}} Will man auf Client-Zertifikate für die Authentifizierung zurückgreifen, muss auch für diese jeweils ein Client-Zertifikat erzeugt werden. Auf einem Client müssen dann das CA-Zertifikat, Client-Zertifikat und der private Client-Schlüssel hinterlegt werden. '''/etc/freeradius/3.0/certs/client.cnf''' {{{ ... [ req ] input_password = output_password = ... [client] countryName = DE stateOrProvinceName = Berlin localityName = Berlin organizationName = Radius-Beispiel emailAddress = max.mustermann@example.org commonName = max.mustermann@example.org ... }}} {{{#!vorlage Befehl sudo make client }}} Privater und öffentlicher Schlüssel des Clients liegen dann in der Datei '''/etc/freeradius/3.0/certs/max.mustermann@example.org.pem'''. == Virtuelle Server (sites-enabled/default, sites-enabled/inner-tunnel) == Ähnlich wie der Apache-Webserver unterstützt auch FreeRADIUS mehrere „virtuelle“ Server. Die Idee dahinter ist, für unterschiedliche Authenticators verschiedene Konfigurationen anzuwenden. So kann für WLAN die Authentisierung über MySQL erfolgen, während Switche die Benutzer per LDAP authentisieren. Jeder virtuelle Server muss allerdings auf einem anderen UDP-Port lauschen (Standard-Port ist UDP/1812). Nach der Installation sind zwei virtuelle Server eingerichtet: '''default''' und '''inner-tunnel'''. In Abhängigkeit von der aktuellen Phase im Anmeldeprozess wird der Default-Tunnel (Phase 1, EAP) oder Inner-Tunnel (Phase 2, TLS/TTLS) genutzt. Alle Konfigurationsdateien in '''sites-enabled''' sind dabei in folgende Bereiche unterteilt, die der Reihe nach abgearbeitet werden: * ''"authorize"'': Erster Einstiegspunkt der den Request nach möglichen Authentisierungsverfahren untersucht. Die [https://freeradius.org/modules/ eingetragenen Module] {en} werden von oben nach unten abgearbeitet. Module können sich untereinander beeinflussen, indem sie Attribute im Request setzen. In komplexeren Fällen werden neue Attribute hinzugefügt. Erkennt ein Modul dass es für den Request zuständig ist, wird ein entsprechender Wert im Attrbut Auth-Type gespeichert. Ist kein Modul zuständig, wird bereits hier das Attribut Auth-Type auf REJECT gesetzt und die Authentisierung abgebrochen. Alternativ kann der Client selbst einen Auth-Type anfordern, z.B. EAP-TTLS. Wird ein Auth-Type angefordert, der nicht angeboten wird, führt dies zu einem REJECT. * ''"authenticate"'': Hier sollte bereits das Attribut Auth-Type im Request gesetzt sein. Das entsprechende Modul entscheidet dann anhand weiterer Attribute (Cleartext-Password, etc), ob der Request akzeptiert oder abgelehnt wird. * ''"post-auth"'': In diesem Abschnitt können nachträgliche Kriterien wie zum Beispiel die Gruppenzugehörigkeit überprüft werden. In der Standardkonfiguration sind bereits alle gängigen Module in der richtigen Reihenfolge konfiguriert, inklusive [#RADIUSUsers lokale Benutzer], [#RADIUSLDAP LDAP] und MySQL. Für einfache Installationen besteht also erstmal kein Bedard den virtuellen Server anzupassen. == Authenticators (clients.conf) == Aus Sicht des RADIUS-Servers sind nicht die Endgeräte (Supplicants) die Clients, sondern die NAS-Geräte (Authenticators). In der Datei '''clients.conf''' werden daher die IP-Adressen aller Switche, APs, etc. eingetragen, die auf den RADIUS-Server zugreifen dürfen. Außerdem wird hier noch das gemeinsame "Secret" hinterlegt (muss auch auf dem NAS-Gerät konfiguriert werden), und ob ein Message-Authenticator verwendet wird (sollte nur bei älteren NAS-Geräten deaktiviert werden). '''/etc/freeradius/3.0/clients.conf''' {{{ ... client switch_123 { ipaddr = 192.168.1.23 secret = testing123 require_message_authenticator = yes } ... }}} [[Anker(RADIUSUsers)]] == Lokale Benutzer (users) == Diese Datei erfüllt zwei Aufgaben. Zum einen können hier direkt Benutzerkonten hinterlegt werden. Dabei handelt es sich um einfache Benutzername/Passwort-Kombinationen, wobei das Passwort im Klartext vorliegen muss. Zusätzlich können hier weitere Attribute eingetragen werden, die aber nur für komplexere Einsatzzwecke sinnvoll sind. Beispiele sind in der Datei als Kommentar hinterlegt. {{{ mustermann Cleartext-Password := "12345" Reply-Message := "Hallo %{User-Name}" }}} Die zweite Aufgabe wird über einen oder mehrere „DEFAULT“-Einträge erfüllt. Diese filtern Benutzer nach bestimmten Attributen, und setzen dann selbst ein oder mehrere Attribute. Am gebräuchlichsten ist hier das Setzen des Attributs "Auth-Type", über das eine Authentifizierung akzeptiert oder abgelehnt wird. Nur der erste zutreffende "DEFAULT"-Eintrag wird angewendet, es sei denn dass Attribut "Fall-Through = Yes" ist gesetzt. Benutzer, die schon über andere Module autorisiert wurden, können hier nachträglich abgelehnt werden. In folgendem Beispiel werden alle Anfragen darauf überprüft, ob der Benutzer der Gruppe „disabled“ angehört. Falls dies der Fall ist, wird der Auth-Type auf "Reject" gesetzt und die Authentifizierung abgelehnt. Da das Attribut "Fall-Through" aktiviert ist, endet die Verarbeitung der Anfrage allerdings nicht sofort, sondern wird mit dem nächsten "DEFAULT"-Eintrag fortgesetzt. Hier wiederum werden alle Benutzeranfragen von Administratoren akzeptiert, sofern diese über WLAN mit Radius-Authentifizierung gemacht werden (NAS-Port-Type == 19). Damit ist sichergestellt, dass sich Administratoren nicht aus Versehen selbst aussperren. {{{ DEFAULT Group == "disabled", Auth-Type := Reject Reply-Message = "Benutzerkonto ist gesperrt" Fall-Through = Yes DEFAULT Group == "administratoren", NAS-Port-Type == 19, Auth-Type := Accept }}} [[Anker(RADIUSLDAP)]] == LDAP (mods-enabled/ldap) == {{{#!vorlage Paketinstallation freeradius-ldap }}} Neben einfacher Benutzername/Passwort-Anfragen können auch die Gruppenzugehörigkeit oder diverse andere LDAP-Attribute abgefragt werden. Im Paket '''freeradius''' ist ein eigenes LDAP-Schema enthalten (Objektklasse '''radiusprofile'''). Dieses wird jedoch nur für erweiterte Funktionen benötigt, z.B. dem Zuweisen eines bestimmten VLANs über das LDAP-Attribut '''radiusTunnelPrivateGroupId'''. Für eine einfache Authentisierung/Autorisierung reicht es in der LDAP-Datenbank dem Benutzer die Standard-Objektklasse '''posixAccount''' oder '''inetOrgPerson''' zuzuordnen. Genutzt werden dann nur die LDAP-Attribute "uid" (Benutzername) und "userPassword" (Passwort). Das FreeRADIUS-Modul verwendet in der Standardkonfiguration für den Zugriff auf das LDAP-Verzeichnis den Benutzernamen und das Passwort aus dem RADIUS-Request (falls das Passwort im Klartext an den RADIUS-Server übertragen wird, z.B. bei EAP-TTLS). Ein zusätzlicher privilegierter LDAP-Account für das Auslesen des Benutzerpassworts aus der LDAP-Datenbank ist daher erstmal nicht notwendig. Die wichtigesten Einstellungen in der Konfigurationsdatei '''./mods-enabled/ldap''' (TLS-verschlüsselter Zugriff auf den LDAP-Server über Port 636 ohne StartTLS): {{{ ldap { server = "ldaps://ldap.example.com" port = 636 basedn = "dc=example,dc=com" user { base_dn = "${..base_dn}" filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" } group { base_dn = "${..base_dn}" #filter = '(objectClass=posixGroup)' scope = 'sub' name_attribute = cn membership_filter = "(&(objectClass=groupOfNames)(member=%{control:Ldap-UserDn}))" membership_attribute = 'memberOf' } tls { start_tls = no ca_file = /etc/ssl/certs/ca-ldap.pem } } }}} Die LDAP-Gruppe kann wie folgt in der Konfigurationsdatei '''users''' verwendet werden: {{{ DEFAULT Ldap-Group != "Wireless", Auth-Type := Reject }}} == NAS-Gruppen (huntgroups) == Huntgroups dienen dazu, NAS-Geräte / Switche nach gewissen Eigenschaften zu gruppieren, z.B. IP-Adressen. Im späteren Verlauf kann über das Attribut „Huntgroup-Name“ auf diese Gruppe zugegriffen werden. Man kann damit beispielsweise in der Konfigurationsdatei '''users''' festlegen, dass sich Besucher nur über Switche im Konferenzraum einloggen dürfen. {{{ DEFAULT Ldap-Group == "besucher", Huntgroup-Name != "konferenzraum", Auth-Type := Reject }}} Im folgenden Beispiel wird eine NAS-Gruppe mit dem Namen "konferenzraum" in der Konfigurationsdatei '''huntgroups''' definiert. Die Angabe des NAS-Ports ist dabei optional und definiert für Switche den phys. Port / Buchse über den der Supplicant angeschlossen ist. Bei APs macht die Angabe des NAS-Ports keinen Sinn. {{{ konferenzraum NAS-IP-Address == 192.168.3.2, NAS-Port == 8 konferenzraum NAS-IP-Address == 192.168.2.1, NAS-Port == 0-7 konferenzraum NAS-IP-Address == 192.168.1.1, NAS-Port < 23 }}} Zur Identifikation des phys. Switch-Ports dienen die EAP-Attribute NAS-Port-Id und NAS-Port. Beide sind optional, müssen also nicht unbedingt vorhanden sein. Während NAS-Port-Id eine frei definierbare Zeichenkette enthält, ist NAS-Port eine Zahl. Beides kann von der tatsächlichen phys. Port-Nummerierung abweichen (s. [https://wiki.freeradius.org/glossary/NAS-Port] {en}). Ob die Attribute vorhanden sind, und welchen Wert sie enthalten, ist herstellerspezifisch, und kann bei Switchen der Enterprise-Klasse sogar konfiguriert werden. Hier hilft ein kleiner Test um die tatsächlichen Werte festzustellen. Bei einfachen, nicht zusammen geschalteten Switchen dürften aber beide Attribute denselben Wert enthalten, nämlich die Port-Nummer die auch auf dem Gerät zu lesen ist. = Testen = Leider wird mit den FreeRADIUS-Paketen kein Test-Client mitgeliefert, der verschlüsselte TLS-Verbindungen oder Client-Zertifikate unterstützt (EAP-TTLS, EAP-TLS). Dazu gibt es aber im Quellcode des Pakets [:WLAN/wpa_supplicant:wpa_supplicant] das Programm '''eapol_test'''. Den Quellcode von '''wpa_supplicant''' übersetzt man wie folgt: {{{#!vorlage Befehl tar -xzvf wpa_supplicant-2.6.tar.gz cd wpa_supplicant-2.6/wpa_supplicant make all make eapol_test }}} Hat man vorher noch alle erforderlichen Abhängigkeiten, die zum Kompilieren notwendig sind, installiert, liegt jetzt im aktuellen Verzeichnis das Kommandozeilenprogramm '''eapol_test''', das z.B. nach '''/usr/local/sbin/''' kopiert wird. {{{#!vorlage Befehl eapol_test -c eapol_test.conf -a 192.168.0.10 -p 1812 -s secret }}} Die Konfigurationsdatei '''eapol_test.conf''' sieht für EAP-TTLS wie folgt aus: {{{ network={ ssid="example" key_mgmt=WPA-EAP eap=TTLS identity="mustermann" anonymous_identity="anonymous" password="strenggeheim" phase2="auth=PAP" ca_cert="ca.crt" } }}} Die Ausgabe ist sehr umfangreich, und endet bei erfolgreicher Authentisierung mit: {{{ ... MPPE keys OK: 1 mismatch: 0 SUCCESS }}} = Problembehebung = == Logging == Geloggt wird in den Standardeinstellungen nach '''/var/log/freeradius/radius.log'''. Um dort auch Einträge für alle Authentisierungsversuche zu erhalten, muss in der '''radiusd.conf''' folgender Eintrag angepasst werden: {{{ log { ... auth = yes auth_badpass = no auth_goodpass = no ... } }}} Das Loggen das Passworts (bei erfolgreicher oder erfolgloser Authentisierung) sollte nur in Absprache mit den Benutzern erfolgen. Anschließend wird der laufende FreeRADIUS-Prozess über die geänderte Konfigurationsdatei informiert: {{{ sudo killall -s HUP freeradius }}} == Debug-Meldungen ausgeben == Kann eine Fehlerquelle nicht sofort ausfindig gemacht werden, bietet der FreeRADIUS-Server einen Debug-Modus an. Die Standardmethode zum Analysieren der Debug-Meldungen ist das Starten des FreeRADIUS-Servers im Debug-Modus. Dazu muss zunächst ein eventuell bereits laufender FreeRADIUS-Prozess gestoppt werden, und anschließend der FreeRADIUS-Server mit folgenden Parametern manuell gestartet werden: {{{ sudo freeradius -xX }}} Alle Debug-Meldungen werden auf der Standardausgabe ausgegeben. Wegen der großen Menge an Informationen empfiehlt es sich daher die Standardausgabe zusätzlich in eine Log-Datei zu schreiben, die später ausgewertet werden kann: {{{ sudo freeradius -xX | tee -a /tmp/freeradius.log }}} == Hardware == Einige Switche (insbesondere ältere Modelle) unterstützen laut Dokumentation beispielsweise nur EAP-MD5 als Authentisierungsverfahren. Diese Einschränkung muss allerdings nicht unbedingt stimmen. Wie weiter oben in der Grafik zum EAP-Protokoll zu sehen ist, kümmert sich ein Authenticator (also der Switch) nur um das Übersetzen des 802.1X-Protokolls in das RADIUS-Protokoll. Betroffen davon ist das direkt darüber liegende EAP-Protokoll. Welche Verfahren innerhalb des EAP-Protokolls zum Einsatz kommen, sollte dabei aber keine Rolle spielen. Die Chancen dass ein Switch, der laut Dokumentation lediglich EAP-MD5 unterstützt, auch noch weitere Authentisierungsverfahren wie EAP-TLS oder EAP-TTLS unterstützt, stehen daher ziemlich gut. Um ganz sicher zu sein, sollte man sich aber letztendlich beim Hersteller-Support erkundigen oder einen Praxistest durchführen. Auch günstige WLAN-Router für das Heimnetzwerk werben in der Produktbeschreibung immer häufiger mit RADIUS-Unterstützung. Hier sollte man sich aber vorher erkundigen, ob dies wirklich für alle konfigurierbaren Netze gilt. Es gibt beispielsweise WLAN-Router, die nur für das Standard-Netz im 2,4 und 5 GHz-Bereich eine RADIUS-Authentisierung ermöglichen. Die zusätzlich konfigurierbaren Gästenetze sind auf die herkömmliche WPA2-Personal- bzw. WPA2-PSK-Authentisierung beschränkt. Für die LAN-Ports gibt es dann ebenfalls kein 802.1X. = Links = * [http://freeradius.org] {en} - FreeRADIUS-Homepage * [wikipedia:RADIUS:] – Wikipedia * [https://w1.fi/wpa_supplicant] {en} - Quellcode für wpa_supplicant * [:Serverdienste:] {Übersicht} – Übersichtsseite #tag: Netzwerk, System, Sicherheit, Server, Internet