Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the value of the "Restrict reuse" setting. If the "Restrict reuse" policy is not set to 5 or more, this is a finding.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit" and enter "5" into the "Restrict reuse" setting and click "OK".
On the system where vCenter is installed locate the webclient.properties file. Windows: C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Appliance: /etc/vmware/vsphere-client/ Find the refresh.rate = line in the webclient.properties file. If the refresh rate is not set to -1 in the webclient.properties file, this is a finding.
You can change the refresh rate value by editing the webclient.properties file. On the system where vCenter is installed locate the webclient.properties file. Windows: C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Appliance: /etc/vmware/vsphere-client/ Edit the file to include the line "refresh.rate = -1" where -1 indicates sessions are not automatically refreshed. Uncomment the line if necessary. After editing the file the vSphere Web Client service must be restarted.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the value of the "Maximum lifetime" setting. If the "Maximum lifetime" policy is not set to 60, this is a finding.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click "Edit" and enter "60" into the "Maximum lifetime" setting and click "OK".
By default, vSphere Web Client sessions terminate after 120 minutes of idle time, requiring the user to log in again to resume using the client. You can view the timeout value by viewing the webclient.properties file. On the system where vCenter is installed locate the webclient.properties file. Windows: C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Appliance: /etc/vmware/vsphere-client/ Find the session.timeout = line in the webclient.properties file. If the session timeout is not set to 10 in the webclient.properties file, this is a finding.
You can change the timeout value by editing the webclient.properties file. On the system where vCenter is installed locate the webclient.properties file. Windows: C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client Appliance: /etc/vmware/vsphere-client/ Edit the file to include the line "session.timeout = 10" where 10 is the timeout value in minutes. Uncomment the line if necessary. After editing the file the vSphere Web Client service must be restarted.
From the vSphere Web Client go to Administration >> Access Control >> Roles. View each role and verify the users and/or groups assigned to it. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VIPermission | Sort Role | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto Application service account and user required privileges should be documented. If any user or service account has more privileges than required, this is a finding.
To create a new role with specific permissions do the following: From the vSphere Web Client go to Administration >> Access Control >> Roles. Click the green plus sign and enter a name for the role and select only the specific permissions required. Users can then be assigned to the newly created role.
From the vSphere Web Client go to Networking >> Select a distributed switch >> Manage >> Settings >> Properties. View the Properties pane and verify Network I/O Control is enabled. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VDSwitch | select Name,@{N="NIOC Enabled";E={$_.ExtensionData.config.NetworkResourceManagementEnabled}} If Network I/O Control is disabled, this is a finding.
From the vSphere Web Client go to Networking >> Select a distributed switch >> Manage >> Settings >> Properties. In the Properties pane click "Edit" and change Network I/O Control to enabled. or From a PowerCLI command prompt while connected to the vCenter server run the following command: (Get-VDSwitch "DVSwitch Name" | Get-View).EnableNetworkResourceManagement($true)
From the vSphere Client select the vCenter server at the top of the hierarchy and go to >> Alarms >> Definitions. Verify there is an alarm created to alert if an ESXi host can no longer reach its syslog server. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-AlarmDefinition | Where {$_.ExtensionData.Info.Expression.Expression.EventTypeId -eq "esx.problem.vmsyslogd.remote.failure"} | Select Name,Enabled,@{N="EventTypeId";E={$_.ExtensionData.Info.Expression.Expression.EventTypeId}} If an alarm is not created to alert when syslog failures occur, this is a finding.
From the vSphere Client select the vCenter server at the top of the hierarchy and go to >> Alarms >> Definitions >> Right click in the empty space and select New Alarm. On the General tab provide an alarm name and description, Select Hosts for alarm type and "Monitor for specific events occurring on this object", check "Enable this alarm". On the Triggers tab click Add and in the event column enter "esx.problem.vmsyslogd.remote.failure" and click OK. Note - This alarm will only trigger if syslog is configured for TCP or SSL connections and not UDP.
Verify the Windows server hosting vCenter is joined to the domain and access to the server and to vCenter is done using Active Directory accounts. If the vCenter server is not joined to an Active Directory domain, this is a finding. If Active Directory based accounts are not used for daily operations of the vCenter server, this is a finding. If Active Directory is not used in the environment, this is not applicable.
If the server hosting vCenter is not joined to the domain follow the OS specific procedures to join it to Active Directory. If local accounts are used for normal operations then Active Directory accounts should be created and used.
Verify the built-in SSO administrator account is only used for emergencies and situations where it is the only option due to permissions. If the built-in SSO administrator account is used for daily operations or there is no policy restricting its use, this is a finding.
A policy should be developed to limit the use of the built-in SSO administrator account.
From the vSphere Web Client go to Networking >> Select a distributed switch >> Manage >> Settings >> Health Check. View the health check pane and verify both checks are disabled. or From a PowerCLI command prompt while connected to the vCenter server run the following commands: $vds = Get-VDSwitch $vds.ExtensionData.Config.HealthCheckConfig If the health check feature is enabled on distributed switches and is not on temporarily for troubleshooting purposes, this is a finding.
From the vSphere Web Client go to Networking >> Select a distributed switch >> Manage >> Settings >> Health Check. Click the edit button and disable both health checks. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-View -ViewType DistributedVirtualSwitch | ?{($_.config.HealthCheckConfig | ?{$_.enable -notmatch "False"})}| %{$_.UpdateDVSHealthCheckConfig(@((New-Object Vmware.Vim.VMwareDVSVlanMtuHealthCheckConfig -property @{enable=0}),(New-Object Vmware.Vim.VMwareDVSTeamingHealthCheckConfig -property @{enable=0})))}
From the vSphere Client go to Home >> Networking. Select a distributed port group and click edit and go to security and verify "Forged Transmits" is set to reject. or From a PowerCLI command prompt while connected to the vCenter server run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy If the "Forged Transmits" policy is set to accept for a non-uplink port, this is a finding.
From the vSphere Client go to Home >> Networking. Select a distributed port group and click edit and go to security and set "Forged Transmits" to reject. or From a PowerCLI command prompt while connected to the vCenter server run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -ForgedTransmits $false Get-VDPortgroup | ?{$_.IsUplink -eq $false} | Get-VDSecurityPolicy | Set-VDSecurityPolicy -ForgedTransmits $false
From the vSphere Client go to Home >> Networking. Select a distributed port group and click edit and go to security and verify "MAC Address Changes" is set to reject. or From a PowerCLI command prompt while connected to the vCenter server run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | Get-VDSecurityPolicy If the "MAC Address Changes" policy is set to accept, this is a finding.
From the vSphere Client go to Home >> Networking. Select a distributed port group and click edit and go to security and set "MAC Address Changes" to reject. or From a PowerCLI command prompt while connected to the vCenter server run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -MacChanges $false Get-VDPortgroup | Get-VDSecurityPolicy | Set-VDSecurityPolicy -MacChanges $false
From the vSphere Client go to Home >> Networking. Select a distributed port group and click edit and go to security and verify "Promiscuous Mode" is set to reject. or From a PowerCLI command prompt while connected to the vCenter server run the following commands: Get-VDSwitch | Get-VDSecurityPolicy Get-VDPortgroup | Get-VDSecurityPolicy If the "Promiscuous Mode" policy is set to accept, this is a finding.
From the vSphere Client go to Home >> Networking. Select a distributed port group and click edit and go to security and set "Promiscuous Mode" to reject. or From a PowerCLI command prompt while connected to the vCenter server run the following commands: Get-VDSwitch | Get-VDSecurityPolicy | Set-VDSecurityPolicy -AllowPromiscuous $false Get-VDPortgroup | Get-VDSecurityPolicy | Set-VDSecurityPolicy -AllowPromiscuous $false
To view NetFlow Collector IPs configured on distributed switches From the vSphere Web Client go to Networking >> Select a distributed switch >> Manage >> Settings >> NetFlow. View the NetFlow pane and verify any collector IP addresses are valid and in use for troubleshooting. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VDSwitch | select Name,@{N="NetFlowCollectorIPs";E={$_.ExtensionData.config.IpfixConfig.CollectorIpAddress}} To view if NetFlow is enabled on any distributed port groups From the vSphere Web Client go to Networking >> Select a distributed port group >> Manage >> Settings >> Policies. Go to Monitoring and view the NetFlow status. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VDPortgroup | Select Name,VirtualSwitch,@{N="NetFlowEnabled";E={$_.Extensiondata.Config.defaultPortConfig.ipfixEnabled.Value}} If NetFlow is configured and the collector IP is not known and is not enabled temporarily for troubleshooting purposes, this is a finding.
To remove collector IPs do the following: From the vSphere Web Client go to Networking >> Select a distributed switch >> Manage >> Settings >> NetFlow. View the NetFlow pane and click edit and remove any unknown collector IPs. or From a PowerCLI command prompt while connected to the vCenter server run the following commands: $dvs = Get-VDSwitch dvswitch | Get-View ForEach($vs in $dvs){ $spec = New-Object VMware.Vim.VMwareDVSConfigSpec $spec.configversion = $vs.Config.ConfigVersion $spec.IpfixConfig = New-Object VMware.Vim.VMwareIpfixConfig $spec.IpfixConfig.CollectorIpAddress = "" $spec.IpfixConfig.CollectorPort = "0" $spec.IpfixConfig.ActiveFlowTimeout = "60" $spec.IpfixConfig.IdleFlowTimeout = "15" $spec.IpfixConfig.SamplingRate = "0" $spec.IpfixConfig.InternalFlowsOnly = $False $vs.ReconfigureDvs_Task($spec) } Note: This will reset the NetFlow collector configuration back to the defaults. To disable NetFlow on a distributed port group do the following: From the vSphere Web Client go to Networking >> Select a distributed port group >> Manage >> Settings >> Policies. Go to Monitoring and change NetFlow to disabled. or From a PowerCLI command prompt while connected to the vCenter server run the following commands: $pgs = Get-VDPortgroup | Get-View ForEach($pg in $pgs){ $spec = New-Object VMware.Vim.DVPortgroupConfigSpec $spec.configversion = $pg.Config.ConfigVersion $spec.defaultPortConfig = New-Object VMware.Vim.VMwareDVSPortSetting $spec.defaultPortConfig.ipfixEnabled = New-Object VMware.Vim.BoolPolicy $spec.defaultPortConfig.ipfixEnabled.inherited = $false $spec.defaultPortConfig.ipfixEnabled.value = $false $pg.ReconfigureDVPortgroup_Task($spec) }
From the vSphere Web Client go to Networking >> Select a distributed port group >> Manage >> Settings >> Properties. View the Properties pane and verify all Override port policies are set to disabled. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VDPortgroup | Get-View | Select Name, @{N="VlanOverrideAllowed";E={$_.Config.Policy.VlanOverrideAllowed}}, @{N="UplinkTeamingOverrideAllowed";E={$_.Config.Policy.UplinkTeamingOverrideAllowed}}, @{N="SecurityPolicyOverrideAllowed";E={$_.Config.Policy.SecurityPolicyOverrideAllowed}}, @{N="IpfixOverrideAllowed";E={$_.Config.Policy.IpfixOverrideAllowed}}, @{N="BlockOverrideAllowed";E={$_.Config.Policy.BlockOverrideAllowed}}, @{N="ShapingOverrideAllowed";E={$_.Config.Policy.ShapingOverrideAllowed}}, @{N="VendorConfigOverrideAllowed";E={$_.Config.Policy.VendorConfigOverrideAllowed}}, @{N="TrafficFilterOverrideAllowed";E={$_.Config.Policy.TrafficFilterOverrideAllowed}}, @{N="PortConfigResetAtDisconnect";E={$_.Config.Policy.PortConfigResetAtDisconnect}} | Sort Name Note: This was broken up into multiple lines for readability. Either paste as is into a PowerShell script or combine into one line and run. This does not apply to the reset port configuration on disconnect policy. If any port level overrides are enabled and not documented, this is a finding.
From the vSphere Web Client go to Networking >> Select a distributed port group >> Manage >> Settings >> Properties. Click Edit and change all Override port policies to disabled. From a PowerCLI command prompt while connected to the vCenter server run the following commands: $pgs = Get-VDPortgroup | Get-View ForEach($pg in $pgs){ $spec = New-Object VMware.Vim.DVPortgroupConfigSpec $spec.configversion = $pg.Config.ConfigVersion $spec.Policy = New-Object VMware.Vim.VMwareDVSPortgroupPolicy $spec.Policy.VlanOverrideAllowed = $False $spec.Policy.UplinkTeamingOverrideAllowed = $False $spec.Policy.SecurityPolicyOverrideAllowed = $False $spec.Policy.IpfixOverrideAllowed = $False $spec.Policy.BlockOverrideAllowed = $False $spec.Policy.ShapingOverrideAllowed = $False $spec.Policy.VendorConfigOverrideAllowed = $False $spec.Policy.TrafficFilterOverrideAllowed = $False $spec.Policy.PortConfigResetAtDisconnect = $True $pg.ReconfigureDVPortgroup_Task($spec) }
From the vSphere Web Client go to Networking >> Select a distributed port group >> Manage >> Settings >> Policies. Review the port group VLAN tags and verify they are not set to the native VLAN ID of the attached physical switch. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VDPortgroup | select Name, VlanConfiguration If any port group is configured with the native VLAN of the ESXi hosts attached physical switch, this is a finding.
From the vSphere Web Client go to Networking >> Select a distributed port group >> Manage >> Settings >> Policies. Click Edit and under the VLAN section change the VLAN ID to a non-native VLAN and click OK. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VDPortgroup "portgroup name" | Set-VDVlanConfiguration -VlanId "New VLAN#"
From the vSphere Web Client go to Networking >> Select a distributed port group >> Manage >> Settings >> Policies. Review the port group VLAN tags and verify they are not set to 4095. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VDPortgroup | select Name, VlanConfiguration If any port group is configured with VLAN 4095 and is not documented as a needed exception, this is a finding.
To change the VLAN ID of distributed virtual port groups do the following: From the vSphere Web Client go to Networking >> Select a distributed port group >> Manage >> Settings >> Policies. Click Edit and under the VLAN section change the VLAN ID to not be 4095 and click OK. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VDPortgroup "portgroup name" | Set-VDVlanConfiguration -VlanId "New VLAN#"
From the vSphere Web Client go to Networking >> Select a distributed port group >> Manage >> Settings >> Policies. Review the port group VLAN tags and verify they are not set to a reserved VLAN ID. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VDPortgroup | select Name, VlanConfiguration If any port group is configured with a reserved VLAN ID, this is a finding.
From the vSphere Web Client go to Networking >> Select a distributed port group >> Manage >> Settings >> Policies. Click Edit and under the VLAN section change the VLAN ID to not be a reserved VLAN ID and click OK. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VDPortgroup "portgroup name" | Set-VDVlanConfiguration -VlanId "New VLAN#"
From the vSphere Web Client go to vCenter Inventory Lists >> vCenter Servers >> Select your vCenter Server >> Manage >> Settings >> Advanced Settings. Verify that config.nfc.useSSL is set to true. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.nfc.useSSL and verify it is set to true. If the config.nfc.useSSL is set to a value other than true or does not exist, this is a finding.
From the vSphere Web Client go to vCenter Inventory Lists >> vCenter Servers >> Select your vCenter Server >> Manage >> Settings >> Advanced Settings. Click Edit and edit the config.nfc.useSSL setting to true or if the value does not exist create it by entering the values in the Key and Value fields and clicking Add. or From a PowerCLI command prompt while connected to the vCenter server run the following command: If the setting already exists: Get-AdvancedSetting -Entity <vcenter server name> -Name config.nfc.useSSL | Set-AdvancedSetting -Value true If the setting does not exist: New-AdvancedSetting -Entity <vcenter server name> -Name config.nfc.useSSL -Value true
This control only applies to Windows based vCenter installations. The following services should be set to run as a service account: VMware Content Library Service VMware Inventory Service VMware Performance Charts VMware VirtualCenter Server vCenter should be installed using the service account as that will configure the services appropriately. If vCenter is not installed with a service account and the services identified in this control and not running as a service account, this is a finding.
For each of the following services open the services console on the vCenter server and right click and select properties on the service. Go to the Log On tab and configure the service to run as a service account and restart the service. VMware Content Library Service VMware Inventory Service VMware Performance Charts VMware VirtualCenter Server
From the vSphere Web Client go to vCenter Inventory Lists >> vCenter Servers >> Select your vCenter Server >> Manage >> Settings >> Advanced Settings. Verify that VirtualCenter.VimPasswordExpirationInDays is set to 30. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name VirtualCenter.VimPasswordExpirationInDays and verify it is set to 30. If the VirtualCenter.VimPasswordExpirationInDays is set to a value other than 30 or does not exist, this is a finding.
From the vSphere Web Client go to vCenter Inventory Lists >> vCenter Servers >> Select your vCenter Server >> Manage >> Settings >> Advanced Settings. Click Edit and edit the VirtualCenter.VimPasswordExpirationInDays setting to 30 or if the value does not exist create it by entering the values in the Key and Value fields and clicking Add. or From a PowerCLI command prompt while connected to the vCenter server run the following command: If the setting already exists: Get-AdvancedSetting -Entity <vcenter server name> -Name VirtualCenter.VimPasswordExpirationInDays | Set-AdvancedSetting -Value 30 If the setting does not exist: New-AdvancedSetting -Entity <vcenter server name> -Name VirtualCenter.VimPasswordExpirationInDays -Value 30
From the vSphere Web Client go to vCenter Inventory Lists >> vCenter Servers >> Select your vCenter Server >> Manage >> Settings >> Advanced Settings. Verify that config.vpxd.hostPasswordLength is set to 32. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.vpxd.hostPasswordLength and verify it is set to 32. If the config.vpxd.hostPasswordLength is set to a value other than 32 or does not exist, this is a finding.
From the vSphere Web Client go to vCenter Inventory Lists >> vCenter Servers >> Select your vCenter Server >> Manage >> Settings >> Advanced Settings. Click Edit and edit the config.vpxd.hostPasswordLength setting to 32 or if the value does not exist create it by entering the values in the Key and Value fields and clicking Add. or From a PowerCLI command prompt while connected to the vCenter server run the following command: If the setting already exists: Get-AdvancedSetting -Entity <vcenter server name> -Name config.vpxd.hostPasswordLength | Set-AdvancedSetting -Value 32 If the setting does not exist: New-AdvancedSetting -Entity <vcenter server name> -Name config.vpxd.hostPasswordLength -Value 32
The Managed Object Browser (MOB) was designed to be used by SDK developers to assist in the development, programming, and debugging of objects. It is an inventory object, full-access interface, allowing attackers to determine the inventory path of an infrastructure's managed entities. Check the operational status of the MOB: Determine the location of the vpxd.cfg file on the vCenter Server's Windows OS host. Edit the file and locate the <vpxd> ... </vpxd> element. Ensure the following element is set. <enableDebugBrowse>false</enableDebugBrowse> If the MOB is currently enabled, ask the SA if it is being used for object maintenance. If the enableDebugBrowse element is enabled (set to true), and object maintenance is not being performed, this is a finding. If the enableDebugBrowse element is enabled (set to true), and object maintenance is being performed, this is not a finding.
If the datastore browser is enabled and required for object maintenance, no fix is immediately required. Disable the managed object browser: Determine the location of the vpxd.cfg file on the Windows host. Edit the file and locate the <vpxd> ... </vpxd> element. Ensure the following element is set. <enableDebugBrowse>false</enableDebugBrowse> Restart the vCenter Service to ensure the configuration file change(s) are in effect.
After the Windows server hosting the vCenter Server has been rebooted, a vCenter Server user or member of the user group granted the administrator role must log in and verify the role permissions remain intact. If the user and/or user group granted vCenter administrator role permissions cannot be verified intact, this is a finding.
As the SSO Administrator, log in to the vCenter Server and restore a legitimate administrator account per site-specific user/group/role requirements.
Login to the vCenter server and verify the local administrators group only contains users and/or groups that contain vCenter Administrators. If the local administrators group contains users and/or groups that are not vCenter Administrators such as "Domain Admins", this is a finding.
Remove all unnecessary users and/or groups from the local administrators group of the vCenter server.
If at any time a vCenter Server installation fails, only the log files of format "hs_err_pid...." should be identified on the Windows host and deleted securely before putting the host into production. Determine if a site policy exists for handling failed installation cleanup of the Windows host prior to deployment. Using the Windows host search function, determine the existence of any log files of format "hs_err_pid". If a file name of the format "hs_err_pid" is found, this is a finding. If a site policy does not exist and/or is not followed, this is a finding.
Develop a site policy for handling failed installation cleanup of the Windows host prior to deployment. Using the Windows host search function, determine the existence of any log files of format "hs_err_pid" and remove them.
Verify the webclient.properties file contains the line "show.allusers.tasks = true". The default locations for the webclient.properties file are: Windows - C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client\ Appliance - /etc/vmware/vsphere-client/ If show.allusers.tasks is not set to true, this is a finding.
Edit the webclient.properties file to set the show.allusers.tasks setting to true. The default locations for the webclient.properties file are: Windows - C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client\ Appliance - /etc/vmware/vsphere-client/ After editing the file the vSphere Web Client service will need to be restarted.
If enhanced linked mode is used then local windows authentication is not available to vCenter, this is not applicable. Under the computer management console for windows view the local administrators group and verify only vCenter administrators have access to the vCenter server. Other groups and users that are not vCenter administrators should be removed from the local administrators group such as Domain Admins. If there are any groups or users present in the local administrators group of the vCenter server, this is a finding.
Under the computer management console for windows view the local administrators group and remove any users or groups that are not vCenter administrators.
Check the following conditions: The Update Manager must be configured to use the Update Manager Download Server. The use of physical media to transfer update files to the Update Manager server (air-gap model example: separate Update Manager Download Server which may source vendor patches externally via the Internet versus an internal source) must be enforced with site policies. Verify the Update Manager download source is not the Internet. To verify download settings, from the vSphere Client/vCenter Server system, click Update Manager under Solutions and Applications. On the Configuration tab, under Settings, click Download Settings. In the Download Sources pane, verify "Direct connection to Internet" is not selected. If "Direct connection to Internet" is configured, this is a finding. If all of the above conditions are not met, this is a finding.
Configure the Update Manager Server to use a separate Update Manager Download Server; the use of physical media to transfer updated files to the Update Manager server (air-gap model) must be enforced and documented with organization policies. Configure the Update Manager Download Server and enable the Download Service. Patches must not be directly accessible to the Update Manager Server application from the Internet. To configure a Web server or local disk repository as a download source (i.e., "Direct connection to Internet" must not be selected as the source), from the vSphere Client/vCenter Server system, click Update Manager under Solutions and Applications. On the Configuration tab, under Settings, click Download Settings. In the Download Sources pane, select Use a shared repository. Enter the <site-specific> path or the URL to the shared repository. Click Validate URL to validate the path. Click Apply.
Verify only the following permissions are allowed to the VUM database user. For Oracle DB normal operation, only the following permissions are required. grant connect to vumAdmin grant resource to vumAdmin grant create any job to vumAdmin grant create view to vumAdmin grant create any sequence to vumAdmin grant create any table to vumAdmin grant lock any table to vumAdmin grant create procedure to vumAdmin grant create type to vumAdmin grant execute on dbms_lock to vumAdmin grant unlimited tablespace to vumAdmin # To ensure space limitation is not an issue For SQL DB normal operation, make sure that the database user has either a sysadmin server role or the db_owner fixed database role on the Update Manager database and the MSDB database. The db_owner role on the MSDB database is required for installation and upgrade only. If the above vendor database-dependent permissions are not strictly adhered to, this is a finding.
For Oracle DB normal runtime operation, set the following permissions. grant connect to vumAdmin grant resource to vumAdmin grant create any job to vumAdmin grant create view to vumAdmin grant create any sequence to vumAdmin grant create any table to vumAdmin grant lock any table to vumAdmin grant create procedure to vumAdmin grant create type to vumAdmin grant execute on dbms_lock to vumAdmin grant unlimited tablespace to vumAdmin # To ensure space limitation is not an issue For SQL DB normal operation, make sure that the database user has either a sysadmin server role or the db_owner fixed database role on the Update Manager database and the MSDB database. The db_owner role on the MSDB database is required for installation and upgrade only. Note: While current, it is always best to check both the latest VMware Update Manager Administration Guide and the vendor database documentation for any updates to these configurations.
Verify only the following permissions are allowed on the vCenter database for the following roles and users. vCenter database administrator role used only for initial setup and periodic maintenance of the database: Schema permissions ALTER, REFERENCES, and INSERT. Permissions CREATE TABLE, VIEW, and CREATE PROCEDURES. vCenter database administrator role: SELECT, INSERT, DELETE, UPDATE, and EXECUTE. EXECUTE permissions on sp_add_job, sp_delete_job, sp_add_jobstep, sp_update_job, sp_add_jobserver, sp_add_jobschedule, and sp_add_category stored procedures. SELECT permission on syscategories, sysjobsteps, sysjobs_view, and sysjobs tables. vCenter database user: VIEW SERVER STATE and VIEW ANY DEFINITIONS. Equivalent permissions must be set for Non-MS databases. If the above database permissions are not set correctly, this is a finding. For more information, refer to the following website: http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.install.doc/GUID-36B92A8C-074A-4657-9938-62AB97225B91.html
Configure correct permissions and roles for SQL: Grant these privileges to a vCenter database administrator role used only for initial setup and periodic maintenance of the database: Schema permissions ALTER, REFERENCES, and INSERT. Permissions CREATE TABLE, VIEW, and CREATE PROCEDURES. Grant these privileges to a vCenter database user role: SELECT, INSERT, DELETE, UPDATE, and EXECUTE. EXECUTE permissions on sp_add_job, sp_delete_job, sp_add_jobstep, sp_update_job, sp_add_jobserver, sp_add_jobschedule, and sp_add_category stored procedures. SELECT permission on syscategories, sysjobsteps, sysjobs_view, and sysjobs tables. Grant the permissions VIEW SERVER STATE and VIEW ANY DEFINITIONS to the vCenter database user. For more information, refer to the following website: http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.install.doc/GUID-36B92A8C-074A-4657-9938-62AB97225B91.html
Verify that each external application that connects to vCenter has a unique service account dedicated to that application. For example there should be separate accounts for Log Insight, Operations Manager, or anything else that requires an account to access vCenter. If any application shares a service account that is used to connect to vCenter, this is a finding.
For applications sharing service accounts create a new service account to assign to the application so that no application shares a service account with another. When standing up a new application that requires access to vCenter always create a new service account prior to installation and grant only the permissions needed for that application.
Verify the vSphere Client used by administrators includes only authorized extensions from trusted sources. From the vSphere Web Client go to Administration >> Client Plug-Ins. View the Installed/Available Plug-ins list and verify they are all identified as authorized VMware, 3rd party (Partner) and/or site-specific (locally developed and site) approved plug-ins. If any Installed/Available plug-ins in the viewable list cannot be verified as vSphere Client plug-ins and/or authorized extensions from trusted sources, this is a finding.
From the vSphere Web Client go to Administration >> Client Plug-Ins and right click the unknown plug-in and click disable then proceed to remove the plug-in. To remove plug-ins do the following: If you have vCenter Server in linked mode, perform this procedure on the vCenter Server that is used to install the plug-in initially, then restart the vCenter Server services on the linked vCenter Server. In a web browser, navigate to http://vCenter_Server_name_or_IP/mob. Where vCenter_Server_name_or_IP/mob is the name of your vCenter Server or its IP address. Click Content. Click ExtensionManager. Select and copy the name of the plug-in you want to remove from the list of values under Properties. For a list of default plug-ins, see the Additional Information section of this article. Click UnregisterExtension. A new window appears. Paste the name of the plug-in and click Invoke Method. This removes the plug-in. Close the window. Refresh the Managed Object Type:ManagedObjectReference:ExtensionManager window to verify that the plug-in is removed successfully. Note: If the plug-in still appears, you may have to restart the vSphere Client. Note: You may have to enable the Managed Object Browser(mob) temporarily if previously disabled.
From the vSphere Web Client go to vCenter Inventory Lists >> vCenter Servers >> Select your vCenter Server >> Manage >> Settings >> Advanced Settings. Verify that config.log.level is set to "info". or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-AdvancedSetting -Entity <vcenter server name> -Name config.log.level and verify it is set to "info". If the config.log.level is set to a value other than info or does not exist, this is a finding.
From the vSphere Web Client go to vCenter Inventory Lists >> vCenter Servers >> Select your vCenter Server >> Manage >> Settings >> Advanced Settings. Click Edit and edit the config.log.level setting to info or if the value does not exist create it by entering the values in the Key and Value fields and clicking Add. or From a PowerCLI command prompt while connected to the vCenter server run the following command: If the setting already exists: Get-AdvancedSetting -Entity <vcenter server name> -Name config.log.level | Set-AdvancedSetting -Value info If the setting does not exist: New-AdvancedSetting -Entity <vcenter server name> -Name config.log.level -Value info
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Minimum Length: 15 If this password policy is not configured as stated, this is a finding.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click Edit. Set the Minimum Length to 15 and click OK.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Upper-case Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click Edit. Set Upper-case Characters to at least 1 and click OK.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Lower-case Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click Edit. Set Lower-case Characters to at least 1 and click OK.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirement should be set at a minimum: Numeric Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click Edit. Set Numeric Characters to at least 1 and click OK.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. View the values of the password format requirements. The following password requirements should be set at a minimum: Special Characters: At least 1 If this password complexity policy is not configured as stated, this is a finding.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Password Policy. Click Edit. Set Special Characters to at least 1 and click OK.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. View the values for the lockout policies. The following lockout policy should be set at follows: Maximum number of failed login attempts: 3 If this account lockout policy is not configured as stated, this is a finding.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. Click Edit. Set the Maximum number of failed login attempts to 3 and click OK.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. View the values for the lockout policies. The following lockout policy should be set at follows: Time interval between failures: 900 seconds If this lockout policy is not configured as stated, this is a finding.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. Click Edit. Set the Time interval between failures to 900 and click OK.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. View the values for the lockout policies. The following lockout policy should be set at follows: Unlock time: 0 If this account lockout policy is not configured as stated, this is a finding.
From the vSphere Web Client go to Administration >> Single Sign-On >> Configuration >> Policies >> Lockout Policy. Click Edit. Set the Unlock time to 0 and click OK.
From the vSphere Client select the vCenter server at the top of the hierarchy and go to >> Alarms >> Definitions. Verify there is an alarm created to alert on permission additions. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-AlarmDefinition | Where {$_.ExtensionData.Info.Expression.Expression.EventTypeId -eq "vim.event.PermissionAddedEvent"} | Select Name,Enabled,@{N="EventTypeId";E={$_.ExtensionData.Info.Expression.Expression.EventTypeId}} If an alarm is not created to alert on permission addition events, this is a finding.
From the vSphere Client select the vCenter server at the top of the hierarchy and go to >> Alarms >> Definitions >> Right click in the empty space and select New Alarm. On the General tab provide an alarm name and description, Select vCenter for alarm type and "Monitor for specific events occurring on this object", check "Enable this alarm". On the Triggers tab click Add three triggers and in the event column enter "vim.event.PermissionAddedEvent", "vim.event.PermissionRemovedEvent", and "vim.event.PermissionUpdatedEvent" for the three triggers and click OK.
From the vSphere Client select the vCenter server at the top of the hierarchy and go to >> Alarms >> Definitions. Verify there is an alarm created to alert on permission deletions. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-AlarmDefinition | Where {$_.ExtensionData.Info.Expression.Expression.EventTypeId -eq "vim.event.PermissionRemovedEvent"} | Select Name,Enabled,@{N="EventTypeId";E={$_.ExtensionData.Info.Expression.Expression.EventTypeId}} If an alarm is not created to alert on permission deletion events, this is a finding.
From the vSphere Client select the vCenter server at the top of the hierarchy and go to >> Alarms >> Definitions >> Right click in the empty space and select New Alarm. On the General tab provide an alarm name and description, Select vCenter for alarm type and "Monitor for specific events occurring on this object", check "Enable this alarm". On the Triggers tab click Add three triggers and in the event column enter "vim.event.PermissionAddedEvent", "vim.event.PermissionRemovedEvent", and "vim.event.PermissionUpdatedEvent" for the three triggers and click OK.
From the vSphere Client select the vCenter server at the top of the hierarchy and go to >> Alarms >> Definitions. Verify there is an alarm created to alert on permission changes. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-AlarmDefinition | Where {$_.ExtensionData.Info.Expression.Expression.EventTypeId -eq "vim.event.PermissionUpdatedEvent"} | Select Name,Enabled,@{N="EventTypeId";E={$_.ExtensionData.Info.Expression.Expression.EventTypeId}} If an alarm is not created to alert on permission update events, this is a finding.
From the vSphere Client select the vCenter server at the top of the hierarchy and go to >> Alarms >> Definitions >> Right click in the empty space and select New Alarm. On the General tab provide an alarm name and description, Select vCenter for alarm type and "Monitor for specific events occurring on this object", check "Enable this alarm". On the Triggers tab click Add three triggers and in the event column enter "vim.event.PermissionAddedEvent", "vim.event.PermissionRemovedEvent", and "vim.event.PermissionUpdatedEvent" for the three triggers and click OK.
From the vSphere Web Client go to Administration >> Access Control >> Roles. View each role and verify the users and/or groups assigned to it. or From a PowerCLI command prompt while connected to the vCenter server run the following command: Get-VIPermission | Sort Role | Select Role,Principal,Entity,Propagate,IsGroup | FT -Auto Application service account and user required privileges should be documented. If any user or service account has more privileges than required, this is a finding.
To create a new role with specific permissions do the following: From the vSphere Web Client go to Administration >> Access Control >> Roles. Click the green plus sign and enter a name for the role and select only the specific permissions required. Users can then be assigned to the newly created role.
If IP-based storage is not used, this is not applicable. IP-Based storage (iSCSI, NFS, VSAN) VMkernel port groups must be in a dedicated VLAN that can be on a common standard or distributed virtual switch that is logically separated from other traffic types. The check for this will be unique per environment. From the vSphere Client select the ESXi host and go to Configuration >> Networking and review the VLANs associated with any IP-Based storage VMkernels and verify they are dedicated for that purpose and are logically separated from other functions. If any IP-Based storage networks are not isolated from other traffic types, this is a finding.
Configuration of an IP-Based VMkernel will be unique to each environment but for example to modify the IP address and VLAN information to the correct network on a standard switch for an iSCSI VMkernel do the following: From the vSphere Client select the ESXi host and go to Configuration > Networking > On the vSwitch that contains the iSCSI VMkernel select Properties. Select the iSCSI VMkernel and click Edit > On the General tab uncheck everything and set the appropriate VLAN ID > Go to the IP Settings tab > Enter the appropriate IP address and subnet information and click OK.
If no clusters are enabled for VSAN, this is not applicable. From the vSphere Web Client go to Host and Clusters >> Select a Cluster >> Manage >> Settings >> Virtual SAN >> Health. Review the "Health Service Status" and verify that it is set to "Enabled". If VSAN is enabled and there is no VSAN health check installed or the VSAN Health Check is disabled, this is a finding.
If VSAN Health Check is not installed (6.0 GA only): Download the VSAN Health Check Plugin and install to the vCenter Server. Then restart the vCenter Server services. DRS must be configured for fully automated on the cluster. Then each ESXi host must have the VSAN Health Check VIB installed on the ESXi hosts. If VSAN Health Check is installed: From the vSphere Web Client go to Host and Clusters > Select a VSAN enabled "Cluster" > Manage > Settings > Virtual SAN > Health > "Health Service Status" and click "Edit Settings". Select the check box for "Turn On Periodical Health Check" and configure the time interval as necessary.
If no clusters are enabled for VSAN, this is not applicable. From the vSphere Web Client go to Host and Clusters >> Select a VSAN Enabled Cluster >> Manage >> Settings >> General >> Internet Connectivity >> Edit If the HCL internet download is not required then ensure that "Enable Internet access for this cluster" is disabled. If this "Enable Internet access for this cluster" is enabled this is a finding. If the HCL internet download is required then ensure that "Enable Internet access for this cluster" is enabled and that a proxy host is configured. If "Enable Internet access for this cluster" is disabled or a proxy is not configured this is a finding.
If no clusters are enabled for VSAN, this is not applicable. If VSAN Health Check is not installed (6.0 GA only): Download the VSAN Health Check Plugin and install to the vCenter Server. Then restart the vCenter Server services. DRS must be configured for fully automated on the cluster. Then each ESXi host must have the VSAN Health Check VIB installed on the ESXi hosts. If VSAN Health Check is installed: From the vSphere Web Client go to Host and Clusters > Select a VSAN Enabled Cluster > Manage > Settings > General > Internet Connectivity > Edit If the HCL internet download is not required then ensure that "Enable Internet access for this cluster" is disabled. If the HCL internet download is required then ensure that "Enable Internet access for this cluster" is enabled and that a proxy host is appropriately configured.
If no clusters are enabled for VSAN, this is not applicable. From the vSphere Web Client go to Host and Clusters >> Select a Cluster >> Related Objects >> Datastores. Review the datastores. Identify any datastores with "vsan" as the datastore type. or From a PowerCLI command prompt while connected to the vCenter server run the following command: If($(Get-Cluster | where {$_.VsanEnabled} | Measure).Count -gt 0){ Write-Host "VSAN Enabled Cluster found" Get-Cluster | where {$_.VsanEnabled} | Get-Datastore | where {$_.type -match "vsan"} } else{ Write-Host "VSAN is not enabled, this finding is not applicable" } If VSAN is Enabled and the datastore is named "vsanDatastore" this is a finding.
From the vSphere Web Client go to Host and Clusters > Select a Cluster > Related Objects > Datastores. Right click on the datastore named "vsanDatastore" and select "Rename". Rename the datastore based on operational naming standards. or From a PowerCLI command prompt while connected to the vCenter server run the following command: If($(Get-Cluster | where {$_.VsanEnabled} | Measure).Count -gt 0){ Write-Host "VSAN Enabled Cluster found" $Clusters = Get-Cluster | where {$_.VsanEnabled} Foreach ($clus in $clusters){ $clus | Get-Datastore | where {$_.type -match "vsan"} | Set-Datastore -Name $(($clus.name) + "_VSAN_Datastore") } } else{ Write-Host "VSAN is not enabled, this finding is not applicable" }