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.
Was this helpful?
0 / 0