Server Core als solide Basis

Hyper-V ist theoretisch der ideale Kandidat für den Einsatz als Windows Server Core. Das Fehlen der grafischen Oberfläche schränkt die Auswahl der installierbaren Software inklusive Windows-Features erheblich ein und hält unerfahrene Administratoren manchmal davon ab, Änderungen am System vorzunehmen, die dessen Sicherheitsniveau senken würden.

Mit dem Windows Admin Center steht Ihnen eine ansprechende wie auch sichere Benutzeroberfläche zur Remote-Verwaltung von Hyper-V im Browser zur Verfügung. Sie sollten daher den Einsatz von Server Core ernsthaft als Basis für Ihre Hyper-V-Installationen erwägen. Die Ersteinrichtung eines Hosts kann anfangs etwas ungewohnt sein und mehr Zeit in Anspruch nehmen, aber erfahrungsgemäß gewöhnen sich Administratoren schnell daran und legen sich PowerShell-Skripte zu, die nach der Grundinstallation und Netzwerkkonfiguration die weiteren Arbeiten automatisiert und fehlerfrei erledigen.

Bevor Sie sich allerdings für Server Core entscheiden, sollten Sie unbedingt prüfen, ob das Team, das die Umgebung betreiben wird, bereits reif dafür ist und die Entscheidung für Server Core bewusst mitträgt. Administratoren, die keine andere Art der Systemverwaltung kennen, als sich per RDP auf jedes einzelne System zu verbinden, werden in einem Server-Core-Cluster nach "Abkürzungen" suchen, die das Potenzial haben, die bisherigen Absicherungsmaßnahmen zunichtezumachen.

Ein weiterer Punkt, dem Sie beim Sicherheitsdesign Ihrer Hyper-V-Umgebung Beachtung schenken sollten, ist die Domänen-Mitgliedschaft der Hosts. Ein Standalone-Host, beispielsweise in einer DMZ, profitiert kaum von einer AD-Integration; letztere eröffnet jedoch einige Angriffsvektoren, die bei einem Betrieb als Workgroup-Server nicht möglich wären. Zwei Beispiele von vielen sind Pass-The-Hash-Angriffe auf Konten von Hyper-V-Admins sowie Angriffe auf DPAPI-geschützte Maschinengeheimnisse durch Missbrauch eines Domaincontroller-Backups.

Die Mehrheit der Hyper-V-Hosts muss allein durch das Clustering in einer AD-Domäne laufen. In solchen Fällen sollten Sie einen Infrastruktur-Forest für Hyper-V, Storage und andere verwandte Dienste in Betracht ziehen. Der Aufwand, einige zusätzliche Domaincontroller zu betreiben, ist in vielen Umgebungen durch den Zugewinn an Sicherheit absolut gerechtfertigt.

Netzwerkzugriff beschränken

Ein Computersystem kann nicht angegriffen werden, wenn der für den Angriff erforderliche Netzwerkzugriff gar nicht erst möglich ist. Deshalb sollten Sie dafür sorgen, dass die Netzwerkkommunikation zu Ihren Hyper-V-Hosts möglichst eingeschränkt ist. Die erste und wichtigste Stufe dieser Trennung ist die hardwareseitige Separation zwischen dem

• Netzwerktraffic der VMs,
• Managementtraffic der Hyper-V-Hosts,
• Managementtraffic der Hardware und
• Storage-Traffic, sofern er über das Netzwerk abgewickelt wird, also iSCSI, SMB oder Storage Spaces Direct.

Am einfachsten funktioniert das Abtrennen des Hardwaremanagements. Dabei handelt es sich in nahezu allen Fällen um separate Netzwerkschnittstellen, und für die effektive Netzwerktrennung müssen Sie sie lediglich an ein anderes VLAN anschließen und Ihre Datacenter-Firewall verwenden, um den Verkehr zu regulieren.

In der Regel sind lediglich SSH-Verbindungen auf Port 22, HTTPS-Verbindungen auf Port 443 sowie zwei herstellerspezifische Ports für das Einbinden von virtuellen Medien und Konsolen erforderlich. Viel wichtiger jedoch ist die Einschränkung der Quellen dieser Kommunikation auf dedizierte Administrator-Workstations.

Eine harte Trennung der Arten von Netzwerktraffic ist in den letzten Jahren schwieriger geworden, da zunehmend nur wenige, dafür aber extrem schnelle Netzwerkkarten in den Servern verbaut sind. Dieser Trend führt dazu, dass Sie oft nur einen einzigen vSwitch einrichten können. Über diesen werden virtuelle Adapter für Host-Management, Live Migration, Replikation, Storage und nicht zuletzt VMs bereitgestellt.

Es ist daher essenziell, diese Verkehrsarten wenigstens durch unterschiedliche VLANs und IP-Subnetze voneinander zu trennen und damit zu erreichen, dass der Verkehr selbst dann durch die Datacenter-Firewall läuft, wenn beispielsweise eine VM mit dem Host kommunizieren soll, auf dem sie gerade ausgeführt wird.

Schalten Sie die Windows-Firewall auf Ihren Hyper-V-Hosts ein. Von den Management-Workstations aus benötigen Sie den Zugriff auf Windows Remote Management (WinRM) und DCOM – das heißt, RPC inklusive der variablen Ports im oberen Bereich. Zwischen den Hosts in einem Cluster sollten Sie den Netzwerkverkehr komplett offenlassen, um möglichen Störungen von vornherein aus dem Weg zu gehen.

Um das Abhören des Migrationsverkehrs zu erschweren, aber auch aus Performancegründen, sollten Sie den Traffic für Live Migration und Hyper-V-Replica nach Möglichkeit nicht routen und auch sonst jeweils in einem einzelnen VLAN einkapseln. Dies ist jedoch nur dann problemlos möglich, wenn sich sowohl der Hyper-V-Cluster als auch alle Replikationspartner innerhalb eines physischen Standorts befinden.

Gerade bei Replikationen ist es jedoch oft der beabsichtigte Zweck, virtuelle Maschinen in einen anderen Standort zu kopieren. In solchen Fällen müssen Sie dafür sorgen, dass die beteiligten Netzwerkkomponenten wie Switche und Router auf der ganzen Strecke den höchsten Schutz genießen und idealerweise den Replikationsverkehr durch das Einbauen oder Aktivieren zusätzlicher Adapter auch hardwareseitig isolieren.

Storage nicht vergessen

Hyper-V unterstützt einige Storage-Technologien zur Speicherung der Daten seiner VMs. Neben den klassischen blockbasierten Datenspeichern auf SAS-, Fibre Channel- oder iSCSI-Basis sind filebasierte Speicher in SMB3-Applikationsfreigaben sowie Software-defined Storage auf Grundlage von Storage Spaces Direct (S2D) möglich. Bei der Umsetzung einer Sicherheitsstrategie für Ihre Hyper-V-Hosts und -Cluster müssen Sie sich zwingend auch mit der Sicherheit des Storage-Unterbaus beschäftigen, denn ein Angriff auf den Storage kann im Endeffekt durchaus wirkungsvoller sein als ein Versuch, die Hosts selbst zu kompromittieren.

Viele Hersteller von SANs der Unternehmensklasse veröffentlichen regelmäßig Best Practices und Anleitungen zum sicheren Betrieb ihrer Produkte – von der regelmäßigen Kennwortänderung über Role Based Access Control (RBAC) bis zu Read-only-Snapshots und Netzwerksegmentierung. Diese Empfehlungen sollten Sie beherzigen und, soweit sie auf Ihre Umgebung passen, umsetzen.

Einen besonderen Platz in der Sicherheitsbetrachtung nimmt freilich der SMB3-Storage ein. Einerseits müssen die jeweiligen Fileserver Mitglied im Active Directory sein, um die Authentifizierung der Hyper-V-Hosts mit ihren Maschinenidentitäten zu gewährleisten. Andererseits kann in der Windows-Implementation von SMB kaum eine Netzwerkeinschränkung für konkrete Freigaben erreicht werden. Zur effektiven Absicherung des Storage-Zugriffs gilt daher:

• Härten Sie die Fileserver nach der in Ihrer Organisation geltenden Richtlinie.
• Nutzen Sie für Anwendungsfreigaben möglichst dedizierte Hosts oder Cluster.
• Beschränken Sie den Netzwerkzugriff auf Port 445 (SMB) auf die Adressen oder Subnetze, in denen Ihre Hyper-V-Hosts stehen.
• Beschränken Sie die Freigaberechte auf die Identitäten der zugriffsberechtigten Maschinen. Sie sollten solche Berechtigungen über Gruppen vergeben, zu denen Sie bei Bedarf Benutzeraccounts von Administratoren hinzufügen können, sollten Sie einmal Daten auf Anwendungsfreigaben kopieren müssen. Vergessen Sie nicht, die Administratoren nach getaner Arbeit wieder aus den Gruppen zu entfernen oder nutzen Sie das PAM-Feature von Active Directory, um temporäre Gruppenmitgliedschaften zu erzeugen.
• Arbeiten Sie im Kontext des Virtual Machine Managers (VMM) möglichst mit Inhaltsbibliotheken, um direkte Zugriffe auf die Applikationsfreigaben zu vermeiden.

Im dritten und letzten Teil der Workshopserie zeigen wir, wie Sie Hyper-V sicher an Storage anbinden und stets den Überblick über Zugriffsrechte behalten. Im ersten Teil haben wir erklärt, warum und wie Sie einen Hyper-V-Host genauso schützen müssen wie jeden anderen Windows-Server.

Über den Autor: Evgenij Smirnov ist Senior Solutions Architect bei Semperis und Microsoft-MVP für Cloud & Datacenter Management und VMware Certified Implementation Expert für Datacenter-Virtualisierung.