All DDoS Definitions
DDoS Testing Definition

Anomaly Detection

Anomaly detection is a behavioral defensive control, one of the detection methods a DDoS test is built to exercise before any filter can act. Instead of matching traffic against a list of known-bad patterns, it learns what normal looks like for a given service (the request rate, the protocol mix, the geographic spread, the ratio of new to returning clients) and flags traffic that departs from that learned baseline. The premise is simple: you cannot enumerate every attack in advance, but you can model normal and treat a large enough deviation from it as hostile.

Anomaly detection: model normal, flag the deviation Traffic per window vs learned baseline learned normal band anomaly time → Anomaly detector compares to baseline, flags deviation within band pass, treated as normal beyond band signal raised, mitigate The model that adapts to seasonal growth also adapts to a patient, low-and-slow attacker. A test measures detection latency and false-positive rate, not whether the feature is switched on. BlackNeuron
Diagram: anomaly detection learns a normal traffic band, passes traffic that stays inside it, and flags a spike that breaks out of the band as an anomaly

How it learns normal

Anomaly detection builds a statistical model of baseline traffic over rolling time windows. It tracks features per window (requests per second, unique source counts, URI distribution, TCP flag ratios, DNS query entropy) and computes an expected range for each, often with an exponentially weighted moving average so the model follows daily and weekly seasonality rather than a fixed number.

When a live measurement falls outside the modeled range by more than a set number of standard deviations, the detector raises a signal. That signal is what a downstream control acts on: a rate limit tightens, a challenge is issued, or traffic is diverted to a scrubbing path. The detector itself usually enforces nothing. It decides that something is wrong.

Three levels of sophistication

Not every system that claims anomaly detection does the same thing, and the differences matter under attack. The simplest is a static threshold: alert if requests per second cross a fixed number. It is trivial to configure and trivial to evade, because a fixed ceiling has no notion of what is normal for a Tuesday at 3am versus a Friday at noon.

Above that sits adaptive statistical modeling: a moving average with a standard-deviation band that shifts with the daily and weekly cycle, so the same absolute rate can be normal at peak and anomalous at trough. The most involved approaches are unsupervised: clustering or density models that learn the joint distribution of many features at once and flag a point that is improbable across all of them, catching traffic that looks ordinary on any single axis but impossible in combination.

A test is indifferent to which one is deployed until it produces attack traffic that is normal on rate, normal on geography, and normal on user-agent, all at once. That is where a single-feature threshold waves it through and a joint model does not.

Sensitivity is a tax you pay in both directions

The one knob that matters is sensitivity, and it trades two errors against each other. Set the deviation threshold tight and the model flags ordinary surges (a product launch, a marketing email, a news mention) as attacks, driving the false-positive rate up and shedding real users.

Set it loose and a slow, careful attack stays inside the envelope. A low-and-slow attack is built to exploit exactly this: it raises load gradually enough that each window looks like plausible growth, and the baseline drifts to accommodate it. The model that adapts to seasonality also adapts to a patient adversary.

Anomaly detection: baseline-conforming traffic passes, deviations are flagged incoming requests Anomaly detector flags deviation Origin normal traffic within baseline flagged as anomalous BlackNeuron
Animated anomaly detector sorting traffic: requests that match the learned baseline pass to the origin while a deviating burst is flagged and dropped

What a DDoS test actually measures

A test does not ask whether anomaly detection is enabled. It asks two questions the console cannot answer.

First, how long from the onset of a deviation to a raised signal: the detection latency, closely tied to mean time to detect. A model that averages over five-minute windows cannot flag a flood that saturates the origin in ninety seconds, no matter how sensitive its threshold.

Second, whether traffic engineered to look normal on every modeled feature still trips the detector, and whether an ordinary traffic spike does not. The gap between the moment a real attack becomes visible and the moment mitigation engages is pure exposure, and it is measurable.

2026-08-14T06:10:26.720103 image/svg+xml Matplotlib v3.5.1, https://matplotlib.org/ 0.0 2.5 5.0 7.5 10.0 12.5 15.0 17.5 20.0 Time (minutes) 0 500 1000 1500 2000 2500 3000 3500 Requests reaching backend (rps) deviation flagged mitigation engaged Simulated shape, not measured data Anomaly detection: the exposure window is the detect-to-mitigate gap detected, not yet blocked BlackNeuron
Requests reaching the backend during an attack: the shaded gap between when anomaly detection flags the deviation and when mitigation engages is the exposure window

Detection is the first link in the chain, and a chain that detects late fails late. Every stack claims to detect; the number that separates them is how long detection takes and how much legitimate traffic it burns to get there. For where detection sits inside a full defensive sequence, see DDoS resilience testing.