VMware NSX-T Distributed Firewall Security Technical Implementation Guide

  • Version/Release: V1R3
  • Published: 2023-06-23
  • 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.
b
The NSX-T Distributed Firewall must generate traffic log entries containing information to establish the details of the event.
AU-3 - Medium - CCI-000130 - V-251727 - SV-251727r810035_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
TDFW-3X-000005
Vuln IDs
  • V-251727
Rule IDs
  • SV-251727r810035_rule
Without sufficient information to analyze the event, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Audit event content that must be included 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. The NSX-T Distributed Firewall must also generate traffic log records when traffic is denied, restricted, or discarded as well as when attempts are made to send packets between security zones that are not authorized to communicate. Satisfies: SRG-NET-000074-FW-000009, SRG-NET-000075-FW-000010, SRG-NET-000076-FW-000011, SRG-NET-000077-FW-000012, SRG-NET-000078-FW-000013, SRG-NET-000492-FW-000006, SRG-NET-000493-FW-000007
Checks: C-55164r810033_chk

From the NSX-T Manager web interface, go to Security >> 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-55118r810034_fix

From the NSX-T Manager web interface, go to Security >> 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-T Distributed Firewall must block outbound traffic containing denial-of-service (DoS) attacks to protect against the use of internal information systems to launch any DoS attacks against other networks or endpoints.
SC-5 - Medium - CCI-001094 - V-251728 - SV-251728r919499_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-001094
Version
TDFW-3X-000019
Vuln IDs
  • V-251728
Rule IDs
  • SV-251728r919499_rule
DoS attacks can take multiple forms but have the common objective of overloading or blocking a network or host to deny or seriously degrade performance. If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Installation of a firewall at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type. The firewall must include protection against DoS attacks that originate from inside the enclave that can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave. These attacks can be simple "floods" of traffic to saturate circuits or devices, malware that consumes CPU and memory on a device or causes it to crash, or a configuration issue that disables or impairs the proper function of a device. For example, an accidental or deliberate misconfiguration of a routing table can misdirect traffic for multiple networks. Satisfies: SRG-NET-000192-FW-000029, SRG-NET-000193-FW-000030
Checks: C-55165r919498_chk

From the NSX-T Manager web interface, go to Security >> 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 are 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-55119r919499_fix

To create a new Flood Protection profile, do the following: From the NSX-T Manager web interface, go to Security >> 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 click "Save".

a
The NSX-T Distributed Firewall must deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
SC-7 - Low - CCI-001109 - V-251729 - SV-251729r810041_rule
RMF Control
SC-7
Severity
Low
CCI
CCI-001109
Version
TDFW-3X-000021
Vuln IDs
  • V-251729
Rule IDs
  • SV-251729r810041_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). Satisfies: SRG-NET-000202-FW-000039, SRG-NET-000236-FW-000027, SRG-NET-000235-FW-000133
Checks: C-55166r810039_chk

From the NSX-T Manager web interface, go to Security >> 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-55120r810040_fix

From the NSX-T Manager web interface, go to Security >> 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-T Distributed Firewall must be configured to send traffic log entries to a central audit server for management and configuration of the traffic log entries.
AU-3 - Medium - CCI-001844 - V-251730 - SV-251730r863248_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-001844
Version
TDFW-3X-000026
Vuln IDs
  • V-251730
Rule IDs
  • SV-251730r863248_rule
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.
Checks: C-55167r810042_chk

Verify NSX-T Distributed Firewall is configured to send traffic log entries to a central audit server for management and configuration of the traffic log entries. Log in to vSphere vCenter https interface with credentials authorized for administration. Navigate to Browse to the host in the vSphere Client inventory >> Configure >> System >> Advanced System Settings >> Edit >> Syslog.global.LogHost. Verify a STIG compliant events server is configured. If Syslog.global.LogHost is not configured with a STIG compliant events server, this is a finding.

Fix: F-55121r810043_fix

Change configuration of NSX-T Distributed Firewall to send traffic log entries to a central audit server for management and configuration of the traffic log entries. Log in to vSphere vCenter https interface with credentials authorized for administration, navigate to Browse to the host in the vSphere Client inventory >> Configure >> System >> Advanced System Settings >> Edit >> Syslog.global.LogHost >> value >> ssl://hostName1:1514 >> OK. Note: Configure the syslog or SNMP server to send an alert if the events server is unable to receive events from the NSX-T and also if denial-of-service (DoS) incidents are detected. This is true if the events server is STIG compliant.

b
The NSX-T Distributed Firewall must employ filters that prevent or limit the effects of all types of commonly known denial-of-service (DoS) attacks, including flooding, packet sweeps, and unauthorized port scanning.
SC-5 - Medium - CCI-002385 - V-251731 - SV-251731r856683_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
TDFW-3X-000028
Vuln IDs
  • V-251731
Rule IDs
  • SV-251731r856683_rule
Not configuring a key boundary security protection device, such as the firewall, against commonly known attacks is an immediate threat to the protected enclave because they are easily implemented by those with little skill. Directions for the attack are obtainable on the internet and in hacker groups. Without filtering enabled for these attacks, the firewall will allow these attacks beyond the protected boundary. Configure the perimeter and internal boundary firewall to guard against the three general methods of well-known DoS attacks: Flooding attacks, protocol sweeping attacks, and unauthorized port scanning. Flood attacks occur when the host receives too much traffic to buffer and slows down or crashes. Popular flood attacks include ICMP flood and SYN flood. A TCP flood attack of SYN packets initiating connection requests can overwhelm the device until it can no longer process legitimate connection requests, resulting in denial of service. An ICMP flood can overload the device with so many echo requests (ping requests) that it expends all its resources responding and can no longer process valid network traffic, also resulting in denial of service. An attacker might use session table floods and SYN-ACK-ACK proxy floods to fill up the session table of a host. In an IP address sweep attack, an attacker sends ICMP echo requests (pings) to multiple destination addresses. If a target host replies, the reply reveals the target's IP address to the attacker. In a TCP sweep attack, an attacker sends TCP SYN packets to the target device as part of the TCP handshake. If the device responds to those packets, the attacker gets an indication that a port in the target device is open, which makes the port vulnerable to attack. In a UDP sweep attack, an attacker sends UDP packets to the target device. If the device responds to those packets, the attacker gets an indication that a port in the target device is open, which makes the port vulnerable to attack. In a port scanning attack, an unauthorized application is used to scan the host devices for available services and open ports for subsequent use in an attack. This type of scanning can be used as a DoS attack when the probing packets are sent excessively.
Checks: C-55168r810045_chk

From the NSX-T Manager web interface, go to Security >> Security Profiles >> 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: F-55122r810046_fix

To create a new Flood Protection profile do the following: From the NSX-T Manager web interface, go to Security >> Security Profiles >> 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 then configure the "Applied To" field with the appropriate security groups, and then click "Save".

b
The NSX-T Distributed Firewall must configure SpoofGuard to block outbound IP packets that contain illegitimate packet attributes.
SI-4 - Medium - CCI-002664 - V-251732 - SV-251732r856684_rule
RMF Control
SI-4
Severity
Medium
CCI
CCI-002664
Version
TDFW-3X-000036
Vuln IDs
  • V-251732
Rule IDs
  • SV-251732r856684_rule
SpoofGuard helps prevent a form of malicious attack called "web spoofing" or "phishing." A SpoofGuard policy blocks traffic determined to be spoofed. SpoofGuard is a tool that is designed to prevent virtual machines in your environment 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 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 in your environment, but for the distributed firewall it will guarantee that rules will not be inadvertently (or deliberately) bypassed. For DFW rules created utilizing 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-55169r810048_chk

From the NSX-T Manager web interface, go to Networking >> Segments, and for each Segment, view Segment Profiles >> SpoofGuard. If a Segment is not configured with a SpoofGuard profile that has Port Binding enabled, this is a finding.

Fix: F-55123r810049_fix

To create a segment profile with SpoofGuard enabled, do the following: From the NSX-T Manager web interface, go to Networking >> Segments >> 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-T Manager web interface, go to the Networking >> Segments, 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".

b
The NSX-T Distributed Firewall must verify time-based firewall rules.
AC-4 - Medium - CCI-001414 - V-251733 - SV-251733r810053_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001414
Version
TDFW-3X-000042
Vuln IDs
  • V-251733
Rule IDs
  • SV-251733r810053_rule
With time windows, security administrators can restrict traffic from a source or to a destination, for a specific time period. Time windows apply to a firewall policy section, and all the rules in it. Each firewall policy section can have one time window. The same time window can be applied to more than one policy section. If you want the same rule applied on different days or different times for different sites, you must create more than one policy section. Time-based rules are available for distributed and gateway firewalls on both ESXi and KVM hosts. If time windows are not verified and periodically checked, a malicious actor could create time windows to effectively disable rules while not being obvious to firewall administrators.
Checks: C-55170r810051_chk

From the NSX-T Manager web interface, go to Security >> Distributed Firewall >> Category Specific Rules. For each category, verify each Policy has no time windows configured or any existing time windows are expected. This can be viewed by clicking on the clock icon in each Policy section. If there are unexpected or misconfigured time windows, this is a finding.

Fix: F-55124r810052_fix

From the NSX-T Manager web interface, go to Security >> Distributed Firewall >> Category Specific Rules. Navigate to the offending Category and Policy section, click on the clock icon, then delete or modify the time window for that Policy. Click "Apply". After all changes are made click "Publish".