> For the complete documentation index, see [llms.txt](https://docs.link11.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.link11.com/product-guides/network-ddos-v3/faq/how-detection-and-mitigation-work.md).

# How Detection and Mitigation Work

This page describes the technical process by which Network DDoS identifies and responds to attacks. For information about routing traffic into the system, see Architecture and Setup Options.

### Traffic Baseline

Network DDoS continuously builds and maintains a baseline of normal traffic behaviour for each protected prefix and for active destination IPs within it. The baseline captures:

* Traffic types (IP, TCP, UDP, ICMP, and others)
* Unique source counts and top talker sources
* ASNs and countries
* Ports and services each destination typically communicates on

The baseline updates continuously as traffic patterns evolve. No manual threshold configuration is required.

### Detection: Signals

Deviations from the baseline generate **signals**. A signal is an individual traffic anomaly — for example, a spike in unique source IPs, an elevated SYN ratio, or an unusual concentration of UDP traffic on a specific port. Signals are recorded and visible in the Explorer.

A signal alone does not trigger mitigation. Many legitimate traffic events produce individual anomalies without indicating an attack.

### Detection: High Quality Signals

When multiple correlated signals align to indicate a specific attack type, the system produces a **high quality signal** — a confirmed attack signature. For example:

* Elevated unique source count + high TCP SYN rate + unusual source port distribution → TCP SYN flood detected.
* Bandwidth spike concentrated on UDP port 123 + amplification-typical packet sizes → NTP amplification attack detected.

A high quality signal triggers the creation of an Attack Event with a unique Attack ID. Targeted mitigations are then activated.

### Mitigation: Targeted and Escalating

Only the mitigation strategies relevant to the detected attack vector are activated. A TCP SYN flood triggers TCP SYN mitigations only — UDP handlers, GRE processing, and other strategies remain off. This minimises the impact on legitimate traffic.

Within the activated strategies, the system uses an escalation ladder:

{% stepper %}
{% step %}

### Drop bad packets

Malformed packets, invalid protocol use, and fragmentation anomalies are dropped first — minimal impact on legitimate traffic.
{% endstep %}

{% step %}

### Block specific attack-associated ports

Traffic on the specific ports associated with the detected attack vector is blocked.
{% endstep %}

{% step %}

### Broaden port-level blocking

Port blocking is widened beyond the initial attack ports.
{% endstep %}

{% step %}

### Block at the protocol level

All traffic matching the attack protocol is blocked.
{% endstep %}

{% step %}

### Block specific source IPs

Individual source IPs contributing to the attack are blocked.
{% endstep %}

{% step %}

### Block source ASNs

Autonomous systems originating attack traffic are blocked.
{% endstep %}
{% endstepper %}

Each level must prove insufficient before the system escalates. The system also automatically de-escalates as the attack subsides.

### Known Legitimate Sources

Top legitimate sources are automatically identified from the traffic baseline and are never blocked, even during an active attack. The system monitors for low-and-slow ramp-up patterns to prevent attackers from gradually establishing themselves as known sources.

Administrators can supplement this with explicit Whitelist rules in Access Control.

### Cooldown

When traffic returns toward normal levels, the system enters a **cooldown period** rather than immediately disabling mitigations. This prevents premature ramp