NGINX App Protect Denial of Service Blocks Application-Level DoS Attacks

While digital transformation is accelerating business potential, unfortunately it’s also broadening the threat landscape. As security teams are occupied adjusting to increasing scope and responsibility, attackers are taking advantage, becoming more sophisticated than ever in the ways they abuse applications for financial gain. Compared to traditional denial-of-service (DoS) attacks at the network level, application‑level (Layer 7) DoS attacks are rising sharply, in large part because they can bypass traditional defenses that are not designed for modern application architectures.

From the viewpoint of attackers, Layer 7 DoS attacks have two valuable features: they require very few resources to create significant disruption, and they are difficult to detect. Generated using sophisticated tools and precisely targeted requests, such attacks disrupt application servers and APIs by making them unable to process legitimate requests. When a server is bombarded with more requests than it can process, it drops legitimate requests, becomes unresponsive, or even crashes.

Traditional DoS‑mitigation solutions are not effective for modern apps. They provide static rule‑based security and require continuous maintenance to keep up with the pace of changes and updates in the modern app landscape.

Introducing NGINX App Protect DoS

NGINX App Protect Denial of Service (DoS) is a new lightweight dynamic module for NGINX Plus, designed to protect modern applications against the most sophisticated application DoS attacks. NGINX App Protect DoS mitigates attacks that intend to disrupt and harm applications, ensuring continuous performance and revenue collection, and preserving customer loyalty and brand in a highly competitive digital world.

NGINX App Protect DoS can be deployed close to applications and microservices on any platform, architecture, or environment, including Kubernetes clusters. It scales out along with the application and maintains high security effectiveness at all times.

Deployment Use Cases

NGINX App Protect DoS can be deployed in a variety of locations to protect application services:

• Edge – External load balancers and proxies
• Ingress Controller – Entry point into Kubernetes
• Per‑service proxy – Interior service proxy tier
• Per‑pod proxy – Proxy embedded in pod
• API gateway – Entry point into microservices

Mitigated Attack Types

NGINX App Protect DoS introduces protection against multiple sophisticated attack types:

• GET and POST flood attacks – (Both HTTP and HTTPS) The attacker tries to overwhelm the server or API with large numbers of requests, rendering it unable to respond to real users.

• “Slow” attacks – (Both HTTP and HTTPS) “Slow-and-low” attacks tie up server resources, leaving none available for servicing requests from actual users. Two factors make them difficult to defend against:

  • Unlike network DDoS attacks, they don’t use extensive bandwidth, making them difficult to distinguish from normal traffic.
  • They don’t require many resources to launch, so thousands of requests can be sent from a single computer using sophisticated automation tools.

  There are three main types of slow attacks:

  • Slowloris – The attacker connects to the server and sends partial request headers at a slow pace. The server keeps the connection open while waiting for the remainder of the headers, exhausting the pool of connections available to actual users.
  • Slow read – The attacker sends a well‑formed HTTP request, but then reads the response at a sluggish speed, if at all. This has the cumulative effect of consuming server resources, thus preventing legitimate requests from going through.
  • Slow POST – The attacker sends legitimate HTTP POST headers to the server, complete with correct specification of the size of the message body that will follow. It then sends the message body very slowly. Because the message seems valid, the server keeps the connection open waiting for the complete body to arrive. A large number of slow POST attacks exhaust the pool of connections available for actual users.

• Distributed variations of the preceding attacks – Obviously, enlisting multiple computers makes it easy to send a larger number of simultaneous attacks. Further, the traffic volume from each computer can be relatively low, making it resemble a regular user. Computers can also drop out of the attack pool and then rejoin, putting the set of source IP addresses in constant flux. These traffic characteristics make traditional mitigation techniques like rate limiting and geo‑blocking less effective.

• Challenge Collapsar attack/random URIs – In a Challenge Collapsar (CC) attack, the attacker sends frequent requests that are normal except that the requested URIs require execution of complicated, and thus time‑consuming, algorithms or database operations, which can exhaust resources on the targeted server. The attacker can also randomize URIs and other HTTPs parameters in way that defeats legacy mitigation tools like static rules. NGINX App Protect DoS instead relies on advanced machine‑learning algorithms that dramatically increase efficacy and reduce false positives.

​

• Hiding behind NAT – The attacker uses encryption or network address translation (NAT) to evade detection. Trying to detect attacks by tracking only the source IP address is ineffective because it treats all NAT users as attackers even if only one user is attacking.

  NGINX App Protect DoS uses fingerprinting for IPv4 to accurately detect bad actors behind NAT. Since most traffic is encrypted using SSL/TLS, it’s possible to extend the key that identifies an actor from just IP address to the combination of IP address and TLS fingerprint (the fingerprint being based on the TLS hello message).

• Targeted SSL/TLS attacks – The attacker abuses the SSL/TLS handshake protocol. One popular approach is to send garbage data to the target SSL/TLS server. It’s just as computationally expensive to process an invalid message as a legitimate one, but without a useful result. Most firewalls don’t help in this case because they can’t distinguish between valid and invalid SSL/TLS handshake packets, and implementing decryption on a firewall is cost‑prohibitive.

  NGINX App Protect DoS uses an SSL/TLS signatures mechanism to provide anomaly‑based detection and mitigation based on the CLIENT HELLO message, which is unencrypted and passed early in the SSL/TLS handshake process, eliminating the high cost of decryption. In addition, using SSL/TLS signatures together with monitoring server health mechanism allows DoS protection and mitigation without SSL/TLS termination.

Summary

It’s becoming more common for DoS attacks to target applications instead of the network. Because many of these Layer 7 DoS attacks look like legitimate traffic, traditional WAF defenses can’t effectively detect them.

Moreover, attackers continue to leverage new technology like machine learning and AI to launch Layer 7 DoS attacks, making simple rules and static signatures less effective. Layer 7 DoS mitigation must evolve as well, and NGINX App Protect DoS brings the right technology to bear with adaptive and dynamic defenses.

If you’d like to learn more about how to ensure DoS protection, check out our solution brief. Also see these related blogs:

• Defending Applications from Complex and Modern Attacks
• How NGINX App Protect Denial of Service Adapts to the Evolving Attack Landscape

Try NGINX App Protect DoS for yourself – start a free 30-day trial today or contact us to discuss your use cases.