Tag Archives: Konfigurationsdatei

Any-Alias in Firewall-Regeln und BOVPN-Probleme

Comment

Im Rahmen eines weiteren PCI Compliance Projekts stand vor zwei Wochen auch die Migration einer WatchGuard X5500e von Fireware 10.2.9 nach Fireware XTM 11.2.3 an sowie die Erweiterung um eine zweite X5500e zu einem HA Active/Passive Cluster. Der Kunde hatte bereits vor einigen Monaten die Migration auf eine frühere 11-er Version versucht, war aber daran gescheitert, dass zwar alle über den WatchGuard Management Server verwalteten Branch Office VPN-Tunnel funktioniert haben – nicht jedoch die über “Manual IPSec” eingerichteten BOVPN-Tunnel zu seinem outgesourceten Rechenzentrum und zu ein paar anderen externen Partnern.
Ich konnte nun erkennen, dass das Problem nicht auf Seiten der VPN-Konfiguration lag, sondern in der Formulierung einiger FIREWALLREGELN. So lautete die Firewall-Regel für “ping” From:Any To:Any. Offenbar hat aber die Firewall nicht erkannt, dass auch Ziele hinter einem BOVPN-Tunnel zu dem Alias “Any” gehören… Insofern wurden pings trotz korrekt vorhandenem VPN-Tunnel als Unhandled Internal Packet eingestuft und verworfen. Abhilfe schuf hier die Aufsplittung dieser einen Firewall-Regel in mehrere einzelne Regeln, z.B. Ping.Out.Internet = From:Any-Trusted To:Any-External und Ping.Out.VPN = From:Any-Trusted To:Any-BOVPN sowie ein paar weitere erforderliche Kombinationen z.B. für die Gegenrichtung From:Any-BOVPN To:Any-Trusted. Diese grundsätzliche Splittung in separate Firewall-Regeln für klassischen gerouteten Firewall-Traffic und VPN-Traffic hat sich bewährt! Die Migration von 10 auf 11 auf Basis der geänderten Konfigurationsdatei war dann auf Anhieb erfolgreich.

1-to-1 NAT Probleme bei 11.2.3 HA Active/Passive Cluster

Comment

In der Softwareversion Fireware XTM 11.2.3 ist offenbar ein Bug zurück, der vor ein paar Sub-Releases bereits gefixt war. Im Rahmen eines PCI Compliance Projekts durfte ich letzte Woche einen WatchGuard XTM 1050 Active/Passive Cluster von 11.1 auf 11.2.3 updaten. Nach dem Update mussten wir bei Tests feststellen, dass sich nach einem Failover das EXTERNE Interface nicht sauber initialisieren konnte. Alle anderen Optional und Trusted Interfaces arbeiteten korrekt. Das Problem trat nicht auf, wenn nur EIN Cluster-Knoten eingeschaltet war (zweite Box aus).
Bei der folgenden Analyse stellte sich heraus, dass die in der Konfigurationsdatei hinterlegten 1-to-1 NAT Einträge zusammen mit der aktuellen Softwareversion 11.2.3 das Problem in einer Cluster-Konstellation hervorrufen. Dieses Verhalten wurde von WatchGuard als Bug klassifiziert (BUG44667: 11.2.3 FireCluster A/P connections failing for 1-1-NAT entries). Da dieser Fehler bereits einmal behoben war, rechne ich damit, dass ein Bugfix sehr kurzfristig zur Verfügung stehen wird. In diesem Kundenprojekt wurde jedoch entschieden, dass das NATting künftig bereits auf dem vorgelagerten Router stattfindet, so dass der XTM1050-Cluster nur noch sauber routen braucht.

Dual Install von WSM 10.2.x und WSM 11.2.x

Comment

Wenn Sie – zum Beispiel für Migrationszwecke – auf der gleichen Windows-Maschine sowohl die Client-Komponenten des WSM 10.2.x als auch WSM 11.2.x benötigen, ist die Reihenfolge wichtig, in der die Installer ausgeführt werden:
Installieren Sie immer zuerst den WSM 10.2.x – und erst danach den WSM 11.2.x!

Wird der WSM 10 nämlich nach dem WSM 11 installiert, zerschießt der nachträglich ausgeführte WSM 10-Installer wichtige Teile der WSM 11-Komponenten. So kommt es dann bei der Migration von Fireboxen zu Problemen. Der Policy Manager von WSM 11 meldet beispielsweise beim Zugriff auf eine 10-er Box java.lang.IllegalArgumentException: Cannot support TLS_RSA_WITH_AES_256_CBC_SHA with currently installed providers. Oder sowohl “Quick Setup Wizard” als auch “Web Quick Setup Wizard” von WSM 10 laufen zwar durch, enden aber mit einer Fehlermeldung. Die Firebox selbst hängt, im LCD Display steht XModemRcv 115200 Start Remote Send…. Die Box lässt sich in diesem Zustand nur noch wieder in den Safe Mode booten (Down-Button), aber das hilft nicht weiter…

Bereinigen Sie die Installation auf Ihrer Windows-Maschine wie folgt:

  • WSM 10.x und 11.x deinstallieren
  • Restliche Fragmente der Java Runtime Engine in “Common FilesWatchGuardjava” löschen (“Gemeinsame Dateien”…)
  • Neuinstallation WSM 10.2.x
  • Neuinstallation WSM 11.2.x
  • Quick Setup Wizard der 10.2.x durchführen
  • Box sollte dann wieder „normal“ booten
  • Über den WSM 11.2.x mit der Box verbinden
  • Über den Policy Manager von 11.2.x die Box updaten…

Natürlich haben Sie sichergestellt, dass Sie Zugriff auf die letzte funktionierende XML-Konfigdatei und eigene Zertifikate/CA haben… 🙂

Unable to load proxy bei 11.2.3

Comment

Wegen ein paar größerer Projekte in den letzten Wochen hatte ich für den Blog leider keine Zeit. Nächste Woche schreibe ich wieder mal ein paar Artikel, denn es gibt doch einiges zu berichten. Hier in aller Schnelle schon mal eine Problembeschreibung, für die es aber schon eine Lösung gibt:

Die Version 11.2.3 hat teilweise Probleme mit Proxy-Regeln. Das äußert sich so, dass Traffic durch Paketfilter einwandfrei abgearbeitet wird (ping, Filtered-DNS usw.), Traffic durch Application Proxies (z.B. HTTP-Proxy, FTP-Proxy, POP3-Proxy, SMTP-Proxy) jedoch nicht. Auf Deutsch: Kunde kann pingen, Namensauflösung funktioniert, er kann aber trotzdem nicht auf Webseiten zugreifen. Im Traffic Monitor tauchen Meldungen auf wie “http-proxy unable to load” oder “proxy failed”.

WatchGuard stellt in diesen Fällen im Rahmen eines Support Incident einen Patch (11.2.3CSP2, appliance build 270901) zur Verfügung, der das Problem behebt (BUG44474: Proxies fail after configuration save).

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…

Menü unvollständig im Policy Manager

Comment

Ein Kunde berichtete heute, dass nach der Einrichtung von WSM 11.2 auf einer frischen virtuellen Maschine im Policy Manager einige (Unter-)Menüs unvollständig angezeigt werden. So würden zum Beispiel unter Setup > Authentication > Authentication Settings die Felder für SSO (Single Sign On) überhaupt nicht angezeigt…

…die auf seinem alten System aber da gewesen wären:

Des Rätsels Lösung ist ein einfaches Grafikproblem: Die Bildschirmauflösung der virtuellen Maschine war auf 1024×768 eingestellt – und bei dieser “geringen” Auflösung werden umfangreiche Menüs eben unvollständig dargestellt. Abhilfe schafft hier entweder das Verbreitern des Pop-Up-Fensters, so dass durch geänderten Zeilenumbruch (weniger Zeilen) mehr “Platz” in der Vertikalen entsteht – oder aber einfach das Hochsetzen der Bildschirmauflösung auf 1280×1024 oder darüber…

Vorsicht bei Leerzeichen im Namen von IPSec Phase 2 Proposals

Comment

Bei einer Migration einer WatchGuard Firebox X Peak X5500e von einer 10.2.x Version auf die Version 11.2 ist es mir die Tage passiert, dass plötzlich etwa die Hälfte der vorher ca. 40 BOVPN-Tunnel nicht mehr vorhanden war und im WSM / Firebox System Manager auch nicht mehr angezeigt wurde. Und zwar wurden nur noch die Tunnel angezeigt, deren Tunnel-Name alphabetisch aufsteigend von A bis zu einem bestimmten Buchstaben ging…
Die Fehlersuche führte natürlich sofort zu einem Vergleich des letzten noch angezeigten und des ersten nicht mehr angezeigten Tunnels. Dabei stellte sich als Besonderheit heraus, dass der Name des Phase 2 Proposals im ersten nicht mehr angezeigten VPN-Tunnel ein Leerzeichen enthielt! Nach dem Ersetzen des Leerzeichens durch ein “-” (Minus) und erneutem Speichern der Konfigurationsdatei waren dann auch alle VPN-Tunnel wieder da…

Version 11.1 Download und Update-Tipps

3 Comments

Am 13.11.2009 wurde die Version 11.1 freigeschaltet. Die Release Notes weisen auf die breite Unterstützung von Windows 7 für die Komponenten des WatchGuard System Manager (WSM) und der VPN-Clients für mobile User hin. Neu ist jetzt auch die Unterstützung von 64-Bit-Betriebssystemen für den Betrieb von Server Services. Hier ein Screenshot der aktuellen Unterstützungstabelle (aus den Release Notes, betrifft Windows XP 32-bit, Windows XP 64-bit, Vista 32-bit, Vista 64-bit, Windows 7 32-bit, Windows 7 64-bit, Mac OS X v10.5 (Leopard) und Microsoft Windows Server 2003. Hier fehlt leider eine konkrete Aussage über die 64-bit Version. Windows Server 2008 wird in der Tabelle leider überhaupt nicht erwähnt):

Bevor Sie das Update durchführen, lesen Sie bitte aufmerksam die Release Notes. Es kommt wirklich darauf an, welche Softwareversion aktuell auf Ihrer WatchGuard Firebox läuft. Unter Umständen muss ein bestimmter Upgrade-Pfad eingehalten werden. Beispiele:

Firebox X Edge

  • Wenn Sie aktuell 11.0 oder 11.0.1 auf Ihrer Firebox X Edge verwenden, müssen Sie die X Edge zunächst auf 11.0.2 updaten, bevor Sie auf 11.1 gehen. Dies gilt nicht für die X Core oder X Peak Geräteserien.

  • Wenn Sie aktuell 10.2.8 oder niedriger auf Ihrer Firebox X Edge verwenden, müssen Sie zunächst auf 10.2.9 (oder höher) updaten, bevor Sie dann direkt auf 11.1 upgraden können.

  • Wenn sich Ihre Firebox X Edge mit 10.x unter “centralized management” eines WatchGuard Management Servers befindet, können Sie das Update auf 11.1 nicht über die Funktion “Scheduled Firmware Updates” des Management Servers vornehmen, sondern müssen diesen Schritt “standalone” durchführen!

  • Nach dem Update auf 11.1 müssen Sie ggfs. die Konfiguration der Mobile User erneut aktivieren. Dies betrifft Mobile VPN mit IPSec, SSL-VPN und PPTP.

  • Unter 10.x gab es nur ein “Web-Kennwort” für den Administrator. Unter 11.x gibt es für die Administration standardmäßig zwei User: admin (Default-Kennwort “readwrite”) und status (Default-Kennwort “readonly”). Wenn unter 11.x Änderungen an der Konfiguration vorgenommen werden sollen, muss die Anmeldung mit dem User “admin” erfolgen.

  • Wenn Sie sich über einen Browser auf das neue Web-Interface verbinden wollen (https://[IP-der-Firebox]:8080) (Port 8080), muss der Browser “Flash” unterstützen. Wenn nicht, müssen Sie Flash installieren. Hierzu brauchen Sie auf dem PC ggfs. Administrator-Rechte.

  • Wenn Sie das Software-Update auf 11.x durchführen, indem Sie die Datei “utm_edge.sysa-dl” über das Webinterface hochladen, wird Ihre X Edge im Zuge des Updates auf Factory Default zurückgesetzt. Erzeugen Sie VORHER über Administration > Backup ein Backup Ihrer Konfigurationsdatei. Ich empfehle außerdem über Administration > View Configuration den im Hauptfenster angezeigten Text mit Cut&Paste in eine Textdatei wegzuspeichern!

  • Ich rate davon ab, ein Update direkt über das Internet vorzunehmen. Ich empfehle, eine Möglichkeit zu schaffen, sich remote auf einen PC im entfernten Netzwerk hinter der X Edge aufschalten zu können (incoming RDP, Teamviewer, PCvisit) – und das eigentliche Update quasi “lokal” von diesem PC aus durchzuführen.

Firebox X Core, X Peak, XTM1050

  • Um eine Firebox X Core oder X Peak auf 11.1 upzudaten, muss sich diese zunächst auf einer Version 10.2.x befinden.

Keine Umlaute und Sonderzeichen in der Konfiguration!

1 Comment

Nach fast 3 Wochen Abstinenz nun mal wieder ein kleines Lebenszeichen. Aus gegebenem Anlass nur ein kurzer Hinweis auf ein eigentlich bekanntes Known Issue:

Verwenden Sie im Zusammenhang mit WatchGuard-Konfigurationen, Kennwörtern, Pre-Shared Keys usw. ausschließlich druckbare Zeichen des US-ASCII Zeichensatzes (ASCII-7) – vgl. http://de.wikipedia.org/wiki/ASCII.

Die Verwendung anderer Zeichen, z.B. deutsche Umlaute (ä,ö,ü,ß) und höherbittige Sonderzeichen, kann zu nicht vorhersagbarem Verhalten der WatchGuard Firebox führen! Ich selbst gehe sogar noch einen Schritt weiter: insbesondere bei den Firewall-Kennwörten und Pre-Shared Keys beschränke ich mich auf die Buchstaben A-Z, a-z und die Ziffern 0-9 – und verzichte entgegen dem Komplexitätsgedanken instinktiv auf Sonderzeichen.
Ich habe neulich die Migration eines Clusters aus zwei Firebox X5500e von der Fireware 9.1 auf die aktuelle Fireware 10.2.7 durchgeführt. Die ursprüngliche Einrichtung wurde von einem anderen Dienstleister vorgenommen, der in den Firewall-Kennwörtern (Status Passphrase und Configuration Passphrase) jeweils ein $ (Dollarzeichen) verwendet hatte, was auch bei der Fireware 9.1 offenbar funktioniert hat. Nach dem Software-Update auf 10.2.7 liefen die Boxen jedoch instabil und konnten vom WSM auch nach kurzer Laufzeit nicht mehr angesprochen werden. Das Rücksetzen auf Factory Default habe ich dann nicht mit dem normalen “Quick Setup Wizard” (Windows-Applikation), sondern über den “Web Quick Setup Wizard” im Safe Mode vorgenommen. Der Web Quick Setup Wizard hat dann übrigens auch die Verwendung des Dollarzeichens in den Passphrases abgelehnt, der normale Quick Setup Wizard hingegen akzeptiert Dollars 🙂 Ohne Sonderzeichen in den Kennwörten liefen die Boxen dann auch mit unveränderter Konfiguration wieder klaglos…

E-Mail-Sicherheit mit dem SMTP-proxy (2)

3 Comments

Als Fortsetzung zu Teil 1 von gestern bietet sich die folgende Überlegung an:

2. Positiv-Liste (Whitelisting) aller existierenden E-Mail-Adressen in Ihrer Domain

Wenn auf Ihrem Mailserver nicht mehr als etwa 300 (verschiedene) E-Mail-Adressen liegen, sollten Sie erwägen, ALLE existierenden E-Mail-Adressen im SMTP-Proxy > Properties > Adress > Rcpt To einzupflegen. Die WatchGuard Firebox würde dann nur noch E-Mails an eben diese Adressen durchlassen – und könnte alle anderen E-Mails mit einer sauberen SMTP-Fehlermeldung “550 Mailbox Unavailable” ABLEHNEN (Deny).

Warum ist das interessant und wichtig? Viele Spammer generieren Spam-Mails an willkürlich erzeugte E-Mail-Adressen (john@meinefirma.de, joe@meinefirma.de,…) in der Hoffnung, vielleicht eine existierende Adresse zu erwischen oder in einem Sammel-Postfach zu landen. Ein korrekt konfigurierter Mailserver müsste bei jeder unzustellbaren E-Mail einen Unzustellbarkeits-Bericht erzeugen (NDR, Non Delivery Report) und an den vermeintlichen (!) Absender schicken. Die Absende-E-Mail-Adresse ist im Spam-Umfeld jedoch meist genauso gefaked, existiert nicht oder der “echte” für die mißbrauchte Domain zuständige Ziel-Mailserver verweigert die Annahme. Damit bleibt unser EIGENER Mailserver zunächst einmal auf dem ausgehenden Unzustellbarkeitsbericht sitzen! Das verstopft im Extremfall die Ausgangs-Warteschlangen (sprich Resourcen im Hauptspeicher, Festplatte) und kann sich durchaus auch zu einer DOS-Attacke (Denial of Service) ausweiten!
Wenn Ihr Mailserver aber von dem SMTP-Proxy der WatchGuard Firebox nur noch solche E-Mails vorgelegt bekommt, die er intern auch tatsächlich zustellen kann, gibt es eben keine unzustellbaren E-Mails mehr. Damit ist das Thema “unzustellbare Unzustellbarkeits-Berichte” vom Tisch und Ihr Mailserver freut sich über deutlich weniger Last! 🙂

Ob dieser Ansatz für Sie praktikabel ist, hängt von der Anzahl Ihrer existierenden E-Mail-Adressen und deren Wechsel-Häufigkeit ab. Ich kenne Installationen mit ca. 300 E-Mail-Adressen, bei denen vielleicht zwei oder drei Mal im Monat diese Liste nachgepflegt werden muss. Der Nutzen ist dann DEUTLICH höher als der administrative Aufwand. Leider findet kein dynamischer Abgleich per LDAP- oder Active Directory-Abfrage statt – die Liste muss HÄNDISCH nachgepflegt werden.
Sie können die E-Mail-Adressen entweder einzeln über die GUI eingeben oder nutzen dafür einen XML-Editor, um fertig vorbereitete Tags mit Cut&Paste direkt in die Konfigurationsdatei einzubauen (Achtung: natürlich ist hierbei Vorsicht geboten!) Selbst bei 300 Adressen dauert die Eingabe über die GUI nicht besonders lange, wenn Sie z.B. den Domainnamen in die Zwischenablage legen, so dass Sie praktisch nur den Teil vor dem @-Zeichen eintippen müssen…

In diesem Screenshot werden noch zwei erweiterte Funktionen aufgezeigt. Durch einen Klick auf “Change View” oben rechts ändert sich die bisherige einfache Ansicht in die erweiterte Darstellung. Hier haben Sie die Möglichkeit, mit “Up” und “Down” auch die Reihenfolge festzulegen, in der die einzelnen Regeln abgearbeitet werden (jede E-Mail-Adresse ist praktisch eine eigene Regel).
Außerdem können Sie hier mit der Rewrite-Funktion arbeiten, um einzelne Ziel-Adressen umzuschreiben. Wenn Sie hier mit einer Wildcard arbeiten, können Sie z.B. ein Sammel-Postfach für alle nicht vorher einzeln aufgeführten Adressen schaffen. Ich bin aber kein Freund von diesem Ansatz – ich lasse lieber unzustellbare E-Mails von der WatchGuard Firebox ABLEHNEN.

(Fortsetzung folgt…)