| Command | checking the Ntp servers for the NSX |
|---|---|
| Status | Failed |
| Expected | Ntp server should be a part of provided Ntp Servers : [] |
| Got | 192.168.0.253 |
| Control | 100601 |
|---|---|
| Title | The NSX Manager must be configured to synchronize internal information system clocks using redundant authoritative time sources. |
| Description | The loss of connectivity to a particular authoritative time source will result in the loss of time synchronization (free-run mode) and increasingly inaccurate time stamps on audit events and other functions. Multiple time sources provide redundancy by including a secondary source. Time synchronization is usually a hierarchy; clients synchronize time to a local source while that source synchronizes its time to a more accurate source. The network device must use an authoritative time server and/or be configured to use redundant authoritative time sources. DOD-approved solutions consist of a combination of a primary and secondary time source using a combination or multiple instances of the following: a time server designated for the appropriate DOD network (NIPRNet/SIPRNet); United States Naval Observatory (USNO) time servers; and/or the Global Positioning System (GPS). The secondary time source must be located in a different geographic region than the primary time source. |
| Severity | High |
| Nist Controls | |
| Check Text |
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. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100602 |
|---|---|
| Title | The NSX Managers must be deployed on separate physical hosts. |
| Description | SDN relies heavily on control messages between a controller and the forwarding devices for network convergence. The controller uses node and link state discovery information to calculate and determine optimum pathing within the SDN network infrastructure based on application, business, and security policies. Operating in the proactive flow instantiation mode, the SDN controller populates forwarding tables to the SDN-aware forwarding devices. At times, the SDN controller must function in reactive flow instantiation mode; that is, when a forwarding device receives a packet for a flow not found in its forwarding table, it must send it to the controller to receive forwarding instructions. With total dependence on the SDN controller for determining forwarding decisions and path optimization within the SDN infrastructure for both proactive and reactive flow modes of operation, having a single point of failure is not acceptable. A controller failure with no failover backup leaves the network in an unmanaged state. Hence, it is imperative that the SDN controllers are deployed as clusters on separate physical hosts to guarantee high network availability. |
| Severity | High |
| Nist Controls | |
| Check Text |
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. |
| Fix Text | Data Not Available |
| Command | checking the logging_enabled |
|---|---|
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Command | checking the logging_enabled |
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Control | 100603 |
|---|---|
| Title | The NSX Distributed Firewall must generate traffic log entries. |
| Description | Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit event content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Associating event types with detected events in the network element logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured network element. |
| Severity | Medium |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Security >> Policy Management >> Distributed Firewall >> All Rules. For each rule, click the gear icon and verify the Logging setting. If Logging is not enabled for any rule, this is a finding. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100604 |
|---|---|
| Title | The NSX Manager must assign users/accounts to organization-defined roles configured with approved authorizations. |
| Description | The lack of authorization-based access control could result in the immediate compromise and unauthorized access to sensitive information. Users must be assigned to roles which are configured with approved authorizations and access permissions. The NSX Manager must be configured granularly based on organization requirements to only allow authorized administrators to execute privileged functions. Role assignments should control which administrators can view or change the device configuration, system files, and locally stored audit information. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
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 to it. 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. |
| Fix Text | Data Not Available |
| Command | checking the Action |
|---|---|
| Status | Failed |
| Expected | Drop or Reject |
| Got | ALLOW |
| Control | 100605 |
|---|---|
| Title | The NSX Distributed Firewall must deny network communications traffic by default and allow network communications traffic by exception. |
| Description | To prevent malicious or accidental leakage of traffic, organizations must implement a deny-by-default security posture at the network perimeter. Such rulesets prevent many malicious exploits or accidental leakage by restricting the traffic to only known sources and only those ports, protocols, or services that are permitted and operationally necessary. As a managed boundary interface, the firewall must block all inbound and outbound network traffic unless a filter is installed to explicitly allow it. The allow filters must comply with the Ports, Protocols, and Services Management (PPSM) Category Assurance List (CAL) and Vulnerability Assessment (VA). |
| Severity | High |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Security >> Policy Management >> Distributed Firewall >> Category Specific Rules >> APPLICATION >> Default Layer3 Section >> Default Layer3 Rule >> Action. If the Default Layer3 Rule is set to ALLOW, this is a finding. |
| Fix Text | a On the main navigation bar, click Security. b In the left pane, navigate to Policy Management > Distributed Firewall. c Click the Category specific rules tab and select Application. d Expand the Default Layer3 Section and for the Default Layer3 Rule, select Reject or Drop from the Actions drop-down menu. e On the Distributed Firewall page, click Publish. Caution Before denying, ensure the necessary rules to whitelist approved traffic are created and published or this change may result in a loss of communication for workloads |
| Command | checking the address_binding_allowlist for Segement Id : fad98876-d7ff-11e4-b9d6-1681e6b88ec1 |
|---|---|
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Command | checking the address_binding_whitelist for Segement Id : fad98876-d7ff-11e4-b9d6-1681e6b88ec1 |
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Command | checking the address_binding_allowlist for Segement Id : fad98876-d7ff-11e4-b9d6-1681e6b88ec1 |
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Command | checking the address_binding_whitelist for Segement Id : fad98876-d7ff-11e4-b9d6-1681e6b88ec1 |
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Command | checking the address_binding_allowlist for Segement Id : fad98876-d7ff-11e4-b9d6-1681e6b88ec1 |
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Command | checking the address_binding_whitelist for Segement Id : fad98876-d7ff-11e4-b9d6-1681e6b88ec1 |
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Command | checking the address_binding_allowlist for Segement Id : fad98876-d7ff-11e4-b9d6-1681e6b88ec1 |
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Command | checking the address_binding_whitelist for Segement Id : fad98876-d7ff-11e4-b9d6-1681e6b88ec1 |
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Control | 100606 |
|---|---|
| Title | The NSX Distributed Firewall must configure SpoofGuard to restrict it from accepting outbound packets that contain an illegitimate address in the source address. |
| Description | A compromised host in an enclave can be used by a malicious platform to launch cyberattacks on third parties. This is a common practice in botnets, which are a collection of compromised computers using malware to attack other computers or networks. Distributed denial-of-service (DDoS) attacks frequently leverage IP source address spoofing to send packets to multiple hosts that in turn will then send return traffic to the hosts with the IP addresses that were forged. This can generate significant amounts of traffic. Therefore, protection measures to counteract IP source address spoofing must be taken. SpoofGuard is a tool that is designed to prevent virtual machines from sending traffic with an IP address from which it is not authorized to send traffic. In the instance that a virtual machine's IP address does not match the IP address on the corresponding logical port and segment address binding in SpoofGuard, the virtual machine's virtual network interface card (vNIC) is prevented from accessing the network entirely. SpoofGuard can be configured at the port or segment level. There are several reasons SpoofGuard might be used, but for the distributed firewall it will guarantee that rules will not be inadvertently (or deliberately) bypassed. For distributed firewall (DFW) rules created using IP sets as sources or destinations, the possibility always exists that a virtual machine could have its IP address forged in the packet header, thereby bypassing the rules in question. |
| Severity | High |
| Nist Controls | |
| Check Text |
Identity Spoof Guard profiles in use by doing the following: From the NSX Manager web interface, go to Networking >> Connectivity >> Segments >> NSX. For each segment, expand view Segment Profiles >> Spoof Guard to note the profiles in use. Review Spoof Guard profile configuration by doing the following: From the NSX Manager web interface, go to Networking >> Connectivity >> Segments >> Profiles >> Segment Profiles. Review the Spoof Guard profiles previously identified as assigned to segments to ensure the following configuration: Port Bindings: Yes If a Segment is not configured with a Spoof Guard profile that has Port Bindings enabled, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the runtime_state for syslog server |
|---|---|
| Status | Passed |
| Expected | running |
| Got | running |
| Command | Checking the syslog servers |
| Status | Failed |
| Expected | Syslog servers should not be nil |
| Got | No Syslog Server found |
| Control | 100607 |
|---|---|
| Title | The NSX Manager must be configured to send logs to a central log server. |
| Description | Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to System >> Configuration >> 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. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100608 |
|---|---|
| Title | The NSX Manager must be configured to integrate with an identity provider that supports multifactor authentication (MFA). |
| Description | Common attacks against single-factor authentication are attacks on user passwords. These attacks include brute force password guessing, password spraying, and password credential stuffing. This requirement also supports nonrepudiation of actions taken by an administrator. This requirement ensures the NSX Manager is configured to use a centralized authentication services to authenticate users prior to granting administrative access. 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. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to System >> Settings >> Users Management >> Authentication Providers. Review the VMware Identity Manager and OpenID Connect tabs. If NSX is not configured to use a VMware Identity Manager or OpenID Connect identity provider that is configured to support MFA, this is a finding. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100609 |
|---|---|
| Title | Configure session timeout to ensure the NSX Manager terminates the device management session at the end of the session or after an organization-defined period of inactivity. |
| Description | Data Not Available |
| Severity | High |
| Nist Controls | |
| Check Text |
From an NSX Manager shell, run the following command: > get service http | find Session Expected result: Session timeout: |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100610 |
|---|---|
| Title | The NSX Manager must be configured to enforce the limit of three consecutive invalid logon attempts, after which time it must block any login attempt for 15 minutes. |
| Description | By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. |
| Severity | High |
| Nist Controls | |
| Check Text |
Verify NSX Manager is configured to set the account lockout-period after a defined number of consecutive invalid login attempts. Log in to NSX Manager command line interface with credentials authorized for administration and run the following command: >> get auth-policy api lockout-period If lockout-period is not set to |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100611 |
|---|---|
| Title | The NSX Manager must be configured to enforce the limit of three consecutive invalid logon attempts, after which time it must block any login attempt for 15 minutes. |
| Description | By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. |
| Severity | High |
| Nist Controls | |
| Check Text |
Verify NSX Manager is configured to enforce the limit of consecutive invalid login attempts. Log in to NSX Manager command line interface with credentials authorized for administration and run the following command: >> get auth-policy api max-auth-failures If max-auth-failures is not set to |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100612 |
|---|---|
| Title | Configure account lockout policies to set lockout reset period. |
| Description | Data Not Available |
| Severity | High |
| Nist Controls | |
| Check Text |
Verify NSX Manager is configured to reset account lockout period. Log in to NSX Manager shell with credentials authorized for administration and run the following command: >> get auth-policy api lockout-reset-period If lockout-reset-period is not set to |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100613 |
|---|---|
| Title | The NSX Manager must configure logging levels for services to ensure audit records are generated. |
| Description | Without generating audit records specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the network device (e.g., module or policy filter). |
| Severity | High |
| Nist Controls | |
| Check Text |
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. |
| Fix Text | Data Not Available |
| Command | checking the minimum_password_length |
|---|---|
| Status | Failed |
| Expected | Should be greater than or equals to 15 |
| Got | 12 |
| Control | 100614 |
|---|---|
| Title | The NSX Manager must enforce a minimum 15-character password length for local accounts. |
| Description | Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password. |
| Severity | High |
| Nist Controls | |
| Check Text |
From an NSX Manager shell, run the following command: > get password-complexity If the minimum password length is not Get-VMHost -Name |
| Fix Text | Data Not Available |
| Command | checking the ip_address |
|---|---|
| Status | Passed |
| Expected | Should not be empty or 0.0.0.0 |
| Got | 192.168.50.4 |
| Command | checking the ip6_address |
| Status | Failed |
| Expected | Should not be empty or :: |
| Got | :: |
| Control | 100615 |
|---|---|
| Title | The NSX Manager must be configured as a cluster. |
| Description | Failure in a known state can address safety or security in accordance with the mission needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the SDN controller. Preserving network element state information helps to facilitate continuous network operations minimal or no disruption to mission-essential workload processes and flows. |
| Severity | High |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to System >> Appliances. Verify there are three NSX Managers deployed, a VIP or external load balancer is configured, and the cluster is in a healthy state. If there are not three NSX Managers deployed and a VIP or external load balancer configured and the cluster is in a healthy state, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the client_api_concurrency_limit |
|---|---|
| Status | Passed |
| Expected | 40 |
| Got | 40 |
| Command | checking the client_api_rate_limit |
| Status | Passed |
| Expected | 100 |
| Got | 100 |
| Command | checking the global_api_concurrency_limit |
| Status | Passed |
| Expected | 199 |
| Got | 199 |
| Control | 100616 |
|---|---|
| Title | The NSX Manager must be configured to protect against denial-of-service (DoS) attacks by limit the number of concurrent sessions to an organization-defined number. |
| Description | DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. Limiting the number of concurrent open sessions helps limit the risk of DoS attacks. Organizations may define the maximum number of concurrent sessions for system accounts globally or by connection type. By default, the NSX Manager has a protection mechanism in place to prevent the API from being overloaded. This setting also addresses concurrent sessions for integrations into NSX API to monitor or configure NSX. |
| Severity | High |
| Nist Controls | |
| Check Text |
From an NSX Manager shell, run the following command: > get service http | find limit Expected result: Client API rate limit: 100 requests/sec Client API concurrency limit: 40 connections Global API concurrency limit: 199 connections If the output does not match the expected result, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the logged value for Tier-0 with rule Name : default_rule |
|---|---|
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Control | 100617 |
|---|---|
| Title | The NSX Tier-0 Gateway Firewall must generate traffic log entries. |
| Description | Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit event content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Associating event types with detected events in the network element logs provides a means of investigating an attack, recognizing resource usage or capacity thresholds, or identifying an improperly configured network element. |
| Severity | High |
| Nist Controls | |
| Check Text |
If the Tier-0 Gateway is deployed in an Active/Active HA mode and no stateless rules exist, this is Not Applicable. From the NSX Manager web interface, go to Security >> Policy Management >> Gateway Firewall >> Gateway Specific Rules. For each Tier-0 Gateway and for each rule, click the gear icon and verify the Logging setting. If Logging is not Enabled, this is a finding. |
| Fix Text | Data Not Available |
| Command | Data Not Available |
|---|---|
| Status | Failed |
| Expected | Data Not Available |
| Got | No syslog servers are configured on Edge Node : nsx-edge-l-02a |
| Command | Data Not Available |
| Status | Failed |
| Expected | Data Not Available |
| Got | No syslog servers are configured on Edge Node : nsx-edge-l-01a |
| Control | 100618 |
|---|---|
| Title | The NSX Tier-0 Gateway Firewall must be configured to send traffic log entries to a central audit server. |
| Description | Without the ability to centrally manage the content captured in the traffic log entries, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. The DOD requires centralized management of all network component audit record content. Network components requiring centralized traffic log management must have the ability to support centralized management. The content captured in traffic log entries must be managed from a central location (necessitating automation). Centralized management of traffic log records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Ensure at least one syslog server is configured on the firewall. If the product inherently has the ability to store log records locally, the local log must also be secured. However, this requirement is not met since it calls for a use of a central audit server. |
| Severity | High |
| Nist Controls | |
| Check Text |
From an NSX Edge Node shell hosting the Tier-0 Gateway, run the following command: > get logging-servers Note: This check must be run from each NSX Edge Node hosting a Tier-0 Gateway, as they are configured individually. or If Node Profiles are used, from the NSX Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles. Click All NSX Nodes and verify the Syslog servers listed. If any configured logging servers are configured with a protocol of udp, this is a finding. If any configured logging servers are not configured with a level of info, this is a finding. If no logging-servers are configured, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the Action for Tier-1 Gateway : WLD-Edge-T1 |
|---|---|
| Status | Failed |
| Expected | Drop or Reject |
| Got | ALLOW |
| Command | checking the Action for Tier-1 Gateway : reg-a-m01-lb01-t1-gw01 |
| Status | Failed |
| Expected | Drop or Reject |
| Got | ALLOW |
| Control | 100619 |
|---|---|
| Title | The NSX Tier-1 Gateway firewall must deny network communications traffic by default and allow network communications traffic by exception. |
| Description | To prevent malicious or accidental leakage of traffic, organizations must implement a deny-by-default security posture at the network perimeter. Such rulesets prevent many malicious exploits or accidental leakage by restricting the traffic to only known sources and only those ports, protocols, or services that are permitted and operationally necessary. As a managed boundary interface, the firewall must block all inbound and outbound network traffic unless a filter is installed to explicitly allow it. The allow filters must comply with the Ports, Protocols, and Services Management (PPSM) Category Assurance List (CAL) and Vulnerability Assessment (VA). |
| Severity | High |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Security >> Policy Management >> Gateway Firewall >> Gateway Specific Rules >> Choose each Tier-1 Gateway in drop-down >> Policy_Default_Infra Section >> Action. If the default_rule is set to Allow, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the Action for Tier-0 Gateway : WLD-Edge-T0 |
|---|---|
| Status | Failed |
| Expected | Drop or Reject |
| Got | ALLOW |
| Control | 100620 |
|---|---|
| Title | The NSX Tier-0 Gateway Firewall must deny network communications traffic by default and allow network communications traffic by exception. |
| Description | To prevent malicious or accidental leakage of traffic, organizations must implement a deny-by-default security posture at the network perimeter. Such rulesets prevent many malicious exploits or accidental leakage by restricting the traffic to only known sources and only those ports, protocols, or services that are permitted and operationally necessary. As a managed boundary interface, the firewall must block all inbound and outbound network traffic unless a filter is installed to explicitly allow it. The allow filters must comply with the Ports, Protocols, and Services Management (PPSM) Category Assurance List (CAL) and Vulnerability Assessment (VA). |
| Severity | High |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Security >> Policy Management >> Gateway Firewall >> Gateway Specific Rules. Choose each Tier-0 Gateway in drop-down, then select Policy_Default_Infra Section >> Action. If the default_rule is set to Allow, this is a finding. |
| Fix Text | Data Not Available |
| Command | Checking the enablement of Multicast/Interface on Tier 0 gateway |
|---|---|
| Status | Not Applicable |
| Expected | Multicast/Interface should be enabled on Tier 0 gateway |
| Got | Multicast is not enabled |
| Control | 100621 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to disable Protocol Independent Multicast (PIM) on all interfaces that are not required to support multicast routing. |
| Description | If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel. Limiting where, within the network, a given multicast group's data is permitted to flow is an important first step in improving multicast security. A scope zone is an instance of a connected region of a given scope. Zones of the same scope cannot overlap while zones of a smaller scope will fit completely within a zone of a larger scope. For example, Admin-local scope is smaller than Site-local scope, so the administratively configured boundary fits within the bounds of a site. According to RFC 4007 IPv6 Scoped Address Architecture (section 5), scope zones are also required to be convex from a routing perspective; that is, packets routed within a zone must not pass through any links that are outside of the zone. This requirement forces each zone to be one contiguous island rather than a series of separate islands. As stated in the DOD IPv6 IA Guidance for MO3, One should be able to identify all interfaces of a zone by drawing a closed loop on their network diagram, engulfing some routers and passing through some routers to include only some of their interfaces. Therefore, it is imperative that the network engineers have documented their multicast topology and thereby knows which interfaces are enabled for multicast. Once this is done, the zones can be scoped as required. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-0 Gateways. For every Tier-0 Gateway, expand the Tier-0 Gateway >> Interfaces, and click on the number of interfaces present to open the interfaces dialog. Expand each interface that is not required to support multicast routing, then expand Multicast and verify PIM is disabled. If PIM is enabled on any interfaces that are not supporting multicast routing, this is a finding. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100622 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to have all inactive interfaces removed. |
| Description | An inactive interface is rarely monitored or controlled and may expose a network to an undetected attack on that interface. Unauthorized personnel with access to the communication facility could gain access to a router by connecting to a configured interface that is not in use. If an interface is no longer used, the configuration must be deleted and the interface disabled. For sub-interfaces, delete sub-interfaces that are on inactive interfaces and delete sub-interfaces that are themselves inactive. If the sub-interface is no longer necessary for authorized communications, it must be deleted. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-0 Gateways. For every Tier-0 Gateway, expand the Tier-0 Gateway >> Interfaces and GRE Tunnels, and click on the number of External and Service interfaces present to open the interfaces dialog. Review each interface present to determine if they are not in use or inactive. If there are any interfaces present on a Tier-0 Gateway that are not in use or inactive, this is a finding. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100623 |
|---|---|
| Title | The NSX Tier-1 Gateway router must be configured to have all inactive interfaces removed. |
| Description | An inactive interface is rarely monitored or controlled and may expose a network to an undetected attack on that interface. Unauthorized personnel with access to the communication facility could gain access to a router by connecting to a configured interface that is not in use. If an interface is no longer used, the configuration must be deleted and the interface disabled. For sub-interfaces, delete sub-interfaces that are on inactive interfaces and delete sub-interfaces that are themselves inactive. If the sub-interface is no longer necessary for authorized communications, it must be deleted. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-1 Gateways. For every Tier-1 Gateway, expand the Tier-1 Gateway. Click on the number in the Linked Segments to review the currently linked segments. For every Tier-1 Gateway, expand the Tier-1 Gateway. Expand Service Interfaces, then click on the number to review the Service Interfaces. Review each interface or linked segment present to determine if they are not in use or inactive. If there are any linked segments or service interfaces present on a Tier-1 Gateway that are not in use or inactive, this is a finding. |
| Fix Text | Data Not Available |
| Command | Checking the DistributedFloodProtectionProfile |
|---|---|
| Status | Skipped |
| Expected | DistributedFloodProtectionProfile should not be nil |
| Got | No DistributedFloodProtectionProfile found |
| Control | 100624 |
|---|---|
| Title | The NSX Distributed Firewall must limit the effects of packet flooding types of denial-of-service (DoS) attacks. |
| Description | A firewall experiencing a DoS attack will not be able to handle production traffic load. The high utilization and CPU caused by a DoS attack will also have an effect on control keep-alives and timers used for neighbor peering resulting in route flapping and will eventually black hole production traffic. The device must be configured to contain and limit a DoS attack's effect on the device's resource utilization. The use of redundant components and load balancing are examples of mitigating flood-type DoS attacks through increased capacity. |
| Severity | High |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Security >> Settings >> General Settings >> Firewall >> Flood Protection to view Flood Protection profiles. If there are no Flood Protection profiles of type Distributed Firewall, this is a finding. If the TCP Half Open Connection limit, UDP Active Flow Limit, ICMP Active Flow Limit, and Other Active Connection Limit are set to not set or SYN Cache and RST Spoofing is not Enabled on a profile, this is a finding. For each distributed firewall flood protection profile, examine the Applied To field to view the workloads it is protecting. If a distributed firewall flood protection profile is not applied to all workloads through one or more policies, this is a finding. |
| Fix Text | Data Not Available |
| Command | Checking the enablement of flood-protection-profiles on Tier 0 gateway |
|---|---|
| Status | Not Applicable |
| Expected | flood-protection-profiles should be enabled on Tier 0 gateway |
| Got | flood-protection-profiles is not enabled |
| Control | 100625 |
|---|---|
| Title | The NSX Tier-0 Gateway Firewall must manage excess bandwidth to limit the effects of packet flooding types of denial-of-service (DoS) attacks. |
| Description | A firewall experiencing a DoS attack will not be able to handle production traffic load. The high usage and CPU caused by a DoS attack will also have an effect on control keep-alives and timers used for neighbor peering resulting in route flapping and will eventually black hole production traffic. The device must be configured to contain and limit a DoS attack's effect on the device's resource usage. The use of redundant components and load balancing are examples of mitigating flood-type DoS attacks through increased capacity. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
If the Tier-0 Gateway is deployed in an Active/Active HA mode and no stateless rules exist, this is Not Applicable. From the NSX Manager web interface, go to Security >> Settings >> General Settings >> Firewall >> Flood Protection to view Flood Protection profiles. If there are no Flood Protection profiles of type Gateway, this is a finding. For each gateway flood protection profile, verify the TCP Half Open Connection limit, UDP Active Flow Limit, ICMP Active Flow Limit, and Other Active Connection Limit are set to None, this is a finding. For each gateway flood protection profile, examine the Applied To field to view the Tier-0 Gateways to which it is applied. If a gateway flood protection profile is not applied to all applicable Tier-0 Gateways through one or more policies, this is a finding. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100626 |
|---|---|
| Title | The NSX Tier-0 Gateway must be configured to use a unique password for each autonomous system (AS) with which it peers. |
| Description | If the same keys are used between External Border Gateway Protocol (eBGP) neighbors, the chance of a hacker compromising any of the BGP sessions increases. It is possible that a malicious user exists in one autonomous system who would know the key used for the eBGP session. This user would then be able to hijack BGP sessions with other trusted neighbors. |
| Severity | High |
| Nist Controls | |
| Check Text |
If the Tier-0 Gateway is not using BGP, this is Not Applicable. Since the NSX Tier-0 Gateway does not reveal the current password, interview the router administrator to determine if unique passwords are being used. If unique passwords are not being used for each AS, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the Maximum Routes for BGP neighbor for Tier 0 gateway WLD-Edge-T0 |
|---|---|
| Status | Failed |
| Expected | Maximum Routes should not be nil |
| Got | null |
| Command | checking the Maximum Routes for BGP neighbor for Tier 0 gateway WLD-Edge-T0 |
| Status | Failed |
| Expected | Maximum Routes should not be nil |
| Got | null |
| Control | 100627 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to use the Border Gateway Protocol (BGP) maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks. |
| Description | The effects of prefix de-aggregation can degrade router performance due to the size of routing tables and also result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured router, prefix de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements. In 1997, misconfigured routers in the Florida Internet Exchange network (AS7007) de-aggregated every prefix in their routing table and started advertising the first /24 block of each of these prefixes as their own. Faced with this additional burden, the internal routers became overloaded and crashed repeatedly. This caused prefixes advertised by these routers to disappear from routing tables and reappear when the routers came back online. As the routers came back after crashing, they were flooded with the routing table information by their neighbors. The flood of information would again overwhelm the routers and cause them to crash. This process of route flapping served to destabilize not only the surrounding network but also the entire internet. Routers trying to reach those addresses would choose the smaller, more specific /24 blocks first. This caused backbone networks throughout North America and Europe to crash. Maximum prefix limits on peer connections combined with aggressive prefix-size filtering of customers' reachability advertisements will effectively mitigate the de-aggregation risk. BGP maximum prefix must be used on all eBGP routers to limit the number of prefixes that it should receive from a particular neighbor, whether customer or peering autonomous system (AS). Consider each neighbor and how many routes they should be advertising and set a threshold slightly higher than the number expected. |
| Severity | High |
| Nist Controls | |
| Check Text |
If the Tier-0 Gateway is not using BGP, this is Not Applicable. From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-0 Gateways. For every Tier-0 Gateway with BGP enabled, expand the Tier-0 Gateway. Expand BGP, click on the number next to BGP Neighbors, and then view the Router Filters for each neighbor. If Maximum Routes is not configured or a route filter does not exist for each BGP neighbor, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the Action for TimeZone |
|---|---|
| Status | Passed |
| Expected | [Etc/UTC, UTC] |
| Got | Etc/UTC |
| Control | 100628 |
|---|---|
| Title | The NSX Manager must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC). |
| Description | If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time stamps generated by the application include date and time. Time is commonly expressed in UTC, a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. |
| Severity | High |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles. 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. Note: This check must be run from each NSX Manager as they are configured individually if done from the command line. |
| Fix Text | Data Not Available |
| Command | Checking the issuer of certificate : Cluster Manager-Corfu Client certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : cluster-manager |
|---|---|
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=cluster-manager |
| Command | Checking the issuer of certificate : AR-Corfu Client certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : ar |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=ar |
| Command | Checking the issuer of certificate : Messaging Manager-Corfu Client certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : messaging-manager |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=messaging-manager |
| Command | Checking the issuer of certificate : Upgrade Coordinator-Corfu Client certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : upgrade-coordinator |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=upgrade-coordinator |
| Command | Checking the issuer of certificate : Cluster certificate for site a9273e63-2fcd-4b72-91b0-3cb4fd7f40a7 for subject : -cluster |
| Status | Passed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=-cluster,OU=NSX,O=VMware Inc.,L=Palo Alto,ST=CA,C=US |
| Command | Checking the issuer of certificate : Corfu Server certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : corfu |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=corfu |
| Command | Checking the issuer of certificate : MP-Corfu Client certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : mp |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=mp |
| Command | Checking the issuer of certificate : CCP certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : nsx-controller |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=nsx-controller,OU=NSBU,O=VMware\, Inc.,ST=CA,C=US |
| Command | Checking the issuer of certificate : APH-TN certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : VMware-NSX-ApplProxyHub |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | UID=0fd9ca8f-0cf8-4d55-8b3c-e2ae4e841347,CN=VMware-NSX-ApplProxyHub,1.2.840.113549.1.9.1=#161b73736c2d63657274696669636174657340766d776172652e636f6d,O=VMware\, Inc.,L=Palo Alto,ST=California,C=US |
| Command | Checking the issuer of certificate : Site Manager-Corfu Client certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : site-manager |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=site-manager |
| Command | Checking the issuer of certificate : CCP-Corfu Client certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : ccp |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=ccp |
| Command | Checking the issuer of certificate : Monitoring-Corfu Client certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : monitoring |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=monitoring |
| Command | Checking the issuer of certificate : APH-AR certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : VMware-NSX-ApplProxyHub |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | UID=0fd9ca8f-0cf8-4d55-8b3c-e2ae4e841347,CN=VMware-NSX-ApplProxyHub,1.2.840.113549.1.9.1=#161b73736c2d63657274696669636174657340766d776172652e636f6d,O=VMware\, Inc.,L=Palo Alto,ST=California,C=US |
| Command | Checking the issuer of certificate : API certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : nsx-l-01a.corp.local |
| Status | Passed |
| Expected | Valid Certificate from approved service provider |
| Got | C=US,ST=CA,L=Palo Alto,O=VMware Inc.,OU=NSX,CN=nsx-l-01a.corp.local |
| Command | Checking the issuer of certificate : IDPS reporting-Corfu Client certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : idps-reporting |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=idps-reporting |
| Command | Checking the issuer of certificate : CM Inventory-Corfu Client certificate for node 38e51c42-d077-4de1-8328-7d82897e0fc0 for subject : cm-inventory |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=cm-inventory |
| Command | Checking the issuer of certificate : LocalManager for subject : local-manager |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=local-manager,O=VMware,L=PaloAlto,ST=California,C=US |
| Command | Checking the issuer of certificate : Cluster Manager-Corfu Client certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : cluster-manager |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=cluster-manager |
| Command | Checking the issuer of certificate : AR-Corfu Client certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : ar |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=ar |
| Command | Checking the issuer of certificate : Messaging Manager-Corfu Client certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : messaging-manager |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=messaging-manager |
| Command | Checking the issuer of certificate : Upgrade Coordinator-Corfu Client certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : upgrade-coordinator |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=upgrade-coordinator |
| Command | Checking the issuer of certificate : Corfu Server certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : corfu |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=corfu |
| Command | Checking the issuer of certificate : MP-Corfu Client certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : mp |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=mp |
| Command | Checking the issuer of certificate : CCP certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : nsx-controller |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=nsx-controller,OU=NSBU,O=VMware\, Inc.,ST=CA,C=US |
| Command | Checking the issuer of certificate : APH-TN certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : VMware-NSX-ApplProxyHub |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | UID=768fbce9-58f3-40e7-ab66-bd8ad700b8f8,CN=VMware-NSX-ApplProxyHub,1.2.840.113549.1.9.1=#161b73736c2d63657274696669636174657340766d776172652e636f6d,O=VMware\, Inc.,L=Palo Alto,ST=California,C=US |
| Command | Checking the issuer of certificate : Site Manager-Corfu Client certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : site-manager |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=site-manager |
| Command | Checking the issuer of certificate : CCP-Corfu Client certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : ccp |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=ccp |
| Command | Checking the issuer of certificate : Monitoring-Corfu Client certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : monitoring |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=monitoring |
| Command | Checking the issuer of certificate : APH-AR certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : VMware-NSX-ApplProxyHub |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | UID=768fbce9-58f3-40e7-ab66-bd8ad700b8f8,CN=VMware-NSX-ApplProxyHub,1.2.840.113549.1.9.1=#161b73736c2d63657274696669636174657340766d776172652e636f6d,O=VMware\, Inc.,L=Palo Alto,ST=California,C=US |
| Command | Checking the issuer of certificate : API certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : nsx-l-02a.corp.local |
| Status | Passed |
| Expected | Valid Certificate from approved service provider |
| Got | C=US,ST=CA,L=Palo Alto,O=VMware Inc.,OU=NSX,CN=nsx-l-02a.corp.local |
| Command | Checking the issuer of certificate : IDPS reporting-Corfu Client certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : idps-reporting |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=idps-reporting |
| Command | Checking the issuer of certificate : CM Inventory-Corfu Client certificate for node 34f31c42-5187-dd1d-869d-b98e87aad7cb for subject : cm-inventory |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=cm-inventory |
| Command | Checking the issuer of certificate : Cluster Manager-Corfu Client certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : cluster-manager |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=cluster-manager |
| Command | Checking the issuer of certificate : AR-Corfu Client certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : ar |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=ar |
| Command | Checking the issuer of certificate : Messaging Manager-Corfu Client certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : messaging-manager |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=messaging-manager |
| Command | Checking the issuer of certificate : Upgrade Coordinator-Corfu Client certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : upgrade-coordinator |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=upgrade-coordinator |
| Command | Checking the issuer of certificate : Corfu Server certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : corfu |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=corfu |
| Command | Checking the issuer of certificate : MP-Corfu Client certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : mp |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=mp |
| Command | Checking the issuer of certificate : CCP certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : nsx-controller |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=nsx-controller,OU=NSBU,O=VMware\, Inc.,ST=CA,C=US |
| Command | Checking the issuer of certificate : APH-TN certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : VMware-NSX-ApplProxyHub |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | UID=fc723d39-e8e6-41b2-b0bd-3f4926dda44c,CN=VMware-NSX-ApplProxyHub,1.2.840.113549.1.9.1=#161b73736c2d63657274696669636174657340766d776172652e636f6d,O=VMware\, Inc.,L=Palo Alto,ST=California,C=US |
| Command | Checking the issuer of certificate : Site Manager-Corfu Client certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : site-manager |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=site-manager |
| Command | Checking the issuer of certificate : CCP-Corfu Client certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : ccp |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=ccp |
| Command | Checking the issuer of certificate : Monitoring-Corfu Client certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : monitoring |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=monitoring |
| Command | Checking the issuer of certificate : APH-AR certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : VMware-NSX-ApplProxyHub |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | UID=fc723d39-e8e6-41b2-b0bd-3f4926dda44c,CN=VMware-NSX-ApplProxyHub,1.2.840.113549.1.9.1=#161b73736c2d63657274696669636174657340766d776172652e636f6d,O=VMware\, Inc.,L=Palo Alto,ST=California,C=US |
| Command | Checking the issuer of certificate : API certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : nsx-l-03a.corp.local |
| Status | Passed |
| Expected | Valid Certificate from approved service provider |
| Got | C=US,ST=CA,L=Palo Alto,O=VMware Inc.,OU=NSX,CN=nsx-l-03a.corp.local |
| Command | Checking the issuer of certificate : IDPS reporting-Corfu Client certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : idps-reporting |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=idps-reporting |
| Command | Checking the issuer of certificate : CM Inventory-Corfu Client certificate for node 4fef1c42-3e3a-9c4b-924e-6e6023455545 for subject : cm-inventory |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | CN=cm-inventory |
| Command | Checking the issuer of certificate : 5fb0551f-3ec7-464c-9329-506a0eb177b9 for subject : nsx-l-01a.corp.local |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | OU=VMware Engineering,O=vc-l-01a.corp.local,ST=California,C=US,DC=local,DC=vsphere,CN=CA |
| Command | Checking the issuer of certificate : 5fb0551f-3ec7-464c-9329-506a0eb177b9 for subject : CA |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | OU=VMware Engineering,O=vc-l-01a.corp.local,ST=California,C=US,DC=local,DC=vsphere,CN=CA |
| Command | Checking the issuer of certificate : 0bac5646-20d4-4a74-bf2f-cb84161dc3d8 for subject : nsx-l-02a.corp.local |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | OU=VMware Engineering,O=vc-l-01a.corp.local,ST=California,C=US,DC=local,DC=vsphere,CN=CA |
| Command | Checking the issuer of certificate : 0bac5646-20d4-4a74-bf2f-cb84161dc3d8 for subject : CA |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | OU=VMware Engineering,O=vc-l-01a.corp.local,ST=California,C=US,DC=local,DC=vsphere,CN=CA |
| Command | Checking the issuer of certificate : 735ce7be-3bc7-4ef8-a48c-80d3412cba11 for subject : nsx-l-03a.corp.local |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | OU=VMware Engineering,O=vc-l-01a.corp.local,ST=California,C=US,DC=local,DC=vsphere,CN=CA |
| Command | Checking the issuer of certificate : 735ce7be-3bc7-4ef8-a48c-80d3412cba11 for subject : CA |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | OU=VMware Engineering,O=vc-l-01a.corp.local,ST=California,C=US,DC=local,DC=vsphere,CN=CA |
| Command | Checking the issuer of certificate : 3f6d24f3-c5a7-4e4b-85d2-f4f66138184e for subject : nsx-lb-a.corp.local |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | OU=VMware Engineering,O=vc-l-01a.corp.local,ST=California,C=US,DC=local,DC=vsphere,CN=CA |
| Command | Checking the issuer of certificate : 3f6d24f3-c5a7-4e4b-85d2-f4f66138184e for subject : CA |
| Status | Failed |
| Expected | Valid Certificate from approved service provider |
| Got | OU=VMware Engineering,O=vc-l-01a.corp.local,ST=California,C=US,DC=local,DC=vsphere,CN=CA |
| Control | 100629 |
|---|---|
| Title | The NSX Manager must obtain its public key certificates from an appropriate certificate policy through an approved service provider. |
| Description | For user certificates, each organization obtains certificates from an approved, shared service provider, as required by Office of Management and Budget (OMB) policy. For federal agencies operating a legacy public key infrastructure cross-certified with the Federal Bridge Certification Authority at medium assurance or higher, this Certification Authority will suffice. |
| Severity | High |
| Nist Controls | |
| Check Text |
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. |
| Fix Text | Data Not Available |
| Command | checking the backup_enabled |
|---|---|
| Status | Passed |
| Expected | Should be true |
| Got | true |
| Command | checking the resource_type |
| Status | Passed |
| Expected | Should be in [IntervalBackupSchedule, WeeklyBackupSchedule] |
| Got | IntervalBackupSchedule |
| Control | 100630 |
|---|---|
| Title | The NSX Manager must be configured to conduct backups on an organizationally defined schedule. |
| Description | Information system backup is a critical step in maintaining data assurance and availability. Information system and security-related documentation contains information pertaining to system configuration and security settings. If this information were not backed up, and a system failure were to occur, the security settings would be difficult to reconfigure quickly and accurately. Maintaining a backup of information system and security-related documentation provides for a quicker recovery time when system outages occur. This control requires the network device to support the organizational central backup process for user account information associated with the network device. This function may be provided by the network device itself; however, the preferred best practice is a centralized backup rather than each network device performing discrete backups. |
| Severity | High |
| Nist Controls | |
| Check Text |
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. |
| Fix Text | Data Not Available |
| Command | checking the logged value for Tier-0 with interface : nsx-edge-l-01a_5fa8fcc5-3db3-48e2-92a2-36d005558045_192.180.0.11 local service Name : WLD-Edge-T0 for Tier 0 gateway WLD-Edge-T0 |
|---|---|
| Status | Passed |
| Expected | STRICT |
| Got | STRICT |
| Command | checking the logged value for Tier-0 with interface : nsx-edge-l-01a_d04be492-7240-4591-91c0-aba6c9d03350_192.170.0.11 local service Name : WLD-Edge-T0 for Tier 0 gateway WLD-Edge-T0 |
| Status | Passed |
| Expected | STRICT |
| Got | STRICT |
| Command | checking the logged value for Tier-0 with interface : nsx-edge-l-02a_5fa8fcc5-3db3-48e2-92a2-36d005558045_192.180.0.12 local service Name : WLD-Edge-T0 for Tier 0 gateway WLD-Edge-T0 |
| Status | Passed |
| Expected | STRICT |
| Got | STRICT |
| Command | checking the logged value for Tier-0 with interface : nsx-edge-l-02a_d04be492-7240-4591-91c0-aba6c9d03350_192.170.0.12 local service Name : WLD-Edge-T0 for Tier 0 gateway WLD-Edge-T0 |
| Status | Passed |
| Expected | STRICT |
| Got | STRICT |
| Control | 100631 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to restrict it from accepting outbound IP packets that contain an illegitimate address in the source address field by enabling Unicast Reverse Path Forwarding (uRPF). |
| Description | A compromised host in an enclave can be used by a malicious platform to launch cyber attacks on third parties. This is a common practice in botnets, which are a collection of compromised computers using malware to attack other computers or networks. Distributed denial-of-service (DDoS) attacks frequently leverage IP source address spoofing to send packets to multiple hosts that in turn will then send return traffic to the hosts with the IP addresses that were forged. This can generate significant amounts of traffic. Therefore, protection measures to counteract IP source address spoofing must be taken. When uRPF is enabled in strict mode, the packet must be received on the interface that the device would use to forward the return packet; thereby mitigating IP source address spoofing. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-0 Gateways. For every Tier-0 Gateway, expand Tier-0 Gateway >> Interfaces, and then click on the number of interfaces present to open the interfaces dialog. Expand each interface to view the URPF Mode configuration. If URPF Mode is not set to Strict on any interface, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the encryption for BGP neighbor for Tier 0 gateway WLD-Edge-T0 |
|---|---|
| Status | Passed |
| Expected | Encryption should be enabled |
| Got | true |
| Command | checking the encryption for BGP neighbor for Tier 0 gateway WLD-Edge-T0 |
| Status | Passed |
| Expected | Encryption should be enabled |
| Got | true |
| Control | 100632 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to use encryption for border gateway protocol (BGP) routing protocol authentication. |
| Description | A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a traffic attraction attack and is prevented by configuring neighbor router authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack. This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as Open Shortest Path First [OSPF], Enhanced Interior Gateway Routing Protocol [EIGRP], and Intermediate System to Intermediate System [IS-IS]) and Exterior Gateway Protocols (such as BGP), multiprotocol label switching (MPLS)-related protocols (such as Label Distribution Protocol [LDP]), and multicast-related protocols. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
If the Tier-0 Gateway is not using BGP, this is Not Applicable. To verify BGP neighbors are using authentication with encryption do the following: From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-0 Gateways. For every Tier-0 Gateway expand the Tier-0 Gateway. Expand BGP, click the number next to BGP Neighbors and expand each BGP neighbor. Expand the Timers and Password section and review the Password field. If any BGP neighbors do not have a password configured, this is a finding. |
| Fix Text | a On the main navigation bar, click Networking. b In the left pane, navigate to Connectivity > Tier-0 gateways. c Expand the NSX tier-0 gateway. d Expand the BGP section and click the number next to BGP neighbors. e In the Set BGP neighbors dialog box, click the vertical ellipsis and click Edit for the first neighbor. f Under Timers and Password, enter a unique password of up to 20 characters that is different from other autonomous systems and then click Save. g Repeat the step to configure all neighbors. |
| Command | Checking the OSPF services for tier 0 gateway : WLD-Edge-T0 |
|---|---|
| Status | Failed |
| Expected | OSPF services should be enabled for Tier 0 gateways |
| Got | OSPF is not enabled for tier 0 gateway : WLD-Edge-T0 |
| Control | 100633 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to use encryption for Open Shortest Path First (OSPF) routing protocol authentication. |
| Description | A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or used to disrupt the network's ability to communicate with other networks. This is known as a traffic attraction attack and is prevented by configuring neighbor router authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack. This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, Enhanced Interior Gateway Routing Protocol [EIGRP], and Intermediate System to Intermediate System [IS-IS]) and exterior gateway protocols (such as Border Gateway Protocol [BGP]), multiprotocol label switching (MPLS)-related protocols (such as Label Distribution Protocol [LDP]), and multicast-related protocols. Typically routing protocols must be setup on both sides so knowing the authentication key does not necessarily mean an attacker would be able to setup a rogue router and peer with a legitimate one and inject malicious routes. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
If the Tier-0 Gateway is not using OSPF, this is Not Applicable. To verify OSPF areas are using authentication with encryption do the following: From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-0 Gateways. For every Tier-0 Gateway expand the Tier-0 Gateway. Expand OSPF, click the number next to Area Definition, and view the Authentication field for each area. If OSPF area definitions do not have the Authentication field set to MD5 and a Key ID and Password configured, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the runtime_state for ssh Services |
|---|---|
| Status | Passed |
| Expected | Stopped |
| Got | stopped |
| Command | checking the start_on_boot for SSH Services |
| Status | Passed |
| Expected | false |
| Got | false |
| Control | 100634 |
|---|---|
| Title | The NSX Manager must disable SSH. |
| Description | The NSX shell provides temporary access to commands essential for server maintenance. Intended primarily for use in break-fix scenarios, the NSX shell is well suited for checking and modifying configuration details, not always generally accessible, using the web interface. The NSX shell is accessible remotely using SSH. Under normal operating conditions, SSH access to the managers must be disabled as is the default. As with the NSX shell, SSH is also intended only for temporary use during break-fix scenarios. SSH must therefore be disabled under normal operating conditions and must only be enabled for diagnostics or troubleshooting. Remote access to the managers must therefore be limited to the web interface and API at all other times. |
| Severity | High |
| Nist Controls | |
| Check Text |
From an NSX Manager shell, run the following command: > get service ssh Example results: Service name: ssh Service state: stopped Start on boot: False Root login: enabled If the SSH server is not stopped or starts on boot, this is a finding. |
| Fix Text | Data Not Available |
| Command | Checking the ICMP services for Tier 0 gateway |
|---|---|
| Status | Failed |
| Expected | ICMP services should not be null |
| Got | ICMP service Found for Tier 0 gateway |
| Control | 100635 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to have Internet Control Message Protocol (ICMP) unreachable notifications disabled on all external interfaces. |
| Description | The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Host unreachable ICMP messages are commonly used by attackers for network mapping and diagnosis. |
| Severity | High |
| Nist Controls | |
| Check Text |
If the Tier-0 Gateway is deployed in an Active/Active HA mode, this is Not Applicable. From the NSX Manager web interface, go to Security >> Policy Management >> Gateway Firewall >> Gateway Specific Rules, and choose each Tier-0 Gateway in the drop-down. Review each Tier-0 Gateway Firewall rule to verify one exists to drop ICMP unreachable messages. If a rule does not exist to drop ICMP unreachable messages, this is a finding. |
| Fix Text | Data Not Available |
| Command | Checking if tier-0s has ICMP Mask Reply rule |
|---|---|
| Status | Skipped |
| Expected | ICMP Mask Reply rule should found. |
| Got | No ICMP Mask Reply rule found. |
| Command | Checking if Shared Gateway Policies Found for tier 0 gateway |
| Status | Failed |
| Expected | Shared Gateway Policies should Found. |
| Got | No Shared Gateway Policies Found |
| Control | 100636 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to have Internet Control Message Protocol (ICMP) mask replies disabled on all external interfaces. |
| Description | The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Mask Reply ICMP messages are commonly used by attackers for network mapping and diagnosis. |
| Severity | High |
| Nist Controls | |
| Check Text |
If the Tier-0 Gateway is deployed in an Active/Active HA mode, this is Not Applicable. From the NSX Manager web interface, go to Security >> Policy Management >> Gateway Firewall >> Gateway Specific Rules, and choose each Tier-0 Gateway in the drop-down. Review each Tier-0 Gateway Firewall rule to verify one exists to drop ICMP mask replies. If a rule does not exist to drop ICMP mask replies, this is a finding. |
| Fix Text | Data Not Available |
| Command | Checking if Tier-0s Found |
|---|---|
| Status | Passed |
| Expected | Tier-0s Found should found |
| Got | Tier-0s Found |
| Command | Checking if any Shared Gateway Policies Found |
| Status | Failed |
| Expected | Shared gateway policies Found |
| Got | No Shared Gateway Policies Found |
| Control | 100637 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to have Internet Control Message Protocol (ICMP) redirects disabled on all external interfaces. |
| Description | The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Redirect ICMP messages are commonly used by attackers for network mapping and diagnosis. |
| Severity | High |
| Nist Controls | |
| Check Text |
If the Tier-0 Gateway is deployed in an Active/Active HA mode, this is Not Applicable. From the NSX Manager web interface, go to Security >> Policy Management >> Gateway Firewall >> Gateway Specific Rules, and choose each Tier-0 Gateway in the drop-down. Review each Tier-0 Gateway Firewalls rules to verify one exists to drop ICMP redirects. If a rule does not exist to drop ICMP redirects, this is a finding. |
| Fix Text | Note If the tier-0 gateway is deployed in an active/active high availability mode and no stateless rules exist, this configuration is not applicable. NSX does not come with a pre-configured service for ICMP mask replies. You may need to create this service. a On the main navigation bar, click Security. b In the left pane, navigate to Policy Management > Gateway Firewall. c Click the All shared rules tab. d Click Add rule (Add a policy first if needed) and, in the Services column, click the Edit button. e On the Set services dialog box, on the Services tab, select the ICMP destination unreachable service, and click Apply. f Click the Settings icon for the newly added rule and, on the Settings dialog box, activate the Logging toggle. g In the Applied to column, click the Edit icon. h In the Applied to dialog box, select the target NSX tier-0 gateway and click Apply. j Repeat the procedure for the ICMP mask replies and ICMP redirectservices |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100638 |
|---|---|
| Title | The NSX Manager must be configured to enforce the limit of three consecutive invalid logon attempts, after which time it must block any login attempt for 15 minutes. |
| Description | By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. |
| Severity | High |
| Nist Controls | |
| Check Text |
From an NSX Manager shell, run the following commands: >> get auth-policy cli lockout-period If lockout-period is not set to |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100639 |
|---|---|
| Title | The NSX Manager must be configured to enforce the limit of three consecutive invalid logon attempts, after which time it must block any login attempt for 15 minutes. |
| Description | By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. |
| Severity | High |
| Nist Controls | |
| Check Text |
Verify NSX Manager is configured to enforce the limit of consecutive invalid login attempts. Log in to NSX Manager command line interface with credentials authorized for administration and run the following command: >> get auth-policy cli max-auth-failures If max-auth-failures is not set to |
| Fix Text | Data Not Available |
| Command | checking the Session timeout for cluster api service |
|---|---|
| Status | Failed |
| Expected | Should be less than 600 |
| Got | 1800 |
| Command | checking the CLI timeout for Node |
| Status | Passed |
| Expected | Should be less than 600 |
| Got | 600 |
| Control | 100640 |
|---|---|
| Title | The NSX Manager must terminate all network connections associated with a session after five minutes of inactivity. |
| Description | Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take immediate control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or deallocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. This does not mean that the device terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
From an NSX Manager shell, run the following command: > get cli-timeout Expected result: |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100641 |
|---|---|
| Title | NSX Manager must disable unused local accounts. |
| Description | Data Not Available |
| Severity | High |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to the System >> Settings >> User Management >> Local Users and view the status column. If the audit, guestuser1, or guestuser2 local accounts are active, this is a finding. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100642 |
|---|---|
| Title | The NSX Manager must only enable TLS 1.2 or greater. |
| Description | A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. Configuration of TLS on the NSX also ensures that passwords are not transmitted in the clear. TLS 1.0 and 1.1 are deprecated protocols with well-published shortcomings and vulnerabilities. TLS 1.2 or greater must be enabled on all interfaces and TLS 1.1 and 1.0 disabled where supported. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
Viewing TLS protocol enablement must be done via the API. Execute the following API call using curl or another REST API client: GET https:// |
| Fix Text | Data Not Available |
| Command | checking the v2_configured for SNMP Services |
|---|---|
| Status | Passed |
| Expected | false |
| Got | false |
| Control | 100643 |
|---|---|
| Title | The NSX Manager must disable SNMP v2. |
| Description | SNMPv3 supports commercial-grade security, including authentication, authorization, access control, and privacy. Previous versions of the protocol contained well-known security weaknesses that were easily exploited. As such, SNMPv1/2 receivers must be disabled. |
| Severity | High |
| Nist Controls | |
| Check Text |
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. |
| Fix Text | Data Not Available |
| Command | checking the dhcp Addresses range for Tier 0 gateway: WLD-Edge-T0 |
|---|---|
| Status | Passed |
| Expected | No Dynamic IP Address Allocation |
| Got | No DHCP Servers Configured for Tier 0 gateway : WLD-Edge-T0 |
| Control | 100644 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to have the Dynamic Host Configuration Protocol (DHCP) service disabled if not in use. |
| Description | A compromised router introduces risk to the entire network infrastructure, as well as data resources that are accessible via the network. The perimeter defense has no oversight or control of attacks by malicious users within the network. Preventing network breaches from within is dependent on implementing a comprehensive defense-in-depth strategy, including securing each device connected to the network. This is accomplished by following and implementing all security guidance applicable for each node type. A fundamental step in securing each router is to enable only the capabilities required for operation. |
| Severity | Medium |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-0 Gateways. For every Tier-0 Gateway expand the Tier-0 Gateway to view the DHCP configuration. If a DHCP profile is configured and not in use, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the BGP neighbor for Tier 0 gateway WLD-Edge-T0 |
|---|---|
| Status | Passed |
| Expected | BGP neighbor should be greater then 0 |
| Got | 2 |
| Command | OSPF is not enabled on T0 for Tier 0 gateway WLD-Edge-T0 |
| Status | Passed |
| Expected | false |
| Got | false |
| Control | 100645 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to have routing protocols disabled if not in use. |
| Description | A compromised router introduces risk to the entire network infrastructure, as well as data resources that are accessible via the network. The perimeter defense has no oversight or control of attacks by malicious users within the network. Preventing network breaches from within is dependent on implementing a comprehensive defense-in-depth strategy, including securing each device connected to the network. This is accomplished by following and implementing all security guidance applicable for each node type. A fundamental step in securing each router is to enable only the capabilities required for operation. |
| Severity | Medium |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-0 Gateways. For every Tier-0 Gateway, expand the Tier-0 Gateway to view if BGP or OSPF is enabled. If BGP and/or OSPF is enabled and not in use, this is a finding. |
| Fix Text | Data Not Available |
| Command | Checking the enablement of Multicast on Tier 0 gateway |
|---|---|
| Status | Not Applicable |
| Expected | Multicast should be enabled on Tier 0 gateway |
| Got | Multicast is not enabled |
| Control | 100646 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to have multicast disabled if not in use. |
| Description | A compromised router introduces risk to the entire network infrastructure, as well as data resources that are accessible via the network. The perimeter defense has no oversight or control of attacks by malicious users within the network. Preventing network breaches from within is dependent on implementing a comprehensive defense-in-depth strategy, including securing each device connected to the network. This is accomplished by following and implementing all security guidance applicable for each node type. A fundamental step in securing each router is to enable only the capabilities required for operation. |
| Severity | Medium |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-0 Gateways. For every Tier-0 Gateway, expand the Tier-0 Gateway, then expand Multicast to view the Multicast configuration. If Multicast is enabled and not in use, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the dhcp Addresses range for Tier 1 gateway : WLD-Edge-T1 |
|---|---|
| Status | Passed |
| Expected | No Dynamic IP Address Allocation |
| Got | No DHCP Servers Configured for Tier 1 gateway : WLD-Edge-T1 |
| Command | checking the dhcp Addresses range for Tier 1 gateway : reg-a-m01-lb01-t1-gw01 |
| Status | Passed |
| Expected | No Dynamic IP Address Allocation |
| Got | No DHCP Servers Configured for Tier 1 gateway : reg-a-m01-lb01-t1-gw01 |
| Control | 100647 |
|---|---|
| Title | The NSX Tier-1 Gateway router must be configured to have the DHCP service disabled if not in use. |
| Description | A compromised router introduces risk to the entire network infrastructure, as well as data resources that are accessible via the network. The perimeter defense has no oversight or control of attacks by malicious users within the network. Preventing network breaches from within is dependent on implementing a comprehensive defense-in-depth strategy, including securing each device connected to the network. This is accomplished by following and implementing all security guidance applicable for each node type. A fundamental step in securing each router is to enable only the capabilities required for operation. |
| Severity | Medium |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-1 Gateways. For every Tier-1 Gateway expand the Tier-1 Gateway to view the DHCP configuration. If a DHCP profile is configured and not in use, this is a finding. |
| Fix Text | Data Not Available |
| Command | Checking the enablement of Multicast/Interface on Tier 1 gateway |
|---|---|
| Status | Not Applicable |
| Expected | Multicast/Interface should be enabled on Tier 1 gateway |
| Got | Multicast/Interface is not enabled |
| Control | 100648 |
|---|---|
| Title | The NSX Tier-1 Gateway router must be configured to have multicast disabled if not in use. |
| Description | A compromised router introduces risk to the entire network infrastructure, as well as data resources that are accessible via the network. The perimeter defense has no oversight or control of attacks by malicious users within the network. Preventing network breaches from within is dependent on implementing a comprehensive defense-in-depth strategy, including securing each device connected to the network. This is accomplished by following and implementing all security guidance applicable for each node type. A fundamental step in securing each router is to enable only the capabilities required for operation. |
| Severity | Medium |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-1 Gateways. For every Tier-1 Gateway, expand the Tier-1 Gateway then expand Multicast to view the Multicast configuration. If Multicast is enabled and not in use, this is a finding. If a Tier-1 Gateway is not linked to a Tier-0 Gateway, this is Not Applicable. |
| Fix Text | Data Not Available |
| Command | Checking the component_version for component : nsx-edge-l-01a |
|---|---|
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | 4.2.0.0.0.24105824 |
| Command | Checking the component_version for component : nsx-edge-l-02a |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | 4.2.0.0.0.24105824 |
| Command | Checking the component_version for component : esx-03a.corp.local |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | 4.2.0.0.0.24105819 |
| Command | Checking the component_version for component : esx-04a.corp.local |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | 4.2.0.0.0.24105819 |
| Command | Checking the component_version for component : esx-01a.corp.local |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | 4.2.0.0.0.24105819 |
| Command | Checking the component_version for component : esx-02a.corp.local |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | 4.2.0.0.0.24105819 |
| Command | Checking the component_version for component : Data Migration Dry Run |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : Prepare Nodes |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : nsx-l-01a |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | 4.2.0.0.0.24105821 |
| Command | Checking the component_version for component : nsx-l-03a |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | 4.2.0.0.0.24105821 |
| Command | Checking the component_version for component : nsx-l-02a |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | 4.2.0.0.0.24105821 |
| Command | Checking the component_version for component : BgpTroubleshootConfigLogicalMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : IpAddressPoolIpTypeLogicalMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : L2UnificationMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : LbSslCipherUpdateMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : TruststorePiCertificateMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : IdsRuleSectionPriorityMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : MPIpBlockSubnetMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : FipsGlobalConfigMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : L4l7RelationshipMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : LrLrpPolicyEdgeRelationshipMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : MacDiscoveryProfileRectifierTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : BridgeEndpointProfileRelationsMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : GatewayFirewallTier0SecurityConfigMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : LicenseGroupInfoMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : SegmentPortIpPoolMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : SegmentTzUpdateMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : QosProfileRectifierTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : CleanupUnusedCertificatesTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : PolicyTransportZoneInternalKeyRectifierTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : EvpnBfdProfileMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : MultiTenancyProjectTransportZoneMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : GreTunnelPortMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : StaticRouteBfdTroubleshootConfigMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : EdgeDefaultFirewallSectionDuplicateCleanupMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : PolicyEdgeClusterMemberMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : ReleaseStaleCertificateMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : TransportNodeStateMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : FirewallConfigurationReassignPriorityMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : IPAddressGroupMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : SegmentRelationshipsMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : BgpNeighborRouteMapRelationshipMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : TunnelRelationshipsMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : NatScopeMigrationTask |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : Unpin API |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : Dashboard Initialization |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : Unpin UI - nsx-l-02a |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : Unpin UI - nsx-l-01a |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : Unpin UI - nsx-l-03a |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Command | Checking the component_version for component : Product Version Update |
| Status | Failed |
| Expected | Component version should be same as that of nsxtVersion provided in input |
| Got | Done |
| Control | 100649 |
|---|---|
| Title | The NSX Manager must be running a release that is currently supported by the vendor. |
| Description | Network devices running an unsupported operating system lack current security fixes required to mitigate the risks associated with recent vulnerabilities. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
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 and supported by the vendor, this is a finding. |
| Fix Text | Data Not Available |
| Command | Data Not Available |
|---|---|
| Status | Failed |
| Expected | Data Not Available |
| Got | No syslog servers are configured on Edge Node : nsx-edge-l-02a |
| Command | Data Not Available |
| Status | Failed |
| Expected | Data Not Available |
| Got | No syslog servers are configured on Edge Node : nsx-edge-l-01a |
| Control | 100650 |
|---|---|
| Title | The NSX Tier-1 Gateway firewall must be configured to send traffic log entries to a central audit server. |
| Description | Without the ability to centrally manage the content captured in the traffic log entries, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. The DOD requires centralized management of all network component audit record content. Network components requiring centralized traffic log management must have the ability to support centralized management. The content captured in traffic log entries must be managed from a central location (necessitating automation). Centralized management of traffic log records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Ensure at least one syslog server is configured on the firewall. If the product inherently has the ability to store log records locally, the local log must also be secured. However, this requirement is not met since it calls for a use of a central audit server. |
| Severity | High |
| Nist Controls | |
| Check Text |
From an NSX Edge Node shell hosting the Tier-1 Gateway, run the following command: > get logging-servers Note: This check must be run from each NSX Edge Node hosting a Tier-1 Gateway, as they are configured individually. or If Node Profiles are used, from the NSX Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles. Click All NSX Nodes and verify the Syslog servers listed. If any configured logging servers are configured with a protocol of udp, this is a finding. If any configured logging servers are not configured with a level of info, this is a finding. If no logging-servers are configured, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the logged value for Tier-1 with rule Name : default_rule for tier 1 gateway : WLD-Edge-T1 |
|---|---|
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Command | checking the logged value for Tier-1 with rule Name : default_rule for tier 1 gateway : reg-a-m01-lb01-t1-gw01 |
| Status | Failed |
| Expected | Should be true |
| Got | false |
| Control | 100651 |
|---|---|
| Title | The NSX Tier-1 Gateway firewall must generate traffic log entries. |
| Description | Without establishing what type of event occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit event content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Associating event types with detected events in the network element logs provides a means of investigating an attack, recognizing resource usage or capacity thresholds, or identifying an improperly configured network element. |
| Severity | High |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Security >> Policy Management >> Gateway Firewall >> Gateway Specific Rules. For each Tier-1 Gateway and for each rule, click the gear icon and verify the Logging setting. If Logging is not Enabled, this is a finding. |
| Fix Text | Data Not Available |
| Command | Checking the enablement of flood-protection-profiles on Tier 1 gateway |
|---|---|
| Status | Failed |
| Expected | flood-protection-profiles should be enabled on Tier 1 gateway |
| Got | flood-protection-profiles is not enabled |
| Control | 100652 |
|---|---|
| Title | The NSX Tier-1 Gateway firewall must manage excess bandwidth to limit the effects of packet flooding types of denial-of-service (DoS) attacks. |
| Description | A firewall experiencing a DoS attack will not be able to handle production traffic load. The high usage and CPU caused by a DoS attack will also have an effect on control keep-alives and timers used for neighbor peering resulting in route flapping and will eventually black hole production traffic. The device must be configured to contain and limit a DoS attack's effect on the device's resource usage. The use of redundant components and load balancing are examples of mitigating flood-type DoS attacks through increased capacity. |
| Severity | Critical |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Security >> Settings >> General Settings >> Firewall >> Flood Protection to view Flood Protection profiles. If there are no Flood Protection profiles of type Gateway, this is a finding. For each gateway flood protection profile, verify the TCP Half Open Connection limit, UDP Active Flow Limit, ICMP Active Flow Limit, and Other Active Connection Limit are set to None, this is a finding. For each gateway flood protection profile, examine the Applied To field to view the Tier-1 Gateways to which it is applied. If a gateway flood protection profile is not applied to all Tier-1 Gateways through one or more policies, this is a finding. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100653 |
|---|---|
| Title | The NSX Manager must display the Standard Mandatory DOD Notice and Consent Banner before granting access. |
| Description | Display of the DOD-approved use notification before granting access to the network device ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. 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. |
| Severity | High |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to System >> Settings >> General Settings >> User Interface. Review the Login Consent Settings. If Login Consent is not On, this is a finding. If Require Explicit User Consent is not Yes, this is a finding. If the Consent Message Description does not contain the Standard Mandatory Notice and Consent Banner verbiage, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the upper_chars |
|---|---|
| Status | Passed |
| Expected | Should be less than or equals to -1 |
| Got | -1 |
| Control | 100654 |
|---|---|
| Title | The NSX Manager must enforce password complexity by requiring that at least one uppercase character be used for local accounts. |
| Description | Use of a complex passwords helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. Multifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using public key infrastructure (PKI) is not available, and for the account of last resort and root account. |
| Severity | High |
| Nist Controls | |
| Check Text |
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. |
| Fix Text | Data Not Available |
| Command | checking the lower_chars |
|---|---|
| Status | Passed |
| Expected | Should be less than or equals to -1 |
| Got | -1 |
| Control | 100655 |
|---|---|
| Title | The NSX Manager must enforce password complexity by requiring that at least one lowercase character be used for local accounts. |
| Description | Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Multifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account. |
| Severity | High |
| Nist Controls | |
| Check Text |
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. |
| Fix Text | Data Not Available |
| Command | checking the digits |
|---|---|
| Status | Passed |
| Expected | Should be less than or equals to -1 |
| Got | -1 |
| Control | 100656 |
|---|---|
| Title | The NSX Manager must enforce password complexity by requiring that at least one numeric character be used for local accounts. |
| Description | Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Multifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account. |
| Severity | High |
| Nist Controls | |
| Check Text |
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. |
| Fix Text | Data Not Available |
| Command | checking the special_chars |
|---|---|
| Status | Passed |
| Expected | Should be less than or equals to -1 |
| Got | -1 |
| Control | 100657 |
|---|---|
| Title | The NSX Manager must enforce password complexity by requiring that at least one special character be used for local accounts. |
| Description | Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Multifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account. |
| Severity | High |
| Nist Controls | |
| Check Text |
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. |
| Fix Text | Data Not Available |
| Command | checking the max_repeats |
|---|---|
| Status | Failed |
| Expected | Should be greater than or equals to 8 |
| Got | 0 |
| Control | 100658 |
|---|---|
| Title | The NSX Manager must require that when a password is changed, the characters are changed in at least eight of the positions within the password. |
| Description | If the application allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different. Multifactor authentication (MFA) is required for all administrative and user accounts on network devices, except for an account of last resort and (where applicable) a root account. Passwords should only be used when MFA using PKI is not available, and for the account of last resort and root account. |
| Severity | High |
| Nist Controls | |
| Check Text |
From an NSX Manager shell, run the following command: > get password-complexity If the number of consecutive characters allowed for reuse is not 8 or more, this is a finding. Note: If this has not previously been configured it will not be shown in the output. |
| Fix Text | Data Not Available |
| Command | checking the ra config -> hop limit for Tier-0 gateway : WLD-Edge-T0 |
|---|---|
| Status | Passed |
| Expected | should be greater than or equal to 32 |
| Got | 64 |
| Control | 100659 |
|---|---|
| Title | The NSX Tier-0 Gateway router must be configured to advertise a hop limit of at least 32 in Router Advertisement messages for IPv6 stateless auto-configuration deployments. |
| Description | The Neighbor Discovery (ND) protocol allows a hop limit value to be advertised by routers in a Router Advertisement message being used by hosts instead of the standardized default value. If a very small value was configured and advertised to hosts on the LAN segment, communications would fail due to the hop limit reaching zero before the packets sent by a host reached its destination. |
| Severity | Medium |
| Nist Controls | |
| Check Text |
If IPv6 forwarding is not enabled, this is Not Applicable. From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-0 Gateways. For every Tier-0 Gateway, expand Tier-0 Gateway >>Additional Settings. Click on the ND profile name to view the hop limit. If the hop limit is not configured to at least 32, this is a finding. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100660 |
|---|---|
| Title | The NSX Tier-1 Gateway firewall must be configured to inspect traffic at the application layer. |
| Description | Application inspection enables the firewall to control traffic based on different parameters that exist within the packets such as enforcing application-specific message and field length. Inspection provides improved protection against application-based attacks by restricting the types of commands allowed for the applications. Application inspection all enforces conformance against published RFCs. Some applications embed an IP address in the packet that needs to match the source address that is normally translated when it goes through the firewall. Enabling application inspection for a service that embeds IP addresses, the firewall translates embedded addresses and updates any checksum or other fields that are affected by the translation. Enabling application inspection for a service that uses dynamically assigned ports, the firewall monitors sessions to identify the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session. |
| Severity | High |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Security >> Policy Management >> Gateway Firewall >> Gateway Specific Rules. For each Tier-1 Gateway, review rules that do not have a Context Profile assigned. For example, if a rule exists to allow SSH by service or custom port then it should have the associated SSH Context Profile applied. If any rules with services defined have an associated suitable Context Profile but do not have one applied, this is a finding. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100661 |
|---|---|
| Title | The NSX Tier-1 Gateway router must be configured to advertise a hop limit of at least 32 in Router Advertisement messages for IPv6 stateless auto-configuration deployments. |
| Description | The Neighbor Discovery protocol allows a hop limit value to be advertised by routers in a Router Advertisement message being used by hosts instead of the standardized default value. If a very small value was configured and advertised to hosts on the LAN segment, communications would fail due to the hop limit reaching zero before the packets sent by a host reached its destination. |
| Severity | Medium |
| Nist Controls | |
| Check Text |
If IPv6 forwarding is not enabled, this is Not Applicable. From the NSX Manager web interface, go to Networking >> Connectivity >> Tier-1 Gateways. For every Tier-1 Gateway, expand Tier-1 Gateway >>Additional Settings. Click on the ND profile name to view the hop limit. If the hop limit is not configured to at least 32, this is a finding. |
| Fix Text | Data Not Available |
| Command | This is a manual or policy based check and must be manually reviewed. |
|---|---|
| Status | Manual |
| Expected | Data Not Available |
| Got | Data Not Available |
| Control | 100662 |
|---|---|
| Title | The NSX Distributed Firewall must be configured to inspect traffic at the application layer. |
| Description | Application inspection enables the firewall to control traffic based on different parameters that exist within the packets such as enforcing application-specific message and field length. Inspection provides improved protection against application-based attacks by restricting the types of commands allowed for the applications. Application inspection all enforces conformance against published RFCs. Some applications embed an IP address in the packet that needs to match the source address that is normally translated when it goes through the firewall. By enabling application inspection for a service that embeds IP addresses, the firewall translates embedded addresses and updates any checksum or other fields that are affected by the translation. By enabling application inspection for a service that uses dynamically assigned ports, the firewall monitors sessions to identify the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session. |
| Severity | High |
| Nist Controls | |
| Check Text |
From the NSX Manager web interface, go to Security >> Distributed Firewall >> All Rules. Review rules that do not have a Context Profile assigned. For example, if a rule exists to allow SSH by service or custom port then it should have the associated SSH Context Profile applied. If any rules with services defined have an associated suitable Context Profile but do not have one applied, this is a finding. |
| Fix Text | Data Not Available |
| Command | checking the arpSnoopingEnabled for ip_v4_discovery_options for : default-vlan-ip-discovery-profile |
|---|---|
| Status | Passed |
| Expected | Should be true |
| Got | true |
| Command | checking the arpBindingLimit for ip_v4_discovery_options for : default-vlan-ip-discovery-profile |
| Status | Passed |
| Expected | 1 |
| Got | 1 |
| Command | checking the dhcpSnoopingEnabled for ip_v4_discovery_options for : default-vlan-ip-discovery-profile |
| Status | Failed |
| Expected | Should be False |
| Got | true |
| Command | checking the vmtoolsEnabled for ip_v4_discovery_options for : default-vlan-ip-discovery-profile |
| Status | Failed |
| Expected | Should be False |
| Got | true |
| Command | checking the dhcpSnoopingV6Enabled for ip_v6_discovery_options for : default-vlan-ip-discovery-profile |
| Status | Passed |
| Expected | Should be False |
| Got | false |
| Command | checking the vmtoolsV6Enabled for ip_v6_discovery_options for : default-vlan-ip-discovery-profile |
| Status | Passed |
| Expected | Should be False |
| Got | false |
| Command | checking the arpSnoopingEnabled for ip_v4_discovery_options for : default-vlan-ip-discovery-profile |
| Status | Passed |
| Expected | Should be true |
| Got | true |
| Command | checking the arpBindingLimit for ip_v4_discovery_options for : default-vlan-ip-discovery-profile |
| Status | Passed |
| Expected | 1 |
| Got | 1 |
| Command | checking the dhcpSnoopingEnabled for ip_v4_discovery_options for : default-vlan-ip-discovery-profile |
| Status | Failed |
| Expected | Should be False |
| Got | true |
| Command | checking the vmtoolsEnabled for ip_v4_discovery_options for : default-vlan-ip-discovery-profile |
| Status | Failed |
| Expected | Should be False |
| Got | true |
| Command | checking the dhcpSnoopingV6Enabled for ip_v6_discovery_options for : default-vlan-ip-discovery-profile |
| Status | Passed |
| Expected | Should be False |
| Got | false |
| Command | checking the vmtoolsV6Enabled for ip_v6_discovery_options for : default-vlan-ip-discovery-profile |
| Status | Passed |
| Expected | Should be False |
| Got | false |
| Command | checking the arpSnoopingEnabled for ip_v4_discovery_options for : default-ip-discovery-profile |
| Status | Passed |
| Expected | Should be true |
| Got | true |
| Command | checking the arpBindingLimit for ip_v4_discovery_options for : default-ip-discovery-profile |
| Status | Passed |
| Expected | 1 |
| Got | 1 |
| Command | checking the dhcpSnoopingEnabled for ip_v4_discovery_options for : default-ip-discovery-profile |
| Status | Failed |
| Expected | Should be False |
| Got | true |
| Command | checking the vmtoolsEnabled for ip_v4_discovery_options for : default-ip-discovery-profile |
| Status | Failed |
| Expected | Should be False |
| Got | true |
| Command | checking the dhcpSnoopingV6Enabled for ip_v6_discovery_options for : default-ip-discovery-profile |
| Status | Passed |
| Expected | Should be False |
| Got | false |
| Command | checking the vmtoolsV6Enabled for ip_v6_discovery_options for : default-ip-discovery-profile |
| Status | Passed |
| Expected | Should be False |
| Got | false |
| Command | checking the arpSnoopingEnabled for ip_v4_discovery_options for : default-ip-discovery-profile |
| Status | Passed |
| Expected | Should be true |
| Got | true |
| Command | checking the arpBindingLimit for ip_v4_discovery_options for : default-ip-discovery-profile |
| Status | Passed |
| Expected | 1 |
| Got | 1 |
| Command | checking the dhcpSnoopingEnabled for ip_v4_discovery_options for : default-ip-discovery-profile |
| Status | Failed |
| Expected | Should be False |
| Got | true |
| Command | checking the vmtoolsEnabled for ip_v4_discovery_options for : default-ip-discovery-profile |
| Status | Failed |
| Expected | Should be False |
| Got | true |
| Command | checking the dhcpSnoopingV6Enabled for ip_v6_discovery_options for : default-ip-discovery-profile |
| Status | Passed |
| Expected | Should be False |
| Got | false |
| Command | checking the vmtoolsV6Enabled for ip_v6_discovery_options for : default-ip-discovery-profile |
| Status | Passed |
| Expected | Should be False |
| Got | false |
| Control | 100663 |
|---|---|
| Title | The NSX Distributed Firewall must configure an IP Discovery profile to disable trust on every use methods. |
| Description |
A compromised host in an enclave can be used by a malicious platform to launch cyberattacks on third parties. This is a common practice in botnets, which are a collection of compromised computers using malware to attack other computers or networks. Distributed denial-of-service (DDoS) attacks frequently leverage IP source address spoofing to send packets to multiple hosts that in turn will then send return traffic to the hosts with the IP addresses that were forged. This can generate significant amounts of traffic. Therefore, protection measures to counteract IP source address spoofing must be taken. IP Discovery in NSX uses DHCP and DHCPv6 snooping, Address Resolution Protocol (ARP) snooping, Neighbor Discovery (ND) snooping, and VM Tools to learn MAC and IP addresses. The discovered MAC and IP addresses are used to achieve ARP/ND suppression, which minimizes traffic between VMs connected to the same logical switch. The addresses are also used by the SpoofGuard and distributed firewall (DFW) components. DFW uses the address bindings to determine the IP address of objects in firewall rules. By default, the discovery methods ARP snooping and ND snooping operate in a mode called trust on first use (TOFU). In TOFU mode, when an address is discovered and added to the realized bindings list, that binding remains in the realized list forever. TOFU applies to the first n unique |
| Severity | Critical |
| Nist Controls | |
| Check Text |
Identity IP Discovery profiles in use by doing the following: From the NSX Manager web interface, go to Networking >> Connectivity >> Segments >> NSX. For each segment, expand view Segment Profiles >> IP Discovery to note the profiles in use. Review IP Discovery profile configuration by doing the following: From the NSX Manager web interface, go to Networking >> Connectivity >> Segments >> Profiles >> Segment Profiles. Review the IP Discovery profiles previously identified as assigned to segments to ensure the following configuration: Duplicate IP Detection: Enabled ARP Snooping: Enabled ARP Binding Limit: 1 DHCP Snooping: Disabled DHCP Snooping - IPv6: Disabled VMware Tools: Disabled VMware Tools - IPv6: Disabled Trust on First Use: Enabled If a Segment is not configured with an IP Discovery profile that is configured with the settings above, this is a finding. |
| Fix Text | Data Not Available |