Mit der der Version 11.12 (etwa Dezember 2016), führte WatchGuard das Feature Geolocation ein. Mit diesem Feature ist es möglich, IP-Adressen aufgrund der Herkunft auszusperren. Allerdings kann man durch Fehlkonfiguration auch sich selbst aussperren.
Heute (16.10.2017) geht eine Meldung um die Welt, die bei allen Wi-Fi-benutzern für Aufhorchen sorgt: Es gibt in den Protokollen WPA und WPA2 einige Fehler, die herstellerübergreifend fast jegliche Wi-Fi Kommunikation betrifft. Die Fehler sind in Standard-Libraries der WPA- und WPA2 Protokolle enthalten und daher praktisch überall anzutreffen.
Unter bestimmten Umständen kann es möglich sein, WPA- und WPA2-Verschlüsselungen auszuhebeln, da der Fehler bereits im 4-Way-Handshake der Protokolle enthalten ist, also dort, wo die Schlüssel für die Verschlüsselung erzeugt werden. Es geht soweit, daß der Wi-Fi-Datenstrom abgefangen, entschlüsselt und ohne Kenntniss des Users modifiziert werden kann.
Der Artikel beschreibt weitere Details und Firmware-Release-Dates der Access-Point Firmware.
In diesem Blog-Artikel zeigen wir Ihnen wie Sie ganz bequem unseren Blog per RSS-Feed abonnieren und verfolgen können. So bleiben Sie immer informiert, wenn neue Firmware-Releases veröffentlicht oder spannende Artikel auf unserer Website bereitgestellt werden.
Weiterlesen
WatchGuard Fireware v12.0 ist ein signifikantes Release Update. Das Release beinhaltet viele neue Features und Erweiterungen, die im Folgenden aufgelistet werden:
Der Open Beta Zeitraum der WatchGuard Fireware 12.0 ist vorbei, das offizielle Release ist im Software Center von WatchGuard verfügbar.
In der Beta haben über 900 Teilnehmer das Release 12.0 und die neuen Features getestet.
Kurzzusammenfassung der Neuerungen: Weiterlesen
Der von vielen Kunden als Ping zur Leitungsüberwachung genutzte DNS-Server 194.25.0.60 der Telekom antwortet heute (11.08.2017) nicht auf Ping (Anm.: seit dem Abend geht es wieder).
Problematik: Multi-WAN bei WatchGuard benötigt eine Ziel-IP für einen Ping-Check (Network > Configuration > Multi-WAN). Hier wird häufig ein gängiger DNS-Server des zuständigen Internet-Providers eingetragen, weil dieser in der Regel hoch performant und hochverfügbar ausgelegt ist. Wenn die an dieser Stelle eingetragene IP-Adresse jedoch nicht mehr auf Ping reagiert, “denkt” die WatchGuard, dass die Leitung nicht mehr verfügbar ist und schaltet das Interface in den Status “External:Failed” und damit logisch auf DOWN. Das bedeutet, dass das Interface für ausgehenden Verkehr nicht mehr verfügbar ist – obwohl die Leitung selbst technisch völlig in Ordnung ist.
Best Practice:
Wir können hier keine allgemein glücklich machende Antwort geben. Wir schlagen vor, beim zuständigen Leitungsprovider (es können ja auch mal mehrere Leitungen von verschiedenen Providern an einer WatchGuard angeschlossen sein…) eine oder mehrere IP-Adresse(n) aus dessen Backbone zu erfragen und zu verwenden, die
Verwenden Sie NICHT IP-Adressen eines anderen Providers (Sie wollen ja die Anbindung an den eigenen Provider testen und nicht das weitere Routing/Peering zu einem anderen Provider. Daher sind auch die allseits bekannten öffentlichen DNS-Server von Google (8.8.8.8 und 8.8.4.4) keine besonders guten Ideen.
Verwenden Sie NICHT die gleiche Test-IP-Adresse für mehrere External Interfaces. Sollte genau diese IP-Adresse tatsächlich einmal nicht erreichbar sein, wie jetzt im Falle des Telekom DNS-Servers 194.25.0.60 geschehen, gehen im Extremfall gleichzeitig ALLE Leitungen auf DOWN und Sie bewirken damit das genaue Gegenteil des eigentlichen Redundanz-Gedankens.
Nutzen Sie in der Multi-WAN Konfiguration auf jeden Fall die Möglichkeit, explizite Test-IP-Adressen einzutragen. Wenn Sie nämlich den System Default belassen = KEINE explizite Test-IP eintragen, dann wird standardmäßig das Default Gateway der jeweiligen Leitung überwacht/angepingt. Bei Static IP, also einer Standleitung mit einem vom Provider bereitgestellten Router mit einem öffentlichen IP-Subnetz ist das Default Gateway aber eben genau dieser Router. Weil sich dieser Router aber (i.d.R.) in Ihrem eigenen Hause befindet und immer antworten wird, liefert er also keine sinnvolle Aussage, ob die Internet-Leitung funktioniert oder nicht.
Bei DSL-Anschlüssen der Deutschen Telekom kommt sogar noch eine weitere Problematik dazu. Das Default Gateway einer DSL-Leitung wird erst nach erfolgreicher Einwahl dynamisch zugewiesen. Leider haben bei der Telekom aber genau diese Systeme die unangenehme Eigenschaft, dass sie überhaupt nicht auf Ping antworten! Wenn also keine explizite Test-IP eingetragen ist, wird eine solche Leitung im Multi-WAN-Betrieb immer als External:Failed angezeigt werden und steht daher auch nicht für WAN Failover Szenarios zur Verfügung…
Jedem selbst überlassen bleibt auch die Einschätzung, ob es statt Ping (oder zusätzlich zu Ping) sinnvoll ist, die Alternative zu nutzen, nämlich per TCP Connect z.B. den Port 80 eines hochverfügbaren Webservers zu prüfen. Bedenken Sie dabei aber bitte auch, wenn Sie hier mit einem Hostnamen arbeiten z.B. www.google.de, dass in diesem Fall die WatchGuard diesen Namen vorher auch noch per DNS auflösen können muss. Besser wäre allemal, auch hier mit einer IP-Adresse statt eines Hostnamens zu arbeiten…
Laut einer Pressemeldung vom 08. August 2017 übernimmt WatchGuard die Firma Datablink.
Datablink hat verschiedene Authentisierungs-Lösungen im Angebot:
WatchGuard beabsichtigt, Datablink Advanced Authentication im Jahr 2018 als vollständige Cloud-Lösung anzubieten.
Weiterführende Links:
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.
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:
Wichtig zu wissen:
Seit heute ist das Fireware Release v11.12.4 verfügbar. Weiterlesen
