What a DDoS Attack Looks Like Step by Step: From Detection to Mitigation

Most materials on DDoS protection describe the topic in general terms: "the system detects the attack and blocks it". In practice, between the first attack packet and its effective mitigation, several concrete technical steps take place, and how quickly and precisely they are carried out determines the real impact of the attack on the network. Below we break this process down into phases, as it looks in the environment of an ISP or data center operator.

Before we can even talk about detecting an attack, the protection system must know what traffic in a given network looks like under normal conditions, for individual IP addresses as well as entire subnets. Without this reference point, every decision about what is an anomaly and what is an ordinary traffic peak (e.g. the evening peak at an internet provider) would be guesswork. This stage happens in the background, continuously, regardless of whether an attack is under way.

A DDoS attack rarely shows a single, readable pattern. In practice it is most often one of several categories:

From the perspective of the victim's network, the first signal is usually a jump in the number of packets or sessions, a change in protocol distribution, or an unusual distribution of traffic across many addresses at once.

This is the moment when the quality of the protection system makes the biggest difference. Two approaches differ fundamentally in reaction time:

A threshold alone is not enough: effective detection must also distinguish an attack spread across many addresses from an ordinary increase in traffic across the whole network. This is where per-subnet aggregation comes in: the system must be able to combine hundreds of seemingly independent, small anomalies on individual IPs into one incident.

After detecting an anomaly, the system must decide how to respond to it. Two complementary mechanisms come into play here, both BGP-based:

BGP FlowSpec: distribution of precise filtering rules (e.g. blocking a specific protocol, port or packet pattern) directly to edge routers, without manual configuration of ACLs. For TCP/UDP attacks, the system analyzes sampled packets and generates a rule matched to the specific attack pattern. In practice this means blocking malicious traffic while preserving normal traffic to the same address and protocol.

Blackholing (RTBH): a more drastic mechanism in which traffic to the attacked address is directed nowhere. Effective and immediate, but at the cost of legitimate traffic to that address as well. Classic, full blackholing, however, has a clear cost-effectiveness limit: blocking one attacked IP address is an acceptable cost, but when the attack is spread across several hundred addresses in the same subnet (carpet bombing), blackholing the entire range means cutting off all customers in that subnet, in practice the same effect the attacker wanted to achieve, only carried out by the operator's own hands.

That is why, at volumes threatening link saturation, instead of blackholing the whole attacked range, selective blackholing is used: limited to the addresses actually attacked or a narrower subset of prefixes within the subnet, possibly announced only to selected BGP sessions (e.g. the specific upstream through which the attack arrives) instead of to all peers at once. As a result, traffic to addresses in the same subnet that are not actually the target of the attack remains untouched, and blackholing keeps its main advantage, immediacy, without having to cut off the entire address range.

A well-designed system does not automatically choose the most drastic option: it first tries for the narrowest possible FlowSpec rule and treats blackholing as a mechanism for situations in which precise matching cannot keep up with the scale of the attack.

Merely classifying "this is an attack" is not enough to apply a precise rule: you also need to know exactly what the traffic to be blocked looks like. Here most systems based on static signatures have a problem: a signature written for one variant of an attack will not catch a modified variant, and attackers modify their vectors over time to bypass known rules.

Instead of relying solely on ready-made signatures, the system analyzes sampled attack packets in real time and continuously builds its profile: protocol, ports, size and flags of packets, distribution of source addresses. The first rule is applied immediately, based on a preliminary classification (e.g. "block UDP flood to this address"), but in the following seconds it is refined as further samples arrive, so that in the end it covers the narrowest possible actual attack pattern rather than all traffic of a given protocol.

The same learning is responsible for tracking the attack over time: if the attacker changes the target or vector during the incident, the system updates the rule instead of sticking to the original classification. For carpet bombing attacks, this also translates into dynamically widening or narrowing the mask of the protected subnet, so as to follow the actual extent of the attack rather than its state in the first second.

The generated rule must reach the network infrastructure. This is done through a BGP session between the protection system and the operator's edge routers: FlowSpec rules or blackhole routes are propagated by the standard BGP mechanism, without having to log in to each device separately. This matters in networks with many points of presence (PoPs): a single decision by the protection system propagates to all relevant routers at the same time.

A rule applied in the first seconds is not final: as long as the incident lasts, the pattern-learning mechanism (Phase 3b) verifies and corrects it on an ongoing basis. This rules out a system that applies a rule once and "forgets" about the incident: filtering remains up to date with the actual behavior of the attack throughout its duration, and not only at the moment of detection.

In parallel with mitigation, the system should inform the appropriate people (e-mail, webhook), ideally with the ability to split notifications across different customer groups or prefixes, so that the NOC team does not have to manually filter which customer a given alarm concerns. For operators covered by the National Cybersecurity System/NIS2, it is also important that incident data (time, vector, volume) be available in a form that eases later reporting to the CSIRT. It is worth stressing: such a module supports the reporting process, but does not in itself replace a full NIS2 compliance program.

When traffic returns to the pre-attack profile, filtering rules should be withdrawn automatically. Keeping blackholing or narrow FlowSpec rules longer than necessary, for no reason, burdens the infrastructure and makes it harder to diagnose subsequent, unrelated events.

Effective DDoS protection is not a single feature but a chain of decisions made within seconds: traffic profile, detection, classification, learning the attack pattern, choosing between FlowSpec and blackholing, distributing rules, maintaining filtering matched to the changing vector, and finally withdrawing mitigation. Every link in this chain that works more slowly or less precisely translates into a longer service outage or a larger scope of blocked legitimate traffic.

A full description of the architecture, BGP configuration and filtering mechanisms can be found in the technical documentation: docs.liveshield.net. You can also try the system with no commitment in the demo version: demo.liveshield.net.