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 an NSX Manager shell, run the following commands: > get service async_replicator | find Logging > get service auth | find Logging > get service http | find Logging > get service manager | find Logging > get service telemetry | find Logging Expected result: Logging level: info If any service listed does not have logging level configured to "info", this is a finding.
From an NSX Manager shell, run the following commands: > set service async_replicator logging-level info > set service auth logging-level info > set service http logging-level info > set service manager logging-level info > set service telemetry logging-level info
From the NSX Manager web interface, go to System >> Settings >> User Management >> User Role Assignment. View each user and group and verify the role assigned has authorization limits as appropriate to the role and in accordance with the site's documentation. If any user/group or service account are assigned to roles with privileges that are beyond those required and authorized by the organization, this is a finding.
To create a new role with reduced permissions, do the following: From the NSX Manager web interface, go to System >> Settings >> User Management >> Roles. Click "Add Role", provide a name and the required permissions, and then click "Save". To update user or group permissions to an existing role with reduced permissions, do the following: From the NSX Manager web interface, go to System >> User Management >> User Role Assignment. Click the menu dropdown next to the target user or group and select "Edit". Remove the existing role, select the new one, and then click "Save".
From an NSX Manager shell, run the following commands: > get auth-policy api lockout-reset-period Expected result: 900 seconds If the output does not match the expected result, this is a finding. > get auth-policy api lockout-period Expected result: 900 seconds If the output does not match the expected result, this is a finding. > get auth-policy api max-auth-failures Expected result: 3 If the output does not match the expected result, this is a finding. > get auth-policy cli lockout-period Expected result: 900 seconds If the output does not match the expected result, this is a finding. > get auth-policy cli max-auth-failures Expected result: 3 If the output does not match the expected result, this is a finding.
From an NSX Manager shell, run the following commands: > set auth-policy api lockout-reset-period 900 > set auth-policy api lockout-period 900 > set auth-policy api max-auth-failures 3 > set auth-policy cli lockout-period 900 > set auth-policy cli max-auth-failures 3
Determine if the network device is configured to present a DOD-approved banner that is formatted in accordance with DTM-08-060. From the NSX Manager web interface, go to System >> Settings >> General Settings >> User Interface. Review the Login Consent Settings. If the "Consent Message Description" does not contain the Standard Mandatory DOD Notice and Consent Banner verbiage, this is a finding. The Standard Mandatory DOD Notice and Consent Banner verbiage is as follows: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."
From the NSX Manager web interface, go to System >> Settings >> General Settings >> User Interface. Under Login Consent Settings click "Edit". Enter the banner language in the "Consent Message Description" text box, formatted in accordance with DTM-08-060, and click "Save". "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."
From the NSX Manager web interface, go to System >> Settings >> General Settings >> User Interface. Review the Login Consent Settings. Verify "Login Consent" is not On. Verify "Require Explicit User Consent" is set to Yes. If the Standard Mandatory DOD Notice and Consent Banner is not retained on the screen until the administrator acknowledges the usage conditions and takes explicit actions to log on for further access, this is a finding.
From the NSX Manager web interface, go to System >> Settings >> General Settings >> User Interface. Under Login Consent Settings, click "Edit". Toggle "Login Consent" to On. Toggle "Require Explicit User Consent" to Yes. Note: The banner text is also entered; however, that is covered by NMGR-4X-000013.
From the NSX Manager web interface, go to System >> Settings >> Users Management >> Authentication Providers. Verify that the "VMware Identity Manager" and "OpenID Connect" tabs are configured. If NSX is not configured to integrate with an identity provider that supports MFA, this is a finding.
To configure NSX to integrate with VMware Identity Manager or Workspace ONE Access, as the authentication source, do the following: From the NSX Manager web interface, go to System >> Users and Roles >> VMware Identity Manager and click "Edit". If using an external load balancer for the NSX Management cluster, enable "External Load Balancer Integration". If using a cluster VIP, leave this disabled. Click the toggle button to enable "VMware Identity Manager Integration". Enter the VMware Identity Manager or Workspace ONE Access appliance name, OAuth Client ID, OAuth Client Secret, and certificate thumbprint as provided by the administrators. Enter the NSX Appliance FQDN. For a cluster, enter the load balancer FQDN or cluster VIP FQDN. Click "Save", import users and groups, and then assign them roles. (The users are not actually local and remain in the authentication/AAA server.) Note: As of NSX 4.1 and vCenter 8.0 Update 2, NSX Manager administrator access can also be configured by connecting VMware NSX to the Workspace ONE Access Broker in VMware vCenter for federated identity. Refer to the NSX product documentation to configure this access option. Ensure the identity provider administrators have configured the provider to support multi-factor authentication.
From the NSX Manager web interface, go to the System >> Settings >> User Management >> Local Users and view the status column. If any local account other than the account of last resort are active, this is a finding.
From the NSX Manager web interface, go to the System >> Settings >> User Management >> Local Users. Select the menu drop down next to any local user on the list except for the "admin" account. Click modify and click "Deactivate User".
Viewing TLS protocol enablement must be done via the API. Execute the following API call using curl or another REST API client: GET https://<nsx-mgr>/api/v1/cluster/api-service Example result: "protocol_versions": [ { "name": "TLSv1.1", "enabled": false }, { "name": "TLSv1.2", "enabled": true }, { "name": "TLSv1.3", "enabled": true } ] If TLS 1.1 is enabled, this is a finding.
Capture the output from the check GET command and update the TLS 1.1 protocol to false. Run the following API call using curl or another REST API client: PUT https://<nsx-mgr>/api/v1/cluster/api-service Example request body: { "session_timeout": 1800, "connection_timeout": 30, "protocol_versions": [ { "name": "TLSv1.1", "enabled": false }, { "name": "TLSv1.2", "enabled": true }, { "name": "TLSv1.3", "enabled": true } ], "cipher_suites": [ { "name": "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA", "enabled": true }, { "name": "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256", "enabled": true }, { "name": "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "enabled": true }, { "name": "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA", "enabled": true }, { "name": "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384", "enabled": true }, { "name": "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", "enabled": true }, { "name": "TLS_RSA_WITH_AES_128_CBC_SHA", "enabled": true }, { "name": "TLS_RSA_WITH_AES_128_CBC_SHA256", "enabled": true }, { "name": "TLS_RSA_WITH_AES_128_GCM_SHA256", "enabled": true }, { "name": "TLS_RSA_WITH_AES_256_CBC_SHA", "enabled": true }, { "name": "TLS_RSA_WITH_AES_256_CBC_SHA256", "enabled": true }, { "name": "TLS_RSA_WITH_AES_256_GCM_SHA384", "enabled": true }, { "name": "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384", "enabled": true }, { "name": "TLS_AES_128_GCM_SHA256", "enabled": true }, { "name": "TLS_AES_256_GCM_SHA384", "enabled": true }, { "name": "TLS_CHACHA20_POLY1305_SHA256", "enabled": true } ], "redirect_host": "", "client_api_rate_limit": 100, "global_api_concurrency_limit": 199, "client_api_concurrency_limit": 40, "basic_authentication_enabled": true, "cookie_based_authentication_enabled": true, "resource_type": "ApiServiceConfig", "id": "reverse_proxy_config", "display_name": "reverse_proxy_config", "_create_time": 1703175890703, "_create_user": "system", "_last_modified_time": 1703175890703, "_last_modified_user": "system", "_system_owned": false, "_protection": "NOT_PROTECTED", "_revision": 0 } Note: Changes are applied to all nodes in the cluster. The API service on each node will restart after it is updated using this API. There may be a delay of up to a minute or so between the time this API call completes and when the new configuration goes into effect.
From an NSX Manager shell, run the following command: > get password-complexity If the minimum password length is not 15 or greater, this is a finding.
From an NSX Manager shell, run the following command: > set password-complexity minimum-password-length 15
From an NSX Manager shell, run the following command: > get password-complexity If the minimum uppercase characters is not 1 or more, this is a finding. Note: If a maximum number of uppercase characters has been configured a minimum will not be shown.
From an NSX Manager shell, run the following command: > set password-complexity upper-chars -1 Note: Negative numbers indicate a minimum number of characters.
From an NSX Manager shell, run the following command: > get password-complexity If the minimum lowercase characters is not 1 or more, this is a finding. Note: If a maximum number of lowercase characters has been configured, a minimum will not be shown.
From an NSX Manager shell, run the following command: > set password-complexity lower-chars -1 Note: Negative numbers indicate a minimum number of characters.
From an NSX Manager shell, run the following command: > get password-complexity If the minimum numeric characters is not 1 or more, this is a finding. Note: If a maximum number of numeric characters has been configured, a minimum will not be shown.
From an NSX Manager shell, run the following command: > set password-complexity digits -1 Note: Negative numbers indicate a minimum number of characters.
From an NSX Manager shell, run the following command: > get password-complexity If the minimum special characters is not 1 or more, this is a finding. Note: If a maximum number of special characters has been configured, a minimum will not be shown.
From an NSX Manager shell, run the following command: > set password-complexity special-chars -1 Note: Negative numbers indicate a minimum number of characters.
From an NSX Manager shell, run the following command: > get password-complexity If the number of consecutive characters allowed for reuse is not eight or more, this is a finding. Note: If this has not previously been configured it will not be shown in the output.
From an NSX Manager shell, run the following command: > set password-complexity max-repeats 8
From an NSX Manager shell, run the following command: > get service http | find Session Expected result: Session timeout: 300 If the session timeout is not configured to 300 or less, this is a finding. From an NSX Manager shell, run the following command: > get cli-timeout Expected result: 300 seconds If the CLI timeout is not configured to 300 or less, this is a finding.
From an NSX Manager shell, run the following commands: > set service http session-timeout 300 > set cli-timeout 300
From the NSX Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles. Click "All NSX Nodes" and verify the NTP servers listed. or From an NSX Manager shell, run the following command: > get ntp-server If the output does not contain at least two authoritative time sources, this is a finding. If the output contains unknown or nonauthoritative time sources, this is a finding.
To configure a profile to apply NTP servers to all NSX Manager nodes, do the following: From the NSX Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles. Click "All NSX Nodes" and then click "Edit". Under NTP servers, remove any unknown or nonauthoritative NTP servers, enter at least two authoritative servers, and then click "Save". or From an NSX Manager shell, run the following commands: > del ntp-server <server-ip or server-name> > set ntp-server <server-ip or server-name>
From the NSX Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles. Note: This check must be run from each NSX Manager as they are configured individually if done from the command line. Click "All NSX Nodes" and verify the time zone. or From an NSX Manager shell, run the following command: > get clock If system clock is not configured with the UTC time zone, this is a finding.
To configure a profile to apply a time zone to all NSX Manager nodes, do the following: From the NSX Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles. Click "All NSX Nodes", and then click "Edit". In the time zone drop-down list, select "UTC", and then click "Save". or From an NSX Manager shell, run the following command: > set timezone UTC Note: This fix must be run from each NSX Manager as they are configured individually if done from the command line.
From an NSX Manager shell, run the following command: > get service http | find limit Expected result: Client API concurrency limit: 40 connections Global API concurrency limit: 199 connections If the NSX does not limit the number of concurrent sessions to an organization-defined number, this is a finding.
From an NSX Manager shell, run the following commands: > set service http client-api-concurrency-limit 40 > set service http global-api-concurrency-limit 199 Note: The limit numbers in this example, while not mandatory, are the vendor recommend options. Setting the limits to lower numbers in a large environment that is very busy may cause operational issues. Setting the limits higher may cause resource contention so should be tested and monitored.
From the NSX Manager web interface, go to System >> Fabric >> Profiles >> Node Profiles. Click "All NSX Nodes" and verify the Syslog servers listed. or From an NSX Manager shell, run the following command: > get logging-servers Note: This command must be run from each NSX Manager as they are configured individually. If no logging severs are configured or unauthorized logging servers are configured, this is a finding. If the log level is not set to INFO, this is a finding.
To configure a profile to apply syslog servers to all NSX Manager nodes, do the following: From the NSX Manager web interface, go to System >> Fabric >> Profiles >> Node Profiles. Click "All NSX Nodes" and then under "Syslog Servers" click "Add". Enter the syslog server details and choose "Information" for the log level and click "Add". or (Optional) From an NSX Manager shell, run the following command to clear any existing incorrect logging-servers: > clear logging-servers From an NSX Manager shell, run the following command to configure a udp/tcp syslog server: > set logging-server <server-ip or server-name> proto <tcp or udp> level info From an NSX Manager shell, run the following command to configure a TLS syslog server: > set logging-server <server-ip or server-name> proto tls level info serverca ca.pem clientca ca.pem certificate cert.pem key key.pem From an NSX Manager shell, run the following command to configure an LI-TLS syslog server: > set logging-server <server-ip or server-name> proto li-tls level info serverca root-ca.crt Note: If using the protocols TLS or LI-TLS to configure a secure connection to a log server, the server and client certificates must be stored in /image/vmware/nsx/file-store on each NSX-T Manager appliance.
From the NSX Manager web interface, go to System >> Settings >> General Settings >> Customer Program >> Customer Experience Improvement Program. If Joined is set to "Yes", this is a finding.
From the NSX Manager web interface, go to System >> Settings >> General Settings >> Customer Program >> Customer Experience Improvement Program, and then click "Edit". Uncheck "Join the VMware Customer Experience Improvement Program" and click "Save".
From the NSX Manager web interface, go to System >> Lifecycle Management >> Backup and Restore to view the backup configuration. If backup is not configured and scheduled on a recurring frequency, this is a finding.
To configure a backup destination, do the following: From the NSX Manager web interface, go to System >> Lifecycle Management >> Backup and Restore, and then click "Edit" next to SFTP Server. Enter the target SFTP server, Directory Path, Username, Password, SSH Fingerprint, and Passphrase, and then click "Save". To configure a backup schedule, do the following: From the NSX Manager web interface, go to System >> Lifecycle Management >> Backup and Restore, and then click "Edit" next to Schedule. Click the "Recurring Backup" toggle and configure an interval between backups. Enable "Detect NSX configuration change" to trigger backups on detection of configuration changes and specify an interval for detecting changes. Click "Save".
NSX Manager uses a certificate for each manager and one for the cluster VIP. In some cases these are the same, but each node and cluster VIP certificate must be checked individually. Browse to the NSX Manager web interface for each node and cluster VIP and view the certificate and its issuer of the website. or From an NSX Manager shell, run the following commands: > get certificate api > get certificate cluster Save the output to a .cer file to examine. If the certificate the NSX Manager web interface or cluster is using is not issued by an approved certificate authority and is not currently valid, this is a finding.
Obtain a certificate or certificates signed by an approved certification authority. This can be done individually by generating CSRs through the NSX Manager web interface >> System >> Settings >> Certificates >> CSRs >> Generate CSR or outside of NSX if a common manager and cluster certificate is desired. Import the certificate(s) into NSX by doing the following: From the NSX Manager web interface, go to System >> Settings >> Certificates >> Certificates >> Import >> Import Certificate. Provide a name for the certificate and paste the certificates contents and key. Uncheck "Service Certificate" and click "Import". After import, note the ID of the certificate(s). Using curl or another REST API client, perform the following API calls and replace the certificate IDs noted in the previous steps. To replace a managers certificate: POST https://<nsx-mgr>/api/v1/node/services/http?action=apply_certificate&certificate_id=e61c7537-3090-4149-b2b6-19915c20504f To replace the cluster certificate: POST https://<nsx-mgr>/api/v1/cluster/api-certificate?action=set_cluster_certificate&certificate_id=d60c6a07-6e59-4873-8edb-339bf75711ac Note: If an NSX Intelligence appliance is deployed with the NSX Manager cluster, update the NSX Manager node IP, certificate, and thumbprint information that is on the NSX Intelligence appliance. Refer to the VMware Knowledge Base article https://kb.vmware.com/s/article/78505 for more information.
From the NSX Manager web interface, go to the System >> Lifecycle Management >> Upgrade. If the NSX Manager current version is not the latest approved for use in DOD and supported by the vendor, this is a finding.
To upgrade NSX, reference the upgrade guide in the documentation for the relevant version being upgraded. Refer to the NSX documentation and release notes for information on the latest releases. https://docs.vmware.com/en/VMware-NSX/index.html If NSX is part of a VMware Cloud Foundation deployment, refer to that documentation for latest supported versions and upgrade guidance.
From an NSX Manager shell, run the following command: > get service ssh Expected results: Service name: ssh Service state: stopped Start on boot: False If the SSH server is not stopped or starts on boot, this is a finding.
From an NSX Manager shell, run the following command(s): > stop service ssh > clear service ssh start-on-boot
From the NSX Manager web interface, go to the System >> Configuration >> Fabric >> Profiles >> Node Profiles. Click "All NSX Nodes" and view the SNMP Polling and Traps configuration. If SNMP v2c Polling or Traps are configured, this is a finding.
From the NSX Manager web interface, go to the System >> Configuration >> Fabric >> Profiles >> Node Profiles. Click on "All NSX Nodes" and delete and v2c Polling or Trap configurations.
From the NSX Manager web interface, go to the Home >> Monitoring Dashboards >> Compliance Report. Review the compliance report for code 72024 with description load balancer FIPS global setting disabled. Note: This may also be checked via the API call GET https://<nsx-mgr>/policy/api/v1/infra/global-config If the global FIPS setting is disabled for load balancers, this is a finding.
Execute the following API call using curl or another REST API client: PUT https://<nsx-mgr>/policy/api/v1/infra/global-config Example request body: { "fips": { "lb_fips_enabled": true }, "resource_type": "GlobalConfig", "_revision": 2 } The global setting is used when the new load balancer instances are created. Changing the setting does not affect existing load balancer instances. To update existing load balancers to use this setting, do the following: From the NSX Manager web interface, go to the Networking >> Load Balancing and then click "Edit" on the target load balancer. In the attachment field, click the "X" to detach the load balancer from its current Gateway and click "Save". Edit the target load balancer again, reattach it to its Gateway, and then click "Save". Caution: Detaching a load balancer from the Tier-1 gateway results in a traffic interruption for the load balancer instance.
From the NSX Manager web interface, go to System >> Configuration >> Appliances. Verify three NSX Managers are deployed, a VIP or external load balancer is configured, and the cluster is in a healthy state. If three NSX Managers are not deployed, a VIP or external load balancer is not configured, and the cluster is not in a healthy state, this is a finding.
To add additional NSX Manager appliances do the following: From the NSX Manager web interface, go to System >> Configuration >> Appliances, and then click "Add NSX Appliance". Supply the required information to add additional nodes as needed, up to three total. To configure NSX with a cluster VIP or external load balancer, do the following: From the NSX Manager web interface, go to System >> Configuration >> Appliances, and then click "Set Virtual IP", enter a VIP that is part of the same subnet as the other management nodes, and then click "Save". To configure NSX with an external load balancer, setup an external load balancer with the following requirements: - Configure the external load balancer to control traffic to the NSX Manager nodes. - Configure the external load balancer to use the round robin method and configure source persistence for the load balancer's virtual IP. - Create or import a signed certificate and apply the same certificate to all the NSX Manager nodes. The certificate must have the FQDN of the virtual IP and each of the nodes in the SAN. Note: An external load balancer will not work with the NSX Manager VIP. Do not configure an NSX Manager VIP if using an external load balancer. If the cluster status is not in a healthy state, identify the degraded component on the appliance and troubleshoot the issue with the error information provided.
This check must be performed in vCenter. From the vSphere Client, go to Administration >> Hosts and Clusters >> Select the cluster where the NSX Managers are deployed >> Configure >> Configuration >> VM/Host Rules. If the NSX Manager cluster does not have rules applied to it that separate the nodes onto different physical hosts, this is a finding.
This fix must be performed in vCenter. From the vSphere Client, go to Administration >> Hosts and Clusters >> Select the cluster where the NSX Managers are deployed >> Configure >> Configuration >> VM/Host Rules. Click "Add" to create a new rule. Provide a name and select "Separate Virtual Machines" under Type. Add the three NSX Manager virtual machines to the list and click "OK".