…definition. As I am working on my research project related to denial of service mitigation, I come across the concept of “application DoS.” Sadly, just as many things in security industry, labeled with "application something" (application security monitoring anybody?), this one is not clearly defined. This lack of clarity leads to missed requirements and misplaced trust in security controls.
For example:
- Is a “GET /” flood from a bunch of LOIC users an application DoS? Presumably yes.
- Will exploitation of a DoS-level vulnerability (with CVSS “A” impact of “Complete”) qualify? Yes, indeed.
- How about Slowloris or other Apache abuses? Yes.
- What about adding 100,000 items to a web shopping cart? Absolutely.
However, an astute reader will realize that the above malicious activities are very dissimilar in nature, and different technologies might be required for their mitigation. The wide range of what is commonly considered an application denial of service might call for an anti-DoS device (or service) for the #1, NIPS for the #2 and a WAF for the #3 and (likely) #4 as well. Mitigating #4 may also require application stack modifications.
In fact, the last example moves us dangerously close to a potentially “unstoppable” DoS, based on any of the numerous application capabilities where a small action by an untrusted client (request of a search page) triggers a lot of computation, disk I/O, RDBMS queries (database SELECT * FROM command, hashing, etc). Presumably, delivering a useful (and sometimes large) piece of data in response to a small request is what web is largely about and eliminating all such occurrences is impossible. Thus, it is pretty obvious that DoS will ALWAYS be with us…
Related blog posts:
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
6 Comments
DoS is all about amplification and all DoS are ‘application’ attacks. If you are doing a smurf attack you are attacking a bug in the router’s software – it’s an application someone wrote to handle packets. If you are doing a DNS attack you are attacking the DNS application. Likewise, if you have a way to cause the server to work hard on a single request to the web application.
By “DoS” it is assumed the attacker is spending a lot less {CPU|Network|RAM} than the target. If they are roughly the same but launched from multiple machines, we will call those machines a botnet and the attack is a DDoS. Otherwise, the force balance is such that the victim has much more resources the attacker. If you are adding 100,000 items to a shopping cart and the web site cannot handle that fast enough, that is a software bug.
So by definition, there is no such thing as an “anti-DoS” device, unless you found a way to heal all software bugs. Good luck with that 🙂
>all DoS are ‘application’ attacks
Thanks a lot for adding more confusion to the discussion – we need more of it in the industry! 🙂
On a more serious note, an attempt to separate application, layer 7, etc DoS from a) floods and b) transport Layer 3/4 DoS is actually very valuable in order to figure our which defense mechanisms to be used.
And, obviously, “anti-DoS” device does not mean “stop all DoS”, just like AV does not mean “stop all viruses”….
Hi Anton,
Actually, I was following your examples of Apache and Solaris attacks which you put in the ‘application attacks’ bucket. I don’t think you can argue they are “layer-7” attacks, at least not by the common IT security definition. If you want to lower the confusion level defining your question better might help 😉
Defense mechanisms for layer-7 DoS (again, in a very theoretical level):
1. Fix all bugs in the application that may cause unintentional DoS
2. Make sure every user action is O(1)
#2 is very much do-able (even if difficult). I can’t see how you can possibly do #1.
Aviram, thanks for the insightful comment!
Indeed, I used “application” and “layer 7” interchangeably and those are not necessarily the same – so shame on me 🙂
To fix all app DoS we need to fix all the bugs – but even that would not be enough, sadly. Some functionality will likely remain “abusable” since a small request (e.g. search) can trigger a lot of server compute or I/O and thus make the app DoS-able. It may be O(1), but still pretty uneven in terms of small- attacker action-> large target response.
Anton,
Agreed on all points. But isn’t it a bit like seeking the silver bullet (for DoS)? If we agree that DoS comes in many forms, requires (among other things) fixing all bugs AND building resilient infrastructure, wouldn’t it be easier to spend our time searching for the cancer cure instead? 😉
More seriously (and constructively), a good way forward might be to limit the scope of ‘DoS defense’ to make it a more reachable target, knowing it doesn’t cover everyhing, just “some things” (I have no idea how one might do that, I’m just throwing it out there).
Indeed, this is true – about the scope limitation. I am trying to logically slice it in my report and then tie solutions to types of issues (or point out that a solution does not really exist for some attack types)