Härtung von Hyper-V im Server 2012 R2, Teil 1
26. März 2014
Viele kleinere und mittlere Unternehmen assoziieren bei der Frage nach der Härtung ihrer Hyper-V-Systeme oftmals nur die entsprechenden Zugriffsbegrenzungen zum Hypervisor-Dienst auf den jeweiligen Servern. Allerdings müssen Systemadministratoren in diesem Bereich sowohl das Augenmerk auf die physikalischen Systeme und die darauf laufenden Virtualisierungsplattformen legen, als auch die virtuellen Maschinen (VMs) selbst im Blick behalten. Somit stehen sie vor der Aufgabe quasi zwei Ebenen mit entsprechenden Gruppenrichtlinien, Zugangsbeschränkungen und Firewalls abzusichern sowie mit Patches und Hotfixes und aktuellen Maleware-Scannern auf dem Laufenden zu halten. In diese Mischung fliest dann auch noch die korrekte Konfiguration des zugrundeliegenden Active Directorys (AD) mit ein. Zudem kommen im Laufe der Zeit auch immer wieder Änderungen seitens Microsoft hinzu.
Beispielsweise wurden einige Veränderungen im Bereich Hyper-V mit dem aktuellen Windows Server 2012 R2 eingeführt. Das NT4ADMIS-Team stellt für diese Zwecke eine Art Leitfaden bereit, um im Hyper-V-Umfeld die Kontrolle aller wichtigen Sicherheitsfunktionen im Griff zu behalten. Mit diesem Beitrag starten wir diese Artikelreihe, die im E-Paper März 2014 fortgesetzt wird.
Wenn es um das Thema Sicherheit geht, konzentrieren sich viele Systemadministratoren auf Bereiche wie etwa Cloud-Speicherlösungen, sichere Passwörter und deren zyklische Erneuerung oder Verbindungen über Virtual Private Networks (VPN) in das Unternehmensnetzwerk.
Doch neben diesen Punkten fallen auch Punkte wie Antivirenschutz, Firewall-Konfiguration und das Einspielen aktueller Patches und Hotfixes ins Gewicht. Besonders hervorzuheben sind die Bereiche, denen Administratoren teilweise zu wenig Bedeutung beimessen: das Absichern der Domäne an sich und den darin enthaltenen Systemen.
Virtualisierung erfordert mehr Aufwand
Besonderen Fokus muss der Systembetreuer auf vorhandene Hyper-V-Hostsysteme und deren Gastsystemen legen. Das Absichern oder Härten dieser Funktionen wird üblicherweise durch die auf die Bedürfnisse eines Unternehmens abgestimmten Gruppenrichtlinien realisiert, die für die einzelnen Servertypen und User entsprechend angepasst werden. Die folgenden Punkte erläutern die einzelnen Sicherheitsaspekte näher und geben den Systembetreuern entsprechende Lösungsansätze vor. Diese sollten auf das jeweilige Szenario im Unternehmen angepasst und zum Einsatz kommen.
Zugriff auf die Funktionen der virtuellen Maschinen eingrenzen
In der Vergangenheit setzten Systemadministratoren auf den Authorization Manager (AzMan) wenn Zugriffe und Funktionen wie etwa Neustarts auf den jeweiligen virtuellen Maschinen ausstanden. In der aktuellen Version Hyper-V Server 2012 R2 wird dieses Tool nicht mehr unterstützt, und als Ersatz ist nun System Center Virtual Machine Manager (SCVMM oder kurz VMM) vorgesehen.
Dieses Werkzeug installiert sich in einen eigenen Windows Management Instrumentation (WMI) Pfad, und stellt eigene Verwaltungsfunktionen bereit. Ein mit AzMan vergleichbares Bordmittel für die Verwaltung der Gastsysteme ist leider nicht mehr vorhanden, daher ist der Systemadministrator darauf angewiesen VMM zusätzlich auf seinen Hyper-V-Systemen ab Version 2012 R2 zu installieren.
Allerdings stellt Microsoft die Möglichkeit bereit, mittels „Simplified Authorization“ entsprechende Zugriffe zu verwalten. Dazu wird auf allen aktuellen Servern mit installierter Hyper-V-Rolle eine zusätzliche Sicherheitsgruppe mit der Bezeichnung „Hyper-V Administratoren“ angelegt.
Mitglieder dieser Gruppe weisen die erforderlichen Berechtigungen auf, um fast alle, für den Hyper-V relevanten Einstellungen zu bearbeiten, haben sonst aber keine erhöhten Rechte auf den Hyper-V-Hostsystemen.
Sollten Speicherplätze wie etwa für Virtual Hard Disks (VHD)s auf nicht standardkonforme Pfade verweisen, können hier allerdings Fehler auftreten. Beispielsweise wenn die jeweiligen Netzwerkfreigaben per iSCSI oder SAN (Storage Area Network) spezielle Berechtigungen benötigen. Diese sollten dann für die Gruppe „Hyper-V Administratoren“ entsprechend hinzugefügt werden.
Insgesamt ist dieses Vorgehen mit der Trennung der Berechtigungen im Hyper-V-Umfeld für die meisten Unternehmen nicht notwendig. Denn auf Hyper-V-Servern im Produktivbetrieb sollen – laut den Vorgaben von Microsoft – keine weiteren Rollen oder Applikationen installiert werden. Daher macht es auf den ersten Blick wenig Sinn, eine zusätzliche Sicherheitsgruppe für Hyper-V zu definieren, da die lokalen Administratorenkonten oder jeweilige Netzwerkadministratorkonten des Active Directorys (AD) bisher auch die jeweiligen Berechtigungen aufwiesen.
Auf den zweiten Blick erweist sich diese Trennung aber sehr wohl als zielführend: Wenn beispielsweise – wie in kleineren Unternehmen üblich – entgegen der Microsoft-Vorgabe doch noch weitere Rollen oder Applikationen auf den jeweiligen Hyper-V-Systemen laufen. Dann erhöht eine Separation der Zugriffsrechte für die einzelnen Rollen in bestimmten Fällen die Sicherheit.
Dagegenhalten könnte man, dass im Umfeld kleinerer Unternehmen meist nur wenige oder einzelne Systembetreuer für die IT verantwortlich sind, und diese sowieso über sämtliche Administratorrechte verfügen. Mittelständische und größere Unternehmen halten sich in ihren Rechenzentren meist an diese Vorgaben, da für Anwendungen oder Remote-Dienste zusätzliche Serversysteme bereitgestellt werden. Das ist aus Kostengründen bei kleineren Unternehmen nicht immer der Fall.
Systembetreuer sollten auch immer im Blick haben, dass sie den jeweiligen Gastsystemnutzern naturgemäß ihre eigenen Berechtigungen anpassen. Schließlich könnten die Mitarbeiter sonst beispielsweise keine Software in ihren VMs installieren. Das wird je nach Vorgabe im Unternehmen unterschiedlich gehandhabt, kann aber auf der Client-Seite durchaus für Sicherheitslücken sorgen. Somit empfiehlt es sich den Mitarbeitern gerade so viele Rechte zur Verfügung zu stellen, wie sie zum Arbeiten benötigen.
Einsatz von Gruppenrichtlinien auf dem Hyper-V-Host
Der Einsatz von Gruppenrichtlinien ist einer der wichtigsten Ansätze im Sicherheitsbereich von Windows-Serversystemen. Zudem wird über die Gruppenrichtlinienobjekte (GPO, Group Policy Objects) die Verwaltung von Benutzern und Gruppen und unterschiedlichen Server- und Client-Systemen vereinfacht. Daher sollten alle Windows-Systeme im Unternehmen in das AD integriert, und über GPOs verwaltet werden.
Dazu zählen naturgemäß auch die jeweiligen Hyper-V-Hosts und deren Gastsysteme. Die Absicherung und Härtung der Hyper-V-Server kann so von den Systembetreuern vernünftig und komfortabel vorgenommen werden. Sollten aus welchen Gründen auch immer einzelne Hyper-V-Host-Systeme nicht in eine Domäne eingebunden sein, so lassen sich die jeweiligen Einstellungen auf einem zusätzlichem Domänensystem einstellen, und gegebenenfalls auf dem betroffenen Hyper-V-Host importieren.
Allerdings lauern im Umfeld der Gruppenrichtlinien auch Gefahren für unerfahrene Administratoren. Beispielsweise können falsche Änderungen im Unterpfad
„Computerkonfiguration\Richtlinien\Windows Einstellungen\Sicherheitseinstellungen\Zuweisen von Benutzerrechten“
gravierende Folgen für den Hyper-V-Server oder die Domäne haben.
Hier ist es beispielsweise möglich sich mit unbedachten Einträgen wie etwa das Setzen von lokalen Administrator-Konten in Richtlinien wie „Lokal anmelden zulassen“ und „Lokal anmelden verweigern“ andere Benutzer- und Administratorkonten aus der Domäne auszusperren.
Schlimmer wird es noch, falls der eingetragene und fortan exklusive Anmelde-Account keine Domänenadministratorrechte besitzt. Denn bei solchen Änderungen in den Sicherheitsrichtlinien ist nur noch dem eingetragenen User ein Anmelden an der Unternehmensdomäne erlaubt, alle anderen Konten werden durch einen Konflikt ausgeschlossen. Das kann im schlimmsten Fall das Aus für die gesamte Domänenstruktur bedeuten.
Beim Konfigurieren der Gruppenrichtlinien im Hyper-V-Umfeld müssen zudem einige Eigenheiten von den Systembetreuern bedacht werden. Viele Administratoren folgen hier den bekannten Windows-Prozeduren um ihre Domänensysteme zu härten.
Eine Besonderheit stellt beispielsweise der spezielle Benutzerkonteneintrag mit der Bezeichnung „Virtuelle Maschinen“ dar. Dieser Account ist nicht in der normalen Domänenliste sichtbar, und kann mit normalen Mitteln auch nicht anderen Sicherheitsgruppen hinzugefügt werden. Findige Systembetreuer finden allerdings Wege diese Verknüpfungen anzulegen, allerdings ergeben sich im Folgenden weitere Probleme beim Erzeugen neuer VMs oder Migrationsaufgaben. Hier kommt dann beispielsweise es zu Fehlermeldungen aufgrund fehlender Berechtigungen. Daher folgen Systemadministratoren bei diesen Fällen besser nicht den Anleitungen für das Setzen von Sicherheitsberechtigungen bei Domänencontroller, sondern nutzen Anleitungen, die extra für Hyper-V-Server 2012 R2 bereitgestellt werden.
Glücklicherweise steht beispielsweise mit dem Microsoft Security Compliance Manager ein nützliches und wirkungsvolles Tool zur Härtung von Hyper-V-Server R2 mittels GPO zur Verfügung.
Hier wird eine lokale SQL-Instanz vorausgesetzt, daher installiert der Administrator dieses Werkzeug am besten auf einem entsprechenden System innerhalb der Domäne wie in Bild 1 zu sehen. Der Installationsassistent liefert bereits eine SQL 2008 Express Instanz beim Installationsvorgang mit. Naturgemäß sollte hier nicht der Hyper-V-Host zur Installation der Anwendung herangezogen werden. Beispielsweise eine Workstation oder ein mobiles System wie etwa Laptop oder ein USB-Stick mit Windows to Go eignet sich für den Einsatz des Tools.
Nach der Installation erweitert der Systembetreuer den Knoten mit der Bezeichnung WS2012 Hyper-V Security 1.0. Hier zeigt sich, dass das Werkzeug noch nicht auf den aktuellen Stand gebracht wurde, eine Option für die Version Server 2012 R2 fehlt bisher. Trotzdem behalten die darin enthaltenen GPO-Vorgaben ihre Gültigkeit und gelten ebenso für die aktuelle Hyper-V-Version.
In der mittleren Spalte befinden die sicherheitsrelevanten Einstellungen für die Gruppenrichtlinienobjekte, der Systembetreuer kann über das rechte Menü die GPOs exportieren wie Bild 2 zeigt. Diese Datei kann über die Gruppenrichtlinien Management Konsole (GPMC) importiert werden, oder der Systembetreuer setzt auf das Powershell Cmdlet „Import-GPO“. Sollten die betreffenden Hyper-V-Hosts nicht Teil einer Domäne sein, kommt das von Microsoft bereitgestellte Werkzeug „LocalGPO“ zum Zuge.
Der Importvorgang über die GPMC gestaltet sich recht komfortabel, allerdings ist ein wichtiges Detail zu beachten: Der Hyper-V-Host muss sich in einer eigenen Organisationseinheit (OU) befinden, sollte der Host zusätzlich als Domänencontroller (DC) heraufgestuft worden sein wird der Vorgang scheitern.
Zunächst erstellt der Systembetreuer ein neues Gruppenrichtlinienobjekt, das NT4ADMINS-Team wählt die Bezeichnung Hyper-V Sicherheitsrichtlinien wie in Bild 3 zu sehen. Über einen Rechtsklick wählt der Systembetreuer die Importfunktion, wählt im Assistenten den entsprechenden Ordnerpfad aus und startet den Importvorgang. Nun verknüpft das NT4ADMINS-Team die Gruppenrichtlinie mit der OU der Hyper-V-Hosts und startet gegebenenfalls über das Cmdlet „gpupdate“ die Replikation der Änderungen innerhalb der Domäne.
Weiter geht es mit dem Beitrag in der Märzausgabe des E-Papers von NT4ADMINS.
