STIGhubSTIGhub
STIGsRMF ControlsCompare

STIGhub

A free tool to search and browse the entire DISA STIG library. Saves up to 75% in security compliance research time.

Navigation

  • Browse STIGs
  • Search
  • RMF Controls
  • Compare Versions

Resources

  • About
  • Release Notes
  • VPAT
  • DISA STIG Library
STIGs updated 4 hours ago
Powered by Pylon
© 2026 Beacon Cloud Solutions, Inc. All rights reserved.
← Back to VMware NSX 4.x Manager NDM Security Technical Implementation Guide

V-265346

CAT II (Medium)

The NSX Manager must be configured to protect against denial-of-service (DoS) attacks by limit the number of concurrent sessions to an organization-defined number.

Rule ID

SV-265346r994261_rule

STIG

VMware NSX 4.x Manager NDM Security Technical Implementation Guide

Version

V1R2

CCIs

CCI-002385CCI-000054

Discussion

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. Limiting the number of concurrent open sessions helps limit the risk of DoS attacks. Organizations may define the maximum number of concurrent sessions for system accounts globally or by connection type. By default, the NSX Manager has a protection mechanism in place to prevent the API from being overloaded. This setting also addresses concurrent sessions for integrations into NSX API to monitor or configure NSX. Satisfies: SRG-APP-000435-NDM-000315, SRG-APP-000001-NDM-000200

Check Content

From an NSX Manager shell, run the following command:

> get service http | find limit

Expected result:
Client API concurrency limit: 40 connections
Global API concurrency limit: 199 connections

If the NSX does not limit the number of concurrent sessions to an organization-defined number, this is a finding.

Fix Text

From an NSX Manager shell, run the following commands:

> set service http client-api-concurrency-limit 40
> set service http global-api-concurrency-limit 199

Note: The limit numbers in this example, while not mandatory, are the vendor recommend options. Setting the limits to lower numbers in a large environment that is very busy may cause operational issues. Setting the limits higher may cause resource contention so should be tested and monitored.