Um die Sicherheit innerhalb des Active Directory zu erhöhen reichen meist schon kleine organisatorische Maßnahmen in Verbindung mit kostenlosen Tools. Viele weit verbreitete Angriffswege können mit ein paar kleinen Änderungen und recht einfachen Maßnahmen zumindest schon deutlich eingedämmt werden. Im folgenden Artikel taucht oft das Wort “Angreifer” auf, mit “Angreifer” ist allerdings nicht unbedingt eine Person gemeint, die es sich zur Aufgabe gemacht hat in ein Netzwerk einzudringen. “Angreifer” steht im folgenden Artikel auch für automatisierte Schadsoftware, welche mitunter darauf ausgelegt ist möglichst viele Opfer zu finden, dabei aber wenig zielgerichtet vorgeht.
Einleitung
Gerade in kleinen Umgebungen mit nur wenigen Servern und Clients, können Bordmittel und kostenlose Tools genutzt werden um ein gewisses Maß an Sicherheit zu gewährleisten und es Angreifern zumindest zu erschweren an die Kronjuwelen des Unternehmens zu kommen.
In ersten Teil der Artikelserie geht es um ein wenig Theorie, der zweite Artikel beschreibt dann die Umsetzung anhand eines Beispiels. Zunächst aber zur Theorie.
Weit verbreitete Einfallstore und Angriffswege
Das größte Einfallstor für Viren und Trojaner aller Art, aber auch für zielgerichtete Angriffe auf Unternehmen, sind E-Mails. Von gefälschten Bewerbungen mit schädlichen Anhang bis hin zu maßgeschneiderten Phishing Mails die es auf die Zugangsdaten der Anwender abgesehen haben, immer wieder schaffen schaffen es solche Mails an den Spamfiltern und Virenscannern vorbei zu kommen. Ist die Mail erst im Postfach angekommen, erkennen Anwender Phishing Mails mit einer Quote von 59 % als Phishing. Die Wahrscheinlichkeit das ein Anwender eine schädliche Mail öffnet, ist also recht hoch. Hier findet sich dazu ein lesenswerter Artikel:
E-Mails sind wichtigstes Einfallstor für Cyberangriffe
Ein weiteres beliebtes Einfallstor ist der Browser, bekannte Sicherheitslücken werden durch Webseiten ausgenutzt um auf diesen Weg an Zugangsdaten der Anwender zu kommen oder Malware auf die Rechner zu schleusen.
Wenn ein Angreifer erst einmal geschafft hat einen einzelnen Rechner im Unternehmen unter seine Kontrolle zu bringen, ist der Rest erstaunlich einfach. Hat man also bereits einen Fuß im Unternehmen, ist oft das “Lateral Movement” eine beliebte Methode um weiter in das Netzwerk vorzudringen. Beim “Lateral Movement” bewegt sich ein Angreifer zunächst “horizontal” und möglichst unauffällig im Netzwerk ohne Schäden anzurichten. Ziel ist es weitere Rechner unter Kontrolle zu bringen, ein Angreifer würde sich also beispielsweise von einem infizierten versuchen, weitere Clients im Netzwerk unter seine Kontrolle zu bringen.
Gerade in Unternehmen in denen Active Directory genutzt wird, kommen nach dem Lateral Movement oft die “Pass the Hash (PTH) oder “Pass the Ticket (PTT)” Angriffe. Ein Angreifer wartet also auf infizierten Clients ab, bis sich ein privilegiertes Konto (beispielsweise ein Benutzer mit Administrator Rechten im Active Directory) anmeldet. Die Passwort Hashes oder das Kerberos Ticket welches der privilegierte Benutzer auf dem infizierten Rechner hinterlässt, kann der Angreifer nun nutzen, um sich tiefer in das Netzwerk vorzuarbeiten. Schafft es der Angreifer an ein Kerberos Ticket eines Domain Administrator zu kommen, kann er sich damit an Servern und Domain Controllern des Unternehmens anmelden. Nahezu alle Daten wären somit auch für den Angreifer einsehbar und man müsste sich nur noch Gedanken darum machen, wie man die Daten möglichst unbemerkt nach draußen schleust. Ein sehr bekanntes Beispiel für einen Angriff, der nach diesem Muster durchgeführt wurde, war der deutsche Bundestag im Jahr 2016.
Dieser Angriffsweg erfordert kein großes fachliches Wissen, wenn das Ziel nicht unbedingt der Bundestag ist. Verschiedene Viren und Trojaner können solche Angriffe völlig automatisch durchführen. Ein Unternehmen muss also nicht erst “relevant für Hacker” werden, es reicht unter Umständen schon sich einen entsprechenden Virus auf einem Rechner einzufangen.
Der hier beschriebe Angriffsweg und das Vorgehen ist übrigens nicht neu und funktioniert so bereits seit Jahren, daher sollte man sich nicht nur auf Virenscanner und Spamfilter verlassen.
Admin Tiers: Wieso, weshalb, warum!?
Ähnlich wie die Segmentierung des Netzwerks anhand von VLANs, kann man sich auch die Segmentierung des Active Directory in Admin Tiers vorstellen. Server, Services und Clients werden in 3 Tiers unterteilt. Das Tier 0 enthält die kritischsten Systeme, in diesem Fall also beispielsweise die Domain Controller. Das Tier 1 enthält Server die Services für die Clients anbieten, beispielsweise FileServer oder Web Server. Das Tier 2 enthält alle Clients, also PCs, Notebooks und Drucker.
Die Klassifizierung der Systeme in die Admins Tiers findet dabei nicht anhand der Kritikalität der jeweiligen Dienste eines Servers statt, sondern anhand der Masse an Systemen die der jeweilige Server oder Dienst kontrolliert. Ein Domain Controller kontrolliert beispielsweise alle anderen Systeme innerhalb des Active Directory, daher sind die DCs auf dem Tier 0 angesiedelt. Ein Fileserver kann zwar beispielsweise sehr wichtig für das Unternehmen sein, da Benutzer nicht in der Lage sind ohne Netzlaufwerke zu arbeiten, aber der Fileserver kontrolliert keine anderen Server, Clients oder Dienste. Daher wird ein Fileserver dem Tier 1 zugeordnet. Clients bilden dann das Tier 2.
Hier mal eine kleine Grafik zur Verdeutlichung:
Quelle: Active Directory-Verwaltungsebenenmodell
Ziel der Admin Tiers ist es nun zu erreichen, dass Tier 0 Systeme zwar Tier 0, Tier 1 und Tier 2 Systeme kontrollieren dürfen (beispielsweise kontrolliert ein DC mit Gruppenrichtlinien Tier 1 und Tier 2 Systeme), aber es einem Tier 1 oder Tier 2 System nicht ermöglicht wird ein Tier 0 System zu kontrollieren.
Hinweis: Exchange Server sind als Tier 0 System einzuordnen, wenn die Exchange Server nicht im “Sicherheitsmodell für geteilte Berechtigungen” installiert wurden. Die Exchange Installation ohne “Active Directory Sicherheitsmodell” ist allerdings die Standardeinstellung:
Die Grafik macht es etwas deutlicher:
Quelle: Active Directory-Verwaltungsebenenmodell
Ein Tier 1 System erhält beispielsweise die Kontrolle über Tier 0 Systeme, wenn es Dienste mit Domain Admin Berechtigung ausführt. Dies könnte beispielsweise eine Sicherungssoftware sein, die der Einfachheit halber als Domain Admin ausgeführt wird. Somit hätte die Backup Software mit Domain Admin Rechten die Möglichkeit die Domain Controller und damit das Active Directory zu verwalten (Higher Tier Control). Wie im Bild dargestellt, muss aber das “Higher Tier Control” unterbunden werden.
Wenn man es sich einfach machen würde, würde man die Backup Software nun einfach als Tier 0 System klassifizieren. Jedoch sollte das Tier 0 möglichst klein gehalten werden, der bessere Weg ist also, die Backup Software entsprechend zu konfigurieren, damit diese eben nicht mehr mit Domain Admin Rechten ausgeführt wird.
Zusätzlich zur Kontrollebene, sollen die Admin Tiers sicherstellen, dass sich ein Konto welches Tier 0 Systeme verwaltet nicht auf Tier 1 und Tier 2 Systemen anmelden kann. Ein Benutzerkonto welches Mitglied der Gruppe der Domain Administratoren ist (Tier0), darf sich also nicht auf einem Web Server in Tier 1 oder einem Client in Tier 2 anmelden.
Diese Grafik macht es wieder etwas deutlicher:
Quelle: Active Directory-Verwaltungsebenenmodell
Hinweis: Wenn es in sehr kleinen Umgebungen nur einen Server gibt (Domain Controller, Exchange, etc. auf einem Server), dann gibt es auch nur Tier 0 und Tier 2. Für diese beiden Tiers werden dann unterschiedliche Admin Konten verwendet.
Kurz zusammengefasst:
- Domain Administratoren melden sich an Domain Controllern (Tier 0) an, aber nicht an Fileserver (Tier 1) oder Workstations (Tier 2)
- Server Administratoren melden sich an FileServern an (Tier 1), aber nicht an Clients (Tier 2). Wenn es die Rolle erfordert darf sich der Server Administrator aber an einem Tier 0 System anmelden (beispielsweise an einem Exchange Server um ein Postfach anzulegen oder zu verwalten)
- Client Administratoren melden sich an Clients an (Tier 2), dürfen sich aber auch an einem Server anmelden welcher die Clients verwaltet (Tier 1)
- Tier 1 und Tier 2 Systeme dürfen nicht die Kontrolle über Tier 0 Systeme erhalten (Backupsoftware mit einem Dienst mit Domain Administrator Rechten)
- Tier 2 Systeme dürfen nicht die Kontrolle über die höheren Tiers haben (Backupsoftware oder eigenes Benutzerkonto mit Domain Admin Rechten)
Und was sollen die Admin Tiers nun bewirken?
Durch die strickte Trennung der Kontroll- und Zugriffsmöglichkeiten soll verhindert werden, dass beispielsweise ein infizierter Client die Kontrolle über die kritischen Systeme der höheren Tiers erhält. Als Beispiel kann wieder die Backupsoftware dienen: Wenn die Backupsoftware einen Agent mitbringt, welcher auf allen Servern und Clients mit Domain Admin Rechten läuft, könnte ein Angreifer an das Passwort dieses Kontos gelangen indem nur ein einzelner Client infiziert wird. Sobald das Passwort bekannt ist, hätte der Angreifer die Kontrolle über alle Systeme innerhalb des Active Directory. Wenn die Grenzen der Admins Tiers eingehalten werden und die Backup Software auf den Clients nur mir Tier 2 Admin Rechten läuft, kann ein Angreifer auch “nur” das Tier 2 Admin Passwort ergattern. Der Angreifer hätte somit die Kontrolle über die Clients, aber nicht über die Tier 1 und Tier 2 Systeme (Stichwort: Same Tier Control und Lateral Movement). Wenn dem Angreifer nun ein Konto mit Tier 2 Admin Rechten in die Hände fällt, dann kann er sich zwar innerhalb des Tier 2 bewegen, kommt aber nur schwer an Tier 1 und Tier 0 Konten, denn diese dürfen sich nicht an Tier 2 Systemen anmelden (Lower Tier Logon).
Lokales Admin Konto: Administrator
Oft wird für das lokale Administrator Konto auf den Clients immer das gleiche Passwort verwendet. Gleiches gilt meist auch für die Server, auch hier wird für das lokale Administrator Passwort gerne immer das gleiche Passwort verwendet. Ganz schlecht ist es natürlich wenn, das Passwort für den lokalen Administrator auf Clients und Servern identisch ist. Natürlich weiß jeder, dass identische Passwörter immer ein Sicherheitsrisiko darstellen, trotzdem will niemand manuell für jeden Rechner und jeden Server ein sicheres und individuelles Passwort vergeben.
Für Angreifer ist das Konto “Administrator” aber ein beliebtes Ziel, denn in der Standardkonfiguration gibt es dieses Konto auf jedem Windows Client und Windows Server. Wenn dann auch noch das Passwort immer gleich ist, ist es umso besser für den Angreifer.
Um auch hier die Sicherheit zu erhöhen, muss also das Passwort für “Administrator” auf jedem Rechner (Server und Client) unterschiedlich sein und auch am besten regelmäßig geändert werden.
Es ging allerdings durch die Medien, dass Microsoft das Ändern von Passwörtern nur noch empfiehlt, wenn bekannt geworden ist, dass das Passwort bekannt geworden ist:
Hier sind die allerdings die Passwörter der Anwender gemeint, ein Anwender soll also nicht mehr alle XX Tage aufgefordert werden sein Passwort zu ändern. Für Administrative Konten gilt diese Empfehlung nicht, welches der dieser Artikel auch erläutert:
Also bleibt das Problem bestehen: Individuelle Passwörter für lokale administrative Konten.
Hier kommt nun LAPS ins Spiel. Mit LAPS (Local Admin Password Solution) generiert sich jeder Client und Server ein sicheres Passwort für lokale Admin Konten selbst und speichert das jeweilige Passwort im Active Directory. Gesteuert wird LAPS über einen Agent auf den Clients (Server und Client) und Gruppenrichtlinien. Mittels der LAPS UI (GUI) oder PowerShell kann ein entsprechend berechtigter Benutzer das lokale Admin Passwort aus dem Active Directory auslesen und verwenden. Mit Gruppenrichtlinien kann gesteuert werden, wann ein Active Directory Mitglied das Passwort wechselt und welche Anforderungen für das lokale Passwort gelten.
Das folgende Bild zur Funktionsweise von LAPS sieht nur auf den ersten Blick kompliziert aus:
Quelle: Local Administrator Password Solution
Der LAPS Agent sorgt dafür, dass ein lokales Administrator Passwort in bestimmten Intervallen geändert wird und speichert das entsprechende Passwort im Active Directory. Wenn das Passwort benötigt wird, kann es aus dem AD ausgelesen und verwendet werden. Mittels LAPS ist es also möglich, individuelle Passwörter für die lokalen Accounts zu verwenden, ohne sich selbst um die Passwörter kümmern zu müssen.
Domain Admin Konto: Administrator (oder auch “Domain Admin”)
Das Domainkonto “Administrator” ist ein besonders lohnenswertes Ziel für Viren und Angreifer, denn dieses Konto hat administrative Rechte auf jedem Windows Client und Server innerhalb des Active Directory. Innerhalb des Active Directory hat das Administrator Konto die meisten Berechtigungen und auch das Recht, sich alle nötigen Berechtigungen selbst zu verschaffen. Solange das Administrator Konto aktiviert ist und im schlimmsten Fall auch noch aktiv zur Administration verwendet wird, hat ein Angreifer oft leichtes Spiel. Der Angreifer kennt bereits den Benutzernamen und kann auch die SID des Kontos auf einfache Weise rausfinden, somit fehlt nur noch das Passwort oder ein Hash / Ticket…
Um es auch hier Angreifern zumindest schwieriger zu machen, sollte das Administrator Konto deaktiviert werden. Zur Administration werden dann nur die Konten der jeweiligen Admin Tiers benutzt. Es ist daher nicht nötig eine Kopie des Domain Admins Kontos zu erzeugen.
Die Frage ist hier eher, wie oft benötigt man ein Konto welches “Domain Administrator”-Privilegien hat!? In der Regel werden solche weitreichende Berechtigungen nur sehr selten benötigt, die Aufgaben für das Tagesgeschäft lassen sich an Konten mit weniger Privilegien delegieren.
Admin Hosts
Ein Admin Hosts ist eine dedizierte Workstation, die für das Administrieren der Server verwendet wird. Der Admin Host wird also nicht für das “normale Arbeiten” verwendet und sollte auch keinen Zugriff auf das Internet haben. Auf den Admin Host können dann alle relevanten Tools zur Administration und Verwaltung von Active Directory und weiteren Diensten installiert werden (RSAT Tools, Exchange Management Tools, SQL Management Studio, etc).
Damit man zur Administration nicht ständig zwischen zwei Rechnern hin- und her schalten muss, kann vom eigenen Rechner eine RDP Verbindung zum Admin Host aufgebaut werden. Die folgenden Maßnahmen helfen den Admin Host selbst zu schützen:
- Die Windows Firewall wird so konfiguriert, dass sie nur von bestimmten PCs RDP Verbindungen zulässt
- Inaktive Sessions werden nach einer bestimmten Zeit abgemeldet (beispielsweise 30 Minuten)
- Kerberos Tickets werden bei Abmeldung des Benutzers gelöscht
Kleine Faustregel: Der Admin Host ist nicht aus dem Internet zu erreichbar, weder per RDP noch per Teamviewer oder ähnlichen Tools. Wer remote Administrative Aufgaben durchführen muss, kann dazu eine VPN Verbindung aufbauen und sich dann per RDP zum Admin Host verbinden.
Die Windows Firewall der Server kann zusätzlich so konfiguriert werden, dass nur RDP Verbindungen vom Admin Host zugelassen werden.
Hinweis: Ein Admin Host kann prinzipiell auch als virtuelle Maschine betrieben werden. Denkbar wäre es beispielsweise auf der eigenen Workstation Hyper-V oder VMware Workstation zu nutzen. Dabei ist allerdings zu beachten: Die VM wird in diesem Fall für das normale Tagesgeschäft benutzt, die physikalische Installation gilt dann als Admin Host. In der Regel stellt es eine größere Hürde dar, aus einer VM auszubrechen und somit Zugriff auf den Admin Host zu bekommen. Umgekehrt ist der Weg für den Angreifer einfacher, besteht erst einmal Zugriff auf den Hypervisor, ist es ein leichtes Zugriff auf die VM zu bekommen.
Windows Admin Center
Das Windows Admin Center ist eine kostenfreie Software zur browserbasierten Verwaltung und Administration von Windows Servern. Windows Server lassen sich somit bequem von der eigenen Workstation aus administrieren, ohne dass man Gefahr läuft Kerberos Tickets für privilegierte Konten auf der eigenen Workstation zu hinterlassen. Somit ist nicht unbedingt ein dedizierter Admin Host für das Erledigen von Standardaufgaben erforderlich. Windows Admin Center kann auch RDP Verbindungen direkt aus dem Browser heraus herstellen.
Das Windows Admin Center sollte natürlich nicht direkt aus dem Internet erreichbar sein. Wer administrative Tätigkeiten aus dem Home Office oder remote durchführen möchte, sollte dazu eine entsprechend gesicherte VPN Verbindung aufbauen und sich dann zum Windows Admin Center verbinden.
Auch hier gibt es eine einfache Faustregel: Administrative Schnittstellen (z.B. Windows Admin Center, HPE iLO, Dell iDRAC, vSphere Webclient, etc) dürfen nicht direkt aus dem Internet erreichbar sein.
Updates, Updates, Updates
Durch fehlende Updates macht man es Angreifern mitunter besonders einfach. Gerade automatisierte Angriffe zielen auf veraltete Systeme mit bekannten Sicherheitslücken ab. Was soll man also groß zu diesem Thema sagen?! Updates müssen möglichst zeitnah eingespielt werden und zwar nicht nur für das Windows Betriebssystem, sondern auch für alle anderen Programme die im Unternehmen verwendet werden. Leider verursacht das Thema Updates aber meist den größten Aufwand, denn oft ist gar nicht bekannt, welche Software in welcher Version, wo zum Einsatz kommt.
Es gibt aber wieder eine einfache Faustregel: Software mit einem hohem Verbreitungsgrad, hat höchste Priorität bei den Updates. Die Angriffsfläche lässt schon deutlich mindern, wenn zumindest die Betriebssysteme, Office Programme und Browser auf aktuellen Updatestand sind. Gerade automatisierte Angriffe basieren auf Sicherheitslücken in Standardsoftware die weit verbreitet sind. Wenn also diese Standardsoftware (beispielsweise Windows, Chrome, Firefox, Office, Adobe Reader, Flash (!) etc.) auf aktuellen Patchlevel sind, laufen viele automatisierte Angriffe schon ins Leere.
Mittels PowerShell lässt sich beispielsweise ermitteln, welche Software besonders häufig im Unternehmen eingesetzt wird, neben dem Windows Betriebssystem könnten dies beispielsweise die Browser Chrome oder Firefox sein. Die am meisten verwendete Software, sollte daher auch zügig mit Updates versorgt werden. Bei der Installation der Windows Updates, kann WSUS helfen. Mit etwas Aufwand und Planung, lässt sich auch weitere Software wie beispielsweise Chrome oder Firefox automatisiert mit Updates versorgen.
Zusammenfassung
Die hier beschriebenen Maßnahmen ersetzen keine anderen Lösungen hinsichtlich der Sicherheit, wenn beispielsweise jeder Benutzer im Unternehmen mit Administrator Rechten unterwegs ist, muss man sich in der Regel keine Gedanken um Admin Tiers machen, hier hat man zunächst andere grundlegende Aufgaben zu erfüllen. Die beschriebenen Maßnahmen dienen dazu es Angreifern schwerer zu machen, unmöglich wird ein Angriff dadurch natürlich nicht.
Im nächsten Artikel geht es um die Umsetzung der beschriebenen Möglichkeiten. In weiteren Artikel kommen, dann auch noch weitere zusätzliche Maßnahmen zur Sprache.
Hi,
den BUILT-IN\Administrator account bitte nicht deaktivieren, da er eine Schlüsselrolle im Forest-Restore spielt. Ferner muss man dazu übergehen, diesen vollumfänglich zu überwachen (monitoren). Auch wenn dies dann schon zu spät sein kann (je nach Attacke und Reaktionszeit).
ad hitman
Hi Franky,
vielen Dank für den Artikel. Mich würden noch 2 Punkte interessieren.
1. Das Problem von Jochen Wagner bei der Anlage des Homelaufwerks
2. Du schreibst folgendes:
„Mittels PowerShell lässt sich beispielsweise ermitteln, welche Software besonders häufig im Unternehmen eingesetzt wird“
–> Meinst Du damit, dass die Anzahl der Installationen mittels PS ermittelt werden kann, oder die wirklich Nutzungsdauer/Aufrufhäufigkeit? Letzteres ist mir nicht bekannt und würde ja ein grundsätzliches „Logging“ bedeuten. Falls Du die Nutzungsdauer/Aufrufhäufigkeit meinst, würde mich das natürlich interessieren.
Vielen Dank!
Mike
Du solltest eigentlich User mit einem anderen „Admin“ anlegen :-)
Das Tier ist nur dazu da, lokale Anmeldungen von einem T1 User auf einem T0 System zu blocken.
Arbeiten kannst Du aber mit dem AD ansich auch mit einem T2 User. Das sind zwei paar Stiefel.
Viele Grüße Rolf
Hallo Jochen,
Das würde mich auch Interessieren. Hast Du da schon eine Lösung für Dich gefunden?
Grüße Renegade
Hallo Frank,
ich hab die Tiers wie von dir beschrieben umgesetzt. Allerdings stoße ich jetzt auf eine Hürde.
Ich habe die DCs in Tier0 und FS in Tier1.
Jetzt lege ich als DomainAdmin auf dem DC in Tier0 per Script einen User an inkl. HomeDirectory auf dem FS.
‚
Problem: Da FS in Tier1 ist, darf sich der DomainAdmin nicht anmelden und demzufolge legt er das HomeDirectory des Users nicht an.
Wie gehe ich damit um? Ich könnte den FS in Tier0 ziehen – was ja nicht im Sinne des Erfinders ist.
Ggf. hast du nen Tipp
Beste Grüße
Jochen Wagner
Hallo Jochen,
Das würde mich auch Interessieren. Hast Du da schon eine Lösung für Dich gefunden?
Grüße Renegade
sorry doppelt :-(
Hallo Jochen,
du musst das Home-Directory nicht vorab anlegen, wenn da keine Daten vorab hinterlegt werden müssen. Der Benutzerprofildienst legt sowohl das Benutzerprofil als auch das Home-Laufwerk bei der Erstanmeldung an, wenn es nocht nicht existiert und der Benutzer Schreibberechtigungen hat. Der erste Teil der Anleitung im Lik unten beschreibt auch die notwendigen Freigabe- und NTFS-Berechtigungen.
Oder man richtet die Freigabe der Home-Laufwerke wie auf https://www.der-windows-papst.de/2017/09/09/userhome-vollautomatisch-erstellen-und-mappen/ beschrieben ein und lässt den Ordner durch Gruppenrichtlinien-Einstellungen veranlasst mit Benutzerrechten anlegen.
VG
Buster
Eine weitere Frage: Wenn in einem kleinen Unternehmen nur zwei Admins existieren, die das gesamte Netzwerk inkl. Clients administrieren sollen und auch User anlegen sollen, benötigen beide Tier 0 Rechte. Soll jeder dieser Admins nun 3 Konten erhalten? Und wenn so eiAdmin auch im Tagesgeschäft an einem Arbeits-PC arbeitet, auch noch ein User Konto ohne Rechte? Das wären dann 4 Konten. Wäre dann die Sicherheit gefährdet, wenn der Admin für alle 4 Konten das Gleiche Kennwort eingibt? Manuelle Angreifer könnten leicht vermuten, wie die anderen Konten heißen und versuchen das Gleiche Kennwort auch dort. Bekommen das Viren und Trojaner aber auch vermutet?
Hallo Mike,
für das Anlegen von Benutzern sind keine Tier 0 Rechte nötig. Entsprechende Rechte lassen sich delegieren, beispielsweise an Tier 1 Konten. Tier 0 Konten werden in der Regel nur benötigt, wenn beispielsweise neue Domänen oder Domain Controller installiert werden. Durch Passwortrichtlinien läksst sich verhindern, dass für Admin und Benutzer Konten die gleichen Passwörter verwendet werden. Beispielsweise könnte eine Richtlinie für Benutzer ein 8-Stelliges Passwort vorsehen, für privilegierte Konten aber ein 12-Stelliges Passwort.
Gruß,
Frank
Ich nochmals. DNS wurde bis anhin nicht erwähnt. Schon klar das der ja auf einem DC läuft aber die Administration muss auch über TIER0 erfolgen. Geht auch immer gerne vergessen oder ist schwer umzusetzen.
Der Artikel ist super und hilft einem Security Anfänger schon sehr.
Zu den Backupsystemen hätte ich auch nachgefragt ob diese in Tier 1 gehören wenn sie doch Lesezugriff auf auf die DCs haben (im Falle einer Wiederherstellung eventuell auch Schreibzugriff).
Womit ich mich etwas schwer tue ist die Sicht für kleine Unternehmen. Sehr kleine Unternehmen haben oft keine große Infrastruktur und dem Kunden erklären dass man mindestens 2 Lizenzen allein fürs Backup benötigt (DCs + Rest) und dazu mehrere Stunden zusätzlichem administrativen Aufwand zur Konfiguration und „Schulung“ nur für Security ist schon schwer vermittelbar.
Dazu kommt wenn man für automatisierte Aufgaben „einfach“ den Domain Admin nimmt, dann läufts halt erstmal. Die extra Kosten und Zeit die benötigt werden würde einen angepassten Account zu erstellen, der genau das darf was nötig ist wird eher selten zur Verfügung gestellt.
Hallo,
irgendwie komme ich nicht dahinter, wie man RDP ohne privilegiertem Account umsetzt.
Wie meldet man sich denn dann z.B. auf einem DC administrativ an?
Ist hier eventuell der RestrictedAdmin Modus gemeint?
Danke und viele Grüße
Christopher
Hallo Christoph,
Ein bisschen spät meine Antwort.
#1 Du hast einen speziellen, normalen User, der die Rechte hat, sich via RDP an und startest dort die Tools mittels „runas“
(Schlechtere Variante)
#2 Du hast einen Admin Client (in der Microsoft Sprache PAW (Privileged Access Workstations) genannt, mit welchem du dich mit einen speziellen, normalen User anmeldest und dann öffnest du per RDP den DC mittels Admin Rechten.
Gruss Stefan H
Ich versteh das auch alles noch nicht. Wenn man davon ausgeht, das Tier 2 angegriffen wurde und man selbst davor sitzt, dann ist doch alles was per Tastatur passiert (Keylogger etc.) doch auch schlecht. Wenn man also per PAW arbeitet, gibt man dort doch auch irgendwann das Konto an welches erhöhte Rechte hat. Oder übersehe ich da etwas?
Hallo Sascha,
Keylogger wären in der Tat ein Problem, wenn auf den Admin Host per RDP zugegriffen wird. Dies könnte man verhindern, wenn der Admin Host ein anderer PC ist. Es geht im Wesentlichen ja darum, es dem Angreifer möglichst schwer zu machen und ihm nicht die Kronjuwelen auf dem Silbertablett zu servieren. Wenn von PCs auf Admin Hosts zugegriffen wird, oder privilegierte Konten eingesetzt werden, dann müssen diese PCs besonders geschützt sein. Ein Angriff auf das Tier 2 ist recht wahrscheinlich, denn hier passiert die meiste Arbeit, Anhänge werden geöffnet und es wird im Netz gesurft. Im Normalfall kommen aber keine privilegierten Konten zum Einsatz. Ein Angreifer müsste also schon den PC des Admins unter seine Kontrolle bringen, ich hoffe das dies in der Regel schwieriger ist, einen Admin zu überzeugen eine Mail mit Virus zu öffnen als einen „normalen“ Benutzer.
Gruß,
Frank
Hallo,
wie verhält es sich denn in dem Tier-Konzept, wenn per DC die Clients verwaltet und dort bspw. lokale Nutzer angelegt/verändert oder Dienste angelegt/gestartet/stoppt werden? Meldet sich dabei nicht der auf dem DC angemeldete Nutzer (mit Domänen-Admin-Rechten) in irgendeiner Weise auf dem Client an?
Hallo Markus
So darfst du ein einem Tier Modell nicht arbeiten. Ein Domänen Admin hat nie Rechte auf den Clients.
Um Clients zu mangen hast du einen Tier2 (Client-Schicht) Admin, welcher einen „Admin Server“ hat, auf welchen er alle Settings für die Clients macht.. (z. B. GPO oder Scripte)
Gruss Stefan H.
Hi Franky,
cooler Artikel, einfach und klar erklärt und auf den Punkt gebracht.
Hallo in die Runde,
vielen Dank für die Kommentare, die alle absolut richtig sind. Grundsätzlich würde ich davon abraten das WAC in irgendeiner Art und Weise aus dem Internet direkt erreichbar zu machen, es könnten beispielsweise Sicherheitslücken vorhanden sein, die ein Aushebeln der Authentifizierung erlauben. In diesem Fall (derzeit ist mir dies zwar nicht bekannt) würde auch die 2FA wenig helfen.
Völlig richtig ist auch: Eine RDP Verbindung darf nicht mit privilegierten Konten aufgebaut werden und sollte daher auch nicht möglich sein.
Falls man sich bereits an einem Client mit einem Domain Admin Account angemeldet hat, würde ich auch immer vom schlimmsten Fall ausgehen und annehmen, dass das Konto bereits kompromittiert ist. Dies werde ich auch in den folgenden Artikeln behandeln.
Beste Grüße,
Frank
Wenn man sich schon einmal mit einem Domain Admin Konto an einem Client angemeldet hat, besteht irgendwie die Möglichkeit, die gespeicherten Anmeldedaten zu löschen? Oder muss man dann das Passwort ändern?
Hallo Stefan
Da hilft nur das Passwort des Domain Admins zu ändern.
Oder aus Sicherheits-Sicht, den Clients neu zu installieren.
Gruss Stefan H.
Hallo
Ich kann mich Flo nur anschliessen.
Es darf nie eine RDP Verbindung mittels privilegierten Accounts von einer normalen Workstation gemacht werden.
Wenn dies gemacht würde, dann ist das ganze Tier Modell hinfällig, dann sind die Credentials des privilegierten Accounts auf der Workstation „gecached“.
Auch müssen Backups und Updates noch separat beachtet werden… (Nicht der gleiche Account für Backup von DCs und normalen Servern… als Beispiel)
Gruss aus CH.
Stefan
Hallo Stefan,
genau genommen müsste für jeden Service im Tier 0 separate Dienste mit integriert werden. Ein T1 System darf niemals auf ein T0 System zugreifen.
Persönlich sehe ich den Exchange Server sogar eher im Tier 1.
Grüße
Rolf
Hallo Rolf
So weit in Detail wollte ich nicht gehen… Aber ja, es ist sehr aufwändig da ein sauberes Tier Modell hinzubekommen.
Microsoft Kriegt da bei seinen Produkten nicht mal selber hin.
Exchange, im „split permissions model“, ist ein Tier 1 System. Sonst verweise ich gerne auf die obenstehende Zeile.
Tier 0 sind nur Domänen Controller und Server die du brauchst um diese zu managen. (Wir brauchen hier WSUS in Tier 0 für die DC, alle anderen Systeme (Server, Clients) werden per SCCM gepachted.. (Ja hier ist das Tiermodel noch nicht fertig))
Hi Franky,
Danke für den spannenden Artikel. Ich denke da gibt es bei einigen Aufholbedarf.
Ein kleiner Hinweis der meines Erachtens sehr wichtig ist. RDP Sessions sind (byDesign) sehr anfällig auf „pth“. Daher muss jeder Client gehärtet werden auf dem eine RDP Session auf den Jumphost initiert wird. Ebenfalls sollten keine privilegierten Accounts für das verbinden über RDP genutzt werden, da diese bspw. mit Powershell innert Sekunden gekapert sind.
Gruss aus der Schweiz
Flo
Hallo Franky,
toller Artikel zu absoluten Basics, die leider sehr häufig nicht beachtet werden.
Grundsätzlich gebe ich dir auch recht, dass Managementschnittstellen nichts im „öffentlichen“ Internet zu suchen haben. Jedoch hat grad das WAC ein Gateway, welches sich mit Azure AD und 2Faktor kombinieren lässt. Je nach Konfig ist das komfortabler und sicherer als der Weg über eine VPN. Oder siehst du das anders?
LG Filip
Super Artikel! Freue mich sehr auf die Fortsetzung(en)