Mit dem Release der Fireware v12.10.4 wurde ein lange erwartetes Feature realisiert: das Blocken der IP-Adressen bei Fehlversuchen für z.B. SSLVPN-Login. Das Feature wird gerne auch unter dem Stichwort “fail2ban” gesucht – nach dem bekannten Paket, das in jeder Linux-Distro enthalten ist.
WatchGuard DNSWatch ist ein cloud-basierter Dienst, der Filter auf DNS-Ebene hinzufügt, um potenziell gefährliche Verbindungen zu erkennen und zu blockieren und Netzwerke und Mitarbeiter vor schädlichen Angriffen zu schützen. WatchGuard-Analysten sichten alle wichtigen Warnungen und verfassen einen leicht verständlichen Bericht, der detaillierte Einblicke in potenzielle Infektionen gibt. Wenn der Angriff Phishing verwendet und ein Mitarbeiter auf den Link klickt, wird er von DNSWatch automatisch von der schädlichen Seite weggeleitet und erhält weitergehende Informationen zum Thema Phishing.
Leider bietet nicht jedes DNSWatch-Szenario einen Fallback für externe DNS-Anfragen. Im Falle eines DNSWatch-Ausfalles werden externe DNS-Anfragen nicht mehr beantwortet.
In diesem Blog-Artikel möchten wir ein ein Best-Practice-Szenario vorstellen, welches die Ausfallsicherheit in Verbindung mit DNSWatch gewährleistet. Weiterlesen
In diesem Blog-Artikel geht es um die Auswirkungen und Folgen bei einem Wechsel einer lokal verwalteten Firebox (WatchGuard System Manager, der WebUI oder einem WatchGuard Management Server) zu einer Cloud-Verwaltung.
Es ist wichtig zu wissen, dass bei einem solchen Wechsel die bestehende Konfiguration gelöscht wird:
Das bedeutet, Ihre Firebox erhält eine minimale Cloud-Konfiguration und muss anschließend neu konfiguriert werden. Ein Upload Ihrer vorhandenen Konfiguration (*.xml) ist nicht möglich. Die Cloud-Konfiguration gleicht der einer lokal verwalteten Firebox nach dem Ausführen des Setup Wizard. Weiterlesen
Im Rahmen der Brute-Force-Angriffe auf das WatchGuard SSLVPN Portal haben wir ein Proof of Concept Setup mit einer externen Linux-VM gebaut, um IP-Adressen nach mehreren fehlerhaften Login-Versuchen auf die WatchGuard-eigene auto-blocklist zu setzen.
Die benötigten Scripte und Snippets sind unter der MIT-License auf Github veröffentlicht: https://watchguard-toolbox-project.github.io/
Update Fireware 12.10.4: Mit dem aktuellen Fireware-Update (Version 12.10.4) kann auch das jetzt integrierte Feature “Block Failed Logins” verwendet werden.
Eine ausführliche Anleitung dazu finden Sie in diesem HOWTO-Artikel.
Gilt für WatchGuard Advanced EPDR, EPDR, EDR, EPP sowie die ehemalige Panda Welt (AD360 & Co.).
Mit dem Zusatzmodul WatchGuard Patch Management ist es möglich, schnell und einfach Patches von Microsoft, Linux und macOS, sowie Third-Party Anwendungen (Patch-Library) zu installieren.
Der folgende Artikel beschreibt die automatische Installation von kritischen und wichtigen Sicherheitsupdates für Microsoft und Third-Party Anwendungen.
In diesem Blog-Artikel geht es um die Auswirkungen bei einem Trade-Up für Firebox Appliances, die in der WatchGuard Cloud eingebunden sind. Logging & Reporting und auch AuthPoint-Integrationen funktionieren nach dem Trade-Up möglicherweise nicht mehr, weil die „alte“ Appliance aus der WatchGuard Cloud entfernt wird. Da die alte Firebox nach der Trade-Up-Aktivierung nicht in der WatchGuard Cloud verfügbar ist, können Sie die alte Firebox-Konfiguration auch nicht auf das neue Gerät kopieren (nur bei cloud-managed Fireboxen). Im Folgenden beschreiben wir wie Sie diese Problematik umgehen können.
Aktuell sehen wir in den Logs vieler Kundenfirewalls Brute-Force-Attacken auf den WatchGuard SSLVPN bzw. das dazugehörige SSLVPN Portal (https://<Ext.-IP>/sslvpn_logon.shtml).
Die Logs zeigen, dass die Angreifer nicht nur Benutzernamen und Passwörter „raten“, sondern auch gezielt die Anmeldeserver des SSLVPN Portals auslesen. Neben typischen Benutzernamen werden so auch alternative Anmeldeserver angesprochen, welche ggf. keine MFA (Multifaktor-Authentifizierung) konfiguriert haben. Weiterlesen
Dieser Artikel soll eine Richtschnur liefern über die empfohlenen Einstellungen der WatchGuard Access Points. Diese hängen allerdings sehr von den Gegebenheiten vor Ort und der Art und dem Alter der WiFi-Clients ab. Beispielhaft richten wir hier eine Gast-SSID ein.
Update 05.06.2024 einige Parameter wurden den neusten Erkenntnissen angepasst.
Folgende Vorüberlegungen sind wichtig:
Der nachfolgende Artikel beschreibt die Absicherung HTTPS basierter Anwendungen via einer Incoming Proxy Regel mit aktivierter HTTPS Content Inspection und Content Actions.
Die Firewall Regel und die HTTPS Proxy Action beinhalten folgende Security Features der Total Security Suite: Intrusion Prevention, Gateway AV, Intelligent AV, Geolocation und den APT Blocker.
Mit Content Actions können HTTP-Anfragen basierend auf der Kombination aus der Domäne im HTTP-Host-Header und dem Pfad in der HTTP-Anfrage an verschiedene interne Webserver weitergeleitet werden.
Optional:
Wenn Sie die Konfiguration entsprechend unseres Howto’s umsetzen, haben Sie einen guten Schutz vor ext. Angriffen. Um die Sicherheit weiter zu erhöhen kann man vor einer WatchGuard Firebox einen weiteren Proxy z.B. NGINX (ausgelagert) mit vorgeschalteter DDOS Protection einsetzen, somit wird unter anderem die IP-Adresse, des Backends verschleiert.
Da Microsoft für IKEv2 oder L2TP MS-CHAPv2 voraussetzt, müssen die Radius Anfragen von dem AuthPoint Gateway an einen Microsoft NPS weitergeleitet werden. Leider Kann in AuthPoint kein NPS Failover konfiguriert werden. Für SSLVPN oder IPSEC wird kein NPS benötigt!
Die Firebox bietet die Möglichkeit mit einem Loopback Interface und einer SNAT Load Balancing Action, die Radius Anfragen auf mehrere Server zu verteilen.
Um die Erreichbarkeit der Server zu prüfen, sendet die Firebox alle 10 Sekunden ein ICMP Paket an die Server. Wenn einer der Radius Server nicht mehr auf die ICMP Pakete antwortet werden die Anfragen an den verbliebenen Server gesendet, bis der Server wieder auf die ICMP Pakete antwortet.
Dieses Setup bietet leider keine Redundanz, wenn der Radius Dienst nicht mehr ordnungsgemäß funktioniert.
