Tag Archives: Administration

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…

Funktionsweise des WatchGuard Firebox Regelwerks

4 Comments

Die WatchGuard Firewall prüft jede neu anstehende Verbindung von einem Host auf der einen Seite der Firewall zu einem Host auf der anderen Seite der Firewall. Dabei werden zunächst die Header der IP-Pakete untersucht: Quell-IP-Adresse, Ziel-IP-Adresse, Quell-Port, Ziel-Port, verwendetes Protokoll (TCP, UDP, ICMP etc.). Die Firewall durchforstet nun das Regelwerk sequentiell “von oben nach unten” (wenn man sich in der Standard-Listenansicht des Policy Managers befindet).
Nacheinander wird jede einzelne Regel geprüft, ob sie die o.g. Kriterien erfüllt – so lange bis der erste “Treffer” gefunden wird. Nur diese Regel wird auch ausgeführt. Gibt es “weiter hinten” im Regelwerk eine andere Regel, auf die ebenfalls die o.g. Kriterien zutreffen, wird diese niemals erreicht/ausgeführt. Wird eine passende Regel gefunden, wird die Verbindung authentisiert und (bei TCP) in die TCP Session Table der Firewall eingetragen. Nachfolgende Pakete in der gleichen TCP-Verbindung werden dann automatisch von der Firewall durchgelassen und nicht noch einmal aufs Neue authentisiert (anders bei Application Proxy Regeln, die eine zusätzliche Kontrolle des Inhalts vornehmen).

Ganz am Ende des Regelwerks steht eine unsichtbare Deny Regel. Jeder Datenverkehr, der nicht ausdrücklich durch eine Firewall-Regel zugelassen wird, wird von dieser Default Deny-Regel ABGELEHNT. Je nachdem, ob der Verbindungsaufbau von innen oder von außen erfolgen sollte, erscheint im Traffic Monitor und im Logfile ein Unhandled Internal Packet oder ein Unhandled External Packet.

Warum werden die Unhandled Packets angezeigt?

Weil im Policy Manager bei Setup > Default Threat Protection > Deafult Packet Handling > Logging das Häkchen “Send Log message” bei den Kategorien “Unhandled Internal Packet” und “Unhandled External Packet” gesetzt ist. Das Logging könnte zwar durch Entfernen des Häkchens ausgeschaltet werden – das ist aber keine gute Idee (bessere Idee weiter unten :-). Der Traffic Monitor und die Unhandled Packets sind ein extrem wichtiges und hochinteressantes Tool, um Fehlverhalten von Maschinen bzw. Fehlkonfigurationen im lokalen Netzwerk aufzudecken und abzustellen! Die Anzeige der Denied Packets kann der Administrator auch sehr gut nutzen, um den Bedarf für neue Regeln zu erkennen und wie diese auszusehen haben.

Das Default Regelwerk und die globale Outgoing-Regel

Der Quick Setup Wizard erzeugt bei der Ersteinrichtung der WatchGuard Firebox ein kleines Default Regelwerk, das im Prinzip sämtlichen TCP- und UDP-Verkehr sowie Ping in ausgehende Richtung (outgoing) zulässt – und sämtlichen eingehenden Verkehr (incoming) verbietet.
Gewissenhafte Administratoren wollen jedoch genau definieren, welcher ausgehende Datenverkehr zulässig ist und diesen auf Maschinen- und/oder User-Ebene auf das absolute Minimum beschränken. Neue Firewall-Regeln werden ins Regelwerk aufgenommen und so weit wie möglich einschränkt. Ein gutes Firewall-Regelwerk wächst dadurch auf 20-30 Regeln, teilweise aber auch auf 80-100 Regeln an. Das schöne feingliedrige Regelwerk wird aber nur dann wie beabsichtigt funktionieren, wenn die defaultmäßig vorhandene Outgoing-Regel auf disabled gesetzt oder ganz gelöscht wird. Denn: das Regelwerk wird “von oben nach unten” abgearbeitet, der erste Treffer zählt. Solange “unten” die globale Outgoing-Regel steht, nützen die Einschränkungen weiter “oben” nichts. Der Verkehr würde trotzdem über die Outgoing-Regel rausgehen, also weg damit!

Anzeige von bestimmten Unhandled Packets unterdrücken

Bisweilen ärgert man sich doch über die Anzeige von Unhandled Packets. Eventuell kann man die Ursache dafür einfach nicht abstellen usw. Bei der Lösung hilft nun das bisher Gesagte: das unzulässige Paket erzeugt eben ein Unhandled Packet, weil es eben keine explizite Regel für diesen Verkehr gibt. Das Paket bleibt an der unsichtbaren Deny Regel ganz am Ende des Regelwerks hängen.
Der Trick besteht nun einfach darin, eine explizite Firewall-Regel zu bauen, die den Verkehr genau beschreibt (siehe oben: Quell-IP, Ziel-IP, Quell-Port, Ziel-Port, Protokoll), aber verbietet (“Denied”) – und das Logging ausschaltet. Der lästige Verkehr taucht künftig nicht mehr im Traffic Monitor und im Logfile auf. Im Regelwerk werden Deny-Regeln mit einem roten X angezeigt:

Konfigurationsbeispiel: HostWatch Namensauflösung (Port 137/udp) unterdrücken

Properties > Logging

Eine Denied-Regel verankert sich im Regelwerk automatisch OBERHALB einer Allow-Regel für den gleichen Port bzw. das gleiche Protokoll, wird also zeitlich gesehen früher geprüft. Das kennen wir: ein explizites Verbot ist mächtiger als eine nicht erfolgte Erlaubnis. Ich nutze die Kombinationsmöglichkeit aus Denied- und Allow-Regeln auch ganz gerne so: Ping.Allow von Any nach Any -und- Ping.Denied von Any-External nach Firebox. Damit kann innerhalb des lokalen Netzwerks/VPN fröhlich hin- und hergepingt werden – auf Pings aus dem Internet reagiert unsere Firebox jedoch nicht. Wenn’s stört, kann für die Denied-Regel natürlich auch das Logging ausgeschaltet werden…

Fireware Installer zweimal starten

Comment

Wenn eine neue Fireware-Version (z.B. 10.2.7) auf eine Windows Management Station installiert werden soll, auf der sich bereits eine etwas ältere Version (z.B. 10.2.6) befindet, erscheint nach dem Aufruf des (neuen) Fireware-Installers die Meldung “Do you want to completely remove the selected application and all of its features?”:

Diese Meldung verwundert zunächst: warum soll etwas deinstalliert werden – es soll doch etwas installiert werden… Antworten Sie mit JA! Nun wird zunächst die ältere Version deinstalliert! Rufen Sie anschließend den Fireware-Installer einfach ein zweites Mal auf. Erst dann wird die neue Fireware-Version tatsächlich installiert…

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…

WSM und Fireware 10.2.7 verfügbar

1 Comment

Die neuen Versionen WSM, Fireware und SSL-VPN-Client 10.2.7 stehen im Software Download Bereich der WatchGuard Website bereit. In den Release Notes sind als “Resolved Issues” die folgenden Bugs aufgeführt. Mit den meisten hatte ich auch schon persönlich Bekanntschaft geschlossen. Ich werde die neue Version in ein paar Minuten installieren und dann Anfang nächster Woche über meine Erfahrungen berichten.

  • This release resolves a kernel crash associated with branch office VPN and Mobile VPN with IPSec traffic through the Firebox X Core or Peak e-Series. [29491]

  • The Firebox no longer stops passing traffic when you save a configuration. [27821]

  • Policy Manager no longer prevents the entry of host ranges for 1-to-1 NAT on the BOVPN tunnel route settings page. [30010]

  • The Server Load Balancing feature in Fireware now correctly detects that a server is not responding and stops sending traffic to that server. [27276]

  • You can now apply QoS and a schedule when you create a VPN firewall policy template for managed BOVPN tunnels. [10270]

  • You should no longer see the error message “HTTP response code: 500 for URL https://x.x.x.x:4117/cmm/cmd” when you try to connect to WSM. [29336]

  • If there is an active Mobile VPN with PPTP tunnel connected to the Firebox during a configuration save, Firebox System Manager no longer shows the HA peer status as “in-transition.” [27557]

  • WSM and Firebox System Manager connections no longer fail after a configuration save to two Fireboxes configured in an HA configuration. [31990]

  • The Windows SSL VPN client no longer fails to install on Windows XP with a Runtime Error message. [31932]

  • The Windows SSL VPN client now operates correctly after a computer returns from sleep mode. [31523]

Feature Key vor Software Update aktualisieren

Comment

Heute stand bei einem Kunden das Upgrade einer X500, auf der noch die alte Fireware 8.3 lief, auf die aktuelle Fireware 10.2.6 an. Generell muss bei Software Upgrades VOR dem Start sichergestellt sein, dass auf der Firebox ein aktueller Feature Key (Lizenzdatei) installiert ist, der dies überhaupt zulässt. Ist nämlich die Live Security abgelaufen, verweigert sich die Firebox mit einer Fehlermeldung! Ob bzw. wie lange die Live Security noch gültig ist, sieht man u.a. im WSM > Policy Manager unter Setup > Feature Keys…:

Steht dort “Expired”, braucht man gar nicht versuchen, die Arbeiten fortzusetzen. Stattdessen muss zunächst dafür gesorgt werden, dass wieder ein Feature Key mit gültiger Live Security vorhanden ist. Die erforderlichen Lizenzverlängerungen (Renewals) kauft man bei dem WatchGuard-Partner seines Vertrauens, gerne hier. Liegt der neue Feature Key vor, muss dieser UNBEDINGT mit der ALTEN Softwareversion (im vorliegenden Fall mit dem WSM 8.3) importiert und auf die Firebox hochgeladen werden.
Erst danach sollten die alten Software-Versionen von der Windows Management-Station entfernt, dann die aktuellen Versionen (derzeit 10.2.6) von Fireware und WSM installiert und erst dann über den Policy Manager (File > Upgrade…) der reguläre Update-Prozess gestartet werden!

BOVPN Notification einschalten

1 Comment

Wenn die Firebox an einen Logging Server angeschlossen und dieser korrekt konfiguriert ist, können für viele unterschiedliche Ereignisse auf der Firewall Notifications (Benachrichtigungen) erzeugt und per E-Mail an den Firewall-Administrator oder einen Support-Alias verschickt werden. Wichtig: Der Versand der Notification E-Mails erfolgt vom Logging Server aus – die Firewall liefert über das Logging lediglich das Triggersignal dazu!

Ein solches Ereignis kann die Unterbrechung eines BOVPN-Tunnels sein. Die Benachrichtigungs-Option hierfür ist noch relativ neu. Sie kann nur global für alle BOVPN-Tunnel ein- bzw. ausgeschaltet werden: Policy Manager > VPN > VPN Settings > BOVPN Notification:

X Edge: versteckte Debug-Funktionen

1 Comment

Die Firebox X Edge hat eine nicht dokumentierte Seite, die zum Testen und für Debug-Zwecke sehr hilfreich ist:
https://IP-DER-FIREBOX/shakne.htm.
Im Abschnitt Property Management können mit den Funktionen “Get Property”, “Put Property” und “Delete Property” einzelne Parameter in der Konfigurationsdatei hinzugefügt, verändert und gelöscht werden, die über die GUI sonst nicht erreichbar wären. Ähnlich wie beim manuellen Eingriff in die Registry eines Windows-Rechners ist hier natürlich ein konkreter Anlass und äußerste Sorgfalt angesagt!
Die Funktion Ping setzt einen Ping direkt von der Firebox an die eingegebene Zieladresse ab. Das ist äußerst hilfreich, z.B. wenn man sich gerade einmal nicht auf anderes Testsystem an dem Standort aufschalten kann…

Weiter unten finden sich noch verschiedene Debug-Hilfen – unter anderem kann hier auch das Logging Level für die Application Proxies hochgesetzt werden (wirklich nur für Debug-Zwecke, denn natürlich erzeugt das erweiterte Logging Last auf der Firewall…)

Upgrade-Pfad für X Edge e-series

Comment

WatchGuard empfiehlt, beim Software-Update einer X Edge e-series (X10e, X20e, X55e und die Wireless-Versionen) auf die Einhaltung folgender Reihenfolge zu achten: Edge e-Series 8.0 > 8.0.1 > 8.0.3 > 8.6.2 > 10.2 > 10.2.6. Dazwischen liegende Software-Versionen sollten immer zunächst auf die nächst höhere Version in der Liste upgedated werden, bevor die weiteren Updates in der o.g. Reihenfolge aufgespielt werden.
Speziell der Zwischenschritt auf 10.2 soll dabei das Problem mit der fehlenden VPN-Any Policy vermeiden. Hier wird beschrieben, wie ein Software-Update auf einer X Edge durchgeführt wird.

Software-Updates auf einer X Edge

Comment

Im Software-Download-Bereich der WatchGuard Website finden sich für die X Edge jeweils zwei Versionen: eine EXE-Datei und eine ZIP-Datei. Die EXE kann unter Windows XP und 2000 verwendet werden – ich verwende im Regelfall aber die ZIP-Datei. Im Download steckt jeweils ein vollständiges Linux-Image, das bei einem Update auf die X Edge Appliance hochgeladen wird. Nach dem Entpacken der ZIP-Datei findet sich neben einer README und drei Language Files (Französisch, Chinesisch und Japanisch) die eigentlich wichtige Datei: yakfw.sysa-dl, die aktuell etwa 20 MB groß ist.

Prüfen Sie nach der Anmeldung am Webinterface der X Edge zunächst, ob die LiveSecurity noch aktuell oder bereits abgelaufen ist (Expired). Nur bei gültiger Live Security kann das Software-Update überhaupt durchgeführt werden. Die Verlängerung bzw. Reaktivierung der Live Security erfolgt über Ihren WatchGuard-Partner, gerne natürlich auch über uns. 🙂

Natürlich ist es eine gute Idee, vor dem Update zunächst ein Backup der Konfigurationsdatei zu erstellen: Administration > Backup Configuration. Hinweis: je nach verwendetem Browser müssen Sie ggfs. zwei Mal auf Backup klicken, bevor Sie die Backup-Datei namens edgecfg.wgbk tatsächlich zum Speichern angeboten bekommen.
Für das eigentliche Software-Update findet sich im Webinterface unterhalb der X Edge-Abbildung der Button Update. Ein Klick bringt Sie zu der Seite Administration > Update. Dort können Sie mit Durchsuchen den Pfad zu der neuen yakfw.sysa-dl auswählen und die Datei anschließend auf die X Edge hochladen. Abschließend will die X Edge einmal booten. Oben links im Webinterface sollte dann die neue Versionsnummer angezeigt werden: 10.2.6 December 08 2008 Build 202312. Die Konfigurationsdatei sollte erhalten geblieben sein, so dass die X Edge sofort wieder voll produktiv ist.