Tag Archives: User Authentication

Fireware XTM: Öffentliches Zertifikat für Anmeldeseite (Port 4100 tcp) verwenden

2 Comments

Wenn auf der WatchGuard Firebox oder WatchGuard XTM mit User Authentication gearbeitet wird – also Firewall-Regeln verwendet werden, die auf User-Basis greifen und nicht auf Maschinen-Basis – kommt häufig die Anmeldeseite der Firewall ins Spiel, die über
https://[IP-der-Firebox]:4100
aufgerufen wird. Die Anmeldeseite verwendet SSL-Verschlüsselung. Hierfür wird standardmäßig ein von WatchGuard selbst generiertes Zertifikat verwendet, das aber nicht von einer öffentlichen Zertifizierungsstelle rückbestätigt ist, weswegen beim Aufruf die allseits bekannte Warnmeldung des Browsers erscheint. Folgende Zertifikate sind ab Werk auf einer WatchGuard Appliance unter Fireware XTM 11.3.x vorhanden:


Das SSL Zertifikat von WatchGuard kann durch ein offizielles, von einer allgemein bekannten Zertifizierungsstelle rückbestätigtes SSL Zertifikat ersetzt werden. Hier reicht schon ein einfaches Zertifikat z.B. von RapidSSL aus, das bereits für 10,95 USD pro Jahr erhältlich ist. Alternativ kann (mit den bekannten Einschränkungen) auch ein von einer firmeninternen, privaten Zertifizierungsstelle erstelltes Zertifikat verwendet werden. Es empfiehlt sich, das Zertifikat für einen griffigen Hostname ausstellen zu lassen (firewall.kundenname.de, watchguard.kundenname.de, fw.kundenname.de etc.) und diesen über DNS korrekt bekannt zu machen. Zur allgemeinen Vorgehensweise:
WatchGuard System Manager (WSM) > Connect to Firebox > Firebox System Manager > View > Certificates > Create Request.
Der abschließend erzeugte CSR (Certificate Signing Request) wird an die Zertifizierungsstelle geschickt, für die man sich entschieden hat. Wenn das von dort ausgestellte Zertifikat vorliegt, kann es über “Import Certificate / CRL” auf die Firebox importiert werden. Wenn das Root-Zertifikat der CA nicht in der Liste der defaultmäßig enthaltenen CA Certificates enthalten ist (http://www.watchguard.com/help/docs/wsm/11/en-US/Content/en-US/certificates/cert_auto_trusted_list_c.html), muss es VOR dem Import des eigentlichen Zertifikats auf die gleiche Weise importiert werden, da sonst ein Fehler generiert wird: “Error: Error occurred while performing ‘import certificate’: certificate add error msg=”Failed to import a certificate!! 6_982: certificate validation fail” add certificate”. Das Root-CA Zertifikat von RapidSSL findet sich übrigens hier: http://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.cer. Wählen Sie für den Import jeweils die Option “IPSec, Web Server, Other”. Der erfolgreiche Import wird angezeigt:

Nun ist/sind die offiziellen Zertifikat(e) zwar schon auf der Firebox vorhanden, müssen aber noch für den Einsatz auf der Authentication Webpage der Firebox ausgewählt werden:
Policy Manager > Setup > Authentication > Web Server Certificate… > Third Party Certificate auswählen > OK > Save to Firebox.
Abschließend muss die Firebox einmal durchgebootet werden, damit diese Änderung auch tatsächlich aktiv wird:


SSL 100: One Time Password per SMS

1 Comment

Die einfachste Form der User Authentication an einer WatchGuard SSL 100 ist die Kombination aus Benutzername und Kennwort, WatchGuard SSL Password. Die User und Kennwörter können auf der SSL100 selbst gepflegt werden oder es erfolgt ein Mapping zu einer externen Benutzerdatenbank, z.B. einem Active Directory. Damit nicht die unbefugte Weitergabe der Zugangsdaten an Dritte die Sicherheit der internen Daten und Programme gefährdet, kann eine zweite Komponente die Sicherheit erhöhen: eine Two-Factor Authentication, also die Kombination aus Wissen und Besitz oder Biometrie). Neben der Kenntnis von Benutzername und Kennwort ist auch noch eine zweite Komponente erforderlich, z.B. ein OTP Token als Schlüsselanhänger, der zeitgesteuert z.B. alle 60 Sekunden eine neue 6-stellige Zahl anzeigt, die bei der Anmeldung zusätzlich abgefragt wird. Hersteller sind u.a. RSA und VASCO. Alternativ ist es auch möglich, das Einmal-Kennwort per E-Mail (z.B. an BlackBerry Handhelds, iPhone oder andere Mobile E-Mail Devices) zu versenden – oder per SMS auf ein beliebiges Mobiltelefon.
Wenn das One Time Password (OTP) per SMS versendet werden soll, bedient man sich in der Regel eines SMS-Providers, bei dem man ein gewisses Kontingent an SMS einkauft. Ein möglicher Anbieter ist Clickatell. Nach der Aktivierung eines Accounts und dem Kauf eines SMS-Kontingents (hier 400 SMS für 17,60 EUR = 4,4 ct pro SMS) bekommt man von Clickatell drei Zugangsinformationen zugewiesen: USERNAME, PASSWORD und API_ID. Diese drei Angaben ersetzen die Platzhalter in folgender URL: https://api.clickatell.com/http/sendmsg?user=USER&password=PASSWORD&api_id=API&to=[$user-mobile]&text=[$message].
In der Konfiguration der WatchGuard SSL100 wird diese URL an folgender Stelle eingetragen: Manage System > Notification Settings > SMS Channel > Add SMS Channel > Plugin = HTTP-Plugin > URL > Save > Save (!!!) > Publish (!!!)
Außerdem muss sichergestellt sein, dass WatchGuard SSL Mobile Text generell als Authentication Methode enabled ist und auch in den entsprechenden Userkonten, die dieses Verfahren nutzen sollen. Dort muss ebenfalls die Mobilfunknummer eingetragen werden, an die die SMS geschickt werden soll (hier im Format 49171xxxxxxx). Die Nutzung des SMS-OTP macht natürlich nur dann Sinn, wenn in den betreffenden User-Accounts die Anmeldemethode WatchGuard SSL Password disabled wird, denn sonst wäre ja nach wie vor die einfache Anmeldung nur mit Benutzername und Kennwort möglich. Beim Aufruf der Anmeldeseite wählt der User also WatchGuard SSL Mobile Text aus und meldet sich zunächst mit seinem regulären Benutzernamen und Kennwort an:

Dadurch wird die Erzeugung des SMS-OTP angestoßen und wenige Sekunden später kommt eine SMS an. Als Absender der SMS tritt bei Clickatell eine +44 Nummer in Erscheinung, da das Gateway wohl in Großbritannien betrieben wird. Der Standard-Text der SMS lautet: Your OTP is xxxxxx. Enter it to login with Mobile Text. Anschließend steht die gewohnte Portaloberfläche mit den freigegebenen Icons zur Verfügung.

LDAP Authentication für IPSec Mobile User VPN

Comment

In einem Migrationsprojekt von WatchGuard Fireware 10.x nach Fireware XTM 11 fand ich neulich bestätigt, dass bei Fireware XTM 11 das Coding geändert wurde, mit dem die Firebox eine LDAP Authentication (hier: Novell e-Directory) durchführt. Problem war, dass externe Client-PCs mit installiertem IPSec-Client (NCP) nach der Umstellung auf Fireware XTM v11.2.3 zwar die VPN-Einwahl vornehmen konnten, anschließend aber kein Traffic durch den Tunnel geflossen ist. Im Traffic Monitor war der Traffic als Unhandled External Packet zu sehen – allerdings mit korrekt angezeigtem User (z.B. testaccount@LDAP). Insofern war klar: die Firebox hat aufgrund der Rückmeldung vom LDAP erkannt, dass Benutzername und Kennwort korrekt waren. Sie konnte an dieser Stelle ebenfalls die Gruppenzugehörigkeit erkennen und hat aus dem korrekten IP-Adresspool eine Einwahl-IP vergeben. Soweit so gut.

Trotzdem hat irgendetwas verhindert, dass die FIREWALLREGEL, die zu der entsprechenden Mobile User VPN Gruppe gehört, ausgeführt wird – also wurde die Gruppenzugehörigkeit für den Firewall-Part nicht korrekt hinterlegt. Bei der Ursachenforschung wurden mehrere Besonderheiten des Kunden-LDAP beleuchtet, z.B. verwendet der Kunde Leerzeichen im Benutzernamen. Im Endeffekt konnte das Problem jedoch darauf eingekreist werden, dass der LDAP Gruppenname, der eben auch als Name für die MUVPN Gruppe auf der WatchGuard Firebox verwendet wird, aus einer Kombination aus Groß- und Kleinbuchstaben bestand! Wurde also der Gruppenname im LDAP so geändert, dass er entweder NUR aus Großbuchstaben oder NUR aus Kleinbuchstaben bestand und die MUVPN Gruppe gelöscht und mit der neuen Syntax neu erzeugt wurde, FUNKTIONIERTE sowohl VPN-Einwahl als auch Traffic korrekt.
Da der Kunde mit 70 Standorten jedoch international aufgestellt ist und die LDAP Gruppennamen auch noch für andere Softwareprodukte in der bisherigen Schreibweise benötigt wurden, musste das Problem anderweitig umgangen werden. Es zeigte sich, dass die allerneueste Version des NCP-Clients, den WatchGuard als Version 11.2.3 im Software Download Portal bereit stellt, mit der Mischung aus Groß- und Kleinbuchstaben im LDAP Gruppennamen korrekt umgehen kann. Es wurde also entschieden, diesen Anlass zu nutzen und alle mobilen Clients auf den neuesten IPSec-Client upzudaten.

Fireware XTM v11 und Windows 2000 Active Directory User Authentication

3 Comments

Die Release Notes von WSM und Fireware XTM v11 enthalten den lapidaren Satz “We no longer support Microsoft Windows 2000”. Eine damit zusammenhängende Erscheinung hat mir die Tage etwas Kopfzerbrechen beschert: User Authentication gegenüber einer nativen Windows 2000 Domäne. Nach dem Upgrade von WSM/Fireware 10.2.7 auf 11.2.1 funktionierte sowohl die Web Authentication über Port 4100 nicht mehr (“user name or password invalid”) als auch die MUVPN-Einwahl über den IPSec-Client (“admd ADM auth Firewall user [xxxxx@Active Directory] Error, Reason – Generic error id=”1100-0012” bzw. “wgcgi Firewall user xxxxx@Active Directory from [IP] rejected – all other error”).
Das liegt daran, dass eine Firebox mit Fireware XTM v11 “anders” in das Active Directory abfragt als die bisherige Fireware 10. Zum Auslesen von Gruppenmitgliedschaften werden jetzt tokenGroups_get Abfragen ins AD gestellt. Damit kann ein natives Windows 2000 Active Directory aber noch nichts anfangen. Erst ein Windows 2003 Domänencontroller kommt damit zurecht. Natürlich sollte heutzutage die AD-Migration kein Problem mehr sein, will aber natürlich trotzdem gut vorbereitet sein. Für die Übergangszeit kann daher mit einem Trick gearbeitet werden, der zwar nicht offiziell supported wird, aber trotzdem funktioniert: anstelle der direkten Active Directory Authentication auf LDAP umstellen – mit ansonsten identischen Einstellungen:

In der Pulldown-Liste von Login Attribute findet sich bei LDAP jedoch nicht das klassische Windows-Attribut sAMAccountName. Dies kann dort aber händisch über die Tastatur eingegeben werden… Natürlich müssen dann ggfs. noch die in Firewallregeln verwendeten Gruppennamen unter Setup > Authentication > Authorized Users and Groups nachgezogen werden. Und unter VPN > Mobile VPN muss auch an den entsprechenden Stellen von Active Directory auf LDAP umgestellt werden.

Probleme mit self-signed Zertifikaten beim Update auf 11.2

Comment

Mir ist es heute zum zweiten Mal passiert, dass nach dem Update einer Firebox X Core bzw. X Peak von Fireware (Pro) 10.2.x auf Fireware XTM v11.2 zwar die Firewall/VPN-Funktionalität da war, die Box jedoch über den WatchGuard System Manager (WSM) nicht mehr ansprechbar war.

In beiden Fällen führe ich das Problem auf das Vorhandensein bzw. die Nutzung eines selbst generierten 3rd Party Zertifikats für die SSL-geschützte Web Authentication Page (Port 4100) zurück. Die Zertifikate waren jeweils von einer eigenen Active Directory-integrierten Zertifizierungsstelle erzeugt worden, damit beim Laden der Firewall-Anmeldeseite auf den Domänen-Mitglieds-PCs die Warnmeldung des Browsers nicht angezeigt wird. Unter Fireware (Pro) 10.2.x hatte dies auch die ganze Zeit problemlos funktioniert.

Beim ersten Fall vor ca. 2 Wochen stand ich sehr unter Zeitdruck (Downtime…) und habe zur schnellen Problemlösung die Brachialmethode gewählt: Factory Default Reset über das Command Line Interface (CLI) [PuTTY/SSH auf Port 4118 der Firebox, Anmeldung als User “admin” mit der Configuration Passphrase (dem “schreibenden Kennwort”)] und Eingabe des Kommandozeilen-Befehls “restore factory-default”. Hierdurch werden u.a. die Firewall-Kennwörter auf die Fireware XTM v11.x Defaults “readwrite” (für den User “admin” bzw. die Configuration Passphrase) und “readonly” (für den User “status” bzw. die Status Passphrase) zurückgesetzt… Anschließend dann das übliche Spiel: Durchklicken des Quick Setup Wizard, Verbinden per WSM, Öffnen des Policy Managers, Laden der letzten funktionierenden Konfigurationsdatei, Ändern der Einstellungen für das Web Server Certificate und “Save to Firebox”…

Heute konnte ich ein paar Minuten Zeit mehr investieren und habe dabei herausgefunden, dass es offenbar auch ausreicht, auf Kommandozeilenebene die Befehle “configure” und “web-server-cert default” auszuführen – also anstelle des 3rd Party Zertifikats das eingebaute Original-WatchGuard-Zertifikat auszuwählen. Anschließend konnte ich auch sofort wieder per WSM auf die Box zugreifen… Interessanterweise konnte ich anschließend im Policy Manager sogar wieder das 3rd Party Zertifikat auswählen und problemlos wieder aktivieren… Das Problem tritt also offenbar nur genau im Moment des Software Upgrades von 10.2.x auf 11.2 auf. Ich werde mir also angewöhnen, bei Migrationen künftig vorsorglich über Setup > Authentication > Web Server Certificate zunächst das Original-WatchGuard-Zertifikat auszuwählen und erst nach der Migration wieder das 3rd Party Zertifikat zu aktivieren…

Achtung bei Migration auf Fireware XTM: Routing Table – Abarbeitung ändert sich

1 Comment

Momentan habe ich wenig Zeit für meinen Blog, weil jeden Tag neue Support-Anforderungen bei mir eingehen. Admins migrieren ihre WatchGuard Firebox mit bestem Wissen und Gewissen auf Fireware XTM (Version 11) – und erleiden bisweilen Schiffbruch. In den allermeisten Fällen lassen sich die Probleme darauf zurückführen, dass bei Fireware XTM (Version 11) die interne Routing Table der Firebox in einer anderen Reihenfolge abgearbeitet wird als bei der bisherigen Fireware 10.2.x.

Generell gilt bei XTM: VPN hat Vorrang!

Welche Probleme können daraus entstehen und welche Lösungsansätze gibt es:

  • 1. Mobile User VPN. Während noch bei der Version WFS 7.x empfohlen wurde, den IP-Pool für die Einwahl der mobilen User INNERHALB des lokalen LAN-Subnetzes zu definieren (Beispiel: LAN = 192.168.0.0/24, mobile User (egal ob PPTP oder IPSec) bekommen 192.168.0.200 bis 220 zugewiesen), ist dies bei Fireware XTM (Version 11) grundsätzlich ein Problem und führt zu gravierendem Fehlverhalten.

    Verwenden Sie grundsätzlich für die Einwahl von mobilen Usern IP-Bereiche, die in dieser Form an keiner anderen Stelle Ihrer (verteilten) IP-Infrastruktur verwendet werden. Ich persönlich verwende gerne für PPTP den Bereich 172.31.254.1 bis 50, für IPSec 172.31.255.1 bis x (je nach Lizenz) und für SSL-VPN 172.31.253.0/24. Diese Bereiche werden in aller Regel noch nicht für andere Zwecke verwendet – und haben eben den Vorteil, dass die WatchGuard Firebox zu diesen Bereichen ein sauberes Routing fahren kann.

  • 2. Network > Routes. Das Problem hier lässt sich anhand von folgendem Support Fall verdeutlichen: als eth1 (=Trusted) war bei einem Kunden definiert: 192.168.0.1/30, d.h. außer der Firebox gibt es in diesem Subnetz nur noch genau einen weiteren Host, 192.168.0.2. Dies ist ein Standleitungs-Router, der eine Leitung zu einem 10-er IP-Netz am Hauptstandort des Unternehmens bedient, an dem sich auch die AD-Domänencontroller des Unternehmens befinden, über die u.a. auch die Einwahl der mobilen User gegenüber Active Directory authentifiziert wurde (Eintrag unter Setup > Authentication > Authentication Servers > Active Directory). Dummerweise gab es in dieser Konfiguration auch noch einen BOVPN-Tunnel (sprich eine feste Außenstelle), der auf der Gegenseite das IP-Netz 192.168.0.0/24 bedient hat. Während unter der Software-Version Fireware 10.2.x das auf eth1 definierte lokale Netzwerk 192.168.0.0/30 Vorrang hatte und daher die DCs in dem 10-er Netz per Routing erreichbar waren, verhält sich die WatchGuard Firebox unter Fireware XTM (Version 11) nun anders und schickt den Traffic zu dem Standleitungs-Router 192.168.0.2 nun nicht mehr zum lokalen Interface eth1 raus – sondern packt ihn in den Tunnel in die Außenstelle x ein, wo er im Nirwana landet… Problematik klar? In diesem Fall am einfachsten die Konfiguration von eth1 und die IP-Adresse und das Routing des/zum Standleitungs-Router so abändern, dass das verwendete IP-Subnetz an keiner anderen Stelle der Unternehmens-IP-Infrastruktur verwendet wird…

  • 3. Problematik: vermaschte IP-Netze. Unter einem “vermaschten IP-Netz” verstehe ich hier ein verteiltes Netzwerk mit mehreren Standorten, die auf TCP/IP-Basis miteinander kommunizieren können, wobei das Routing jedoch nicht direkt von Außenstelle zu Außenstelle geführt wird, sondern über einen gemeinsamen, zentralen Punkt (i.d.R. ein Rechenzentrum). Auch ich habe in der Vergangenheit Netze gebaut, die in einer Außenstelle z.B. ein IP-Netz à la 10.0.23.0/24 verwendet haben – und einen BOVPN-Tunnel zu 10.0.0.0/8 hinter einem zentralen Gateway angesteuert haben. Dort befand sich eine WatchGuard Firebox X Core oder X Peak, die den Traffic angenommen hat – und auch tatsächlich wieder korrekt in die ebenfalls dort terminierten BOVPN-Tunnel zu den anderen Außenstellen eingepackt hat. Damit ließen sich auch schon in der Vergangenheit zentralisierte VoIP-Lösungen (z.B. Asterisk, Siemens HiPath, Avaya) abbilden. Ein Problem entsteht unter Fireware XTM insbesondere dann, wenn auch das zentrale Netzwerk in einem IP-Subnetz des o.g. vermaschten Netzwerks betrieben wird. Die zentralen Server sind dann aus den Außenstellen heraus nicht mehr korrekt erreichbar. Trifft dieses Szenario auf Sie zu, sprechen Sie mich bitte direkt an, um eine Lösung gemeinsam zu erarbeiten.

  • 4. Allgemein gilt: sofern Ihre IP-Infrastruktur *KLAR* definiert ist und es zwischen den verwendeten IP-Bereichen keine Konflikte/Überschneidungen gibt, wird ein Update auf die aktuelle Version WSM 11.x und Fireware XTM v11.x relativ einfach und überschaubar über die Runden gehen.

Falscher Download-Link zum SSO Agent 10.2.11

1 Comment

Aus den Release Notes der Version 10.2.11 geht hervor, dass der SSO Client unverändert auf 10.2.9 bleibt (das optionale MSI-Paket für die Installation auf dem Desktop-PC) – dass es aber einen neuen SSO Agent 10.2.11 gibt (Authentication Gateway), der im Software Download Bereich auch so angeboten wird. Der Download-Link zeigt aber derzeit auf eine falsche Datei, nämlich den alten SSO Agent 10.2.9! Zumindest bei einem Kunden mit einer X Edge musste ich feststellen, dass nach dem Update auf Edge 10.2.11 die User Authentication gegen Active Directory mit dem (alten) SSO Agent nicht mehr funktioniert.

Neue Software-Versionen

6 Comments

Die Version 10.2.4 soll am Montag, 17.11.08, amerikanischer Zeit zum Download über die WatchGuard-Website bereitgestellt werden. Hier soll sich speziell die Funktion Single Sign On bei Verwendung von User Authentication in Verbindung mit Active Directory verbessern. Bislang hatte der SSO Agent auf dem Domänencontroller Schwierigkeiten mit PCs, an denen mehrere wechselnde Benutzer arbeiten oder Dienstkonten genutzt werden (z.B. für Backup- oder Antivirus-Software). Mit 10.2.4 soll ein zusätzlicher Software-Client bereitgestellt werden, der – auf den PCs installiert – die Erkennung des aktiven Benutzerkontos für den Agent vereinfacht.
Vor Weihnachten soll dann noch eine Version 10.2.5 erscheinen, bevor dann Ende Januar mit dem nächsten Major Release Fireware 11 zu rechnen ist.

Zertifikat für Web Authentication

3 Comments

Bei Nutzung von User Authentication melden sich die User an der von der WatchGuard Firebox selbst zur Verfügung gestellten Anmeldeseite https://ip-der-firewall:4100 an. Für die SSL-Verschlüsselung wird standardmäßig ein von WatchGuard selbst erzeugtes SSL-Zertifikat verwendet, das aber nicht gegenüber einer “offiziellen” Zertifizierungsstelle rückbestätigt ist. Daher bekommen die User zunächst die übliche Warnmeldung des Browsers gezeigt, die sie entsprechend übergehen müssen.
Der beste Ansatz, dieses Verhalten zu umgehen, ist der Einsatz eines offiziellen Webserver SSL-Zertifikats, das aber kostenpflichtig ist und im Regelfall pro Jahr ebenfalls kostenpflichtig erneuert werden muss. Die entsprechende Zertifikatskette kann dann über den Firebox System Manager im Menüpunkt View / Certificates… importiert werden. Anschließend steht das Zertifikat im Policy Manager unter Setup / Authentication / Web Server Certificate als Third Party Certificate zur Auswahl bereit. Alternativ dazu kann bei Vorhandensein einer (Windows) Active Directory Umgebung dort auch eine eigene (Windows-)Zertifizierungsstelle aufgesetzt und darüber ein eigenes Webserver-Zertifikat generiert werden. Computer, die Mitglied der Domäne sind, lernen dieses Zertifikat dann automatisch.
Wichtig: Der Import von Zertifikaten ist ein Feature der Zusatzoption Fireware Pro, die bei X Peak Geräten standardmäßig dabei ist, auf X Core Geräten jedoch separat lizensiert werden muss!