Im Umfeld großer Netzwerke¶

RADIUS-Authentisierung wird häufig im Umfeld großer Netzwerke eingesetzt. Durch die Unterstützung unterschiedlicher Backend-Datenbanken können beliebige Organisations-Strukturen im Netzwerk abgebildet werden. So können Clients unabhängig von Standort oder Verbindungstechnik (Kabel, WLAN, VPN) immer ins gleiche Zielnetz/VLAN „gebeamt“ werden bzw. die Zugriffe verwaltet werden.

Zusätzlich erzeugt 802.1x einen Sicherheitsvorteil: Switches öffnen nicht mehr jedem Client ihre Netzwerkports. Nur noch „bekannte“ Clients bekommen Zugang zum Netz. Auch das Abstecken/Ersetzen eines validen Clients durch einen unbekannten Clients ist nicht mehr möglich. Voraussetzung ist, dass alle Switches richtig konfiguriert sind und alle Endgeräte 802.1x unterstützen.

Sonderfall WLAN¶

Die bisher genannten Eigenschaften kommen eher im Umfeld von größeren Firmennetzen zum Tragen. Das Zusammenspiel zwischen (Free)RADIUS-Server und WLAN-AP kann aber auch in Klein- bzw Heimnetzwerken echte Sicherheitsvorteile bieten. Betreibt man ein WLAN, hat man – unabhängig vom Verschlüsselungsalgorithmus – immer das Problem des ersten Schlüsselaustauschs: Sowohl WEP, WPA als auch WPA2 setzen auf symmetrische (schnelle) Verschlüsselungsalgorithmen. Der dafür benötigte Schlüssel wird vom AP „zufällig“ generiert. Zum Austausch des Schlüssels kommt dabei das sogenannte PSK-Verfahren (PreSharedKey) zum Einsatz: Ein Client initiiert einen Handshake verschlüsselt mit dem PSK und bekommt vom AP den symmetrischen Schlüssel als Ergebnis.

Das PSK-Verfahren hat mehrere Sicherheitsprobleme:

• Der PSK ist das Geheimnis, auf dem die Sicherheit des Netzwerkes basiert. 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 Verlust/Diebstahl eines Gerätes muss der PSK auf allen Geräten geändert werden. Das kann mit wachsender Anzahl von Endgeräten beliebig schwierig werden.

• Beim Verfahren ist der Handshake vom Client zum AP der Schwachpunkt: Ein Angreifer, der diesen mitschneidet, kennt sowohl den Klar- (aus dem Protokoll) als auch den chiffrierten Text. Daraus lässt sich der PSK errechnen. Es ist nur eine Frage der Zeit oder des Geldes (beim Einsatz von Cloud-Diensten), bis der PSK im Klartext vorliegt.

Beim Einsatz des 802.1x-Protokolles muss an allen Clients ein Root-Zertifikat hinterlegt werden. Der RADIUS-Server verfügt selber über ein Zertifikat, das von der Root-CA signiert ist. Beim initialen Handshake wird mit Hilfe dieser Zertifikate eine TLS-Verbindung „aufgebaut“. Ein Angreifer muss nun anstatt eines PSKs einen RSA-Private-Key errechnen. Damit wird die Zeitspanne bis zum „Bruch“ von „in wenigen Wochen/Tagen“ auf „sehr lange“ erhöht.

Es obliegt dem Administrator, wie der Client autorisiert wird. Im einfachsten Fall wird am Client ein Client-Zertifikat hinterlegt, das ebenfalls von der Root-CA signiert ist. Der RADIUS-Server überprüft die Gültigkeit des Zertifikates und gibt den Client dann frei. Prinzipbedingt können Client und Server aber nur überprüfen, ob ein Zertifikat korrekt signiert ist – nicht aber, ob das Zertifikat zum Server/Client passt. So ist es möglich, allen Clients mit nur einem Zertifikat Zugriff auf das Netzwerk zu geben.

Besser ist es jedoch, jedem Client ein eigenes Zertifikat auszustellen. Bei Verlust eines Gerätes muss nur das entsprechende Zertifikat im RADIUS-Server gesperrt werden und nicht auf allen Clients ein neues Zertifikat installiert werden. Noch flexibler wird das Verfahren, wenn weitere Verfahren wie PAP, CHAP, MSCHAP usw. zum Einsatz kommen.

sites-enabled/default|inner-tunnel¶

Standardmäßig sind zwei „Virtuelle“ Server eingerichtet: Default und Inner-Tunnel. In Abhängigkeit vom gewählten Modus des Clients wird der Default (TLS) oder Inner-Tunnel (TTLS) genutzt. Die Konfiguration ist in folgende Kategorien unterteilt:

• "authorize": Erster „echter“ Einstiegspunkt. Die eingetragenen Module werden von oben nach unten abgearbeitet. Die Module können sich untereinander beeinflussen, indem sie Umgebungsparameter setzen. Im einfachsten Fall wird der Auth-Type gesetzt (REJECT,ACCEPT, usw), in komplexeren Fällen werden neue dynamische Parameter hinzugefügt. Die Reihenfolge ist dabei entscheidend. Parameter sind nur verfügbar, wenn das entsprechende Modul durchlaufen wurde.

• "authenticate": Während der erfolgreichen Authorize-Phase wird ein Auth-Type gesetzt oder der Client fordert selber einen Auth-Type an. Wird ein Auth-Type angefordert, der nicht angeboten wird, führt das zu einem REJECT. Das Auth-Module entscheidet anhand eines Identifikationsmerkmales (Password, Geheimnis, etc), ob der Client in das Netzwerk gelassen werden darf.

• "post-auth": In diesen Sektionen können nachträgliche Überprüfungen wie zum Beispiel die Prüfung der Gruppenzugehörigkeit durchgeführt werden.

Eine Beispieldatei für eine Datei im Ordner /etc/freeradius/sites-enabled oder /etc/freeradius/sites-avaible. Das Beispiel ist um Kommentare bereinigt und enthält nur die wesentlichen Sektionen:

authorize {
	preprocess
	auth_log
	chap
	mschap
#	digest
	eap {
		ok = return
	}
	unix
	ldap
        files
  #	sql
        expiration
	logintime
	pap
}

authenticate {
	Auth-Type PAP {
		pap
	}

	Auth-Type CHAP {
		chap
	}

	Auth-Type MS-CHAP {
		mschap
	}
 
	unix

	Auth-Type LDAP {
		ldap
	}
	eap
}

...

post-auth {
  if (LDAPGroup == "forbidden") {
    nok
  }

  exec
  Post-Auth-Type REJECT {
    attr_filter.access_reject
  }
}

module/ldap¶

Neben einfacher „User-Existiert“-Anfragen können auch die Gruppenzugehörigkeit oder diverse Attribute abgefragt werden. Es wird auch ein eigenes LDAP-Schema angeboten; dies wird jedoch nur für erweiterte Parameterzuweisung benötigt. Für eine einfache Autorisierung/Authentisierung reicht das Standard-PosixAccount-Schema.

Das Modul benötigt einen lesenden Zugang auf das LDAP-Verzeichnis, ggf. auch auf die Secrets für diverse Auth-Types (MSCHAP).

ldap {
        #
        #  Note that this needs to match the name in the LDAP
        #  server certificate, if you're using ldaps.
        server = "ldap.example.com"
        identity = "cn=radius,dc=example,dc=com"
        password = "very-secret-password"
        basedn = "dc=example,dc=com"
        filter = "(&(cn=%{%{Stripped-User-Name}:-%{User-Name}})(objectClass=posixAccount)))"
        ldap_connections_number = 5
        timeout = 4
        net_timeout = 1
        tls {
                start_tls = no
        }
        dictionary_mapping = ${confdir}/ldap.attrmap
        edir_account_policy_check = no
        keepalive {
                idle = 60
                probes = 3
                interval = 3
        }
}

Zusätzlich bietet das Modul auch den Support für das Abfragen der „Usergruppen“.

        groupname_attribute = cn
        groupmembership_filter = "(objectClass=posixGroup)(memberUid=%{%{Stripped-User-Name}:-%{User-Name}})"

Im Code kann man die LDAP-Gruppe wie folgt einsetzen:

DEFAULT Ldap-Group != "Wireless", Auth-Type := Reject

module/krb5¶

Beim Kerberos handelt es sich nur um ein Authentisierung-Modul. Ein Benutzer muss erst über ein anderes Modul autorisiert werden, um anschließend über Kerberos authentisiert werden zu können.

Für den Betrieb wird eine eigene Keytab samt einem Hostkey benötigt.

Beispiel für /etc/freeradius/modules/krb5

krb5 {
        keytab = /etc/freeradius/keytab 
        service_principal = radius/radius.example.com
}

Anschließend kann das Modul aktiviert und vom Client angefordert werden. Man kann allerdings auch eine Ersetzung vornehmen. So kann man z.B. PAP so umkonfigurieren, dass Kerberos genutzt wird. Prinzipbedingt funktioniert das nur mit Verfahren, bei dem FreeRADIUS das Password/Secret nicht verschlüsselt oder es im Klartext vorliegen muss. MSCHAP oder ähnliches lassen sich so nicht anbinden.

authenticate {
        # PAP auf krb5 umleiten.
        Auth-Type PAP {
                krb5
        }
        # Einen eigenen Auth-Type anlegen.
        Auth-Type Kerberos {
                krb5
        }
}

huntgroups¶

Diese Datei wird vom Modul preprocess eingelesen. Standardmäßig erfolgt dies am Beginn der Verarbeitung. Huntgroups dienen dazu, NAS-Geräte nach gewissen Eigenschaften zu gruppieren. Im späteren Verlauf kann über den Select-Operator „Huntgroup-Name“ auf diese Information zugegriffen werden.

access-points   NAS-IP-Address == 192.168.3.2, NAS-Port == 1
access-points   NAS-IP-Address == 192.168.2.1, NAS-Port == 2
access-points   NAS-IP-Address == 192.168.1.1, NAS-Port == 3

users¶

Diese Datei erfüllt zwei Aufgaben. Zum einen können hier direkt Benutzer-Informationen hinterlegt werden. Diese Angaben können einfache Login-Password Kombinationen oder komplexe Kombinationen wie Protokoll-Parameter, Auth-Methoden usw. sein. Beispiele sind in der Datei hinterlegt.

Die zweite Aufgabe wird über den „DEFAULT“-User erfüllt. Dieser „matched“ auf alle Benutzer, auch solche, die schon über andere Module autorisiert wurden. So kann man einfache „Regeln“ definieren. Alternativ kann man das etwas komplizierter in der Post-Auth-Sektion in der Default oder Inner-Tunnel-Datei realisieren.

In folgendem Beispiel werden alle Anfragen, die über die APs angenommen wurden, darauf überprüft, ob der zugeordnete Benutzer der LDAP-Group „Wireless“ angehören. Falls dies nicht der Fall ist, wird der Auth-Type auf EAP (Zertifikate) gesetzt. So haben nur Geräte mit gültigen Client-Zertifikaten oder der richtigen Gruppen-Zuordnung Zugriff auf das WLAN.

DEFAULT Huntgroup-Name == access-points, Ldap-Group != "Wireless", Auth-Type := eap