ubuntuusers.de

FreeRADIUS

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte teste diesen Artikel für eine Ubuntu-Version, welche aktuell unterstützt wird. Dazu sind die Hinweise zum Testen von Artikeln zu beachten.

Artikel für fortgeschrittene Anwender

Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

Wiki/Icons/service.png Der Server-Dienst FreeRADIUS 🇬🇧 ist laut eigener Angabe „der am häufigsten genutzte RADIUS-Server der Welt“ und unterstützt neben dem EAP- natürlich auch das RADIUS-Protokoll. Im Kern geht es beim "Remote Authentication Dial-In User Service" um das sogenannte AAA:

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

802.11X-Prinzip.png
Übersicht 802.1X (Bildquelle)

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

radius-protocols.png

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

Einsatzgebiete

⚓︎

WLAN

Möchte man Daten über ein WLAN übertragen, hat man immer das Problem des Schlüsselaustauschs. 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 (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.

  2. Aus dem PSK wird der PTK auf dem AP und auf dem Client generiert. Auch der PTK wird selbst nicht über das Netzwerk übertragen.

  3. 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. 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 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 Zertifikate).

Festnetz

RADIUS-Authentisierung wird auch häufig in 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 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.

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.

Gängige EAP-Verfahren zur Authentisierung
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 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.

⚓︎

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 (OpenLDAP, 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:

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

  • freeradius

Befehl zum Installieren der Pakete:

sudo apt-get install freeradius 

Oder mit apturl installieren, Link: apt://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):

  • freeradius-ldap

  • freeradius-krb5

  • freeradius-mysql

  • freeradius-postgresql

  • freeradius-redis

Befehl zum Installieren der Pakete:

sudo apt-get install freeradius-ldap freeradius-krb5 freeradius-mysql freeradius-postgresql freeradius-redis 

Oder mit apturl installieren, Link: apt://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.

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.

Wichtige Konfigurationsdateien und -Verzeichnisse
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: unlang 🇬🇧. 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:

Elemente der Sprache "unlang"
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.

⚓︎

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 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      = <Passwort für privaten CA-Schlüssel>
output_password     = <Passwort für privaten CA-Schlüssel>
...
[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      = <Passwort für privaten Server-Schlüssel>
output_password     = <Passwort für privaten Server-Schlüssel>
...
[server]
countryName         = DE
stateOrProvinceName = Berlin
localityName        = Berlin
organizationName    = Radius-Beispiel
emailAddress        = admin@example.org
commonName          = "Radius Beispiel Server"
...
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 = <Passwort für privaten Server-Schlüssel>
        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
...
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      = <Passwort für privaten Client-Schlüssel>
output_password     = <Passwort für privaten Client-Schlüssel>
...
[client]
countryName         = DE
stateOrProvinceName = Berlin
localityName        = Berlin
organizationName    = Radius-Beispiel
emailAddress        = max.mustermann@example.org
commonName          = max.mustermann@example.org
...
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 eingetragenen Module 🇬🇧 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 lokale Benutzer, 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
}
...

⚓︎

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

⚓︎

LDAP (mods-enabled/ldap)

  • freeradius-ldap

Befehl zum Installieren der Pakete:

sudo apt-get install freeradius-ldap 

Oder mit apturl installieren, Link: apt://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 🇬🇧). 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 wpa_supplicant das Programm eapol_test. Den Quellcode von wpa_supplicant übersetzt man wie folgt:

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.

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.

Diese Revision wurde am 28. März 2020 15:56 von Heinrich_Schwietering erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Sicherheit, Server, System, Netzwerk, Internet, ungetestet