Neue Struktur für Admin PCs - wie am besten realisieren?

[phatair 39]

Hallo zusammen,

 

ich würde bei uns gerne mal ein dringendes Thema angehen. Das Thema wurden ja schon öfter mal diskutiert und ich wollte nicht einfach ein anderen Thema übernehmen.

Aktuell nutzen bei uns die Admins ihre normalen Notebooks auch für jegliche administrative Tätigkeiten, d.h. auf diesen werden Management Konsolen gestartet, Admin Web GUIs aufgerufen und RDP Sessions zu Servern gestartet.

 

Ein kurzer Überblick über die bestehenden Security Vorgaben

• VLAN Segmentierung für Server, RDMS, Management, IT, Clients, DMZ, usw vorhanden
• Routing über die zentrale Firewall inkl. granularer FW Regeln und Security Profiles für jedes VLAN und WAN Verbindung
• personalisierte Server Admin Accounts die nur auf zugewiesenen Servern genutzt werden können.
• personalisierte Client Admin Accounts die nur auf zugewiesenen Servern genutzt werden können.
• personalisierte Domain Admin Accounts die nur auf den DCs genutzt werden können.
• Spezielle "Fine grained password policies" für die Admin Accounts
• dedizierte Service Accounts die jeweils nur für einen Dienst/Aufgabe genutzt werden
• Kein "normaler" User hat Adminrechte bzw. einen Admin Account
• Standard Admin ist auf allen Servern deaktiviert.
• Unterschiedliche Passwörter für die lokalen Server Admins
• LAPS befindet sich aktuell in der Implementierung
• Kein Internet Zugriff für Server. Wenn benötigt, werden diese URLs/Ports explizit für diesen Server in der Edge Firewall geöffnet
• es werden noch keine Admin Tiers verwendet

 

Nun nutzen wir, wie schon oben beschrieben, unsere Notebooks zum einen für die tägliche "non Admin Arbeit" wie Mails schreiben oder Recherche im Internet. Zugleich haben wir auf diesen Geräten auch unsere administrativen Tools installiert. 

Das ist natürlich alles andere als optimal und soll geändert werden.

 

Die erste Idee war, für jeden Admin eine VM bereitzustellen und dort die notwendigen Tools zu installieren. Über das Notebook wird dann nur noch die normale Standard Tätigkeit durchgeführt.
Credential Guard nutzen um die Anmeldedaten vor "Pass-the-Hash" Attacken zu schützen.

-> Bei weiterer Recherche stellte sich dann aber raus, dass dies wohl nicht so einfach ist. Ein PAW sollte wohl eher anders rum genutzt werden. Also das NB als Admin Workstation und z.b. eine VMware als normale Arbeitsstation.

Da die Admin Station aber nicht in der Domäne sein soll und besonders gehärtet sein muss, stellt sich das bei uns aktuell etwas schwierig da.

 

Das Thema ist recht komplex, gerade wenn man auch die Admin Tiers mit einbezieht.

Daher mal meine Frage in die Runde, was gibt es für Möglichkeiten um die aktuelle Situation mit den Admin Notebooks bei uns zu verbessern, aber ohne gleich die volle Ausbaustufe zu implementieren? Das würden wir aktuell absolut nicht schaffen.

 

Auf der VMware Seite hätten wir noch genug Ressourcen um jedem Admin eine eigen VM bereitzustellen. Lässt sich da schon etwas bauen, damit wir etwas besser aufgestellt sind als jetzt?

Ziel wäre es also:

- Notebook für die tägliche User Arbeit

- VM als Admin PC/"PAW" der z.B. nicht in der Domäne und gehärtet (Security Baselines ...) ist 

 

Vorgehen wäre dann so, dass man per RDP auf den "Admin PC" geht um dann dort die installierten Admin Tools zu nutzen oder sich von dort per RDP auf einen bestimmten Server einwählt.

 

Damit hätte ich zumindest schon mal die Admin Tätigkeit von der täglichen Arbeit getrennt. Ein erster Schritt, dem noch weitere folgen müssen, aber besser so als es einfach so zu belassen wie es ist. 

Bin gespannt und dankbar für eure Antworten.

Grüße

[MurdocX 952]

Hallo @phatair,

 

vor 4 Stunden schrieb phatair:

Da die Admin Station aber nicht in der Domäne sein soll und besonders gehärtet sein muss, stellt sich das bei uns aktuell etwas schwierig da.

 

Die PAWs sollten sehr wohl in der Domäne sein, denn sonst nutzt du kein Kerberos, sondern das alte NTLM(v2). Wichtig ist hierbei zu achten, dass keine administrativen AD-Accounts auf die PAWs administrativen Zugriff haben, sonst hebelst du die Workstations schnell wieder aus.

 

Deine Themen sind gut, jedoch nur ein Tropfen auf den heißen Stein. Ich behaupte, das lässt sich nicht wie gewünscht in einem Forum diskutieren. 

[cj_berlin 1.323]

Moin,

 

was @MurdocX sagt. Holt euch jemanden ran, der sich mit sowas auskennt, und diskutiert das mit ihr konkret, statt mit uns hier im Forum abstrakt.

 

Wäre ich aber derjenige, den ihr einkauft, gäbe es zwei Punkte, über die ich mit mir gar nicht erst diskutieren lassen würde:

1. Admin-Accounts kommen in einen separaten Forest (und nein, es ist kein Aufwand, ihn zu bauen und einen einseitigen Trust einzurichten)

2. PAWs sind auf dedizierter Hardware abzubilden - entweder als physische Notebooks oder als nicht-persistente VDI (ebenfalls auf einer separaten Virtualisierung, deren Management-Schnittstellen aus dem Produktionsnetzwerk nicht erreichbar sind). Und das Betriebssystem. an dem sich Admin-Accounts interaktiv anmelden, hat Ceredential Guard aktiviert.

[daabm 1.357]

Bei dem Uni-Trust bin ich sofort dabei - Will hat mal einen rausgehauen dazu: https://posts.specterops.io/not-a-security-boundary-breaking-forest-trusts-cd125829518d

 

[phatair 39]

Hallo zusammen,

 

vielen Dank für eure Rückmeldungen. Ich gebe euch Recht, dass das Thema wahrscheinlich zu vielschichtig ist, um es hier im Forum zu diskutieren bzw. eine Lösung für uns zu finden.

 

Ich werde mal schauen, ob und wie wir das über unseren bestehenden Dienstleister angehen können.

Darf ich in diesem Zuge auch Fragen, wer von euch so eine Dienstleistung in Bezug auf PAW/Server Tiering anbietet oder ist das nicht gestattet?

[NilsK 2.940]

Moin,

 

sowas sollten wir per PN klären, nicht im Forum. Hier ist Community, nicht Kommerz.

 

Gruß, Nils

 

[cj_berlin 1.323]

vor einer Stunde schrieb NilsK:

sowas sollten wir per PN klären, nicht im Forum. Hier ist Community, nicht Kommerz.

 

Korrekt, aber ich meine, @phatair würde gern wissen, an wen er die PN schicken soll  

[NilsK 2.940]

Moin,

 

schon klar, aber vielleicht können wir es andersrum machen: Er könnte angeben, dass man ihn per PN kontaktieren kann, wenn Interesse besteht. 

 

Gruß, Nils

 

[phatair 39]

So machen wir es :)

Bei der Planung und der Umsetzung für ein PAW bzw. auch Server Tier Konzept würden wir noch Externe Unterstützung benötigen.

Falls uns hier jemand als externer Dienstleister unterstützten könnte, kann er sich gerne per PN an mich wenden.

Vielen Dank schon mal.

Grüße

[Lian 2.425]

So sei es

 

Der Thread bleibt offen, falls noch Rückfragen bestehen zur Architektur oder der Technik dahinter.

[Weingeist 159]

Was ich mich schon öfter gefragt habe, gibts eigentlich keine sinnvolle Windows Security bzw. Aufbau-Wiki die man  abarbeiten kann und mehr oder weniger das beinhaltet was man tun sollte und warum und wie?

Man kann ja schon immer auf die spezialiserten Dienstleister in diese Bereich verweisen, aber A weiss man nicht wie gut die sind, B gehen die guten zu den grösseren Firmen oder sie sind schlicht zu teuer für KMU's und C auch wenn sie gut sind, kann denen gewisse Ding durch die Lappen gehen.

 

 

Am 15.8.2022 um 22:02 schrieb cj_berlin:

1. Admin-Accounts kommen in einen separaten Forest (und nein, es ist kein Aufwand, ihn zu bauen und einen einseitigen Trust einzurichten)

2. PAWs sind auf dedizierter Hardware abzubilden - entweder als physische Notebooks oder als nicht-persistente VDI (ebenfalls auf einer separaten Virtualisierung, deren Management-Schnittstellen aus dem Produktionsnetzwerk nicht erreichbar sind). Und das Betriebssystem. an dem sich Admin-Accounts interaktiv anmelden, hat Ceredential Guard aktiviert.

 

Zu 1: Warum genau ist das eigentlich sicherer? So ganz begriffen habe ich persönlich das nicht. Wenn der DC der produktiven Umgebung komprimittiert ist, ist es doch der Rest so oder so auch. Was übersehe ich?

 

Zu 2: Warum eine Non-Peristente VM und bei der physischen setzt man auf Persistent? Vorzüge non-Persistent sehe ich im immer jungfräulichen OS, aber das Patch-Management für die Non-Persistent Admin-VM's ist ja verhältnissmässig aufwendig.

[cj_berlin 1.323]

vor einer Stunde schrieb Weingeist:

Zu 1: Warum genau ist das eigentlich sicherer? So ganz begriffen habe ich persönlich das nicht. Wenn der DC der produktiven Umgebung komprimittiert ist, ist es doch der Rest so oder so auch. Was übersehe ich?

 

Zu 2: Warum eine Non-Peristente VM und bei der physischen setzt man auf Persistent? Vorzüge non-Persistent sehe ich im immer jungfräulichen OS, aber das Patch-Management für die Non-Persistent Admin-VM's ist ja verhältnissmässig aufwendig.

Es geht ja darum, DASS die DCs im produktiven Forest nicht kompromittiert werden. Und ein wichtiger Schritt dahin ist, Admin-Accounts nicht kompromittieren zu lassen. Und Admins, die sich nur per Shadow Principal aus dem Bastion-Forest authentifizieren, können im Prod-Forest gar nicht kompromittiert werden.

 

Patch-Management einer nicht-persistenten VDI ist nur bei Microsoft RDS ein Problem, andere Systeme beherrschen dies nativ. Und nicht-persistent deshalb, weil man bei VDI (zu der man sich aus der unsicheren Zone verbindet) nicht alle Mittel einsetzen kann, um das Hinterlassen von Credentials zu verhindern, die einem bei einem physischen Rechner, an dem man sich direkt interaktiv anmeldet, zur Verfügung stehen.

 

Bei einer physischen PAW setzt man nicht bewusst auf persistent, aber eine nicht-persistente physische PAW zu kreieren, die auch beispielsweise offline hochfahren kann, ist halt viel schwieriger. Das konnte man früher recht charmant mit XenClient abbilden, aber den hat Citrix ja nun eingestampft. Thin Clients mit Write Filter könnte man hier durchaus in Betracht ziehen, wenn man ein passendes OS findet. Meistens laufen die Dinger aber nicht ohne die ganzen Spezial-Softwaretitel des Herstellers, die dann wieder Löcher aufreißen.

vor 1 Stunde schrieb Weingeist:

Was ich mich schon öfter gefragt habe, gibts eigentlich keine sinnvolle Windows Security bzw. Aufbau-Wiki die man  abarbeiten kann und mehr oder weniger das beinhaltet was man tun sollte und warum und wie?

ASAI-I-Kurs von NTSystems. Die Jungs kann man auch für Umsetzung buchen.

[NilsK 2.940]

Moin,

 

vor 2 Stunden schrieb Weingeist:

Was ich mich schon öfter gefragt habe, gibts eigentlich keine sinnvolle Windows Security bzw. Aufbau-Wiki die man  abarbeiten kann und mehr oder weniger das beinhaltet was man tun sollte und warum und wie?

gibt es deshalb nicht, weil das sehr schnell sehr individuell wird und eine ganze Menge mit Prozessanalyse und -beratung zu tun hat. Das ist als Checkliste nicht sinnvoll zu leisten. Wer es ernst meint, muss da ganzheitlich ran. Und da ist es auch sinnvoll (für den Kunden) und legitim (für den Anbieter), dafür gutes Geld einzuplanen.

 

Die Nachteile von Checklisten kann man übrigens gerade bei dem Thema in der freien Wildbahn gut beobachten. Als es die ESAE-Doku von Microsoft noch gab, war dort ein Verfahren beschrieben, wie man die PAWs grundlegend aufbaut. Das war so ziemlich die einzige Anleitung zu dem ganzen Themenkomplex, die ganzen eigentlich wichtigen Dinge waren nicht in der Form beschrieben. Viele Admins - und leider auch viele Berater - haben dann geglaubt, das sei alles. Sie haben das umgesetzt und dann geglaubt, sie hätten eine vollständige ESAE-Umgebung. Von den ganzen Prozessen und Härtungen drumrum aber keine Spur.

 

Gruß, Nils

 

[LK28 11]

vor 2 Stunden schrieb cj_berlin:

Es geht ja darum, DASS die DCs im produktiven Forest nicht kompromittiert werden. Und ein wichtiger Schritt dahin ist, Admin-Accounts nicht kompromittieren zu lassen. Und Admins, die sich nur per Shadow Principal aus dem Bastion-Forest authentifizieren, können im Prod-Forest gar nicht kompromittiert werden.

 

 

Hierzu mal eine Frage: Die Shadow Principals sind aber nur möglich, wenn man das Microsoft PAM nutzt + den PAM Trust?

Es ist aber auch aus sicherheitstechnischer Sicht möglich/sinnvoll, einen einseitigen Trust (Prod Forest vertraut dem Admin Forest) einzurichten, sodass die Admins aus dem Admin Forest die Prod Umgebung verwalten können?

bearbeitet 21. Oktober 2022 von LK28
vertippt

[cj_berlin 1.323]

vor 46 Minuten schrieb LK28:

Hierzu mal eine Frage: Die Shadow Principals sind aber nur möglich, wenn man das Microsoft PAM nutzt + den PAM Trust?

Es ist aber auch aus sicherheitstechnischer Sicht möglich/sinnvoll, einen einseitigen Trust (Prod Forest vertraut dem Admin Forest) einzurichten, sodass die Admins aus dem Admin Forest die Prod Umgebung verwalten können?

Ich vermag hier keinen Widerspruch zu erkennen