Diese Sicherheitskontrollen stellen einen grundlegenden Satz bewährter Methoden für die ESXi-Sicherheit bereit. Sie sind dahingehend gegliedert, dass die Vor- und Nachteile der Implementierung der Kontrolle verdeutlicht werden. Die meisten Kontrollen stellen erweiterte Systemeinstellungen dar. Erweiterte Systemeinstellungen können Sie entweder über die bereitgestellte PowerCLI ändern oder unter vSphere Client ().
Verwendete Variable
Die in diesem Abschnitt aufgeführten PowerCLI-Befehle verwenden folgende Variablen:
- $ESXi = "host_name"
- $vmkernel_interface = "vmkernel_adapter"
Verweigern des Zugriffs des DCUI-Kontos
Der ESXi-Host muss dem DCUI-Benutzerkonto den Shell-Zugriff verweigern.
Das DCUI-Benutzerkonto wird zur Prozessisolierung für die DCUI selbst verwendet. Um die Angriffsfläche zu verringern, deaktivieren Sie für das DCUI-Benutzerkonto den Shell-Zugriff.
Annotations.WelcomeMessage
Konfiguriert den Text der Anmeldenachricht, die auf dem VMware Host Client und der DCUI angezeigt wird.
ESXi bietet die Möglichkeit, eine Anmeldenachricht anzuzeigen. Die Anmeldenachricht wird beispielsweise dazu verwendet, Eindringlinge über die Rechtswidrigkeit ihrer Aktivitäten zu informieren und autorisierten Benutzern mitzuteilen, welche Erwartungen und Verpflichtungen sie bei der Verwendung des Systems erfüllen und akzeptieren müssen.
Config.HostAgent.vmacore.soap.sessionTimeout
Konfiguriert für die vSphere API eine Zeitüberschreitung für die Sitzung.
Diese trägt dazu bei, potenzielle Sicherheitsrisiken zu verringern, indem sichergestellt wird, dass unbeaufsichtigte Sitzungen nicht unbefristet offen bleiben, wodurch sie von nicht autorisierten Benutzern oder Schadsoftware ausgenutzt werden könnten.
Config.Etc.issue
Konfiguriert den Text des Banners, das angezeigt wird, wenn ein Benutzer mittels SSH eine Verbindung zu einem ESXi-Host herstellt.
ESXi bietet die Möglichkeit, Banner für SSH-Verbindungen anzuzeigen. Ein Banner wird beispielsweise verwendet, um Eindringlinge über die Rechtswidrigkeit ihrer Aktivitäten zu informieren und autorisierten Benutzern mitzuteilen, welche Erwartungen und Verpflichtungen sie bei der Nutzung des Systems einhalten und akzeptieren müssen. Lassen Sie den SSH-Dienst deaktiviert, solange Sie keine Fehlerbehebung durchführen. Eine Inkonsistenz der Implementierung von ESXi und vCenter Server erfordert, dass „issue“ in Config.Etc.issue klein geschrieben wird, damit beide Szenarien funktionieren.
- Beispiel für PowerCLI-Befehlsstandardisierung
-
Get-VMHost -Name $ESXi | Get-AdvancedSetting Config.Etc.issue | Set-AdvancedSetting -Value "****************************************************************************`n* Authorized users only. Actual or attempted unauthorized use of this *`n* system is prohibited and may result in criminal, civil, security, or *`n* administrative proceedings and/or penalties. Use of this information *`n* system indicates consent to monitoring and recording, without notice *`n* or permission. Users have no expectation of privacy. Any information *`n* stored on or transiting this system, or obtained by monitoring and/or *`n* recording, may be disclosed to law enforcement and/or used in accordance *`n* with Federal law, State statute, and organization policy. If you are not *`n* an authorized user of this system, exit the system at this time. *`n****************************************************************************`n"
Deaktivieren des Shell-Zugriffs für vpxuser
Der ESXi-Host muss den Shell-Zugriff für das vpxuser-Konto verweigern.
vCenter Server erstellt das vpxuser-Konto, wenn ein ESXi-Host erstmalig angehängt wird. Das vpxuser-Konto wird anschließend für die privilegierte Authentifizierung bei ESXi verwendet. Während vCenter Server das Kennwort für das vpxuser-Konto automatisch in einem mit der Option VirtualCenter.VimPasswordExpirationInDays festgelegten Intervall rotiert, verfügt das vpxuser-Konto auch über Shell-Zugriff. Deaktivieren Sie das vpxuser-Konto, um die Angriffsfläche zu verringern.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Benutzerkonten ohne Shell-Zugriff können den Shell-Zugriff anderer Benutzer nicht neu konfigurieren. Dies gilt unabhängig von ihrer Berechtigungsstufe. Da vCenter Server eine Verbindung mit einem ESXi-Host über das vpxuser-Konto herstellt, kann dieses nach dem Deaktivieren des Shell-Zugriffs für vpxuser nicht mehr verwendet werden, um diese Kontoeinstellungen für andere Konten zu ändern. Weitere Neukonfigurationen müssen für jeden Host einzeln bei Verwendung eines autorisierten Kontos erfolgen.
vCenter Server muss den vSphere Authentication Proxy verwenden, um das Speichern von Active Directory-Anmeldedaten zu vermeiden
Mit dem vSphere Authentication Proxy kann vCenter Server eine Verbindung mit Active Directory-Entitäten herstellen und diese verwalten, ohne dass Active Directory-Anmeldedaten direkt gespeichert werden müssen. Dies verringert das Risiko einer Offenlegung oder eines Missbrauchs von Anmeldedaten.
DCUI.Access
Der ESXi-Host muss über eine exakte DCUI.Access-Liste verfügen.
Legt die Liste der Benutzerausnahmen für den Sperrmodus so fest, dass diese eine exakte Liste von Benutzern enthält, und stellt sicher, dass nur autorisierte Benutzer direkten DCUI-Zugriff auf den ESXi-Host haben, wenn der Sperrmodus aktiviert ist.
Der Root-Benutzer kann nicht aus der Liste entfernt werden.
Verwenden Sie die Liste der Benutzerausnahmen für den Sperrmodus, um den Zugriff auf die ESXi Shell und SSH zu kontrollieren. Weitere Informationen hierzu finden Sie unter Vorhandenseins einer exakten Liste der ausgenommenen Benutzer auf dem ESXi-Host.
Vorhandenseins einer exakten Liste der ausgenommenen Benutzer auf dem ESXi-Host
Der ESXi-Host muss über eine exakte Liste der ausgenommenen Benutzer verfügen.
In der Liste „Benutzerausnahmen für den Sperrmodus“ aufgeführte Benutzer verlieren ihre Berechtigungen nicht, wenn der Host in den Sperrmodus wechselt. Diese Situation kann gegebenenfalls den Zweck des Sperrmodus zunichte machen.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Potenzieller Verlust des Administratorzugriffs auf ESXi-Hosts. Stellen Sie vor dem Konfigurieren des Sperrmodus sicher, dass ESXi-Hosts an vCenter Server angehängt sind und dass Zugriffslisten und Ausnahmelisten konfiguriert werden.
Aktivieren des normalen Sperrmodus zur Beschränkung des Zugriffs auf ESXi
Die Aktivierung des Sperrmodus deaktiviert den direkten Zugriff auf einen ESXi-Host. Der Sperrmodus erfordert, dass vCenter Server den ESXi-Host direkt verwaltet.
Eine Beschränkung des Zugriffs auf diesem Weg stellt sicher, dass vCenter Server Rollen und Berechtigungen erzwingt. Benutzer können diese Rollen und Berechtigungen auch nicht umgehen, indem sie sich direkt bei einem ESXi-Host anmelden. Indem sämtliche Interaktionen über vCenter Server erfolgen müssen, verringert sich das Risiko, dass Benutzer versehentlich erhöhte Berechtigungen erlangen oder Aufgaben ausführen, für die sie nicht ordnungsgemäß überwacht werden.
Benutzer, die in der Liste „Ausnahme für Benutzer“ der einzelnen ESXi-Hosts aufgeführt sind, sind berechtigt, den Sperrmodus außer Kraft zu setzen und sich anzumelden. Standardmäßig sind in der Liste der ausgenommenen Benutzer keine Benutzer enthalten.
Mögliche Einstellungen für den Sperrmodus sind „Deaktiviert“, „Normal“ und „Streng“. Wenn der Sperrmodus auf „Streng“ festgelegt ist und der ESXi-Host den Kontakt zu vCenter Server verliert, können Sie diesen erst wieder verwalten, nachdem die Verbindung wiederhergestellt wurde. Wenn Sie die Verbindung nicht wiederherstellen können, müssen Sie den ESXi-Host neu erstellen. In der Regel geht der Sperrmodus „Streng“ über die Anforderungen der meisten Bereitstellungen hinaus. Der Sperrmodus „Normal“ ist in den meisten Fällen ausreichend.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Potenzieller Verlust des Administratorzugriffs auf Hosts. Stellen Sie vor dem Konfigurieren des Sperrmodus sicher, dass ESXi-Hosts an vCenter Server angehängt sind und dass Zugriffslisten und Ausnahmelisten konfiguriert werden.
Syslog.global.auditRecord.storageEnable
Konfiguriert Sie den ESXi-Host für das lokale Speichern von Prüfdatensätzen.
Sie müssen auf ESXi-Hosts die Protokollierung der Überwachungsdatensätze aktivieren.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Für Protokolle wird zusätzlicher Speicherplatz benötigt.
Syslog.global.auditRecord.storageCapacity
Auf ESXi-Hosts müssen Sie ausreichend Speicherkapazität für die Überwachungsdatensätze einer Woche aktivieren.
Wenn ein Remote-Speichergerät für Prüfdatensätze vorhanden ist, muss unbedingt sichergestellt werden, dass die lokale Speicherkapazität ausreicht, um Prüfdatensätze aufzunehmen, die sich während möglicher Unterbrechungen der Datenübermittlung auf dem Gerät ansammeln. Dadurch wird sichergestellt, dass in Zeiten, in denen der Remote-Speicher nicht verfügbar ist, keine Prüfdatensätze verloren gehen oder überschrieben werden. Dies sichert die nahtlose Kontinuität des Prüfpfads und sorgt für die Einhaltung der Compliance-Anforderungen.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Für Protokolle wird zusätzlicher Speicherplatz benötigt.
ScratchConfig.CurrentScratchLocation and Syslog.global.auditRecord.storageDirectory
Konfiguriert einen dauerhaften Protokollspeicherort für alle lokal auf dem ESXi-Host gespeicherten Überwachungsdatensätze.
Sie können ESXi so konfigurieren, dass Prüfdatensätze in einem In-Memory-Dateisystem gespeichert werden. Dies passiert, wenn das Verzeichnis „/scratch“ des Hosts mit „/tmp/scratch“ verknüpft ist. Anschließend werden immer nur die Datensätze eines einzigen Tages gespeichert. Darüber hinaus werden Prüfdatensätze bei jedem Neustart neu initialisiert. Dies stellt ein Sicherheitsrisiko dar, da die auf dem Host protokollierte Benutzeraktivität nur temporär gespeichert wird und bei Neustarts verloren geht. Dies kann auch die Überprüfung und die Überwachung von Ereignissen sowie die Diagnose von Problemen erschweren. Konfigurieren Sie die Protokollierung von ESXi-Host-Überwachungsdatensätzen immer in einem persistenten Datenspeicher.
Sie können ermitteln, ob der Scratch-Datenträger temporär oder persistent ist, indem Sie die erweiterte Einstellung ScratchConfig.CurrentScratchLocation abfragen. Wenn bei der Abfrage „/tmp/scratch“ zurückgegeben wird, handelt es sich um einen temporären Datenspeicher. In diesem Fall sollten Sie den Speicher für die Prüfdatensätze erneut einem persistenten Gerät zuordnen.
Der Speicher darf kein vSAN-Datenspeicher sein. Wenn Ihr einziger lokaler, Nicht-vSAN-Speicher ein SD- oder USB-Medium ist (das bei wiederholtem Schreiben von Protokollen unzuverlässig werden kann), sollten Sie die Protokolle auf der Ramdisk belassen und stattdessen einen Host für die Remoteprotokollierung konfigurieren. Dokumentieren Sie die Entscheidung und die Gründe für zukünftige Prüfungen.
- Werte
-
Standardwert der Installation:
ScratchConfig.CurrentScratchLocation: Hängt vom Startgerät ab
Syslog.global.auditRecord.storageDirectory: /scratch/auditLog
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Für Protokolle wird zusätzlicher Speicherplatz benötigt.
- PowerCLI-Befehlsbeurteilung
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $ESXcli.system.syslog.config.get.Invoke() | Select LocalLogOutput,LocalLogOutputIsPersistent # If your LocalLogOutput is set to a directory in /scratch, and LocalLogOutputIsPersistent is true, that means your boot device is of a type and size that makes /scratch persistent. Verify that your audit storage is also on /scratch, and that /scratch points to a VMFS datastore: Get-VMHost -Name $ESXi | Get-AdvancedSetting ScratchConfig.CurrentScratchLocation Get-VMHost -Name $ESXi | Get-AdvancedSetting Syslog.global.auditRecord.storageDirectory
Syslog.global.auditRecord.remoteEnable
Konfiguriert den ESXi-Host für die Übertragung von Überwachungsprotokollen auf einen Remotehost.
Syslog.global.logFiltersEnable
Aktiviert die Protokollfilterung auf dem ESXi-Host.
Sie können Protokollfilter erstellen, um die Anzahl doppelter Einträge in den Protokollen zu reduzieren und bestimmte Protokollereignisse komplett zu sperren.
LocalLogOutputIsPersistent, ScratchConfig.CurrentScratchLocation und Syslog.global.logDir
Konfiguriert die dauerhafte Protokollierung aller lokal gespeicherten Protokolle auf dem ESXi-Host.
Sie können ESXi so konfigurieren, dass Protokolldateien in einem speicherresidenten Dateisystem gespeichert werden. Dies passiert, wenn das Verzeichnis „/scratch“ des Hosts mit „/tmp/scratch“ verknüpft ist. Anschließend werden immer nur die Protokolle eines einzigen Tages gespeichert. Darüber hinaus werden Protokolldateien bei jedem Neustart neu initialisiert. Dies stellt ein Sicherheitsrisiko dar, da die auf dem Host protokollierte Benutzeraktivität nur temporär gespeichert wird und bei Neustarts verloren geht. Das kann auch die Überprüfung und die Überwachung von Ereignissen sowie die Diagnose von Problemen erschweren. Konfigurieren Sie auf dem ESXi-Host die Protokollierung immer in einem persistenten Datenspeicher.
Sie können ermitteln, ob der Scratch-Datenträger temporär oder persistent ist, indem Sie den erweiterten Parameter ScratchConfig.CurrentScratchLocation abfragen. Wenn bei der Abfrage „/tmp/scratch“ zurückgegeben wird, handelt es sich um einen temporären Datenspeicher. In diesem Fall sollten Sie den Speicher für die Prüfdatensätze erneut einem persistenten Gerät zuordnen.
Der Speicher darf kein vSAN-Datenspeicher sein, es sei denn, Sie legen Syslog.global.vsanBacking fest, was Einschränkungen und Abhängigkeiten mit sich bringt. Wenn Ihr einziger lokaler, Nicht-vSAN-Speicher ein SD- oder USB-Medium ist (das bei wiederholtem Schreiben von Protokollen unzuverlässig werden kann), sollten Sie die Protokolle auf der Ramdisk belassen und stattdessen einen Host für die Remoteprotokollierung konfigurieren. Dokumentieren Sie die Entscheidung und die Gründe für zukünftige Prüfungen.
- Werte
-
Standardwert der Installation: ScratchConfig.CurrentScratchLocation: Vom Startgerät abhängig
Syslog.global.logDir: /scratch/log
- PowerCLI-Befehlsbeurteilung
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $ESXcli.system.syslog.config.get.Invoke() | Select LocalLogOutput,LocalLogOutputIsPersistent # If your LocalLogOutput is set to a directory in /scratch, and LocalLogOutputIsPersistent is true, that means your boot device is of a type and size that makes /scratch persistent. Verify that your log storage is also on /scratch, , and that /scratch points to a VMFS datastore: Get-VMHost -Name $ESXi | Get-AdvancedSetting ScratchConfig.CurrentScratchLocation Get-VMHost -Name $ESXi | Get-AdvancedSetting Syslog.global.logDir
Syslog.global.logHost
Konfiguriert die Remoteprotokollierung.
Wenn Sie die Remoteprotokollierung auf einem zentralen Protokoll-Host konfigurieren, stellen Sie für ESXi-Protokolle einen sicheren, zentralisierten Speicher bereit. Das Sammeln von Host-Protokolldateien auf einem zentralen Host eröffnet Ihnen die Möglichkeit, alle Hosts mit einem einzigen Tool zu überwachen. Sie können auch aggregierte Analysen durchführen und nach Elementen wie koordinierten Angriffen auf mehrere Hosts suchen. Die Protokollierung auf einem sicheren, zentralen Protokollserver unterstützt das Verhindern von Protokollmanipulation und bietet außerdem eine langfristige Prüfungsaufzeichnung.
Syslog.global.certificate.checkSSLCerts
Verifiziert Zertifikate für TLS.
Der ESXi-Host muss Zertifikate für Endpoints für die TLS-Remoteprotokollierung verifizieren. Mit TLS-Zertifikaten kann sichergestellt werden, dass ein Endpoint authentifiziert und vertrauenswürdig ist.
Syslog.global.certificate.strictX509Compliance
Führt eine strenge x509-Verifizierung für TLS-fähige Remoteprotokollierungs-Endpoints durch.
Der ESXi-Host muss eine strenge x509-Verifizierung für TLS-fähige Remoteprotokollierungs-Endpoints anwenden. Die Einstellung Syslog.global.certificate.strictX509Compliance führt während der Verifizierung zusätzliche Gültigkeitsprüfungen der CA-Root-Zertifikate durch.
Mem.MemEagerZero
Aktiviert die Vernichtung flüchtiger Schlüssel.
Standardmäßig setzt ESXi Seiten, denen virtuelle Maschinen, Benutzerbereichsanwendungen und Kernel-Threads zugeteilt wurden, im Moment der Zuteilung auf Null. Dadurch wird sichergestellt, dass keine nicht auf Null gesetzte Seiten für virtuelle Maschinen oder Benutzerbereichsanwendungen offengelegt werden. Diese Maßnahme dient dazu, zu verhindern, dass kryptografische Schlüssel von virtuellen Maschinen oder Benutzerwelten für andere Clients offengelegt werden.
Wenn der Arbeitsspeicher jedoch nicht wiederverwendet wird, können diese Schlüssel über einen längeren Zeitraum im Arbeitsspeicher des Hosts verbleiben. Um dies zu beheben, können Sie die Einstellung MemEagerZero dahingehend konfigurieren, dass das Nullsetzen von Benutzerwelt- und Gast-Arbeitsspeicherseiten erzwungen wird, wenn ein Benutzerwelt-Prozess oder Gast aussteigt. Bei Kernel-Threads werden Speicherbereiche, die Schlüssel enthalten, auf Null gesetzt, sobald das Geheimnis nicht mehr benötigt wird.
Prüfung auf aktive Wartung der ESXi-Version
Stellen Sie sicher, dass die ESXi-Version nicht den VMware-Status „Ende des allgemeinen Supports“ erreicht hat.
Aktivieren von Zeitsynchronisierungsquellen
Auf dem ESXi-Host müssen die Zeitsynchronisierungsdienste aktiviert sein und ausgeführt werden.
Verschlüsselung, Überwachungsprotokollierung, Clustervorgänge sowie Reaktionen auf Vorfälle und Forensik basieren auf einer synchronisierten Uhrzeit. Um sicherzustellen, dass die Uhrzeit über Dienste und Vorgänge hinweg synchronisiert wird, aktivieren Sie zunächst auf dem Host die Dienste NTP und/oder PTP und stellen Sie sicher, dass diese ausgeführt werden.
- Beispiel für PowerCLI-Befehlsstandardisierung
-
Get-VMHostService -VMHost $ESXi -ErrorAction:Stop | Where-Object{$_.Key -eq "ntpd"} | Set-VMHostService -policy "on" -Confirm:$false Get-VMHostService -VMHost $ESXi -ErrorAction:Stop | Where-Object{$_.Key -eq "ntpd"} | Restart-VMHostService -Confirm:$false
Konfigurieren zuverlässiger Zeitsynchronisierungsquellen
Für den ESXi-Host müssen zuverlässige Zeitsynchronisierungsquellen konfiguriert werden.
Verschlüsselung, Überwachungsprotokollierung, Clustervorgänge sowie Reaktionen auf Vorfälle und Forensik sind auf eine synchronisierte Uhrzeit angewiesen. Für NTP (Network Time Protocol) müssen mindestens vier Quellen verfügbar sein. Wenn Sie sich zwischen zwei Quellen oder einer Quelle entscheiden müssen, sollten Sie eine Quelle vorziehen.
PTP (Precision Time Protocol) ist eine Alternative zu NTP, die eine Zeitgenauigkeit unter einer Millisekunde bietet. Die Architektur von PTP unterscheidet sich von der von NTP und bietet nicht dieselbe Resilienz bei einem Ausfall des primären Servers. Ziehen Sie in Erwägung, NTP als Backup-Quelle für PTP zu konfigurieren, damit weiterhin eine Zeitquelle verfügbar ist, wenn auch mit geringerer Genauigkeit.
Verwendung der TLS-Verschlüsselung
Der ESXi-Host muss durch Aktivierung moderner TLS-Verschlüsselungen die Vertraulichkeit und Integrität der Übertragungen sicherstellen.
Ab ESXi 8.0 Update 3 konfigurieren TLS-Profile die Client- und Server-TLS-Einstellungen so, dass nur starke Verschlüsselungen verwendet werden. Mit den folgenden Befehlen können Sie die gesamte Verschlüsselungsliste und alle Verschlüsselungssuites anzeigen:
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $arguments = $ESXcli.system.tls.server.get.CreateArgs() $arguments.showprofiledefaults = $true $arguments.showcurrentbootprofile = $true $ESXcli.system.tls.server.get.invoke($arguments)
Nach Änderungen am TLS-Profil müssen Sie den ESXi-Host neu starten. (Im vSphere Client wird der Host mit dem Suffix „Neustart erforderlich“ angezeigt.)
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Änderungen an den Verschlüsselungssuites wirken sich auf die Konnektivität mit externen Systemen aus. Sie müssen den Host neu starten, damit diese Änderung des TLS-Profils wirksam wird.
UserVars.ESXiVPsDisabledProtocols
Der ESXi-Host muss die höchste unterstützte TLS-Version aktivieren.
ESXi 8.0 aktiviert standardmäßig TLS 1.2. Im Bedarfsfall können jedoch andere Protokolle aktiviert werden. Ab ESXi 8.0 Update 3 ist standardmäßig TLS 1.3 aktiviert.
Konfigurieren der TPM-basierten Verschlüsselung
Der ESXi-Host muss eine TPM-basierte Konfigurationsverschlüsselung erfordern.
Die Konfiguration eines ESXi-Hosts besteht aus Konfigurationsdateien für jeden Dienst, der auf dem Host ausgeführt wird. Die Konfigurationsdateien befinden sich in der Regel im Verzeichnis /etc, sie können sich aber auch in anderen Namespaces befinden. Die Konfigurationsdateien enthalten Laufzeitinformationen über den Status der Dienste. Im Laufe der Zeit können sich die Standardwerte in den Konfigurationsdateien ändern, z. B. wenn die Einstellungen auf dem ESXi-Host geändert werden.
Ein Cron-Auftrag sichert die ESXi-Konfigurationsdateien regelmäßig, wenn ESXi ordnungsgemäß heruntergefahren wird, oder bei Bedarf, und erstellt eine archivierte Konfigurationsdatei in der Startbank. Wenn ESXi neu startet, liest das System die archivierte Konfigurationsdatei und stellt den Zustand wird wieder her, in dem sich ESXi befand, als die Sicherung erstellt wurde.
Vor vSphere 7.0 Update 2 ist die archivierte ESXi-Konfigurationsdatei nicht verschlüsselt. In vSphere 7.0 Update 2 und höher ist die archivierte Konfigurationsdatei verschlüsselt. Wenn der ESXi-Host mit einem Trusted Platform Module (TPM) konfiguriert ist, wird das TPM zum „Versiegeln“ der Konfiguration für den Host verwendet, was eine starke Sicherheitsgarantie und zusätzlichen Schutz vor Online-Angriffen bietet.
Die Konfigurationsverschlüsselung verwendet das physische TPM, sofern es zum Zeitpunkt der Installation oder des Upgrades verfügbar ist und unterstützt wird. Wenn das TPM später hinzugefügt oder aktiviert wird, müssen Sie den ESXi-Host explizit neu konfigurieren, damit er das neu verfügbare TPM verwendet. Nachdem die TPM-Verschlüsselung der Konfiguration aktiviert wurde, kann sie nicht wieder deaktiviert werden.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Die Verwendung von Secure Boot und durch TPM erzwungener Konfigurationsverschlüsselung machen herkömmliche Versuche zur Wiederherstellung des Root-Passworts unbrauchbar. Stellen Sie sicher, dass Sie den Zugriff auf ESXi-Administratorkonten nicht verlieren.
Prüfen der ESXi-Software auf Aktualität
Indem Sie über ESXi-Patches auf dem aktuellen Stand bleiben, reduzieren Sie Schwachstellen im Hypervisor.
Ein versierter Angreifer kann bekannte Schwachstellen ausnutzen, wenn er versucht, auf einen ESXi-Host zuzugreifen oder seine Berechtigungen zu erhöhen. Aktualisieren Sie immer zuerst vCenter Server, wenn ein Update verfügbar ist. Aktualisieren Sie danach ESXi.
VMkernel.Boot.execInstalledOnly
Führen Sie nur von einem VIB bereitgestellte Binärdateien aus.
ESXi führt Integritätsprüfungen von VIBs durch, die auf der Akzeptanzebene basieren. Indem ESXi angewiesen wird, nur solche Binärdateien auszuführen, die aus einem gültigen auf dem Host installierten VIB stammen, wird Angreifern die Verwendung vorgefertigter Toolkits für einen Angriff erschwert und die Wahrscheinlichkeit einer Erkennung verbessert.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Nicht signierte Software von Drittanbietern wird möglicherweise nicht installiert oder ausgeführt.
Deaktivieren von Verwaltungsdiensten auf VMkernel-Adaptern
Stellen Sie sicher, dass für vSAN, vMotion und andere dedizierte VMkernel-Adapter keine Verwaltungsdienste aktiviert sind.
Für spezielle Verwendungen vorgesehene VMkernel-Netzwerkschnittstellen können mit Verwaltungsfunktionen konfiguriert werden, die gegebenenfalls die Netzwerkisolierung und die Sicherheitsmaßnahmen konterkarieren. Aktivieren Sie Verwaltungsdienste nur auf VMkernel-Schnittstellen, die für die Verwaltung vorgesehen sind.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Für einige von Drittanbietern verwaltete Lösungen ist es möglicherweise erforderlich, dass Sie die Verwaltungsdienste auf VMkernel-Adaptern aktivieren.
Konfigurieren der ESXi-Firewall für das Blockieren von Datenverkehr
Sie müssen die ESXi-Host-Firewall so konfigurieren, dass der Netzwerkdatenverkehr standardmäßig blockiert wird.
Stellen Sie sicher, dass der gesamte eingehende und ausgehende Netzwerkdatenverkehr blockiert wird, sofern er nicht ausdrücklich erlaubt ist. Das verringert die Angriffsfläche und verhindert den nicht autorisierten Zugriff auf den Host.
Konfigurieren der ESXi-Firewall für autorisierte Netzwerke
Konfigurieren Sie die ESXi-Firewall so, dass nur Datenverkehr von autorisierten Netzwerken zugelassen wird.
Stellen Sie sicher, dass der gesamte eingehende und ausgehende Netzwerkdatenverkehr blockiert wird, sofern er nicht ausdrücklich erlaubt ist. Das verringert die Angriffsfläche und verhindert den nicht autorisierten Zugriff auf den ESXi-Host.
Ab vSphere 8.0 Update 2 werden Firewallregeln als Besitz von „user“ oder „system“ kategorisiert, wobei nur benutzereigene Regeln konfiguriert werden können. In vSphere 8 Update 2b und PowerCLI 13.2.1 gibt es zusätzliche abfragbare Parameter, um die Einstellung und Prüfung auf konfigurierbare Regeln zu automatisieren.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Eine Firewall ist recht simpel und ähnelt den ACLs von Routern. Gegebenenfalls müssen Sie reflexive Regeln neu konfigurieren.
- PowerCLI-Befehlsbeurteilung
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $list = $ESXcli.network.firewall.ruleset.list.Invoke() | Where {($_.AllowedIPconfigurable -eq $true) -and ($_.EnableDisableconfigurable -eq $true)} | Select -ExpandProperty Name $arguments = $ESXcli.network.firewall.ruleset.allowedip.list.CreateArgs() foreach ($rule in $list) { $arguments.rulesetid = $rule $ESXcli.network.firewall.ruleset.allowedip.list.Invoke($arguments) }
- Beispiel für PowerCLI-Befehlsstandardisierung
-
# Customize this example for your environment. $ESXcli = Get-EsxCli -VMHost $ESXi -V2 # Deactivate firewall temporarily so we don't lose connectivity $arguments = $ESXcli.network.firewall.set.CreateArgs() $arguments.enabled = $false $ESXcli.network.firewall.set.Invoke($arguments) # Unset the "allow all" flag $arguments = $ESXcli.network.firewall.ruleset.set.CreateArgs() $arguments.allowedall = $false $arguments.rulesetid = "sshServer" $ESXcli.network.firewall.ruleset.set.Invoke($arguments) # Add an IP range $arguments = $ESXcli.network.firewall.ruleset.allowedip.add.CreateArgs() $arguments.ipaddress = "192.168.0.0/16" $arguments.rulesetid = "sshServer" $ESXcli.network.firewall.ruleset.allowedip.add.Invoke($arguments) # Enable the firewall $arguments = $ESXcli.network.firewall.set.CreateArgs() $arguments.enabled = $true $ESXcli.network.firewall.set.Invoke($arguments)
Festlegen der Richtlinie für gefälschte Übertragungen auf „Ablehnen“
Legen Sie in der Richtlinie für gefälschte Übertragungen sowohl für den vSphere Standard-Switch als für dessen Portgruppen „Ablehnen“ fest.
Wenn das Betriebssystem der virtuellen Maschine die MAC-Adresse ändert, kann es jederzeit Frames mit einer imitierten Quell-MAC-Adresse senden. Durch das Imitieren einer MAC-Adresse kann ein Betriebssystem böswillige Angriffe auf die Geräte in einem Netzwerk durchführen, indem es die Identität eines vom empfangenden Netzwerk autorisierten Netzwerkadapters annimmt. Wenn die Option „Gefälschte Übertragungen“ auf „Akzeptieren“ festgelegt ist, führt ESXi keinen Vergleich zwischen der Quell-MAC-Adresse und der geltenden MAC-Adresse durch. Zum Schutz vor MAC-Imitation können Sie die Option „Gefälschte Übertragungen“ auf „Ablehnen“ einstellen. Dann vergleicht der Host die Quell-MAC-Adresse, die vom Gastbetriebssystem übertragen wird, mit der geltenden MAC-Adresse für den Adapter der virtuellen Maschine, um festzustellen, ob sie übereinstimmen. Wenn die Adressen nicht übereinstimmen, verwirft der ESXi-Host das Paket.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Einige Arbeitslasten, beispielsweise geclusterte Anwendungen sowie Netzwerkgeräte und -funktionen, nutzen diese Techniken im normalen Betrieb. Im Bedarfsfall können Sie eine separate Portgruppe konfigurieren, die dieses Verhalten zulässt, und daran ausschließlich autorisierte virtuelle Maschinen anhängen.
Festlegen der Richtlinie „MAC-Adressänderungen“ auf „Ablehnen“
Legen Sie die Richtlinie „MAC-Adressänderungen“ auf dem vSphere Standard-Switch und den dazu gehörigen Portgruppen auf „Ablehnen“ fest.
Wenn das Betriebssystem der virtuellen Maschine die MAC-Adresse ändert, kann es Frames mit einer imitierten Quell-MAC-Adresse senden. Damit kann es böswillige Angriffe auf die Geräte in einem Netzwerk durchführen, indem es die Identität eines vom empfangenden Netzwerk autorisierten Netzwerkadapters annimmt. Um zu verhindern, dass virtuelle Maschinen ihre geltende MAC-Adresse ändern, sollten Maßnahmen ergriffen werden, die die Stabilität der MAC-Adresse erzwingen oder die Möglichkeit zum Ändern von MAC-Adressen einschränken. Dies trägt dazu bei, das Risiko einer MAC-Imitation und potenzieller böswilliger Aktivitäten zu mindern.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Einige Arbeitslasten, beispielsweise geclusterte Anwendungen und Netzwerkgeräte und -funktionen, nach MAC-Adresse lizenzierte Anwendungen und das vCenter Server-Upgrade mit reduzierter Ausfallzeit nutzen diese Techniken im normalen Betrieb. Im Bedarfsfall können Sie eine separate Portgruppe konfigurieren, die dieses Verhalten zulässt, und daran ausschließlich autorisierte virtuelle Maschinen anhängen.
Festlegen der Richtlinie „Promiskuitiver Modus“ auf „Ablehnen“
Legen Sie die Richtlinie „Promiskuitiver Modus“ auf dem vSphere Standard-Switch und dessen Portgruppen auf „Ablehnen“ fest.
Wenn für eine Portgruppe „Promiskuitiver Modus“ aktiviert ist, können alle mit dieser Portgruppe verbundenen virtuellen Maschinen potenziell alle über diese Portgruppe übertragenen Pakete lesen, unabhängig vom beabsichtigten Empfänger. Bedenken Sie die möglichen Auswirkungen und Designaspekte, bevor Sie den Standardwert in „Promiskuitiver Modus“ ändern.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Bestimmte Arbeitslasten und Arbeiten, z. B. DHCP-Server, Netzwerkgeräte und die Sicherheitsüberwachung, integrieren diese Techniken in ihrem regelmäßigen Betrieb. Im Bedarfsfall können Sie eine separate Portgruppe konfigurieren, die dieses Verhalten zulässt, und daran ausschließlich autorisierte virtuelle Maschinen anhängen.
Beschränken von Virtual Guest Tagging (VGT) auf Standard-Switches
Der ESXi-Host muss die Verwendung von Virtual Guest Tagging (VGT) auf Standard-Switches beschränken.
Wenn eine Portgruppe auf „VLAN 4095“ festgelegt ist, übergibt der vSwitch alle Netzwerk-Frames an die angehängten virtuellen Maschinen, ohne die VLAN-Tags zu ändern. Dies wird in vSphere als VGT bezeichnet. Die virtuelle Maschine muss die VLAN-Informationen unter Verwendung eines 802.1Q-Treibers selbst im Betriebssystem verarbeiten.
VLAN 4095 darf nur implementiert werden, wenn die angehängten virtuellen Maschinen spezifisch autorisiert wurden und in der Lage sind, VLAN-Tags selbsttätig zu verwalten. Wenn VLAN 4095 nicht ordnungsgemäß aktiviert ist, kann dies zu einem Denial-of-Service führen oder einer virtuellen Maschine die Interaktion mit Datenverkehr in einem nicht autorisierten VLAN ermöglichen.
Aktivieren der Secure Boot-Erzwingung
Secure Boot (sicherer Start) ist Bestandteil des UEFI-Firmwarestandards. Bei aktiviertem UEFI Secure Boot lädt ein Host einen UEFI-Treiber oder ESXi-Apps nur dann, wenn der Bootloader des Betriebssystems über ein gültige digitale Signatur verfügt. Secure Boot für ESXi erfordert die Unterstützung durch die Firmware. Secure Boot für ESXi erfordert außerdem, dass alle ESXi-Kernelmodule, -Treiber und -VIBs von VMware oder einem unterstellten Partner signiert wurden.
Secure Boot wird im BIOS des physischen ESXi-Servers aktiviert und vom Hypervisor-Bootloader unterstützt. Diese Kontrolle ändert die Einstellung von ESXi von der bloßen Unterstützung von Secure Boot in die Erforderung desselben. Ohne Aktivierung dieser Einstellung und die Konfigurationsverschlüsselung ist ein ESXi-Host möglicherweise Offline-Angriffen ausgesetzt. Ein Angreifer könnte einfach das ESXi-Installationslaufwerk in einen Host ohne Secure Boot transferieren und starten.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Die Verwendung von Secure Boot und durch TPM erzwungener Konfigurationsverschlüsselung machen herkömmliche Versuche zur Wiederherstellung des Root-Passworts unbrauchbar. Stellen Sie sicher, dass Sie den Zugriff auf ESXi-Administratorkonten nicht verlieren.
Deaktivieren der ESXi Shell
Die ESXi Shell sollte deaktiviert sein.
UserVars.ESXiShellInteractiveTimeOut
Legt eine Zeitüberschreitung fest, um ESXi Shell- und SSH-Sitzungen im Leerlauf automatisch zu beenden.
Wenn Benutzer vergessen, sich von ihrer SSH-Sitzung abzumelden, bleibt die Verbindung im Leerlauf unbegrenzt offen. Dies steigert die Möglichkeit, dass andere Benutzer potenziell einen privilegierten Zugriff auf den Host erhalten. Sie können Shell-Sitzungen, die sich im Leerlauf befinden, dahingehend konfigurieren, dass sie automatisch beendet werden.
Deaktivieren des SNMP-Dienstes
Deaktivieren Sie den SNMP-Dienst, wenn Sie ihn nicht verwenden.
Deaktivieren des SNMP-Dienstes
Deaktivieren Sie SSH und aktivieren Sie es nur für die Fehlerbehebung.
ESXi ist kein UNIX-ähnliches Multiuser-Betriebssystem. ESXi ist ein speziell entwickelter Hypervisor, der durch den VMware Host Client, den vSphere Client, die CLIs und die APIs verwaltet wird. Auf ESXi dient SSH als Schnittstelle für die Fehlerbehebung und den Support und wird standardmäßig angehalten und deaktiviert. Die Aktivierung dieser Schnittstelle birgt Risiken.
Verwenden von Entropie für kryptografische Vorgänge
Der ESXi-Host muss für kryptografische Vorgänge ausreichende Entropie verwenden.
In vSphere 8.0 und höher unterstützt die ESXi-Entropie-Implementierung die Zertifizierungen FIPS 140-3 und EAL4. Kernel-Startoptionen steuern, welche Entropiequellen auf einem ESXi-Host aktiviert werden sollen.
- PowerCLI-Befehlsbeurteilung
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $ESXcli.system.settings.kernel.list.Invoke() | Where {$_.Name -eq "disableHwrng" -or $_.Name -eq "entropySources"}
- Beispiel für PowerCLI-Befehlsstandardisierung
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $arguments = $ESXcli.system.settings.kernel.set.CreateArgs() $arguments.setting = "disableHwrng" $arguments.value = "FALSE" $ESXcli.system.settings.kernel.set.invoke($arguments) $arguments.setting = "entropySources" $arguments.value = "0" $ESXcli.system.settings.kernel.set.invoke($arguments)
Überprüfen von Image-Profil- und VIB-Akzeptanzebenen
Die Akzeptanzebene des ESXi-Host-Image-Profils muss mindestens „PartnerSupported“ lauten.
Die Akzeptanzebene steuert, welche Installationen ESXi zulässt. Informationen zu den VIB-Ebenen finden Sie unter Verwalten der Akzeptanzebenen von ESXi-Hosts und vSphere-Installationspaketen.
Weder VMware noch VMware-Partner testen CommunitySupported-VIBs. CommunitySupported-VIBs enthalten außerdem keine digitale Signatur. Gehen Sie daher bei der Installation von CommunitySupported-VIBs äußerst vorsichtig vor.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- CommunitySupported-Pakete sind nicht signiert und können nicht installiert werden.
- Beispiel für PowerCLI-Befehlsstandardisierung
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $arguments = $ESXcli.software.acceptance.set.CreateArgs() $arguments.level = "PartnerSupported" # VMwareCertified, VMwareAccepted, PartnerSupported, CommunitySupported $ESXcli.software.acceptance.set.Invoke($arguments)
Security.AccountUnlockTime
Der ESXi-Host muss Konten nach einer bestimmten Zeit entsperren.
Security.AccountUnlockTime stellt sicher, dass Benutzerkonten auf dem ESXi-Host nach einem festgelegten Zeitraum der Inaktivität automatisch entsperrt werden. Durch das Erzwingen des automatischen Entsperrens von Konten können Organisationen ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit erzielen. Dieses stellt sicher, dass Konten, die sich im Leerlauf befinden, sofort wieder aktiviert werden können, während gleichzeitig das Potenzial für den nicht autorisierten Zugriff minimiert wird.
Security.AccountLockFailures
Legt die maximale Anzahl fehlgeschlagener Anmeldeversuche fest, nach denen ein Konto gesperrt wird.
Dies schützt vor Brute-Force-Angriffen und nicht autorisierten Zugriffsversuchen, indem das betroffene Konto vorübergehend deaktiviert wird, was bis zum Ablaufen der Sperrzeit oder das manuelle Zurücksetzen des Kontos durch einen Administrator weitere Anmeldeversuche verhindert. Das Entsperren eines gesperrten Kontos erfordert entweder ein administratives Eingreifen oder eine Wartezeit bis das Konto automatisch entsperrt wird, sofern diese Einstellung Security.AccountUnlockTime verwendet wird.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Ein niedriger Schwellenwert für Anmeldefehler kann potenziell eine Zunahme beabsichtigter oder unbeabsichtigter Denial-of-Service-Angriffe bewirken, z. B. durch erneute Versuche eine SSH-Verbindung herzustellen.
Security.PasswordHistory
Lässt keine erneute Verwendung von Kennwörtern zu.
Diese Einstellung verhindert die erneute Verwendung vorheriger Kennwörter. Dies verhindert potenzielle Angriffe mit alten, kompromittierten Anmeldedaten.
Security.PasswordMaxDays
Legt die maximale Anzahl an Tagen zwischen Kennwortänderungen fest.
Moderne Best Practices für Kennwörter, wie sie in NIST 800-63B Abschnitt 5.1.1.2 und anderen relevanten Anleitungen beschrieben werden, besagen, dass die Erzwingung regelmäßiger Kennwortänderungen die Sicherheit nicht verbessert, wenn Kennwörter bereits über eine angemessene Entropie verfügen.
Security.PasswordQualityControl
Erzwingt komplexe Kennwörter.
Empfehlungen wie in NIST 800-63B Abschnitt 5.1.1.2 legen nahe, dass Erstellungsregeln, z. B. das Festlegen einer Mischung aus Zeichenklassen, auf Systemen nicht erzwungen werden sollten, da sie die Kennwortsicherheit häufig nicht verbessern und die Akzeptanz für sicherere Passphrasen verringern.
Regeln für die Stärke und Komplexität von Kennwörtern gelten für alle ESXi-Benutzer, einschließlich des Root-Benutzers. Wenn der ESXi-Host jedoch einer Domäne beitritt, gelten diese Regeln nicht für Active Directory (AD)-Benutzer, da Kennwortrichtlinien für AD-Benutzer vom AD-System erzwungen werden.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Andere Produkte und Dienste innerhalb des VMware-Ökosystems erwarten möglicherweise keine Änderungen der Anforderungen an die Komplexität von Kennwörtern, weshalb möglicherweise die Installation fehlschlägt.
UserVars.SuppressHyperthreadWarning
Unterdrückt die Warnung vor einer potenzielle Sicherheitslücke aufgrund von Hyper-Threading.
Sicherheitswarnungen aufgrund von Hyper-Threading resultieren aus nicht behobenen CPU-Schwachstellen im System. Wenn diese Warnungen ignoriert werden, bleiben potenzielle Risiken möglicherweise unerkannt. Stellen Sie sicher, dass Korrekturen von Hardwareproblemen gemäß dem in Ihrem Unternehmen akzeptablen Risikos erfolgen. Sofern Sie eine Warnung unterdrücken, dokumentieren Sie die Entscheidung und geben Sie eine Begründung an.
UserVars.DcuiTimeOut
Legt eine Zeitbeschränkung fest, nach deren Ablauf im Leerlauf befindliche DCUI-Sitzungen automatisch beendet werden.
DCUI ermöglicht eine direkte Anmeldung beim ESXi-Host für Verwaltungsaufgaben. Um eine unbeabsichtigte DCUI-Nutzung über noch laufende Anmeldesitzungen zu verhindern, beenden Sie Verbindungen im Leerlauf.
CIM-Dienst deaktivieren
Der ESXi-CIM-Dienst sollte deaktiviert sein.
Dienste, die nicht verwendet werden und für den Betrieb nicht erforderlich sind, sollten deaktiviert werden.
Config.HostAgent.log.level
Legt die Protokollierungsebene fest.
Stellen Sie beim Festlegen der Protokollierungsebene sicher, dass in den Überwachungsprotokollen ausreichend Informationen vorhanden sind, um Diagnosen und forensische Untersuchungen durchzuführen.
Syslog.global.logLevel
Protokolliert ausreichende Informationen für Ereignisse.
Ohne ausreichende Protokolldaten können kritische Indikatoren für eine Kompromittierung unbemerkt bleiben, was bei der effektiven Reaktion auf Cybersicherheitsvorfälle zu einer erhöhten Angreifbarkeit und potenziellen Ausfällen führt.
Config.HostAgent.plugins.solo.enableMob
Deaktiviert den Managed Object Browser (MOB).
Dienste, die nicht verwendet werden und für den Betrieb nicht erforderlich sind, sollten deaktiviert werden.
Net.BlockGuestBPDU
Blockiert BPDU (Bridge Protocol Data Unit)-Übertragungen des Gastbetriebssystems.
BPDUs werden genutzt, um Spanning-Tree-Protocol (STP)-Informationen zu übertragen und Netzwerkschleifen zu erkennen. BPDU Guard und Portfast werden normalerweise auf dem physischen Switch aktiviert, der direkt mit dem ESXi-Host verbunden ist, um die Verzögerung bei der Spanning-Tree-Konvergenz zu reduzieren.
Wenn jedoch ein BPDU-Paket von einer virtuellen Maschine auf dem ESXi-Host an den konfigurierten physischen Switch gesendet wird, kann dies zu einer kaskadierenden Sperrung aller Uplink-Schnittstellen vom ESXi-Host führen. Um solche Sperren zu verhindern, können Sie den BPDU-Filter auf dem ESXi-Host aktivieren, damit alle BPDU-Pakete verworfen werden, die an den physischen Switch gesendet werden.
Standard-Switches und Distributed Virtual Switches unterstützen kein STP und generieren keine BPDUs.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- Einige netzwerkorientierte Arbeitslasten können legitime BPDU-Pakete generieren. Stellen Sie vor der Aktivierung des BPDU-Filters sicher, dass von virtuellen Maschinen auf dem ESXi-Host keine legitimen BPDU-Pakete generiert werden. Wenn der BPDU-Filter in dieser Situation aktiviert ist, bietet die Aktivierung der Funktion „Gefälschte Übertragungen“ mittels „Ablehnen“ in der Portgruppe des virtuellen Switches zusätzlichen Schutz vor Spanning Tree-Schleifen.
Net.DVFilterBindIpAddress
Schränkt die Verwendung der dvFilter-Netzwerk-APIs ein.
Wenn Sie kein Produkt wie VMware NSX verwenden, das die dvFilter-Netzwerk-API nutzt, konfigurieren Sie den ESXi-Host nicht so, dass er Netzwerkinformationen an eine IP-Adresse sendet. Das Aktivieren der API und der Verweis auf eine kompromittierte IP-Adresse kann möglicherweise einen unbefugten Zugriff auf das Netzwerk anderer virtueller Maschinen auf dem ESXi-Host ermöglichen.
Wenn Sie ein Produkt verwenden, das auf diese API angewiesen ist, müssen Sie unbedingt prüfen, ob der ESXi-Host korrekt konfiguriert wurde, um eine sichere Netzwerkkommunikation zu gewährleisten.
UserVars.ESXiShellTimeOut
Legt eine Zeitüberschreitung fest, um zu begrenzen, wie lange ESXi Shell- und SSH-Dienste ausgeführt werden dürfen.
Diese erweiterte Systemeinstellung definiert ein Zeitfenster, nach dessen Ablauf die ESXi Shell- und SSH-Dienste automatisch beendet werden.
UserVars.SuppressShellWarning
Unterdrückt die Warnung für Support- und Fehlerbehebungsschnittstellen.
Der ESXi-Host darf keine Warnungen unterdrücken, die melden, dass die ESXi Shell aktiviert ist.
Warnungen, dass SSH oder die ESXi Shell aktiviert ist, können ein Hinweis auf einen laufenden Angriff sein. Dabei ist es wichtig, sicherzustellen, dass SSH und die ESXi Shell deaktiviert sind und dass diese erweiterte Systemeinstellung nicht aktiviert ist.
Konfigurieren des ESXi Secure Shell-Daemons für FIPS
Der Secure Shell (SSH)-Daemon des ESXi-Hosts muss so konfiguriert werden, dass er nur gemäß FIPS 140-2/140-3 validierte Verschlüsselungen verwendet. Sie müssen Systemdienste härten und sichern, wenn diese aktiviert werden.
- Werte
- Standardwert der Installation: [email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
- PowerCLI-Befehlsbeurteilung
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $ESXcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'ciphers'} | Select-Object -ExpandProperty Value
- Beispiel für PowerCLI-Befehlsstandardisierung
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $arguments = $ESXcli.system.ssh.server.config.set.CreateArgs() $arguments.keyword = 'ciphers' $arguments.value = '[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr' $ESXcli.system.ssh.server.config.set.Invoke($arguments)
Konfigurieren des ESXi SSH-Daemon für FIPS
Der SSH-Daemon des ESXi-Hosts muss gemäß FIPS 140-2/140-3 validierte kryptografische Module verwenden.
OpenSSH auf dem ESXi-Host wird mit einem nach FIPS 140-2/140-3 validierten Kryptografiemodul ausgeliefert, das standardmäßig aktiviert ist. Zum Erzielen von Abwärtskompatibilität können Sie dieses Modul deaktivieren. Überwachen und korrigieren Sie dies gegebenenfalls.
Konfigurieren des ESXi Secure Shell-Daemons für das Nicht-Zulassen von Gateway-Ports
Der Secure Shell (SSH)-Daemon des ESXi-Hosts muss so konfiguriert sein, dass er keine Gateway-Ports zulässt.
Sie müssen Systemdienste härten und sichern, wenn diese aktiviert werden.
Konfigurieren des ESXi Secure Shell-Daemons, damit er keine hostbasierte Authentifizierung zulässt
Der Secure Shell (SSH)-Daemon des ESXi-Hosts darf keine hostbasierte Authentifizierung zulassen.
Sie müssen Systemdienste härten und sichern, wenn diese aktiviert werden.
Konfigurieren des ESXi Secure Shell-Daemons für das Festlegen eines Timeout-Zählers
Der Secure Shell (SSH)-Daemon des ESXi-Hosts muss für Sitzungen im Leerlauf einen Timeout-Zähler festlegen.
Sie müssen Systemdienste härten und sichern, wenn diese aktiviert werden. Der Timeout-Zähler-Wert multipliziert mit dem Wert des Zeitüberschreitungsintervalls im Leerlauf ergibt die Gesamtzahl der Sekunden, während der eine Sitzung bis zur Trennung inaktiv sein kann.
Konfigurieren des ESXi Secure Shell-Daemons für das Festlegen eines Zeitüberschreitungsintervalls
Der Secure Shell (SSH)-Daemon des ESXi-Hosts muss für Sitzungen im Leerlauf einen Timeout-Zähler festlegen.
Sie müssen Systemdienste härten und sichern, wenn diese aktiviert werden. Der Timeout-Zähler-Wert multipliziert mit dem Wert des Zeitüberschreitungsintervalls im Leerlauf ergibt die Gesamtzahl der Sekunden, während der eine Sitzung bis zur Trennung inaktiv sein kann.
Konfigurieren des ESXi Secure Shell Daemons für die Anzeige eines Anmelde-Banners
Der Secure Shell (SSH)-Daemon des ESXi-Hosts muss das Anmelde-Banner des Systems anzeigen, bevor der Zugriff auf das System gewährt wird.
Sie müssen Systemdienste härten und sichern, wenn diese aktiviert werden. Sie müssen außerdem die Einstellung Config.Etc.issue festlegen, um Text für dieses Banner anzugeben.
Konfigurieren des ESXi Secure Shell-Daemons für das Ignorieren von .rhosts-Dateien
Der Secure Shell (SSH)-Daemon des ESXi-Hosts muss .rhosts -Dateien ignorieren.
Sie müssen Systemdienste härten und sichern, wenn diese aktiviert werden.
Konfigurieren des ESXi Secure Shell-Daemons für die Deaktivierung der lokalen Stream-Weiterleitung
Der Secure Shell (SSH)-Daemon des ESXi-Hosts muss die lokale Stream-Weiterleitung deaktivieren.
Sie müssen Systemdienste härten und sichern, wenn diese aktiviert werden.
Konfigurieren des ESXi Secure Shell-Daemons für die Deaktivierung der TCP-Weiterleitung
Der Secure Shell (SSH)-Daemon des ESXi-Hosts muss die TCP-Weiterleitung deaktivieren.
Sie müssen Systemdienste härten und sichern, wenn diese aktiviert werden.
Konfigurieren des ESXi Secure Shell-Daemons für das Nicht-Zulassen von Tunnels
Der Secure Shell (SSH)-Daemon des ESXi-Hosts darf keine Tunnel zulassen.
Sie müssen Systemdienste härten und sichern, wenn diese aktiviert werden.
Konfigurieren des ESXi Secure Shell-Daemons für das Nicht-Zulassen von Benutzerumgebungseinstellungen
Der Secure Shell (SSH)-Daemon des ESXi-Hosts darf keine Benutzerumgebungseinstellungen zulassen.
Sie müssen Systemdienste härten und sichern, wenn diese aktiviert werden.
Deaktivieren des Service Location Protocol-Dienstes
Deaktivieren Sie den Service Location Protocol (SLP)-Dienst, wenn er nicht verwendet werden.
Mem.ShareForceSalting
Beschränkt die transparente gemeinsame Seitennutzung auf virtuelle Maschinen, die mit sched.mem.pshare.salt konfiguriert sind.
Die transparente gemeinsame Seitennutzung (Transparent Page Sharing, TPS) ist eine Methode zur Verringerung des Arbeitsspeicherbedarfs virtueller Maschinen. Unter streng kontrollierten Bedingungen können Angreifer mithilfe von TPS unbefugten Zugriff auf Daten auf benachbarten virtuellen Maschinen erlangen. Virtuelle Maschinen, für die die Einstellung sched.mem.pshare.salt nicht konfiguriert ist, können Speicher nicht mit anderen virtuellen Maschinen gemeinsam nutzen. Große Seitenformate, eine Leistungsoptimierung im Hypervisor auf vielen modernen CPUs, sind nicht mit TPS kompatibel.
UserVars.HostClientSessionTimeout
Legt eine Zeitüberschreitung fest, um im Leerlauf befindliche ESXi-Host-Clientsitzungen automatisch zu beenden.
Der ESXi-Host muss im Leerlauf befindliche Clientsitzungen automatisch beenden. Diese trägt dazu bei, potenzielle Sicherheitsrisiken zu verringern, indem sichergestellt wird, dass unbeaufsichtigte Sitzungen nicht unbefristet offen bleiben, wodurch sie von nicht autorisierten Benutzern oder Schadsoftware ausgenutzt werden könnten.
Net.BMCNetworkEnable
Deaktiviert die Netzwerkschnittstellen für die Verwaltung virtueller Hardware.
Controller für die Hardwareverwaltung stellen dem ESXi-Host häufig virtuelle oder USB-NICs bereit. Da diese als Hintertüren verwendet werden können, sollten sie sowohl in der Hardwarekonfiguration als auch in der ESXi-Konfiguration deaktiviert werden.
Aktivieren der bidirektionalen/gegenseitigen CHAP-Authentifizierung für iSCSI-Datenverkehr
Legen Sie für die Authentifizierung des iSCSI-Speicheradapters „Bidirektionales CHAP verwenden“ fest und geben Sie die Anmeldedaten an.
Gegenseitiges CHAP bietet eine zusätzliche Schutzebene, da sowohl der Initiator (Client) als auch das Ziel (Server) gegenseitig ihre Identität bestätigen müssen. Dies verhindert, dass zwischen den beiden Instanzen übertragene Daten durch nicht autorisierte Entitäten abgefangen oder geändert werden.
- Aktion erforderlich
- Ändern Sie den Standardwert der Installation, wenn Sie diese Funktion verwenden.
Kein Speichern von Verschlüsselungsschlüsseln ohne Absicherung des physischen Zugriffs auf ESXi-Hosts
Der ESXi-Host darf keine Verschlüsselungsschlüssel auf dem ESXi-Host selbst speichern, wenn der Host nicht vor physischem Zugriff geschützt ist.
Schlüsselpersistenz ist ein Mechanismus, der ein lokales Trusted Platform Module (TPM) verwendet, um Schlüssel des Standardschlüsselanbieters zu speichern, die sich normalerweise nur in einem externen Schlüsselverwaltungssystem (Key Management System, KMS) befinden. Zwar kann dieses Setup die Verwaltung von Abhängigkeiten verbessern, durch die Verwendung der Schlüsselpersistenz ändern sich jedoch die Verschlüsselungsrisiken. Wenn ein Angreifer den Host stiehlt, hat er Zugriff auf die Verschlüsselungsschlüssel für die Daten auf diesem Host und umgeht die Zugriffskontrollen des externen KMS. Nutzen Sie Schlüsselpersistenz daher nur, wenn Sie die physische Sicherheit Ihrer Hosts gewährleisten können. Wenn die physischen Hosts nicht sicher sind und ein Angreifer den Host stehlen kann, kann der Angreifer auch auf verschlüsselte Arbeitslasten zugreifen und diese verwenden.
Schlüsselpersistenz und vSphere Native Key Provider werden häufig verwechselt, da beide Verschlüsselungsdaten auf Hosts speichern. Der vSphere Native Key Provider verwendet jedoch keine Schlüsselpersistenz. Das Deaktivieren der Schlüsselpersistenz wirkt sich daher nicht auf ihn aus. Wie bei der Schlüsselpersistenz muss auch beim vSphere Native Key Provider sorgfältig auf die physische Sicherheit geachtet werden. Weitere Informationen hierzu finden Sie unter vSphere-Systemdesign-Sicherheitskontrollenreferenz.
- Mögliche funktionale Auswirkungen einer Änderung des Standardwerts
- „Standard“ ist das gewünschte Verhalten. Eine Abweichung von der Standardeinstellung kann sich negativ auf die Vertraulichkeit in Umgebungen auswirken, in denen ein physischer Zugriff durch Angreifer möglich ist.
