By the time an interface utilization alert fires for a volumetric DDoS attack, the link is already saturated and the outage has started. The window for a useful response opened earlier, during the ramp, and closed while the polling interval was still counting.
Flow data changes the timing. Attacks have structural signatures visible in flow characteristics well before they consume the circuit: source count exploding, packet sizes converging, flow duration collapsing, source ports behaving in ways real clients do not. This page covers those signatures per attack class, threshold starting points, and how detection feeds a mitigation decision.
In this guide
- How volumetric, protocol, and application-layer attacks each appear in flow records.
- Threshold starting points for early detection, and how to distinguish an attack from a legitimate traffic surge.
- What flow-based detection contributes to mitigation, and where it stops.
Why utilization alerts arrive too late
Three timing problems compound.
Polling interval: SNMP utilization is typically polled every one to five minutes. An attack can saturate a 1 Gbps circuit in seconds, which means the first poll after onset already shows a fully congested link and the outage is underway.
Duplicate-inflated volume: Where several devices along one path all export flow for the same conversation, the collector receives multiple records describing a single transfer, and volume-based detections read a multiple of the real figure. Flow deduplication, which merges records matching on the same five-tuple within a time window, is a prerequisite for trusting any volume threshold. Without it, the first tuning session is spent raising thresholds to suppress phantom traffic.
Aggregate blindness: A utilization counter reports total throughput. It carries no information about whether that throughput comes from 50 sources or 50,000, which is the single most discriminating attack characteristic.
Saturation masks the ramp: Once the link is full, utilization sits at 100% regardless of attack volume. You lose visibility into whether the attack is growing, which matters for deciding whether to scrub.
Flow records address all three, because they carry per-conversation structure at whatever granularity the exporter provides. On sampled exporters, volumetric detection remains reliable precisely because sampling preserves proportions on high-volume events.
The three attack classes in flow data
| Class | Mechanism | Flow signature | Scale |
|---|---|---|---|
| Volumetric | Saturate the circuit | Source count spike, uniform packet sizes, very short flows, single destination | Gbps to Tbps |
| Protocol | Exhaust state tables on firewalls, load balancers, and servers | High flow rate with low byte counts, incomplete TCP handshakes, SYN flag imbalance | Packets per second matters more than bandwidth |
| Application layer | Exhaust application resources | Normal-looking sessions at abnormal rate, concentrated on expensive endpoints | Requests per second, modest bandwidth |
Attacks are frequently multi-vector, combining a volumetric flood to occupy the network team with an application-layer attack that does the actual damage. Detecting one and stopping investigation is a common and costly mistake.
Volumetric attacks
What they look like
Enormous inbound traffic toward one destination IP or a small range, sourced from a very large number of addresses.
The reflection and amplification variant deserves particular attention because it is both common and structurally obvious in flow data. The attacker sends spoofed requests to public servers running amplifying protocols, which reply to the victim with responses far larger than the requests.
Protocols historically abused for amplification include DNS (UDP 53), NTP (UDP 123, particularly the monlist command), memcached (UDP 11211), SSDP (UDP 1900), CLDAP (UDP 389), and Chargen (UDP 19). Amplification factors vary widely by protocol and by server configuration, and published figures should be treated as approximate. Memcached amplification in particular produced some of the largest recorded attacks.
Flow signatures for reflection attacks
- Inbound UDP traffic from a specific source port toward a single destination
- Source addresses spread across a very large number of distinct IPs, frequently thousands
- Highly uniform packet sizes, because the amplifying servers are all producing the same response
- No preceding outbound request from the victim, since the requests were spoofed
That last point is the highest-confidence discriminator. Legitimate DNS responses follow queries your resolvers sent. A flood of DNS responses with no matching outbound queries is definitionally reflected traffic.
Direct flood signatures
- Distinct source count rising by orders of magnitude within minutes
- Flow duration collapsing, as each source sends a small burst rather than holding a session
- Bytes per flow dropping sharply, with total volume rising
- Destination concentration on one address or a narrow range
Protocol attacks
SYN flood
The classic. Attacker sends TCP SYN packets and never completes the handshake, consuming connection table entries.
Flow signatures
- Very high count of short-lived TCP flows, each with minimal bytes
- SYN flags present without corresponding ACK completion, where TCP flag fields are exported
- Ratio of new flows to completed sessions collapsing
- Source addresses frequently spoofed, so distinct source count is very high and geographically incoherent
ACK and RST floods
Packets that do not correspond to any established session, aimed at forcing stateful devices to look up nonexistent entries.
Fragmentation attacks
Fragmented packets that consume reassembly resources. Visible in flow as fragment-related counters and unusual packet size distributions.
The key metric for this class is flows per second rather than bits per second. A protocol attack can take down a firewall while consuming a small fraction of link capacity, which means bandwidth-based alerting misses it entirely. If your monitoring only alerts on utilization, protocol attacks are invisible until the firewall stops passing traffic.
Application-layer attacks
What they are
HTTP request floods, slow-read and slow-post attacks, and targeted requests against expensive endpoints such as search functions or report generation.
Why flow detection is weaker here
These attacks use complete, legitimate-looking TCP sessions. Each individual flow is unremarkable, and volume may stay well within normal range. Flow data sees sessions and not the requests inside them.
What flow can still contribute
- Session count to a web server rising far above baseline while bytes per session stay normal or fall
- Source distribution differing from the server's usual client population, including unfamiliar ASNs or geographies
- Session duration distribution shifting, which is how slow-read attacks appear
- Connection concurrency per source exceeding what a human user produces
What is needed alongside
Web server logs, a web application firewall, and application performance metrics. Flow contributes context and does not carry the primary detection.
Detection thresholds worth starting from
These are illustrative starting points drawn from field practice. No industry standard sets them. Calibrate each against your own baselines before enabling it, and treat the multipliers as variables to fit rather than values to adopt.
- Source count deviation: Alert when distinct source IPs toward a single internal destination exceed 10 times that destination's baseline within a 1 minute window. This is the earliest reliable volumetric signal.
- Flow rate deviation: Alert when flows per second on an interface exceed 5 times the interface baseline for that hour of the week. Catches protocol attacks that bandwidth thresholds miss.
- Reflection signature: Alert on inbound UDP from source ports 53, 123, 11211, 1900, or 389 exceeding a small multiple of baseline, with no corresponding outbound request volume. High confidence, low false positive rate.
- Packet size uniformity: Alert when the standard deviation of packet size toward a destination collapses while flow count rises. Real traffic mixes packet sizes. Generated floods do not.
- Bytes per flow collapse: Alert when average bytes per flow toward a destination drops below a fraction of baseline while flow count rises sharply. Distinguishes a flood from a legitimate traffic surge.
- Subnet-aggregate volume: Alert when total inbound volume or flow count toward an entire subnet exceeds baseline, independent of any single destination. This is the threshold that catches carpet bombing, also called spread-spectrum attacks, where volume is distributed across hundreds of addresses so that no individual destination crosses a per-destination threshold while the aggregate uplink saturates. Every other threshold on this list is per-destination and would miss it.
- Geographic and ASN anomaly: Alert when the source ASN distribution for a service shifts substantially from its historical profile. Useful for services with a predictable audience, noisy for globally accessed ones.
Combining thresholds raises confidence considerably. Source count spike plus packet size uniformity plus bytes per flow collapse, occurring together, is a volumetric attack with very few alternative explanations.
From detection to mitigation
Detection matters because of what it enables in the next few minutes.
Characterize the attack
Mitigation choice depends on class, vector, volume, and source distribution. Flow provides all four immediately, which is what a scrubbing provider will ask for.
Decide on diversion
Cloud scrubbing services are effective and add latency and cost, so diversion is a decision rather than a default. Flow-based volume and growth trend inform whether the attack will exceed local capacity.
Apply local mitigation where feasible
For attacks within local capacity, options include rate limiting by source, ACLs against specific source ports or protocols, and remotely triggered black hole filtering (RTBH, described in RFC 5635) or BGP Flowspec (RFC 8955) to push filtering upstream toward the provider. Flow data supplies the specific match criteria these mechanisms need.
Preserve evidence
Retained flow supports post-incident analysis, provider discussions, and any law enforcement engagement.
Verify mitigation
After scrubbing engages, flow confirms whether attack traffic actually stopped reaching you or merely stopped being counted.
One operational note. RTBH drops all traffic to the targeted address, which completes the denial of service for that specific host while protecting everything else. It is a deliberate trade and should be a documented, pre-approved decision instead of one made under pressure at 3 AM.
Separating an attack from a legitimate surge
Product launches, news coverage, and marketing campaigns all produce sudden traffic increases. Four discriminators separate them from attacks.
| Characteristic | Legitimate surge | Attack |
|---|---|---|
| Bytes per session | Normal or higher, users load full pages | Collapsed, minimal payload per flow |
| Session completion | Handshakes complete, sessions run to normal duration | Incomplete handshakes, very short flows |
| Source distribution | Follows your usual audience geography and ASN mix | Unfamiliar ASNs, incoherent geography, spoofed sources |
| Ramp shape | Rises over minutes to hours, follows referral patterns | Near-instantaneous onset, frequently sustained flat |
Bytes per flow is the most reliable single discriminator. Real users consume content. Flood sources send packets.
What flow-based DDoS detection will not do
- It does not mitigate: Detection is the input to mitigation, which requires scrubbing capacity, upstream filtering, or provider action.
- It sees the attack only where you have visibility: An attack saturating your provider's link upstream of your router may never reach a device that exports flow. Provider-side detection covers this and yours does not.
- Application-layer detection is partial: Flow contributes context and cannot see request content or targeted endpoints.
- Sampled export delays small-scale detection: High-volume attacks remain visible under sampling. Low-rate application-layer attacks may not.
- Spoofed sources limit attribution: Source addresses in a volumetric attack are frequently forged, so the source list identifies reflectors rather than attackers.
DDoS detection with NetFlow Analyzer
ManageEngine NetFlow Analyzer analyzes flow characteristics continuously, surfacing structural attack signatures instead of waiting for a utilization threshold.
Feature highlights
- Flow deduplication: Duplicate records exported by multiple devices along the same path are merged before analysis, so volume-based thresholds measure actual traffic.
- Continuous stream analysis: Flow evaluated as it arrives for source count, flow rate, and packet size anomalies.
- Attack pattern detection: Recognition of flood, scan, and reflection signatures with severity classification.
- Baseline-relative alerting: Deviation measured against learned per-interface and per-destination profiles.
- Attack characterization reporting: Source distribution, protocol, port, and volume detail for provider escalation.
- Retained history: Post-incident reconstruction and evidence for provider and insurer discussions.
See the attack during the ramp, while a decision is still worth making.
Start your 30-day free trialFAQs
How does NetFlow detect a DDoS attack?
By flow structure rather than by bandwidth alone. Attacks produce a spike in distinct source addresses toward one destination, a collapse in bytes per flow, uniform packet sizes, very short flow durations, and in reflection attacks, inbound UDP from characteristic source ports with no matching outbound requests. These appear during the ramp, before utilization thresholds trigger.
Can flow data detect an attack before the link saturates?
What is a reflection amplification attack and how is it identified in flow?
Does traffic analysis stop a DDoS attack?
Why do bandwidth alerts miss protocol attacks?
By Shynu,
ManageEngine Team