Tag Archives: HTTPS

Downgrade von Version 11.4.1 auf 11.3.2

Comment

Beim Versuch, eine Firebox mit Fireware XTM 11.4.1 über den Menüpunkt File > Upgrade im Policy Manager auf eine ältere Softwareversion downzugraden, erscheint die Fehlermeldung:

“The WatchGuard device is currently running Fireware XTM v11.4.1 and cannot be downgraded to v11.3.2 in this manner. To downgrade, please restore a backup image of the device when it was running v11.3.2 or use the device’s Recovery Mode to install a clean version of Fireware XTM v11.3.2.”

Die unkomplizierteste Version ist allerdings die Verwendung des Webinterfaces https://[IP-der-Firebox]:8080 (nicht möglich im High Availability Clusterbetrieb). Über den dortigen Menüpunkt System > Upgrade OS kann auch der Downgrade auf ältere Versionen erfolgen. Hierbei muss die gewünschte Version der xtm_xxx.sysa-dl Datei über das Filesystem ausgewählt und hochgeladen werden. Die sysa-dl Dateien befinden sich typischerweise unter C:ProgrammeGemeinsame DateienWatchGuardresourcesFirewareXTM => Versionsnummer => Gerätetyp

Policy Based Routing

2 Comments

Die Voraussetzung für die Nutzung von Policy Based Routing ist die Fireware Pro bzw. XTM Pro Zusatzoption und die korrekte Konfiguration von mehr als einem externem Interface für den Multi-WAN-Betrieb (vgl. z.B. http://de.watchguard-blog.com/2011/08/multi-wan-und-policy-based-routing.html).
Anschließend erweitert sich das Erscheinungsbild jeder einzelnen Firewall-Policy – und über die dort erscheinenden, eigentlich selbsterklärenden erweiterten Einstellungen lässt sich das gewünschte Verhalten im Multi-WAN-Umfeld bestimmen:

Sinn macht an dieser Stelle natürlich – speziell für ausgehende HTTP und HTTPS Policies – hier das vom Multi-WAN-Default abweichende Interface auszuwählen (im Beispiel das Interface “VDSL50” anstelle der defaultmäßigen “STANDLEITUNG”). Das hat zur Folge, dass eben der durch ausgehende HTTP/HTTPS-Verbindungen (also auch Downloads!) verursachte Traffic über das “zweite” externe Interface geführt wird (VDSL50) – und somit die STANDLEITUNG von eben diesem Traffic entlastet wird, so dass die dortige Bandbreite für die unternehmenskritischeren Anwendungen wie VPN, E-Mail etc. genutzt werden kann.

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: Öffentliches Zertifikat verwenden

2 Comments

Ab Werk wird auf einer WatchGuard SSL 100 ein von WatchGuard selbst generiertes Zertifikat verwendet, das nicht gegenüber einer allgemein bekannten, offiziellen Zertifizierungsstelle rückbestätigt ist. Das Zertifikat heißt “TestCert” und ist auf den imaginären Domainnamen “my.company.my” ausgestellt. Beim Aufruf der Anmeldeseite der SSL 100 erscheint also zunächst die allgemein bekannte Warnmeldung des Browsers. Natürlich kann das Zertifikat akzeptiert werden und das weitere Arbeiten mit der SSL 100 erfolgt trotzdem gesichert auf der Basis von SSL.
Wenn die SSL 100 jedoch nicht nur für den Remote Zugriff von eigenen Mitarbeitern verwendet wird, denen man die o.g. Vorgehensweise natürlich per Hausmitteilung bekannt machen kann – sondern auch zur Anbindung von externen Mitarbeitern, Lieferanten oder Kunden, ist es natürlich ein professionelles Vorgehen, das TestCert durch ein offiziell rückbestätigtes Zertifikat zu ersetzen. Je nachdem, welche Sicherheitsstufe angebracht erscheint, kann mit einfachen SSL-Zertifikaten für weniger als 10 Euro pro Jahr gearbeitet werden oder mit entsprechend teureren Zertifkaten, bei denen z.B. dann auch die Browserzeile nicht weiß, sondern grün hinterlegt wird…
Die Vorgehensweise ist in jedem Fall identisch, erscheint jedoch etwas kompliziert: Zunächst muss manuell ein CSR (Certificate Signing Request), eine Zertifikatsanforderung, erstellt werden – auf der Basis eines ebenfalls manuell erzeugten privaten Schlüssels. Hierzu muss auf einem Computer die Software “OpenSSL” installiert werden. Download im Internet, Einstieg über http://www.openssl.org. Der Installer für Windows findet sich unter http://www.slproweb.com/products/Win32OpenSSL.html. Sofern auf dem Windows-PC noch nicht die “Visual C++ 2008 Redistributables” installiert sind, müssen diese ebenfalls installiert werden (Download-Link direkt darunter oder Suche nach vcredist_x86.exe im Microsoft Download-Bereich).
Nach der Installation von OpenSSL mit den Default Einstellungen wird eine MSDOS-Eingabeaufforderung geöffnet und im Programmverzeichnisbin werden folgende Befehle ausgeführt:
openssl genrsa -out wgnet.key 1024
openssl req -new -key wgnet.key -out wgnet.csr
openssl pkcs8 -topk8 -in wgnet.key -out wgnet.pk8

Der erste Befehl erzeugt den privaten Schlüssel, der im zweiten Befehl zur Erzeugung der Zertifikatsanforderung verwendet wird. Dort startet auch ein Dialog, bei dem entsprechende Kundendaten abgefragt werden, unter anderem auch den Common Name (CN), auf den das Zertifikat ausgestellt werden soll, also z.B. “sslvpn.kundenname.de”. Der dritte Befehl konvertiert den privaten Schlüssel in das PKCS8-Format, das zum Import in die WatchGuard SSL 100 benötigt wird. Hier wird auch nach einem Encryption Password gefragt, das ebenfalls für den Import benötigt wird.
Die mit dem zweiten Befehl erzeugte Datei “wgnet.csr” wird nun an die Zertifizierungsstelle geschickt, für die man sich entschieden hat. Ein möglicher, sehr preiswerter Anbieter ist RapidSSL, der einfache SSL-Zertifikate bereits für 10,95 USD pro Jahr anbietet. Nach Beantragung und Legitimation erhält man innerhalb von 24 Stunden dann per E-Mail sein Zertifikat zugestellt.

Nach der Anmeldung an der Admin-Oberfläche der SSL 100 werden Zertifikat und privater Schlüssel importiert: Manage System > Certificates > Add Server Certificate (sslvpn.kundenname.de) > Publish; Manage System > Administration Service > Server Certificate (sslvpn.kundenname.de) > Publish und Restart Service; Manage System > Device Settings > General Settings (sslvpn.kundenname.de) > Publish. Nun wird beim Zugriff auf die SSL 100 das eigene Zertifikat verwendet und die Warnmeldung des Browsers unterbleibt. Anstelle einer öffentlichen Zertifizierungsstelle kann der CSR auch an eine firmeninterne (z.B. Active Directory integrierte) Zertifizierungsstelle geschickt werden. Die Warnmeldung unterbleibt dann jedoch nur auf den PCs, die z.B. als Domänenmitglied das Stammzertifikat “gelernt” haben.
WICHTIG: Die mit OpenSSL erzeugten Dateien, die verwendeten Kennwörter, die Zugangsdaten zu dem Accout der Zertifizierungsstelle und das Zertifikat sind auf jeden Fall SICHER auzubewahren und vor Zugriff von Dritten zu schützen!

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.

Internal Server Error beim Quarantine Server

Comment

Nach dem Update auf Version 10.2.12 war die User Spam Quarantäne, die im Rahmen von spamBlocker konfiguriert werden kann, über https nicht mehr ansprechbar. Port 4119 hat zwar noch Verbindungen angenommen, aber immer diese Fehlermeldung ausgegeben:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log.

Das Problem wird von einer veralteten Datei mod_python.so verursacht, die beim Update auf 10.2.12 nicht korrekt erneuert wird.
Lösung: Quarantine Server Dienst anhalten, C:ProgrammeWatchGuardwsm10.2apachebinmod_python.so durch die neuere Version ersetzen (erhältlich im Rahmen eines Support Incidents), Dienst wieder starten…

X Edge: Zugriff auf Konfigurationsdatei per FTP

Comment

Im Normalzustand akzeptiert eine Firebox X Edge FTP-Verbindungen auf ihrem Trusted Interface. Öffnen Sie eine MSDOS-Eingabeaufforderung: ftp IP-der-Firebox. Nach Eingabe von Username/Password (die gleichen Credentials wie bei der Anmeldung über das Webinterface) wird durch Eingabe von bin in den Binary Mode gewechselt. Anschließend kann mit dem Befehl get wg.cfg die Konfigurationsdatei der X Edge geholt werden. Die Datei wg.cfg steht dann an genau der Stelle des Filesystems unseres PC, von dem aus der FTP-Befehl gestartet wurde (im Regelfall C:Dokumente und EinstellungenUSERPROFIL). Hier kann die Datei dann mit einem Texteditor (z.B. Wordpad) bearbeitet werden. Dass hierbei natürlich äußerste Vorsicht geboten ist, versteht sich von selbst! Die geänderte Konfigurationsdatei kann dann in der FTP-Verbindung mit dem Befehl put wg.cfg wieder auf die X Edge hochgeladen werden. Die meisten Änderungen werden zwar sofort on-the-fly übernommen, die X Edge sollte jedoch abschließend einmal neu gebootet werden.

ACHTUNG: Die Datensicherheit ist bei dieser Vorgehensweise nur gewährleistet, wenn Sie sich entweder direkt vom Trusted Network aus mit der X Edge verbinden – oder durch einen VPN-Tunnel (egal ob Branch Office VPN oder Mobile User VPN): FTP überträgt Benutzernamen und Kennwort bei der Anmeldung im Klartext!!! Auch die Übertragung der Konfigurationsdatei erfolgt unverschlüsselt! In der Konfigurationsdatei stehen z.B. solche sensiblen Daten wie die Preshared Keys von VPN-Tunneln im KLARTEXT!!!

Von außen über das Internet sollte also nur im Notfall von dieser Methode Gebrauch gemacht werden (temporär Firewall > Incoming > FTP > Allow > [NAT:Trusted-IP-der-Firebox] einschalten). Anschließend sollten auf jeden Fall Firewall-Kennwort und Preshared Keys in einer gesicherten Verbindung geändert werden! Der FTP-Zugriff auf die X Edge kann auch deaktiviert werden: Firewall > Firewall Options > Do not allow FTP access to the Edge from the Trusted Network (bzw. Optional Network). Praktische Anwendungsfälle sind Backup/Restore/Archivierung von Konfigurationen – und wenn Sie mehrere Änderungen am Regelwerk gleichzeitig vornehmen müssen, z.B. per Fernwartung/HTTPS die IP-Adresse des Trusted Interface ändern und gleichzeitig auch den Incoming NAT-Eintrag anpassen, über den eben genau die Fernwartungssitzung läuft (der berühmte Ast, auf dem man gerade sitzt… 🙂

Wenn es nur um das Auslesen der Konfigurationsdatei geht, ist es besser, sie sich SSL-verschlüsselt über das Webinterface anzeigen zu lassen (Administration > View Configuration) und mit Cut&Paste in eine Textdatei weg zu speichern…

Sichere Fernwartung einer X Edge

Comment

Um eine entfernt stehende Firebox X Edge auch per HTTPS direkt über das Internet administrieren zu können, füge ich normalerweise bei Firewall > Incoming eine Custom Packet Filter Policy hinzu, die eingehenden HTTPS-Verkehr direkt auf das Webinterface der Firebox leitet (Static NAT). Damit nicht jeder beliebige Rechner aus dem Internet bis zur Anmeldeseite gelangt, lasse ich jedoch nur die bekannten festen IP-Adressen z.B. des Hauptstandorts des Kunden (und unsere eigenen) zu:

Hat die X Edge eine feste externe IP-Adresse, erfolgt der Zugriff über https://EXTERNE-IP. Bei einer dynamischen externen IP-Adresse nehme ich mir einen kostenfreien DYNDNS-Hostname zu Hilfe, der bei Network > Dynamic DNS eingetragen wird:

Befindet sich die X Edge in einer (VPN-)Außenstelle unseres Unternehmens, sorgt diese Einrichtung natürlich auch dafür, dass wir die X Edge über das Internet erreichen können, auch wenn der reguläre VPN-Tunnel dorthin gerade einmal nicht zur Verfügung steht 🙂 Wenn ich parallel dazu auch die SSL-VPN-Möglichkeit der X Edge nutzen möchte, um dort mobile User zu terminieren, lege ich den Port für Remote-HTTPS meist von 443 zum Beispiel auf 444 um: Administration > System Security: