Tag Archives: Fireware 12

Vorsicht mit Fireware v12.0.1 und M200/M300 (Update)

1 Comment

Heute (09.11.) haben wir auf der WatchGuard Software-Download-Seite für die M200+M300 folgende Meldung entdeckt:

Fireware v12.0.1 Currently Unavailable

We have identified an issue with Fireware v12.0.1 (Build 545166) for Firebox M200/M300 devices that can cause the network interfaces to stop passing traffic after a reboot. We are working on this issue and will provide updated software as soon as possible.

Fazit: Für M200/M300 => bitte vorerst kein Update auf die v12.0.1.
Wir informieren hier, sobald wir neue Informationen haben.
Update 13.11.2017: 
In der Nacht von Freitag auf Samstag (MEZ, 10.11.) wurde von WatchGuard das Update veröffentlicht.
Bitte beachten prüfen Sie die Build-Nummer: Nur Build 546110  sollte verwendet werden.

Zu beachten beim Upgrade einer XTMv von 11.x => 12.x

Comment

beim Upgrade einer XTMv kann es passieren, daß auf einem oder mehreren Interfaces keine Kommunikation mehr stattfindet. Der Grund hierfür liegt darin, daß die Erkennung der Interface-Reihenfolge bei der XTMv geändert wurde.

Aus dem Artikel aus der Knowledgebase:

On a FireboxV or XTMv on a VMWare ESXi server, after you upgrade from Fireware v11.x to v12.0, communication might be lost on one or more interfaces.

In Fireware v11.x and lower, Firebox interfaces correspond to ESXi interfaces based on the order in which ESXi interfaces become active.

In Fireware v12.0, Firebox interfaces correspond to ESXi interfaces based on the MAC address value of the ESXi interfaces. For example, the lowest ESXi MAC address is assigned to Firebox eth0, and the next lowest MAC address is assigned to eth1.

Empfohlener Workaround:

Before you upgrade from Fireware v11.x to v12.0, configure the ESXi MAC addresses in increasing order by the ESXi interface number. This ensures that the Firebox interfaces correspond to the ESXi interfaces in increasing order.

 

Trennung der SSLVPN- und Authentication Login-Seiten

Comment

WatchGuard hat mit Fireware 11.12.2 das Authentication Portal (üblicherweise auf Port 4100) noch weiter vom SSLVPN-Portal abgetrennt. Bei älteren Fireware Releases war es möglich, über https://[IP-der-Firebox]/sslvpn_logon.shtml die SSLVPN-Login-Seite aufzurufen und über https://[IP-der-Firebox]/logon.shtml die Login-Seite für die normale User Authentifizierung an der Firewall – unabhängig davon, welcher Port (4100/Authentification oder 443/SSLVPN bzw. anderer eingestellter Port) aufgerufen wurde. Die saubere Trennung der beiden Dienste führt nun einerseits zu einer erhöhten Sicherheit, ist aber möglicherweise für den einen oder anderen etwas hinderlich. Beispielsweise wenn jemand, der die Authentifizierung von External nutzen soll, an seinem aktuellen Internet-Zugang nicht über Port 4100 ins Internet hinaus darf. Hier war es extrem praktisch, die Authentifizierung eben auch auf dem üblicherweise in ausgehende Richtung offenen Port 443 ansprechen zu können.

Folgende Workarounds können nun eingerichtet werden:

  • Falls der Port 443 noch gar nicht verwendet wird: Einrichten eines SNAT von Any-External an IP:443 mit Weiterleitung an die interne IP der Firewall auf Port 4100!
  • Falls der Port 443 bereits für SSLVPN verwendet wird: Sekundäre IP für den o.g. SNAT verwenden, sofern vom Provider mehrere externe IPs zur Verfügung gestellt werden
  • Evtl. SSLVPN auf einem anderen Port als 443 betreiben, um den Port 443 für User Authentication freizuschalten. Hier verlagert man das Problem aber nur, denn wenn SSLVPN z.B. auf Port 444 umkonfiguriert wird, dann müssen eben mögliche SSLVPN-Nutzer an deren Standort eben auch über diesen Port 444 ins Internet hinaus können…

Falls der externe Port 443 bereits für Microsoft Outlook Web Access (OWA) oder einen anderen Dienst (interner Webserver mit HTTPS) für die Weiterleitung nach innen benutzt wird, hilft hierbei künftig eventuell ein für Fireware 12.x angekündigtes neues Feature: Host Header Redirection. Mit diesem Feature soll es möglich werden, auf der WatchGuard Firewall ein Multidomain/SAN-Zertifikat zu installieren und dann abhängig vom jeweiligen Hostnamen auf unterschiedliche interne IPs weiterzuleiten. Leider wird hier nach meinem Kenntnisstand SSLVPN außen vor bleiben.

Point-to-Point Tunneling-Protokoll (PPTP) entfällt bei Fireware 12.x

1 Comment

Was ist PPTP?
Das Point-to-Point Tunneling-Protokoll (PPTP) ist eine inzwischen veraltete Methode zur Implementierung von VPN-Netzwerken. Es wurden massive Sicherheitslücken festgestellt, die – insbesondere bei fehlerhafter Konfiguration – von Angreifern ausgenutzt werden könnten, um Kennwörter im Netzwerk auszuspähen, das VPN-Verschlüsselungsschema zu knacken und so an vertrauliche Daten zu gelangen.

Mobile User VPN mit PPTP ab Fireware 12.x nicht mehr möglich
Wegen dieser Sicherheitsbedenken gegenüber PPTP hat WatchGuard entschieden, PPTP-VPN bei den kommenden Fireware-Betriebssystemversionen ab Version 12.x nicht mehr anzubieten. Die Version 12.0 befindet sich derzeit im Beta-Stadium, die öffentliche Verfügbarkeit ist für September 2017 geplant.

WatchGuard Kunden, die derzeit noch Mobile User VPN mit PPTP verwenden, sollten schon jetzt auf eine der anderen in der WatchGuard enthaltenen VPN-Technologien mit höherer Sicherheit zu wechseln: IPSec-VPN, SSL-VPN und L2TP-VPN. Der Umstieg zu L2TP-VPN ist dabei am einfachsten, da hierfür keine separate VPN-Client-Software installiert werden muss, weil die Client-Komponenten wie bei PPTP in den gängigen Betriebssystemen wie Windows, iOS und Android bereits integriert ist. Im WatchGuard Support Center finden Sie einen Artikel zum Thema Migration von PPTP zu L2TP.

Fireware 12.0 kommt mit neuer Gateway AntiVirus-Engine

2 Comments

Neue Gateway AntiVirus Engine von BitDefender

WatchGuard hat turnusmäßig seine Antimalware- und Gateway AntiVirus-Technologie (bislang vom Hersteller AVG) einem umfassenden Check unterzogen, um sicherzustellen, dass den Kunden weiterhin die bestmögliche Lösung geboten wird. Die Ergebnisse haben WatchGuard dazu veranlasst, den Technologiepartner hinter dem Gateway AntiVirus Service zu wechseln. Die neue Engine wird von BitDefender bereitgestellt.

Die Änderung tritt mit der Fireware-Betriebssystemversion 12.0 in Kraft, die erstmals ab September 2017 bereitgestellt werden soll. Die Versionen Fireware 11.x verwenden nach wie vor die AVG Engine und die AVG Signaturen. Der Update-Service für die AVG Signaturen wird aber zum 15.01.2018 eingestellt, so dass der GAV-Service dann deutlich eingeschränkt wäre. Es ist also anzuraten, vor dem 15.01.2018 von Fireware 11.x auf eine neuere Version von Fireware 12.x zu wechseln. Alle derzeit unterstützten XTM- und Firebox Appliances können auf Version 12.0 umgestellt werden – mit Ausnahme der Modelle XTM 505, XTM 510, XTM 520 und XTM 530, die ohnehin am 3. Dezember 2017 auslaufen.

Gründe für die Auswahl von BitDefender waren unter anderem:

  • Bessere Erkennungsleistung über das gesamte Portfolio. Als Pionier auf dem Gebiet des maschinellen Lernens zur Erkennung von Schadsoftware erreicht BitDefender in unabhängigen Tests unbestritten Platz eins im Hinblick auf Bedrohungserkennung, Reduzierung von False-Positives und hoher Systemleistung.
  • Schnellere Reaktion bei auftretenden Bedrohungen. BitDefender führt Signaturaktualisierungen in sehr kurzen Abständen durch. Auf diese Weise sind Kunden so früh wie möglich gegenüber neuen Bedrohungen geschützt.
  • Höhere Performance durch optimiertes Scannen von .exe-, Microsoft Office- und PDF-Dateien.

Wichtig zu wissen:

  • Beim Wechsel auf Fireware 12.0 erfolgt die Umstellung auf die neue Gateway Antivirus Lösung automatisch.
  • Kunden, die dennoch auf einer Fireware 11.x-Version bleiben, erhalten ab 15.01.2018 keine Aktualisierungen für den Gateway AntiVirus Service mehr.