Cyber · Trackr The Free Compliance Library
⌘K
DoD Compliance · STIG

VMware NSX 4.x Tier-0 Gateway Firewall Security Technical Implementation Guide

V1R2 · · · Released 30 Jan 2025 · 4 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

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.
Digest of Updates vs. V1R1 · 07 Aug 2024 +4 −4

Comparison against the immediately-prior release (V1R1). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.

Added rules 4

  • V-265362 Medium The NSX Tier-0 Gateway Firewall must generate traffic log entries.
  • V-265367 High The NSX Tier-0 Gateway Firewall must manage excess bandwidth to limit the effects of packet flooding types of denial-of-service (DoS) attacks.
  • V-265368 Medium The NSX Tier-0 Gateway Firewall must deny network communications traffic by default and allow network communications traffic by exception.
  • V-265370 Medium The NSX Tier-0 Gateway Firewall must be configured to send traffic log entries to a central log server.

Removed rules 4

  • V-263278 Medium The NSX Tier-0 Gateway Firewall must generate traffic log entries.
  • V-263279 High The NSX Tier-0 Gateway Firewall must manage excess bandwidth to limit the effects of packet flooding types of denial-of-service (DoS) attacks.
  • V-263280 Medium The NSX Tier-0 Gateway Firewall must deny network communications traffic by default and allow network communications traffic by exception.
  • V-263281 Medium The NSX Tier-0 Gateway Firewall must be configured to send traffic log entries to a central audit server.
Sort by
b
The NSX Tier-0 Gateway Firewall must generate traffic log entries.
AU-3 - Medium - CCI-000130 - V-265362 - SV-265362r994329_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
NT0F-4X-000004
Vuln IDs
  • V-265362
Rule IDs
  • SV-265362r994329_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 usage or capacity thresholds, or identifying an improperly configured network element. Satisfies: SRG-NET-000074-FW-000009, SRG-NET-000061-FW-000001, 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-69279r994327_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 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: F-69187r994328_fix

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 with logging disabled, click the gear icon, enable logging, and then click "Apply". After all changes are made, click "Publish".

c
The NSX Tier-0 Gateway Firewall must manage excess bandwidth to limit the effects of packet flooding types of denial-of-service (DoS) attacks.
SC-5 - High - CCI-001095 - V-265367 - SV-265367r994344_rule
RMF Control
SC-5
Severity
H
CCI
CCI-001095
Version
NT0F-4X-000015
Vuln IDs
  • V-265367
Rule IDs
  • SV-265367r994344_rule
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 impact control of keep-alives and timers used for neighbor peering. This will result 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. Satisfies: SRG-NET-000193-FW-000030, SRG-NET-000192-FW-000029, SRG-NET-000362-FW-000028
Checks: C-69284r994342_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 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, if 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: F-69192r994343_fix

To create a new Flood Protection profile, do the following: From the NSX Manager web interface, go to Security >> Settings >> 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 Tier-0 Gateway Firewall must deny network communications traffic by default and allow network communications traffic by exception.
SC-7 - Medium - CCI-001109 - V-265368 - SV-265368r994347_rule
RMF Control
SC-7
Severity
M
CCI
CCI-001109
Version
NT0F-4X-000016
Vuln IDs
  • V-265368
Rule IDs
  • SV-265368r994347_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-000205-FW-000040, SRG-NET-000235-FW-000133, SRG-NET-000364-FW-000031
Checks: C-69285r994345_chk

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: F-69193r994346_fix

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. Change the Action to "Drop" or "Reject", and then click "Publish".

b
The NSX Tier-0 Gateway Firewall must be configured to send traffic log entries to a central log server.
AU-4 - Medium - CCI-001851 - V-265370 - SV-265370r994353_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001851
Version
NT0F-4X-000020
Vuln IDs
  • V-265370
Rule IDs
  • SV-265370r994353_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. Satisfies: SRG-NET-000333-FW-000014, SRG-NET-000098-FW-000021
Checks: C-69287r994351_chk

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 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: F-69195r994352_fix

To configure a profile to apply syslog servers to all NSX Edge Nodes, do the following: From the NSX Manager web interface, go to System >> Configuration >> Fabric >> Profiles >> Node Profiles. Click "All NSX Nodes" and then under "Syslog Servers", click "Add". Enter the syslog server details, choose "Information" for the log level, and click "Add". or (Optional) From an NSX Edge Node shell, run the following command to clear any existing incorrect logging servers: > clear logging-servers From an NSX Edge Node shell, run the following command to configure a TCP syslog server: > set logging-server <server-ip or server-name> proto tcp level info From an NSX Edge Node shell, run the following command 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 Edge Node shell, run the following command to configure an LI-TLS syslog server: > set logging-server <server-ip or server-name> proto li-tls level info serverca root-ca.crt Note: If using the protocols TLS or LI-TLS to configure a secure connection to a log server, the server and client certificates must be stored in /var/vmware/nsx/file-store/ on each NSX Edge Node appliance. Note: Configure the syslog 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.