freeradius

Wie man sein WLAN-Netzwerk mit Freeradius absichern kann

An unserer Schule haben wir ein offenes WLAN mit einem Captive Portal sowie ein weiteres WLAN-Netz (WPA Enterprise, 802.1X), welches nur für Lehrkräfte gedacht ist. Für beide Netze nutzen wir einen RADIUS-Server für die Authentifizierung. Freeradius ist der am weitesten verbreitete OpenSource RADIUS-Server, der auch bei uns zum Einsatz kommt. In diesem Artikel wollen wir einen Freeradius-Server und Zertifikate für eine verschlüsselte Verbindung einrichten. Im Besonderen möchte ich auf die Anbindung an Linuxmuster 6.2 eingehen und die Authentifizierung mit einem LDAP-Server beschreiben.

Ein RADIUS-Server kümmert sich im Allgemeinen um 3 Dinge: Authentifizierung, Autorisierung und Accounting (oft auch als Triple-A oder AAA bezeichnet). Wir werden uns nur mit den ersten beiden „As“ beschäftigen, d.h. ob die Zugangsdaten korrekt sind und ob der Benutzer berechtigt ist, einen Zugang zu erhalten (zum WLAN z.B.).

Installation von freeradius

Die Installation führen wir auf einer aktuellen Linux-Installation (hier Ubuntu 18.04 Server) durch, z.B. in einem LXD Container oder einer virtuellen Maschine.

$ apt install freeradius freeradius-ldap freeradius-utils

Konfiguration

Grundkonfiguration

Um unseren freeradius Server zu testen, kommentieren wir folgende Zeile in /etc/freeradius/3.0/users aus oder fügen sie zu Beginn der Datei ein:

# Das Kommentarzeichen "#" vor dieser Zeile entfernen
steve Cleartext-Password := "testing"

Standardmäßig sollte in der Datei /etc/freeradius/3.0/clients.conf der localhost als Client eingerichtet sein:

client localhost {
  ipaddr = 127.0.0.1
  secret = testing123
}

Nun können wir einen ersten Test durchführen. Dazu stoppen wir den freeradius-Service und starten ihn manuell im Debug-Modus neu:

$ systemctl stop freeradius.service
$ freeradius -X
...
Ready to process request

Wichtig ist, dass am Ende „Ready to process requests“ steht.

Überprüfen der Grundkonfiguration

Als nächstes überprüfen wir, ob unser Test-Benutzer „Steve“ sich am RADIUS-Server anmelden kann (am besten in einem neuen/zweiten Terminal):

$ radtest steve testing 127.0.0.1 10 testing123

Falls alles passt, sollten wir folgende Antwort bekommen:

Sent Access-Request Id 234 from 0.0.0.0:40302 to 127.0.0.1:1812 length 75
    User-Name = "steve"
    User-Password = "testing"
    NAS-IP-Address = 10.18.10.60
    NAS-Port = 10
    Message-Authenticator = 0x00
    Cleartext-Password = "testing"
Received Access-Accept Id 234 from 127.0.0.1:1812 to 0.0.0.0:0 length 20

Wichtig ist, dass wir ein „Received Access-Accept“ bekommen. Hat diese Anfrage geklappt ist der freeradius-Server grundlegend eingerichtet und die folgenden Authentifizierungsverfahren sollten ohne weitere Probleme klappen:

  • PAP
  • CHAP
  • MS-CHAPv1
  • MS-CHAPv2
  • PEAP
  • EAP-TTLS
  • EAP-GTC
  • EAP-MD5

Diese Verfahren sind unterschiedliche Protokolle, die verschieden „sicher“ sind. Alle verwenden einen Benutzernamen und Passwort zur Authentifizierung. Die Bedeutung der (P)EAP Verfahren kann man hier nachlesen. MS-CHAPv1 und v2 sind Verfahren aus dem Hause Microsoft.

Hinweis: Die Zeile mit unserem Benutzer „Steve“ sollten wir jetzt wieder kommentieren oder löschen!

Wir werden im Folgenden das LDAP-Modul konfigurieren und neue Zertifikate für EAP-TTLS erstellen.

LDAP Anbindung einrichten

Die Konfiguration des LDAP-Servers nehmen wir in der Datei /etc/freeradius/3.0/mods-enabled/ldap vor. Falls diese Datei nicht existiert, müssen wir vorher noch einen symbolischen Link erstellen.

$ cd /etc/freeradius/3.0/mods-enabled/
$ ln -s ../mods-available/ldap ./

Ziemlich an Anfang der Datei konfigurieren wir unseren LDAP-Server:

server = "ldaps://linuxmuster.internal.example.com"
identity = "cn=admin,dc=internal,dc=example,dc=com"
password = superSecretPassword
base_dn = "ou=accounts,dc=internal,dc=example,dc=com"

...

group {
    ...
    membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))"
    ...
}

Es muss sichergestellt sein, dass alle nötigen Ports für die Kommunikation zwischen dem RADIUS und LDAP-Server offen sind.

Hinweis: Wenn man Freeradius 3.0 zusammen mit linuxmuster.net v6.2 verwenden möchte, müssen noch folgende Zeilen angepasst werden, damit die Authentifizierung mit Windows klappt (sign…):

update {
            control:Password-With-Header    += 'userPassword'
            control:NT-Password             := 'sambaNTPassword'
            ...
}

LDAP Verbindung testen

Nachdem der LDAP-Server in Freeradius konfiguriert ist, müssen wir ihn einmal neustarten und können anschließend testen, ob sich ein Benutzer aus dem LDAP am RADIUS-Server anmelden kann.

$ systemctl restart freeradius.service
$ radtest testuser password localhost 10 testing123
Sent Access-Request Id 213 from 0.0.0.0:46425 to 127.0.0.1:1812 length 73
    User-Name = "testuser"
    User-Password = "password"
    NAS-IP-Address = 10.18.10.60
    NAS-Port = 10
    Message-Authenticator = 0x00
    Cleartext-Password = "password"
Received Access-Accept Id 213 from 127.0.0.1:1812 to 0.0.0.0:0 length 20

Wenn wir wieder ein „Received Access-Accept“ als Antwort erhalten, klappt die Verbindung zwischen RADIUS und LDAP-Server. Falls es nicht klappt, sollten wir den RADIUS Server manuell starten und schauen, welche Fehler uns der RADIUS-Server ausgibt.

$ systemctl stop freeradius.service 
$ freeradius -X 
... 
Ready to process request

Zertifikate erstellen (für EAP-TTLS)

Standardmäßig verwendet Freeradius sogenannte Snake-Oil-Zertifkate, die natürlich nicht für den produktiven Einsatz gedacht sind. Deshalb erstellen wir in den folgenden Schritten eine neue Root-CA und ein Zertifikat für den Server. Die Zertifikate und die dazugehörigen Konfigurationsdateien befinden sich unter /etc/freeradius/3.0/certs/. Zuerst öffnen wir die Datei ca.cnf und ändern ein paar wenige Einstellungen:

...
[ CA_default ]
...
default_days        = 3650
...
default_md      = sha256
...

[ req ]
....
default_bits        = 2048
input_password      = supersecretandlongpassword
output_password     = supersecretandlongpassword
...

[certificate_authority]
countryName     = US
stateOrProvinceName = My State
localityName        = My Town
organizationName    = My School
emailAddress        = admin@my-school.org
commonName      = "CA Freeradius"
...

Ähnliche Einstellungen nehmen wir nun der Datei server.cnf vor:

...

[ CA_default ]
...
default_days        = 3560
...
default_md      = sha256
...

[ req ]
...
default_bits        = 2048
input_password      = supersecretandlongpassword
output_password     = supersecretandlongpassword

[server]
countryName     = US
stateOrProvinceName = My State
localityName        = My Town
organizationName    = My School
emailAddress        = admin@my-school.org
commonName      = "Freeradius Server Certificate"

Das Passwort muss jetzt auch in der Datei /etc/freeradius/3.0/mods-enabled/eap geändert werden:

tls-config tls-common {
    private_key_password = supersecretandlongpassword
    ...
}

Die Zertifikate erstellen wir mit einem einfachen make:

$ cd /etc/freeradius/3.0/certs/
$ make

EAP-TTLS Anmeldung testen

epol_test kompilieren

radtest unterstützt leider keinen Test für eine EAP-TTLS Authentifizierung. Dazu brauchen wir das Tool eapol_test, welches Teil des wpa_supplicant Pakets ist. Leider wird dieses Tool standardmäßig nicht von wpa_supplicant gebaut, deswegen müssen wir das selbst machen. Wir laden den Quellcode herunter, entpacken ihn und müssen noch einige Abhängigkeiten installieren.

$ wget https://w1.fi/releases/wpa_supplicant-2.7.tar.gz
$ tar -xzvf wpa_supplicant-2.7.tar.gz
$ apt install build-essential pkg-config libnl-3-dev libssl-dev libnl-genl-3-dev
$ cd wpa_supplicant-2.7
$ cp defconfig .config

Danach müssen wir die Datei .config öffnen und die Zeile #CONFIG_EAPOL_TEST=y  finden und das Kommentarzeichen entfernen.

$ nano .config
# Kommentarzeichen "#" entfernen
CONFIG_EAPOL_TEST=y

Mit dem folgenden Befehlen bauen wir nun das Programm und kopieren es noch an die richtige Stelle:

$ make eapol_test
$ cp eapol_test /usr/local/bin

Anmeldung testen

Um EAP-TTLS zu testen, brauchen wir für eapol_test eine kleine Config-Datei, die folgendermaßen aussehen kann:

$ nano eapol_test.conf
network={
        ssid="example"
        key_mgmt=WPA-EAP
        eap=TTLS
        identity="mustermann"
        anonymous_identity="anonymous"
        password="strenggeheim"
        phase2="auth=PAP"
}

Nun können wir eapol_test aufrufen:

$  eapol_test -c eapol_test.conf -a 127.0.0.1 -p 1812 -s testing123

Wenn man am Ende diese Ausgabe erhält, war alles erfolgreich:

MPPE keys OK: 1  mismatch: 0
SUCCESS

Clients einrichten (z.B. Accesspoints)

Bisher haben wir immer nur direkt auf dem RADIUS-Server getestet. Im Normalfall wird die Anfrage für die Authentifizierung aber von einem Accesspoint, Captive Portal oder einem Wireless Controller kommen. Diese müssen auf dem RADIUS-Server als Clients eingerichtet werden. Wir öffnen dazu die Datei /etc/freeradius/3.0/clients.conf und fügen am Ende alle Accesspoints etc. mit ihrer IP und einem Passwort / Secret ein:

$ nano /etc/freeradius/3.0/clients.conf
client AP1 {
    ipaddr = 10.0.0.10
    secret = supersecretsecret
}

Nun kann man auf dem Accesspoint ein WPA Enterprise (802.1X) Netzwerk einrichten und den RADIUS-Server mit seiner IP, den Port (1812) und dem eben festgelegten Passwort/Secret konfigurieren. Nun sollte man sich mit seinem mobilen Gerät im WLAN anmelden können.

Zugang auf bestimmte LDAP Gruppen beschränken

An unserer Schule haben nur Mitarbeiter und Lehrkräfte sowie die Oberstufenschüler Zugang zum WLAN an der Schule. In linuxmuster.net ist das über die Gruppe p_wifi gelöst. Alle, die in dieser Gruppe sind, sollen Zugang bekommen. Bisher ist unser RADIUS-Server aber so konfiguriert, dass jeder Benutzer im LDAP Zugang erhält. Um den Zugang einzuschränken, fügen wir noch folgende Zeilen in der Datei /etc/freeradius/3.0/users hinzu:

DEFAULT Ldap-Group == "cn=p_wifi,ou=groups,dc=internal,dc=example,dc=com"
DEFAULT Auth-Type := Reject
   Reply-Message = "Your are not allowed to access the WLAN!"

Freeradius und linuxmuster.net 6.2

Die Installation von Freeradius für linuxmuster.net 6.2 ist in der Dokumentation beschrieben. Bis auf ein paar wenige Details ist die Konfiguration sehr ähnlich. In Freeradius 2.0 sind die Standardeinstellungen für die Zertifikate nicht mehr zeitgemäß, sodass es zu Verbindungsproblemen mit einigen Clients kommen kann (z.B. mit einem aktuellen macOS). Hier sollte man unbedingt die Vorgaben von Freeradius 3.0 verwenden (siehe oben)!

Unterschiedliche Zugangsbeschränkungen nach WLAN-Netz

An unserer Schule haben wir ein Captive Portal für Gäste und Schüler, sowie ein WPA 802.1X (Enterprise) Netz für Mitarbeiter und Lehrkräfte. Während sich am Captive Portal alle anmelden können, die in der Gruppe p_wifi sind, sollen sie im WPA 802.1X Netzwerk nur Lehrkräfte und Mitarbeiter anmelden dürfen. Die Anfragen vom Captive Portal kommen von einer anderen IP (pfSense) als die für das WPA Enterprise Netzwerk. In der Datei /etc/freeradius/sites-enabled/inner-tunnel haben wir deshalb eine Abfrage eingebaut, die überprüft, von welcher IP die Anfrage kommt und entsprechend entscheidet, ob jemand Zugang bekommt oder nicht:

post-auth {
    ...
    #Only allow Teacher&Staff on WPA 802.1X Teacher and Staff network  
    if (NAS-IP-Address == 10.0.0.10) {
        if (LDAP-Group == "cn=teachers,ou=groups,dc=internal,dc=example,dc=com" || LDAP-Group == "cn=staff,ou=groups,dc=internal,dc=example,dc=com") {
            noop
        } else {
            reject
        }
    }
    ...
}

Fazit

Dieser Artikel beschreibt nur eine von vielen Möglichen Konfigurationen. Ein RADIUS-Server ist komplex, aber dank der guten Standardkonfiguration von Freeradius (v.a. in Version 3) kommt man recht schnell zum Erfolg. Lange Zeit hatten wir nur das Captive Portal im Einsatz und es hat auch gut funktioniert, doch die Benutzerfreundlichkeit und Sicherheit ist mit einem WPA 802.1X (Enterprise) Netzwerk nochmal gestiegen. Ohne den RADIUS-Server wäre das aber nicht möglich gewesen.

Nützliche Links:

8 Comments:

  1. Anonymous

    Hallo,
    ich finde deinen Artikel sehr spannend. Hast du Lust noch zu erzählen, was für Hardware ihr dafür verwendet (z.B. Router).

  2. zefanja

    @Anonymous: Für das Captive Portal nutzen wir pfSense. pfSense ist gleichzeitig auch unser Router/Firewall. Der RADIUS-Server läuft in einer virtuellen Maschine auf unserem Server. Für’s WLAN haben wir einen Cisco Wireless Controller mit entsprechenden Accesspoints. Aber heutzutage kann eigentlich jeder Accesspoint so eingerichtet werden, dass man da auch einen RADIUS-Server konfigurieren kann.

  3. Auch ein Lehrer

    Hallo,
    sehr gute Beschreibung. Ich frage mich trotzdem, ob es eine Möglichkeit gibt, dass unterschiedliche Benutzergruppen auch unterschiedliche Bandbreiten zugewiesen bekommen könnten. Oder geht das überhaupt nicht?

    Viele Grüße aus dem Hessenland

  4. Zoschel

    Hallo, nach langen Suchen bin ich hier endlich fündig geworden, Super Anleitung zu WPA2!!! Schon wäre es noch wenn die Konfiguration Eures LDAP Server beschrieben würde, und auch pfsene mit dem Captive Portal 😀 Ich wöllte das gerne mal Nachbauen. Als Router nutze ich Mikrotik. Danke für die super Anleitung!!

  5. Hans Meier

    Hallo,

    Super Anleitung.
    Bis zum Punkt der testing ausgabe funktioniert so weit auch alles.

    Nach dem Kommando:
    radtest steve testing 127.0.0.1 10 testing123

    Komtm leider nichts.
    Die Ausgabe im Terminal bleibt Schwarz.

    An was kann das liegen?
    Probiere das ganze auf Rasperryan mit RasperryPi4.

  6. Rudi

    Funktioniert das schon, wenn der LDAP-Server keine Klartext-Passwörter hat? Ich glaube irgendwo gelesen zu haben, dass das für diese Methode Voraussetzung ist.

  7. zefanja

    @Rudi: Ich denke, dass es kaum noch LDAPs gibt / geben sollte, die das Passwort im Klartext speichern. Also: Ja, es funktioniert natürlich, wenn die Passwörter verschlüsselt gespeichert werden.

  8. Jürgen

    Hallo Zefanjas,

    Geht das auch unanbhängig von Benutzer und Kennwort mit einem 802.1x Zertifikat?Wäre z. B. sinnvoll um eine WLAN-Verbindung mit einem schuleigenen Windows Client herzustellen, bevor der Benutzer sich an der Domäne anmeldet oder ein WLAN-Profil zu erstellen und zu verteilen, das nicht einfach geteilt werden kann, wie es z. B. Android mit einem PSK per QR-Code erlaubt.

Leave a Reply:

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert