Stand: Oktober 2026

Einleitung: Warum ESXi-Hosts ein primäres Angriffsziel sind

Hypervisoren bilden das Fundament virtualisierter Infrastrukturen – und ziehen damit Angreifer magisch an. Die kritische Schwachstelle CVE-2024-37085 im SLP-Dienst zeigte 2024 eindrucksvoll, wie schnell ein einzelner Host kompromittiert wird. Ransomware-Gruppen nutzen diesen Einfall, um Audit-Logs zu löschen (T1070) und VM-Dateien auf gemeinsamen Datastores zu verschlüsseln. Ein erfolgreicher Einbruch legt damit gesamte Cluster lahm.

Die Frage lautet nicht, ob ein Angriff erfolgt, sondern ob Ihre Hosts darauf vorbereitet sind. Fehlende MFA-Unterstützung auf Host-Ebene, Standard-Passwort-Richtlinien und deaktiviertes persistentes Logging sind Einfallstore, die Angreifer systematisch scannen. Der VMware Hardening Guide liefert die technische Baseline, doch Checklisten allein reichen nicht.

Dieser Leitfaden führt in neun Schritten vom initialen Hardening über Netzwerk-Segmentierung, SSH-Hardening und Log-Archivierung bis zum automatisierten Compliance-Audit. Jeder Schritt nennt konkrete PowerCLI-Befehle, relevante STIG-IDs und Fallback-Strategien – damit Sie die Angriffsfläche verkleinern, bevor der nächste Exploit erscheint. Der Aufbau orientiert sich an CIS-Benchmarks und DISA-STIGs, sodass Sie Härtegrad und Nachweisbarkeit parallel steigern.

Bevor du startest: 3 Klärungsfragen

Drei Fragen entscheiden über Umfang und Priorisierung aller nachfolgenden Schritte. Erstens: Welche Compliance-Vorgaben greifen? Ein ISMS nach ISO 27001 fordert andere Nachweise als NIS2 oder branchenspezifische Regularien. Zweitens: Welche Verwaltungs-Tools stehen bereit? Wer PowerCLI oder Ansible nutzt, härtet Hosts automatisiert und wiederholbar; reine GUI-Administration über vCenter limitiert Skalierbarkeit und Auditierbarkeit. Drittens: Wie sieht der aktuelle Patch- und Logging-Stand aus? Fehlende Security-Patches, deaktiviertes persistentes Logging oder eine fehlende Scratch-Partition machen jedes spätere Hardening wirkungslos.

Die Antworten bestimmen, ob du mit einer schnellen Baseline (STIG Level 1) startest oder direkt ein risikobasiertes Vorgehen nach ISO 27001 wählst. Auch die MFA-Lücke auf Host-Ebene lässt sich nur bewerten, wenn klar ist, welche Identitätsquellen (vCenter, AD, Entra ID) im Spiel sind. Dokumentiere die drei Antworten knapp – sie bilden die Basis für die Schritt-Auswahl in den folgenden Abschnitten.

Schritt 1: Offizielle Hardening-Guides als Baseline nutzen

Der Security Configuration Guide für vSphere 8.0 liefert die referenzierte Basis aller ESXi-Sicherheitskontrollen. Broadcom dokumentiert dort verbindliche Vorgaben für FIPS-konforme Cipher-Suiten, Passwort-Richtlinien wie Security.PasswordMaxDays auf 9999 Tage und Audit-Logging-Parameter. Der Guide definiert zudem die SSH-Baseline. Standardmäßig erlaubt ESXi aes256-ctr, aes192-ctr, aes128-ctr plus zwei Legacy-Einträge. Das Hardening fordert ausschließlich FIPS 140-2/3-validierte Algorithmen. Seit vSphere 7.0 Update 2 verschlüsselt der Host seine Konfiguration automatisch – ein Detail, das der Leitfaden explizit herausstellt.

Ergänzend bündelt die zentrale Hardening-Guide-Übersicht alle aktuellen Leitfäden für vCenter, NSX und Aria Operations. Wer Abweichungen vom Standard plant, muss sie gegen diese Baseline begründen und dokumentieren. Der ESXi-Guide referenziert zudem die DISA-STIG-Prüf-IDs V-258787 für lokales Audit-Logging und V-258788 für Syslog-Offload, die für Compliance-Audits herangezogen werden. Ohne diese Referenz bleibt jedes Hardening eine Insellösung ohne Nachweisbarkeit. Die konsequente Orientierung an diesem Kanon stellt sicher, dass spätere Assessments mit CIS-Benchmarks oder Tenable-Audits auf gemeinsamer Datenbasis aufsetzen. Persistentes Logging via Scratch-Partition auf VMFS-Datastore bildet dabei die technische Vorbedingung, damit Audit-Daten einen Reboot überleben. Der Guide fungiert als Single Source of Truth für alle nachfolgenden Schritte dieses Härtungsprozesses.

Schritt 2: STIG/CIS-Benchmarks als Audit-Maßstab anwenden

Der DISA STIG für vSphere 8.0 ESXi liefert konkrete Prüf-IDs, die jeder Host erfüllen muss. V-258787 verlangt lokales Audit-Logging, V-258788 fordert den Syslog-Offload auf zentrale Collector. Diese IDs machen Compliance messbar und wiederholbar.

Parallel stellt der CIS-Benchmark über Tenable eine automatisierbare Audit-Vorlage bereit. Scanner prüfen Hunderte Konfigurationswerte gegen die Baseline – von Passwort-Richtlinien bis zu SSH-Cipher-Suiten. Ergebnisse lassen sich als Report exportieren und in Ticket-Systeme überführen.

Beide Standards decken sich weitgehend, setzen aber unterschiedliche Schwerpunkte: STIG orientiert sich an DoD-Anforderungen, CIS an Community-Konsens. Wer beide abbildet, schließt Lücken, die ein einzelner Katalog offenlässt. Automatisierung via PowerCLI oder Tenable-API wandelt Punkt-in-Zeit-Prüfungen in Continuous Compliance um.

Wichtig: Die Benchmarks nur anzuwenden reicht nicht. Abweichungen müssen dokumentiert, risikobewertet und mit Fristen hinterlegt werden. Nur so entsteht ein nachweisbares Verfahren, das Auditoren akzeptieren.

Schritt 3: MFA-Lücke schließen – Bastion & Privileged Access Workstations

ESXi bietet auch 2026 kein natives MFA und keine Identity Federation. Wer sich direkt am Host per SSH oder DCUI anmeldet, umgeht jede vCenter-Policy. Der Workaround verlagert die starke Authentifizierung vor den Hypervisor: Ein Bastion-Host (Jump-Host) mit erzwungener Zweifaktor-Authentifizierung wird zum einzigen Einfallstor für administrativen Zugriff. Alle anderen Management-Interfaces – SSH, ESXi-Shell, DCUI – werden per Firewall-Regel auf die IP des Bastions beschränkt.

Für den täglichen Betrieb ergänzen Privileged Access Workstations (PAW) das Modell. Diese gehärteten Clients laufen ohne lokale Admin-Rechte, nutzen Zertifikat-basiertes Login am Bastion und protokollieren jede Sitzung lückenlos. Der ESXi-Host selbst bleibt unverändert – keine VIBs, keine Konfigurationsänderungen, die beim nächsten Update verloren gingen.

Im vCenter definiert striktes RBAC, welche Rolle哪个 Account auf welchem Host ausüben darf. Der Administrator-Account wird nicht mehr direkt genutzt; stattdessen erhalten benannte Operatoren über Gruppenmitgliedschaften nur die Rechte, die ihr Task erfordert. Sophos empfiehlt, den lokalen root-Account zu behalten, aber dessen Passwort in einem Tresor zu hinterlegen und die Anmeldung per PermitRootLogin no zu sperren. So bleibt ein Notfall-Zugang erhalten, ohne die Angriffsfläche zu vergrößern.

Schritt 4: Persistentes Logging & Scratch-Partition konfigurieren

Standard-Logging auf ESXi landet im RAM und verschwindet beim Neustart. Für forensische Nachvollziehbarkeit und die STIG-Prüfung V-258787 müssen Audit-Records und Scratch-Daten auf einem persistenten VMFS-Datastore liegen.

Zwei Parameter steuern das Verhalten. Syslog.global.auditRecord.storageDirectory legt das Zielverzeichnis für Audit-Logs fest. ScratchConfig.CurrentScratchLocation definiert, wo Core-Dumps, Hostd-Logs und weitere Diagnosedateien geschrieben werden. Beide verweisen auf einen Pfad wie /vmfs/volumes//logs//.

Die Konfiguration erfolgt über esxcli system syslog config set --logdir=<Pfad> --logdir-unique=true für Syslog sowie esxcli system settings advanced set -o /ScratchConfig/CurrentScratchLocation -s <Pfad> für die Scratch-Partition. Ein Reboot aktiviert die Änderungen. Der Broadcom Security Controls Reference listet die zugehörigen STIG-IDs und Validierungsschritte.

Ein separater, dedizierter Datastore für Logs verhindert, dass volle Protokolle den Produktions-Storage blockieren. Rechte auf dem Verzeichnis beschränken sich auf root und den syslog-Dienst. Regelmäßige Rotation und Retention (z. B. 90 Tage) schließen die Lücke zu SIEM-Systemen.

Ein Medium-Artikel zur vSphere-8-Hardening-Reihe zeigt die PowerCLI-Automatisierung für Cluster-Rollouts.

Schritt 5: Root-Account entmachten & benannte Admins einsetzen

Der lokale root-Account bleibt auf ESXi-Hosts bestehen, sollte aber für den täglichen Betrieb gesperrt werden. Legen Sie stattdessen benannte Administrator-Konten an und weisen Sie ihnen die Rolle Admin zu. So verlangsamen Sie Angreifer, die nach dem Standard-Namen suchen, und schaffen eine nachvollziehbare Audit-Spur.

Entziehen Sie root die Shell-Zugriffsrechte über die Einstellung Security.AccountLockFailures auf einen niedrigen Wert (z. B. 3) und setzen Sie Security.PasswordMaxDays auf 9999, um Passwortänderungen zu erzwingen, ohne das Konto zu löschen. Diese Parameter konfigurieren Sie im Advanced Settings-Dialog des Hosts oder per PowerCLI im Skript.

Dokumentieren Sie jede Änderung mit Zeitstempel, Verantwortlichem und Ticket-Referenz. Ein Änderungslog schützt vor unbeabsichtigter Aufweichung und erfüllt Compliance-Anforderungen. VirtualizationHowto empfiehlt zudem, den root-Zugang auf die Direct Console UI (DCUI) zu beschränken und SSH für root global zu deaktivieren. IT Perfection ergänzt, dass benannte Accounts im Lockdown-Modus weiterhin über vCenter verwaltet werden können, während root isoliert bleibt.

• Lokalen Admin-User anlegen, root nicht löschen, nur entmachten
• Security.AccountLockFailures auf 3, Security.PasswordMaxDays auf 9999 setzen
• Änderungen im Change-Log mit Ticket-ID erfassen

Schritt 6: SSH-Hardening & FIPS-Ciphers erzwingen

Der SSH-Dienst auf ESXi liefert ab Werk eine Cipher-Suite, die aes256-ctr, aes192-ctr, aes128-ctr sowie zwei weitere Einträge umfasst. Für Compliance-Umgebungen genügt das nicht. Die Broadcom-Referenz definiert exakt, welche Algorithmen FIPS 140-2/3 validiert sind. Nur diese dürfen in Security.SSH.Ciphers und Security.SSH.MACs verbleiben.

Administratoren setzen die Werte über das Advanced-Settings-Panel oder per PowerCLI. Ein Beispiel: Security.SSH.Ciphers = "aes256-ctr,aes192-ctr,aes128-ctr" und Security.SSH.MACs = "hmac-sha2-256,hmac-sha2-512". Damit entfallen schwächere Verfahren wie CBC-Modi oder SHA-1-HMACs. Die Konfiguration überlebt Reboots, sofern die Host-Konfiguration verschlüsselt gespeichert wird – ab vSphere 7.0 Update 2 Standard.

Ein abschließender Verbindungsversuch mit ssh -vvv bestätigt die ausgehandelten Parameter. Dokumentieren Sie die gewählten Suites im Härtungsnachweis. Der Leonx-Leitfaden 2026 mappt diesen Schritt direkt auf ISO-27001-Kontrollen (A.8.2, A.8.3) und erleichtert Audits. Wer den Host später per Host-Profile ausrollt, übernimmt die SSH-Hardening-Werte automatisch in neue Cluster-Knoten.

Schritt 7: Automatisierte Compliance-Audits mit PowerCLI & Open-Source-Tools

Manuelle Checks skalieren nicht. Rob Vandenbrinks GitHub-Guide und die VMware-PowerCLI-Module liefern eine Offene-Basis für Assessment und Remediation at Scale. Ein Beispiel: Der Befehl Set-VMHostAdvancedConfiguration -Name Security.PasswordMaxDays -Value 9999 setzt die Passwort-Lebensdauer auf den harten Wert, den STIG und CIS fordern. Solche Snippets lassen sich in GitLab CI, GitHub Actions oder Azure DevOps einbetten – jeder Pipeline-Run prüft dann automatisch gegen die DISA-STIG-IDs (V-258787, V-258788) und die CIS-Benchmarks.

Die Open-Source-Community pflegt fertige Profiles für Tenable und STIG Viewer, die per API abgefragt werden. Ergebnisse landen als JUnit-XML oder SARIF im CI-Dashboard; Abweichungen brechen den Build. So entsteht Continuous Hardening statt Punkt-in-Zeit-Audit. StarWind und Netzpalaver betonen zudem, dass geteilte Datastores bei Ransomware als Einfallstor dienen – automatisierte Drift-Erkennung schließt diese Lücke.

Wichtig: Die Skripte nur aus vertrauenswürdigen Repos ziehen, Signaturen prüfen und in einer Staging-Umgebung testen, bevor sie auf Produktions-Hosts laufen.

Schritt 8: Ransomware-Schutz durch Segmentierung & Immutable Backups

Ein einzelner kompromittierter ESXi-Host reicht Angreifern, um sämtliche VMs auf gemeinsamem Storage zu verschlüsseln. Geteilte Datastores werden so zum zentralen Risiko. Netzwerkseitig trennen dedizierte VLANs oder NSX-Segmente Management-, vMotion- und Backup-Traffic strikt voneinander. Storage-seitig verhindern separate Datastores pro Tenant oder Workload-Klasse, dass sich Malware lateral ausbreitet.

Backups müssen unveränderbar sein. Object Lock auf S3-kompatiblem Storage oder Veeam Hardened Repository mit Immutability-Flag schützen Snapshots vor Löschung und Verschlüsselung – selbst bei kompromittierten Backup-Accounts. Regelmäßige Restore-Tests auf isolierten Test-Hosts validieren die Wiederherstellbarkeit unter Realbedingungen. Der Broadcom Hardening Guide empfiehlt zudem, SSH und ESXi Shell dauerhaft zu deaktivieren und Lockdown Mode durchzusetzen. Ergänzend liefert die Community-Diskussion zu VCF-Hardening praxisnahe Hinweise zur Segmentierung in Cloud-Foundation-Umgebungen. Herstellerunabhängige Security-Blogs wie Sophos oder Google Cloud Threat Intelligence bestätigen: Segmentierung plus Immutable Backups bilden die wirksamste Barriere gegen Hypervisor-Ransomware.

Schritt 9: Kontinuierliches Monitoring & Threat Hunting (VIB-Signaturen, Anomalien)

Ein einmaliger Hardening-Check reicht nicht. Angreifer manipulieren VIB-Pakete oder driften Konfigurationen schrittweise ab. Die Google/VMware Detection-Scripts scannen CommunitySupported VIBs auf verdächtige Signaturen und erkennen anomale Einstellungen, die signierte Pakete nicht ausschließen. Ergebnisse fließen direkt in den SIEM: Log-Quellen wie hostd, vobd und syslog liefern Events für Korrelationsregeln, die Config-Drift bei Firewall-Regeln, SSH-Ciphers oder Lockdown-Mode melden.

Tenable Retina CS automatisiert CIS-Benchmark-Audits per API und plant Remediation-Jobs über PowerCLI. So wird Hardening zum fortlaufenden Zyklus statt Punkt-in-Zeit-Prüfung. Ergänzend mappt der ISO-27001-Leitfaden von Leonx Monitoring-Kontrollen auf Risikobehandlung und Lieferantenmanagement. Alerts bei unerwarteten VIB-Installationen, geänderten Scratch-Partitionen oder deaktiviertem Audit-Logging triggern Playbooks, die Hosts in Quarantäne-VLANs verschieben und forensische Snapshots erzeugen. Ein praxisnaher Admin-Guide fasst Skripte für tägliche Baseline-Vergleiche zusammen. Damit schließt sich der Kreis: Härten, überwachen, nachjustieren – kontinuierlich.