Rational Survivability

Soundtrack for this post: http://tiny.cc/9tgjcx

I had a similar dialogue with a colleague last week after a certain vendor published a whitepaper outlining the “4 steps to Defeat a DDoS Attack”. He thought it was a good paper that gave security practitioners (potential customers) a good starting place. I found it trite and insulting to the intelligence of anyone who has ever actually weathered a DDoS attack (though I don’t think there’s anyone who has *only* weathered one). Four steps? C’mon. If it was that easy, even to get started, no one would ever talk about DDoS attacks, because no one would ever be “defeated” (experience service outage) from one.

Perhaps I have some innate loathing of oversimplification for the purpose of marketing, but this one struck me as particularly crude.

While I agree with Hoff, I suggest the terms ‘quench’, ‘shunt’ ‘sink’ to describe DDoS mitigation techniques.

Quench: Shutdown the DDoS at the source
Shunt: Redirect the DDoS traffic to a mechanism that both absorb the traffic and filter the ‘real’ traffic and deliver the ‘real’ traffic to the site
Sink: Deploy enough hardware/software capacity to absorb a DDoS and continue application availability

Using techniques such as S/RTBH or flowspec to block DDoS directly northbound of the hosts emitting the attack traffic can be considered ‘stopping’ a DDoS attack. Personally, I tend to use the verb ‘squelch’ to describe mitigation at this point in the attack path.

Elsewhere in the attack path, the term ‘mitigate’ is what’s generally used.

When high-bandwidth/high-throughput DDoS attacks are mitigated at some point in the attack path, network operators often contact the peer/downstream/upstream networks from which the attack traffic is ingressing their network and request that the attack traffic be mitigated on those networks, and so on, and so forth, until the attack traffic is squelched nearer its origination point. This process takes time, however, and often doesn’t make it all the way down to the networks from which the attack traffic originated before the attack is over. Varying levels of responsiveness by network operators to such requests is also a consideration, as is the source-distribution of the attack, et. al.

The Internet never sleeps.

;>

Likewise!

Whichever of “mitigating”, “squelching”, “weathering” etc you wish to use, in the context of dealing with a DDoS by sending the load elsewhere, that’s what you’re doing. Ultimately, while a DDoS is in progress, bandwidth is getting consumed with malice aforethought, on every pipe between each attacking node and wherever you’re either redirecting it or sinking it. (Mmm; “sinking” is another good term, here.)

To actually “stop” a DDoS, in my view, requires that the bandwidth getting consumed in pursuance of the attack, stops getting consumed. This means stopping the participating nodes from emitting the traffic in the first place, or at least ensuring it gets sunk before it hits a pipe where bandwidth can be considered a scarce resource, such as a WAN or sub-gigabit LAN.

It’s also worth noting here, that DDoS attacks have collateral damage; unless you’re in the rare situation where there’s fine-grained DiffServ or some other bandwidth management running on every link between a DDoS-participating node and its target, other systems which need to make use of a pipe with DDoS traffic running down it, are going to see degraded performance.

If we’re splitting lexical hairs in discussing DDoS, too often we conflate all DDoS to attacks designed to overwhelm bandwidth. It’s as likely, if not moreso, to see volumetric attacks designed to overwhelm connection tables on network firewalls that will never sniff the bandwidth of the pipe to that data center. Or a volumetric attack designed to overwhelm the L7 request processing capacity of some server. Or a volumetric attack against the SSL processing capacity.

All “volumetric attacks” that may be delivered via distributed attack origins with the intent to cause service outage. Some of these attacks can be stopped, others squelched, some sunk, and so on. But there are no 4-step programs that will enable you to survive every instance unscathed.

And maybe there’s the word that captures all the methodologies, but isn’t nearly so marketing-friendly: “Survive a DDoS Attack”

The challenge with your definition, Chris, is that it strictly defines an attack as being the will of an attacker – so only an attacker can “stop” their will by calling it off. This is a very attacker-centric worldview.

From a defender’s standpoint, an attack is a vector, from an attacker to a target; and “stopping” the attack merely entails interrupting that vector between the adversary and their target; much like a levee “stops” a flood – it doesn’t negate the existentialism of the flood, but it keeps it from some target.

Now as Dave Walker notes, an attack might have bystanders who are hurt as collateral damage, who might continue to be hurt even as the attack is “stopped” by its target, who may disagree with the stoppage-nature of the defense.

But from a “sell to the target” approach, if you can keep the DDoS from reaching them, you’ve “stopped it” for them.