Einrichten von Threat Detection and Response – Teil 4

In dieser Artikel-Serie (bestehend aus 5 Teilen) wird das Setup von WatchGuard Threat Detection and Response beschrieben:

1. Initiales Einrichten von Threat Detection and Response im WatchGuard KundenPortal
2. Konfiguration von Threat Detection and Response auf der WatchGuard Firebox und Installation der Host Sensoren
3. Konfiguration von Threat Detection and Response im TDR Kundenportal 
4. (Dieser Artikel:) Weitere Hinweise zu TDR, Tipps und Tricks
5. Best Practices

Teil 4 (Weitere Hinweise zu TDR, Tipps und Tricks)

Hier finden Sie Informationen über die Funktionsweise und Lizensierung von Threat Detection and Response.

Teil 4 – Weitere Hinweise zu TDR, Tipps und Tricks

TDR und Virenscanner

Prinzipiell sollten die TDR und Virenscanner gegenseitig ausgeschlossen werden, d.h. beim Virenscanner sollte der Bereich des TDR unter

C:\Program Files (x86)\WatchGuard\Threat Detection and Response\

ausgeschlossen werden. Beim TDR der entsprechende Bereich des Virenscanners (abhängig vom jeweiligen Hersteller).

TDR auf Server-Betriebssystemen

Typischerweise ist auf Servern möglicherweise mit einer etwas höheren Last zu rechnen. Hier kann man, um CPU-Resourcen zu sparen, das eine oder andere Feature des Host Sensors abschalten. Die folgenden Host Sensor Einstellungen beeinflussen die CPU-Last am meisten:

  • Loadable Modules on Host Sensors
  • Baselines on Host Sensors

Man erkauft sich also zusätzliche Server-Performance durch Abschalten der obigen Features mit demzufolge weniger Tests, also hat man schlimmstenfalls dadurch auch weniger Sicherheit.

TDR und Performance im Allgemeinen

Direkt beim Systemstart kann es zu einer spürbaren CPU-Mehrbelastung kommen, da während der Bootphase der Host Sensor sein Baselining macht – also auf dem System schaut, welche Prozesse sich wie verhalten. Beim Startup im Prevention-Modus werden auch einige zusätzliche Honeypot-Dateien angelegt; auch dies führt zu einer kurzzeitigen Mehrbelastung auf dem System.

Im laufenden Betrieb eines typischen Office-PCs sollte man aber keinen Unterschied bemerken. Die zusätzliche CPU-Last durch den Host Sensor sollte typisch im niedrigen 1-stelligen Prozentbereich liegen.

TDR bei PCs ohne direkten Internetzugriff

Gelegentlich hat man den Fall, dass manche PCs keinen direkten Internetzugriff haben (sollen). Wenn auf diesen PCs der TDR Host Sensor installiert wird, benötigt man ein paar zusätzliche Freischaltungen in der Firewall. Nach der Freischaltung von folgenden FQDNs hat es in meinem Test-Szenario funktioniert; das kann sich leider jedoch mit Updates des TDR Host Sensors ändern. Ich werde versuchen, die Liste hier aktuell zu halten.

Benötigt werden folgende FQDNs in HTTP(!) und HTTPS (genauer, ein Teil davon in HTTP, der Rest in HTTPS). Der Einfachheit halber empfehle ich einen Alias “Grp_EXT_TDR” o.ä. anzulegen, der dann einfach im To-Feld für eine HTTP Packet Filter Policy und eine HTTPS Packet Filter Policy verwendet wird. Der Alias benötigt folgenden Inhalt:

  • tdr-adhh-eu.watchguard.com
  • tdr-hsc-eu.watchguard.com
  • tdr-hsc-na.watchguard.com
  • *.watchguard.com
  • whats-my-ip-address.com
  • *.whats-my-ip-address.com
  • ctldl.windowsupdate.com
  • ocsp.digicert.com

Kann man TDR Updates verhindern?

TLDR; nein.

Da der Host Sensor schnell an zusätzliche Bedrohungen angepasst werden muss, wird dieser automatisch aktualisiert ähnlich wie ein Virenscanner. Da der Host Sensor dauerhaft mit seiner zentralen Cloud-Instanz in Verbindung steht, muss er auch immer aktuell sein, sonst könnte die Cloud-Plattform bei Bedarf nicht erweitert werden (Feature Updates). Daher folgt: das automatische Update des Host Sensors kann nicht unterbunden werden.

Gibt es ein Log des TDR Host Sensors?

Der Host Sensor schreibt ein Log nach

C:\Windows\Temp\host_sensor.log

4 Kommentare zu “Einrichten von Threat Detection and Response – Teil 4”

Leave a Reply

Your email address will not be published. Required fields are marked *