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.
Hi Franky,
warum sollte eigentlich der Admin-Host kein Domänen-Mitglied sein?
Das ist eine gute Frage. Laut PAW Konzept von Microsoft muss er sogar in die Domäne, da hier GPOs verteilt werden und Windows Updates vom WSUS kommen. Woher bekommt also der Admin Host seine Windows Updates, wenn er doch nie ein Internet sieht!? Und was ein ungepatchtes System bedeutet, ist jedem klar.
Es gibt z.B. eine GPO die es verbietet auf dem Admin Host / PAW die lokale Firewall zu bearbeiten. Also selbst mit dem „AHAdmin“ wäre das nicht möglich. Das wäre ohne Domäne gar nicht möglich.
Ein PAW nach Microsoft ist jedoch eine echt umfangreiche Geschichte und da ist dieser hier gezeigte Admin Host immer noch tausendmal besser, als die Tiering Kennwörter auf der Workstation einzugeben, die sowieso den ganzen Tag vom Admin für Mails, Surfing etc hergenommen wird ;-)
Hallo Frank,
Vielen Dank für die schnelle Antwort. Lokales gpedit gefolgt von gpupdate und Neustart hatte ich als erstes versucht. Leider ohne Erfolg.
LG Roland
Hallo Frank,
danke für die vielen interessanten Themen.
Ich habe versucht der Anteilung zu folgen. So weit ist alles gut und umsetzbar.
Probleme bereitet die Security Compliance auf Windows 10 1909. Wird die angewendet lässt sich der ausgehende Datenverkehr in der Firewall nicht mehr blockieren. Der Schalter steht auf Zulassen und lässt sich weder mit der GUI, netsh, regdit oder powershell ändern.
Hast Du eine Empfehlung?
LG Roland
Hallo Roland,
du kannst Gruppenrichtlinien verwenden um die Einstellungen zu ändern. Alternativ kannst du auch die lokalen Einstellungen via gpedit.msc“ überschreiben.
Gruß,
Frank
Wenn es nur darum geht auf keinem der Tier 1 oder 2 Systemen ein T0-Admin-Kennwort einzugeben könnte man da nicht auch ein günstiges Raspi-System nehmen, sich dort per RDP oder ähnlichem zu verbinden und von dort dann per RDP-Client auf den Server anzumelden? Der Vorteil wäre neben dem sehr günstigen Preis, geringem Stromverbrauch auch noch dass man ein minimales Linux-System verwenden könnte, sicherheitstechnisch vielleicht besser als Windows 10.
Hallo Frank,
sehr interessanter Artikel, den ich auch umsetzen möchte.
Doch dazu habe ich noch eine Frage: Habe das Security Compliance Toolkit fuer Win 2016 Server downgeloadet,
doch leider finde ich in dem Verzeichnis „Local_Scripts“ nicht das BaselineLocalInstall.ps1 Script.
Bei mir sehe ich nur drei Shell-Scripts:
– Client_Install.cmd
– Domain_Controller_Install.cmd
– Member_Server_Install.cmd
Wo finde ich das Powershellscript?
Gruss, Erwin
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.
Warum wird auf diese Anmerkung nicht eingegangen? Soll man es wie hier beschrieben lieber nicht machen? Es stellt sich mir noch die Frage wieviele Admin Host ich nun wirklich benötige. Bei z.B. 2 Admins wären das 6 Hosts.
Hi,
ich wäre auch entweder bei der Lösung T0 Workstation mit T3 VM, oder zwei Clients und klassisch mit KVM-Switch am Arbeitsplatz umschaltbar. In Anbetracht der aktuellen Situation mit Corona ist das allerdings mit mehreren physischen Geräten so eine Herausforderung, ein virtueller KVM Switch wäre wieder ein Angriffspunkt.
T3 auf T0 hätte man bei Exploits von dem Hypervisor / Guest VM allerdings auch wieder Probleme.
Ich pers. würde deshalb auf 2 Hardware-Clients setzen und diese virtuell im Netzwerk segmentiert zur Administration nutzen. Ebenfalls T0 Clients dem AD joinen und strenge Regeln in Hinblick auf Sicherheit und schnelles OS patchen etablieren.
Deinen Gedankengang kann ich nur allzu gut nachvollziehen.
Es ist ein leichtes, RDP-Credentials mit Tools wie Mimikatz etc. aufzudecken (https://pentestlab.blog/2021/05/24/dumping-rdp-credentials/)
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
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??
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
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
Hallo Heiko,
du kannst in einer RDP-Sitzung auf dem RDP-Server Laufwerke des RDP-Clientrechners verwenden, wenn du diese im RDP-Client zuvor als „Lokale Ressourchen“ aktiviert hast.
VG
Buster
Ich war bisher immer stiller Leser hier. Das Thema ist aber besonders spannend und ich freue mich schon auf die weiteren Artikel. Top Arbeit!
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?
Hi Stefan,
doch der Admin Host kann genau dafür genutzt werden. Wichtig ist in der Firewall dann nur die Admin Oberflächen freizugeben die auch benötigt werden.
Gruß,
Frank
Hallo Frank, Hallo Stefan!
Ich habe drei Admin-Hosts unter Windows 10 2004 eingerichtet und möchte nun auf dem T0-Host die RSAT-Tools verwenden. Der Start eines RSAT-Tools (z.B. DHCP) ist erwartungsgemäß unter dem lokalen User AHUser nicht sinnvoll, da mir dann die Berechtigungen fehlen, um auf den DHCP-Server zuzugreifen. Wenn ich das Tool als anderer Benutzer starten will und hier die Zugangsdaten meines T0-Admins eingebe, erhalte ich immer die Fehlermeldung „Benutzername oder Kennwort ist falsch“.
Können die RSAT-Tools ausschließlich auf den Servern gestartet werden oder wo liegt mein Denkfehler?