How NGINX App Protect Denial of Service Adapts to the Evolving Attack Landscape

As we move more and more aspects of our daily lives online, cyberattackers are keeping pace in their efforts to degrade the level of service provided by the apps we rely on. Their motivations are numerous, ranging from revenge to influencing the stock price of affected companies to creating a smokescreen that distracts security teams from data breaches.

In a previous blog, we describe how in the past security teams had to continually develop new defenses against volumetric denial-of-service (DoS) and distributed DoS (DDoS) attacks at the network and transport levels (Layers 3 and 4), which exhaust servers’ available bandwidth by flooding them with TCP/UDP connection requests. Now attackers have added a new tool to their arsenal – DoS and DDoS attacks that use HTTP requests or API calls to exhaust resources at the application level (Layer 7).

Traditional DoS protections against network and volumetric attacks aren’t effective against Layer 7 attacks because at the application level malicious requests often look the same as legitimate ones. Furthermore, HTTP attacks at Layer 7 can be damaging at a much lower rate and volume of requests than network‑level attacks. Layer 7 DoS protection must be more sensitive in the face of a completely new set of requirements:

• Distinguishing attacks from regular traffic patterns
• Evaluating server health under load
• Determining when an attack started and whether it’s over
• Mitigating attacks without affecting legitimate users
• Determining whether changes in app behavior are due to attack or updates to app functionality
• Surviving a prolonged attack without loss of detection efficacy

NGINX App Protect Denial of Service (DoS) addresses all of these challenges to ensure zero‑day protection that’s streamlined, easy to implement, and provides adaptive, zero‑touch policy configuration.

How NGINX App Protect DoS Adapts to Stop Attacks Automatically

NGINX App Protect DoS uses a multistep process to detect and mitigate Layer 7 DoS attacks:

1. Capture typical behavior in a statistical site model
2. Check service health
3. Detect an anomaly
4. Identify malicious actors and request patterns
5. Mitigate the attack with a multilayer defense

Capturing Typical Behavior in a Statistical Site Model

The first step in the process is capturing user and application behavior during a time when we know the site isn’t under attack, to create a statistical site model which captures a baseline of typical behavior. NGINX App Protect DoS tracks 320 user and app metrics for a comprehensive view of your app deployment. It also dynamically updates the statistical site model as it observes traffic. This frees you from the need to adjust system thresholds manually, while also guaranteeing that NGINX App Protect DoS takes into account the changes in traffic patterns that inevitably occur over time.

One class of tracked metrics concern HTTP request characteristics – the HTTP method, the value of the User-Agent header, and others like those shown in the graphic.

Checking Service Health

Many Layer 7 DoS mitigation tools pay attention only to client traffic patterns. For superior attack detection, you can configure NGINX App Protect DoS to actively check service health in addition. It tracks multiple server performance metrics such as response time and proportion of dropped requests. Worsening values for these metrics indicate that an application is “under stress”, possibly because of an attack. There’s another benefit to tracking server metrics: once NGINX App Protect DoS determines that an attack is in progress, the pattern of responses to health checks helps identify when the attack started.

Detecting an Anomaly

When NGINX App Protect DoS determines that an attack is underway – based on deviations from the site statistical model and changes to server response (if configured) – it stops updating the site statistical model and instead analyzes how current metric values differ from the established baselines. Differences likely point to a global anomaly.

Identifying Malicious Actors and Request Patterns

NGINX App Protect DoS then kicks off two procedures that run in parallel:

1. Analyzing the behavior of individual users to detect who created or contributed to the anomaly.

   NGINX App Protect initially treats all users as suspects and analyzes their behavior. It’s unlikely that every user is an attacker, but measuring the behavior of all of them enables NGINX App Protect to create a statistical picture that reveals who did and did not contribute to the attack. Detected bad actors are identified using their IP address or the X-Forwarded-For header in their requests.

2. Generating a list of rules that describe attack traffic without blocking legitimate users – real‑time signatures for zero‑day attack protection. Signatures generated during previous attacks can be reused.

   The generated signatures identify HTTP attributes associated with the attack, as in this example:

   http.request.method eq GET and http.user_agent contains Chrome and http.uri_parameters eq 6 and http.accept_header_exists eq false and 
   http.headers_count eq 7
   

Mitigating the Attack with a Multilayer Defense

The primary goal in defending against a Layer 7 attack is to catch it before it can do any damage.

As shown in the following diagram, you can configure either a conservative or standard mitigation strategy. With both strategies, the first layer of defense is to block requests from the malicious actors who were identified by IP address and X-Forwarded-For header in the previous step. The next layer of defense blocks requests that match the signatures generated in the previous step.

Finally, if you’ve configured standard mitigation, and NGINX App Protect DoS finds the first two layers of defense are insufficient, it applies global rate limiting for a short period.

Minimizing False Positives During Attack Mitigation

When NGINX App Protect DoS applies global rate limiting, there is a chance that requests from legitimate users get blocked – a false positive. NGINX App Protect DoS can reduce false positives based on the fact that a typical DoS attack is created using scripts run by a botnet controller (malware on infected computers), not directly by humans. Unlike web browsers, many of these simple scripts cannot properly handle an HTTP redirect, and even fewer can process JavaScript. These differences in capability between scripts and browsers help NGINX App Protect DoS tell which of them is generating the suspicious traffic.

So instead of rate limiting requests from all clients, NGINX App Protect DoS first sends an HTTP redirection and then a snippet of JavaScript to be processed. Scripted bots cannot successfully respond, but a browser can, enabling NGINX App Protect DoS to block traffic from scripts while allowing browser traffic through.

We acknowledge that some users are uncomfortable relying on adaptive learning because of the potential for large numbers of false positives, but we have found it’s the most effective way to mitigate Layer 7 DoS attacks. NGINX App Protect DoS reduces false positives by combining multiple approaches – analyzing user behavior, checking service health checks, and measuring the effectiveness of mitigation tactics. Together the three approaches provide comprehensive visibility and protection without requiring you to manually alter configuration in response to attacks.

Why Layer 7 DoS Protection When I Already Have a WAF?

You might wonder why you need Layer 7 DoS protection if your WAF already protects against bots. While it’s true that Layer 7 DDoS attacks are usually launched by bots, their purpose is not the same as other bot activity. Bots typically try to grab information without disrupting service, whereas service disruption is precisely the goal of Layer 7 Dos and DDoS attacks.

Another difference is that standard anti‑bot tools try to distinguish between “good bots” and “bad bots”, a challenging task that usually requires human supervision to avoid false positives. NGINX App Protect DoS, on the other hand, doesn’t care whether traffic is generated by bots or some other mechanism – it concentrates on distinguishing between attackers and legitimate users based on their behavior. Because NGINX App Protect DoS uses antibot techniques only when it has determined that the bots are participating in a Layer 7 DoS attack, it generates significantly fewer false positives than standard antibot software. Additionally, NGINX App Protect DoS mitigation methods are CPU‑efficient, enabling it to continue protecting your apps throughout the course of a Layer DoS attack.

Conclusion

NGINX App Protect DoS tracks more than 320 metrics related to user and app behavior, resulting in a multifactor statistical model that provides the most accurate possible protection. Its unique algorithms greatly reduce false positives. These features enable NGINX App Protect DoS to mitigate highly distributed DoS attacks, where each attacking request looks completely legal and a single attacker might even generate less traffic than the average legitimate user. With its adaptive technology, NGINX App Protect DoS protects modern infrastructures not only against today’s attacks but also those that will evolve in the future.

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
• NGINX App Protect Denial of Service Blocks Application-Level DoS Attacks

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