In diesem Artikel werden die Herausforderungen und der Workaround bei der Konfiguration der Windows-Firewall für den WatchGuard EDR Core Agent erläutert, die nach einer Windows-Client Härtungsmaßnahme in Verbindung mit den Windows-Firewall Profilen auftreten können.
Einleitung
In einer Kundenumgebung ist ein Fehlerbild aufgetreten, der eine alternative Lösung erforderte, in Verbindung mit der „WatchGuard EDR Core Agent“-Installation und einer WatchGuard Firebox, die aus dem Internet erreichbar ist.
Der EDR Core Agent wird im aktuellen Fall zur eindeutigen Identifizierung von Windows-Client Maschinen gegenüber der Firebox genutzt. Bedeutet, das Ziel ist, VPN-Verbindungen von bekannten Endgeräten zuzulassen und nicht bekannte Endgeräte können trotz gültiger VPN-Benutzerinformationen (inkl. dem Passwort), nicht genutzt werden.
Bedeutet im Klartext, dass eine VPN-Verbindung ins Kundennetzwerk nur möglich ist, wenn ein bekanntes Endgerät zuvor zentral mit einer eindeutigen ID registriert ist. Fremde Endgeräte, die nicht zentral registriert sind, können keine VPN-Verbindung ins Kundennetzwerk herstellen.
Problemstellung
In dem benannten Kundenszenario trafen nun besondere Konstellationen aufeinander:
- Windows-Client Härtungsmaßnahmen (Microsoft Security Baseline)
- WatchGuard EDR Core Agent
Symptome
Nach der Installation des WatchGuard EDR Core Agenten und der Herstellung einer VPN-Verbindung mit gültigen Benutzerinformationen, wurde jeglicher Netzwerkverkehr geblockt, obwohl auf der Firebox und in der Windows-Firewall alles korrekt eingestellt gewesen ist.
Der betreffende Windows-Client ist durch die „Microsoft Security Baseline“-Härtungsmaßnahmen abgesichert und befindet sich außerhalb des Kundennetzwerkes. Die Eingabe und Validierung der VPN-Benutzerinformationen verläuft erfolgreich.
Analyse
Um der Ursache auf die Spur zu kommen, habe ich im ersten Schritt, eine neue Windows Installation ohne Einschränkungen installiert (frischer Microsoft Download). Lediglich Windows Updates und der WatchGuard EDR Core Agent sind installiert. Resultat: Fehlerfreie VPN-Verbindung ins Kundennetzwerk.
Daraufhin habe ich auf den gehärteten Windows-Kundensystemen folgende Schritte durchgeführt:
Windows-Firewallregeln geprüft. | Die Windows-Firewallregeln sind korrekt angelegt worden. |
Windows-Firewalllogs auf geblockte Verbindungen hin untersucht. | Die Windows-Firewalllogs zeigten auf, dass der Port 33000 eingehend geblockt wird (kommend von der Firebox = Quell-IP-Adresse). |
Zugelassene Apps geprüft. | Festgestellt das der „Panda Endpoint Agent“ für das öffentliche Netzwerk nicht zugelassen ist. Die zugelassenen Apps sind unter „Windows-Sicherheit > Firewall- & Netzwerkschutz > Zugriff von App durch Firewall zulassen“ zu finden. |
Die Windows-Client Installation des Kunden blockt also den Port 33000 eingehend für genau diese App, wenn sich der Windows-Client außerhalb des Kundennetzwerkes befindet. Trotz gültiger Windows-Firewallregeln für alle drei Windows-Netzwerkprofile.
Netzwerkprofile in Windows
Windows bietet standardmäßig drei Netzwerkprofile, die jeweils unterschiedliche Sicherheitsstufen und Firewall-Einstellungen haben:
Domänenprofil | Dieses Profil wird verwendet, wenn der Computer mit einer Domäne verbunden ist. Es bietet die geringsten Einschränkungen, da davon ausgegangen wird, dass das Netzwerk vertrauenswürdig ist. |
Privates Profil | Dieses Profil wird verwendet, wenn der Computer mit einem privaten Netzwerk wie einem Heim- oder Firmennetzwerk verbunden ist. Es bietet moderate Sicherheitsmaßnahmen. |
Öffentliches Profil | Dieses Profil wird verwendet, wenn der Computer mit einem öffentlichen Netzwerk wie einem Café oder Flughafen verbunden ist. Es bietet die strengsten Sicherheitsmaßnahmen, um den Computer vor potenziellen Bedrohungen zu schützen. |
Lösungsansatz / Workaround
Der hier beschriebene Lösungsansatz ist nur als eine Art "Workaround" zu verstehen und ist keine offizielle Lösung seitens der Hersteller!
Um das Problem zu lösen, erstellte ich eine neue, zentrale Gruppenrichtlinie für die betreffenden Kundensysteme. In der Gruppenrichtlinie habe ich den „Panda Endpoint Agent“ explizit für das Standardprofil zugelassen.
Richtlinie:
EN
Computer Configuration > Policies > Administrative Templates > Network > Network Connections > Windows Defender Firewall > Standard Profile >
Windows Defender Firewall: Define inbound program exceptions
DE
Computerkonfiguration > Administrative Vorlagen > Netzwerk > Netzwerkverbindungen > Windows Defender Firewall > Standardprofil >
Windows Defender Firewall: Eingehende Programmausnahmen festlegen
Parameter:
C:\Program Files (x86)\Panda Security\Panda Aether Agent\AgentSvc.exe:192.168.17.1:enabled:Panda Endpoint Agent
Die IP-Adresse ist als Beispiel zu verstehen. Genau an dieser Stelle gehört die Gateway-Adresse des VPN-DHCP-Pools (nach erfolgreicher Benutzerauthentifizierung erreichbar). Die Ausnahme ist auf „Aktiv“ gesetzt und ein frei zu vergebener Name ist definiert.
Erklärung:
In der Gruppenrichtlinie wird der „Panda Endpoint Agent“ (AgentSvc.exe) hinterlegt, der vom VPN-Gateway eingehende „Requests“ entgegennehmen kann.
Nach der Anwendung dieser Richtlinie funktioniert die VPN-Verbindung, obwohl die Anzeige in der Windows Defender Firewall die App-Zeile weiterhin aus gegraut ist. Dies bedeutet, dass die Einstellungen durch die „Gruppenrichtlinie“ verwaltet werden und nicht manuell geändert werden können.
Sicherheitsüberlegungen
Kunden, die ihre Windows-Clients und andere Systeme sicherheitsbedingt „härten“, legen großen Wert auf Transparenz und konsistente Sicherheitseinstellungen. Alle eingehenden Verbindungen sind stets mit äußerster Vorsicht zu betrachten.
Warum die Kommunikation zwischen dem WatchGuard EDR Core Agent und der WatchGuard Firebox darauf angewiesen ist, dass die Firebox den EDR Core Agent über den Port 33000 ansprechen muss, ist derzeit unklar.
Aus sicherheitstechnischer Sicht ist eine eingehende Kommunikation im öffentlichen Netzwerk grundsätzlich nicht erlaubt. Es wäre bedeutend sicherer, wenn der EDR Core Agent der Firebox seine eigene, eindeutige ID übermitteln würde. Die genauen Hintergründe, warum die Kommunikation von der Firebox aus initiiert werden muss, sind jedoch nicht bekannt.
Zusammenfassung
Die Firebox sendet eine Anfrage über den Port 33000 an den jeweiligen Client zur Validierung. Der Client nutzt in öffentlichen Netzwerken standardmäßig das öffentliche Profil. Aufgrund von Härtungsmaßnahmen ist eine Anpassung des Agenten in der App-Steuerung der Netzwerkprofile erforderlich.
Fazit
Die Konfiguration der Windows-Firewall und die Anwendung von Härtungsmaßnahmen können komplex sein und zu unerwarteten Problemen führen. Durch eine sorgfältige Überprüfung der Firewall-Einstellungen, Gruppenrichtlinien und Netzwerkprofile kann jedoch sichergestellt werden, dass der WatchGuard EDR Core Agent ordnungsgemäß funktioniert.
„WatchGuard EDR Core Agent“-Funktionen
Der WatchGuard EDR Core Agent ist eine Sicherheitslösung, die darauf abzielt, Endpunkte vor dateilosen und malwarelosen Angriffen zu schützen, einschließlich Ransomware und Advanced Persistent Threats (APTs). Der Agent bietet Funktionen wie Anti-Manipulationsschutz, Anti-Exploit-Schutz, kontextuelle Erkennungen, Decoy-Dateien und VPN-Validierung
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Endpoint-Security/_intro/edr-core-about.html