Einfache Maßnahmen für mehr Sicherheit im AD (Teil 2): Admin Host

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:

Active Directory: Einfache Maßnahmen für mehr Sicherheit (Teil 2)

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:

Admin Host Lokale Benutzer

Der Benutzer AHAdmin erhält lokale Administrator Berechtigungen:

Admin Host Lokale Benutzer

Der Benutzer AHUser bleibt normaler Benutzer, erhält aber RDP Rechte:

Admin Host Lokale Benutzer

Jetzt kann sich bereits mit dem Konto “AHAdmin” angemeldet werden und das Konto “Administrator” deaktiviert werden:

Admin Host Administrator Konto

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:

Microsoft Security Compliance Toolkit

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”:

Microsoft Security Compliance Toolkit

In diesem Ordner findet sich wiederum der Ordner “Tools”. Hier wird nun das Archiv von LGPO entpackt:

Microsoft Security Compliance Toolkit

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:

Active Directory: Einfache Maßnahmen für mehr Sicherheit (Teil 2)

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:

Windows Firewall Sicherheit

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:

Windows Firewall

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:

Windows Firewall

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:

Windows Firewall

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:

Windows Dienste

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:

Fertiger Admin Host

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.

8 Kommentare zu “Einfache Maßnahmen für mehr Sicherheit im AD (Teil 2): Admin Host”

  1. Ein sehr spannendes Thema, nicht nur in Bezug zum gerade aktuellen Emotet Fall bei Heise. Freue mich schon auf den nächsten Teil.

    Zum Artikel: Nutzt man den Admin-Host also nicht direkt für die Administration der Server via RSAT oder Admin- Weboberflächen wie Exchange Admin Center, sondern springt auf ein weiteres System, das dann hierfür benutzt wird?

  2. Ich war bisher immer stiller Leser hier. Das Thema ist aber besonders spannend und ich freue mich schon auf die weiteren Artikel. Top Arbeit!

  3. Hi

    sehr spannendes Thema und sehr gut erklärt!
    Jedoch ergibt sich mir noch nicht ganz, wie ich „Daten“ z.b. die Installationsdateien für vSphere bzw. die Security Baseline auf den Admin Host bekomme. Tatsächlich via USB oder über SMB Freigabe?

    Gruß
    Heiko

  4. Hallo,
    wenn ich mir das so alles durchlese fällt mir auf, dass ich dann auf den AdminHosts noch einmal alle T0-, T1- bzw. T2-Admins anlegen muss. Sonst können sie ja nicht Remote darauf bzw. darüber arbeiten.
    Oder habe ich da etwas falsch verstanden??

    1. Hallo Cordula,
      auf dem Admin Host braucht du keine Tier Konten anlegen. Der Admin Host ist ja nicht Mitglied des ADs. Die Verbindung zum AdminHost via RDP wird mit dem Benutzer AHUser hergestellt. Es macht aber Sinn, mehrere AdminHosts zu installieren, wie viele hängt von der Umgebung ab. Beispielsweise könnte man für jedes Tier einen AdminHost installieren, oder auch für jeden Admin, oder für Jedes Tier und jeden Admin.
      Gruß,
      Frank

  5. Hallo Frank,

    mit interesse verfolge ich die Artikel der Reihe.
    Könntest Du eventuell kurz etwas zu den Firewall-Regeln hinzufügen, die Adressbereiche kann ich nirgends finden im Zusammenhang mit der zu Verwaltenden Umgebung.
    Du verwendet ja 192.168.200.xxx in dem Beispiel

    Gruss,
    Michael

  6. Moin,

    schön das dieses Thema und die Umsetzung in den Artikelserie gezeigt wird.
    Ich möchte hier anmerken das ein Sprungsystem „Jump host“ des sicheren Quellen-prinzips „clean source“ widerspricht. Diese Admin Workstation ist auch keine PAW. In diesem hier gezeigten Aufbau wird immer noch das T0 Admin Passwort auf einer T3 Workstation Tastatur (physisch) eingegeben. (Was leicht abgefangen werden kann)
    Anderes herum wäre es „richtig/besser“ (laut dem Tier und PAW Konzept): T0 (oder T1…) Admin Workstation: an dieser wird sich mit dem T0 Admin Benutzer angemeldet und von hier aus werden T0 Systeme verwaltet. In z.B. einer virtuellen Maschine auf der T0 Workstation läuft eine T3 Workstation an der man sich mit seinem T3 Benutzer anmeldet um z.B. Mails abzurufen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.