VMware vSphere schützen (2)
Virtuelle Plattformen sind ein komplexes Gebilde. Dementsprechend groß ist die potenzielle Angriffsfläche und wichtig die Absicherung. Glücklicherweise steht Admins in vSphere eine Fülle an Funktionen zur Verfügung, um die Plattform vor Hackern abzuschirmen. Wir werfen einen Blick auf die wichtigsten Schritte. Im zweiten Teil geht es darum, wie Sie den Virtualisierungshost lückenlos abdichten, warum NTP als Zeitquelle robuster ist als PTP und wie Sie schon auf Netzwerkebene für Schutz sorgen.
Ist die Hardware Ihrer ESXi-Hosts optimal konfiguriert, müssen Sie sich der Konfiguration des Hypervisors und der restlichen Dienste widmen, aus denen sich ein ESXi-Host zusammensetzt. Viele der Maßnahmen und Designprinzipien, die Sie für die Hardwareverwaltung beherzigen sollten, gelten gleichermaßen für das Managementinterface eines ESXi-Hosts.
Host abdichten
Versuchen Sie, soweit technisch möglich, die Administrationsschnittstellen über separate Netzwerkkarten auszuführen. Mindestens jedoch gehört das Host-Management in ein separates VLAN mit rigoros eingeschränkten Zugriffsmöglichkeiten aus produktiven Netzsegmenten, insbesondere sollte kein Zugriff aus Client- und VPN-Netzen möglich sein. Hosts, die von einem vCenter verwaltet werden, sollten im strikten Sperrmodus laufen. Damit ist ein direkter Verwaltungszugriff auf diese Hosts nicht mehr möglich. Allerdings gibt es keine unterstützte Möglichkeit, die lokale Administration wiederherzustellen, sollte die Verbindung zum vCenter gestört sein oder verloren gehen. Sie müssten in diesem Fall den Host neu installieren. Die Empfehlung von VMware lautet in der Regel, den normalen Sperrmodus zu aktivieren und eine möglichst kurze Liste zugelassener lokaler Accounts für die Notfalladministration zu führen.
Fügen Sie die ESXi-Hosts nicht Ihrem Active Directory als Member hinzu. Selbst bei Hosts ohne vCenter-Verwaltung sollten Sie hier mit lokalen Benutzerkonten arbeiten. Begrenzen Sie außerdem durch die eingebaute Firewall des ESXi den ein- und ausgehenden Netzwerkverkehr auf die unbedingt notwendigen Kommunikationsbeziehungen und deaktivieren Sie SSH und SNMP komplett.
Aktivieren Sie dafür die modernen und als sicher eingestuften TLS-Dialekte. ESXi 8.0 wird standardmäßig in einer reinen TLS-1.2-Konfiguration ausgeliefert. Auf älteren Versionen müssen Sie dafür sorgen, dass TLS 1.2 aktiv bleibt und veraltete Protokolle nicht versehentlich zum Einsatz kommen. Leiten Sie zudem die Host-Logs auf einen externen Syslog-Server um. Das Gleiche gilt für die Logs Ihrer vCenter-Appliance(s), die unter Umständen sogar wichtiger sind, denn sie beinhalten das Authentifizierungs- und Autorisierungsgeschehen in vCenter-SSO.
Zeitquelle: Besser NTP als PTP
Nun sorgen Sie noch dafür, dass die Systemzeit Ihrer ESXi-Hosts und anderer Komponenten wie beispielsweise der Storage-Arrays oder der vCenter-Appliance möglichst exakt der Uhrzeit in der übrigen Infrastruktur entspricht. Dabei sollten Sie vermeiden, zwei NTP-Zeitquellen einzutragen. Falls Ihnen nicht mehr als zwei NTP-Server zur Verfügung stehen, belassen Sie es lieber bei einem. ESXi beherrscht mittlerweile neben NTP auch das relativ neue "Precision Time Protocol" (PTP). Allerdings verfügt dieses nicht über die gleiche Resilienz gegenüber Infrastrukturstörungen wie NTP. Falls Sie PTP einsetzen, aktivieren Sie daher unbedingt einen Fallback auf NTP und tragen eine entsprechende Anzahl an NTP-Servern ein. Aus Sicherheitssicht ist der Einsatz von NTP dem von PTP vorzuziehen.
Ist Ihre Umgebung mit der vSphere Enterprise Plus Edition lizenziert, sollten Sie Host-Profile verwenden, um die zuvor beschriebenen Sicherheitskonfigurationen einheitlich anzuwenden. Damit stellen Sie sicher, dass Sie keine der wichtigen Konfigurationseinstellungen vergessen. Außerdem prüft vCenter die Profilcompliance und generiert Alarme, wenn sich bei einem Host eine vom Profil abweichende Konfiguration einschleicht.
Prüfen Sie auch, inwiefern die "Microarchitectural Data Sampling"-Sicherheitslücke für Ihre ESXi-Hosts relevant ist, und führen Sie bei Bedarf die Analyse und Nachbehandlung mit dem entsprechenden PowerShell-Skript durch. Falls Sie bisher keine Behandlung dieser Anfälligkeit vorgenommen hatten, müssen Sie mit einem gewissen Verlust an Virtualisierungsleistung rechnen. Normalerweise bewegen sich die Einbußen zwischen fünf und zehn Prozent, in Extremfällen wurden aber auch schon 30 bis 40 Prozent gemessen.
Software aktuell halten
Halten Sie Ihre Umgebung stets auf dem neusten Stand, denn VMware veröffentlicht ständig neue Sicherheitsupdates für alle Komponenten und schließt damit zuweilen gravierende Sicherheitslücken. Das betrifft in erster Linie ESXi-Hosts und vCenter-Appliances, die Sie mithilfe des Lifecycle Managers (vLCM) auf eine geordnete Art und Weise aktuell halten können, aber auch VMware Tools in den Gastbetriebssystemen und Drittanbieter-Produkte, die sich eng mit vSphere integrieren und dennoch nicht über vLCM aktualisierbar sind.
Falls Sie in Ihrer Umgebung spezielle Hardware wie etwa NVIDIA-Grafikkarten einsetzen, deren Treiber regelmäßigen Updates unterliegen, müssen Sie einen Prozess zum Herunterladen dieser Komponenten und deren Integration in Ihre vLCM-Umgebung einrichten. Studieren Sie bei dieser Gelegenheit die Supportrichtlinien der jeweiligen Hersteller aufmerksam. Manchmal wird eine Software- oder Treiberversion nur bis zum Erscheinen der übernächsten Version unterstützt. Für die installierbaren Drittanbieter-Komponenten hat VMware mit dem Release der Version 8 die Boot-Option "execInstalledOnly" standardmäßig aktiviert. In früheren Versionen mussten Sie diese Option explizit für Ihre Hosts einschalten. Bedenken Sie, dass die Option erst dann ihre Wirkung entfalten kann, wenn Secure Boot für ESXi eingerichtet und aktiviert wurde.
Schutz auf Netzwerkebene
Zusätzlich zur grundsätzlichen Designempfehlung, den vSAN- und vMotion-Traffic in isolierten Netzwerksegmenten einzukapseln, sollten Sie für diese Netzwerkkommunikation die Transportverschlüsselung aktivieren. Beide Protokolle haben nämlich das Potenzial, die gesamten Daten einer VM einem Lauschangriff auszusetzen, sodass zusätzliche Absicherung dringend zu empfehlen ist.
Die Verschlüsselung für vMotion müssen Sie für jede VM einzeln aktivieren, die vSAN "Data-In-Transit Encryption" auf der Ebene des vSAN-Clusters. Die Transportverschlüsselung für vSAN funktioniert unabhängig von der Verschlüsselung der ruhenden Daten und erfordert keinen Schlüsselverwaltungsserver. Lizenztechnisch sind die Voraussetzungen allerdings identisch: Beide Verschlüsselungsverfahren erfordern mindestens Enterprise-Lizenzierung.
Deaktivieren Sie Netzwerkfunktionen wie "Forged Transmit", "Promiscuous Mode" und "MAC Spoofing" auf den virtuellen Switches und Portgruppen. Standardmäßig lehnen alle Netzwerk-Komponenten von vSphere 7.0 und 8.0 diese Arten von Verkehr ab. Manche VMs könnten allerdings diese Merkmale benötigen. In diesem Fall müssen Sie mit den Betreibern der jeweiligen Anwendungen zusammenarbeiten, um die optimale Platzierung für solche VMs zu finden. Sorgen Sie außerdem dafür, dass der Verwaltungsdatenverkehr nur bei dedizierten Managementadaptern aktiviert ist. Alle VMKernel-Adapter wie vSAN oder vMotion haben die Fähigkeit, gleichzeitig als Management-NIC zu fungieren. Sie sollten diese Art von Konfigurationen vermeiden.
Im dritten Teil schauen wir uns an, wie Sie das vCenter härten und wie Sie als letzten Schritt Ihre virtuellen Maschinen abschirmen. Im ersten Teil haben wir uns nach einer Einführung damit beschäftigt, wie Sie in vSphere-Szenarien für physische Sicherheit sorgen und warum das Powermanagement über IPMI als unsicher einzustufen ist.
Über den Autor: Evgenij Smirnov ist Senior Solutions Architect bei Semperis und Microsoft-MVP für Cloud & Datacenter Management sowie VMware Certified Implementation Expert für Datacenter-Virtualisierung.