{"stig":{"title":"VMware NSX 4.x Distributed Firewall Security Technical Implementation Guide","version":"1","release":"2"},"checks":[{"vulnId":"V-265612","ruleId":"SV-265612r993933_rule","severity":"low","ruleTitle":"The NSX Distributed Firewall must generate traffic log entries that can be sent by the ESXi hosts to the central syslog.","description":"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.\n\nAudit 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.\n\nAssociating 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.\n\nSatisfies: 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","checkContent":"From the NSX Manager web interface, navigate to Security >> Policy Management >> Distributed Firewall >> All Rules.\n\nFor each rule, click the gear icon and verify the logging setting.\n\nIf logging is not enabled for any rule, this is a finding.","fixText":"From the NSX Manager web interface, navigate to Security >> Policy Management >> Distributed Firewall >> Category Specific Rules.\n\nFor each rule that has logging disabled, click the gear icon, toggle the logging option to \"Enable\", and click \"Apply\".\n\nor\n\nFor each Policy or Section, click the menu icon on the left and select \"Enable Logging for All Rules\".\n\nAfter all changes are made, click \"Publish\".\n\nNOTE: Syslog and alert monitoring procedure: Syslog configuration is in the vSphere ESXi STIG where there is a control to require syslog configuration. This is because the NSX Distributed Firewall data plane is not directly configured to communicate with the central log server/syslog. The firewall runs in a distributed manner across ESXi hosts, and the traffic logs for the DFW are located on each host for the traffic it processes and are forwarded from each host to a centralized syslog server. Thus, ESXi hosts must be configured to send the syslogs to the log server. In turn, the syslog must be configured to send all required alerts, including when unknown or out-of-order extension headers are detected in inbound and outbound IPv6 traffic.","ccis":["CCI-000130","CCI-000131","CCI-000132","CCI-000133","CCI-000134","CCI-000172"]},{"vulnId":"V-265618","ruleId":"SV-265618r993951_rule","severity":"medium","ruleTitle":"The NSX Distributed Firewall must limit the effects of packet flooding types of denial-of-service (DoS) attacks.","description":"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.\n\nThe 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.\n\nSatisfies: SRG-NET-000193-FW-000030, SRG-NET-000192-FW-000029, SRG-NET-000362-FW-000028","checkContent":"From the NSX Manager web interface, navigate to Security >> Settings >> General Settings >> Firewall >> Flood Protection to view Flood Protection profiles.\n\nIf there are no Flood Protection profiles of type \"Distributed Firewall\", this is a finding.\n\nIf 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.\n\nFor each distributed firewall flood protection profile, examine the \"Applied To\" field to view the workloads it is protecting.\n\nIf a distributed firewall flood protection profile is not applied to all workloads through one or more policies, this is a finding.","fixText":"To create a new Flood Protection profile:\n\nFrom the NSX Manager web interface, navigate to Security >> Settings >> General Settings >> Firewall >> Flood Protection >> Add Profile >> Add Firewall Profile.\n\nEnter 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.\n\nEnable SYN Cache and RST Spoofing, configure the \"Applied To\" field with the appropriate security groups, and click \"Save\".","ccis":["CCI-001095","CCI-001094","CCI-002385"]},{"vulnId":"V-265619","ruleId":"SV-265619r993954_rule","severity":"medium","ruleTitle":"The NSX Distributed Firewall must deny network communications traffic by default and allow network communications traffic by exception.","description":"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.\n\nAs 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).\n\nSatisfies: SRG-NET-000202-FW-000039, SRG-NET-000235-FW-000133","checkContent":"From the NSX Manager web interface, navigate to Security >> Policy Management >> Distributed Firewall >> Category Specific Rules >> APPLICATION >> Default Layer3 Section >> Default Layer3 Rule >> Action.\n\nIf the Default Layer3 Rule is set to \"ALLOW\", this is a finding.","fixText":"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\".\n\nAfter all changes are made, click \"Publish\".\n\nNote: 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.","ccis":["CCI-001109","CCI-001190"]},{"vulnId":"V-265628","ruleId":"SV-265628r993981_rule","severity":"medium","ruleTitle":"The NSX Distributed Firewall must be configured to inspect traffic at the application layer.","description":"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.\n\nSome 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.","checkContent":"From the NSX Manager web interface, navigate to Security >> Distributed Firewall >> All Rules.\n\nReview 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.\n\nIf any rules with services defined have an associated suitable Context Profile but do not have one applied, this is a finding.","fixText":"From the NSX Manager web interface, navigate to Security >> Policy Management >> Distributed Firewall >> Category Specific Rules.\n\nFor each rule that should have a Context Profile enabled, click the pencil icon in the Context Profile column.\n\nSelect an existing Context Profile or create a custom one then click \"Apply\".\n\nAfter all changes are made, click \"Publish\".\n\nNote: This control does not apply to Ethernet rules.\n\nNot all App IDs will be suitable for use in all cases and should be evaluated in each environment before use.\n\nA list of App IDs for application layer rules is available here: https://docs.vmware.com/en/NSX-Application-IDs/index.html.","ccis":["CCI-000366"]},{"vulnId":"V-265630","ruleId":"SV-265630r993987_rule","severity":"medium","ruleTitle":"The NSX Distributed Firewall must configure SpoofGuard to restrict it from accepting outbound packets that contain an illegitimate address in the source address.","description":"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.\n\nSpoofGuard 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.","checkContent":"Identity SpoofGuard profiles in use by doing the following:\n\nFrom the NSX Manager web interface, navigate to Networking >> Connectivity >> Segments >> NSX.\n\nFor each segment, expand view Segment Profiles >> SpoofGuard to note the profiles in use.\n\nReview SpoofGuard profile configuration by doing the following:\n\nFrom the NSX Manager web interface, navigate to Networking >> Connectivity >> Segments >> Profiles >> Segment Profiles.\n\nReview the SpoofGuard profiles previously identified as assigned to segments to ensure the following configuration:\n\nPort Bindings: Yes\n\nIf a segment is not configured with a SpoofGuard profile that has port bindings enabled, this is a finding.","fixText":"To create a segment profile with SpoofGuard enabled, do the following:\n\nFrom the NSX Manager web interface, navigate to Networking >> Connectivity >> Segments >> Profiles >> Segment Profiles >> Add Segment Profile >> SpoofGuard.\n\nEnter a profile name and enable port bindings, then click \"Save\".\n\nTo update a segments SpoofGuard profile, do the following:\n\nFrom 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.\n\nExpand \"Segment Profiles\" then choose the new SpoofGuard profile from the drop-down list, and then click \"Save\".","ccis":["CCI-000366"]},{"vulnId":"V-265633","ruleId":"SV-265633r993996_rule","severity":"high","ruleTitle":"The NSX Distributed Firewall must configure an IP Discovery profile to disable trust on every use method.","description":"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.\n\nIP 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.\n\nThe 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.\n\nBy 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 <IP, MAC, VLAN> 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.","checkContent":"Identify IP Discovery profiles in use by doing the following:\n\nFrom the NSX Manager web interface, navigate to Networking >> Connectivity >> Segments >> NSX.\n\nFor each segment, expand view Segment Profiles >> IP Discovery to note the profiles in use.\n\nReview IP Discovery profile configuration by doing the following:\n\nFrom the NSX Manager web interface, navigate to Networking >> Connectivity >> Segments >> Profiles >> Segment Profiles.\n\nReview the IP Discovery profiles previously identified as assigned to segments to ensure the following configuration:\n\nDuplicate IP Detection: Enabled\nARP Snooping: Enabled\nARP Binding Limit: 1\nDHCP Snooping: Disabled\nDHCP Snooping - IPv6: Disabled\nVMware Tools: Disabled\nVMware Tools - IPv6: Disabled\nTrust on First Use: Enabled\n\nIf a segment is not configured with an IP Discovery profile that is configured with the settings above, this is a finding.","fixText":"To create a segment profile for IP Discovery, do the following:\n\nFrom the NSX Manager web interface, navigate to Networking >> Connectivity >> Segments >> NSX >> Profiles >> Segment Profiles >> Add Segment Profile >> IP Discovery.\n\nEnter a profile name then configure the below settings:\n\nDuplicate IP Detection: Enabled\nARP Snooping: Enabled\nARP Binding Limit: 1\nDHCP Snooping: Disabled\nDHCP Snooping - IPv6: Disabled\nVMware Tools: Disabled\nVMware Tools - IPv6: Disabled\nTrust on First Use: Enabled\n\nClick \"Save\".\n\nNote: ND Snooping may be enabled if IPv6 is in use.\n\nTo update a segments IP Discovery profile, do the following:\n\nFrom 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.\n\nExpand \"Segment Profiles\" then choose the new IP Discovery profile from the drop-down list, and then click \"Save\".","ccis":["CCI-000366"]}]}