Category Archives: Technischer Blog

Neuer 3G / UMTS-Router von WatchGuard

Der im Herbst 2008 angekündigte 3G Extender (UMTS-Router zum Einsatz “vor” der Firebox) gelangte in Europa nie zur Auslieferung, da er nicht über das CE-Zeichen verfügte. Seit Juli 2009 ist jetzt ein neuer 3G Extender (UMTS-Router) für ca. 150-200 Euro bestellbar (WG8650). Das neue Produkt verfügt über einen PC-Express Slot und einen USB-Anschluss, so dass dort entweder ein UMTS-Modem in PC Express Bauform oder als USB-Stick verwendet werden kann (stellt im Regelfall der jeweilige Mobilfunkanbieter im Rahmen eines Mobilfunk-Datenvertrags zur Verfügung). Damit können auch Lokationen ans Internet und per VPN an das Firmennetzwerk angebunden werden, an denen kein DSL/Telefonanschluss zur Verfügung steht oder die nur temporär genutzt werden. Auch der Einsatz in Kiosken oder Verkaufsautomaten ist denkbar. Weiterhin kann im Multi-WAN Betrieb hierüber eine Backup-Anbindung ans Internet realisiert werden, die nur im Bedarfsfall genutzt wird (Voraussetzung Edge Pro bzw. Fireware Pro Erweiterung).

WatchGuard Ersatzteile einzeln bestellbar

In der aktuellen Preisliste tauchen folgende Ersatzteile auf, die eine eigene Bestellnummer haben und somit auch einzeln bestellbar sind:

  • WG8530 19″ Rackmount Kit für alte Firebox X Serie
  • WG8531 19″ Rackmount Kit für aktuelle X Core / X Peak
  • WG8532 Kabelsatz für aktuelle X Core / X Peak
  • WG8533 Ersatz-Netzteil für X Edge e-series !!!!!
  • WG8534 Ersatz-Antennen für X Edge e-series (nur -W)

Damit schließt sich eine Versorgungslücke, denn auch in meiner Praxis kommt es regelmäßig vor, dass nach 19″-Winkeln und Ersatz-Netzteilen gefragt worden ist.

WSM und Fireware 10.2.9 verfügbar

Im Software Download Bereich steht seit heute die Version 10.2.9 für Kunden mit aktiver Live Security zur Verfügung. Die Release Notes geben Aufschluss über Bugfix und neue Features:

Server Load Balancing (SLB) and VPN

  • A Firebox configured for server load balancing no longer stops sending traffic to a healthy server because of quick continuous requests, a missing route to a dead server, or interference from other SLB policies [35761]
  • A Firebox configured for server load balancing now considers a server as active as soon as it can set up a connection with the server, instead of waiting for three successful tries. [35550]
  • A problem that caused an IKED runtime crash with a pstack call “trace EIP:e045684d” is fixed. [32966, 36424]
  • The Mobile VPN with SSL client can now resolve host names on an internal DNS server. [28120]
  • If you have configured two DNS or WINS servers, both IP addresses are now assigned correctly to Mobile VPN clients (IPSec and PPTP). [12575, 33904]
  • A problem that caused an error “HTTP response code: 500 for URL: https://x.x.x.x:4117/cmm/cmd” when you saved a configuration in which Mobile VPN with SSL is enabled has been fixed. [28105]

High Availability

  • The primary HA Firebox no longer stays in the “in-transition” state indefinitely after you do an HA sync operation just after you save your configuration. [36033]
  • HA sync now completes successfully when two HA ports are used. [30207]
  • You can now use WSM to quickly create successive tunnels on Fireboxes in an HA pair and not lose management access. [36007]
  • VRRP logging messages no longer show in the log file unless the appropriate log level has been set. [35763]

Single Sign On

  • You can now install the SSO client on Windows Vista. [35869]
  • When you enable SSO, you can now obtain group information even if the SSO agent is not installed on the Domain Controller. [36043]
  • When you install the SSO client on Vista, you can now see the build number. [36289]
  • SSO client and agent communication is now more reliable and several timeout issues have been resolved. [35199, 35200]
  • SSO now ignores group names exceeding 32 characters and continues to process other group names. It no longer returns a “domain name str too log” error. [35988]

WSM Management

  • WSM no longer displays a device as “Pending” when it is not. [36080]
  • WSM can now handle different devices with identical IP addresses. It no longer shows a “Maintenance Alert” warning for these devices. [36068]
  • LogViewer can now display SMTP and POP3 log messages whose headers are encoded in ISO-2022-JP. [33460]
  • Firebox System Manager and Policy Manager now show and error that says “Invalid login/password” instead of “No SID” when users enter the wrong password when downloading a configuration, downloading a feature key, or during a system backup. [36959]
  • Service Watch can now reliably connect to the Firebox when there are a large number of policies. [37142]

Proxy

  • The Application Blocking feature now blocks the most recent versions of Yahoo! Messenger. [36268]
  • The Firebox now supports more than 1000 FTP proxy connections. [35998]

Neues Produkt: WatchGuard SSL 100

In Kürze wird eine neue SSL-VPN Appliance lieferbar sein: die WatchGuard SSL 100. Das Produkt basiert auf der Technologie der bekannten SSL 500 und SSL 1000, ist für den Betrieb von maximal 100 parallelen SSL-VPN Sessions ausgelegt und kommt standardmäßig mit einer Lizenz für 25 concurrent sessions. Diese Zahl kann schrittweise auf bis zu 100 erhöht werden. Preise sind leider noch nicht bekannt, werden aber sicher mit der nächsten Preisliste Anfang Juni kommuniziert. Das Produkt und die Optionen sind ab sofort bestellbar.

E-Mails ohne Datum und Uhrzeit (POP3-proxy)

Gelegentlich kommt es vor, dass der POP3-proxy zur Abholung von E-Mails bei einem externen Provider eingesetzt wird. In Verbindung mit den UTM Services Gateway Antivirus und spamBlocker macht das natürlich Sinn. spamBlocker kann bei POP3 jedoch nur mit der Option “Tagging” verwendet werden, also das Schreiben eines Zusatzes in die Betreffzeile, z.B. [SPAM?]. “Deny” macht technisch keinen Sinn, da die E-Mails ja bereits auf dem zuständigen Mailserver beim Provider stehen und dort auch abgeholt werden müssen. “Quarantine” wäre technisch zwar denkbar, steht bei POP3 aber leider auch nicht zur Verfügung.

Wenn der POP3-proxy mit seinen Default-Einstellungen verwendet wird, führt dies mitunter dazu, dass die abgeholten E-Mails ohne Sende-Datum/Uhrzeit im Mailclient (z.B. Outlook) angezeigt werden (“Keine Angabe”). Dies liegt dann vermutlich daran, dass der diesbezügliche Header vom POP3-proxy entfernt wurde, weil er nicht auf der Allow-Liste steht. Fügen Sie in diesem Fall einmal den Wert Date:* in die Liste der erlaubten Header ein.

Sollten Sie ein ähnliches Problem haben – irgendetwas geht bei Verwendung des POP3-proxy nicht mehr, das aber vorher mit einem POP3 Paketfilter geklappt hat – dann ist es sicher eine gute Idee, das Häkchen bei “Log” neben der “Strip” Action zu setzen und im Traffic Monitor mitzuverfolgen, welche eventuell doch benötigten Header noch auf der Strecke bleiben. Diese können dann in die Allow-Liste eingepflegt werden. Auch ein Blick in die “Header”-Sektion des SMTP-proxy (!) und ein entsprechender Vergleich lohnt sich gegebenenfalls…

SSL-VPN bei Multi-WAN auf einer X Edge

Bei Vorhandensein der Edge Pro (Standard bei X55e, Nachrüst-Option bei X10e und X20e) können beide WAN-Anschlüsse der X Edge (WAN1 und WAN2) mit einem Internet-Anschluss belegt werden (z.B. zweimal aktives DSL für Multi-WAN oder einmal DSL und einmal UMTS als Fallback).

Obwohl die GUI auch andere Einstellungen zulässt, terminieren VPN-Verbindungen immer auf WAN1, solange WAN1 aktiv ist. Insofern handelt es sich bezüglich VPN bei WAN2 um ein reines Failover-Interface. Hat man die Konstellation, dass z.B. zunächst auf WAN1 ein normaler ADSL-Anschluss liegt (z.B. T-DSL 6000 mit 512 kBit Upload) – und nach einiger Zeit kommt ein SDSL-Anschluss hinzu (2 Mbit symmetrisch), der gerade wegen des höheren Upload für VPN-Verbindungen genutzt werden soll – sollte man die External Interface neu zuordnen, so dass der SDSL auf WAN1 und der ADSL auf WAN2 zu liegen kommt.

Im Falle von Mobile User SSL-VPN kann man eine Primary IP und eine Secondary IP angeben. Hierbei sollte Primary immer die WAN1-IP sein (bzw. der DYNDNS-Hostname) und Secondary immer die WAN2-IP. Der Client ist zwar in der Lage, die Secondary IP zu connecten und bekommt von dort auch die VPN-Konfig zugewiesen, die eigentliche VPN-Verbindung wird dann aber zu der Primary IP (sprich WAN1) aufgebaut, solange dieses Interface aktiv ist. Sind die IPs vertauscht oder wird z.B. nur die WAN2-IP in die Konfiguration eingetragen, kommt keine Verbindung zustande. Der Client zeigt im Log die Fehlermeldung “Connection refused (WSAECONNREFUSED)” und steht im Logon-Fenster in einer Endlosschleife “Paused, waiting 5 seconds”.

Support kennt hierzu auch ähnliche Berichte aus der Praxis:
BUG30110: Cannot construct SSL VPN and MOVPN on WAN2 while WAN1 is up und BUG23704: Cannot construct a tunnel on WAN2 while WAN1 is up. Diese wurden aber abgeschlossen mit dem Hinweis, dass dieses Verhalten “normal” und “by design” ist.

Preview zu WSM und Fireware XTM 11

Die Version Beta 4 ist da. Bis zum eigentlichen Release werden nun also wohl noch etwa 4-6 Wochen vergehen. XTM (Extensible Threat Management) setzt natürlich auf UTM (Unified Threat Management) auf und erweitert diesen Begriff um “Erweiterbarkeit” in den Bereichen Sicherheit, Netzwerk Features und flexibleres Management.

Wichtigste Neuerung ist, dass das neue Betriebssystem Fireware XTM 11 auf allen bisherigen e-series Boxen (also auch auf der X Edge!) und der neuen XTM 1050 laufen wird. Es wird also künftig für alle WatchGuard Boxen ein einheitliches Betriebssystem geben. Im kernelnahen Bereich wurde ein ganz neues Software Design angewendet, um überhaupt für die gestiegenen und künftig noch weiter steigenden Performance-Anforderungen an eine Security Appliance gewappnet zu sein.

Zu einem höheren Maß an Sicherheit werden beitragen: HTTPS content inspection – ja, ein HTTPS-Proxy, der in SSL-verschlüsselten Traffic hineinsehen kann; ein neuer OEM-Partner für Antivirus Engine und Signaturen (AVG); bessere Unterstützung für VoIP und verbesserte Einstellmöglichkeiten für IPS (Intrusion Prevention Service).
Bei den neuen Netzwerk Features wäre insbesondere FireCluster zu nennen, der neue Name für den neuen Active/Active Cluster Mode, des weiteren der neue Bridge Mode, VLAN auf externen Interfaces, MAC Access Control. Die Interfaces der X Edge werden künftig wie bei der X Core weitgehend frei verwendbar sein, die Namen WAN1, WAN2, OPT und LAN0-2 werden weitgehend bedeutungslos und durch eth0, eth1, eth2 und eth3 ersetzt. Innerhalb von Branch Office VPN Tunneln (BOVPN) können Regeln nun auch mit einer zeitlichen Begrenzung versehen werden, auch Traffic Management, QoS und Priorisierung innerhalb des VPN-Tunnels wird möglich, ebenso wie Dynamic NAT.
Für SSL-VPN entfällt die Notwendigkeit von Port 4100 tcp, die gesamte Verbindung läuft über Port 443 tcp.
Flexibleres Management wird insbesondere dadurch erreicht, dass zum einen künftig alle Boxen (also auch die X Edge!) über den WSM / Policy Manager administriert werden können. Alle Boxen (also auch X Core und X Peak!) können künftig aber auch über Web-Interface und weitestgehend auch über CLI (Command Line Interface) konfiguriert und verwaltet werden.

Weitere kleine Nettigkeiten sind: WebBlocker Override Passwort auch bei X Core und X Peak (bisher nur bei X Edge); deutlich verbessertes Logging und Reporting (mehr Performance und braucht weniger Resourcen); nur noch ein Einstiegspunkt WatchGuard Server Center in die Verwaltung der Server Services; HostWatch zeigt für jede einzelne Verbindung an, wie viel Bandbreite verbraucht wird – die Liste kann sogar nach dieser neuen Spalte in absteigender Reihenfolge sortiert werden 🙂

Der WSM 11 wird auch Fireboxen mit Fireware 10.x verwalten können. Dies ermöglicht in meinen Augen für den Anfang einen interessanten Mischbetrieb: die verbesserten Möglichkeiten des WSM 11 (speziell Logging und Reporting) in Verbindung mit der letzten stabilen 10-er Version auf der Firebox selbst. Die Version 11 wird im Rahmen der Live Security kostenfrei zum Download angeboten, kann aber nur installiert werden, wenn auf der Firebox ein gültiger Feature Key vorhanden ist.

Lock / Unlock bei SMTP E-Mails

Der SMTP-proxy verfügt im Bereich Attachments sowohl bei Content Types als auch bei Filenames über die Optionen Allow, Lock, AV Scan, Strip, Drop und Block im Pull-Down-Menü Actions to take. Wurde zur Steuerung von unerwünschten E-Mail-Anhängen vom Default Strip (Herausschneiden und Löschen) abgewichen und die Option Lock gewählt, werden Dateianhänge, auf die ausgewählten Kriterien passen, von der WatchGuard Firewall “ge-locked”.

Im Detail passiert folgendes: die Datei wird binärtechnisch leicht verändert, es werden ein paar Byte vor und hinter die Datei gehängt. Außerdem wird der Dateiname um die Endung .clk ergänzt (cloaked). Die Datei hängt aber nach wie vor an der eigentlichen E-Mail dran und erreicht auch das Postfach des Empfängers. Versucht nun der Empfänger, die Datei mit Doppelklick zu öffnen, schlägt dies fehl. Dies ist auch so beabsichtigt! An die E-Mail wird eine zusätzliche Textdatei angehängt, die die bei Deny Message definierte Fehlermeldung beinhaltet. Der Standardtext lautet: “The WatchGuard Firebox that protects your network has detected a message that may not be safe. […] Your network administrator can unlock this attachment.” Außerdem finden sich nähere Angaben über die Datei und den Grund.

Die Option Lock gibt es schon seit über zehn Jahren bei WatchGuard-Produkten. Die theoretische Denke dahinter ist auch genau so alt: der Empfänger speichere die ge-lockte Datei z.B. auf ein transportables Speichermedium (Diskette, USB-Stick) und gehe damit zu seinem Systemadministrator. Dieser starte in einer MSDOS-Eingabeaufforderung auf einem – separat vom lokalen Netzwerk stehenden und mit einer aktuellen lokalen Antivirus-Software ausgestatteten – PC das kleine Hilsprogramm unlock.exe, das sich im Verzeichnis C:ProgrammeWatchGuardwsm10.2bin befindet und entpackt dadurch die .clk-Datei in den Urzustand, woraufhin sie mit der Antivirus-Software untersucht und bei Unbedenklichkeit an den eigentlichen Empfänger ausgehändigt werden kann. Abwandlungen in der einen oder anderen Form gestattet… 🙂

Auch das Gateway Antivirus-Subsystem kann die Option Lock nutzen, entweder wenn bereits tatsächlich ein Virus in der Datei gefunden wurde – oder wenn ein Scan Error aufgetreten ist, also die AV Engine die Datei nicht scannen konnte. Das ist übrigens auch dann der Fall, wenn die Datei verschlüsselt ist – und sei es nur eine ZIP-Datei, die mit einem Kennwort versehen wurde. Klar – eine verschlüsselte Datei kann erst dann auf Viren gescannt werden, wenn sie korrekt entschlüsselt wurde. In einem solchen Fall kann man natürlich der lokalen Antivirus-Software auf dem PC des Empfängers vertrauen und anstelle von Lock die Option Allow wählen – oder man nutzt die Option Lock und überläßt zumindest das Entpacken dem Administrator…