Why node-level detection catches
what network monitoring misses

Back to Blog

How Network-Level DDoS Detection Works

Traditional DDoS detection operates at the network layer. Routers and switches export sampled traffic metadata (NetFlow, sFlow, IPFIX) to a central collector. The collector aggregates these samples, builds traffic profiles, and fires alerts when traffic exceeds configured thresholds.

This approach was designed for backbone ISPs managing terabits of transit traffic. It works well for detecting large volumetric floods that saturate upstream links. But it was never designed for the kind of precision that modern infrastructure requires.

Here is what actually happens in a typical NetFlow-based detection pipeline:

1. The router samples 1 in every 1,000 to 1 in every 10,000 packets
2. Sampled packets are batched into flow records and exported every 30 to 60 seconds
3. The collector ingests flow records, aggregates by destination, and compares to baselines
4. If a threshold is exceeded, the collector raises an alert

From the moment an attack starts to the moment the alert fires, 60 to 120 seconds have elapsed. In that window, a 10 Gbps attack has already delivered 75 to 150 GB of traffic to your infrastructure.

How Node-Level Detection Works

Node-level detection takes a fundamentally different approach. Instead of sampling traffic at the network edge, a lightweight agent on each server reads kernel-level counters directly from /proc/net/dev and /proc/net/snmp every second.

These counters are not sampled. They represent every single packet the kernel has processed. Every SYN, every UDP datagram, every ICMP echo. The agent computes per-second deltas, compares them against dynamic baselines, and classifies anomalies using protocol-level ratios.

The result: detection in under 2 seconds, with attack classification (SYN flood, UDP flood, ICMP flood, DNS amplification, etc.) included in the first alert.

The Five Blind Spots of Network-Only Detection

1. Sampling hides low-volume, high-impact attacks

A targeted SYN flood at 50,000 PPS can exhaust a server's connection table and take it offline. But at a 1:4096 sampling rate on a router handling 2 million PPS of legitimate traffic, those 50,000 attack packets produce roughly 12 sampled records per export interval. That signal is invisible against the baseline noise.

At the node level, 50,000 PPS is unmistakable. The kernel counter TcpExtSyncookiesSent starts climbing, TcpExtListenDrops appears, and the agent classifies the attack within 1 second.

2. Export intervals create detection lag

NetFlow records are exported on a timer (typically 30 to 60 seconds) or when a flow expires. The collector processes records in batches. Even with aggressive configuration, the fastest practical detection time for a NetFlow-based system is 30 seconds. Most production deployments detect in 60 to 90 seconds.

Node-level agents read kernel counters every second. There is no export interval. There is no batching delay. The detection-to-alert latency is the time it takes to read /proc/net/dev, compute a delta, and send a webhook. That is typically under 2 seconds.

3. No protocol-level classification at the network edge

NetFlow records contain source/destination IP, ports, protocol number, byte count, and packet count. They do not contain payload data. A flow record for a UDP flood and a flow record for legitimate DNS traffic look structurally identical: both are UDP, both have packet counts, both have byte counts.

Node-level detection has access to kernel protocol counters that provide classification for free. The ratio of Udp NoPorts to Udp InDatagrams immediately distinguishes a random-port UDP flood from legitimate application traffic. Rising TcpExtSyncookiesSent confirms a SYN flood. These ratios do not exist in flow data.

4. No packet-level forensics

When an attack ends, the only evidence a NetFlow-based system can provide is aggregated flow statistics: total bytes, total packets, top source IPs (if the sampling happened to capture them). You cannot reconstruct the actual packets. You cannot analyze payloads. You cannot identify whether the traffic was spoofed, amplified, or botnet-driven.

A node-level agent can trigger a PCAP capture the moment an attack is detected. Full packet headers, payloads, timing data. This is the evidence your ISP needs to act, your security team needs to classify the threat, and your compliance team needs for audit trails.

5. No visibility into per-server impact

Network-level detection tells you that a destination IP is receiving anomalous traffic. It cannot tell you whether the server behind that IP is actually affected. A game server handling 80,000 PPS of legitimate player traffic looks identical to one receiving 80,000 PPS of attack traffic in flow data.

Node-level detection knows the difference because it sees kernel-level stress indicators: ring buffer drops, socket buffer errors, SYN backlog exhaustion, conntrack table saturation. These counters distinguish "receiving lots of traffic" from "under attack and degrading."

Side-by-Side Comparison

Capability	Network-Level (NetFlow/sFlow)	Node-Level (Kernel Counters)
Detection speed	30 to 120 seconds	1 to 2 seconds
Sampling	1:1,000 to 1:10,000	Every packet counted
Attack classification	IP/port heuristics only	Protocol-level kernel counters
Packet forensics (PCAP)	Not available	On-demand capture at detection
Server impact visibility	Traffic volume only	Kernel stress indicators (drops, backlog, conntrack)
Low-volume attack detection	Often missed due to sampling	Detected via protocol anomaly ratios
Deployment	Router/switch config + central collector	Lightweight agent per server
Cost	$10,000+/year for enterprise tools	$9.99/node/month

Why Detection Speed Matters More Than You Think

A 10 Gbps attack delivers 1.25 GB of data per second. In the 60-second window that a NetFlow-based system needs to detect the attack, 75 GB of attack traffic has already hit your infrastructure. If your server has a 1 Gbps NIC, it was saturated in the first second. The remaining 59 seconds of detection delay mean 59 seconds of complete downtime before any mitigation can begin.

With node-level detection firing in under 2 seconds, automated mitigation (iptables rules, BGP FlowSpec announcements, or cloud scrubbing activation) can begin immediately. The difference between 2-second and 60-second detection is not an incremental improvement. It is the difference between a blip and an outage.

Real-World Scenario: The 40k PPS SYN Flood

Consider a targeted SYN flood at 40,000 PPS directed at a single web server. The attack uses random source IPs (spoofed) and targets port 443.

What network-level detection sees: At a 1:4096 sampling rate, roughly 10 sampled SYN packets per 60-second export interval. The collector sees a slight uptick in TCP traffic to the destination IP. Depending on the baseline, this may or may not trigger an alert. If the server normally receives 20,000 legitimate HTTPS connections per minute, the sampled attack traffic is indistinguishable from a minor traffic increase.

What node-level detection sees: Within 1 second, the agent observes TcpExtSyncookiesSent jumping from 0 to 38,000 per second. TcpExtListenDrops starts incrementing. The SYN backlog on port 443 is full. The agent classifies this as a SYN flood, fires an alert with the exact PPS rate, and triggers an automatic PCAP capture.

By the time the NetFlow-based system has collected its first export, the node-level system has already classified the attack, alerted the team, captured forensic evidence, and (if auto-mitigation is configured) deployed iptables SYN rate-limiting rules.

Attacks That Network Monitoring Consistently Misses

Certain attack patterns are structurally invisible to sampled flow analysis:

• Low-and-slow SYN floods that stay below volumetric thresholds but exhaust connection state tables over minutes
• Application-layer attacks that generate legitimate-looking HTTP requests at rates too low for flow-based detection but high enough to overload specific endpoints
• Pulsing attacks that send traffic in short bursts (2 to 5 seconds on, 10 seconds off) designed to stay below the minimum export interval
• Multi-vector rotation where the attacker switches between UDP, TCP, and ICMP every 15 to 20 seconds, preventing any single protocol from breaching flow thresholds
• Same-protocol blending where attack traffic uses the same ports as legitimate services (e.g., UDP/53 floods against a DNS server)

Node-level detection catches all of these because it operates on complete kernel counter data, not sampled snapshots. A pulsing attack shows up as a per-second PPS spike. Multi-vector rotation shows up as shifting protocol ratios. Same-protocol blending shows up as anomalous Udp NoPorts or TcpExtListenDrops rates that deviate from the server's learned baseline.

What This Means for Your Defense Strategy

Network-level monitoring is not wrong. It serves a real purpose: aggregate visibility across an entire network, transit utilization tracking, and peering analysis. If you run an ISP or a large hosting operation, you need flow-based visibility for capacity planning and upstream coordination.

But for DDoS detection specifically, relying on network-level monitoring alone leaves critical gaps. The attacks that take servers offline in 2026 are not the 500 Gbps volumetric floods that light up every flow dashboard. They are the 40,000 PPS targeted floods that slip through sampling, evade fixed thresholds, and exhaust server resources before the flow collector has finished its first export.

Node-level detection closes those gaps. It gives you per-second visibility into what each server is actually experiencing, with protocol-level classification and packet forensics that no flow-based system can provide.

Back to Blog

Related Articles