Category Archives: Technischer Blog

XTM 11.4: mehr Details zu den neuen Features

Comment

Die Fireware XTM v11.4 befindet sich kurz vor dem Beta-Stadium. Das endgültige Release ist noch für 2010 angekündigt (Dezember). Hier eine aktuelle Zusammenfassung der neuen Features und Produkt-Verbesserungen. Bitte beachten Sie, dass einige Neuerungen NUR für die neuen XTM Hardware Appliances bereitgestellt werden – NICHT jedoch für die bisherigen Produktreihen X Edge e-series, X Core e-series und X Peak e-series…

Application Control: Diese bahnbrechende Funktion ermöglicht, dass speziell der Zugriff auf Web 2.0 Anwendungen wie Facebook, Skype, YouTube, Twitter, Gmail, BitTorrent, MSN, Yahoo Messenger, WebEx, Teamviewer, weitere Instant Messaging und über 1.500 weitere Web Anwendungen wesentlich genauer reglementiert werden kann als bisher. Application Control gibt den Admins also wieder die tatsächliche Kontrolle über die Nutzung ihrer Internet-Bandbreite zurück.

Intrusion Prevention Service: Die Kooperation mit einem neuen Signatur-Anbieter ermöglicht eine eine einfachere Konfiguration, die auch alle Ports und Protokolle scannen kann.

Configuration History und Rollback: Bei Verwendung des WatchGuard Management Servers kann nun auch automatisiert eine gewisse Histore von Konfigurationsdateien verwaltet werden.

In gemanagten Umgebungen (WatchGuard Management Server) können nun wesentlich mehr Features innerhalb von Policy Templates genutzt werden: sowohl globale Einstellungen als auch lokale Einstellungen (z.B. lokale SNAT-Regeln für lokale Mailserver).

Verbessertes Reporting: z.B. Überblick über Application Control und DHCP Leases. Reports können nun bei Bedarf mit einer Zeitsteuerung versehen werden. Auch können Admins per SMTP über die Bereitstellung von neuen Reports informiert werden.

Terminal Services Authentication: Auch dieses Feature ist bahnbrechend! Mit Version 11.4 wird ein neuer Agent bereit gestellt, der auf einem Terminalserver installiert werden kann. Der WatchGuard Firewall werden dann die angemeldeten User und deren Gruppen-Mitgliedschaften gemeldet, so dass session-basiert unterschiedliche Berechtigungsebenen auf dem gleichen Terminalserver realisiert werden können.

Als neues Feature wird die parallele Nutzung von Active Directory-basiertem Single Sign-On und manueller Anmeldung angepriesen, wenn z.B. neben Windows-Maschinen auch Apple Mac und Linux Systeme eingesetzt werden. Dies ist jedoch auch jetzt bereits bei den aktuellen Versionen 11.3.x möglich… Neu ist jedoch, dass auf EINER WatchGuard Firebox auch MEHRERE Active Directory Domains für die User Anmeldung unterstützt werden – und dass für die Abfrage nicht nur klassisches LDAP, sondern aus Sicherheitsgründen auch LDAP-SSL unterstützt wird.

XTM 2 Wireless Appliances bekommen die Möglichkeit, nicht autorisierte (Rogue) WLAN Access Points zu erkennen und zu reporten.

Das WebUI wird erweitert, so dass auch Application Proxy Settings über das Webinterface bearbeitet werden können.

Als weniger wichtig schätze ich ein, dass künfig der “Drop-In-Mode” auch auf Active/Passive Cluster Konfigurationen unterstützt wird – und dass neue XTM Appliances (“out of the box”) auch über den Quick Setup Wizard registriert werden können, wenn dort Benutzername/Kennwort für den WatchGuard LiveSecurity Account eingegeben werden können.

Nachgereicht: Resolved Issues in Fireware XTM 11.3.2

3 Comments

Fireware XTM v11.3.2 behebt einige Probleme, die in früheren Fireware XTM v11.x Versionen gefunden wurden:

General

  • This release resolves a problem that caused excessive CPU usage after multiple PPTP connection attempts. [56005]

Authentication

  • You can now add Single Sign-On exceptions by host range or subnet. [41194]
  • The Single Sign-On agent no longer fails when you have Active Directory groups or users with non-ASCII characters in their names. [41883]
  • A problem that caused the Single Sign-On client to get incorrect group membership information when used with the Microsoft Windows 7 OS has been resolved. [55738]
  • This release includes improvements to the Single Sign-On client and agent software to improve the reliability of group membership retrieval. [44134]
  • The Single Sign-on agent no longer sends login information to the Active Directory server twice. [45292]

Mobile VPN with SSL

  • Mobile VPN with SSL client connections are no longer possible for a user who is not part of the SSLVPN-Users group when you use LDAP for the authentication server. [56462]

FireCluster

  • This release resolves an issue the caused the real MAC address to be used when your Firebox or XTM device is configured for SSL VPN Bridge Mode. [55606]
  • When you configure an active/active FireCluster, the FireCluster management IP addresses are now accessible through a branch office VPN tunnel. [39728]

Logging and Reporting

  • The Log Server no longer stops functioning if a Japanese font appears in the log messages sent from the Management Server. [56593]
  • An email notification is now sent when the Log Server detects that a Firebox or XTM device has stopped sending log messages to the server. [55869]
  • When you reinstall the Report Server, the Log Server database path no longer changes. [56292]
  • If the Log Server is rebooted during the upgrade from Fireware v10.x to Fireware XTM v11.3.2, the database migration now resumes successfully. [56846]
  • The WatchGuard Server Center Setup Wizard no longer fails when you install the Log Server without also installing the Management Server. [56509]
  • A confirmation dialog now shows when you set up the Log Server or Report Server database path. [56516]

WatchGuard System Manager

  • The HTTPS proxy action is no longer blank when you create a new proxy action. [56627]
  • You can now configure up to 200 Traffic Management objects in Policy Manager. [55796]
  • Several improvements have been made to reduce the occurrence of configuration saves that fail with the error: “failed to read servers response: premature EOF”. [40706]
  • Certificate verification no longer fails for Role Based Access Control after a certificate is renewed. [56329]

Web UI

  • You can now release or renew a DHCP lease manually from the Web UI when the external interface is configured to use DHCP. [37478]
  • You can now successfully generate a Mobile VPN with IPSec .ini profile when the group name contains a space. [56537]
  • Policy Based Routing now works correctly when the external interface has a dynamic IP address. [56550]
  • You can now disable Single Sign-On in the Web UI. [56661]
  • You can now select a network subnet or host range when you configure Branch Office VPN tunnels. [44954]

Proxies and Services

  • The default Body Content Types rule for Windows EXE/DLL files has been updated to match a larger class of Windows executable files. This change applies only to new configurations created in Policy Manager using version 11.3.2 or later. The existing configuration on your device does not change when you upgrade from a previous 11.x version. To correct the Body Content Types rule in your existing configuration, go to the Body Content Types category in your HTTP proxy action and edit the Windows EXE/DLL rule. (Note that in Policy Manager, you must be in Advanced View to edit the rule.) Use Pattern Match and for the pattern use: %0x4d5a%* [40799]
  • The default WebBlocker Exception in Policy Manager to always allow WebBlocker categorizations to the WatchGuard web site has been updated to more closely match the WatchGuard domain. This change applies only to new configurations created in Policy Manager using version 11.3.2 or later. It does not apply to the Web UI. The existing configuration on your device does not change when you upgrade from a previous 11.x version. To correct the WebBlocker Exception in your existing configuration, edit your WebBlocker action and go to the Exceptions tab. Edit the WatchGuard exception. Change the “Match Type” to Regular Expression and use this expression: ^[0-9a-zA-Z_-.]{1,256}.watchguard.com/ WatchGuard would like to thank Eric Snyder from Verus Corp in Fridley, MN for bringing this issue to our attention. [44585]
  • The SMTP proxy configuration now includes an option to turn off the logging of denied SMTP Commands. [45119]
  • A problem was resolved that caused HTTP traffic to fail when Gateway AV scanning of HTTP traffic is enabled on Firebox X Edge e-Series devices that run v11.3.2 build 291323. [57372]
  • The Firebox System Manager Subscription Services tab now correctly displays IPS deny totals. [56096]
  • This release resolves a stack trace in the FTP proxy caused by a malformed user command. [56248]
  • When spamBlocker and Allow BDAT chunking are both enabled, the SMTP proxy log file now shows the spam score log message instead of a message that says: SMTP Message classification is unknown because an error occurred while classifying. [56394]

SIP and H323

  • SIP Forking (INVITE) with the same call-id now works correctly. [56000]
  • MSRP file-transfer now works correctly. [55999]
  • RTP packets are no longer sent from the wrong interface when multi-WAN is configured. [44587]
  • The media timeout is now separate from the registration timeout. [55762]
  • SIP registrations no longer fail when the server sends a NOTIFY. [56448]

Branch Office VPN

  • Branch Office VPN tunnels now rekey correctly when the remote side initiates the rekey and 1-to-1 NAT or Dynamic NAT is used within the tunnel. [56599]
  • Traffic log messages now show the source interface of the incoming Branch Office VPN tunnel traffic. [45052]

Networking

  • NAT loopback now works correctly with Server Load Balancing. [41090]
  • When a Firebox or XTM device is configured in drop-in mode with no external interfaces configured, the default route now works correctly. [41802]
  • This release resolves an issue that caused the DHCP Server on the Firebox or XTM device to hand out IP addresses slowly because of DNS host name lookup. [44571]
  • You can now correctly add a secondary address to an external interface when the interface name contains a space. [56439]
  • When you use MAC access control for wireless users and you bridge wireless to your trusted interface, you no longer need to add the MAC address to the trusted interface MAC Access Control list. [41678]
  • When your Firebox or XTM device is configured in bridge mode, MAC access control is now applied correctly to DHCP bootp traffic. [56867]
  • QoS now works correctly with FTP policies. [56266]
  • When you change the wireless configuration on an XTM 2 device, the interfaces no longer go up and down spontaneously. [42300]
  • This release resolves an issue that caused the certd process to use excessive memory. [56181]

XTM: Mobile User verlieren Routing in das lokale Netzwerk

1 Comment

In einem Support Incident hatte ich in den letzten Wochen mit dem Problem zu kämpfen, dass Mobile User, die sich per MUVPN (NCP IPSec Client) oder WatchGuard SSL-VPN-Client einwählen, zwar eine augenscheinlich stabile VPN-Verbindung stehen haben – aber trotzdem nicht auf Resourcen im lokalen Netzwerk zugreifen können.
Die Besonderheit hierbei war jedoch, dass der Zugriff unmittelbar nach der Einwahl möglich war (z.B. Test per “ping -t”) – nach ein paar Sekunden jedoch plötzlich nicht mehr. Ein Vergleich der Routing Table des Einwahl-PCs (“route print”) sofort nach der Einwahl und später nach dem Auftreten des Problems zeigt, dass die Einwahl-Routen in das lokale Netzwerk plötzlich verschwinden, wodurch natürlich nicht mehr auf die internen Resourcen zugegriffen werden kann… Umfangreiche Fehlersuche zeigte auf, dass das beschriebene Problem nur in Kombination aus bestimmten Faktoren auftritt. Reproduzierbar war das Problem insbesondere, wenn auf dem betroffenen Client-PC:

  • Windows XP läuft als Betriebssystem
  • eine Broadcom-Netzwerkkarte eingebaut ist, die IEEE 802.1X Authentication unterstützt (oder ein anderer Hersteller)
  • eventuell begünstigt auch das Vorhandensein des “Novell-Client” auf dem gleichen PC das Problem.

Der Workaround, der das Problem bei dem betreffenden Kunden zunächst umschifft hat (ohne dabei jedoch das eigentliche Problem zu beheben) basiert darauf, unter Systemsteuerung > Netzwerkverbindungen in dem virtuellen Netzwerkadapter, der von dem MUVPN-IPSec-Client (NCP) erzeugt wird, auf dem Tab “Authentication” das Häkchen entfernen bei Enable IEEE 802.1X Authentication:

Das o.g. Häkchen scheint auch bei virtuellen Adaptern automatisch aktiviert zu sein (wie dem IPSec MUVPN-Client und dem WatchGuard SSLVPN-Client), wenn der darunter liegende physikalische Netzwerk-Adapter diese Funktion unterstützt. Nachdem die VPN-Software die Verbindung hergestellt hat, greift offenbar die 802.1X Authentication ein und unterbricht für kurze Zeit die Netzwerkverbindung. Anschließend kommt offenbar zwar die Netzwerkverbindung zurück, aber die Routen sind aus der Routingtabelle verschwunden…

XTM: Ankündigung 11.4 – neue Funktionen

Comment

Im November oder Dezember 2010 wird WatchGuard die neue Version Fireware XTM 11.4 herausbringen. In der neuen Version der XTM Software stecken etliche neue Funktionen:

  • Application Control
  • neue Intrusion Prevention Service (IPS) Engine
  • Terminal Service Authentication
  • Authentication Enhancements
  • Rogue Wireless Access Point detection
  • Multi-Box und Logging Reporting Erweiterungen

Die größte Neuerung ist Application Control. Mit diesem neuen Bestandteil des Security Service Bundles erkennt eine WatchGuard XTM Appliance (Achtung: nur die aktuellen XTM 2, XTM 5, XTM 8 und XTM 1050 Appliances werden diese Funktion unterstützen!) über 1500 Web-Anwendungen innerhalb des üblichen HTTP- und HTTPS-Verkehrs und bietet die Möglichkeit, den Zugriff darauf auf User-Basis, Gruppenmitgliedschaften und der Tageszeit zu steuern (Block oder Allow) und auch entsprechende Reports darüber zu erzeugen.
Das Beta-Programm für die Version 11.4 wird in wenigen Tagen anlaufen, zudem bietet WatchGuard aktuell eine Reihe von Webinaren an, in denen die neuen Funktionen in Live Sessions vorgestellt werden.

XTM: SSO Exceptions jetzt auch als Host Range und Network IP

Comment

Bei einer WatchGuard Firebox oder XTM hat Single Sign On (SSO) in Verbindung mit Active Directory die Aufgabe, automatisch zu erkennen, welcher Windows-User an einem PC angemeldet ist und dies an die WatchGuard Firebox zu melden, damit Firewall-Regeln angewendet werden, die auf einer Gruppenmitgliedschaft oder einem Usernamen basieren. Wie beim händischen Ausfüllen der Authentication Page (Port 4100) lernt die WatchGuard mit Hilfe des SSO Agent (und des optionalen SSO Client) dabei, welcher User sich hinter einer bestimmten IP “verbirgt” und in welchen Active Directory Gruppen dieser User Mitglied ist.

Die automatische Erkennung per SSO macht jedoch nur Sinn bei Standalone-PCs, die Mitglied einer Windows-AD-Domäne sind – und an denen jeweils nur ein User gleichzeitig angemeldet ist. In der Regel ist es empfehlenswert, Maschinen, die kein AD-Domänenmitglied sind oder kein Windows-Betriebssystem haben (z.B. Apple Mac, Linux oder Windows Mobile Clients) sowie Windows-Server von der automatischen User-Erkennung per SSO auszuschließen.

Bislang konnte die Liste der so genannten “SSO Exceptions” nur relativ umständlich befüllt werden. Jede dementsprechende IP-Adresse musste einzeln eingetippt werden. Mit dem aktuellen WatchGuard System Manager (WSM) und Fireware XTM 11.3.2 lassen sich nun auch die von normalen Firewall-Regeln her bekannten Auswahlen Host Range, Network IP und Host Name (DNS lookup) verwenden, was das Befüllen der SSO Exception List in vielen Umgebungen sicher deutlich vereinfachen wird:

Gross-/Kleinschreibung bei Active Directory Authentication

Comment

Wenn Firewall-Regeln auf Basis einer Active Directory Gruppenmitgliedschaft oder eines Active Directory Username geschrieben werden, muss der Name der Gruppe oder des Users auf der WatchGuard zuerst einmal “bekannt gemacht” werden: Setup > Authentication > Authorized Users/Groups. Als “Name” MUSS genau die gleiche Schreibweise bezüglich Groß-/Kleinschreibung verwendet werden mit der die Gruppe bzw. der User im Active Directory angelegt ist (sAMAccountName):


Anderenfalls ist zwar unter Umständen die User Authentication an für sich erfolgreich, jedoch werden dabei nicht die passenden Gruppenmitgliedschaften ausgelesen – entsprechende Firewall-Regeln laufen daher ins Leere. Im Traffic Monitor wird der Traffic zwar als dem User zugehörig angezeigt, aber u.U. eben trotzdem als Unhandled Packet und daher als denied.

Installations-Problem bei WSM 11.3.2

Comment

Mir ist mittlerweile in ein paar Update-Installationen des WatchGuard System Manager (WSM) 11.3.2 aufgefallen, dass der Installer mit einer Fehlermeldung an ein paar Stellen hängengeblieben ist, die etwas mit den Dateien C:ProgrammeGemeinsame DateienWatchGuardwsm11libnlsen_US logging_res.loc und C:ProgrammeWatchGuardwsm11postgresqllib pgevent.dll zu tun hatten. Wenn die Dateien im Hintergrund z.B. im Windows Explorer umbenannt oder gelöscht werden, kann der Installer anschließend fortgesetzt werden…

Active/Passive HA Failover Problem

Comment

In einem Kundenprojekt (zwei XTM 505 in Active/Passive HA) wurde berichtet, dass nach einem Failover von der Primary auf die Secondary Firebox die Systeme in einer DMZ nicht mehr erreichbar wären. Die Systeme untereinander könnten kommunizieren, auch die Systeme im eigentlichen Trusted Network arbeiten korrekt.
Das Problem scheint sich auf einen bereits bekannten Bug zurückführen zu lassen, der dafür sorgt, dass sich nach einem Failover die neue MAC-Adresse des WatchGuard Clusters nicht in die ARP Table der angeschlossenen Client-PCs einträgt (BUG45223). Das Problem soll in einer der kommenden Software-Releases behoben sein.

XCS: DNS-Problem behindert Reputation Authority und DNSBL

3 Comments

Am heutigen Montag, 06.09.2010, trat gegen 10 Uhr ein Problem in der DNS-Zone “borderware.com” auf, weswegen die IP-Adressen der WatchGuard Reputation Authority und der von Borderware und der WatchGuard XCS verwendeten DNSBL-Server nicht mehr aufgelöst werden konnten. Das Problem war zwar kurze Zeit später bereits wieder behoben, wegen des weltweiten Abgleichs der DNS-Resolver kommt es jedoch auch jetzt (19 Uhr) noch zu Problemen, da u.a. auch die bekannten Telekom-Server 194.25.0.52, 194.25.0.60, 194.25.0.68, 194.25.2.129 z.B. den Hostname “www.reputationauthority.org” noch immer nicht auflösen können.

Auf der WatchGuard XCS tritt das Problem unter anderem so in Erscheinung, dass eingehende E-Mails bereits auf dem Connection Layer abgelehnt werden:
connect to mail.xxx.de[xxx.xxx.xxx.xxx]: server refused to talk to me: 550 Client host rejected: [not accepting mail from this ip]

Ich habe das Problem heute auf drei WatchGuard XCS Installationen kurzerhand und vorübergehend so gelöst, indem ich die Überprüfungen anhand der Reputation Authority und DNSBL ausgeschaltet, sowie den internen DNS Cache der XCS disabled habe. Diese Einstellungen werde ich in 1-2 Tagen wieder rückgängig machen, wenn die DNS-Auflösung aller Systeme wieder korrekt funktioniert. Dadurch wird zwar die Spam-Quote in den nächsten 1-2 Tagen geringfügig höher sein, jedoch können jetzt natürlich auch die ganzen legitimen E-Mails wieder zugestellt werden.

Security > Connection Control:
   Reject on Reputation *AUS*,
   Reject on infection *AUS*,
   Reject on DNSBL *AUS*
Activity > Status&Utility > Flush DNS Cache > Flush
Configuration > Interfaces:
   Enable DNS Cache *AUS*

Fireware XTM: HA Cluster Probleme mit MTU Size im BOVPN Tunnel

1 Comment

Ich habe aktuell einige offene Support-Fälle, die folgende Gemeinsamkeiten aufweisen: Active/Passive Cluster unter Fireware XTM v11.3.x, Branch Office IPSec VPN Tunnel zu festen Außenstellen, Kommunikationsprobleme innerhalb des/der BOVPN Tunnel.
In allen Fällen scheinen die Probleme mit fehlerhafter Fragmentierung von IPSec-Paketen zu tun zu haben. Ich konnte etwas ausführlicher debuggen und feststellen, dass bisweilen (also nur zeitweise!) IP-Pakete größer als 1394 Bytes im VPN-Tunnel nicht korrekt fragmentiert, sondern komplett verworfen werden. WatchGuard hat das Szenario im TestLab nachgestellt, konnte jedoch die Fehlerursache bis jetzt noch nicht weiter eingrenzen.
Zur schnellen Dokumentation des Problems verwende ich von einem PC in einer Außenstelle eine MSDOS-Eingabeaufforderung mit dem Befehl

ping [IP] -l 2000 -t

wobei [IP] eine IP-Adresse am anderen Ende eines BOVPN-Tunnels (in der Zentrale) ist. Der Befehl erzeugt Ping-Pakete mit einer Größe von 2000 Byte, die also beim Transport über das Internet zwingend fragmentiert werden müssen, da die maximale MTU Size auf Internet-Routern in der Regel 1500 Bytes beträgt. Erhalte ich korrekte ICMP-Antworten, weiss ich, dass die Fragmentierung korrekt funktioniert. Wenn nicht, liegt ein Problem vor. Durch Verkleinern der Paketlänge kann man sich iterativ an den kritischen Wert herantasten. Im vorliegenden Problemfall werden Pings mit 1394 Bytes korrekt übertragen, Pings mit 1395 Bytes und mehr jedoch NICHT:

Das Problem scheint zudem nur auf dem Rückweg von dem angepingten Host aufzutreten. Offenbar erreichen im Problemfall auch größere Datenpakete den Zielhost, der auch korrekt antwortet – jedoch scheint die WatchGuard Firebox ein Problem mit dem “Rücktransport” der Antwortpakete zu haben, wie sich am Vergleich der folgenden, im Abstand von ein paar Minuten aufgenommenen Screenshots erkennen lässt. Die mit grünen Streifen markierten Werte zählen im Laufe der Zeit korrekt hoch, während der eine rot markierte Wert (RCVD zurück auf dem ursprünglich sendenden System) sich nicht ändert…:

In allen meinen Support-Fällen konnte ich das Problem zunächst durch einen Workaround umgehen: auf dem Cluster Reduktion der MTU Size auf den Interfaces, die an BOVPN-Tunneln beteiligt sind, von 1500 auf 1380 Bytes:

WatchGuard muss jedoch das eigentliche Problem finden und beheben, denn durch den Workaround wird die Gesamtleistung der WatchGuard Firebox etwas ausgebremst.