A Distributed Denial of Service (DDoS) attack is generally volumetric attacks, intended to overwhelm their target by consuming all available capacity for the vector being attacked. NSX Advanced Load Balancer is built on a distributed data plane model, which allows it to quickly scale capacity to handle the attack.

Volumetric attacks can commonly be grouped into three buckets, based on the intended vulnerability being targeted. These are:

  • Throughput/ packets per second

  • Memory

  • CPU

NSX Advanced Load Balancer protects itself, the networks, and the applications through many mechanisms, and a unique ability to dynamically increase its size when necessary. Administrators have complete control to view and respond to attacks.

Note:

This feature is not supported for IPv6.

Scaling Capacity



The NSX Advanced Load Balancer plays a significant role as the last line of defense to protect applications and networks against DDoS attacks. One of key defenses of NSX Advanced Load Balancer is the ability to absorb DDoS by quickly scaling out a virtual service across commodity hardware.

A single Service Engine can be configured with up to 36 CPU cores and 128 GB memory. Performance increases nearly linearly with the additional hardware allocation. A Service Engine installed on a bare-metal server can saturate multiple 10-Gbps NICs and sustain millions of packets per second.

The NSX Advanced Load Balancer can also scale out, distributing load horizontally across multiple SEs. Using native autoscale of NSX Advanced Load Balancer, a single virtual service can be distributed across up to four SEs. Using BGP and Equal Cost MultiPath routing, a single virtual service can be scaled across 32 SEs.

Licensing model of NSX Advanced Load Balancer is flexible, enabling an application virtual service under attack to automatically be moved to dedicated Service Engines. Isolating the attack ensures that multiple applications or tenants are not impacted by the event, and provides further scale of resources to defend against the attack. The NSX Advanced Load Balancer can also burst beyond the licensed limit of the system, ensuring the health of the applications on priority.

Attack Mitigation

The NSX Advanced Load Balancer natively protects against different DDoS attacks targeting IP, TCP, SSL, and HTTP. Service Engines automatically defend themselves by implementing features such as TCP SYN cookies, idle connection reaping, and protocol validation, and so on.



IP Blocklists can be configured and automatically updated by third party systems through REST APIs. Administrators can also choose to block an attacker through the block button from the Security page in the UI.

Customized Protection

Many predefined DDoS detections are built into the system, but are easily configurable for full customization on a per-application basis. For example, an attacker doing a port scan can be reported, or can be actively blocked. Another attacker doing an HTTP request flood may be throttled, dropped, or sent a customized error page. A wide range of rate shaping and throttling features for layer 4 through 7 protocols exist to ensure maximum security with minimal effort or training. To know more, see Rate Shaping and Throttling Options in the VMware NSX Advanced Load Balancer Monitoring and Operability Guide.



Further customization can be done through the Policy Engine of NSX Advanced Load Balancer, which allows point-and-click rule sets to be defined, such as blocking or throttling users from specific countries.

For the highest level of customization, DataScripts can be used to identify suspicious traffic and take appropriate actions. DataScripts are scripted rules based on Lua which can be used for higher layer DDoS mitigation, such as blocking brute force login attempts or other use cases.

Attack Visibility

The NSX Advanced Load Balancer is more of a distributed fabric, rather than a collection of isolated appliances linked by a centralized manager. Since each Service Engine is part of a fabric, an attack on any SE is fed to the Controllers for analysis and correlation. The Controllers push configuration changes down to the other Service Engines, such as to throttle a bad actor. For example, a port scan that is distributed across multiple Service Engines will still be detected and the attacker automatically quarantined, even if the connection is the first made by the attacker to the SE.

The NSX Advanced Load Balancer provides rich data on client interaction with virtual services. It logs the client’s site navigation, timings, errors, and so on. More than 100 data points are logged for an attacking client. The NSX Advanced Load Balancer makes it easy to drill in to view top attackers, their IP, country, ASN, operating system, and any interaction they had with the site prior to launching the attack. Most importantly, it is easy to take action with the click of a button to throttle, block permanently or block for a limited time.



A system that is difficult to understand is also difficult to properly secure. Similarly, the NSX Advanced Load Balancer can proactively send alerts to email, syslog, SNMP, or custom APIs to ensure that administrators are kept aware of events, as they happen. The powerful alerting and reporting tools, which monitor over 500 real-time metrics, are a vital component for ensuring successful DDoS and attack mitigation.



Thresholds for DDOS Attacks

DOS attacks are reported as DDOS events. A threshold is used by service engine to report a DOS attack to the Controller. The threshold starts with a configurable minimum threshold. As the attack increases, the threshold is also increased by a fraction of the threshold value until the configurable maximum threshold is reached. At any point, new attack events are raised only if the number of attacks are above the threshold. When the attack decreases the threshold also decreases step by step till it reaches minimum threshold.

The values can be dynamically adjusted by using the min_thresh and max_thresh parameters. The threshold value is specified when initializing the structure containing the threshold values:

thresh = se_min(se_max(thresh, min_thresh), max_thresh)

SE Level Attacks

The default threshold values if DoS threshold profile is not configured in the Service Engine Group are as follows:

DDoS Attack

Minimum Threshold

Maximum Threshold

LAND

500

5000

SMURF

500

5000

ICMP_FLOOD

500

5000

UNKNOWN_PROTOCOL

500

5000

TEARDROP

500

5000

IP_FRAG_OVERRUN

500

5000

IP_FRAG_TOOSMALL

500

5000

IP_FRAG_FULL

500

5000

IP_FRAG_INCOMPLETE

500

5000

PORT_SCAN

500

5000
Note:

These threshold values are per dispatcher core for SE.

Virtual Service Level Attacks

The default threshold values stored in the application profile’s DoS threshold profile for virtual service DoS attacks are as follows:

DDoS Attack

Minimum Threshold

Maximum Threshold

SYN_FLOOD

BAD_RST_FLOOD

500

5000

MALFORMED_FLOOD

500

5000

FAKE_SESSION

500

5000

ZERO_WINDOW_STRESS

500

5000

SMALL_WINDOW_STRESS

500

5000

DOS_HTTP_TIMEOUT

500

5000

DOS_HTTP_ERROR

500

5000

DOS_HTTP_ABORT

500

5000

DOS_SSL_ERROR

500

5000

DOS_APP_ERROR

500

5000

DOS_SLOW_URL

500

5000

TCP_NON_SYN_FLOOD

100

1000

POLICY_DROPS

100

1000

DNS_ATTACK_REFLECTION

Decided by security manager

UINT_MAX

DNS_ATTACK_AMPLIFICATION_EGRESS

Decided by security manager

UINT_MAX
For the unlisted attack types max and min thresholds are set to 0 by default.

These threshold values are per proxy core for virtual service.