Tag Archives: Fernwartung

Verlust der Konfigurationsdatei beim Update von v10 auf v11.3.4

Mir ist es in den letzten Wochen selbst zweimal passiert, und auch ein Kunde hat übereinstimmend berichtet, dass beim Software-Update einer bestehenden X Core e-series (X550e, X750e, X1250e) von Softwareversion 10.2.x direkt auf Version 11.3.4 die Firebox anschließend eine “leere” Konfigurationsdatei hatte – genau so wie sie aus dem Setup Wizard mit durchbestätigten Default-Einstellungen heraus kommen würde.
Das Dumme dabei ist, dass sich auch die TCP/IP-Einstellungen der Interfaces auf Default zurückgesetzt haben: eth0=10.0.0.1/24, eth1=10.0.1.1/24 usw.!! Dadurch war die Firebox natürlich nicht mehr direkt “ansprechbar”, weder vom Trusted Network noch remote über das Internet!
Zum Glück war bisher in allen meinen Fällen kompetentes IT-Personal vor Ort zur Stelle, das nach telefonischer Anleitung den lokalen Zugriff und den Remote-Zugriff wieder herstellen konnte:

  • Auf eth1 lag 10.0.1.1/24, also musste zunächst irgendwie dafür gesorgt werden, dass ein PC/Notebook mit einer anderen fest konfigurierten IP-Adresse aus dem Subnetz 10.0.1.0/24 auf eth1 zugreifen kann.
  • Auf dem PC/Notebook muss bereits ein funktionsfähiges Adobe Flash Plugin vorhanden sein!
  • https://10.0.1.1:8080 ruft den WatchGuard Setup Wizard auf.
  • Die Passwörter waren jedoch NICHT die Factory Defaults readonly bzw. readwrite, sondern immer noch die bisherigen tatsächlichen Kennwörter der Firebox! (Auch der Feature Key war auf dem Gerät noch vorhanden und aktiv!)
  • Durchklicken des Setup Wizard, wobei jedoch die TCP/IP-Einstellungen für das TRUSTED Interface (und bei Remote Administration die Einstellungen für das EXTERNAL Interface) passend wiederhergestellt werden müssen!! Diese Angaben sollten also bei Durchführung eines Software-Updates grundsätzlich immer irgendwie “schwarz auf weiß” zugänglich sein… 🙂
  • Bei Remote Administration muss noch die “WatchGuard” Firewall Policy kurzfristig so erweitert werden, dass der Alias “Any-External” im From-Feld zu stehen kommt.
  • Nun kann die letzte existierende XML-Konfigurationsdatei wieder auf die Firebox hochgeladen werden – und alles sollte wie vorher sein, nur dass jetzt eben die 11-er Software darunter liegt…

Dieses Verhalten ist bei WatchGuard (noch) nicht als Problem bekannt, aber man weiß ja nie… Drei unabhängige Fälle lassen ja schon vermuten, dass da womöglich momentan ein Bug sein Unwesen treibt… Kleiner Tipp: eventuell hat das Problem ja auch etwas mit den berühmten Sonderzeichen zu tun. Sollten Sie also Firewall-Kennwörter verwenden, die nicht ausschliesslich aus A-Z, a-z und 0-9 bestehen, sollten Sie diese eventuell VOR dem Software-Update kurzfristig entsprechend ändern… 🙂

Command Line Interface (CLI) auf Port 4118 tcp

WatchGuard Firebox e-series und XTM Systeme mit Software 10.x oder 11.x bieten auch die Möglichkeit der Administration und Programmierung im Kommandozeilenmodus (CLI). Ausnahme: X Edge e-series mit v10.x. Hierzu läuft auf der WatchGuard ein SSH-Daemon, der auf Port 4118 tcp hört. Dieser Port ist Bestandteil der standardmäßig im Regelwerk enthaltenen Firewall-Regel “WatchGuard”, die ebenfalls standardmäßig den Zugriff auf die “Firebox” von “Any-Trusted” und “Any-Optional” ermöglicht. Das From-Feld dieser Regel kann natürlich auch so erweitert werden, dass der Zugriff über das Internet oder für mobile User möglich wird (Sicherheitsüberlegungen berücksichtigen!).
Das CLI kennt wie das WebUI zwei User: status und admin. Zu status gehört immer das lesende Kennwort der Firebox (status passphrase). Zu admin gehört immer das schreibende Kennwort der Firebox (configuration passphrase).
Wenn Sie nun über einen SSH-Client (z.B. PuTTY) eine SSH-Verbindung zu Port 4118 öffnen und sich als admin an der Firebox anmelden, können Sie dort zunächst durch die Eingabe eines Fragezeichens (?) eine Übersicht der verfügbaren Befehle anzeigen lassen:

Hier findet sich unter anderem auch der Befehl “reboot”, über den die Firebox durchgebootet werden kann. Gerade bei Fireboxen mit v10.x ist dieser Einstieg manchmal “der letzte Rettungsanker”, wenn durch Memory Leak Effekte der Hauptspeicher auf der Firebox zugelaufen ist und die Firebox in Folge den Daemon abgeschaltet hat, über den sich der WSM mit der Firebox verbindet…
Ebenfalls sehr hilfreich ist der CLI-Befehl “ping”, der es ermöglicht, pings direkt von der Firebox aus zu verschicken.
Theoretisch kann über das CLI auch eine weitgehende Administration des Gesamtsystems erfolgen, also auch Konfigurationsänderungen etc., jedoch kommt dies in der Praxis eher selten vor. WatchGuard bietet hierfür unter http://www.watchguard.com/help/documentation/xtm.asp eine umfangreiche PDF: die Command Line Interface Reference.

Vorsicht bei “Deny” Firewall Rules auf der X Edge!

Durch die Migration einer Firebox X Edge von der Version 10 auf die neue Fireware XTM v11.x ändert sich unter anderem auch die Reihenfolge, in der die Firewallregeln ausgeführt werden. Unter Version 10 war es kein Problem, bei Firewall > Outgoing die nicht benötigten Services auf “Deny” (roter Hintergrund) zu setzen, solange z.B. die “Outgoing”-Regel selbst auf “Allow” (grüner Hintergrund) stand.

Bei Fireware XTM v11.x ist es anders. Dies zeigt dieser Supportfall: Kunde führt ein Update einer X Edge mit 10-er Software auf Fireware XTM v11.x durch. Das Update läuft erfolgreich durch. Anschließend ist plötzlich kein HTTP-Zugriff mehr auf das Internet möglich. Beim Versuch, auf das Webinterface der X Edge (neu, Port 8080) zuzugreifen, erscheint die Meldung, dass hierfür zunächst der Adobe Flash Player heruntergeladen und installiert werden müsse. Dumm gelaufen, HTTP funktioniert ja gerade eben nicht… Gut, wenn noch ein weiterer PC lokal vorhanden ist, auf dem schon Flash installiert ist und man von diesem PC aus auf das Webinterface der X Edge zugreifen kann – oder wenn vor der Migration eine Remote Access Regel für Port 8080 (Firewall > Incoming) angelegt wurde, die einem externen Supporter Zugang zu dem Gerät ermöglicht… 😉 Dieser konnte so die “Deny”-Regel für HTTP aus dem Regelwerk löschen, die nun “weiter oben” saß und dadurch den kompletten HTTP-Verkehr verhinderte.

Meine Empfehlung: Prüfen Sie vor der Migration einer X Edge von Version 10 auf Fireware XTM v11.x, ob es Firewallregeln gibt, die auf “Deny” stehen (roter Hintergrund). Wenn es hierfür keinen dringenden Grund gibt, sollten Sie diese Regeln auf “No Rule” setzen (grauer Hintergrund). Nach der Migration wird das Regelwerk wesentlich anschaulicher dargestellt und Sonderregelungen können hier viel einfacher eingebaut werden.

X Edge: Zugriff auf Konfigurationsdatei per FTP

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

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: