Estos controles de seguridad proporcionan un conjunto de líneas base de prácticas recomendadas de seguridad de ESXi. Están estructurados de manera tal que se explican los beneficios y las compensaciones de la implementación del control. La mayoría de los controles están en forma de configuración avanzada del sistema. Para cambiar la configuración avanzada del sistema, puede utilizar la instancia de PowerCLI proporcionada o vSphere Client ().
Variable utilizada
Los comandos de PowerCLI de esta sección utilizan las siguientes variables:
- $ESXi = "host_name"
- $vmkernel_interface = "vmkernel_adapter"
Garantizar que se deniegue el acceso a la cuenta de DCUI
El host ESXi debe denegar el acceso al shell de la cuenta de usuario dcui.
La cuenta de usuario dcui se utiliza para el aislamiento de procesos de la propia DCUI. Para reducir la superficie de ataque, desactive el acceso al shell de la cuenta de usuario dcui.
Annotations.WelcomeMessage
Configura el texto del mensaje de inicio de sesión que se muestra en VMware Host Client y la DCUI.
ESXi permite mostrar un mensaje de inicio de sesión. Los usos del mensaje de inicio de sesión incluyen informar a los intrusos que sus actividades son ilegales, y transmitir a los usuarios autorizados las expectativas y las obligaciones que deben cumplir y aceptar al utilizar el sistema.
- Impacto funcional potencial si se cambia el valor predeterminado
- Enmascara la información de "F2/F12" y la dirección IP en la DCUI. También puede requerir documentación y formación de su entorno.
Config.HostAgent.vmacore.soap.sessionTimeout
Configura un tiempo de espera de sesión para vSphere API.
Esta práctica mitiga los posibles riesgos de seguridad al garantizar que las sesiones sin supervisión, que los usuarios no autorizados o el software malicioso podrían aprovechar, no se dejen abiertas de forma indefinida.
Config.Etc.issue
Configura el texto del aviso cuando un usuario se conecta a un host ESXi mediante SSH.
ESXi proporciona la capacidad de mostrar un aviso para las conexiones de SSH. Los usos del aviso incluyen informar a los intrusos de que sus actividades son ilegales, y transmitir a los usuarios autorizados las expectativas y obligaciones que deben cumplir y aceptar al utilizar el sistema. Mantenga el servicio de SSH desactivado, a menos que esté realizando operaciones de solución de problemas. Una incoherencia de implementación entre ESXi y vCenter Server requiere que el "problema" en Config.Etc.issue esté en minúsculas para funcionar en ambos escenarios.
- Evaluación mediante comandos de PowerCLI
-
Get-VMHost -Name $ESXi | Get-AdvancedSetting Config.Etc.issue
- Ejemplo de corrección mediante un comando de PowerCLI
-
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"
Desactivar el acceso al shell para vpxuser
El host ESXi debe denegar el acceso al shell de la cuenta vpxuser.
vCenter Server crea la cuenta vpxuser cuando se asocia por primera vez un host ESXi. Posteriormente, la cuenta vpxuser se utiliza para la autenticación con privilegios para ESXi. Mientras que vCenter Server rota automáticamente la contraseña de la cuenta vpxuser en un intervalo regido por la opción VirtualCenter.VimPasswordExpirationInDays, la cuenta vpxuser también tiene acceso al shell. Desactive la cuenta vpxuser para reducir la superficie de ataque.
- Impacto funcional potencial si se cambia el valor predeterminado
- Las cuentas de usuario que no tienen acceso al shell no pueden reconfigurar el acceso al shell de otros usuarios, independientemente de sus niveles de privilegio. Debido a que vCenter Server se conecta a un host ESXi como la cuenta vpxuser, una vez que desactive el acceso al shell para vpxuser, ya no se podrá utilizar para cambiar esa configuración de cuenta para otras cuentas. Debe producirse una reconfiguración adicional host por host mediante el uso de una cuenta que esté autorizada.
vCenter Server debe utilizar vSphere Authentication Proxy para evitar el almacenamiento de credenciales de Active Directory
vSphere Authentication Proxy permite que vCenter Server se conecte a entidades de Active Directory y las administre sin necesidad de almacenar directamente las credenciales de Active Directory, lo que reduce el riesgo de exposición o uso indebido de las credenciales.
DCUI.Access
El host ESXi debe tener una lista DCUI.Access precisa.
Establece la lista de usuarios con excepción en modo de bloqueo para que contenga una lista precisa de usuarios y garantiza que solo los usuarios autorizados tengan acceso directo a la interfaz de usuario de la consola (DCUI) al host ESXi cuando se active el modo de bloqueo.
No puede eliminar el usuario raíz de la lista.
Para controlar el acceso a ESXi Shell y a SSH, utilice la lista de usuarios con excepción en modo de bloqueo. Consulte Garantizar que el host ESXi tenga una lista precisa de usuarios con excepción.
Garantizar que el host ESXi tenga una lista precisa de usuarios con excepción
El host ESXi debe tener una lista precisa de usuarios con excepción.
Los usuarios de la lista de usuarios con excepción en modo de bloqueo no pierden sus privilegios cuando el host entra en modo de bloqueo. Esta situación podría anular el propósito del modo de bloqueo.
- Impacto funcional potencial si se cambia el valor predeterminado
- Posible pérdida de acceso administrativo a los hosts ESXi. Asegúrese de asociar los hosts ESXi a vCenter Server, y de configurar las listas de acceso y las listas de excepciones antes de configurar el modo de bloqueo.
Activar el modo de bloqueo normal para restringir el acceso a ESXi
Al activar el modo de bloqueo, se desactiva el acceso directo a un host ESXi. El modo de bloqueo requiere que vCenter Server administre el host ESXi directamente.
Restringir el acceso de esta manera garantiza que vCenter Server aplique funciones y permisos. Además, los usuarios no pueden omitir estas funciones y permisos al iniciar sesión en un host ESXi directamente. Requerir que toda la interacción se produzca a través de vCenter Server reduce el riesgo de que los usuarios obtengan privilegios altos inadvertidamente o realicen tareas para las que no se les realiza una auditoría correctamente.
Los usuarios que figuran en la lista de usuarios con excepción para cada host ESXi tienen permiso para anular el modo de bloqueo e iniciar sesión. De forma predeterminada, no hay usuarios presentes en la lista de usuarios con excepción.
Los ajustes del modo de bloqueo son Deshabilitado, Normal y Estricto. Cuando el modo de bloqueo se establece en Estricto, si el host ESXi pierde contacto con vCenter Server, no podrá administrarlo hasta que se restablezca la conexión. Si no puede restablecer la conexión, debe reconstruir el host ESXi. En general, el modo de bloqueo estricto supera las necesidades de la mayoría de las implementaciones. Por lo tanto, el modo de bloqueo normal suele ser suficiente.
- Impacto funcional potencial si se cambia el valor predeterminado
- Posible pérdida de acceso administrativo a los hosts. Asegúrese de asociar los hosts ESXi a vCenter Server, y de configurar las listas de acceso y las listas de excepciones antes de configurar el modo de bloqueo.
Syslog.global.auditRecord.storageEnable
Configura el host ESXi para almacenar los registros de auditoría de forma local.
Debe activar el registro de registros de auditoría en los hosts ESXi.
- Impacto funcional potencial si se cambia el valor predeterminado
- Los registros consumen espacio de almacenamiento adicional.
Syslog.global.auditRecord.storageCapacity
Debe activar la capacidad de almacenamiento durante una semana de los registros de auditoría en los hosts ESXi.
Si hay una instalación de almacenamiento de registros de auditoría remota disponible, es esencial garantizar que la capacidad de almacenamiento local sea suficiente para mantener los registros de auditoría que se pueden acumular durante las interrupciones previstas en la entrega de los registros a la instalación. Esto garantiza que los registros de auditoría no se pierdan ni se sobrescriban durante los períodos en los que el almacenamiento remoto no está disponible, lo que permite una continuidad sin problemas de la traza de auditoría y los requisitos de conformidad.
- Impacto funcional potencial si se cambia el valor predeterminado
- Los registros consumen espacio de almacenamiento adicional.
ScratchConfig.CurrentScratchLocation y Syslog.global.auditRecord.storageDirectory
Configura una ubicación de registro persistente para todos los registros de auditoría almacenados localmente en el host ESXi.
Puede configurar ESXi para almacenar registros de auditoría en un sistema de archivos en la memoria. Esto ocurre cuando el directorio "/scratch" del host está vinculado a "/tmp/scratch". Cuando se hace esto, solo se almacenan registros de un solo día en cualquier momento. Además, los registros de auditoría se reinician después de cada reinicio. Esto representa un riesgo de seguridad, ya que la actividad del usuario que inició sesión en el host solo se almacena temporalmente y no se mantiene después del reinicio. Esto también puede complicar la auditoría, y dificultar la supervisión de eventos y el diagnóstico de problemas. Configure siempre el registro de auditoría del host ESXi en un almacén de datos persistente.
Puede detectar si el volumen de scratch es temporal o persistente al consultar la configuración avanzada de ScratchConfig.CurrentScratchLocation. Si, cuando se consulta, devuelve "/tmp/scratch", el volumen es temporal y debe volver a asignar el almacenamiento de registros de auditoría a un dispositivo persistente.
El almacenamiento no puede ser un almacén de datos de vSAN. Si el único almacenamiento local que no es de vSAN es un medio SD o USB (que puede volverse poco fiable con las escrituras repetidas de los registros), considere la posibilidad de dejar los registros en el disco RAM y asegúrese de que se haya configurado un host de registro remoto en su lugar. Documente la decisión y la lógica como preparación para futuras auditorías.
- Valores
-
Valor predeterminado de instalación:
ScratchConfig.CurrentScratchLocation: depende del dispositivo de arranque.
Syslog.global.auditRecord.storageDirectory: /scratch/auditLog
- Impacto funcional potencial si se cambia el valor predeterminado
- Los registros consumen espacio de almacenamiento adicional.
- Evaluación mediante comandos de PowerCLI
-
$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
Configura el host ESXi para la transmisión de registros de auditoría a un host remoto.
Syslog.global.logFiltersEnable
Activa el filtro de registros en el host ESXi.
Puede crear filtros de registros para reducir la cantidad de entradas repetidas y denegar eventos de registros específicos en su totalidad.
LocalLogOutputIsPersistent, ScratchConfig.CurrentScratchLocation y Syslog.global.logDir
Configura el registro persistente de todos los registros almacenados localmente en el host ESXi.
Puede configurar ESXi para almacenar archivos de registro en un sistema de archivos en la memoria. Esto ocurre cuando el directorio "/scratch" del host está vinculado a "/tmp/scratch". Cuando se hace esto, solo se almacenan los registros de un solo día en cualquier momento. Además, los archivos de registro se reinician después de cada reinicio. Esto representa un riesgo de seguridad, ya que la actividad del usuario que inició sesión en el host solo se almacena temporalmente y no se conserva después de los reinicios. También puede complicar la auditoría, y dificultar la supervisión de eventos y el diagnóstico de problemas. Configure siempre el registro del host ESXi en un almacén de datos persistente.
Puede detectar si el volumen de scratch es temporal o persistente al consultar el parámetro avanzado de ScratchConfig.CurrentScratchLocation. Si, cuando se consulta, devuelve "/tmp/scratch", el volumen es temporal y debe volver a asignar el almacenamiento de registros de auditoría a un dispositivo persistente.
El almacenamiento no puede ser un almacén de datos de vSAN, a menos que establezca Syslog.global.vsanBacking, que tiene advertencias y dependencias. Si el único almacenamiento local que no es de vSAN es un medio SD o USB (que puede volverse poco fiable con las escrituras repetidas de los registros), considere la posibilidad de dejar los registros en el disco RAM y asegúrese de que se haya configurado un host de registro remoto en su lugar. Documente la decisión y la lógica como preparación para futuras auditorías.
- Valores
-
Valor predeterminado de instalación: ScratchConfig.CurrentScratchLocation: depende del dispositivo de arranque.
Syslog.global.logDir: /scratch/log
- Evaluación mediante comandos de PowerCLI
-
$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
Configura el registro remoto.
Cuando configura el registro remoto en un host de registro central, proporciona un almacén centralizado y seguro para los registros de ESXi. La recopilación de archivos de registro del host en un host central permite supervisar todos los hosts con una sola herramienta. También puede realizar análisis adicionales y buscar elementos como ataques coordinados en varios hosts. El inicio de sesión en un servidor de registro centralizado y seguro ayuda a prevenir la modificación de los registros, además de proporcionar un registro de auditoría a largo plazo.
Syslog.global.certificate.checkSSLCerts
Comprueba los certificados de TLS.
El host ESXi debe comprobar los certificados de los endpoints de registro remoto de TLS. Los certificados de TLS garantizan que el endpoint sea auténtico y confiable.
Syslog.global.certificate.strictX509Compliance
Realiza una verificación x509 estricta para los endpoints de registro remoto habilitados para TLS.
El host ESXi debe utilizar una verificación x509 estricta para los endpoints de registro remoto habilitados para TLS. La configuración de Syslog.global.certificate.strictX509Compliance realiza comprobaciones de validez adicionales en los certificados raíz de CA durante la verificación.
Mem.MemEagerZero
Activa la destrucción de claves volátiles.
De forma predeterminada, ESXi coloca en cero las páginas asignadas para máquinas virtuales, las aplicaciones del espacio del usuario y los subprocesos de kernel en el momento de la asignación. Esto garantiza que no se expongan páginas que no estén en cero a las máquinas virtuales ni a las aplicaciones del espacio del usuario. Esta medida se aplica para evitar la exposición de claves criptográficas de máquinas virtuales o ámbitos del usuario a otros clientes.
Sin embargo, si no se reutiliza la memoria, estas claves pueden permanecer presentes en la memoria del host durante un período prolongado. Para solucionar esto, puede configurar el ajuste de MemEagerZero para aplicar la puesta a cero de las páginas de memoria del ámbito del usuario y del invitado cuando un invitado o un proceso del ámbito del usuario salga. En el caso de los subprocesos del kernel, los espacios de memoria que contienen claves se ponen en cero tan pronto como ya no se requiere el secreto.
- Impacto funcional potencial si se cambia el valor predeterminado
- Se requiere de un tiempo de apagado adicional para las máquinas virtuales, que corresponde a la cantidad de memoria asignada.
Comprobar el mantenimiento activo en la versión de ESXi
Asegúrese de que la versión de ESXi no esté en el estado Fin de soporte general de VMware.
Activar los orígenes de la sincronización de hora
El host ESXi debe tener servicios de sincronización de hora activados y en ejecución.
La criptografía, el registro de auditoría, las operaciones del clúster y la respuesta a incidentes y los análisis se basan en la sincronización de la hora. Para garantizar que la hora esté sincronizada en todos los servicios y las operaciones, active los servicios NTP o PTP para que comiencen con el host y asegúrese de que dichos servicios se estén ejecutando.
- Evaluación mediante comandos de PowerCLI
-
Get-VMHostService -VMHost $ESXi | Where-Object{$_.Key -eq "ntpd"}
- Ejemplo de corrección mediante un comando de PowerCLI
-
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
Configurar orígenes de sincronización de hora confiables
El host ESXi debe tener configurados los orígenes de sincronización de hora confiables.
La criptografía, el registro de auditoría, las operaciones del clúster y la respuesta a incidentes y los análisis dependen de la sincronización de la hora. El protocolo de tiempo de red (NTP) debe tener al menos cuatro orígenes. Si debe elegir entre dos orígenes y un origen, es preferible uno solo.
El protocolo de hora de precisión (PTP) es una alternativa a NTP que proporciona una precisión temporal de submilisegundos. La arquitectura de PTP es diferente de la de NTP y no tiene la misma resistencia a los errores del servidor principal. Considere la posibilidad de configurar el NTP como un origen de copia de seguridad del PTP, de modo que un origen de hora siga estando disponible, incluso si la precisión es menor.
Usar cifrados TLS
El host ESXi debe mantener la confidencialidad y la integridad de las transmisiones mediante la habilitación de cifrados TLS modernos.
A partir de ESXi 8.0 Update 3, los perfiles de TLS configuran los ajustes de TLS del cliente y del servidor para que solo usen cifrados seguros. Puede ver toda la lista y los conjuntos de claves de cifrado mediante los siguientes comandos:
$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)
Debe reiniciar el host ESXi después de realizar cambios en el perfil de TLS. (En vSphere Client, el host presenta el sufijo de "Reinicio necesario").
- Impacto funcional potencial si se cambia el valor predeterminado
- Los cambios en los conjuntos de claves de cifrado afectan la conectividad con sistemas externos. Debe reiniciar el host para que se aplique este cambio de perfil de TLS.
UserVars.ESXiVPsDisabledProtocols
El host ESXi debe habilitar la versión más alta de TLS admitida.
ESXi 8.0 activa TLS 1.2 de forma predeterminada, pero es posible activar otros protocolos si es necesario. A partir de ESXi 8.0 Update 3, TLS 1.3 está activado de forma predeterminada.
Configurar el cifrado basado en TPM
El host ESXi debe requerir un cifrado de configuración basado en TPM.
La configuración de un host ESXi consta de archivos de configuración para cada servicio que se ejecuta en el host. Los archivos de configuración suelen residir en el directorio /etc, pero también pueden residir en otros espacios de nombres. Los archivos de configuración contienen información en tiempo de ejecución sobre el estado de los servicios. Con el tiempo, los valores predeterminados de los archivos de configuración pueden cambiar, por ejemplo, cuando se cambia la configuración en el host ESXi.
Un trabajo cron realiza una copia de seguridad de los archivos de configuración de ESXi periódicamente, o cuando ESXi se apaga correctamente o a pedido, y crea un archivo de configuración archivado en el banco de arranque. Cuando ESXi se reinicia, el sistema lee el archivo de configuración archivado y vuelve a crear el estado en el que ESXi estaba cuando se creó la copia de seguridad.
Antes de vSphere 7.0 Update 2, el archivo de configuración ESXi archivado no está cifrado. En vSphere 7.0 Update 2 y versiones posteriores, se cifra el archivo de configuración archivado. Cuando el host ESXi está configurado con un módulo de plataforma de confianza (TPM), el TPM se utiliza para "sellar" la configuración en el host, lo que proporciona una garantía de seguridad sólida y protección adicional contra los ataques sin conexión.
El cifrado de configuración utiliza el TPM físico cuando está disponible y se admite en el momento de la instalación o la actualización. Si el TPM se agregó o se habilitó más adelante, debe volver a configurar explícitamente el host ESXi para utilizar el TPM recién disponible. Una vez habilitado el cifrado de la configuración de TPM, no se puede desactivar.
- Impacto funcional potencial si se cambia el valor predeterminado
- El uso del arranque seguro y el cifrado de configuración forzado por TPM hacen inutilizables los esfuerzos tradicionales de recuperación de la contraseña raíz. Asegúrese de no perder el acceso a las cuentas del administrador ESXi.
Comprobar que el software ESXi esté actualizado
Al mantenerse al día con las revisiones ESXi, se mitigan las vulnerabilidades en el hipervisor.
Un atacante con formación puede aprovechar las vulnerabilidades conocidas al intentar acceder o elevar los privilegios en un host ESXi. Actualice siempre vCenter Server primero; si hay una actualización disponible, y luego actualice ESXi.
VMkernel.Boot.execInstalledOnly
Ejecute archivos binarios que solo entregue un VIB.
ESXi realiza comprobaciones de integridad de los VIB en función del nivel de aceptación. Indicar a ESXi que solo ejecute archivos binarios que se originen a partir de un VIB válido instalado en el host hace que sea más difícil para los atacantes utilizar kits de herramientas precompilados durante un riesgo, y aumenta las posibilidades de detección.
- Impacto funcional potencial si se cambia el valor predeterminado
- Es posible que el software no firmado de terceros no se instale ni se ejecute.
Desactivar los servicios de administración en adaptadores de VMkernel
Asegúrese de que vSAN, vMotion y otros adaptadores de VMkernel dedicados no tengan los servicios de administración activados.
Las interfaces de red de VMkernel que están destinadas a un uso especializado pueden configurarse con capacidades de administración, lo que podría anular los esfuerzos de seguridad y aislamiento de red. Habilite solo los servicios de administración en las interfaces de VMkernel destinadas a la administración.
- Impacto funcional potencial si se cambia el valor predeterminado
- Es posible que algunas soluciones administradas de terceros requieran que se activen los servicios de administración en los adaptadores de Vmkernel.
Configurar el firewall ESXi para bloquear el tráfico
Debe configurar el firewall del host ESXi para bloquear el tráfico de red de forma predeterminada.
Asegúrese de que todo el tráfico de red entrante y saliente esté bloqueado, a menos que se permita explícitamente, lo que reduce la superficie de ataque y evita el acceso no autorizado al host.
Configurar el firewall de ESXi para redes autorizadas
Configure el firewall de ESXi para permitir el tráfico solo desde redes autorizadas.
Asegúrese de que todo el tráfico de red entrante y saliente esté bloqueado, a menos que se permita explícitamente, lo que reduce la superficie de ataque y evita el acceso no autorizado al host ESXi.
A partir de vSphere 8.0 Update 2, las reglas de firewall se clasifican como propiedad de "usuario" o "sistema", donde solo se pueden configurar las reglas que son propiedad del "usuario". En vSphere 8 Update 2b y PowerCLI 13.2.1, hay parámetros adicionales a los que se puede consultar para automatizar la configuración y la comprobación de las reglas configurables.
- Impacto funcional potencial si se cambia el valor predeterminado
- El firewall es simplista, similar a las LCA del enrutador. Es posible que deba volver a configurar las reglas reflexivas.
- Evaluación mediante comandos de PowerCLI
-
$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) }
- Ejemplo de corrección mediante un comando de PowerCLI
-
# 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)
Configurar la directiva de transmisiones falsificadas en Rechazar
Configure la directiva de transmisiones falsificadas en Rechazar tanto en el conmutador estándar de vSphere como en sus grupos de puertos.
Si el sistema operativo de la máquina virtual cambia la dirección MAC, el sistema operativo puede enviar marcos con una dirección MAC de origen suplantada en cualquier momento. La suplantación de direcciones MAC permite que un sistema operativo realice ataques maliciosos en los dispositivos de una red suplantando un adaptador de red autorizado por la red receptora. Cuando la directiva de transmisiones falsificadas está establecida en Aceptar, ESXi no compara las direcciones MAC de origen y efectivas. Para evitar la suplantación de MAC, configure la directiva Transmisiones falsificadas en Rechazar. El host luego compara la dirección MAC de origen que transmite el sistema operativo invitado con la dirección MAC efectiva del adaptador de la máquina virtual para ver si coinciden. Si las direcciones no coinciden, el host ESXi descarta el paquete.
- Impacto funcional potencial si se cambia el valor predeterminado
- Algunas cargas de trabajo, como las aplicaciones agrupadas en clúster y los dispositivos de red y las funciones, dependen de estas técnicas como una parte normal de su funcionamiento. Si es necesario, puede configurar un grupo de puertos independiente que permita este comportamiento y asociarle solo máquinas virtuales autorizadas.
- Evaluación mediante comandos de PowerCLI
-
Get-VMHost -Name $ESXi | Get-VirtualSwitch -Standard | Get-SecurityPolicy | select VirtualSwitch,ForgedTransmits Get-VMHost -Name $ESXi | Get-VirtualPortGroup -Standard | Get-SecurityPolicy | select VirtualPortGroup,ForgedTransmits
- Ejemplo de corrección mediante un comando de PowerCLI
-
Get-VMHost -Name $ESXi | Get-VirtualSwitch -Standard | Get-SecurityPolicy | Set-SecurityPolicy -ForgedTransmits $false Get-VMHost -Name $ESXi | Get-VirtualPortGroup -Standard | Get-SecurityPolicy | Set-SecurityPolicy -ForgedTransmitsInherited $true
Establecer la directiva de cambios de dirección MAC en Rechazar
Establezca la directiva de cambios de dirección MAC en Rechazar tanto en el conmutador estándar de vSphere como en sus grupos de puertos.
Si el sistema operativo de la máquina virtual cambia la dirección MAC, puede enviar marcos con una dirección MAC de origen suplantada, lo que le permite realizar ataques malintencionados en los dispositivos dentro de una red al suplantar un adaptador de red autorizado por la red receptora. Para evitar que las máquinas virtuales cambien su dirección MAC efectiva, se deben tomar medidas para aplicar la estabilidad de la dirección MAC o restringir la capacidad de modificar direcciones MAC. Esto mitiga el riesgo de suplantación de MAC y las posibles actividades malintencionadas.
- Impacto funcional potencial si se cambia el valor predeterminado
- Algunas cargas de trabajo, como las aplicaciones agrupadas en clúster, las funciones y los dispositivos de red, las aplicaciones con licencia por dirección MAC y la actualización con periodo de inactividad reducido de vCenter Server, dependen de estas técnicas como parte normal de su funcionamiento. Si es necesario, puede configurar un grupo de puertos independiente que permita este comportamiento y asociarle solo máquinas virtuales autorizadas.
Establecer la directiva de modo promiscuo en Rechazar
Establezca la directiva de modo promiscuo en Rechazar tanto en el conmutador estándar de vSphere como en sus grupos de puertos.
Cuando se habilita el modo promiscuo en un grupo de puertos, todas las máquinas virtuales conectadas a ese grupo de puertos tienen la posibilidad de leer todos los paquetes transmitidos a través de ese grupo de puertos, independientemente del destinatario previsto. Tenga en cuenta el impacto potencial y las consideraciones de diseño antes de cambiar el valor predeterminado del modo promiscuo.
- Impacto funcional potencial si se cambia el valor predeterminado
- Ciertas cargas de trabajo y tipos de trabajo, como los servidores DHCP, los dispositivos de red y la supervisión de seguridad, incorporan estas técnicas como parte regular de su funcionamiento. Si es necesario, puede configurar un grupo de puertos independiente que permita este comportamiento y asociarle solo máquinas virtuales autorizadas.
- Evaluación mediante comandos de PowerCLI
-
Get-VMHost -Name $ESXi | Get-VirtualSwitch -Standard | Get-SecurityPolicy | select VirtualSwitch,AllowPromiscuous Get-VMHost -Name $ESXi | Get-VirtualPortGroup -Standard | Get-SecurityPolicy | select VirtualPortGroup,AllowPromiscuous
- Ejemplo de corrección mediante un comando de PowerCLI
-
Get-VMHost -Name $ESXi | Get-VirtualSwitch -Standard | Get-SecurityPolicy | Set-SecurityPolicy -AllowPromiscuous $false Get-VMHost -Name $ESXi | Get-VirtualPortGroup -Standard | Get-SecurityPolicy | Set-SecurityPolicy -AllowPromiscuousInherited $true
Restringir el etiquetado de invitado virtual en conmutadores estándar
El host ESXi debe restringir el uso del etiquetado de invitado virtual (Virtual Guest Tagging, VGT) en los conmutadores estándar.
Cuando un grupo de puertos se establece en VLAN 4095, el vSwitch pasa todas las tramas de red a las máquinas virtuales asociadas sin modificar las etiquetas de VLAN. En vSphere, esto se conoce como VGT. La máquina virtual debe procesar la información de VLAN mediante un controlador 802.1Q en el sistema operativo.
VLAN 4095 solo debe implementarse si las máquinas virtuales asociadas tienen autorización específica y son capaces de administrar las etiquetas de VLAN por sí mismas. Si VLAN 4095 está habilitado de forma inadecuada, puede provocar una denegación del servicio o permitir que una máquina virtual interactúe con el tráfico en una VLAN no autorizada.
Activar la aplicación del arranque seguro
El arranque seguro forma parte del estándar del firmware UEFI. Con el arranque seguro UEFI activado, un host ESXi se niega a cargar cualquier aplicación o controlador UEFI, a menos que el cargador de arranque del sistema operativo tenga una firma digital válida. El arranque seguro de ESXi requiere la compatibilidad del firmware. El arranque seguro de ESXi también requiere que todos los módulos de kernel, los controladores y los VIB de ESXi estén firmados por VMware o un subordinado del socio.
El arranque seguro se activa en el BIOS del servidor físico ESXi y es compatible con el cargador de arranque del hipervisor. Este control cambia ESXi de simplemente admitir el arranque seguro a requerirlo. Sin esta configuración activada y sin el cifrado de la configuración, un host ESXi podría estar sujeto a ataques sin conexión. Un atacante simplemente podría transferir la unidad de instalación de ESXi a un host de arranque no seguro y realizar el arranque.
- Impacto funcional potencial si se cambia el valor predeterminado
- El uso del arranque seguro y el cifrado de configuración forzado por TPM hacen inutilizables los esfuerzos tradicionales de recuperación de la contraseña raíz. Asegúrese de no perder el acceso a las cuentas del administrador ESXi.
Desactivar ESXi Shell
ESXi Shell debe desactivarse.
UserVars.ESXiShellInteractiveTimeOut
Establece un tiempo de espera para finalizar automáticamente las sesiones de ESXi Shell y de SSH inactivas.
Si los usuarios se olvidan de cerrar la sesión de SSH, la conexión inactiva permanece abierta de forma indefinida, lo que aumenta la posibilidad de que otros usuarios obtengan acceso privilegiado al host. Puede configurar las sesiones de shell inactivas para que finalicen automáticamente.
Desactivar el servicio de SNMP
Desactive el servicio de SNMP si no lo está utilizando.
Desactivar el servicio de SSH
Desactive el SSH y actívelo solo para solucionar problemas.
ESXi no es un sistema operativo multiusuario similar a UNIX. ESXi es un hipervisor diseñado para que lo administren VMware Host Client, vSphere Client, las CLI y las API. En ESXi, SSH es una interfaz de solución de problemas y soporte, y se detiene y desactiva intencionalmente de forma predeterminada. La activación de la interfaz conlleva riesgos.
Usar entropía para las operaciones criptográficas
El host ESXi debe utilizar suficiente entropía para las operaciones criptográficas.
En vSphere 8.0 y versiones posteriores, la implementación de la entropía de ESXi admite las certificaciones FIPS 140-3 y EAL4. Las opciones de arranque del kernel controlan qué orígenes de entropía se activan en un host ESXi.
- Evaluación mediante comandos de PowerCLI
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $ESXcli.system.settings.kernel.list.Invoke() | Where {$_.Name -eq "disableHwrng" -or $_.Name -eq "entropySources"}
- Ejemplo de corrección mediante un comando de PowerCLI
-
$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)
Comprobar el perfil de imagen y los niveles de aceptación de VIB
El nivel de aceptación del perfil de imagen del host ESXi debe ser PartnerSupported o superior.
El nivel de aceptación controla lo que ESXi permite que se instale. Consulte Administrar los niveles de aceptación de los hosts ESXi y los paquetes de instalación de vSphere para conocer los niveles de VIB.
Ni VMware ni los socios de VMware prueban los VIB CommunitySupported, ni los VIB CommunitySupported contienen una firma digital. Por estos motivos, tenga cuidado al instalar los VIB CommunitySupported.
- Impacto funcional potencial si se cambia el valor predeterminado
- Los paquetes CommunitySupported no están firmados y no se pueden instalar.
- Evaluación mediante comandos de PowerCLI
-
(Get-EsxCli -VMHost $ESXi -V2).software.acceptance.get.Invoke()
- Ejemplo de corrección mediante un comando de PowerCLI
-
$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
El host ESXi debe desbloquear las cuentas después de un tiempo de espera especificado.
Security.AccountUnlockTime garantiza que las cuentas de usuario del host ESXi se desbloqueen automáticamente después de un periodo definido de inactividad. Al aplicar el desbloqueo automático de cuentas, las organizaciones pueden mantener un equilibrio entre la seguridad y la capacidad de uso, lo que garantiza que las cuentas inactivas se reactiven con rapidez, a la vez que se minimiza la posibilidad de acceso no autorizado.
Security.AccountLockFailures
Establece el recuento máximo de intentos de inicio de sesión fallidos antes de bloquear la cuenta.
Brinda protección contra ataques por fuerza bruta e intentos de acceso no autorizado al deshabilitar temporalmente la cuenta afectada, lo que evita que se produzcan más intentos de inicio de sesión hasta que el periodo de bloqueo caduque o un administrador lo restablezca manualmente. Para desbloquear una cuenta bloqueada, es necesario realizar una acción administrativa o esperar a que la cuenta se desbloquee de forma automática si se utiliza la configuración de Security.AccountUnlockTime.
- Impacto funcional potencial si se cambia el valor predeterminado
- Un umbral bajo para errores de inicio de sesión puede aumentar los ataques de denegación del servicio, ya sean intencionales o accidentales, como con reintentos de conexión SSH.
Security.PasswordHistory
No permite la reutilización de contraseñas.
Esta opción evita la reutilización de contraseñas anteriores, lo que mitiga las posibles infracciones por credenciales antiguas y vulneradas.
Security.PasswordMaxDays
Establece el número máximo de días entre cambios de contraseña.
Las prácticas recomendadas modernas para contraseñas, tal como se describe en la sección 5.1.1.2 de NIST 800-63B y otras guías relevantes, indican que la aplicación de cambios periódicos de contraseñas no mejora la seguridad cuando las contraseñas ya poseen una entropía adecuada.
Security.PasswordQualityControl
Exige la complejidad de la contraseña.
En las recomendaciones como la Sección 5.1.1.2 de NIST 800-63B se sugiere que las reglas de composición, por ejemplo, que exigen mezclas de clases de caracteres, no deben aplicarse en los sistemas, ya que a menudo no mejoran la seguridad de las contraseñas y desalientan la adopción de frases de contraseña más seguras.
Las reglas de seguridad y complejidad de contraseñas se aplican a todos los usuarios ESXi, incluido el usuario raíz. Sin embargo, cuando el host ESXi está unido a un dominio, estas reglas no se aplican a los usuarios de Active Directory (AD), ya que el sistema de AD aplica las directivas de contraseña para los usuarios de AD.
- Impacto funcional potencial si se cambia el valor predeterminado
- Es posible que otros productos y servicios dentro del ecosistema de VMware no esperen cambios en los requisitos de complejidad de la contraseña y se produzca un error en la instalación.
UserVars.SuppressHyperthreadWarning
Suprime la advertencia de una posible vulnerabilidad de seguridad de hiperproceso.
Las advertencias de seguridad del hiperproceso significan vulnerabilidades de CPU no atendidas en el sistema. Ignorar estas advertencias podría enmascarar posibles riesgos. Asegúrese de que las correcciones de hardware correspondan con el riesgo aceptado de su organización. Cuando elimine una advertencia, documente la decisión y la justificación.
UserVars.DcuiTimeOut
Establece un tiempo de espera para finalizar de forma automática las sesiones de DCUI inactivas.
La DCUI permite el inicio de sesión directo en el host ESXi para las tareas de administración. Para evitar el uso no intencionado de la DCUI de sesiones de inicio de sesión sobrantes, finalice las conexiones inactivas.
Desactivar el servicio de CIM
El servicio de CIM ESXi debe desactivarse.
Los servicios que no están en uso y que no son esenciales para las operaciones deben desactivarse.
Config.HostAgent.log.level
Establece el nivel informativo de registro.
Al configurar el nivel de registro, asegúrese de que haya suficiente información en los registros de auditoría para realizar diagnósticos y análisis forenses.
- Impacto funcional potencial si se cambia el valor predeterminado
- Los registros consumen espacio de almacenamiento adicional.
Syslog.global.logLevel
Registra suficiente información de los eventos.
Sin suficientes datos de registro, los indicadores críticos de compromiso pueden pasar inadvertidos, lo que lleva a una mayor vulnerabilidad y posible incapacidad de responder de forma eficaz a los incidentes de ciberseguridad.
- Impacto funcional potencial si se cambia el valor predeterminado
- Los registros consumen espacio de almacenamiento adicional.
Config.HostAgent.plugins.solo.enableMob
Desactiva el explorador de objetos administrados (Managed Object Browser, MOB).
Los servicios que no están en uso y que no son esenciales para las operaciones deben desactivarse.
Net.BlockGuestBPDU
Bloquea las transmisiones de la unidad de datos de protocolo de puente (BPDU) del sistema operativo invitado.
Las BPDU se utilizan para transmitir información del protocolo de árbol de expansión (STP) y detectar bucles de red. BPDU Guard y Portfast se activan normalmente en el conmutador físico conectado directamente al host ESXi para reducir el retraso de convergencia del árbol de expansión.
Sin embargo, si se envía un paquete de la BPDU desde una máquina virtual en el host ESXi al conmutador físico configurado, puede provocar un bloqueo en cascada de todas las interfaces de enlace ascendente del host ESXi. Para evitar este tipo de bloqueo, puede activar el filtro de la BPDU en el host ESXi para descartar cualquier paquete de la BPDU que se envíe al conmutador físico.
Los conmutadores virtuales estándar y distribuidos no admiten STP y no generan BPDU.
- Impacto funcional potencial si se cambia el valor predeterminado
- Algunas cargas de trabajo orientadas a redes pueden generar paquetes de BPDU de forma legítima. Compruebe que no haya paquetes de BPDU legítimos generados por las máquinas virtuales en el host ESXi antes de habilitar el filtro de BPDU. Si el filtro de BPDU está activado en esta situación, la habilitación de Rechazar transmisiones falsificadas en el grupo de puertos del conmutador virtual agrega protección contra bucles del árbol de expansión.
Net.DVFilterBindIpAddress
Restringe el uso de las API de red dvFilter.
Si no utiliza un producto como VMware NSX que utiliza la API de red dvFilter, no configure el host ESXi para enviar información de red a una dirección IP. Habilitar la API y hacer referencia a una dirección IP comprometida podría proporcionar acceso no autorizado a la red de otras máquinas virtuales en el host ESXi.
Si utiliza un producto que se basa en esta API, es importante comprobar que el host ESXi se haya configurado correctamente para garantizar una comunicación de red segura.
UserVars.ESXiShellTimeOut
Establece un tiempo de espera para limitar el tiempo de ejecución de los servicios de ESXi Shell y SSH.
Esta configuración avanzada del sistema define una ventana de tiempo después de la cual los servicios ESXi Shell y SSH finalizan automáticamente.
UserVars.SuppressShellWarning
Suprime la advertencia para las interfaces de soporte y solución de problemas.
El host ESXi no debe suprimir las advertencias de que ESXi Shell está activado.
Las advertencias que indican que SSH o ESXi Shell están activados pueden indicar que hay un ataque en curso. Es importante asegurarse de que SSH y ESXi Shell estén desactivados, y que esta configuración avanzada del sistema no esté activada.
Configurar el daemon de Shell seguro ESXi para FIPS
El daemon de shell seguro (SSH) del host ESXi debe configurarse para utilizar solo cifrados validados por FIPS 140-2/140-3. Debe fortalecer y proteger los servicios del sistema cuando se activan.
- Valores
- Valor predeterminado de instalación: [email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
- Evaluación mediante comandos de PowerCLI
-
$ESXcli = Get-EsxCli -VMHost $ESXi -V2 $ESXcli.system.ssh.server.config.list.invoke() | Where-Object {$_.Key -eq 'ciphers'} | Select-Object -ExpandProperty Value
- Ejemplo de corrección mediante un comando de PowerCLI
-
$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)
Configurar el daemon SSH de ESXi para FIPS
El daemon SSH del host ESXi debe utilizar módulos criptográficos validados por FIPS 140-2/140-3.
OpenSSH en el host ESXi se envía con un módulo criptográfico validado por FIPS 140-2/140-3, activado de forma predeterminada. Por motivos de compatibilidad con versiones anteriores, puede desactivar este módulo. Audite y corrija si es necesario.
Configurar el daemon de Shell seguro ESXi para que no permita puertos de puerta de enlace
El daemon de Shell seguro (SSH) del host ESXi debe configurarse para que no permita puertos de puerta de enlace.
Debe fortalecer y proteger los servicios del sistema cuando se activan.
Configurar el daemon de Shell seguro ESXi para que no utilice la autenticación basada en el host
El daemon de Shell seguro (SSH) del host ESXi no debe permitir la autenticación basada en el host.
Debe fortalecer y proteger los servicios del sistema cuando se activan.
Configurar el daemon de Shell seguro ESXi para establecer un recuento de tiempo de espera
El daemon de Shell seguro (SSH) del host ESXi debe establecer un recuento de tiempo de espera para las sesiones inactivas.
Debe fortalecer y proteger los servicios del sistema cuando se activan. El recuento de tiempo de espera multiplicado por el intervalo de tiempo de espera de inactividad es el número total de segundos que la sesión puede estar inactiva hasta que se desconecte.
Configurar el daemon de Shell seguro ESXi para establecer un intervalo de tiempo de espera
El daemon de Shell seguro (SSH) del host ESXi debe establecer un recuento de tiempo de espera para las sesiones inactivas.
Debe fortalecer y proteger los servicios del sistema cuando se activan. El recuento de tiempo de espera multiplicado por el intervalo de tiempo de espera de inactividad es el número total de segundos que la sesión puede estar inactiva hasta que se desconecte.
Configurar el daemon de Shell seguro ESXi para que muestre un aviso de inicio de sesión
El daemon de shell seguro (SSH) del host ESXi debe mostrar el aviso de inicio de sesión del sistema antes de conceder acceso a este.
Debe fortalecer y proteger los servicios del sistema cuando se activan. También debe establecer la configuración de Config.Etc.issue para proporcionar texto a este aviso.
Configurar el daemon de Shell seguro ESXi para ignorar los archivos .rhosts
El daemon de Shell seguro (SSH) del host ESXi debe ignorar los archivos .rhosts.
Debe fortalecer y proteger los servicios del sistema cuando se activan.
Configurar el daemon de Shell seguro ESXi para desactivar el reenvío local de transmisión
El daemon de Shell seguro (SSH) del host ESXi debe desactivar el reenvío local de transmisión.
Debe fortalecer y proteger los servicios del sistema cuando se activan.
Configurar el daemon de Shell seguro ESXi para desactivar el reenvío de TCP
El daemon de shell seguro (SSH) del host ESXi debe desactivar el reenvío de TCP.
Debe fortalecer y proteger los servicios del sistema cuando se activan.
Configurar el daemon de Shell seguro ESXi para que no permita túneles
El daemon de Shell seguro (SSH) del host ESXi no debe permitir túneles.
Debe fortalecer y proteger los servicios del sistema cuando se activan.
Configurar el daemon de Shell seguro ESXi para que no permita la configuración del entorno del usuario
El daemon de Shell seguro (SSH) del host ESXi no debe permitir la configuración del entorno del usuario.
Debe fortalecer y proteger los servicios del sistema cuando se activan.
Desactivar el servicio del protocolo de ubicación de servicios
Desactive el servicio del protocolo de ubicación de servicios (SLP) si no lo está utilizando.
Mem.ShareForceSalting
Restringe el uso compartido transparente de páginas a las máquinas virtuales que están configuradas con sched.mem.pshare.salt.
El uso compartido transparente de páginas (TPS) es un método para reducir el espacio de memoria de las máquinas virtuales. En condiciones altamente controladas, los atacantes pueden utilizar el TPS para obtener acceso no autorizado a los datos de las máquinas virtuales vecinas. Las máquinas virtuales que no tienen establecida la configuración de sched.mem.pshare.salt no pueden compartir memoria con otras máquinas virtuales. Los tamaños de página grandes, una optimización del rendimiento en el hipervisor en muchas CPU modernas, no son compatibles con TPS.
UserVars.HostClientSessionTimeout
Establece un tiempo de espera para finalizar automáticamente las sesiones del cliente del host ESXi inactivas.
El host ESXi debe finalizar automáticamente las sesiones del cliente del host inactivas. Esta práctica mitiga los posibles riesgos de seguridad al garantizar que las sesiones sin supervisión, que los usuarios no autorizados o el software malicioso podrían aprovechar, no se dejen abiertas de forma indefinida.
Net.BMCNetworkEnable
Desactiva las interfaces de red de administración de hardware virtual.
Las controladoras de administración de hardware suelen presentar NIC virtuales o USB al host ESXi. Se pueden utilizar como puertas traseras y deben desactivarse tanto en la configuración del hardware como en la configuración de ESXi.
- Impacto funcional potencial si se cambia el valor predeterminado
- Algunas soluciones administradas de terceros pueden requerir esta funcionalidad.
Activar la autenticación de CHAP bidireccional/mutua para el tráfico iSCSI
Establezca la autenticación del adaptador de almacenamiento iSCSI en "Usar CHAP bidireccional" y proporcione las credenciales.
El CHAP mutuo proporciona una capa adicional de protección, ya que requiere que tanto el iniciador (cliente) como el destino (servidor) verifiquen sus identidades entre sí, lo que garantiza que las entidades no autorizadas no intercepten ni alteren los datos transmitidos entre los dos.
No almacenar claves de cifrado en hosts ESXi sin proteger el acceso físico
El host ESXi no debe almacenar claves de cifrado en el propio host ESXi sin proteger el acceso físico al host.
La persistencia de claves es un mecanismo que utiliza un módulo de plataforma de confianza (TPM) local para almacenar claves del proveedor de claves estándar, que generalmente solo se encuentran en un sistema de administración de claves (KMS) externo. Si bien esta configuración puede mejorar la administración de dependencias, el uso de la persistencia de claves cambia los riesgos de cifrado. Si un atacante roba el host, tiene acceso a las claves de cifrado de los datos de ese host, lo que omite los controles de acceso del KMS externo. Por lo tanto, utilice la persistencia de claves solo cuando pueda garantizar la seguridad física de los hosts. Si los hosts físicos no son seguros y un atacante puede robar el host, el atacante también tiene los medios para acceder y utilizar cargas de trabajo cifradas.
La persistencia de claves y vSphere Native Key Provider a menudo se mezclan debido a que ambos almacenan datos de cifrado en los hosts. Sin embargo, vSphere Native Key Provider no utiliza la persistencia de claves, por lo que desactivar la persistencia de claves no lo afectará. Al igual que la persistencia de claves, vSphere Native Key Provider también requiere de una consideración cuidadosa de la seguridad física. Consulte Referencia de controles de seguridad para diseño del sistema de vSphere.
- Impacto funcional potencial si se cambia el valor predeterminado
- El comportamiento deseado es el predeterminado. Cambiar el valor predeterminado puede afectar negativamente la confidencialidad en entornos donde es posible el acceso físico por parte de los atacantes.
