Watchguard SSLVPN 2-Factor mit Google-Authenticator Token

WatchGuard SSLVPN 2-Factor mit Google-Authenticator Token

2-Factor Authentisierung ist derzeit stark im Kommen, und dies ist eine gute Entwicklung. Eine 2-Factor 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 muß (typischerweise das Passwort), und dann etwas, das man besitzen muß (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 muß sie nämlich dabei haben. also “noch ein Ding rumschleppen”.

Seit einigen Jahren gibt es bei Google die Möglichkeit, mit Google-Authenticator eine 2-Factor Authentisierung zu 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 muß 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 muß es selbst gebaut werden. NTP ist nicht zwingend notwendig, aber sehr sinnvoll, schließlich muß 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 muß 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 includiert, 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.

google-authenticator  google-auth-1 google-auth-2

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

radius-server

Anschließend werden die Radius-Gruppen definiert:

radius-groups-2 radius-groups-3

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

radius-groups-1

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

Anmeldung im Watchguard SSLVPN-Client

Zur Anmeldung im WatchGuard SSLVPN-Client muß 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.

16 Kommentare zu “Watchguard SSLVPN 2-Factor mit Google-Authenticator Token”

  1. mouhcine

    Hallo, lässt sich das auch für Mobile VPN mit IPSec umsetzen? Würde dafür gern eine 2 Faktor Authentifizierung nutzen mit Google Auth.

    1. Werner Maier Post Author

      Hallo,
      die 2-Faktor-Geschichte wird ja vom Radius erledigt, nicht von der Firewall. Daher sollte mit Mobile-VPN mit IPSec genauso funktionieren, da Sie im Profil des Mobile-VPN für IPSec ebenfalls RADIUS beim Authentication Server hinterlegen können.

      1. mouhcine

        Hi,
        Dann werde ich das mal nach dieser tollen Anleitung probieren.
        Vielen Dank für die prompte Antwort und den schönen Artikel.

        Gruß
        Mouhcine

      1. mouhcine

        Es hat über Umwege jetzt doch geklappt. Die Authentifizierung ohne Googleauth klappt am Radius. Nach Aktivierung von Google Auth und den oben beschriebenen Einstellungen klappt die Authentifizierung nicht mehr. Kann das ein Zeitproblem sein?

        1. Werner Maier Post Author

          1) der Radius-Server muß per NTP synchronisiert sein, wir arbeiten ja mit Time Based Tokens
          2) Sie müssen als Password den zusammengesetzten String verwenden, ; sie bekommen keine zweite Aufforderung oder ein 2. Eingabefeld. Das ist bei Radius aber so üblich.
          3) kommerzielle Lösungen in diesem Bereich wären beispielsweise Duo-Security oder der neue Service von WatchGuard, der voraussichtlich in Q2 starten wird. siehe den Artikel über den Kauf von Data Blink.

          1. mouhcine

            Hi vielen dank für die zügige Antwort.

            Zeit hatte ich überprüft sieht in Ordnung aus:
            timedatect1 -> Local time: 17:40 universal time: 16:40 rtc time: 16:40
            Die local time ist korrekt müssen die anderen beiden ebenso aug 17:40 stehen?
            Genau ich tippe das Passwort (hallo) mit dem token ein (123 456) -> radtest test1 hallo123456 localhost 18120 testing123
            Ergebnis ist Access Reject

  2. mouhcine

    Guten Morgen,
    vielen Dank und nochmals vielen Dank für die nette Unterstützung. Bin dann doch jetzt soweit das Google Auth funktioniert. Jetzt werde ich es in der Watchguard integrieren. Kann man für die VPN IP Sec mit Google auth den kostenlosen Shrew Soft Client nutzen ?

    1. Werner Maier Post Author

      Guten Morgen.
      woran lag es?

      für 2-Factor via radius sollte es unerheblich sein, welcher Client benutzt wird, da der client “nur” eine Anfrage mit Benutzername + Passwort an die Firewall schickt. und das Passwort enthält dann beides. Der Shrew VPN Client funktioniert als IPSec Client, wobei uns Rückmeldungen von Kunden bekannt sind, daß der NCP Client stabiler sei.

      1. mouhcine

        Guten Morgen,
        folgende Fehlermeldung hatte ich noch gefunden: pam_pass: function pam_authenticate FAILED for . Reason: Module is unknown
        Hier hatte ich den Pfad in der Datei angepasst /usr/local/lib/security/pam_google_authenticator.so forward_pass danach hatte es glücklicherweise funktioniert.

        Kann bestätigen das es mit dem Shrew Soft Client funktioniert. Perfekt wäre es noch wenn ich den Radius ans AD angebunden bekomme und die Userabfrage darüber läuft.

        Gibt es eine Möglichkeit, das im Debug Modus freeradius -XXX die Passwörter nicht im Klartext angezeigt werden, finde ich sehr unschön 🙂

        1. Werner Maier Post Author

          nun, es ist ein DEBUG mode. ich tippe darauf, daß weniger “X” weniger debuggt und irgendwann die passworte nicht mehr angezeigt werden.

          für Radius an AD: entweder mit LDAP spielen – vielleicht kann man beim PAM eine LDAP-Auth einklinken, die gegen AD authorisiert, und trotzdem das lokale google-authenticator-Modul benutzt.
          Alternativ: über den Microsoft NPS (=radius für Windows/AD) arbeiten – dafür habe ich irgendwo auch mal eine proof-of-concept Software aus der “Microsoft Garage” gesehen, die das machen soll.
          Oder, mit so Dingen wie Duo-Security etc. arbeiten.

  3. NEOC

    Hallo Herr Maier,

    ist es eigentlich auch möglich eine andere Authenticator App wie z.B. Google AUthenticator für die Watchguard Authpoint Lösung zu verwenden oder muss hier zwingend die Watchguard eigene Authpoint App genutzt werden?

    Viele Grüße

    1. Werner Maier Post Author

      die WatchGuard Authenticator App ist der bessere Weg, weil hier außer dem Seed des Tokens noch einige Teile der “Hardware-DNA” des Handys mit eingehen – man kann also nicht einfach die Daten der App auf ein anderes Handy kopieren und dann das Token dort weiterbenutzen – das muss schon über den “offiziellen” Weg gehen: Token migrieren. Diese Add-On-Sicherheit gäbe es mit anderen Software-Tokens nicht.

      Zudem wird die Push-Funktionalität ausschließlich mit der AuthPoint App unterstützt.

      als Software-Token für den 6-stelligen-OTP-Code sollten andere OTP-Soft-Tokens genauso funktionieren, allerdings müssen Sie dann die entsprechenden Seed-Files besitzen und hochladen können. Im Prinzip sollte das genauso funktionieren wie bei Hardware-Tokens.

      siehe auch WatchGuard Dokumentation: Import Hardware Tokens

Leave a Reply

Your email address will not be published. Required fields are marked *