Whereas defending against volumetric DoS attacks requires resilient network architectures and service providers, dealing with application-targeted DoS puts the impetus for defense back squarely on your shoulders. As discussed in Attacks, overwhelming an application entails messing with its ability to manage session state and targeting weaknesses in the application stack. These attacks don’t require massive bandwidth, bot armies or even more than a well crafted series of GET or POST requests.

While defending against network-based DoS involves handling brute force, application attacks require a more nuanced approach. Many of these attack tactics are based on legitimate traffic. For example, even legitimate application transactions start with a simple application request. So the challenge is to separate the good from the bad without impacting legitimate traffic that will get you in hot water with your operations folks.

What about WAFs?

Application-targeted DoS attacks look an awful lot like every other application attack. Just the end goal is different. DoS attacks try to knock the application down, whereas more traditional application attacks involve compromising either the application or the server stack as a first step to either application/data tampering or exfiltration. Most organizations work to secure their applications either by building security in via a secure SDLC (software development lifecycle) or front ending the application with a WAF (web application firewall). Or, in many cases, both.

So is building security in a solution to dealing with application DoS attacks? Obviously effectively managing state within a web app is good practice, and building anti-DoS protections directly into each application will help. But given the sad state of secure application development and the prevalence of truly simplistic attacks like SQLi, it’s hard to envision anti-DoS capabilities becoming a key specification of web apps any time soon. Yeah, that’s cynical, and we recommend that you keep DoS mitigation in mind during application security and technology planning, but it will be a while before that is widespread. A long while.

What about WAFs? Are they reasonable devices for dealing with application DoS attacks? Let’s circle back to the trouble with existing WAFs: ease of evasion and the difficulty of keeping policies current. We recently did an entire series on maximizing the value of WAF: Pragmatic WAF Management, highlighting positive polices based on what applications should do, and negative policies to detect and handle attacks.

It turns out many successful WAF implementations start with stopping typical application attacks. Like a purpose-built IPS to protect applications. Those WAF policies can be helpful in stopping application DoS attacks too. Whether you’re talking about GET floods, Slowloris-type session manipulation, or application stack vulnerabilities, a WAF is well positioned to deal with those attacks.

Of course, a customer-premise-based WAF is another device that can be targeted, just like a firewall or IPS device. And given the type of inspection that is required to detect and block an application attack, overwhelming the device can be trivial. So the WAF needs anti-DoS capabilities built in, and the architectural protections discussed in the network defense post should be used to protect the WAF from brute force attacks.

Anti-DoS Devices

As mentioned in the last post, anti-DoS devices have emerged to detect volumetric attacks, drop bad traffic locally as long as possible, and then redirect the traffic to a scrubbing center. Another key capability of anti-DoS devices is their ability to deal with application DoS attacks. From this perspective they look an awful lot like half a WAF, focused on negative, policies without the capabilities to profile applications and implement positive policies. This is just fine if you are deploying equipment specifically to deal with DoS attacks.

But you don’t need to choose between a WAF and an anti-DoS device. Many anti-DoS vendors also offer full-featured WAF products. These providers may offer the best of both worlds, helping you block network attacks (via load balancing, anti-DoS techniques, and coordination with scrubbing centers), as well as implement both negative and positive WAF policies within a single policy management system.

Managed WAF Services and CDN

As with network-based DoS attacks, there is no lack of service options for handling application attacks. Let’s go through each type of service provider to compare and contrast them. First, managed WAF services. We discussed service options in the Pragmatic WAF paper, and they tend to focus on meeting compliance requirements of regulations such as PCI-DSS. These cloud WAFs tend to implement slimmed-down rule bases, focused mostly on negative policies – exactly what you need to defend against application DoS attacks.

Managed WAFs are largely offered by folks who offer Content Delivery Networks (CDN), as a value-added offering or possibly part of the core service. Obviously the less the service costs, the fewer capabilities you will have to customize the rule base, which impacts the usefulness of a general-purpose WAF. But a managed WAF service will provide the additional bandwidth and 24/7 protection you are looking for to deal with attacks, and if the primary use case is DoS mitigation, a CDN or managed WAF can meet the need.

Keep in mind that you will need to run all your application traffic through the managed WAF service, and many of the same issues crop up as with CDN. If you don’t protect the application with the managed WAF, it can be attacked directly. If its direct IP address can be discovered the application can be attacked directly. And be clear on response processes, notifications, handoffs, and forensics with the service provider before things go live, so you are ready when an attack starts.

Anti-DoS Service Providers

We discussed handling volumetric attacks with scrubbing centers. Can a scrubbing center detect and block an application DoS attack? Of course they have racks of anti-DoS gear and sophisticated SOC infrastructures to detect and defeat attacks. But that doesn’t mean this kind of service is best suited to application DoS mitigation. Application DoS is not a brute force attack. It works by gaming the innards of an application stack or application code itself. By the time you realize the application is under attack the servers are down, and switching traffic to a scrubbing center won’t change that.

If you run all your traffic through a scrubbing center (or mega-CDN), it should detect and block everything. But that’s not economically feasible for most organizations, so the scrubbing center approach is not the primary mitigation for application DoS attacks.

The Answer? It Depends

All that said, neither network nor application DoS hits by itself. As we have seen with recent DoS attacks on financial institutions, attackers are now attacking across all levels of the stack. The web infrastructure is blasted with 60gbps of traffic, while simultaneously being hit by application attacks, typically using using either SSL or application weaknesses to knock applications out, even if the traffic flood can be handled.

So you don’t really choose between tactics for the two types of DoS attacks. You need to build a mitigation architecture to handle both volumetric and application DoS. You need to combine use of on-premise solutions (or managed WAF/CDN) with scrubbing centers to provide full coverage against this class of attacks. Of course, if you need to phase in defenses, you can start with a CDN-based alternative which provides performance benefits and simple defense against DoS. As your advisories become more sophisticated and your risk profile changes, implementing customer-premise-based defenses and contracting with a scrubbing center would be next logical steps.

But without a clean and well-rehearsed process for dealing with Denial of Service attacks, you will be dead in the water anyway. Now that we have set the context for the kinds of attacks you will see and the defenses at your disposal, it’s time to put everything into context and extend your existing incident response process to DoS attacks. We will handle that next to wrap up this series.