Automating the Response to a DDoS Attack: What Happens After an Attack Is Detected
DDoS Attack Detected. What Does Your System Do in the Next Few Seconds?
Conversations about anti-DDoS protection usually revolve around one question: how quickly the system detects an attack and sets up a filtering rule. That question makes sense, but for an operator's NOC team it rarely settles the matter. A generated FlowSpec rule or blackholing is usually the beginning of the procedure, not the end. Someone has to be notified, the incident has to be logged, sometimes the customer has to be switched to another IP address, and sometimes a script has to be run on an edge device.
In many networks these steps are performed by a human anyway. They receive an alert, log in to a panel, check what happened, and only then start the procedure. For an attack that lasts a dozen or so seconds, this delay is often longer than the detection and filtering time combined.
The system already knows what is happening; the problem is that nobody else does yet
At the moment an attack is detected, the anti-DDoS system has all the information needed for further action: it knows the victim's IP address, the protocols, the scale of the traffic and the exact moment the threshold was exceeded. The question is whether this knowledge ends with generating the filtering rule, or whether it can immediately be used to trigger something more.
In LiveShield, this is done by the event pipeline: a set of actions attached to specific events in the attack lifecycle, for example "Blackholing started" or "Blackholing stopped". To each of these events you can attach a call to your own script, with the attacked IP address passed as a parameter, or a webhook to a specified URL.
A real-life example: two thresholds, one automatic reaction
A typical configuration looks like this:
Pps/bps thresholds are set on a prefix. When they are exceeded, the system detects an attack with specific protocols and generates FlowSpec rules. In parallel, higher thresholds from the blackholing profile are checked; they can be set in total per IP or separately for individual protocols. If these higher thresholds are also exceeded, blackholing is triggered.
And this is where the pipeline comes in. When blackholing is invoked, a script attached to the "Blackholing started" event runs. It could be, for example, switching the customer's IP address to a backup one. When the attack subsides and blackholing is lifted, the "Blackholing stopped" event triggers the reverse action, restoring the original address.
The same scheme works when integrating with a scrubbing center. Instead of filtering traffic locally, the pipeline can redirect it to an external cleaning point when the attack escalates, and return to standard routing once it ends.
FlowSpec first, RTBH only when really needed
Separating detection thresholds from blackholing thresholds makes practical sense. The lower threshold triggers a precise FlowSpec rule, filtering traffic by specific parameters: protocol, port, flags. Only after the second, higher threshold is exceeded does blackholing of the entire prefix take place. Most attacks, the smaller and more predictable ones, are handled without losing legitimate traffic. RTBH remains the tool for situations in which continuing to carry traffic to a given address starts to threaten the stability of the whole network.
For addresses with a different risk profile, such as service servers that must have higher availability, the same mechanisms can be configured separately. It is enough to add them as a more specific subnet with its own set of thresholds.
Deploy a system for protection against DDoS attacks in your infrastructure. Contact us: office@liveshield.net
