VMware NSX-T Tier-0 Gateway Firewall Security Technical Implementation Guide

  • Version/Release: V1R3
  • Published: 2023-06-22
  • Released: 2023-07-26
  • 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-T Tier-0 Gateway Firewall must generate traffic log entries containing information to establish the details of the event.
AU-3 - Low - CCI-000130 - V-251737 - SV-251737r810078_rule
RMF Control
AU-3
Severity
Low
CCI
CCI-000130
Version
T0FW-3X-000006
Vuln IDs
  • V-251737
Rule IDs
  • SV-251737r810078_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 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-000399-FW-000008, SRG-NET-000492-FW-000006, SRG-NET-000493-FW-000007
Checks: C-55174r810076_chk

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-T Manager web interface, go to Security >> 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: F-55128r810077_fix

From the NSX-T Manager web interface, go to Security >> Gateway Firewall >> Gateway Specific Rules. For each Tier-0 Gateway and for each rule with logging disabled, click the gear icon, enable Logging, and then click "Apply". After all changes are made, click "Publish".

b
The NSX-T Tier-0 Gateway Firewall must be configured to use the TLS or LI-TLS protocols to configure and secure communications with the central audit server.
AU-5 - Medium - CCI-000140 - V-251738 - SV-251738r919225_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000140
Version
T0FW-3X-000011
Vuln IDs
  • V-251738
Rule IDs
  • SV-251738r919225_rule
It is critical that when the network element is at risk of failing to process traffic logs as required, it takes action to mitigate the failure. Collected log data be secured and access restricted to authorized personnel. Methods of protection may include encryption or logical separation. In accordance with DOD policy, the traffic log must be sent to a central audit server. Ensure at least primary and secondary syslog servers are 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. This does not apply to traffic logs generated on behalf of the device itself (management). Some devices store traffic logs separately from the system logs. Satisfies: SRG-NET-000089-FW-000019, SRG-NET-000098-FW-000021, SRG-NET-000333-FW-000014
Checks: C-55175r919224_chk

From an NSX-T Edge Node shell hosting the Tier-0 Gateway, run the following command(s): > get logging-servers If any configured logging-servers are not configured with protocol of "li-tls" or "tls" and level of "info", this is a finding. If no logging-servers are configured, this is a finding. Note: This check must be run from each NSX-T Edge Node hosting the Tier-0 Gateway, as they are configured individually.

Fix: F-55129r810080_fix

(Optional) From an NSX-T Edge Gateway shell, run the following command(s) to clear any existing incorrect logging-servers: > clear logging-servers From an NSX-T Edge Node shell, run the following command(s) to configure a primary and backup tls syslog server: > set logging-server <server-ip or server-name> proto tls level info serverca ca.pem clientca ca.pem certificate cert.pem key key.pem From an NSX-T Edge Node shell, run the following command(s) to configure a li-tls syslog server: > set logging-server <server-ip or server-name> proto li-tls level info serverca root-ca.crt Note: If using the protocols TLS or LI-TLS to configure a secure connection to a log server, the server and client certificates must be stored in /var/vmware/nsx/file-store/ on each NSX-T Edge Gateway appliance. 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 DoS incidents are detected. This is true if the events server is STIG compliant.

b
The NSX-T Tier-0 Gateway 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-251739 - SV-251739r919228_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-001094
Version
T0FW-3X-000019
Vuln IDs
  • V-251739
Rule IDs
  • SV-251739r919228_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-55176r919226_chk

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-T Manager web interface, go to Security &gt;&gt; General Settings &gt;&gt; Firewall &gt;&gt; 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". If they are not, 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: F-55130r919227_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 Edge Gateway 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. Configure the "Applied To" field to contain Tier-0 Gateways, and then click "Save".

b
The NSX-T Tier-1 Gateway Firewall must deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
SC-7 - Medium - CCI-001097 - V-251740 - SV-251740r810087_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-001097
Version
T0FW-3X-000021
Vuln IDs
  • V-251740
Rule IDs
  • SV-251740r810087_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. This configuration, which is in the Manager function of the NSX-T implementation, helps prevent the firewall instance from failing to a state that may cause unauthorized access to make changes to the firewall filtering functions. 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 configured 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-000235-FW-000133, SRG-NET-000236-FW-000027, SRG-NET-000205-FW-000040
Checks: C-55177r810085_chk

From the NSX-T Manager web interface, go to Security &gt;&gt; Gateway Firewall &gt;&gt; Gateway Specific Rules. Choose each Tier-1 Gateway in drop-down, then select Policy_Default_Infra Section &gt;&gt; Action. If the default_rule is set to "Allow", this is a finding.

Fix: F-55131r810086_fix

From the NSX-T Manager web interface, go to Security >> Gateway Firewall >> Gateway Specific Rules. Choose each Tier-1 Gateway in drop-down, then select Policy_Default_Infra Section >> Action. Change the Action to "Drop" or "Reject", and then click "Publish".

b
The NSX-T Tier-0 Gateway 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-251741 - SV-251741r856690_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
T0FW-3X-000028
Vuln IDs
  • V-251741
Rule IDs
  • SV-251741r856690_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 it 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-55178r810088_chk

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-T Manager web interface, go to Security &gt;&gt; Security Profiles &gt;&gt; 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 "not set" or SYN Cache and RST Spoofing is not "Enabled" on a profile, 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 Tier-0 Gateways through one or more policies, this is a finding.

Fix: F-55132r810089_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 to contain Tier-0 Gateways and click "Save".

b
The NSX-T Tier-0 Gateway Firewall must apply ingress filters to traffic that is inbound to the network through any active external interface.
SC-7 - Medium - CCI-002403 - V-251742 - SV-251742r856691_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-002403
Version
T0FW-3X-000030
Vuln IDs
  • V-251742
Rule IDs
  • SV-251742r856691_rule
Unrestricted traffic to the trusted networks may contain malicious traffic that poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources. Firewall filters control the flow of network traffic, ensure the flow of traffic is only allowed from authorized sources to authorized destinations. Networks with different levels of trust (e.g., the internet) must be kept separated.
Checks: C-55179r810091_chk

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-T Manager web interface, go to Security &gt;&gt; Gateway Firewall &gt;&gt; Gateway Specific Rules. Choose each T0-Gateway in the drop-down and review the firewall rules "Applied To" field to verify no rules are selectively applied to interfaces instead of the Gateway Firewall entity. If any Gateway Firewall rules are applied to individual interfaces, this is a finding.

Fix: F-55133r810092_fix

From the NSX-T Manager web interface, go to Security >> Gateway Firewall >> Gateway Specific Rules and choose the target Tier-0 Gateway from the drop-down. For any rules that have individual interfaces specified in the "Applied To" field, click "Edit" in the "Applied To" column and remove the interfaces selected, leaving only the Tier-0 Gateway object type checked. Click "Publish" to save any rule changes.

b
The NSX-T Tier-0 Gateway Firewall must configure SpoofGuard to block outbound IP packets that contain illegitimate packet attributes.
CM-6 - Medium - CCI-000366 - V-251743 - SV-251743r810096_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
T0FW-3X-000036
Vuln IDs
  • V-251743
Rule IDs
  • SV-251743r810096_rule
If outbound communications traffic is not filtered, hostile activity intended to harm other networks may not be detected and prevented.
Checks: C-55180r810094_chk

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

Fix: F-55134r810095_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, enable port bindings, and then click "Save". To update a Segments SpoofGuard profile, do the following: From the NSX-T Manager web interface, go to Networking >> Segments and click "Edit" from the drop-down menu next to the target Segment. Expand Segment Profiles, choose the new SpoofGuard profile from the drop-down list, and then click "Save".