28
AD Tiering Umsetzung
Guten Abend,
da ich gerade angefangen habe mich mit dem Thema Ad Tiering zu beschäftigen und dann auch bald bei uns im Betrieb umsetzen will, bin ich auf ein paar Fragen bezüglich der Umsetzung gestoßen, zu denen ich bisher leider keine wirkliche Antwort finden konnte.
Die Theorie dahinter, also das Prinzip dass jeder Admin der das AD komplett verwalten soll vier Konten braucht, wobei jeweils eines in Tier 0, 1 und 2 sind und ein unprivilegiertes Konto für Internet, E-Mails etc. benötigt und auch dass z.B. ein Tier 1 Admin nur Tier 1 Server verwalten darf etc. ist mir soweit verständlich.
Mir fehlen allerdings für die Praktische Umsetzung noch ein paar Informationen, welche mir bestimmt jeder der es in der Praxis umgesetzt hat beantworten kann.
Eine Möglichkeit, welche ich auch so häufig gelesen habe wäre doch dann wie folgt:
Jeder Admin hat einen physischen PC auf welchem er sich mit seinem unprivilegiertes Konto anmeldet und dort E-Mails etc. bearbeitet.
Wenn er administrative Rechte auf seinem oder auf einem anderen PCs des Tiers 2 benötigt, meldet er sich dort mit seinem Tier 2 Admin an.
Aber wie sieht es nun genau aus wenn er Server verwalten will (Tier 1) oder auch Gruppenrichtlinien etc. erstellen will (Tier 0)?
Häufig habe ich hier gelesen sich per RDP auf den Server zu verbinden und dort dann seine Tier 1 oder 0 Anmeldedaten einzugeben.
Dabei wird aber doch der Passworthash auf dem physischen PC gespeichert, welcher wieder einfach ausgelesen werden kann oder?
Aber wie genau verbinde ich mich denn dann mit den Servern?
Wenn ich noch eine VM erstelle, welche extra abgesichert ist (Kein Internet, nur RDP Verbindungen von bestimmten Host erlaubt etc.) und mich dann von dort aus per RDP auf die Server verbinde, bräuchte ich ja noch einen Benutzer mit welchem ich mich bei dieser VM anmelde? Und darauf müsste ich mich ja auch wieder per RDP verbinden, also das gleiche Problem..
Ich hoffe jemand kann mir bei meinem Verständnisproblem helfen und erklären wie ihr das in der Praxis umsetzen.
Vielen Dank auf jeden fall schon mal
da ich gerade angefangen habe mich mit dem Thema Ad Tiering zu beschäftigen und dann auch bald bei uns im Betrieb umsetzen will, bin ich auf ein paar Fragen bezüglich der Umsetzung gestoßen, zu denen ich bisher leider keine wirkliche Antwort finden konnte.
Die Theorie dahinter, also das Prinzip dass jeder Admin der das AD komplett verwalten soll vier Konten braucht, wobei jeweils eines in Tier 0, 1 und 2 sind und ein unprivilegiertes Konto für Internet, E-Mails etc. benötigt und auch dass z.B. ein Tier 1 Admin nur Tier 1 Server verwalten darf etc. ist mir soweit verständlich.
Mir fehlen allerdings für die Praktische Umsetzung noch ein paar Informationen, welche mir bestimmt jeder der es in der Praxis umgesetzt hat beantworten kann.
Eine Möglichkeit, welche ich auch so häufig gelesen habe wäre doch dann wie folgt:
Jeder Admin hat einen physischen PC auf welchem er sich mit seinem unprivilegiertes Konto anmeldet und dort E-Mails etc. bearbeitet.
Wenn er administrative Rechte auf seinem oder auf einem anderen PCs des Tiers 2 benötigt, meldet er sich dort mit seinem Tier 2 Admin an.
Aber wie sieht es nun genau aus wenn er Server verwalten will (Tier 1) oder auch Gruppenrichtlinien etc. erstellen will (Tier 0)?
Häufig habe ich hier gelesen sich per RDP auf den Server zu verbinden und dort dann seine Tier 1 oder 0 Anmeldedaten einzugeben.
Dabei wird aber doch der Passworthash auf dem physischen PC gespeichert, welcher wieder einfach ausgelesen werden kann oder?
Aber wie genau verbinde ich mich denn dann mit den Servern?
Wenn ich noch eine VM erstelle, welche extra abgesichert ist (Kein Internet, nur RDP Verbindungen von bestimmten Host erlaubt etc.) und mich dann von dort aus per RDP auf die Server verbinde, bräuchte ich ja noch einen Benutzer mit welchem ich mich bei dieser VM anmelde? Und darauf müsste ich mich ja auch wieder per RDP verbinden, also das gleiche Problem..
Ich hoffe jemand kann mir bei meinem Verständnisproblem helfen und erklären wie ihr das in der Praxis umsetzen.
Vielen Dank auf jeden fall schon mal
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 22728281562
Url: https://administrator.de/contentid/22728281562
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
28 Kommentare
Neuester Kommentar
Servus,
in deiner Gleichung hast du die "PAW" vergessen. "Privileged Access Workstation"
Diese PAW ist als Jumphost für einen dahinterliegenden Admin-Host gedacht.
Die Anmeldung an diesen PAWs erfolgt wiederum mit "PAW" Benutzern, auch wieder aufgeteilt in die jeweiligen Tiers.
Diese PAW-Benutzer können sich nur an der PAW anmelden, darüberhinaus haben diese Nutzer keine Berechtigungen.
Von dort aus kann eine Verbindung zu einem Admin-Host aufgebaut werden, hier kommt dann erst der wirkliche "Adminuser" zum Einsatz.
Schematisch sieht das grob wie folgt aus:
Wichtig ist, dass wirklich jeder Admin einen dedizierten Tier-PAW User sowie Admin-User hat.
Das macht bei dem klassischen Modell 4 Tiers * 2 Account, ergo 8 Admin Accounts pro Nase.
Die PAW-Systeme sind logischerweise vernünftig abzusichern. Die PAWs sind von außen betrachtet die erste Anlaufstelle für einen möglichen Angriff, allerdings kennt jede PAW wenn überhaupt nur die Hashes für das jeweilige Tier, aber nicht aller anderen.
Es könnte also z.B. passieren, dass ein Angreifer es schafft deine T3-PAW zu kapern. In dem Fall begrenzt sich sein Schaden auf Enduser und deren Clients. Er kann aber nicht deine komplette Backend-Infrastruktur lahmlegen und dich somit in die Handlungsunfähigkeit bringen.
in deiner Gleichung hast du die "PAW" vergessen. "Privileged Access Workstation"
Diese PAW ist als Jumphost für einen dahinterliegenden Admin-Host gedacht.
Die Anmeldung an diesen PAWs erfolgt wiederum mit "PAW" Benutzern, auch wieder aufgeteilt in die jeweiligen Tiers.
Diese PAW-Benutzer können sich nur an der PAW anmelden, darüberhinaus haben diese Nutzer keine Berechtigungen.
Von dort aus kann eine Verbindung zu einem Admin-Host aufgebaut werden, hier kommt dann erst der wirkliche "Adminuser" zum Einsatz.
Schematisch sieht das grob wie folgt aus:
Wichtig ist, dass wirklich jeder Admin einen dedizierten Tier-PAW User sowie Admin-User hat.
Das macht bei dem klassischen Modell 4 Tiers * 2 Account, ergo 8 Admin Accounts pro Nase.
Die PAW-Systeme sind logischerweise vernünftig abzusichern. Die PAWs sind von außen betrachtet die erste Anlaufstelle für einen möglichen Angriff, allerdings kennt jede PAW wenn überhaupt nur die Hashes für das jeweilige Tier, aber nicht aller anderen.
Es könnte also z.B. passieren, dass ein Angreifer es schafft deine T3-PAW zu kapern. In dem Fall begrenzt sich sein Schaden auf Enduser und deren Clients. Er kann aber nicht deine komplette Backend-Infrastruktur lahmlegen und dich somit in die Handlungsunfähigkeit bringen.
1
Ah, das macht schon mehr Sinn.
Aber verbinde ich mich dann von dem PAW aus per RDP auf den zu verwaltenden Server? Was ist wenn zwei Admins gleichzeitig auf einem DC arbeiten müssen?
Oder starte ich dann von dem PAW aus eine MMC und verwalte diese so?
Aber verbinde ich mich dann von dem PAW aus per RDP auf den zu verwaltenden Server? Was ist wenn zwei Admins gleichzeitig auf einem DC arbeiten müssen?
Oder starte ich dann von dem PAW aus eine MMC und verwalte diese so?
Regulär verbindet man sich auf die Admin-Workstation. (via RDP)
Von dort aus solltest du RDP-Verbindungen nur aufbauen, wo es zwingend notwendig ist.
Ich würde mich z.B. niemals interaktiv via RDP auf einem DC anmelden, da dieser idr. als Coreserver aufgesetzt wurde.
RDP ist da maximal ein Fallback, alle regulären Themen fackelt man über die dementsprechenden MMCs ab.
In einem Windows-Netzwerk sind RDP-Anmeldungen auf die Zielsysteme eigentlich nur selten notwendig. Da wo es trotzdem benötigt wird, nutz man halt RDP, bleibt ja nichts anderes über.
Von dort aus solltest du RDP-Verbindungen nur aufbauen, wo es zwingend notwendig ist.
Ich würde mich z.B. niemals interaktiv via RDP auf einem DC anmelden, da dieser idr. als Coreserver aufgesetzt wurde.
RDP ist da maximal ein Fallback, alle regulären Themen fackelt man über die dementsprechenden MMCs ab.
In einem Windows-Netzwerk sind RDP-Anmeldungen auf die Zielsysteme eigentlich nur selten notwendig. Da wo es trotzdem benötigt wird, nutz man halt RDP, bleibt ja nichts anderes über.
Nur dass ich das richtig verstehe. Ich brauche also für jeden Admin 8 VMs? pro Tier einen PAW und zusätzlich einen Admin-Host (Oder wie im Bild Server genannt).
Und ich verbinde mich dann vom physischen PC aus per RDP mit dem PAW Benutzer auf den PAW und von dort aus nochmal per RDP mit dem jeweiligen Tier Admin auf den Admin-Host und dort ist dann MMC, SQL Management Studio etc. drauf installiert und damit verwalte ich die Server?
Sorry nochmal der nachfrage, will nur nicht dass ich doch etwas falsch verstanden habe.
Und ich verbinde mich dann vom physischen PC aus per RDP mit dem PAW Benutzer auf den PAW und von dort aus nochmal per RDP mit dem jeweiligen Tier Admin auf den Admin-Host und dort ist dann MMC, SQL Management Studio etc. drauf installiert und damit verwalte ich die Server?
Sorry nochmal der nachfrage, will nur nicht dass ich doch etwas falsch verstanden habe.
Das hast du etwas falsch verstanden.
Nehmen wir mal dein angedachtes Konstrukt mit T0,1, und 2.
Dann bekommt jeder Admin für jedes Tier jeweils einen PAW-User und einen Admin-User.
Also z.B.
Die PAWs und Admin-Workstations können selbstverständlich von allen Admins des jeweiligen Tiers genutzt werden.
Heißt bei 3-Tiers dementsprechend und jeweils 1.PAW und 1.ADM Jumphost je Tier.
Nehmen wir mal dein angedachtes Konstrukt mit T0,1, und 2.
Dann bekommt jeder Admin für jedes Tier jeweils einen PAW-User und einen Admin-User.
Also z.B.
- T0PAWUSER
- T0ADMUSER
- T1PAWUSER
- T1ADMUSER
- usw.
Die PAWs und Admin-Workstations können selbstverständlich von allen Admins des jeweiligen Tiers genutzt werden.
Heißt bei 3-Tiers dementsprechend und jeweils 1.PAW und 1.ADM Jumphost je Tier.
Achso, aber was passiert dann wenn zwei Admins gleichzeitig einen Server im Tier 1 verwalten wollen?
Es können sich ja nicht beide ohne weiteres per RDP auf die gleiche PAW bzw. Admin Workstations verbinden?
Es können sich ja nicht beide ohne weiteres per RDP auf die gleiche PAW bzw. Admin Workstations verbinden?
Klar, 2 verbindungen gehen immer.
Darüber hinaus bräuchtest du halt RDS-Cals.
Ansonsten kannst du auch einfach mehrere Server provisionieren, je nachdem was für dich günstiger / einfacher ist.
Darüber hinaus bräuchtest du halt RDS-Cals.
Ansonsten kannst du auch einfach mehrere Server provisionieren, je nachdem was für dich günstiger / einfacher ist.
Hast mir wirklich sehr weitergeholfen. Vielen Dank für deine Hilfe
Abend,
Sorge nur dafür das du nicht von deinem Client PC per RDP auf einen PAW gelangen kannst.
Der PAW sollte Eigenständig physikalisch von mir aus neben deinem PC stehen (gut abgesichert, ja mit bitlocker).
Hier läuft ein gewöhnlicher Benutzer, der PAW wie oben beschrieben dient als Sprunghost z.B. auf:
1. Mailserver
2. AV
3. WSUS
Die RDP Verbindung sollte z.B. per /restricted Admin erfolgen das heißt bzw. der Vorteil des Restricted Admin-Modus für RDP besteht darin, dass bei Verwendung dieses Modus keine Anmeldedaten an den Host gesendet werden. Dies reduziert das Risiko von sogenannten "Pass-the-Hash"-Angriffen.
Dieser PAW sollte natürlich nur die Rechte haben auf diesen Servern z.B. per RDP zuzugreifen, sonst gar nichts.
Solltest du auf die Idee kommen, einfach über deinen PC per VM auf deinen Sprunghost zuzugreifen, dann wird das irgendwann böse für dich enden. Sollte dein Client mal kompromittiert werden, dann können auch die Zugangsdaten ausgelesen werden, sollte Kerberos mal Probleme machen und auf NTLM umschalten, dann braucht der Angreifer noch nicht mal das Passwort, der Hash reicht.
Ist der Täter dann auf einem PAW(VM) ist das Spiel eigentlich vorbei.
Deswegen sollte der PAW so gut wie möglich abgesichert sein und wie gesagt im ideal Fall als physische Kiste stehen. Kein Rechner, Server, oder Workstation sollte diesen PC erreichen können.
Sorge nur dafür das du nicht von deinem Client PC per RDP auf einen PAW gelangen kannst.
Der PAW sollte Eigenständig physikalisch von mir aus neben deinem PC stehen (gut abgesichert, ja mit bitlocker).
Hier läuft ein gewöhnlicher Benutzer, der PAW wie oben beschrieben dient als Sprunghost z.B. auf:
1. Mailserver
2. AV
3. WSUS
Die RDP Verbindung sollte z.B. per /restricted Admin erfolgen das heißt bzw. der Vorteil des Restricted Admin-Modus für RDP besteht darin, dass bei Verwendung dieses Modus keine Anmeldedaten an den Host gesendet werden. Dies reduziert das Risiko von sogenannten "Pass-the-Hash"-Angriffen.
Dieser PAW sollte natürlich nur die Rechte haben auf diesen Servern z.B. per RDP zuzugreifen, sonst gar nichts.
Solltest du auf die Idee kommen, einfach über deinen PC per VM auf deinen Sprunghost zuzugreifen, dann wird das irgendwann böse für dich enden. Sollte dein Client mal kompromittiert werden, dann können auch die Zugangsdaten ausgelesen werden, sollte Kerberos mal Probleme machen und auf NTLM umschalten, dann braucht der Angreifer noch nicht mal das Passwort, der Hash reicht.
Ist der Täter dann auf einem PAW(VM) ist das Spiel eigentlich vorbei.
Deswegen sollte der PAW so gut wie möglich abgesichert sein und wie gesagt im ideal Fall als physische Kiste stehen. Kein Rechner, Server, oder Workstation sollte diesen PC erreichen können.
Hallo,
Alternativ kann man RemoteCredentialGuard nutzen. Das wiederrum setzt ein funktionierendes Kerberos voraus, so dass das Verwalten von Domänencontrollern und Virtualisiserungshosts im Desasterfall scheitern kann (z.B. wenn der DC "weg ist").
Ich würde für den Notfall wenigstens eine PAW so konfigurieren, dass RDP auf ohne RestrictedAdminMode oder RemoteCredentialGuard möglich ist. Dazu müssen natürlich auch die Server eingehend weder RestrictedAdminMode noch RemoteCredentialGuard erzwingen.
siehe https://learn.microsoft.com/en-us/windows/security/identity-protection/r ...
Grüße
lcer
Zitat von @watIsLos:
Die RDP Verbindung sollte z.B. per /restricted Admin erfolgen das heißt bzw. der Vorteil des Restricted Admin-Modus für RDP besteht darin, dass bei Verwendung dieses Modus keine Anmeldedaten an den Host gesendet werden. Dies reduziert das Risiko von sogenannten "Pass-the-Hash"-Angriffen.
Das ist definitiv richtig. Aber da muss man ganz genau schauen, dass es keine bösen Überraschungen gibt. Per RestrictedAdmin verbundene Benutzer können sich nicht "als Benutzer" auf weitere Systeme verbinden sondern benutzen das Computerkonto des Hosts. Sprich - die auf anderen System bereitgestellten Freigaben müssen dem zu administrierenden Server Zugriffsrechte erteilen, nicht dem Nutzer. Das passt nicht in allen Sicherheitskontexten.Die RDP Verbindung sollte z.B. per /restricted Admin erfolgen das heißt bzw. der Vorteil des Restricted Admin-Modus für RDP besteht darin, dass bei Verwendung dieses Modus keine Anmeldedaten an den Host gesendet werden. Dies reduziert das Risiko von sogenannten "Pass-the-Hash"-Angriffen.
Alternativ kann man RemoteCredentialGuard nutzen. Das wiederrum setzt ein funktionierendes Kerberos voraus, so dass das Verwalten von Domänencontrollern und Virtualisiserungshosts im Desasterfall scheitern kann (z.B. wenn der DC "weg ist").
Ich würde für den Notfall wenigstens eine PAW so konfigurieren, dass RDP auf ohne RestrictedAdminMode oder RemoteCredentialGuard möglich ist. Dazu müssen natürlich auch die Server eingehend weder RestrictedAdminMode noch RemoteCredentialGuard erzwingen.
siehe https://learn.microsoft.com/en-us/windows/security/identity-protection/r ...
Grüße
lcer
Hallo Icer,
bei uns habe ich das so eingerichtet das über diesen einen PAW vier verschiedene Server angesteuert werden.
Der PAW soll nicht dafür genutzt werden dann von einem Server auf den nächsten zu springen.
bei uns habe ich das so eingerichtet das über diesen einen PAW vier verschiedene Server angesteuert werden.
Der PAW soll nicht dafür genutzt werden dann von einem Server auf den nächsten zu springen.
Zitat von @watIsLos:
Sorge nur dafür das du nicht von deinem Client PC per RDP auf einen PAW gelangen kannst.
Der PAW sollte Eigenständig physikalisch von mir aus neben deinem PC stehen (gut abgesichert, ja mit bitlocker).
Sorge nur dafür das du nicht von deinem Client PC per RDP auf einen PAW gelangen kannst.
Der PAW sollte Eigenständig physikalisch von mir aus neben deinem PC stehen (gut abgesichert, ja mit bitlocker).
Das ist natürlich der sicherste Weg. Nur wie funktioniert dass dann wenn ich mit meinem Notebook z.B. Zuhause bin?
Dann muss ich mich ja trotzdem irgendwie auf die PAW verbinden können?
Außerdem bin ich davon ausgegangen dass die Lösung mit der PAW und dem Admin-Host als zusätzliche Schicht, diese Gefahr ziemlich eindämmt.
Der Passworthash beim Verbinden per RDP wird aber dann immer noch auf dem "Quellhost" gespeichert richtig?
Ist das nicht eher die größere Gefahr? Aber warum müssen dann eigentlich bei jedem erneuten Verbinden per RDP der Benutzername und Passwort erneut eingegeben werden? Warum speichert er die Anmeldedaten überhaupt zwischen?
Und mir ist noch eine andere Frage eingefallen:
Wir nutzen bei uns auch VMware vsphere. Von wo aus melde ich mich denn auf der Weboberfläche an?
Doch vom jeweiligen Admin-Host oder? Einer unserer DCs ist aber auch eine VM. Ich müsste dann den Zugriff auf die DC VM nur mit dem Tier 0 Admin und auf andere Server mit dem Tier 1 Admin erlauben richtig? Muss mich dann also auch mit dem jeweiligen Konto beim vsphere anmelden.
Vielen Dank für die Hilfe und viele Grüße
Das ist natürlich der sicherste Weg. Nur wie funktioniert dass dann wenn ich mit meinem Notebook z.B. Zuhause bin?
Dann muss ich mich ja trotzdem irgendwie auf die PAW verbinden können?
Dann muss ich mich ja trotzdem irgendwie auf die PAW verbinden können?
Ich habe von zu Hause aus mit einem Laptop Zugriff auf die jeweiligen Server. Wichtig ist das dieser Computer oder Laptop für nichts anderes benutzt wird!
Sonst ist auch hier die Gefahr zu groß das er verseucht werden könnte.
Im Urlaub oder von zu Hause aus auf den DC zuzugreifen ist ein bequemer Weg, auch ich habe das vor vielen Jahren so gemacht bis 2016 die ersten professionellen Ransomware auf den Markt kam, seitdem ist der DC nur noch über einen physischen PAW in der Firma erreichbar.
Wenn etwas am Domänencontroller gemacht werden muss, dann macht man das vor Ort oder man hat einen zweiten Kollegen, der sich auch damit auskennt und das übernimmt, wenn man im Urlaub, auf Reisen oder sonst wie abwesend ist.
Der Passworthash beim Verbinden per RDP wird aber dann immer noch auf dem "Quellhost" gespeichert richtig?
Ist das nicht eher die größere Gefahr? Aber warum müssen dann eigentlich bei jedem erneuten Verbinden per RDP der Benutzername und Passwort erneut eingegeben werden? Warum speichert er die Anmeldedaten überhaupt zwischen?
Ob der Hash auf dem Sprunghost gespeichert wird oder nicht ist erst einmal irrelevant. Natürlich kann er ausgelesen werden, deshalb ist es auch so wichtig, dass dieser Sprunghost bzw. Client, mit dem man sich per RDP verbindet, so gut wie möglich abgesichert ist.
Da dich das Thema interessiert, versetze dich in die Rolle des Angreifers.
Erstelle eine Kopie von einem Client und einem Server und lade diese in die VM.
Jetzt kannst Du selbst testen, was ausgelesen werden kann, z.B. mit einem Programm wie Mimikatz.
Und mir ist noch eine andere Frage eingefallen:
Wir nutzen bei uns auch VMware vsphere. Von wo aus melde ich mich denn auf der Weboberfläche an?
Doch vom jeweiligen Admin-Host oder? Einer unserer DCs ist aber auch eine VM. Ich müsste dann den Zugriff auf die DC VM nur mit dem Tier 0 Admin und auf andere Server mit dem Tier 1 Admin erlauben richtig? Muss mich dann also auch mit dem jeweiligen Konto beim vsphere anmelden.
Wir nutzen bei uns auch VMware vsphere. Von wo aus melde ich mich denn auf der Weboberfläche an?
Doch vom jeweiligen Admin-Host oder? Einer unserer DCs ist aber auch eine VM. Ich müsste dann den Zugriff auf die DC VM nur mit dem Tier 0 Admin und auf andere Server mit dem Tier 1 Admin erlauben richtig? Muss mich dann also auch mit dem jeweiligen Konto beim vsphere anmelden.
Wir verwenden kein VMware vpshere, daher kann ich dazu nichts sagen, aber ich bin mir sicher, dass einige hier schon Erfahrung damit haben.
Hallo,
Eine echte Person sitzt an dem echten PAW und meldet sich an. Von dort aus wird administriert.
Falsch ist:
Man verbindet sich vom nicht-PAW-Laptop auf die PAW und administriert. Das darf nicht sein.
Grüße
lcer
Zitat von @bnk890:
Das ist natürlich der sicherste Weg. Nur wie funktioniert dass dann wenn ich mit meinem Notebook z.B. Zuhause bin?
Dann muss ich mich ja trotzdem irgendwie auf die PAW verbinden können?
Wenn das Notebook ein PAW ist, dann ist alles OK. Im Grunde ist das so vorgesehen:Das ist natürlich der sicherste Weg. Nur wie funktioniert dass dann wenn ich mit meinem Notebook z.B. Zuhause bin?
Dann muss ich mich ja trotzdem irgendwie auf die PAW verbinden können?
Eine echte Person sitzt an dem echten PAW und meldet sich an. Von dort aus wird administriert.
Falsch ist:
Man verbindet sich vom nicht-PAW-Laptop auf die PAW und administriert. Das darf nicht sein.
Grüße
lcer
Also bräuchte ich dann Zuhause entweder eine zweite PAW oder müsste einen zweiten Laptop immer mit hin und her nehmen?
Wofür ist dann der Ansatz mit einem zusätzlichem Admin-Host bzw. Admin-Server pro Tier wie in der Antwort von Cloudrakete?
Ich habe gedacht das mache ich damit ich mich dann eben auf die PAW und von da aus auf den Admin-Host bzw. Admin-Server jeweils per RDP verbinden kann und somit eine zusätzliche Schicht als Absicherung dazwischen ist.
Weil bei eurer Lösung brauche ich ja nur die PAW auf welcher ich MMC etc. nutze?
Diese ist ja physisch und nicht per RDP oder Internet etc. erreichbar, also sollte da ja so gut wie unmöglich jemand einen Hash abgreifen können oder? Zumindest solange er nicht physischen Zugriff auf die PAW hat..
Wofür ist dann der Ansatz mit einem zusätzlichem Admin-Host bzw. Admin-Server pro Tier wie in der Antwort von Cloudrakete?
Ich habe gedacht das mache ich damit ich mich dann eben auf die PAW und von da aus auf den Admin-Host bzw. Admin-Server jeweils per RDP verbinden kann und somit eine zusätzliche Schicht als Absicherung dazwischen ist.
Weil bei eurer Lösung brauche ich ja nur die PAW auf welcher ich MMC etc. nutze?
Diese ist ja physisch und nicht per RDP oder Internet etc. erreichbar, also sollte da ja so gut wie unmöglich jemand einen Hash abgreifen können oder? Zumindest solange er nicht physischen Zugriff auf die PAW hat..
Hallo,
es darf keine Rechner geben, auf denen die Tier-Credentials gemischt werden. Die bittere Wahreit ist also, dass Du pro Tier eine (oder mehrere) PAWs brauchst.
Wenn Du bisher keine PAWs hast, ist es aber alle mal besser, wenn Du ein separates Notebook verwendest, von dem aus Du ausschließlich Adminrecht-erfordernde Tätigkeiten betreibst. Das ist dann aber kein sauberes Tier/PAW-Modell.
Grüße
lcer
es darf keine Rechner geben, auf denen die Tier-Credentials gemischt werden. Die bittere Wahreit ist also, dass Du pro Tier eine (oder mehrere) PAWs brauchst.
Wenn Du bisher keine PAWs hast, ist es aber alle mal besser, wenn Du ein separates Notebook verwendest, von dem aus Du ausschließlich Adminrecht-erfordernde Tätigkeiten betreibst. Das ist dann aber kein sauberes Tier/PAW-Modell.
Grüße
lcer
Hallo,
aber das ist doch nicht wirklich in der Praxis (zumindest für kleinere oder mittlere Betriebe) umsetzbar.
Um es wirklich richtig zu machen müsste ja dann jeder Admin 4-5 Notebooks haben (eines mit dem er E-Mails etc. bearbeitet und je Tier eines).
Diese müsste er dann jeden Tag mit nach Hause und wieder in die Firma nehmen. Das macht doch keiner..
Wahrscheinlich habe ich aber auch die Frage einfach nicht ganz richtig gestellt..
Mir kommt die Lösung von Cloudrakete zumindest deutlich eher umsetzbar vor.
Und dadurch sollte doch das Risiko auch deutlich reduziert sein.
Ein Angreifer müsste ja dann erst einmal Adminrechte auf einem Tier 2 Client bekommen um damit den Passworthash für den PAW Benutzer auszulesen. Zumindest ist es dann nicht mehr schwer an diesen zu kommen.
Ich will nur von unserem jetzigen Stand weg und wollte es gleich so sicher wie möglich aber auch möglichst Praxistauglich machen..
aber das ist doch nicht wirklich in der Praxis (zumindest für kleinere oder mittlere Betriebe) umsetzbar.
Um es wirklich richtig zu machen müsste ja dann jeder Admin 4-5 Notebooks haben (eines mit dem er E-Mails etc. bearbeitet und je Tier eines).
Diese müsste er dann jeden Tag mit nach Hause und wieder in die Firma nehmen. Das macht doch keiner..
Wahrscheinlich habe ich aber auch die Frage einfach nicht ganz richtig gestellt..
Mir kommt die Lösung von Cloudrakete zumindest deutlich eher umsetzbar vor.
Und dadurch sollte doch das Risiko auch deutlich reduziert sein.
Ein Angreifer müsste ja dann erst einmal Adminrechte auf einem Tier 2 Client bekommen um damit den Passworthash für den PAW Benutzer auszulesen. Zumindest ist es dann nicht mehr schwer an diesen zu kommen.
Ich will nur von unserem jetzigen Stand weg und wollte es gleich so sicher wie möglich aber auch möglichst Praxistauglich machen..
Zitat von @bnk890:
Hallo,
Mir kommt die Lösung von Cloudrakete zumindest deutlich eher umsetzbar vor.
Und dadurch sollte doch das Risiko auch deutlich reduziert sein.
also, Cloudrakete schrieb folgendes:Hallo,
Mir kommt die Lösung von Cloudrakete zumindest deutlich eher umsetzbar vor.
Und dadurch sollte doch das Risiko auch deutlich reduziert sein.
Zitat von @Cloudrakete:
Die PAWs und Admin-Workstations können selbstverständlich von allen Admins des jeweiligen Tiers genutzt werden.
Heißt bei 3-Tiers dementsprechend und jeweils 1.PAW und 1.ADM Jumphost je Tier.
Die PAWs und Admin-Workstations können selbstverständlich von allen Admins des jeweiligen Tiers genutzt werden.
Heißt bei 3-Tiers dementsprechend und jeweils 1.PAW und 1.ADM Jumphost je Tier.
macht 6 Rechner. Wobei ich auch auf die Jumphosts verzichten könnte. Auf die PAW pro Tier jedoch nicht, wenn es sauber sein soll.
Grüße
lcer
Ja klar, aber diese könnten als VM umgesetzt werden. Es geht ja hauptsächlich darum dass keiner mehrere Notebooks mit sich rumträgt..
Also man muss auch immer etwas aufpassen.
Klar, sind die von den Kollegen beschriebenen Szenarien sehr sicher bzw. sehr nah an der maximal möglichen Sicherheit.
Auf der anderen Seite muss das Setup in Gänze für dich aber noch händelbar bleiben. Die Erfahrung zeigt, dass zu komplexe (wenn auch sichere) Setups immer darin enden, dass doch wieder Krücken und Brücken gebaut werden, welche dann noch unsichererer sind als hätte man zu Beginn z.B. auf physische PAWs verzichtet und wäre mit VMs ins Rennen gestartet.
Ich habe ja weiter oben ausgeführt: Du hast je Tier eine dedizierte PAW. Diese PAW stellt nur den "Access" auf dahinterliegende Admin-VMs zur Verfügung.
Bedeutet: Auf deinen Notebook sind maximal die Hashes für die PAW. Auf der PAW nur die Hashes für den jeweiligen Tier-Admin. Wenn du jetzt Funktionen wie Credential Guard nutzt, kannst du dich in Theorie sogar vor dem Diebstahl der Hashes schützen.
Es darf nicht vergessen werden, dass solch ein Tieringkonstrukt samt PAW und Admin-Maschinen nur ein Baustein in einer gesamtheitlichen Security-Strategie sind. Du wirst darüber hinaus Hardening via GPOs und anderen Einstellungen benötigen, damit in Summe dein Setup weitesgehend wasserdicht ist.
Am Ende musst du immer zwischen Schutzbedarf, Risiko, Risikoeintrittwahrscheinlichtkeit und den damit verbundenen Kosten ein Gleichgewicht finden.
Als Beispiel: Ein Unternehmen mit 1.000.000€ Umsatz im Jahr für den Einsatz von 5.000.000 + Betriebskosten durch Mehraufwand abzusichern steht in keinem Verhältnis
Klar, sind die von den Kollegen beschriebenen Szenarien sehr sicher bzw. sehr nah an der maximal möglichen Sicherheit.
Auf der anderen Seite muss das Setup in Gänze für dich aber noch händelbar bleiben. Die Erfahrung zeigt, dass zu komplexe (wenn auch sichere) Setups immer darin enden, dass doch wieder Krücken und Brücken gebaut werden, welche dann noch unsichererer sind als hätte man zu Beginn z.B. auf physische PAWs verzichtet und wäre mit VMs ins Rennen gestartet.
Ich habe ja weiter oben ausgeführt: Du hast je Tier eine dedizierte PAW. Diese PAW stellt nur den "Access" auf dahinterliegende Admin-VMs zur Verfügung.
Bedeutet: Auf deinen Notebook sind maximal die Hashes für die PAW. Auf der PAW nur die Hashes für den jeweiligen Tier-Admin. Wenn du jetzt Funktionen wie Credential Guard nutzt, kannst du dich in Theorie sogar vor dem Diebstahl der Hashes schützen.
Es darf nicht vergessen werden, dass solch ein Tieringkonstrukt samt PAW und Admin-Maschinen nur ein Baustein in einer gesamtheitlichen Security-Strategie sind. Du wirst darüber hinaus Hardening via GPOs und anderen Einstellungen benötigen, damit in Summe dein Setup weitesgehend wasserdicht ist.
Am Ende musst du immer zwischen Schutzbedarf, Risiko, Risikoeintrittwahrscheinlichtkeit und den damit verbundenen Kosten ein Gleichgewicht finden.
Als Beispiel: Ein Unternehmen mit 1.000.000€ Umsatz im Jahr für den Einsatz von 5.000.000 + Betriebskosten durch Mehraufwand abzusichern steht in keinem Verhältnis
Hallo bnk,
ich habe nun tatsächlich meinen zig Jahre inaktiven Account reaktiviert um dir zu Antworten ;)
Vergessen wird bei der ganzen Geschichte gern das grundlegende Problem. Passwörter, Anmeldehashes usw. Die meisten vergessen die Admin-Konten in die Protected Users Gruppe zu packen und schwupp, werden die Hashes 1) unsicher und 2) sehr lang zwischengespeichert, die Sitzungen laufen nicht ab usw usw.
Baut man so ein Konstrukt, sollte man sich die Zeit nehmen und mindestens eine PKI bereitstellen, Smartcards ausrollen und die Anmeldungen der Admins mit Smartcards erzwingen. Es gibt z.B. Yubikeys, dort kannst du 4 Smartcard-Slots für verschiedene Anmeldungen ablegen und per Biometrie absichern. Eine solche Anmeldung für Admins lässt sich weder mit Keyloggern, Mimikatz oder anderen Tools abgreifen.
Ist ein Angreifer auf deinem System und du meldest dich an der PAW klassisch an, hat der Angreifer selbst auch die Zugangsdaten zur PAW. Dann öffnest du deine Konsole auf der PAW, gibst deine Zugangsdaten ein und die zweite Ebene ich auch kompromitiert. Mit Smartcards gibt es diese Lücke nicht mehr. Ohne physischen Zugriff auf die Karte wird es sehr dünn. Hier würde mir nur noch einfallen den Grafikspeicher des Admin-Systems abzugreifen um zumindest an Informationen zu kommen.
ich habe nun tatsächlich meinen zig Jahre inaktiven Account reaktiviert um dir zu Antworten ;)
Vergessen wird bei der ganzen Geschichte gern das grundlegende Problem. Passwörter, Anmeldehashes usw. Die meisten vergessen die Admin-Konten in die Protected Users Gruppe zu packen und schwupp, werden die Hashes 1) unsicher und 2) sehr lang zwischengespeichert, die Sitzungen laufen nicht ab usw usw.
Baut man so ein Konstrukt, sollte man sich die Zeit nehmen und mindestens eine PKI bereitstellen, Smartcards ausrollen und die Anmeldungen der Admins mit Smartcards erzwingen. Es gibt z.B. Yubikeys, dort kannst du 4 Smartcard-Slots für verschiedene Anmeldungen ablegen und per Biometrie absichern. Eine solche Anmeldung für Admins lässt sich weder mit Keyloggern, Mimikatz oder anderen Tools abgreifen.
Ist ein Angreifer auf deinem System und du meldest dich an der PAW klassisch an, hat der Angreifer selbst auch die Zugangsdaten zur PAW. Dann öffnest du deine Konsole auf der PAW, gibst deine Zugangsdaten ein und die zweite Ebene ich auch kompromitiert. Mit Smartcards gibt es diese Lücke nicht mehr. Ohne physischen Zugriff auf die Karte wird es sehr dünn. Hier würde mir nur noch einfallen den Grafikspeicher des Admin-Systems abzugreifen um zumindest an Informationen zu kommen.
Oh ich fühle mich geehrt ;)
Das mit den Smartcards hört sich sehr interessant an.
Daran habe ich tatsächlich bis jetzt gar nicht wirklich gedacht.
Also könnte ich dann das Konzept mit den Paws und den Admin-Hosts umsetzen und die Anmeldung der Admins nur noch per Smartcard erlauben. So sollte ich doch eine sehr gute Lösung haben.
Das mit den Smartcards hört sich sehr interessant an.
Daran habe ich tatsächlich bis jetzt gar nicht wirklich gedacht.
Also könnte ich dann das Konzept mit den Paws und den Admin-Hosts umsetzen und die Anmeldung der Admins nur noch per Smartcard erlauben. So sollte ich doch eine sehr gute Lösung haben.
Korrekt. Ist eine PKI bereits vorhanden, dauert das ganze nur wenige Stunden. Wenn du noch keine PKI hast, schau dir bitte zuerst die Dokumentation dazu an.
vlg
vlg
Smartcards sind schon eine coole Sache, aber auch nichts, was man mal eben so macht, die Einrichtung ist auch nicht ohne...
Hallo,
auch mit Smartcards muss man sich einen Plan machen, was im Desasterfall passiert. Die Smartcardanmeldung ist nur möglich, wenn ein DC erreichbar ist.
Grüße
lcer
auch mit Smartcards muss man sich einen Plan machen, was im Desasterfall passiert. Die Smartcardanmeldung ist nur möglich, wenn ein DC erreichbar ist.
Grüße
lcer
Hallo @lcer00,
Wenn kein DC erreichbar ist, hast du ganz andere Probleme. Auf Memberservern gibt es noch die Möglichkeit mit lokalen Admin-Konten anzumelden um die Verbindung zur Domäne wieder herzustellen. Im Falle eines kompromitierten Servers spielen diese lokalen Admin-Konten keine Rolle, da der Server zu diesem Zeitpunkt bereits komprimitiert ist. Die lokalen Kennwörter lassen sich mit LAPS ganz gut verwalten (M365-Abo nötig).
Die aktuelle CRL und die AIA liegt im LDAP, also gibt es das Problem auf DCs selbst nicht.
Jeder Admin, der Offline/Zwischengespeicherte Credentials für Domänenweite Admins nutzt, sollte gesteinigt werden. Gut, nicht ganz so brutal, aber jede Technologie, die Passwörter verwendet, ist für Administrative Zugänge einfach zu riskant.
@watIsLos
Völlig richtig. Sollte die PKI nicht vorhanden sein oder die Erfahrung damit fehlen, muss man zwangläufig schulen oder sich vollständig mit dem Thema beschäftigen. Fehlendes Wissen entschuldigt aber im Fehlerfall weder die Versicherung noch der Angreifer. Leider.
vlg
Wenn kein DC erreichbar ist, hast du ganz andere Probleme. Auf Memberservern gibt es noch die Möglichkeit mit lokalen Admin-Konten anzumelden um die Verbindung zur Domäne wieder herzustellen. Im Falle eines kompromitierten Servers spielen diese lokalen Admin-Konten keine Rolle, da der Server zu diesem Zeitpunkt bereits komprimitiert ist. Die lokalen Kennwörter lassen sich mit LAPS ganz gut verwalten (M365-Abo nötig).
Die aktuelle CRL und die AIA liegt im LDAP, also gibt es das Problem auf DCs selbst nicht.
Jeder Admin, der Offline/Zwischengespeicherte Credentials für Domänenweite Admins nutzt, sollte gesteinigt werden. Gut, nicht ganz so brutal, aber jede Technologie, die Passwörter verwendet, ist für Administrative Zugänge einfach zu riskant.
@watIsLos
Völlig richtig. Sollte die PKI nicht vorhanden sein oder die Erfahrung damit fehlen, muss man zwangläufig schulen oder sich vollständig mit dem Thema beschäftigen. Fehlendes Wissen entschuldigt aber im Fehlerfall weder die Versicherung noch der Angreifer. Leider.
vlg
Zitat von @Cloudrakete:
Also man muss auch immer etwas aufpassen.
Klar, sind die von den Kollegen beschriebenen Szenarien sehr sicher bzw. sehr nah an der maximal möglichen Sicherheit.
Auf der anderen Seite muss das Setup in Gänze für dich aber noch händelbar bleiben. Die Erfahrung zeigt, dass zu komplexe (wenn auch sichere) Setups immer darin enden, dass doch wieder Krücken und Brücken gebaut werden, welche dann noch unsichererer sind als hätte man zu Beginn z.B. auf physische PAWs verzichtet und wäre mit VMs ins Rennen gestartet.
Ich habe ja weiter oben ausgeführt: Du hast je Tier eine dedizierte PAW. Diese PAW stellt nur den "Access" auf dahinterliegende Admin-VMs zur Verfügung.
Bedeutet: Auf deinen Notebook sind maximal die Hashes für die PAW. Auf der PAW nur die Hashes für den jeweiligen Tier-Admin. Wenn du jetzt Funktionen wie Credential Guard nutzt, kannst du dich in Theorie sogar vor dem Diebstahl der Hashes schützen.
Es darf nicht vergessen werden, dass solch ein Tieringkonstrukt samt PAW und Admin-Maschinen nur ein Baustein in einer gesamtheitlichen Security-Strategie sind. Du wirst darüber hinaus Hardening via GPOs und anderen Einstellungen benötigen, damit in Summe dein Setup weitesgehend wasserdicht ist.
Am Ende musst du immer zwischen Schutzbedarf, Risiko, Risikoeintrittwahrscheinlichtkeit und den damit verbundenen Kosten ein Gleichgewicht finden.
Als Beispiel: Ein Unternehmen mit 1.000.000€ Umsatz im Jahr für den Einsatz von 5.000.000 + Betriebskosten durch Mehraufwand abzusichern steht in keinem Verhältnis
Also man muss auch immer etwas aufpassen.
Klar, sind die von den Kollegen beschriebenen Szenarien sehr sicher bzw. sehr nah an der maximal möglichen Sicherheit.
Auf der anderen Seite muss das Setup in Gänze für dich aber noch händelbar bleiben. Die Erfahrung zeigt, dass zu komplexe (wenn auch sichere) Setups immer darin enden, dass doch wieder Krücken und Brücken gebaut werden, welche dann noch unsichererer sind als hätte man zu Beginn z.B. auf physische PAWs verzichtet und wäre mit VMs ins Rennen gestartet.
Ich habe ja weiter oben ausgeführt: Du hast je Tier eine dedizierte PAW. Diese PAW stellt nur den "Access" auf dahinterliegende Admin-VMs zur Verfügung.
Bedeutet: Auf deinen Notebook sind maximal die Hashes für die PAW. Auf der PAW nur die Hashes für den jeweiligen Tier-Admin. Wenn du jetzt Funktionen wie Credential Guard nutzt, kannst du dich in Theorie sogar vor dem Diebstahl der Hashes schützen.
Es darf nicht vergessen werden, dass solch ein Tieringkonstrukt samt PAW und Admin-Maschinen nur ein Baustein in einer gesamtheitlichen Security-Strategie sind. Du wirst darüber hinaus Hardening via GPOs und anderen Einstellungen benötigen, damit in Summe dein Setup weitesgehend wasserdicht ist.
Am Ende musst du immer zwischen Schutzbedarf, Risiko, Risikoeintrittwahrscheinlichtkeit und den damit verbundenen Kosten ein Gleichgewicht finden.
Als Beispiel: Ein Unternehmen mit 1.000.000€ Umsatz im Jahr für den Einsatz von 5.000.000 + Betriebskosten durch Mehraufwand abzusichern steht in keinem Verhältnis
Ein sehr interessanter Thread - ich denke, ich habe das Prinzip verstanden: das Tiering, damit evtl. kompromittierte Logins nicht alle Server betreffen, die PAW, damit man nur indirekt auf das Server-Netzwerk zugreifen kann (so wie ich das verstehe, ist die PAW dann sowas wie früher ein "Jumphost").
Ich verstehe den typischen Zugriffspfad eines Admins so (wie im Bild vom ersten Post in diesem Thread AD Tiering Umsetzung):
- Arbeitsplatz-PC (der auch für Office, Internet, etc. verwendet wird), verwendet RDP um auf eine der PAWs zuzugreifen ("nur" mit den Credentials für den Zugriff auf die PAW)
- PAW(Jumphost), wird verwendet um über MMC, evtl. RDP, etc. Verbindungen zum Server herzustellen - für diese Verbindungen wird (worst case) ein Domain-Admin-Recht benötigt. Die Software, die auf der PAW läuft, benötigt Passwort-Hashes um auf den Server zugreifen zu können.
- Server (hardened) erlauben Admin-Logins nur für PAWs, haben evtl. Firewall-Regeln für RDP nur für PAW-Zugriff, ...
Als (Windows)Entwickler und Hobby-Admin habe ich trotzdem ein Verständnisproblem: Offensichtlich ist eines der größten Themen das caching der Credentials (Passwort-Hash), da dann auf dem (potenziell kompromittierten) Rechner des Admins (Arbeitsplatz-PC) die credentials der PAW missbräuchlich verwendet werden könnten.
Fragen:
- Auf dem Arbeitsplatz-PC des Admins: Würde RDP keine Hashes (lokal) speichern, dann wäre das gar kein Angriffsvektor?
- Ist das ein Designfehler des RDP-Clients und es wäre dann sicherer den (remote-Zugriff auf die PAW) über andere Software/Hardware (z. B. KVM über IP, kann natürlich dann keinen Filetransfer oder VNC, ...) zu machen?
- Wenn über die PAW wieder mit RDP auf den Server zugegriffen wird (klar, nicht für Core), dann wäre doch ein Remotezugriff direkt auf die Server vom Arbeitsplatz-PC (über KVM, ...) kaum schlechter...?
Danke!
Tiering ist heutzutage ein Muss, aber es gibt immer noch Fälle, in denen sich ein Admin mit Domänenberechtigung im Netz bewegt.
Egal wie restriktiv Dein Konstrukt ist, sobald der Angreifer sich diese Berechtigung erschlichen hat, ist Dein Netz im Grunde nicht mehr zu retten. Es sei denn, du hast es rechtzeitig bemerkt. (idps).
Egal wie restriktiv Dein Konstrukt ist, sobald der Angreifer sich diese Berechtigung erschlichen hat, ist Dein Netz im Grunde nicht mehr zu retten. Es sei denn, du hast es rechtzeitig bemerkt. (idps).
