Die Windows-Firewall als Sperre und Sensor gegen seitliche Bewegung

Die Windows-Firewall wird meist nur als das wahrgenommen, was ein Client vor dem Internet schützt, und dort leistet sie ohnehin wenig, weil der Perimeter das übernimmt. Ihr eigentlicher Wert für ein Blue Team liegt woanders: im Inneren des Netzes, als Sperre gegen die seitliche Bewegung und als Sensor, der jeden Versuch protokolliert. Der Beitrag zur seitlichen Bewegung beschreibt, wie ein Angreifer sich von einem übernommenen Client zu weiteren Systemen bewegt; dieser Beitrag zeigt, wie die Client-Firewall genau das verhindert und dabei sichtbar macht. Er behandelt die Firewall als Sperre und als Erkennungsquelle, die zentrale Steuerung per Gruppenrichtlinie und die typischen Fehler.

Warum die Client-Firewall gegen seitliche Bewegung wirkt

Ein Angreifer, der einen Arbeitsplatzrechner übernommen hat, will von dort weiter: auf andere Clients, auf Server, zum Domain Controller. Die Wege dorthin sind fast immer eingehende Verbindungen auf den Zielsystemen, RDP auf Port 3389, SMB auf 445, WMI über 135 und die dynamischen Ports, WinRM auf 5985. Genau hier setzt die Client-Firewall an: Wenn ein Arbeitsplatzrechner diese eingehenden Verbindungen überhaupt nicht mehr von anderen Arbeitsplatzrechnern annimmt, sondern nur noch aus dem Admin-Segment und von den Sprunghosts, dann läuft die seitliche Bewegung von Client zu Client ins Leere. Der entscheidende Punkt: Arbeitsplatzrechner haben untereinander im Normalbetrieb nichts zu besprechen. Ein Client muss keine eingehende RDP-, SMB- oder WMI-Verbindung von einem anderen Client annehmen, und wenn doch ein Helpdesk fernwartet, dann von einem definierten System aus. Diese eine Regel, eingehendes RDP, SMB und WMI auf Clients nur aus dem Admin-Segment, kappt den häufigsten Ausbreitungsweg und ist die Maßnahme, die der Beitrag zur seitlichen Bewegung als beste Gegenmaßnahme nennt.

Die Firewall als Sensor

Der zweite, oft vergessene Nutzen: Eine geblockte Verbindung ist eine Erkennung. Wenn die Client-Firewall protokolliert, was sie abweist, dann erscheint jeder Versuch eines übernommenen Clients, sich zu einem anderen Client zu verbinden, als abgewiesene Verbindung im Firewall-Log. Das ist eine der saubersten Erkennungen überhaupt, weil sie kaum Fehlalarme erzeugt: Im gesperrten Zustand gibt es keinen legitimen Grund, warum ein Arbeitsplatz einen anderen auf Port 445 oder 3389 ansprechen sollte. Die Protokollierung ist standardmäßig aus und muss aktiviert werden; danach schreibt Windows abgewiesene und, wenn gewünscht, erlaubte Verbindungen in eine Protokolldatei, die sich per Agent oder Windows Event Forwarding ins SIEM bringen lässt. Die Firewall wird damit vom passiven Schutz zum aktiven Melder, und die Sperre und der Sensor sind dieselbe Maßnahme.

Zentrale Steuerung per Gruppenrichtlinie

Eine Firewall, die auf jedem Client einzeln konfiguriert wird, ist nicht zu pflegen und wird vom ersten Benutzer mit Adminrechten wieder abgeschaltet. Deshalb wird die Windows-Firewall zentral per Gruppenrichtlinie gesteuert, mit ein paar Grundsätzen:

• Die Firewall ist immer an. Auf allen drei Profilen (Domäne, privat, öffentlich), und die lokale Änderung durch den Benutzer wird per Richtlinie unterbunden. Ein Angreifer mit Adminrechten kann sie zwar theoretisch ändern, aber das erzeugt ein Ereignis und ist selbst ein Alarm.
• Eingehend standardmäßig blockieren. Der Grundsatz ist, eingehende Verbindungen zu verbieten und nur das ausdrücklich Erlaubte zuzulassen. Auf einem Arbeitsplatz ist die Liste des Erlaubten kurz.
• Die kritischen Ports nur aus dem Admin-Segment. Regeln für RDP, SMB und WMI, die als Quelle nur die Adressen der Admin-Arbeitsplätze und Sprunghosts zulassen. Alles andere wird abgewiesen und protokolliert.
• Protokollierung aktivieren. Die abgewiesenen Verbindungen werden protokolliert und weitergeleitet, damit aus der Sperre eine Erkennung wird.
• Server anders behandeln. Server müssen viele Dienste eingehend anbieten und bekommen eigene, engere Regeln pro Rolle. Die pauschale Client-Regel passt nicht, aber das Prinzip, nur das Nötige zu erlauben, gilt auch dort.

Diese Trennung nach Systemklasse ist dieselbe Idee wie die Tiered Administration aus dem Beitrag zur Active-Directory-Härtung: Die Firewall-Segmentierung ergänzt die Rechte-Segmentierung, und zusammen machen sie aus einem kompromittierten Client eine Sackgasse statt eines Sprungbretts.

Der Weg zur gesperrten Umgebung

1. Erst beobachten, dann sperren. Zuerst die Protokollierung aktivieren und die eingehenden Verbindungen zwischen Clients eine Weile mitschreiben, ohne zu blockieren. So zeigt sich, welche legitimen Verbindungen es tatsächlich gibt, etwa die Fernwartung des Helpdesks, bevor man sie versehentlich kappt.
2. Die legitimen Ausnahmen klären. Der Helpdesk, der von seinem Arbeitsplatz aus fernwartet, ist die häufigste legitime Client-zu-Client-Verbindung. Er gehört auf einen Sprunghost oder in ein Fernwartungswerkzeug mit eigenem Protokoll, damit die Sperre ihn nicht trifft.
3. Schrittweise ausrollen. Die Sperrregeln zuerst auf einer Testgruppe, dann abteilungsweise, damit ein übersehener legitimer Verbindungsweg nicht die ganze Organisation lahmlegt.
4. Die Erkennung einrichten. Eine Regel im SIEM, die abgewiesene eingehende Verbindungen zwischen Clients auf den kritischen Ports meldet. Weil das im gesperrten Zustand kaum vorkommt, ist jeder Treffer ein Blick wert.
5. Testen. Nach dem Ausrollen im Homelab oder auf einem Testpaar prüfen, dass eine RDP- oder SMB-Verbindung von Client zu Client tatsächlich blockiert wird und im Log erscheint, wie im Beitrag zu Atomic Red Team beschrieben.

Typische Fehler

• Firewall aus „weil stört“. Der häufigste Fehler: Die Firewall wird abgeschaltet, weil eine Anwendung angeblich nicht läuft. Fast immer lässt sich stattdessen eine gezielte Regel schreiben. Eine abgeschaltete Client-Firewall ist ein offenes Tor für die seitliche Bewegung.
• Protokollierung vergessen. Wer sperrt, aber nicht protokolliert, hat die halbe Wirkung verschenkt: Die Sperre hält, aber niemand sieht die Versuche. Die Erkennung ist der zweite, gleich wertvolle Teil.
• Alles erlauben aus Bequemlichkeit. Eine Regel, die eingehendes SMB oder RDP aus dem ganzen internen Netz zulässt, ist keine Segmentierung. Die Einschränkung auf das Admin-Segment ist der Kern der Wirkung.
• Server wie Clients behandeln. Die pauschale Client-Sperre auf einen Server anzuwenden, der Dienste anbietet, bricht den Betrieb. Server brauchen eigene, rollenbasierte Regeln.
• Nicht getestet. Ob die Sperre wirklich greift und im Log erscheint, weiß man erst nach einem Test. Eine Firewall-Regel, die nie gegen einen echten Verbindungsversuch lief, ist eine Vermutung.

Fazit

Die Windows-Firewall auf den Clients ist die beste kostenlose Maßnahme gegen die seitliche Bewegung, und sie ist zugleich eine Erkennung: Wer eingehendes RDP, SMB und WMI auf Arbeitsplätzen nur aus dem Admin-Segment zulässt und die abgewiesenen Verbindungen protokolliert, macht aus jedem kompromittierten Client eine Sackgasse und aus jedem Ausbreitungsversuch einen Alarm. Zentral per Gruppenrichtlinie gesteuert, nach Systemklasse getrennt und vor dem Sperren beobachtet, kostet sie nichts außer Sorgfalt beim Ausrollen. Für ein Blue Team ist die Client-Firewall damit das Werkzeug, das den Angreifer dort stoppt, wo er am gefährlichsten wird: auf dem Weg vom ersten Client zum Rest des Netzes.