Threat detection and mitigation - DDoS, spoofing, MITM

Requirement / business driver

Detect abuse and mitigate it without taking the service down with it - especially volumetric DDoS and spoofing.

Threats and counters

• DDoS (volumetric / protocol / application): mitigate with scrubbing (on-prem or cloud), RTBH (remote-triggered black hole via BGP), BGP Flowspec (granular drop/rate-limit rules), upstream rate-limiting, and capacity. Volumetric floods usually need upstream/cloud mitigation - you can't absorb them at your own edge.
• Spoofing: uRPF and edge anti-spoofing ACLs (Infrastructure hardening - control, management, and data plane); BCP38 ingress filtering.
• MITM: at L2, DAI / DHCP snooping / RA Guard (Layer 2 security); on the path, encryption (MACsec/IPsec/TLS).
• Evasion / botnet: NGFW + IPS signatures, DNS/URL filtering, and flow telemetry (NetFlow) for behavioural detection.

DoS fine print - reflection, SYN counters, ICMP doctrine, and the ISP contract

Four pieces of classic doctrine sharpen the DDoS story. Reflection: the smurf archetype - spoof the victim as source, bounce a query off a responder population, and the replies flood the victim - is the template every modern reflection/amplification attack follows; the counters are killing the responder role (no directed broadcast, hosts ignoring broadcast probes, rate-limiting the reflectable service) and killing the spoof at origin (BCP38/uRPF, above). SYN floods have two structural counters: SYN cookies on the host - the server keeps no state for a half-open connection, encoding what it needs into a cryptographically generated ISN and reconstructing it from the returning ACK - and TCP intercept/proxying in the network, which brokers the three-way handshake on the server's behalf once the embryonic-connection count crosses a threshold, so only completed handshakes ever reach the real server. ICMP: blocking it wholesale is the signature of inexperienced design - instead rate-limit it, deny ICMP fragments outright (legitimate ICMP is far too small to fragment), and at trust boundaries expressly permit a short type list - the echo pair plus the error types operations genuinely needs, with the PMTUD dependency as the canonical don't-break-this caveat (MTU, fragmentation, and PMTUD) - and deny the rest. And organisationally: volumetric response runs through the upstream, so agree the flooding playbook with the ISP in writing before the attack - which mitigations, triggered how, with what turnaround - because a contract negotiated mid-flood protects nobody.

Recommendation / justification

Detect with telemetry (Network management - traditional vs model-driven) and mitigate at the right place: volumetric DDoS upstream/cloud (RTBH/Flowspec/scrubbing), spoofing at the edge (uRPF/BCP38), MITM via L2 hardening + encryption. The design rule: push volumetric mitigation as far upstream as possible - filtering at your own door still saturates the pipe to it.

What would change this (mid-scenario twist)

• Internet-facing critical service -> cloud DDoS scrubbing + RTBH/Flowspec readiness.
• Spoofing/lateral concerns -> uRPF everywhere + L2 anti-MITM baseline.

Validation checks

• Is volumetric DDoS handled upstream (not just at the saturated edge)?
• Is there detection (flow telemetry) feeding the mitigation, and are RTBH/Flowspec pre-staged?

IPv6 / dual-stack note

DDoS/spoofing/MITM all apply to v6 - ensure uRPF, RTBH/Flowspec, and L2 protections cover both families.

Related

• BGP in enterprise design
• Perimeter security - firewalls and IPS-IDS
• Network management - traditional vs model-driven

Spaced repetition

Sources

• Cisco Press, Network Security Architectures (Convery) - reflection archetype, SYN-flood counters, ICMP filtering doctrine, ISP cooperation.
• Cisco Press, SCOR; BGP RTBH / Flowspec and DDoS mitigation guides.

domain: Core · blueprint-ref: Core 6.3.d Detect and mitigate common attacks · type: design-decision · status: complete · tags: [core, core/security, tradeoff/security, tradeoff/operability]