On DoS Detection

In the past, I used to cringe when I heard that somebody offers "DoS detection" capability. After all, detection of a successful DoS attack should be trivial: you have no service, it has been "denied." I am happy to report that I was wrong. DoS detection is a sneaky little problem today.

First, you might have no service, but how do you know you are under a malicious DoS attack? A lot of factors may affect the availability of networks, servers, applications and whatever other part of modern IT – from your business sudden popularity to your server team sudden idiocy. Maybe we can call this "attack discrimination" if you object to this being called “detection.” In essence, telling a malicious attack from an operational failure is an important part of DoS detection.

Second, you might be under a successful attack but still have service. Huh? Well, what if your site usually serves 1000 customers an hour but it’s been serving only 50 for the last few days. You might be under the attack, which is succeeding to sufficient degree to bring glee to the attacker’s eye, but not enough for your service availability indicators to blink RED. Another fun example was given to my by a vendor today: “everything” works in your web app, except for an ability of your users to login (it is DoS’d)… A special DoS detection measures would be called for such "reduction of service" attacks.

Third, you might have intermittent failure indicators in different places due to a suspected attack which just refuse to converge into an obvious attack pattern. You see attack evidence, just not enough to do anything about it. You still need to figure our what type of an attack it is to mitigate it. Think of this as "attack classification."

In other words, if you only consider massive traffic floods to be DoS, then detection is indeed trivial (and mitigation often is not) – you lose your internet presence. However, is is often not what DoS is about in 2012.

Finally, I find it curious that the industry got used to tools that detect+block an attack (think NIPS, WAF, etc) and a lot of that thinking (about deployment, architecture, but more importantly, operations!) just doesn’t carry over into the DoS realm. As I explore this corner of security realm, I notice that while detection is needed for both intrusions and DoS attacks, we want to block/prevent (and later investigate, of course) the former, but have to mitigate/reduce the latter.

Blocking implies closing a door, but mitigation implies …mmmm…. can’t think of a good analogy here … trying to push a malicious actor back out through the open door? We can try to erect a relatively intrusion-proof door (yes, with all the known limitations and only for specific types of intrusions), but we have to fight the DoS attack while also keeping the door open with the attacker on the other side trying different tricks to get in. In any case, please help me with this metaphor Smile Similarly, I heard another way to put from a anti-DDoS service provider COO: “DDoS is a human-vs-human attack, not human-vs-machine.”