Härtung von Hyper-V im Server 2012 R2, Teil 3
1. April 2014
Für viele kleinere und auch mittlere Unternehmen ist die Frage nach der Härtung und Absicherung ihrer Hyper-V-Systeme oftmals nur mit entsprechenden Zugriffsbegrenzungen zum Hypervisor-Dienst auf den jeweiligen Servern assoziiert. Allerdings müssen Systemadministratoren gerade in diesem Bereich sowohl das Augenmerk auf die Physikalischen Systeme und den darauf laufenden Virtualisierungstechnologien haben, als auch die virtuellen Maschinen (VMs) selbst im Blick behalten.
In den beiden ersten Teilen (Teil 1 ist hier auf der Website zu finden, Teil 2 steht im Rahmen des E-Papers März 2014 allen Abonnenten zur Verfügung) wurden bereits einige Details zum Eingrenzen des Zugriff auf die Funktionen der virtuellen Maschinen, auf den Einsatz von Gruppenrichtlinien beim Hyper-V-Host, und zum Härten der VMs mit Hilfe von Gruppenrichtlinien gezeigt.
Im Teil 3 liegt das Augenmerk auf den Sicherheitseinstellungen im Bereich der Dateien, Ordner und Freigaben.
Der Hyper-V setzt beim Verwalten der Daten auf das traditionelle Datei-und Ordnersystem. Hier kann der Systembetreuer versuchen, die Zugriffe wie gewohnt zu reglementieren und das System so zu härten. Oftmals kann es – vielfach erst später im Betrieb – vorkommen, dass Zugriffsbeschränkungen nicht wie gewohnt ihre Wirkung zeigen, sondern dass Applikationen oder Tools plötzlich am Dateizugriff gehindert werden.
Da hilft es auch nicht als Domänenadministrator angemeldet zu sein, denn im Hintergrund des Hyper-V laufen die Zugriffsanfragen über das lokale Serverkonto ab, und nicht unbedingt über den angemeldeten Benutzer-Account. Zwar wird das Hyper-V-Interface über den angemeldeten Benutzer ausgeführt, doch Anfragen werden an den Hintergrunddienst des Hyper-V-Servers übermittelt, dieser kümmert sich dann um die Ausführung.
Auch bei der Kommunikation mit anderen Diensten oder Servern authentifiziert sich der Hyper-V-Dienst über den entsprechenden lokalen System-Account. Beim Domäneneinsatz ist dieser System-Account im Active Directory vorhanden, in Arbeitsgruppen-Netzwerken greift der Systembetreuer auf Authentifizierungs-Systeme wie etwa Credential Security Supportprovider (CredSSP) zurück, oder er umgeht teilweise die Sicherheitsabfragen mittels Einträgen in die Liste der vertrauenswürdigen Hosts (TrustedHosts) per Windows Remote Management (WinRM). Das kann entweder über die Kommandozeile oder auch per Powershell vorgenommen werden.
winrm set winrm/config/client @{TrustedHosts="RemoteComputerName"}
Weitere Informationen sind auf der Technet-Seite von Microsoft zu finden.
Vor allem die Begrenzung auf maximal fünf Verbindungen pro Benutzer ist hierbei erwähnenswert. Daher empfiehlt es sich fast in jedem Fall, die Hyper-V-Hostsysteme in eine Domäne einzubinden, vor allem die Härtung der Systeme kann so vom Systemadministrator einheitlich und komfortabel vorgenommen werden. Zudem Einträge in die Liste der vertrauenswürdigen Hosts bei vielen Administratoren durchaus sicherheitskritische Bedenken auslöst.
Sollte das Hyper-V-System ausschließlich lokal eingesetzt werden, kümmert sich der Systembetreuer vor allem um die Berechtigungen des New Technology File System (NTFS). Hierbei ist eines besonders wichtig – egal ob die Ordnerpfade nun eigens definiert sind, oder die Standardvorgabe von Hyper-V zum Tragen kommt: Der Hyper-V-Serverdienst kümmert sich von Anfang an selbst um die Verwaltung der Sicherheitsberechtigungen.
Somit besteht für den Systembetreuer kein Bedarf, hier Zugriffseinschränkungen oder ähnliches auf der Ebene der Ordnerberechtigungen vorzunehmen. Sollten solche Eingriffe trotzdem vorgenommen werden, so kann dies zu unvorhergesehenen Problemen und diversen Fehlern führen.
Auch Netzwerkfreigaben wie etwa iSCSI-Ziele (internet Small Computer Interface) oder mittels Fibre Channel (FC) angebundene Logical Unit Numbers (LUNs) müssen in diese Überlegungen mit einbezogen werden, falls hier beispielsweise VMs abgelegt sind.
Sollten Einschränkungen in den entsprechenden Ordnerbereichen unbedingt vorgenommen werden, etwa weil Unternehmensrichtlinien oder technische Gründe dies unumgänglich machen, so muss der Systembetreuer hier besonders vorsichtig vorgehen. Sollten VMs nach einer solchen Operation nicht starten und beispielsweise „Zugriff verweigert“ Fehlermeldung auftauchen, überprüft der Administrator besser nochmals die gesetzten Ordnerberechtigungen.
Interessant wird es auch bei einem Blick in die Berechtigungsliste der Hyper-V-Ordner. Hier taucht (wie in Bild 5 zu sehen) beispielsweise der Eintrag „Virtual Machines“ auf, dieser Benutzer darf auf keinen Fall verändert oder aus der Berechtigungsliste entfernt werden. Zudem ist es nicht möglich, diesen Benutzer in die Zugriffsliste von anderen Ordnern zu bringen, das AD wird bei solchen versuchen diesen AD-User nicht finden, da er nur vom Hyper-V während der Konfiguration der Speicherorte angelegt wird.
Falls SMB-Freigaben (Server Message Block) zum Einsatz kommen, sind zusätzliche Überlegungen anzustellen. Sicherheitsaspekte lassen hier nur den sinnvollen Einsatz innerhalb von Domänensystemen zu. Die jeweiligen System-Accounts der Hyper-V-Server sollten hier Vollzugriffsrechte eingeräumt werden, mehr ist beim Einsatz dieser Freigaben erst einmal nicht zu beachten.
Falls die SMB-Version 3.0 verwendet wird, so ist es möglich, VMs im laufenden Betrieb von einem Hyper-V-Host auf einen anderen zu verschieben. Die entsprechende Microsoft-Seite liefert passende Hilfestellungen zu diesem Thema. Mittels der Powershell kann die Live Migration über folgenden Befehl gestartet werden:
Move-VM –Name VM1 -DestinationHost HV2
Nun kann es vorkommen, dass die jeweiligen Rechte für diesen Vorgang erst einmal nicht ausreichen. Dann öffnet der Administrator das entsprechende Untermenü im Hyper-V-Eigenschaftsfenster wie Bild 5 zeigt, und vergibt die passenden Vertrauensstellungen.
Hier achtet der Systembetreuer darauf, nicht über die Option „alle Dienste“ sämtliche Freigabemöglichkeiten zu aktivieren, besser ist die Auswahl der einzelnen Dienste für Common Internet File System (CIFS) und dem Microsoft Virtual System Migration Service. Aber Achtung, der CIFS-Eintrag nur hier als Synonym für den SMB-Zugriff verwendet, in den meisten Zusammenhängen sind die beiden Begriffe nicht gleichzusetzen.
Virenschutz nicht vergessen
Sichere Systeme sind nur möglich, wenn neben allen anderen Sicherheitskriterien auch ein vernünftiges Antivirensystem installiert ist. Während auf der Clientseite innerhalb der VMs meist Virenschutzlösungen ohne besondere Konfigurationseinstellungen aufgespielt werden, gestaltet sich die korrekte Konfiguration der Hostsystem-Schutzlösungen meist deutlich differenzierter.
Hier müssen beispielsweise bestimmte Ordner und Dienste von der Echtzeitüberwachung ausgeschlossen werden. Das unterscheidet sich je nach Einsatzszenario gegebenenfalls noch voneinander. Beispielsweise müssen bei Hyper-V-Clustersystemen deutlich mehr Punkte beachtet werde. Dazu stellt Microsoft entsprechende Informationen auf ihrer Webseite zur Verfügung.
Im zweiten Teil unserer Beitragsreihe „Hyper-V: Performanceprobleme bei VMs beheben“ wurde dieses Thema ebenfalls angesprochen. Aber auch die besten Virenschutzlösungen sind nicht ausreichend, wenn weitere Anwendungen oder gar Systemdienste von Sicherheitslücken betroffen sind.
Sicherheits-Patches und Hotfixes halten Systeme aktualisiert
Eine Möglichkeit, Infektionen und Angreifern das Leben zu erschweren, ist auf den Gastsystemen alle sicherheitsrelevanten Patches oder Hotfixes einzuspielen. Bei den Patches sollten die Systembetreuer nicht nur auf die Microsoft-Updates vertrauen, auch bei Anwendungen und Laufzeitumgebungen von Drittanbietern wie Flashplayer oder Java werden immer wieder Sicherheitslücken bekannt, dem sollten durch aktuelle Versionen entgegengetreten werden.
Das kann beispielsweise manuell von den Systembetreuern überprüft werden. Oder es werden entsprechende Server im Unternehmen eingesetzt die auch eine definierte Gruppe an Zusatz-Applikationen auf dem Laufenden hält. Kleinere Unternehmen können beispielsweise auch Drittanbietersoftware wie etwa „ninite“ oder „Secunia PSI“ einsetzen, um auf ihren VM-Systemen automatisch für Anwendungssoftwareupdates zu sorgen.
Durch einen Scan der im System installierten Software und einem Abgleich mit den aktuell verfügbaren Versionen kann dem Systembetreuer mittels SecuniaPSI ein guter Überblick verschafft werden, wie Bild 6 zeigt. Hierbei stellt sich aufmerksamen Administratoren allerdings die Frage, ob die eingesetzte Aktualisierungssoftware nicht selbst von Sicherheitslücken betroffen ist, und gegebenenfalls im Hintergrund dazu gebracht werden kann selbst Schadsoftware ins System einzuschleusen.
Aber auch auf den Hyper-V-Servern ist es wichtig, für Aktualität zu sorgen, und Windows-Updates regelmäßig einzuspielen und deren korrekte Installation zu prüfen. Bei Updatefehlern informieren sich gewissenhafte Systembetreuer über Probleme in einschlägigen Foren oder nutzen die KB-Nummer der Patches um Installationsanleitungen und Fehlerbehebungsmaßnahmen von Microsoft zu erhalten.
Zusammenfassung
Sicherheit im Hyper-V-Umfeld bleibt ein heikles Thema. Je nach Unternehmensvorgaben, Netzwerk- und Serverarchitektur, und dem verfügbaren Budget müssen die Systembetreuer einen bestmöglichen Kompromiss aus Sicherheit, Kosten, Nutzerfreundlichkeit und Verwaltungsaufwand finden. Oftmals können bereits einige Stellschrauben verändert werden um die Sicherheit deutlich zu erhöhen. Beispielsweise durch eine Härtung der Hyper-V-Hostsysteme und VMs durch Gruppenrichtlinien.
Andere Lösungen erfordern zusätzliche Investitionen in die vorhandene Infrastruktur wie der Einsatz aktueller Hardwarefirewall-Technologie und die Trennung von Client- und Servernetzwerk. Daher gibt es in Bereich Hyper-V-Sicherheit kein Allheilmittel, die Administratoren stehen vor einem komplexen Thema, und dies gilt es geplant und vor allem fallspezifisch anzugehen.
Obligatorische Sicherheitsaspekte wie die Schulung der Mitarbeiter, dass Kennwörter beispielsweise nicht auf die Unterseite der Tastatur geklebt werden oder schlimmer noch fremden „Administratoren“ per Email gesendet werden sollen hat das NT4ADMINS-Team bewusst außen vor gelassen.
