Category Archives: Technischer Blog

HOWTO: Härten einer WatchGuard Firebox mit fail2ban (Schutz gegen SSLVPN Logon Brute-Force)

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/

Idee / Funktionsweise

  • Setup einer Linux-VM
  • Installation Konfiguration von syslog-ng
  • Konfiguration der WatchGuard, loggen via Syslog auf die Linux-VM. ACHTUNG: syslog ist unverschlüsselt!
  • Installation und Konfiguration von logrotate, damit die Firewall-Logs auch rotiert werden
  • Installation von fail2ban
  • Erweiterung der fail2ban Konfiguration
    • Überwachen der WatchGuard Log Files
    • Triggern eines Scriptes, das per CLI die angreifende IP auf die auto-blocklist setzt

Details

Voraussetzung:

  • bereits installierte Linux-VM (Distribution eigentlich egal, wir haben ubuntu verwendet, die verwendeten Befehle passen daher typisch für ubuntu und debian)
  • Ausstattung 1-2 Kerne, 2-4 GB RAM, ca. 20 GB für das Betriebssystem und die Logfiles.
    Mein eigenes Setup loggt zu einer Standard-Dimension (40GB Logdevice auf der Dimension,
    das ergibt bei mir ca. 30d Vorhaltezeit) sowie eben parallel per syslog zu einer Linux-VM.
    Aufgrund des täglichen Logrotates habe ich hier einen Platzbedarf von unter 3 GB für das
    gesamte Logverzeichnis.

Umsetzung:

Installation/Konfiguration syslog-ng

Installation von syslog-ng mittels

apt-get install syslog-ng

Anpassung der Konfiguration: der folgende Bereich muss in die Datei /etc/syslog-ng/syslog-ng.conf eingetragen werden (am Dateiende ist ausreichend):

source s_net {  tcp(ip(10.10.1.5) port(514));
                udp(ip(10.10.1.5) port(514)); };

destination d_net_messages { file("/var/log/hosts/$HOST/syslog"); };

log { source(s_net); filter(f_messages); destination(d_net_messages); };

Neustart von syslog-ng mittels

service syslog-ng restart

Konfiguration der Firewall für syslog

Im Policy Manager unter Setup => Logging wird die IP des Syslog-Hosts (unserer Linux-VM) eingetragen.

 

 

Testen der Syslog-Übertragung:

Mit folgendem Kommando sollte auf der Linux-Maschine das Live-Log der WatchGuard zu sehen sein:

tail -f /var/log/hosts/<ip.der.firewall>/syslog

Dort erscheinen dann auch die Logon-Zeilen des SSLVPN:

tail -f /var/log/hosts/<ip.der.firewall>/syslog | grep "SSL"

Mar 11 14:44:59 10.10.1.11 M270-NFR-WUE wgcgi[12399]: SSL VPN user foo@Firebox-DB from <ip> was rejected - Unspecified.
Mar 11 14:45:02 10.10.1.11 M270-NFR-WUE wgcgi[12400]: SSL VPN user foo@RADIUS from <ip> was rejected - U

Installation/Konfiguration git

Installation von git mittels

apt-get install git

Installation fail2ban-for-watchguard

Die folgenden Kommandos installieren die fail2ban-for-watchguard Komponenten nach /usr/local/fail2ban-for-watchguard/ – wo sie von den Scripten und den Config-Dateien auch erwartet werden:

cd /usr/local/
git clone https://github.com/watchguard-toolbox-project/fail2ban-for-watchguard.git

Konfiguration fail2ban-for-watchguard

Unter /usr/local/fail2ban-for-watchguard wird eine Datei “config.sh” erwartet. (zur Vorlage: config.sh-dist mitgeliefert).

kopieren

cd /usr/local/
cp config.sh-dist config.sh

Mit dem Editor der Wahl editieren, sie sollte dann wie folgt aussehen; natürlich müssen IP und Username/Passwort entsprechend angepasst werden. Hier wird ein Benutzer benötigt, der Schreib-Rechte für die Firewall hat (z.b. admin). Zum Testen sind 3 Minuten sehr gut geeignet, im Live-Betrieb kann man hier durchaus auf 10 oder 20 Minuten gehen. Vorsicht: IPs auf der Blockliste sind generell gesperrt, nicht nur für diesen Dienst. Es wäre nicht das erste Mal, das sich jemand mittels auto-block-liste selbst von der Firewall aussperrt. (Zitat aus unserem Firewall-Kurs: “block ist böse, denn es macht genau das: blocken.”).

#!/bin/bash

FW=10.0.1.1
USER=admin
PASS=readwrite
TIME="minute 3 second 0"

Absichern der Konfiguration fail2ban-for-watchguard

Zur Sicherheit sollten die Linux-Dateirechte entsprechend gesetzt werden. fail2ban läuft als root, weil es im Normalfall ja auch die lokalen Linux-iptables bearbeiten soll. Daher zur Sicherheit die Ownership und Dateirechte der config.sh entsprechend setzen, damit niemand (außer root) diese lesen kann. Dort ist schließlich unser Firewall-Passwort enthalten:

cd /usr/local/fail2ban-for-watchguard
chown root:root config.sh
chmod 700 config.sh

Installation fail2ban

Installation von fail2ban mittels

apt-get install fail2ban

Anpassung von fail2ban

Das fail2ban muss entsprechend angepasst werden, damit es die Logfiles überwacht, dann muss ein Filter definiert werden, der auf die WatchGuard Log-Zeile matcht und letztlich eine Aktion definiert werden, die ausgeführt wird. Die entsprechenden Dateien / Snippets sind bereits enthalten.

Mit folgenden Kommandos wird das ganze eingerichtet:

cd /usr/local/fail2ban-for-watchguard/

# Filter-Definition kopieren
cp filter.d-wgsslvpn.conf to /etc/fail2ban/filter.d/wgsslvpn.conf

# Action-Definition kopieren
cp action.d-wgsslvpn.conf to /etc/fail2ban/action.d/wgsslvpn.conf

# Jail für den neuen Service konfigurieren
cat jail.conf-addon >> /etc/fail2ban/jail.conf

Abschließend muss fail2ban neu gestartet werden.

service fail2ban restart

Prüfung, ob alles funktioniert

in der Datei /var/log/fail2ban.log werden die Aktionen von fail2ban geloggt:

tail -f /var/log/fail2ban.log
2024-03-11 14:44:55,444 fail2ban.filter         [24195]: INFO    [wgsslvpn] Found <ip>
2024-03-11 14:44:59,509 fail2ban.filter         [24195]: INFO    [wgsslvpn] Found <ip>
2024-03-11 14:45:02,819 fail2ban.filter         [24195]: INFO    [wgsslvpn] Found <ip>
2024-03-11 14:45:03,037 fail2ban.actions        [24195]: NOTICE  [wgsslvpn] Ban <ip>
2024-03-11 14:46:03,119 fail2ban.actions        [24195]: NOTICE  [wgsslvpn] Unban <ip>

 

Gory Details und weitere Ideen

  • Die Datei mit dem Filter ist ziemlich primitiv, das könnte professioneller gestaltet werden.
  • Ebenso können hier weitere Filter dazugeschrieben werden: IKEv2-VPNs, AccessPortal logons, etc.
  • Im Abschnitt für die jail.conf ist die bantime mit 60s angegeben. Dies dient dazu, das fail2ban nach 60s für diese IP erneut scharf zu schalten. Das Unbanning erfolgt aber nicht durch fail2ban getriggert, sondern durch den Automatismus der WatchGuard und deren Auto-Block-Liste. Dies war eine bewusste Design-Entscheidung, denn hierdurch greifen auch die Exceptions der WatchGuard (Ausnahmen, wer NIE geblockt werden soll), zudem gibt es die gewohnten manuellen Eingriffsmöglichkeiten zum Bearbeiten der Auto-Block-Liste über den Firebox System Manager
  • Zum Erweitern der Blockliste wird per SSH und EXPECT Script die CLI der WatchGuard verwendet.
  • Die Inhalte der Dateien will ich bewusst nicht hier im Blog-Artikel hinterlegen, da sich diese bei Weiterentwicklung noch verändern können.
    Sie sind direkt auf github zu finden, falls es jemand vorher ansehen/prüfen möchte.

Links / Referenzen

Notizen

  • Kommentare willkommen.
  • Pull-Requests werden ebenfalls gerne gesehen.

HOWTO: Automatische Installation von Sicherheitsupdates für Microsoft und Third-Party Anwendungen zur Härtung der Endgeräte

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.

Weiterlesen »

HOWTO: Trade-Up mit WatchGuard AuthPoint

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.

Problem:

Weiterlesen »

HOWTO: Best Practices/Empfehlungen Konfiguration von Access Points in der WatchGuard Cloud

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.

Folgende Überlegungen sind wichtig:

  • Die Netzwerkanbindung der Access Points und Konfiguration der VLAN’s
  • Die Ordnerstruktur in der Cloud
  • Die Erstellung einer Access Point Site

Weiterlesen »

HOWTO: Reverse Proxy mit HTTPS Content Inspection und Content Actions (Deep Packet Inspection)

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.

Erläuterung:

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.

Voraussetzungen:

Weiterlesen »

HOWTO: Redundantes AuthPoint Radius (Microsoft Netzwerkrichtlinienserver) Setup mit der WatchGuard Firebox

Problemstellung

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!

Lösungsvorschlag

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.

Weiterlesen »

HOWTO: Download und Installation von manuellen Patches via WatchGuard Patch Management

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 oder Third-Party Anwendungen (Patch-Library) zu installieren.
In einigen Fällen können Patches, bei denen eine EULA bestätigt werden muss oder der Downloadlink nicht öffentlich verfügbar bzw. unbekannt ist, nicht automatisch via Patch Management installiert werden. Hierzu ist ein manueller Eingriff notwendig.

Der folgende Artikel beschreibt die Installation von manuellen Downloads.

Weiterlesen »

HOWTO: OpenVPN / WatchGuard SSLVPN und „Start Before Logon“ konfigurieren

Seit der Version 2.6 von OpenVPN (>> Changelog OpenVPN) gibt es die Möglichkeit ein „Start Before Logon“ (PLAP, Pre Logon Access Provider, VPN Before Login, GINA-Mode) zu konfigurieren. Ein Login noch vor der Benutzeranmeldung bietet für Domain-Computer einige Vorteile (Passwortänderungen, GPO, Start-Skripte, neue Benutzerprofile anlegen, …) und ist ein häufig gewünschtes Feature.

Da WatchGuard für deren SSLVPN einen OpenVPN als Grundlage verwendet, kann dieser How-To Artikel sowohl für WatchGuard als auch für alle anderen OpenVPN fähigen VPN-Gateways verwendet werden.

Weiterlesen »

Neuer Microsoft365-Alias in der Firebox ab Firmware v12.10

Seit Firmware v12.10 gibt es einen neuen „Microsoft365“-Alias im Fireware Policy Manager. Die hinterlegte Liste mit DNS und IP-Adressen basiert auf folgendem Link, der von Microsoft gepflegt wird:

https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide&redirectSourcePath=%252fen-us%252farticle%252fOffice-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2

Ein Alias ist eine Abkürzung, die eine Gruppe von Hosts, Netzwerken oder Schnittstellen identifiziert. Ihre Konfigurationsdatei enthält viele Standardaliase. Sie können auch neue Aliase erstellen. Um den Datenverkehr über Ihre Firebox zu verwalten, können Sie dann beliebige Aliase zu den in Ihrer Konfigurationsdatei definierten Policies hinzufügen.

Den „Microsoft365“-Alias finden Sie über das bekannte Menü im Fireware Policy Manager:

Die hinterlegte Liste mit DNS und IP-Adressen wird automatisch aktualisiert, wenn das Feature “Automatic Update” über die Subscription Services aktiviert ist:

WatchGuard System Manager (WSM):                                                                                              Fireware Web UI:

 

Das Update kann jedoch auch manuell angestoßen werden:
WatchGuard System Manager (WSM):


Fireware Web UI:

Nützliche Links: