Node-level + network-level:
the complete DDoS defense stack

Back to Blog

Why Layered Detection Wins

DDoS attacks in 2026 do not fit into a single category. A volumetric flood that saturates your upstream link requires detection at the network edge. A targeted SYN flood at 40,000 PPS requires detection at the server kernel. A carpet bombing attack that distributes traffic across a /24 requires both perspectives simultaneously.

Teams that rely exclusively on network-level flow monitoring miss targeted attacks that fall below sampling thresholds. Teams that rely exclusively on node-level detection miss upstream saturation events where packets never reach the server. The complete defense uses both layers, each doing what it does best.

Layer 1: Network-Level Flow Monitoring

Network-level detection is your early warning for volumetric attacks that threaten aggregate infrastructure. When a 200 Gbps flood is heading toward your network, you need to know before it saturates the transit link and causes collateral damage to every server behind it. Flow data from edge routers provides this macro-level view.

The critical action at this layer is upstream mitigation: triggering BGP RTBH (remotely triggered blackhole), BGP FlowSpec rules, or cloud scrubbing center activation. These are network-level responses that require network-level visibility.

Layer 2: Node-Level Kernel Detection

Node-level detection is your precision layer. It answers questions that network-level tools cannot: What specific attack type is this? Which servers are actually affected? What does the packet payload look like? Is the server degrading or handling the load?

The actions at this layer include local firewall rules (iptables/nftables rate limiting), application-level responses (connection limits, request throttling), and escalation triggers that feed into the network layer's mitigation capabilities.

How the Layers Work Together

The real power of layered detection is not just parallel monitoring. It is the feedback loop between layers.

Scenario 1: Volumetric flood detected at network level

1. Network layer detects a 50 Gbps UDP flood toward your /24 via flow export. Alert fires at T+60s.
2. Node layer detected the same attack at T+1s on each affected server. By T+60s, it has already classified the attack (random-port UDP flood), captured PCAP, and deployed local iptables rate-limiting.
3. The network layer triggers BGP FlowSpec to drop the specific attack signature at the edge router.
4. Node-level agents confirm attack traffic has stopped reaching each server. Incident is closed with full forensic data from both layers.

Without node-level detection, the first 60 seconds have zero mitigation. With it, local firewall rules are active within 2 seconds, limiting damage while the network-level response kicks in.

Scenario 2: Targeted attack invisible to network layer

1. Node layer detects a 45,000 PPS SYN flood against a single web server at T+1s. The attack is classified and PCAP capture begins.
2. Network layer sees nothing unusual. The 45,000 PPS is below the flow sampling threshold's confidence interval for this destination.
3. The node-level agent triggers auto-escalation: first, local SYN rate-limiting via iptables. If the attack persists beyond the configured threshold, it escalates to BGP FlowSpec via API.
4. The network layer applies the FlowSpec rule at the edge, dropping SYN traffic matching the attack pattern before it reaches the server.

Without node-level detection, this attack goes undetected entirely. The server's connection table fills, legitimate users get connection timeouts, and the operations team does not find out until users complain.

Scenario 3: Carpet bombing attack

1. Node layer detects anomalies on 40+ servers in the same subnet simultaneously. Each reports a modest traffic increase (10 to 15 Mbps above baseline) with a mix of UDP and ICMP.
2. Network layer detects the aggregate: the /24's total inbound traffic has jumped by 500 Mbps, visible in flow data for the upstream interface.
3. The combination of per-server classification from the node layer and aggregate visibility from the network layer identifies the carpet bombing pattern within seconds.
4. Mitigation: network layer applies upstream rate-limiting for the /24's inbound traffic, while node-level agents apply local filtering per-server.

Neither layer alone catches this cleanly. The node layer sees each server's modest anomaly. The network layer sees the aggregate spike. Together, the pattern is unambiguous.

The Auto-Escalation Chain

The most effective layered defense is not just parallel monitoring with separate alert channels. It is an automated escalation chain that starts with the fastest, most surgical response and scales up only when needed.

1. Level 1: Local firewall (0 to 2 seconds) - The node-level agent detects the attack and immediately applies local iptables/nftables rules. SYN rate-limiting, UDP source filtering, ICMP throttling. This is the fastest possible response: kernel-level filtering on the target server itself.
2. Level 2: BGP FlowSpec (5 to 15 seconds) - If local filtering is not sufficient (attack volume exceeds the server's capacity to filter), the agent escalates to BGP FlowSpec. The edge router drops matching traffic before it reaches the server.
3. Level 3: RTBH blackhole (15 to 30 seconds) - If the attack is volumetric enough to threaten the transit link, RTBH blackholing drops all traffic to the target IP at the network edge. This sacrifices the target to protect the rest of the network.
4. Level 4: Cloud scrubbing (30 to 60 seconds) - For attacks that exceed local mitigation capacity, traffic is diverted to a cloud scrubbing center (Cloudflare Magic Transit, OVH VAC, Path.net) via BGP announcement changes.

Each level buys time for the next. Local firewall rules at T+2s keep the server functional while BGP FlowSpec is deployed. FlowSpec at T+10s handles the attack at the edge while cloud scrubbing activates. The entire chain runs automatically based on attack severity and duration thresholds.

Practical Deployment Architecture

Small hosting operation (5 to 50 servers)

• Node layer: Flowtriq agent on every server. Per-second detection with auto-escalation to local iptables. Alerts to Discord/Slack.
• Network layer: If you have your own ASN and BGP, enable sFlow on your edge router and run a lightweight collector. If you are behind a provider, rely on node-level detection and their upstream filtering.
• Escalation: Node agent auto-deploys local firewall rules. Manual BGP FlowSpec or RTBH for severe attacks via provider portal.

Mid-size infrastructure (50 to 500 servers)

• Node layer: Flowtriq on all servers with per-service baselines. Auto-escalation configured for local firewall and BGP FlowSpec.
• Network layer: sFlow/NetFlow from edge routers to a collector (Kentik, FastNetMon, or self-hosted). Transit utilization monitoring and aggregate anomaly detection.
• Escalation: Full 4-level auto-escalation. Cloud scrubbing pre-configured with BGP sessions to at least one provider.

Large network (ISP / hosting provider / 500+ servers)

• Node layer: Flowtriq on customer-facing servers and infrastructure nodes. White-label dashboards per customer. Automated PCAP capture for evidence collection.
• Network layer: Full NetFlow/IPFIX from all edge and core routers. Arbor Sightline or equivalent for network-wide visibility. Peering and transit analysis.
• Escalation: Automated FlowSpec deployment to all edge routers. Multiple scrubbing center partnerships with automated failover. Per-customer escalation policies.

What Each Layer Should Not Try to Do

Layered detection works when each layer stays in its lane:

• Network-level tools should not try to detect per-server targeted attacks. Reducing sampling rates to catch them creates CPU and memory pressure on routers and floods collectors with data.
• Node-level tools should not try to detect upstream link saturation. If the transit link is full, packets are being dropped before they reach the server. The agent sees packet loss, but cannot determine whether the cause is upstream saturation or local NIC overload without network-level context.
• Neither layer should duplicate the other's alerting. Coordinate alert channels so that a single attack does not generate redundant notifications from both systems.

Measuring Detection Coverage

After deploying both layers, measure your detection coverage by attack type:

• Volumetric floods (10+ Gbps): Should be detected by both layers. Network layer detects via flow data; node layer detects via PPS spike. Both should alert within their respective latencies.
• Targeted floods (sub-sampling-threshold): Should be detected by node layer only. If you are seeing these in flow data, your sampling rate may be more aggressive than you think.
• Pulsing attacks: Node layer should catch every burst. Network layer will miss bursts shorter than the export interval.
• Carpet bombing: Node layer catches per-server anomalies. Network layer catches aggregate anomaly. Both should correlate.
• Upstream saturation: Network layer detects via interface utilization. Node layer sees increased packet loss and retransmissions. Both should alert.

If you find attack types that neither layer detects, you have a gap to close. In practice, the combination of per-second node-level detection and flow-based network monitoring covers the full spectrum of DDoS attack patterns seen in production.

Back to Blog

Related Articles