RPC-Filter Whitelisting? via GPO verteilen (PetitPotam usw)

[Weingeist 157]

Hallo zusammen,

 

Habe mich mal etwas mit den RPC-Filter der Windows Firewall befasst. Habe zwar die Empfehlung für die Blockierung von Remote-EFS damals blind umgesetzt, aber eingehend damit beschäftigt bis anhin nicht.

So wie es aussieht sind RPC-Angriffe einigermassen beliebt und effizient. Vielleicht auch weil es selten konfiguriert wird?

 

1. Frage: Hat sich jemand schonmal mit einem Whitelisting beschäftigt? Sprich alles an RPC zu blocken und nur das gewünschte zu gewünschten Empfängern zuzulassen? Oder einem Black-Listing?

Also quasi je nach Client oder Servertyp? Gibt es Empfehlungen dazu? Habe zwar etwas recherchiert aber nix sinnvolles gefunden. Da es doch ein paar Protokolle gibt, wäre der Aufwand nicht ganz unerheblich.

 

2. Frage: Wie rollt man das am einfachsten aus? Per Start-Script oder geht das eleganter? "Rumpfuschen" in der Registry mit GPP braucht bei Firewall-Rules normal nen neustart.

 

3. Frage: Wie hoch ist der tatsächliche Nutzen? Bei PetitPotam scheint es ja jedenfalls die Attacke zu verhindern.

 

Grüsse und Danke

 

 

Dann noch etwas Lektüre zum Thema für die die es interessiert:

Interessanter Beschrieb: https://www.akamai.com/blog/security/guide-rpc-filter#why

Die technische Doku bei MS zu den Protokollen (für die GUIDs): https://learn.microsoft.com/en-us/openspecs/windows_protocols/MS-WINPROTLP/e36c976a-6263-42a8-b119-7a3cc41ddd2a

Ein paar bekannte Attacken und wie man sie blockt/filtert: https://github.com/jsecurity101/MSRPC-to-ATTACK (Leider schon etwas älter? Keine Ahnung ob obsolet oder nicht)

Etwas mehr Details: https://www.tiraniddo.dev/2021/08/how-windows-firewall-rpc-filter-works.html

bearbeitet 29. April 2023 von Weingeist

[MurdocX 904]

vor 15 Stunden schrieb Weingeist:

Hat sich jemand schonmal mit einem Whitelisting beschäftigt? Sprich alles an RPC zu blocken und nur das gewünschte zu gewünschten Empfängern zuzulassen?

Nein. In großen Umgebungen ist es ohnehin schon sehr komplex. Kollegen werden einem Sonderkonfigurationen danken ;)

 

Einfacher -> Alle möglichen administrative Ports abschalten und die Übriggebliebenen festlegen auf einen Trusted-Hosts oder ein Admin-Netz. Warum kompliziert, wenn es doch so einfach sein kann ;)

Keep IT short and simple sollte überall angewendet werden, wo es möglich ist.

 

Im Allgemeinen sollte man sich nicht um die Auswirkung/das Problem am Ende kümmern, sondern das Thema an der Wurzel analysieren. "Berechtigungen" sollten ein Hauptaugenmerk bekommen. Das Protokoll ist i.d.R. selten der Schuldige.

[Weingeist 157]

keep it simple versuche ich auch wenn irgendwie möglich durchzusetzen. Auch das mit den Berechtigungen sehe ich genau so, auch wenn es nicht immer ganz einfach durchzublicken ist, wo und wie man genau das Standardverhalten ändern muss. Das erstellen von Benutzern/Admin Workstations welche nur in ihrem möglichst kleinen Teil und möglichst nur dann wenn notwendig Zugriff haben/anmelden können, ist noch der einfachste/offensichtlichste Teil.

 

 

Für die verlinkten RPC-Protokollle gibt es aber aktive Exploits und soweit ich das richtig verstanden habe, sind die Updates von MS nur die halbe Miete und die Wahrscheinlichkeit das ähnliche Exploits auftauchen relativ hoch. Macht es da nicht doch Sinn, die problematischen Protokolle ebenfalls auf die Admin-WS zu begrenzen oder gänzlich zu blockieren wenn sie nicht benötigt werden (z.B. Remote EFS)? Gerade was via RPC läuft ist durch die variablen Ports/maskierten Services doch einigermassen schwierig via FW auf einen bestimmten Port/Endgerät zu begrenzen. Ausser man biegt es von Variabel auf fix um, was dann auch nicht mehr Standardverhalten wäre. RPC selbst kann man ja lediglich zwischen den Clients verhindern ohne Ärger zu bekommen.

[daabm 1.185]

RPC verträgt sich schlecht mit Infrastruktur-Firewalls. Ich hatte "aus Gründen" kürzlich das Vergnügen, mich mit Subnetzen zu beschäftigen. Dabei ging's um ein Autosite-Skript für ein übergreifendes AD. Ergebnis: Wir haben Subnetze im sechsstelligen Bereich. Im Testlab mit einem Teil davon angelegt (50.000 Subnets, 13.000 Sites, 950 Site Links) waren dann KCC, ISTG, ISMServ und Netlogon "mehr als beschäftigt".

Das ergänze ich jetzt noch mit 3 verschiedenen RPC-Ranges, die wir historisch bedingt haben.

 

Wie soll ich da Regeln bauen, daß jeder AD-Client seine DCs (also die für seine Site zuständigen) auf den dafür erforderlichen Ports erreichen kann, alle anderen aber nicht? Und alle anderen RPC-Services ebenso? Und vorher weiß ich nicht, welcher RPC-Service sich welchen Port schnappt. Die Liste der erforderlichen IP-Netze dürfte die Kapazität der Reg-Werte sprengen, die fassen AFAIK nur 64k.

 

🏳️🏳️🏳️ (Kapitulation...)

 

PS: Ja, ich weiß ein wenig wovon ich rede. Deshalb ist in dem Skript hier auch der RPC-Check von Ryan Ries enthalten - https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1

[cj_berlin 1.137]

Moin,

 

wenn man in seiner Härtung so weit gekommen ist, dass die fehlende Granularität bei RPC-Diensten die letzte verbliebene offene Flanke ist, müsste man doch eigentlich genug Zeit übrig haben, um alle Hersteller von Enterprise Firewalls vorzuladen und eine RPC-LAN-Party zu veranstalten, denn nominal kann eine PaloAlto oder eine Fortinet ja durchaus zwischen RPC-Protokollen unterscheiden und Regelwerke auf dieser Grundlage bauen. Wie gut es dann funktioniert, kann man nur selbst beurteilen --> RPC-LAN-Party.

[Weingeist 157]

vor 14 Stunden schrieb daabm:

Und vorher weiß ich nicht, welcher RPC-Service sich welchen Port schnappt. Die Liste der erforderlichen IP-Netze dürfte die Kapazität der Reg-Werte sprengen, die fassen AFAIK nur 64k.

Klar, Deine Netze sind eine "etwas" andere Dimension. Aber das einzelne Subnet für sich ist ja auch nicht gigantisch gross. ;)

Ein RPC-Filter seitens Windows ist relativ trivial. Der Filter greift auf eine der untersten Eben der BFE. Um die random Ports muss man sich nicht kümmern. Windows weiss, welches Protokoll aktuell an welche RPC-Ports gebunden ist. Die Firewall müsste ja gar nicht so viele und aufwendige Rules haben, da man die "Freigabe" oder Blocks auch an AD-Gruppen binden kann.

 

Ich sehe es in etwa so: Wenn z.B. auf den DC's Printservice und andere Dienste abschaltet werden weil es dafür bestehende Exploits gibt und sie nicht gebraucht werden, wieso verhindert man auf den Servern nicht auch einfach alles ein einkommenden RPC-Verkehr der nicht notwendig ist oder beschränkt ihn - sofern sinnvoll möglich auf gewisse Partner? Ist ja jetzt nicht so eine Weltmeisterübung wenn man mal weiss was überhaupt benötigt wird. Die meisten sind z.B. der Meinung, EFS sei kaum sinnvoll zu verwalten, wozu dann seine Remote-Anlaufstelle offen lassen wenn genau dafür Exploits existieren (Auch wenn dafür der Dienst laufen muss).

Wenn gewisse Protokolle nur für den Austausch unter DC's/CA/DFS's/Admin-WS zuständig sind und für "normale" Clients irrelevant sind, könnte man die erlaubte Kommunikation für bestimmte Protokolle an bestimmte AD-Gruppen hängen. Der Aufwand wäre überschaubar und das Problem doch eigentlich an der Wurzel gepackt, eine Kommmunikation wird zum vornherein verhindert. Ein allfälliger Explit ist zahnlos. Die Logeinträge für untypische Kommunikationsaufnahmen hätte man ja auch grad gratis dazu. Muss ja nicht gleich Whitelisting für alles sein.

 

Die ganzen PetitPotam wären - zumindest wenn ich die Artikel richtig interpretiere - eher nicht so erfolgreich gewesen mit einer handvoll RPC-Filtern, deren "Anlaufstelle" auf DC's/CA sowieso nicht gebraucht wird.

[daabm 1.185]

Einer der Gründe, warum wir versuchen NTLM los zu werden. Aber das ist eine gaaanz lange Reise... Und wir haben ja alle echt viel Zeit übrig, um uns mit solchen Sahnehäubchen zu beschäftigen. Klar wäre es "nice", aber wer soll es in welcher freien Zeit machen?

 

Dynamische RPC-Openings auf den Firewalls haben unsere Netzer mal versucht, ging schief. Da ich daran aber nicht beteiligt war, weiß ich leider nichts über die Hintergründe.

[Weingeist 157]

Am 3.5.2023 um 18:37 schrieb daabm:

Und wir haben ja alle echt viel Zeit übrig, um uns mit solchen Sahnehäubchen zu beschäftigen. Klar wäre es "nice", aber wer soll es in welcher freien Zeit machen?

Ja da hast Du auch wieder recht, auch wenn es eigentlich eine schlechte Aussage ist. Die paar RPC-Protokolle welche für die aktuellen "Schmerzen" punkto NTLM sorgen, kann man ja bis auf wenige Ausnahmen schmerzfrei einfach deaktivieren. Insbesondere wenn man NTLM noch nicht deaktivieren kann. Die paar wenigen Ausnahmen wie die DC-Replikation müssen wohl nur an eine AD-Gruppe gebunden werden. Ist im Unterhalt ja eigentlich trivial, einfach in die entsprechende Gruppe schieben. Muss ja nicht extremst granular sein.

 

Aber ist wohl schon so, je grösser die Umgebung, desto mehr kann ein deaktivieren Schmerzen bereiten, weil mehr Tasks Remote erledigt werden und nicht auf der Maschine selbst. Allerdings hat man ja schon heute Admin-Benutzergruppen denen man verschiedenste Rechte wie das lokale Anmelden verweigert oder zulässt. Diese Gruppe (oder eigene) könnte man an die RPC-Filter hängen mit welchen man heikle Remote-RPC-Protokolle benutzen darf. Die BFE lässt einem gar nicht mit den anfälligen oder heiklen Diensten sprechen, welche als Relay oder sonstiges missbraucht werden könnten. Die nächsten Wochen/Monate werden zeigen wie praxistauglich die Umsetzung ist und welchen Ärger sie produzieren. Bis jetzt habe ich nur geblockt und nicht Zugriffe zugelassen und schon gar kein Whitelisting betrieben (ist mir der Aufwand vermutlich auch zu hoch).

 

Bezüglich NTLM: Zum Glück hat man ja noch laaaaaange Zeit *hust*: Günther Born hat wie ich heute gesehen habe, übrigens seit ein paar Tagen ne Timeline für die aktuellen Dinge wann sie scharf geschaltet werden: https://www.borncity.com/blog/2023/05/02/windows-hrtung-termine-2023/ Eigentlich ist es ja krass, dass erst 20 Jahre nach der Einführung das Messer an den Hals gesetzt wird. Wobei auch krass ist, dass das Standardverhaten für neue Umgebungen seit 20 Jahren nie geändert wurde. =)

 

 

Am 3.5.2023 um 18:37 schrieb daabm:

Dynamische RPC-Openings auf den Firewalls haben unsere Netzer mal versucht, ging schief. Da ich daran aber nicht beteiligt war, weiß ich leider nichts über die Hintergründe.

Ich meine ja in Windows selbst, nicht auf Stufe Netzwerk. Bei Windows muss man sich ja gar nicht darum kümmern. Macht Windows selbst. Entweder antwortet kein Dienst, da abgeschaltet oder es kommt nichts bis zum Dienst, da der Fragende via dem RPC-Protokoll-Filter der BFE geblockt wird. Der Overhead der BFE ist zudem vergleichsweise minimal, da sie die benötigten Infos hat/bekommt und nicht grossartig analysieren und berechnen muss.