Cyber Trackr - Free Compliance Library
Cyber Trackr
The Free Compliance Library

VMware NSX 4.x Distributed Firewall Security Technical Implementation Guide

  • Version/Release: V1R1
  • Published: 2024-07-26
  • Released: 2024-08-07
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
a
The NSX Distributed Firewall must generate traffic log entries.
AU-3 - Info - CCI-000130 - V-263175 - SV-263175r977292_rule
RMF Control
AU-3
Severity
Info
CCI
CCI-000130
Version
NDFW-4X-000004
Vuln IDs
  • V-263175
Rule IDs
  • SV-263175r977292_rule
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.
Checks: C-67075r977290_chk

From the NSX Manager web interface, navigate 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: F-66983r977291_fix

From the NSX Manager web interface, navigate to Security >> Policy Management >> Distributed Firewall >> Category Specific Rules. For each rule that has logging disabled, click the gear icon, toggle the logging option to "Enable" and click "Apply". or For each Policy or Section, click the menu icon on the left and select "Enable Logging for All Rules". After all changes are made, click "Publish".

a
The NSX Distributed Firewall must generate traffic log entries containing information to establish the source of the events, such as the source IP address at a minimum.
AU-3 - Info - CCI-000133 - V-263176 - SV-263176r977295_rule
RMF Control
AU-3
Severity
Info
CCI
CCI-000133
Version
NDFW-4X-000007
Vuln IDs
  • V-263176
Rule IDs
  • SV-263176r977295_rule
Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. To compile an accurate risk assessment and provide forensic analysis, security personnel need to know the source of the event. In addition to logging where events occur within the network, the traffic log events must also identify sources of events, such as IP addresses, processes, and node or device names.
Checks: C-67076r977293_chk

From the NSX Manager web interface, navigate 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: F-66984r977294_fix

From the NSX Manager web interface, navigate to Security >> Policy Management >> Distributed Firewall >> Category Specific Rules. For each rule that has logging disabled, click the gear icon, toggle the logging option to "Enable" and click "Apply". or For each Policy or Section, click the menu icon on the left and select "Enable Logging for All Rules". After all changes are made, click "Publish".

a
The NSX Distributed Firewall must generate traffic log entries containing information to establish the outcome of the events, such as, at a minimum, the success or failure of the application of the NSX Distributed Firewall rule.
AU-3 - Info - CCI-000134 - V-263177 - SV-263177r977298_rule
RMF Control
AU-3
Severity
Info
CCI
CCI-000134
Version
NDFW-4X-000008
Vuln IDs
  • V-263177
Rule IDs
  • SV-263177r977298_rule
Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the network. Event outcomes can include indicators of event success or failure and event-specific results. They also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.
Checks: C-67077r977296_chk

From the NSX Manager web interface, navigate 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: F-66985r977297_fix

From the NSX Manager web interface, navigate to Security >> Policy Management >> Distributed Firewall >> Category Specific Rules. For each rule that has logging disabled, click the gear icon, toggle the logging option to "Enable" and click "Apply". or For each Policy or Section, click the menu icon on the left and select "Enable Logging for All Rules". After all changes are made, click "Publish".

b
The NSX Distributed Firewall must limit the effects of packet flooding types of denial-of-service (DoS) attacks.
SC-5 - Medium - CCI-001095 - V-263178 - SV-263178r977301_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-001095
Version
NDFW-4X-000015
Vuln IDs
  • V-263178
Rule IDs
  • SV-263178r977301_rule
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.
Checks: C-67078r977299_chk

From the NSX Manager web interface, navigate 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 "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: F-66986r977300_fix

To create a new Flood Protection profile: From the NSX Manager web interface, navigate to Security >> Settings >> General Settings >> Firewall >> Flood Protection >> Add Profile >> Add Firewall Profile. Enter a name and specify appropriate values for the following: TCP Half Open Connection limit, UDP Active Flow Limit, ICMP Active Flow Limit, and Other Active Connection Limit. Enable SYN Cache and RST Spoofing, configure the "Applied To" field with the appropriate security groups, and then click "Save".

b
The NSX Distributed Firewall must deny network communications traffic by default and allow network communications traffic by exception.
SC-7 - Medium - CCI-001109 - V-263179 - SV-263179r977304_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-001109
Version
NDFW-4X-000016
Vuln IDs
  • V-263179
Rule IDs
  • SV-263179r977304_rule
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).
Checks: C-67079r977302_chk

From the NSX Manager web interface, navigate 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: F-66987r977303_fix

From the NSX Manager web interface, navigate to Security >> Policy Management >> Distributed Firewall >> Category Specific Rules >> APPLICATION >> Default Layer3 Section >> Default Layer3 Rule and change action to "Drop" or "Reject". After all changes are made, click "Publish". Note: Before enabling, ensure the necessary rules to whitelist approved traffic are created and published, or this change may result in loss of communication for workloads.

b
The NSX Distributed Firewall must be configured to inspect traffic at the application layer.
CM-6 - Medium - CCI-000366 - V-263180 - SV-263180r977307_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
NDFW-4X-000027
Vuln IDs
  • V-263180
Rule IDs
  • SV-263180r977307_rule
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.
Checks: C-67080r977305_chk

From the NSX Manager web interface, navigate 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: F-66988r977306_fix

From the NSX Manager web interface, navigate to Security >> Policy Management >> Distributed Firewall >> Category Specific Rules. For each rule that should have a Context Profile enabled, click the pencil icon in the Context Profile column. Select an existing Context Profile or create a custom one then click "Apply". After all changes are made, click "Publish". Note: This control does not apply to Ethernet rules. Not all App IDs will be suitable for use in all cases and should be evaluated in each environment before use. A list of App IDs for application layer rules is available here: https://docs.vmware.com/en/NSX-Application-IDs/index.html.

b
The NSX Distributed Firewall must configure SpoofGuard to restrict it from accepting outbound packets that contain an illegitimate address in the source address.
CM-6 - Medium - CCI-000366 - V-263181 - SV-263181r977310_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
NDFW-4X-000029
Vuln IDs
  • V-263181
Rule IDs
  • SV-263181r977310_rule
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.
Checks: C-67081r977308_chk

Identity SpoofGuard profiles in use by doing the following: From the NSX Manager web interface, navigate to Networking >> Connectivity >> Segments >> NSX. For each segment, expand view Segment Profiles >> SpoofGuard to note the profiles in use. Review SpoofGuard profile configuration by doing the following: From the NSX Manager web interface, navigate to Networking >> Connectivity >> Segments >> Profiles >> Segment Profiles. Review the SpoofGuard profiles previously identified as assigned to segments to ensure the following configuration: Port Bindings: Yes If a segment is not configured with a SpoofGuard profile that has port bindings enabled, this is a finding.

Fix: F-66989r977309_fix

To create a segment profile with SpoofGuard enabled, do the following: From the NSX Manager web interface, navigate to Networking >> Connectivity >> Segments >> Profiles >> Segment Profiles >> Add Segment Profile >> SpoofGuard. Enter a profile name and enable port bindings, then click "Save". To update a segments SpoofGuard profile, do the following: From the NSX Manager web interface, navigate to the Networking >> Connectivity >> Segments >> NSX, and click "Edit" from the drop-down menu next to the target segment. Expand "Segment Profiles" then choose the new SpoofGuard profile from the drop-down list, and then click "Save".

c
The NSX Distributed Firewall must configure an IP Discovery profile to disable trust on every use methods.
CM-6 - High - CCI-000366 - V-263182 - SV-263182r977313_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
NDFW-4X-000034
Vuln IDs
  • V-263182
Rule IDs
  • SV-263182r977313_rule
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 bindings discovered using ARP/ND snooping, where "n" is the configurable binding limit. Users can disable TOFU for ARP/ND snooping. The methods will then operate in trust on every use (TOEU) mode. In TOEU mode, when an address is discovered, it is added to the realized bindings list and when it is deleted or expired, it is removed from the realized bindings list. DHCP snooping and VM Tools always operate in TOEU mode.
Checks: C-67082r977311_chk

Identify IP Discovery profiles in use by doing the following: From the NSX Manager web interface, navigate 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, navigate 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: F-66990r977312_fix

To create a segment profile for IP Discovery, do the following: From the NSX Manager web interface, navigate to Networking >> Connectivity >> Segments >> NSX >> Profiles >> Segment Profiles >> Add Segment Profile >> IP Discovery. Enter a profile name then configure the below settings: 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 Click "Save". Note: ND Snooping may be enabled if IPv6 is in use. To update a segments IP Discovery profile, do the following: From the NSX Manager web interface, navigate to the Networking >> Connectivity >> Segments >> NSX, and click "Edit" from the drop-down menu next to the target segment. Expand "Segment Profiles" then choose the new IP Discovery profile from the drop-down list, and then click "Save".