Jump to content
Weingeist

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

Recommended Posts

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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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...

Share this post


Link to post

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. ;)

Share this post


Link to post

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

 

Share this post


Link to post

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.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


Werbepartner:



×
×
  • Create New...