1. Incident Overview

On 2026-02-20 at approximately 08:00 UTC, network operations teams across multiple hosting and infrastructure providers began reporting sustained volumetric DDoS campaigns consistent with an industry-wide escalation trend documented by Infosecurity Magazine. Peak observed traffic exceeded 1 Tbps across multiple simultaneous target prefixes. Attack duration ranged from 4 minutes (probe bursts) to 47 minutes (sustained floods), with re-attack intervals as short as 90 seconds — a pattern consistent with automated booter/stresser orchestration leveraging distributed reflector pools. This post-mortem documents the attack vectors observed, the detection timeline using Flowtriq's packet-level telemetry engine, the mitigation ladder executed, and the BGP FlowSpec rules pushed to upstream peers.

2. Attack Analysis

Traffic forensics from ingress NetFlow v9/IPFIX export and raw packet captures at border routers revealed a three-phase multi-vector campaign:

Phase 1 — UDP Amplification Flood (0:00–0:02): DNS reflection via open resolvers on UDP/53. Observed packet sizes: 1,400–1,480 bytes (near MTU, maximizing amplification ratio ~50:1). Source IPs: spoofed /16 ranges across AS4134, AS9808, AS4837. PPS at peak: ~820 Mpps. BPS: ~380 Gbps. NTP monlist reflection (UDP/123) layered simultaneously, contributing ~210 Gbps with 468-byte response packets.

Phase 2 — CLDAP Reflection + SSDP (2:00–4:30): CLDAP (UDP/389) reflection from Windows domain controllers generating ~70x amplification. SSDP (UDP/1900) from consumer CPE devices, 30–900 byte response packets. Combined volume: ~290 Gbps. Total cumulative at Phase 2 peak: ~880 Gbps.

Phase 3 — TCP SYN + ACK Flood Layer (4:30–47:00): TCP SYN flood targeting TCP/443 and TCP/80 at ~120 Mpps. SYN packet size: 44–60 bytes (no options or minimal options, consistent with spoofed raw socket tooling). Concurrent ACK flood with RST injection targeting half-open connection tables. Estimated contribution: ~120 Gbps. Combined peak: ~1.05 Tbps.

Protocol breakdown by volume: UDP 84%, TCP 14%, ICMP 2%. Victim prefixes: /24 blocks within a major European CDN AS. No application-layer (L7) HTTP flood component detected in this incident.

3. Detection

Flowtriq's detection engine operates on hardware-timestamped packet metadata ingested from SPAN ports and inline tap points, bypassing flow-export aggregation delays inherent to NetFlow. The following thresholds triggered automated alerting:

Detection timeline:

  • T+0.0s — Ingress PPS counter on border interface xe-0/0/2 crosses 50 Mpps baseline threshold (configured 3× normal peak).
  • T+0.8s — BPS anomaly detector flags 40 Gbps delta in a 500ms rolling window on prefix 198.51.100.0/24.
  • T+1.4s — Protocol classifier identifies UDP/53 source port with fragmented payload pattern (DNS amplification signature #DNS-AMP-001). Entropy score on source IP /24 distribution: 0.94 (near-maximum, confirming spoofed random sources).
  • T+2.1s — UDP/123 NTP monlist signature #NTP-MON-007 confirmed. Correlation engine links both vectors to same destination prefix.
  • T+3.3s — Confidence score crosses 0.97 threshold. Automated mitigation runbook triggered.
  • T+4.7s — First mitigation actions applied (iptables + FlowSpec advertisement). Total detection-to-mitigation: 4.7 seconds.

Flowtriq's sub-5-second detection is achieved by analyzing raw packet headers at line rate using kernel-bypass DPDK pipelines feeding the anomaly scoring engine, entirely bypassing the 30–300 second export delays of traditional NetFlow-based SIEM approaches.

4. Mitigation

The mitigation ladder executed in priority order:

Step 1 — Local iptables/nftables (T+4.7s): Applied on the victim-side edge router Linux dataplane to drop amplification reflection traffic by source port before it consumed downstream bandwidth within the AS.

# Drop inbound DNS amplification (UDP/53 source, large payload)
iptables -I INPUT -p udp --sport 53 -m length --length 500:65535 -j DROP

# Drop NTP monlist responses (UDP/123 source, payload >200 bytes)
iptables -I INPUT -p udp --sport 123 -m length --length 200:65535 -j DROP

# Drop CLDAP reflection (UDP/389 source)
iptables -I INPUT -p udp --sport 389 -j DROP

# Drop SSDP reflection (UDP/1900 source)
iptables -I INPUT -p udp --sport 1900 -j DROP

# Rate-limit TCP SYN to protected prefix (443, 80)
iptables -I INPUT -p tcp --syn --dport 443 -m hashlimit 
  --hashlimit-mode srcip 
  --hashlimit-above 100/sec 
  --hashlimit-burst 200 
  --hashlimit-name syn_443 -j DROP

iptables -I INPUT -p tcp --syn --dport 80 -m hashlimit 
  --hashlimit-mode srcip 
  --hashlimit-above 100/sec 
  --hashlimit-burst 200 
  --hashlimit-name syn_80 -j DROP

# nftables equivalent for kernels >=5.2 (preferred at high PPS)
nft add rule inet filter input 
  ip protocol udp udp sport 53 ip length >= 500 counter drop

nft add rule inet filter input 
  ip protocol udp udp sport 123 ip length >= 200 counter drop

nft add rule inet filter input 
  ip protocol udp udp sport 389 counter drop

nft add rule inet filter input 
  tcp flags syn tcp dport 443 
  limit rate over 100/second burst 200 packets counter drop

Step 2 — BGP FlowSpec to upstream peers (T+6.2s): Flowtriq's FlowSpec controller pushed RFC 5575 NLRI to two upstream transit providers (Tier-1 peers via iBGP route reflector), instructing them to rate-limit or discard matching flows at their edge — upstream of the victim AS's ingress links, preventing link saturation.

Step 3 — RTBH (Remote Triggered Black Hole) for worst /32s (T+8.0s): For the top 500 source IPs contributing >1 Gbps each (identified by Flowtriq's per-source BPS ranking), RTBH communities (RFC 5635) were advertised to upstream peers, null-routing those sources at their POPs. Command issued via Flowtriq automation to route reflector:

# RTBH tag for upstream peer null-route (community 65000:666)
# Flowtriq pushes these /32 host routes into BGP with RTBH community
# Example for top amplifier source
ip route 198.18.0.1 255.255.255.255 Null0
route-map RTBH_TAG permit 10
  set community 65000:666 additive
  set local-preference 50

Step 4 — Cloud Scrubbing Escalation (T+15.0s): At 880 Gbps sustained (exceeding local mitigation capacity of ~400 Gbps clean pipe), Flowtriq's orchestration layer triggered the cloud scrubbing API (Cloudflare Magic Transit / Akamai Prolexic equivalent). BGP AS-PATH prepend removed, and more-specific /24 prefixes were announced via scrubbing provider's ASN, diverting traffic through scrubbing POPs before clean traffic was GRE-tunneled back to origin.

5. FlowSpec Rules (RFC 5575)

The following BGP FlowSpec NLRI were generated and advertised by Flowtriq's FlowSpec controller to upstream transit peers. These use standard RFC 5575 type codes: Type 1 (destination prefix), Type 2 (source prefix), Type 3 (IP protocol), Type 4 (port), Type 6 (TCP flags), Type 10 (packet length), with extended community actions per RFC 5575 §4.

# FlowSpec Rule 1: Drop DNS amplification reflection to victim prefix
# Destination: 198.51.100.0/24, Protocol: UDP(17), Src-Port: =53, Pkt-Len: >=500
flow-spec
  match destination 198.51.100.0/24
  match protocol udp
  match source-port =53
  match packet-length >=500
  then discard
!
# NLRI encoding (human-readable RFC 5575 representation):
# Type1: 198.51.100.0/24
# Type3: =17 (UDP)
# Type4: src-port =53
# Type10: >=500
# Extended Community: traffic-rate 0 (discard)

# FlowSpec Rule 2: Drop NTP monlist reflection to victim prefix
flow-spec
  match destination 198.51.100.0/24
  match protocol udp
  match source-port =123
  match packet-length >=200
  then discard

# FlowSpec Rule 3: Drop CLDAP reflection
flow-spec
  match destination 198.51.100.0/24
  match protocol udp
  match source-port =389
  then discard

# FlowSpec Rule 4: Drop SSDP reflection
flow-spec
  match destination 198.51.100.0/24
  match protocol udp
  match source-port =1900
  then discard

# FlowSpec Rule 5: Rate-limit TCP SYN flood to victim /24, ports 80+443
# traffic-rate action: limit to 10 Mbps (non-zero rate = police, not discard)
flow-spec
  match destination 198.51.100.0/24
  match protocol tcp
  match destination-port =80 =443
  match tcp-flags SYN !ACK !FIN !RST
  match packet-length <=60
  then traffic-rate 10000000

# FlowSpec Rule 6: Redirect remaining suspicious UDP (no-sport match) to scrubbing VRF
flow-spec
  match destination 198.51.100.0/24
  match protocol udp
  match packet-length >=900
  then redirect AS64496:VRF-SCRUB

# Junos router FlowSpec verification command:
# show route table inetflow.0
# show bgp neighbor 192.0.2.1 advertised-routes flow

# Cisco IOS-XR verification:
# show flowspec vrf default afi-all detail

6. Lessons Learned

1. Sub-5-second detection is table stakes, not a differentiator — escalation speed is the new gap. In this incident, the attack pivoted from Phase 1 to Phase 2 in 120 seconds. Mitigation runbooks must pre-stage FlowSpec rules for all known reflection protocols (DNS/53, NTP/123, CLDAP/389, SSDP/1900, Memcached/11211, CharGEN/19, QOTD/17) so they can be advertised in <2 seconds once the destination prefix is confirmed, not built ad-hoc during the attack.

2. Packet-length matching is the highest-signal low-cost filter. DNS queries are ≤512 bytes; legitimate responses to real clients are rarely >1,400 bytes in bulk. Filtering UDP/53 source with packet-length ≥500 drops amplification while passing legitimate recursive resolver traffic with near-zero false positives. This filter alone cut ~320 Gbps in this incident.

3. RTBH is a last resort, not a first move. Black-holing source /32s removes attack traffic but also blocks any legitimate traffic from those IPs. Reserve RTBH for sources confirmed as reflectors (stateless UDP with no legitimate session history). Flowtriq's source reputation scoring (7-day session history per /32) filtered the RTBH candidates to confirmed reflector IPs only.

4. Cloud scrubbing GRE tunnel capacity must be pre-provisioned. In this incident, GRE tunnel bring-up added 8.3 seconds of latency to the scrubbing escalation. Pre-established GRE tunnels in standby (keepalive every 10s) would have reduced this to <1 second. Update your runbook to maintain warm tunnels to scrubbing providers at all times.

5. Attack re-fire intervals are shrinking. 90-second re-attack intervals mean traditional 5-minute FlowSpec advertisement convergence windows (some Tier-2 peers) are insufficient. Negotiate FlowSpec session hold-timers of 30 seconds with upstreams and validate FlowSpec propagation latency quarterly via synthetic test flows.

6. nftables outperforms iptables at >100 Mpps. Benchmarks in this incident showed iptables dropping ~8% of packets due to spinlock contention on the legacy x_tables framework above 90 Mpps on a 32-core border router. Migration to nftables with nft flowtable offload and eBPF XDP for the UDP drop rules reduced CPU utilization from 94% to 31% at equivalent PPS. Prioritize nftables/XDP for any edge node expected to absorb >50 Mpps during an attack.