Hola a tod@s
En esta oportunidad veremos algunos de los principales parámetros para aumentar la seguridad de nuestra infraestructura vSphere, haciendo uso de VMware vSphere Security Configuration Guide 7.
Tratare de resumir los principales datos necesarios para entender esta guía, que puede llegar a ser algo confusa para algunos por lo que la ordene de tal manera que pueda ser más simple de entender, que parámetro se recomienda modificar, descripción, motivo y comando para modificarlo a través de VMware PowerCLI.
VMware vSphere Security Configuration Guide 7, ESXi Controls – Part 1
Para poder ejecutar los comandos necesarios para verificar o modificar los parámetros, tendremos que tener instalado y configurado VMware PowerCLI.
En el siguiente post que cree están los pasos necesarios “Introducción e instalación de VMware PowerCLI 12.3.0“
Lo primero que haré en este laboratorio será conectarme al host ESXi que usare para la demostración con el comando:
PS C:WINDOWSsystem32> Connect-VIServer -Server 10.10.10.201 -Protocol https -User root -Password {password}
Nota: Existen muchas más formas de automatizar o conectarnos a nuestra maquinas, pero en este laboratorio usare una forma simple.
Esta primera parte veremos 10 parámetros indicados en la guía.
esxi-7.account-lockout
| Parámetros de configuración | Valor deseado | Valor por defecto | Acción necesaria |
| Security.AccountLockFailures | 3 | 10 | Modificar |
Descripción: Establece el número máximo de intentos fallidos de inicio de sesión antes de que la cuenta se bloquee. El valor 0 deshabilita el bloqueo de la cuenta.
Motivo para el cambio: Múltiples fallos en el inicio de sesión de la misma cuenta pueden indicar un problema de seguridad. Estos intentos de fuerza bruta del sistema deben limitarse bloqueando la cuenta tras alcanzar un umbral.
Ejecutamos el siguiente comando para ver el valor actual del parámetro:
PS C:WINDOWSsystem32> Get-VMHost | Get-AdvancedSetting Security.AccountLockFailures
Modificamos el parámetro con el comando:
PS C:WINDOWSsystem32> Get-VMHost | Get-AdvancedSetting Security.AccountLockFailures | Set-AdvancedSetting -Value 3
Nota importante: La cuenta se bloquearía y requeriría una acción administrativa para desbloquear la cuenta o un tiempo de espera para que la cuenta se desbloquee automáticamente.
esxi-7.account-password-history
| Parámetros de configuración | Valor deseado | Valor por defecto | Acción necesaria |
| Security.PasswordHistory | 5 | 0 | Modificar |
Descripción: Cantidad máxima permitida de intentos de inicio de sesión con errores antes de bloquear la cuenta del usuario. El valor 0 deshabilita el bloqueo de la cuenta.
Motivo para el cambio: Debido a las directrices de complejidad de las contraseñas, los usuarios a veces intentan reutilizar contraseñas antiguas. Este ajuste lo impide.
Ejecutamos el siguiente comando para ver el valor actual del parámetro:
PS C:WINDOWSsystem32> Get-VMHost | Get-AdvancedSetting Security.PasswordHistory
Modificamos el parámetro con el comando:
PS C:WINDOWSsystem32> Get-VMHost | Get-AdvancedSetting Security.PasswordHistory | Set-AdvancedSetting -Value 5
esxi-7.account-password-policies
| Parámetros de configuración | Valor deseado | Valor por defecto | Acción necesaria |
| Security.PasswordQualityControl | Site-Specific | retry=3 min=disabled,disabled,disabled,7,7 | Modificar |
Descripción: Establecer una política de complejidad de las contraseñas.
Motivo para el cambio: Es importante utilizar contraseñas que no sean fáciles de adivinar y que sean difíciles de determinar para los generadores de contraseñas. Las reglas de fortaleza y complejidad de las contraseñas se aplican a todos los usuarios de ESXi, incluido el root. No se aplican a los usuarios de Active Directory cuando el host ESX está unido a un dominio, ya que esas políticas de contraseña son aplicadas por AD. Para más detalles podemos revisar: https://docs.vmware.com/en/VMware vSphere/7.0/com.vmware.vsphere.security.doc/GUID-DC96FFDB-F5F2-43EC-8C73-05ACDAE6BE43.html
Ejecutamos el siguiente comando para ver el valor actual del parámetro:
PS C:WINDOWSsystem32> Get-VMHost | Get-AdvancedSetting Security.PasswordQualityControl
La configuración en este punto es un valor que cada organización define según sus necesidades. En mi caso esta configuración funciono para este laboratorio: “retry=3 min=4,4,4,7,7 passphrase=1”
PS C:WINDOWSsystem32> Get-VMHost | Get-AdvancedSetting Security.PasswordQualityControl | Set-AdvancedSetting -Value “retry=3 min=4,4,4,7,7 passphrase=1“
Nota importante: Es necesario poder tomarnos un tiempo para averiguar la mejor combinación. Podemos obtener una idea mirando el post realizado en el blog: How to disable VMware ESXi complex passwords and why you should not do it.
Como podrán ver en este post, puede que no siempre sea la mejor opción cambiar este parámetro, por lo cual queda a su criterio.
esxi-7.disable-mob
| Parámetros de configuración | Valor deseado | Valor por defecto | Acción necesaria |
| Config.HostAgent.plugins.solo.enableMob | False | False | Auditar |
Descripción: Verificar que esta deshabilitado Managed Object Browser (MOB).
Motivo para el cambio: El managed object browser(MOB) proporciona una forma de explorar el modelo de objetos utilizado por el VMkernel para gestionar el host; también permite cambiar las configuraciones. Esta interfaz está destinada a ser utilizada principalmente para la depuración del SDK de vSphere. Es necesario auditar nuestros servidores ESXi para asegurarse de que alguien no ha activado el MOB. Por defecto esta deshabilitado desde la versión 6.
Ejecutamos el siguiente comando para ver el valor actual del parámetro:
PS C:Usersamira> Get-VMHost | Get-AdvancedSetting Config.HostAgent.plugins.solo.enableMob
Modificamos el parámetro en caso de estar habilitado con el comando:
PS C:Usersamira> Get-VMHost | Get-AdvancedSetting Config.HostAgent.plugins.solo.enableMob | Set-AdvancedSetting -Value False
Nota importante: Es fundamental verificar si nuestros host ESXi no tengan habilitado MOB. Debido a que no hay controles de acceso, podría ser utilizado como un método para obtener información sobre un host que está siendo objetivo para un acceso no autorizado.
esxi-7.account-auto-unlock-time
| Parámetros de configuración | Valor deseado | Valor por defecto | Acción necesaria |
| Security.AccountUnlockTime | 900 | 120 | Modificar |
Descripción: Desbloquear automáticamente una cuenta bloqueada después de un tiempo determinado.
Motivo para el cambio: Múltiples fallos en el inicio de sesión de la misma cuenta pueden indicar un problema de seguridad. Estos intentos de fuerza bruta en el sistema deberían limitarse bloqueando la cuenta tras alcanzar un umbral. Sin embargo, como esto puede utilizarse para denegar el servicio, a menudo se especifica un periodo de desbloqueo.
Ejecutamos el siguiente comando para ver el valor actual del parámetro:
PS C:Usersamira> Get-VMHost | Get-AdvancedSetting Security.AccountUnlockTime
Modificamos el parámetro con el comando:
PS C:Usersamira> Get-VMHost | Get-AdvancedSetting Security.AccountUnlockTime | Set-AdvancedSetting -Value 900
esxi-7.hardware-secure-boot
| Parámetros de configuración | Valor deseado | Valor por defecto | Acción necesaria |
| N/A | Enabled | Enabled | Auditar |
Descripción: Secure boot es una característica del BIOS UEFI que refuerza la seguridad del sistema operativo al asegurarse de que todo el código que se carga en el arranque está firmado digitalmente y no ha sido manipulado.
Es posible que haya algunos paquetes de terceros (‘VIB’, en lenguaje vSphere) que tengan el ‘Nivel de aceptación’ incorrecto y puedan impedir que el arranque seguro funcione correctamente. Para comprobar si el host ESXi ya tiene habilitado el arranque seguro y si existen obstáculos para habilitarlo, ejecute los dos comandos siguientes desde una línea de comandos de ESXi (SSH):
Motivo para el cambio: La habilitación de UEFI Secure Boot en el hardware del host ESXi ayuda a prevenir el malware y las configuraciones no confiables.
Ejecutamos el siguiente comando para comprobar si Secure Boot está habilitado:
[root@esxilab:~] /usr/lib/vmware/secureboot/bin/secureBoot.py -s
Verificamos que no tengamos problemas con el Secure Boot ejecutando el siguiente comando:
[root@esxilab:~] /usr/lib/vmware/secureboot/bin/secureBoot.py -c
Listamos la configuración actual con el comando:
Habilitamos el Secure Boot con el siguiente procedimiento:
[root@esxilab:~] esxcli system settings encryption set –require-secure-boot=TRUE
Para más detalle podemos revisar la documentación de VMware.
esxi-7.vib-trusted-binaries
| Parámetros de configuración | Valor deseado | Valor por defecto | Acción necesaria |
| VMkernel.Boot.execInstalledOnly | Enabled | False | Modificar |
Descripción: Esta configuración prohíbe la ejecución de código personalizado dentro de ESXi y hará que el host ESXi no permita la instalación de ningún paquete VIB que este firmado por algún partner certificado.
Motivo para el cambio: ESXi lleva a cabo comprobaciones de integridad de los “vSphere Installable Bundles” o VIBs, gobernados por el Nivel de Aceptación. Instruir a ESXi para que sólo ejecute los binarios que se originan a partir de un VIB válido instalado en el host dificulta a los atacantes el uso de kits de herramientas preconstruidos durante un ataque, y aumenta las posibilidades de detección.
Verificamos la configuración actual con el comando:
PS C:WINDOWSsystem32> Get-VMHost | Get-AdvancedSetting VMkernel.Boot.execInstalledOnly
Modificamos el comando usando PowerCLI con el comando:
PS C:WINDOWSsystem32> Get-VMHost | Get-AdvancedSetting VMkernel.Boot.execInstalledOnly | Set-AdvancedSetting -Value True
Podemos comprobar el cambio entrando al host por SSH y ejecutando el siguiente comando:
[root@esxilab:~] esxcli system settings kernel list -o execinstalledonly
Como podemos ver el parámetro runtime aún sigue estando en “False“. Esto se debe a que el host requiere un reinicio para que la configuración tenga efecto.
Nota importante: Las herramientas de terceros instaladas fuera de los VIB certificados pueden dejar de funcionar. Esto puede provocar que el host no vuelva arrancar correctamente, por lo cual hay que tener mucho cuidado con esta configuración.
En caso de presentar problemas con el boot del host, podemos revisar el siguiente KB81446 de VMware.
esxi-7.updates
| Parámetros de configuración | Valor deseado | Valor por defecto | Acción necesaria |
| N/A | N/A | N/A | Auditar |
Descripción: Mantener ESXi actualizado.
Motivo para el cambio: Si se mantienen al día los parches de ESXi, se pueden mitigar las vulnerabilidades del hipervisor. Un atacante experimentado puede explotar las vulnerabilidades conocidas al intentar obtener acceso o elevar los privilegios en un host ESXi.
Actualice siempre primero vCenter Server (si hay una actualización disponible), y luego ESXi.
En el VMware KB 7821 podemos ver la secuencia correcta a seguir para actualizar productos compatibles de VMware con vSphere 7.
Como vemos en la tabla, antes de pensar en actualizar vCenter server o los ESXi, tendremos que actualizar primero varios productos de VMware (en caso que contemos con ellos en nuestra infraestructura).
Podemos comprobar la compilación actual con el siguiente comando:
PS C:WINDOWSsystem32> Get-VMHost | Select-Object Name,Version,Build
Compare los números de compilación de ESXi con la última versión disponible en VMware KB2143832.
Podemos revisar el siguiente post “vSphere 7 – Update Planner” para actualizar nuestro host ESXi.
esxi-7.timekeeping
| Parámetros de configuración | Valor deseado | Valor por defecto | Acción necesaria |
| N/A | Site-Specific | Null | Modificar |
Descripción: Configurar NTP o PTP
Motivo para el cambio: La criptografía, el registro de auditoría, las operaciones de cluster y la respuesta a incidentes/forense dependen en gran medida de la sincronización de la hora. La recomendación para NTP es tener al menos cuatro fuentes. No tengas dos fuentes (una fuente es preferible a dos).
Podemos ver el status actual de la configuración de NTP con los siguientes comandos:
PS C:WINDOWSsystem32> Get-VMHost | Select Name, @{N=”NTPSetting”;E={$_ | Get-VMHostNtpServer}}
PS C:WINDOWSsystem32> Get-VMHostService -VMHost * | Where-Object {$_.Key -eq ‘ntpd’}
Creamos una variable que contenga los servidores NTP que queramos agregar:
PS C:WINDOWSsystem32> $ntpServers = “0.pool.ntp.org”, “1.pool.ntp.org”, “2.pool.ntp.org”, “3.pool.ntp.org”
Agregamos los servidores NTP a nuestro host ESXi con el comando:
PS C:WINDOWSsystem32> Get-VMHost | Add-VmHostNtpServer $NTPServers
Modificamos la política para usar NTP con el comando:
PS C:WINDOWSsystem32> Get-VMHostService -VMHost * | where {$_.Key -eq ‘ntpd’} | Set-VMHostService -Policy On
Iniciamos el servicio con el comando:
PS C:WINDOWSsystem32> Get-VMHostService -VMHost * | where {$_.Key -eq ‘ntpd’} | Start-VMHostService
esxi-7.supported
| Parámetros de configuración | Valor deseado | Valor por defecto | Acción necesaria |
| N/A | N/A | N/A | Auditar |
Descripción: La versión de ESXi esta mantenimiento activo por parte de VMware.
Motivo: Verificar que nuestra versión actual de ESXi no alcanzado el status de End of Support.
Podemos comprobar la compilación actual con el siguiente comando:
PS C:WINDOWSsystem32> Get-VMHost | Select-Object Name,Version,Build
En próximos post seguiré viendo más parámetros de la guía: VMware vSphere Security Configuration Guide 7.
Espero que esta información pueda ser de ayuda. Si tienes dudas o alguna acotación sobre este post, déjalo en comentarios. Saludos.