Windows-Firewall>Service-basierte Regeln>Probleme mit manipulierten SIDs

[Weingeist 159]

Hallo Leute,

 

Kann mir jemand sagen ob es eine Möglichkeit gibt, Firewallregeln aufgrund eines manipulierten Tokens eines Services zu erstellen? Die Service-SID entspricht da nicht mehr dem Standard. Mit dieser Info würde ich gerne eine Firewall-Regel aktualisieren, damit sie wieder zieht. Eventuell gibt es da etwas - evtl. auch direkt auf der Filter-Engine Ebene statt WFP-Ebene und ich habs übersehen. Eine Regel welche den Service-Namen benutzt und alle "Kinder" freischaltet wäre natürlich top.

 

Hintergrund: Windows verfolgt seit 8.1 teilweise die Strategie, das Token nach dem Starten des Services zu manipulieren. Bei Windows 10 ist diese Anzahl nochmals gestiegen und wird lästig weil zum Beispiel auch der Updatedienst manipuliert wird. Teilweise sind sie sogar User-Basiert und da funktioniert es eh hinten und vorne nicht mehr. Das heisst eine Filterung auf Service-Ebene ist nicht mehr sinnvoll möglich. Das heisst wiederum, man muss z.Bsp. die svchost.exe für ausgehenden Verkehr komplett freischalten, was nicht in meinem Sinne ist.

 

Erklärung eines Threads im Technet:

Zitat

Block by service name uses Service SID as filtering condition. There are cases when a service impersonates when it binds to the socket. In such cases, traffic is sent in context of user and SID that is being examined by WFP is the user's SID and not the service SID. Hence block by service name doesnt work. May be this happens in case of spooler svc. For wuauserv, it doesnot impersonate so the rule by service name seems to work.

--> wuauserv ist in W10 auch manipuliert.

 

Grüsse und Danke

[Weingeist 159]

Das Problem hat meinen Jagdtrieb geweckt, also habe ich gestern Abend mal ein paar Stunden geopfert. =)

Bei der Internetsuche bin ich auf einen Tipp gestossen, die svchost.exe als Kopie bereitzuerstellen. Hätte ich auch selber drauf kommen können. Fand ich aber nicht so prickelnd. Insbesondere weil sie dann nicht mehr durch das System geschützt ist. Aber es gibt ja noch Hardlinks. Diese müssten auch Update-Sicher sein. Gesagt getan und eine "eigene" svchhost.exe für die Dienste erstellt, welche durch die Firewall kommunzieren dürfen.

Die Datei ist wie viele Systemdateien durch TI geschützt, man benötigt also ein TI Token um einen Hardlink zu erstellen ohne den Besitz zu übernehmen. Ich mag es bis auf wenige Ausnahmen, Berechtigungen auf Systemstandard zu belassen.

 

Für die normale svchost.exe habe ich dann eine explizite Blockregel erstellt - theoretisch würde auch einfach das Standard Block-Out der FW reichen - für die svchost-"Kopie" eine Freigabe. Es funktioniert wie gewünscht.  Entweder verbiegt man nun alle Dienste auf eine gänzlich eigene "Kopie" und gibt die jeweiligen Ports frei oder erstellt einfach eine "Kopie" für alle die durch kommen sollen. Ersteres hätte den Vorteil, das man quasi wieder die vollständige Filterungsmöglichkeit in der FW hätte einfach das nicht mehr nach Dienst sondern eben nach dessen exe gefiltert wird.

 

Hätte noch den angenehmen Vorteil, das sbei allen Protokollierungen sofort klar ist, welcher Dienst von einem Fehler betroffen ist. Das ist nicht ganz immer der Fall weil lediglich die Prozess-ID + exe geloggt wird. Wenn ein Dienst aber nur bei Gebrauch gestartet wird und unter Umständen jedes mal eine andere ID hat, ist es manchmal schwierig den Verursacher zu lokalisieren. Der Overhead ist minimal und W10 separiert viele Dienste bei genügend RAM sowieso schon mit eigenen Prozessen. Jene die W10 gruppiert, würde ich wohl immer noch gruppieren. Hatte in der Vergangenheit schonmal Probleme als ich für eine Problemsuche alle Dienste mit separaten svchost.exe Instanzen laufen liess.

--> Prüfen z.Bsp. mit tasklist /svc /fi "IMAGENAME eq svchost.exe"

 

Ein paar System-Regeln der Firewall sollte man evtl. noch anpassen, diese verweisen auch auf die svchost.exe. Auch die Standard-Regel-Sätze sind dann eben nicht mehr Standard.

--> HKLM\System\CurrentControlSet\services\sharedaccess\Parameters\firewallpolicy\restrictedservices\static

 

 

Das vorgehen funktioniert übrigens auch für Home oder Pro-Versionen wo man z.Bsp. Mühe hat die ganzen Telemetrie-Dienste abzuschalten. So kann man z.Bsp. Industrie-Kisten die immer noch oft mit Pro ausgliefert werden statt mit LTSC wieder etwas besser kapseln/erlaubten Traffic steuern bzw. auf ein Minimum beschränken.

[MurdocX 953]

Ich verstehe nicht ganz dein Ziel das du damit erreichen möchtest. Könntest du das nochmal erklären?

[Weingeist 159]

So schwierig formuliert? Ziel ist die Erstellung von Firewallregeln mit der Filterung nach Services. Das funktioniert nicht (mehr) zuverlässig weil die Filterengine den Service nicht mehr zuverlässig findet weil manche Services ihre SID nach dem Start maskieren und so nicht mehr durch die Filter-Engine gefunden werden. Weder für Block noch Allow Regeln. Es gibt wohl keine Möglichkeit Regeln auf der aktuell verwendeten SID zu erstellen.

 

Als Beispiel nenne ich mal Industriemaschinen: Diese sollten nur in ganz klar definierten Zeiträumen Updates beziehen bzw. ausschliesslich auf Kommando. Herunterladen wäre OK, installation aber eben nur wenn die Produktionszelle still steht. Das geht seit W10 nicht mehr, schon gar nicht mit den Pro-Versionen die in der Regel eingesetzt werden. Insbesondere weil man den Updatedienst nicht mehr so konfigurieren kann, das Updates ausschliesslich heruntergeladen aber nicht automatisch installiert werden sollen.  Da der Krempel immer öfter an ERP's angebunden ist, Werkzeugdaten, PP etc. empfängt, muss aber eine Verbindung ins Unternehmensnetz bestehen. Auch Fernwartungen sind auf Befehl erwünscht und Schwupps, sind die Updates gezogen, in der Nacht installiert und die Produktion steht still.

 

Nun könnte man Updates komplett abdrehen, was ziemlich aufwändig, nicht wirklich nachhaltig und auch nicht sinnvoll ist. MS aktiviert die Dienste sowieso selbständig wieder wenn sie nicht laufen. Als zweite Variante kann man eben die Kommunikation des Update-Clients sowie Übermittlungsdienst und Bits beschränken. Das funktioniert aber nicht mehr, weil die Dienste nicht mit ihrer eigentlichen SID laufen. Eine granulare Freigabe ist also nicht möglich. Man muss quasi svchost.exe komplett freigeben oder aber die notwendigen Ports, welche wiederum mehrere Dienste - evtl. auch unerwünschte - bedienen könnte.

 

Mit der Separierung der svchost.exe kann man dieses Szenario wieder umsetzen indem einfach auf die exe statt den Dienst selber gefiltert wird.

 

Oder man möchte die Übermittlung von Telemetriedaten auf sensitiven Systemen komplett verhindern. Da der Kram auch via svchost.exe läuft, hätte man früher auf Dienstebene eine explizite Block-Regel erstellen oder eben jene die mein Freigeben wollte, bewusst freigeben können. Ein Block auf diagtrack juckt die Firewall aber nicht wirklich, weil diagtrack eben seine SID maskiert, genauso wie dns oder wuaauserv. Erstellt man nun eine neue svchost.exe welche alle Dienste verwenden welche eine Kommunikation haben dürfen, hat man das Problem umschifft indem nur auf diese eine Freigabe erteilt wird.

[daabm 1.366]

Ich kapier das mit "SID maskieren" schon nicht... Service-SIDs sind ja nix besonderes, sondern nur die Übersetzung des Service-Namens. Da gibt's nichts zu maskieren. Aber vermutlich versteh ich's komplett falsch, da eh nicht...

[Weingeist 159]

Was ganz genau wie verbogen wird, weiss ich auch nicht genau. Exakte technische Angaben habe ich dazu nicht gefunden. Fakt ist, die Bordeigenen API's können die SID's nicht mehr dem Service-Namen zuordnen bzw. eigentlich anders rum, sie finden mit dem Service-Namen die aktuelle Service-SID welche gerade für den Service verwendet wird nicht mehr. Sie ändert sich quasi mit jedem Start des Services oder beim Neustart von Windows. (Müsste man analysieren was zutrifft). Normal ist die SID immer identisch und ändert sich nicht. Dieses Verhalten hat sich geändert.

 

Deshalb funktionieren Firewall-Regeln auf Service-Ebene eben nicht mehr zuverlässig. Weder Block noch Allow. Ich vermute das ist um Malware ein paar Steine in den Weg zu werfen.

Ob die Static-Regeln davon ausgenommen sind, weiss ich allerdings noch nicht. Ich tippe allerdings auf nein, weil die Versions-Nr der Regeln nochmals deutlich tiefer ist.

 

Irgendwann dürfte die Firewall-Engine vermutlich auch ein Update bekommen damit es wieder klappt. Oder es ist Ihnen egal das es nicht klappt weil Standard-Block-Out eh so gut wie nie umgesetzt wird und alle die sich dafür interessieren, sich andersweitig zu helfen wissen. ;)

[NorbertFe 2.061]

Ich versteh es auch nicht komplett, aber evtl. Hilft ja sowas:

https://directaccess.richardhicks.com/2018/11/27/always-on-vpn-and-windows-server-2019-nps-bug/
 

da gibts im rechnet Forum auch noch einen längeren thread, der am Ende den selben workaround bietet. Da der Fehler bei 2019 von Anfang an besteht, würde ich bei w10 nicht unbedingt auf Besserung hoffen.

 

bye

norbert

 

[Weingeist 159]

Yep das dürfte auf das gleiche Probleme hinauslaufen. Der NPS ist eines der ersten Dienste die maskiert wurden und somit funktioniert das nicht (mehr). Unrestricted funktioniert aber - meine ich - nicht in jedem Fall. Soweit meine Recherche korrekt ist, bedeutet das nur, dass eine eigene svchost.exe Instanz verwendet wird und keine Shared. Aber nicht zwingend, dass die SID nicht maskiert wird. Aber die Infos dazu sind eher spärlich gesäht.

 

Manche Dienste schiesst man so auch ab, weil es von MS nicht vorgesehen ist, sie voneinander zu entkoppeln. Welche weiss ich nicht mehr genau, zu lange her als ich das zu Firewall-Debug-Zwecken mal vollständig entdrösselt habe, aber MS ist gerade eh selbst drann alles zu entflechten und macht es teilweise auch wenn mehr als 3.5GB RAM da ist. Daher würde ich jene Dienste die mit viel RAM immer noch gekoppelt sind, gekoppelt lassen. Dürfte seine Gründe haben. Allerdings funktioniert es einwandfrei mit dem Hardlink-Trick wenn man Sie auf eine gemeinsame EXE zeigen lässt.

[Weingeist 159]

Kleines Update: Funktioniert übrigens durchs Band zuverlässig. Ziemlich angenehm wenn man in den Logs gleich sieht welcher Dienst bei einem Block/Allow betroffen ist.

Bitte an das anpassen der Firewall-Regeln denken, falls es einer im Lab nachmachen möchte. Auch Static/Configurable sowie Default Rules sollen diese funktionieren.

--> Falls es jemand möchte, kann ich das Script dann hier veröffentlichen wenn es +- fertig ist. Wird inklusive Modifikation  der verschiedenen Firewall-Stores und der Services sein.

 

Ausstehend ist noch die Frage ob es beim Ersatz der svchost.exe durch Windows-Updates die Hardlinks ebenfalls auf die neue Datei und nicht die alte Version pointern. Ich denke das müsste eigentlich der Fall sein. Evtl kann ja jemand grad bestätigen/dementieren wie das ist bei den Hardlinks ist, wenn Files ersetzt und nicht nur geändert werden. Oder gelöscht und dann ersetzt. Sonst werde ich das auch noch testen.

 

Auch wie sich die Firewall-Regeln bei "Funktions-Upgrades" verhalten weiss ich noch nicht. Sprich ob sie ersetzt oder ergänzt werden. Ergänzen hätte den Vorteil, dass neue Dienste nicht einfach mal durchgelassen werden sondern erst wieder konfiguriert werden müssen. Die Hardlinks dürften neu erstellt werden müssen.

 

Gruppierte Dienste die man auch gruppiert lassen sollte:

- DcomLaunch, brokerinfrustructure, SystemEventsBroker, Power (warum auch immer Power hier reinkommt)

- RpcSs, RpcEptMapper

- mpssvc, BFE

- UserDataSvc, OneSyncSvc, PimIndexMaintenanceSvc, UniStoreSvc

 

Ich habe jeweils einen Dienst als "Chef" auserkoren und die anderen der gleichen Gruppe auf den gleichen Hardlink gemünzt.

 

Die letzte Gruppe wird nicht nur maskiert sondern pro User als eigener Service + Instanz erstellt. (Gibt noch mehr davon, auch wenn diese nicht gruppiert sind). Evtl sind diese nur wegen Speicher sparen gruppiert, habe ich (noch) nicht getestet, da ich sie eh (noch) nicht brauche. Bei den oberen führt die Aufdröselung zu Problemen. Teilweise massive.

Die anderen werden seit einiger Zeit sowieso schon durch Windows in eigene Prozess-Instanzen der svchost.exe aufgedröselt sobald RAM > 3.5GB ist.