Watchguard SSLVPN 2-Factor mit Google-Authenticator Token

WatchGuard SSLVPN 2-Factor mit Google-Authenticator Token

Zwei-Faktor-Authentisierung ist derzeit stark im Kommen und dies ist eine gute Entwicklung. Eine Zwei-Faktor-Authentisierung baut auf zwei Dinge:

• Something you know
• Something you have

Es werden zum Login also zwei komplett unterschiedliche Dinge benötigt, einmal etwas, das man kennen muss (typischerweise das Passwort), und dann etwas, das man besitzen muss (typischerweise einen Token-Generator). Der Token-Generator erzeugt nun automatisiert zeitabhängige Token, also mehrstellige Ziffern-Folgen, die sich mit der Zeit ändern. Hierfür gibt es bei WatchGuard die Unterstützung von Secure-ID – aber diese Tokens sind umständlich, man muss sie nämlich dabei haben. Also “noch ein Ding rumschleppen”.

Seit einigen Jahren gibt es bei Google die Möglichkeit, mit Google-Authenticator eine Zwei-Faktor-Authentisierungzu aktivieren. Hierbei wird ebenfalls ein “Ding” als Tokengenerator verwendet, nur ist dieses Ding etwas, das man sowieso schon dabei hat: das Smartphone.

Die Idee ist nun, die Token-Erzeugung in eine App auf dem Smartphone auszulagern, somit muß jemand zum Login auf das Google-Konto nicht nur das Passwort kennen, sondern auch das Smartphone besitzen _und_ es freischalten können, um an das Token zu kommen.

Was liegt nun näher, als die WatchGuard mit Google-Authenticator zu vermählen?

Hierzu muss man allerdings ein wenig in die Trickkiste greifen. Das prinzipielle Vorgehen ist:

• Setup eines Linux-Servers als radius-Server mit freeradius
• Setup der Authentifizierung für freeradius mit google-authenticator über PAM
• Setup der Benutzer als lokale Linux-Benutzer mit den entsprechenden Gruppen
• Einrichten des google-authenticator für jeden Benutzer und konfiguration des jeweiligen smartphones
• Konfiguration des freeradius, um die entsprechenden Gruppen zurückzumelden
• Verbinden der Watchguard Firewall mit dem radius-Server

Da es beim WatchGuard SSLVPN-Client keine Möglichkeit gibt, ein token zusätzlich zum Passwort einzugeben, wird ein weiterer Kunstgriff aus der Linux-PAM-Trickkiste verwendet: das Passwort wird einfach zusammengesetzt aus dem Password + dem von der app generierten Token.

Anstelle einem Passwort (z.B. “strenggeheim”) und einem zeitbasiertem Token (z.B. “123456”) muß dann als Passwort “strenggeheim123456” eingegeben werden. Das Google-Authenticator-Modulo für PAM zerlegt das auf der Linuxseite dann passend.

Installation des Linux-Servers mit freeradius

Zunächste wird der Linux-Server installiert. Die folgende Beispiele basieren auf einer ubuntu-16.4-server Installation, ausgewählt bei der Installation war nur “system tools” und “openssh server”!

Installation des freeradius + Google-Authenticator

Leider kann das mitgelieferte libpam-google-authenticator-Paket nicht verwendet werden, es unterstützt nicht alle benötigten PAM-Keywords. Daher muss es selbst gebaut werden. NTP ist nicht zwingend notwendig, aber sehr sinnvoll, schließlich muss der Server mit der genauen Zeit laufen, da die Zeit als Basis für das Token verwendet wird.

apt-get install freeradius
apt-get install ntp
apt-get install libpam0g-dev libqrencode3 make gcc
cd /usr/src/
wget https://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2
tar jvxf libpam-google-authenticator-1.0-source.tar.bz2
cd libpam-google-authenticator-1.0/
make
make install

Demo-Gruppen und Demo-User anlegen

Zunächst werden die benötigten Gruppen und Benutzer angelegt:

root@radius:~# groupadd radius-disabled
root@radius:~# groupadd ssl-vpn-users
root@radius:~# groupadd mailserveraccess
root@radius:~# groupadd terminalserveraccess
root@radius:~# useradd -d /home/test1 -s /bin/bash -m -c "Radius Test-User 1" test1 
root@radius:~# passwd test1
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
root@radius:~# useradd -d /home/test2 -s /bin/bash -m -c "Radius Test-User 2" test2 
root@radius:~# passwd test2
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
root@radius:~# usermod -G ssl-vpn-users,terminalserveraccess,mailserveraccess test1
root@radius:~# usermod -G radius-disabled,ssl-vpn-users,terminalserveraccess test2
root@radius:~# id test1
uid=1001(test1) gid=1006(test1) groups=1006(test1),1002(ssl-vpn-users),1004(mailserveraccess),1005(terminalserveraccess)
root@radius:~# id test2
uid=1002(test2) gid=1007(test2) groups=1007(test2),1001(radius-disabled),1002(ssl-vpn-users),1005(terminalserveraccess)

Die Gruppe ssl-vpn-users wird später auf die von WatchGuard benötigte Gruppe SSL-VPN-Users gemappt, die Gruppe radius-disabled ist zum disablen eines Accounts gedacht. Die restlichen Gruppen sind für Resourcen, die man später in der WatchGuard mit Policies freigeben möchte.

Konfiguration freeradius und PAM

Zunächst muss der Radius-Server als root laufen. Dies wird benötigt, damit der Radius-Server in den Home-Directories der User die Datei .Google-Authenticator lesen kann, die aufgrund der entsprechende Restrictions mit den Linux-Rechten 400 versehen sind.

In der Datei /etc/freeradius/radiusd.conf wird hierzu der entsprechende Eintrag von freerad auf root geändert:

user = root
group = root

Einen Prozess als root laufen zu lassen ist böse. Da der Server aber außer Radius nichts macht, und nur die Radius-Requests durch die Firewall erhält, ist das zwar immer noch unschön, aber nicht wirklich kritisch. Eventuell kann dies auch umschifft werden, siehe hierzu den Abschnitt Ausblick am Ende dieses Beitrags.

In der Datei /etc/freeradius/users wird die Konfiguration am Ende der Datei ergänzt:

DEFAULT Group == "radius-disabled", Auth-Type := Reject
        Reply-Message = "Your account has been disabled."

DEFAULT Group == "ssl-vpn-users", Auth-type = PAM

Hiermit wird für die Gruppe radius-disabled der Zugriff via Radius komplett abgeschaltet, und nur für die Gruppe ssl-vpn-users die Authentifizierung auf PAM geschaltet.

In der Datei /etc/freeradius/sites-enabled/default mußt noch das PAM-Modul aktiviert werden, hierzu ist das Kommentarzeichen zu Beginn der Zeile vor dem Schlüsselwort pam zu löschen:

#
#  Pluggable Authentication Modules.
pam

Für einen ersten Test dieses Setups startet man in einer Shell den freeradius-Server mit

root@radius:/etc/freeradius# service freeradius stop
root@radius:/etc/freeradius# freeradius -XXX

Und testet mit radtest die beiden Testaccounts. (ich habe oben als Passwort 12341234 vergeben). das Secret testing123 ist das Default-Secret für lokales testen):

root@radius:/etc/freeradius# service freeradius restart
root@radius:/etc/freeradius# radtest test1 12341234 localhost 18120 testing123
Sending Access-Request of id 148 to 127.0.0.1 port 1812
        User-Name = "test1"
        User-Password = "12341234"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 18120
        Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=148, length=20

root@radius:/etc/freeradius# radtest test2 12341234 localhost 18120 testing123
Sending Access-Request of id 67 to 127.0.0.1 port 1812
        User-Name = "test2"
        User-Password = "12341234"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 18120
        Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=67, length=53
        Reply-Message = "Your account has been disabled."
root@radius:/etc/freeradius#

Der erste Account wird sauber authentifiziert (Access-Accept), während der zweite Account abgelehnt wird (Access-Reject, “Your account has been disabled”).

Erweiterung der Radius-Konfiguration um Gruppen

WatchGuard verwendet für die Auswertung der Radius-Gruppen das Attribut Filter-Id (11). Dieses muss nun in der radius-Konfiguration entsprechend befüllt werden. Hierzu werden zwei Dateien benötigt, die später mit $INCLUDE eingebunden werden.

In /etc/freeradius/groups.conf werden die Linux-Gruppen auf die in der WatchGuard sichtbaren Gruppen gemappt, z.B. auf die benötigte Gruppe SSL-VPN-Users.

if (Group-Name == "ssl-vpn-users") {
        update control {
                Tmp-String-1 := "SSL-VPN-Users"
        }
}
if (Group-Name == "users") {
        update control {
                Tmp-String-2 := "RadiusUsers"
        }
}
if (Group-Name == "terminalserveraccess") {
        update control {
                Tmp-String-3 := "TerminalServer"
        }
}
if (Group-Name == "mailserveraccess") {
        update control {
                Tmp-String-4 := "MailServer"
        }
}

In /etc/freeradius/post-auth.conf wird nach dem authentisieren die Filter-ID entsprechend der Werte aus group.conf befüllt.

update reply {
        Filter-Id := "%{control:Tmp-String-2}"
        Filter-Id := "%{control:Tmp-String-3}"
        Filter-Id := "%{control:Tmp-String-1}"
        Filter-Id := "%{control:Tmp-String-4}"
        Filter-Id := "%{control:Tmp-String-5}"
        Filter-Id := "%{control:Tmp-String-6}"
        Filter-Id := "%{control:Tmp-String-7}"
}

In /etc/freeradius/sites-enabled/default werden nun obige Dateien inkludiert, hierzu werden die Bereiche Authorization und post-auth um die INCLUDE-Zeile ergänzt.

authorize {
        [...]
        $INCLUDE groups.conf
}
[...]
post-auth {
        [...]
        $INCLUDE post-auth.conf
}

Nach dem Neustarten des freeradius (wieder mit -XXX) erhalten wir folgendes Ergebnis:

root@radius:/etc/freeradius# radtest test1 12341234 localhost 18120 testing123
Sending Access-Request of id 255 to 127.0.0.1 port 1812
        User-Name = "test1"
        User-Password = "12341234"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 18120
        Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=255, length=63
        Filter-Id = "TerminalServer"
        Filter-Id = "SSL-VPN-Users"
        Filter-Id = "MailServer"

root@radius:/etc/freeradius# radtest test2 12341234 localhost 18120 testing123
Sending Access-Request of id 119 to 127.0.0.1 port 1812
        User-Name = "test2"
        User-Password = "12341234"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 18120
        Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=119, length=53
        Reply-Message = "Your account has been disabled."

Der User test1 bekommt nun die für ihn relevanten Gruppen als Filter-Id mit ausgeliefert.

Google-Authenticator für den User initialisieren

Zur Initialisierung des Google-Authenticator für den User test1 erzeugen wir mit Google-Authenticator das entsprechende Secret, installieren die App Google-Authenticator auf einem Smartphone und fotografieren den entstandenen QR-Code; die entsprechenden Fragen auf wiederholbare Codes, Ratelimit etc. beantwortet man entsprechend der gewünschten Funktionalitäten.

   

PAM für Radius auf Google-Authenticator umstellen

In der Datei /etc/pam.d/radius wird nun der Inhalt wie folgt geändert (alle bisherigen Konfigurationseinstellungen auskommentieren und durch die zwei neuen Zeilen ersetzen):

# We fall back to the system default in /etc/pam.d/common-*
# 

#@include common-auth
#@include common-account
#@include common-password
#@include common-session

auth requisite pam_google_authenticator.so forward_pass
auth required pam_unix.so use_first_pass

Zum Testen müssen wir nun das von der App ausgewürfelte Token mit übergeben, da sonst der Passwort-Check zu einem Reject führt:

root@radius:/etc/pam.d# radtest test1 12341234 localhost 18120 testing123
Sending Access-Request of id 44 to 127.0.0.1 port 1812
        User-Name = "test1"
        User-Password = "12341234"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 18120
        Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=44, length=20

root@radius:/etc/pam.d# radtest test1 12341234395752 localhost 18120 testing123
Sending Access-Request of id 233 to 127.0.0.1 port 1812
        User-Name = "test1"
        User-Password = "12341234395752"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 18120
        Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=233, length=63
        Filter-Id = "TerminalServer"
        Filter-Id = "SSL-VPN-Users"
        Filter-Id = "MailServer"

Verbinden von freeradius und WatchGuard

Als erstes benötigen wir einen Eintrag in der Datei /etc/freeradius/clients.conf, hier wird das Passwort gesetzt, das wir in der WatchGuard angeben müssen, und natürlich die IP der Firebox, damit niemand anders unseren Radius-Server fragen darf.,

client 10.0.1.1 {
        secret          = strenggeheim
        shortname       = Firebox
}

Zunächst wird der Server im Policy-Manager unter Setup => Authentication => Authentication-Servers im Tab Radius eingetragen (hier mit der Server-IP 10.0.1.36.

Anschließend werden die Radius-Gruppen definiert:

Abschließend wird die Gruppen-Definition für das SSLVPN unter VPN => Mobile-VPN => SSL im Tab Authentication ergänzt:

Jetzt können die definierten Gruppen in den Policies verwendet werden.

Anmeldung im WatchGuard SSLVPN-Client

Zur Anmeldung im WatchGuard SSLVPN-Client muss nun der Benutzername mit dem Prefix “radius\” verwendet werden, um der Firebox zu sagen, daß hier als Authentisierung radius gewünscht wird. Das Passwort besteht aus dem Benutzerpasswort zzgl. dem Google-Authenticator-Token (wie oben bei den tests zu sehen).

 

Ausblick: Anbinden einer AD und mit lokaler Google-Authenticator Konfiguration

Prinzipiell sollte es möglich sein, anstelle via PAM gegen die lokale Linux-Benutzer (/etc/passwd /etc/group) gegen LDAP und damit gegen eine AD zu authentisieren. Ebenso kann man dem Google-Authenticator Modul einen Pfad für die Home-Verzeichnisse der Benutzer mitgeben, um lokal trotzdem die entsprechende .google-authenticator-Datei zu haben.

Dieses Setup habe ich aber noch nicht ausgetestet.