In Teil 1 dieser Artikelserie wurden bereits Maßnahmen vorgestellt um die Sicherheit des Active Directory zu verbessern. Die nächsten Artikel widmen sich nun der Umsetzung der genannten Maßnahmen innerhalb eines bestehenden Active Directory anhand einer Beispielumgebung. In diesem Artikel geht es zunächst um den Admin Host.
Einleitung
Als Beispiel kann hier das fiktive Unternehmen “FrankysWebLab” dienen. Nehmen wir mal an, diese fiktive Firma hat einen Administrator, welcher sich um um den Betrieb der eigenen IT-Infrastruktur kümmert. In der fiktiven Firma gibt es also ein paar Server und Clients. Typischerweise befinden sich also in der Firma “FrankysWebLab” die folgenden IT-Systeme:
- Domain Controller
- FileServer
- Datenbank Server
- Exchange Server
- Windows Clients (PC und Notebooks)
Vielleicht auch noch ein paar weitere Server/Services und Clients.
Ursprünglich hatte ich vor mit dem Admin Tier Modell zu beginnen, ich denke aber, dass es mehr Sinn macht zunächst mit dem Admin Host zu starten. Das Admin Tier Modell ist dann im nächsten Artikel an der Reihe.
Installation Admin Host
Die Installation eines Admin Hosts sollte von einem “sauberen Medium” erfolgen, es sollte also kein fertiges Image oder ähnliches verwendet werden. Die Installation von einem sauberen Medium ist wichtig, da beispielsweise in Templates für virtuelle Maschinen bereits Einstellungen angewendet und ggf. auch weitere Software installiert wurden. Wenn man also den Admin Hosts von Grund auf neu installiert, weiß man sehr genau welche Software installiert wird und welche Einstellungen angewendet werden.
Nach der Installation des Betriebssystems (ich verwende in diesem Fall Windows Server 2019, Windows 10 ist natürlich auch OK) wird zunächst einmal das Remotedesktopprotokoll aktiviert und die Remoteverwaltung deaktiviert. Der Admin Host wird nicht dem Active Directory hinzugefügt:
Danach können zwei neue Benutzerkonten erstellt werden, ein administrativer Benutzer (AHAdmin) und ein Benutzer der für die Verbindung zum Admin Host via RDP verwendet wird (AHUser). Für beide Benutzer müssen sichere Passwörter verwendet werden:
Der Benutzer AHAdmin erhält lokale Administrator Berechtigungen:
Der Benutzer AHUser bleibt normaler Benutzer, erhält aber RDP Rechte:
Jetzt kann sich bereits mit dem Konto “AHAdmin” angemeldet werden und das Konto “Administrator” deaktiviert werden:
Mit dem Benutzer AHAdmin kann nun die “Microsoft Security Baseline” angewendet werden, die einige grundlegende Einstellung für die Sicherheit des Betriebssystems setzt. Um die Security Baseline anzuwenden, wird das Security Compliance Toolkit (je nach Betriebssystem) und das Tool LGPO benötigt. Beides kann hier runtergeladen werden:
Hinweis: Die Downloads werden natürlich nicht auf dem Admin Host durchgeführt.
Das ZIP Archiv mit der Security Baseline wird auf den Admin Host übertragen und entpackt. In dem Ordner in dem das Archiv entpackt wurde, findet sich dann der Ordner “Local_Script”:
In diesem Ordner findet sich wiederum der Ordner “Tools”. Hier wird nun das Archiv von LGPO entpackt:
In der PowerShell kann nun die Baseline angewendet werden. In meinem Fall mit dem Parameter “WS2019NonDomainJoined”, wenn Windows 10 als Betriebssystem verwendet wird, kann der Parameter “Win10NonDomainJoined” verwendet werden:
Jetzt kann die Windows Firewall angepasst werden. Dazu wird zunächst einmal die lokale Sicherheitsrichtlinie so angepasst, dass auch ausgehende Verbindungen blockiert werden, so lässt sich recht gut steuern welcher Netzwerkverkehr zugelassen wird:
Jetzt können die Firewall Regeln konfiguriert werden. Ich habe hier zunächst alle eingehenden und ausgehenden Regeln entfernt. Somit sind also erst einmal keine Verbindungen mit dem Admin Host möglich, das Löschen der Regeln muss also über die Konsole oder VM Konsole erfolgen.
Für die eingehenden Verbindungen sind eigentlich nur zwei Regeln nötig, Ping und Remote Desktop. Diese beiden Regeln lassen sich zusätzlich einschränken, damit Verbindungen zum Admin Host nur von bestimmten Subnetzen oder IPs möglich ist:
Für ausgehenden Verbindungen werden ggf. mehr Regeln benötigt wie hier dargestellt. Mindestens DNS, RDP und Ping sollte man aber zulassen. Falls weitere Tools auf dem Admin Host installiert werden, müssen die ausgehenden Regeln entsprechend erweitert werden. Auch diese Regeln lassen sich wieder auf bestimmte Ziel Netze oder IPs anpassen:
Wenn Management Websites aufgerufen werden müssen, kann eine weitere Regeln für HTTPs Verkehr erzeugt werden. Diese sollte aber auf jeden Fall auf das interne Netzwerk beschränkt werden:
Mit der Windows Firewall wird nun also gesteuert welcher Rechner (oder welches Netz) sich mit dem Admin Host verbinden kann und wohin sich wiederum der Admin Host verbinden darf.
Hinweis: Regeln wie Any-Any-Any sind hier strikt verboten. Genauso wie das Surfen im Internet.Hier wird nur das zugelassen, was zu Administration benötigt wird. Keine AD-Mitgliedschaft, kein Virenscanner der zentral verwaltet wird, keine zentral verwaltete Backup Software, etc. Regeln für Windows Updates können vorbereitet und nur dann aktiviert werden, wenn das System auch aktualisiert wird.
Nachdem die Windows Firewall konfiguriert wurde, können unnötige Windows Dienste abgeschaltet werden. Hier finden sich in der Regel zahlreiche Dienste, die nicht auf einem Admin Host genutzt werden. Es bietet sich daher an, alle Windows Dienste einmal durchzugehen und nicht benötige Dienste zu stoppen und zu deaktivieren:
Zusätzlich zu den genannten Maßnahmen, sind noch weitere Einstellungen sinnvoll, beispielsweise das Trennen und Abmelden der RDP Verbindungen nach XX Minuten Leerlauf. Auch das Speichern von Kennwörtern sollte verboten werden. In wie weit diese Einstellungen sinnvoll sind, sollte jeder selbst entscheiden.
Wenn der Admin Host fertig konfiguriert wurde, ist die Benutzung simpel. Mit dem Benutzer AHUser wird eine RDP Verbindung von der eigenen Workstation zum Admin Host aufgebaut. Innerhalb der RDP Session zum Admin Host wird nun eine privilegierte RDP Verbindung zum Ziel System aufgebaut. Der Admin Host dient also als gesichertes Sprungsystem zum eigentlichen Ziel:
Die normale Workstation darf nicht mehr für administrative Zwecke verwendet werden. Es macht ebenfalls Sinn, sich für die unterschiedlichen Admin Tiers verschiedene Admin Hosts zu installieren.