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

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

  • Version/Release: V1R2
  • Published: 2024-12-20
  • Released: 2025-01-30
  • 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 Tier-1 Gateway firewall must generate traffic log entries.
AU-3 - Medium - CCI-000130 - V-265488 - SV-265488r994833_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
NT1F-4X-000004
Vuln IDs
  • V-265488
Rule IDs
  • SV-265488r994833_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-69405r994831_chk

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: F-69313r994832_fix

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

c
The NSX Tier-1 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-265493 - SV-265493r994848_rule
RMF Control
SC-5
Severity
High
CCI
CCI-001095
Version
NT1F-4X-000015
Vuln IDs
  • V-265493
Rule IDs
  • SV-265493r994848_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 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. Satisfies: SRG-NET-000193-FW-000030, SRG-NET-000192-FW-000029, SRG-NET-000362-FW-000028
Checks: C-69410r994846_chk

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-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: F-69318r994847_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 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. Configure the "Applied To" field to contain Tier-1 Gateways and then click "Save".

b
The NSX Tier-1 Gateway firewall must deny network communications traffic by default and allow network communications traffic by exception.
SC-7 - Medium - CCI-001109 - V-265494 - SV-265494r994851_rule
RMF Control
SC-7
Severity
Medium
CCI
CCI-001109
Version
NT1F-4X-000016
Vuln IDs
  • V-265494
Rule IDs
  • SV-265494r994851_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, SRG-NET-000364-FW-000032
Checks: C-69411r994849_chk

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: F-69319r994850_fix

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

b
The NSX Tier-1 Gateway firewall must be configured to send traffic log entries to a central audit server.
AU-4 - Medium - CCI-001851 - V-265496 - SV-265496r994857_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
NT1F-4X-000020
Vuln IDs
  • V-265496
Rule IDs
  • SV-265496r994857_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-69413r994855_chk

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: F-69321r994856_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 and 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 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 Edge Node appliance. Note: Configure the syslog or Simple Network Management Protocol (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 Tier-1 Gateway firewall must be configured to inspect traffic at the application layer.
CM-6 - Medium - CCI-000366 - V-265500 - SV-265500r994869_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
NT1F-4X-000027
Vuln IDs
  • V-265500
Rule IDs
  • SV-265500r994869_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. 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.
Checks: C-69417r994867_chk

From the NSX Manager web interface, go to Security &gt;&gt; Policy Management &gt;&gt; Gateway Firewall &gt;&gt; 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: F-69325r994868_fix

From the NSX Manager web interface, go to Security >> Policy Management >> Gateway Firewall >> Gateway Specific Rules. For each Tier-1 Gateway and 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". 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.