DDoS Incident Response Playbook for Network Engineers

A DDoS incident response playbook is a short, pre-agreed runbook that tells your on-call engineer what to do in the first 15 minutes of an attack: confirm it, classify it, pick a mitigation, tell people, and learn from it afterward. The five phases are detect, classify, mitigate, communicate and post-mortem, and each one needs an owner, a command or config you can paste, and a clear exit condition.

This guide is written for ISP, data center and hosting engineers. Examples use documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24) and private ASNs from AS64496-AS64511.

Before the incident: prerequisites

Most failed incident responses fail because of missing groundwork, not missing skill. Check these now, not during an attack:

• Flow export on every edge router (NetFlow v5/v9, IPFIX or sFlow) to a collector that can analyze per-IP and per-prefix traffic in near real time.
• Thresholds per destination, in both pps and bps. See our article on DDoS detection thresholds for tuning and hysteresis.
• A tested RTBH path with each upstream, including the exact blackhole community they accept.
• An escalation list: who can approve blackholing a customer IP, who talks to customers, who calls the upstream NOC.
• Out-of-band access to routers. If your management network rides the same congested link, you are blind.

Phase 1: Detect

Goal: confirm that the traffic is an attack, not a flash crowd or a broken backup job, and identify the target.

Triggers usually come from three places: flow-based alerts, interface utilization alarms, or customer tickets. Treat flow alerts as primary because they name the destination IP. Customer tickets are the slowest signal.

Quick confirmation checklist:

1. Which destination IP or prefix is receiving the traffic? One IP, several, or a whole /24 (see carpet bombing)?
2. Is the spike in pps, bps or both? High pps with modest bps usually means small-packet floods that kill routers and firewalls before links fill.
3. Is it still rising? Note the time the alert fired and the peak so far.
4. Is any link or device saturated? Check upstream interface counters and router CPU.

On a Linux host or mirror port, a fast sanity check:

# top source IPs hitting the victim in a 5000-packet sample
tcpdump -nn -i eth0 -c 5000 dst host 192.0.2.10 \
  | awk '{print $3}' | sed 's/\.[0-9]*$//' | sort | uniq -c | sort -rn | head

Do not spend more than a few minutes here. A wrong "maybe" costs more than a quick confirmation.

Phase 2: Classify

Classification decides which mitigation is safe. Gather four attributes from flow data: protocol, source port, destination port, packet size, plus the distribution of source IPs.

Two questions matter most:

• Can I describe the attack with a narrow match? If yes (for example UDP source port 11211), FlowSpec or an ACL can drop it without hurting legitimate traffic.
• Is the attack spread across many ports and protocols? Then narrow filters will not hold, and your choices are blackholing or diverting to scrubbing.

Phase 3: Mitigate

Use the least destructive action that protects the network. In order of increasing collateral damage:

1. Targeted filter (ACL or BGP FlowSpec) on a clear signature.
2. Diversion to scrubbing (on-prem or cloud) so clean traffic still reaches the customer.
3. RTBH (remotely triggered blackhole) of the victim IP. This protects everyone else but completes the attack for the victim.

RTBH examples

RFC 7999 defines the well-known BLACKHOLE community 65535:666. Many upstreams use their own community, so confirm with each provider.

Juniper:

set policy-options community BLACKHOLE members 65535:666
set routing-options static route 192.0.2.10/32 discard
set routing-options static route 192.0.2.10/32 community BLACKHOLE
set policy-options policy-statement RTBH-OUT term 1 from protocol static
set policy-options policy-statement RTBH-OUT term 1 from community BLACKHOLE
set policy-options policy-statement RTBH-OUT term 1 then accept
set protocols bgp group TRANSIT export RTBH-OUT

Cisco IOS:

ip route 192.0.2.10 255.255.255.255 Null0 tag 666
!
route-map RTBH-OUT permit 10
 match tag 666
 set community 65535:666 additive
!
router bgp 64500
 address-family ipv4
  redistribute static route-map RTBH-OUT
  neighbor 198.51.100.1 send-community

MikroTik (RouterOS v7):

/ip route add dst-address=192.0.2.10/32 blackhole comment="RTBH"

On MikroTik you also need a BGP output filter that attaches the community to that route. Test it in a lab first.

Guard rails for RTBH:

• Only accept /32 (IPv4) and /128 (IPv6) blackholes from your automation, never a whole /24 by accident.
• Set a maximum duration and remove the route automatically. Forgotten blackholes are a classic cause of "that customer has been offline since Tuesday."
• Tag blackhole routes with a no-export community so they stay inside the intended scope.

FlowSpec for narrow signatures

If your routers support it, announce a rule matching the attack, for example "UDP, source port 11211, destination 192.0.2.10, action discard" or rate-limit. Validate the match against flow data before sending. Start with rate-limit when unsure. We cover this in detail in our FlowSpec rules and safety article.

Diversion to scrubbing

If you have your own ASN and at least one /24, cloud scrubbing such as NixGuard Edge can announce your prefixes from the scrubbing edge and return clean traffic over a GRE tunnel with a BGP session inside. This can run always-on or on-demand. Keep the tunnel MTU and MSS settings correct, otherwise the "mitigated" traffic will still stall on large packets.

Verify the mitigation

Do not declare success because an alert cleared. Verify:

• Inbound pps/bps on the targeted prefix dropped as expected.
• Upstream interface utilization and router CPU normalized.
• Legitimate traffic (customer health checks, known client ASNs) still arrives.
• No unrelated customers lost service.

Phase 4: Communicate

Communication is part of mitigation. Assign one person as incident lead and one as communicator so the engineer on the router is not writing emails.

Internal updates every 15-30 minutes during the incident. Use a fixed template:

[Time UTC] Incident: DDoS against 192.0.2.10
Status: Mitigating / Monitoring / Resolved
Attack: UDP reflection, src port 11211, peak xx pps
Action taken: FlowSpec rate-limit announced at hh:mm
Customer impact: <what customers see>
Next update: hh:mm

Customer messaging should be short and factual: what they may be seeing, what you are doing, when the next update arrives. Avoid guessing at the attacker or promising a fix time you do not control. If you blackholed a customer IP, tell them explicitly that it was done to protect the network and how to request removal.

Upstream and peers: open a ticket early if you need them to filter or if the attack saturates the link before your edge. Include timestamps, target IP, protocol and source port, and sample flow records.

Phase 5: Post-mortem

Hold the review within a few days, while the details are fresh. Keep it blameless and focused on system gaps.

Capture:

• Timeline: attack start, alert time, confirmation, mitigation applied, mitigation effective, resolved.
• Time to detect and time to mitigate. These two numbers show whether your thresholds and runbook work.
• Attack profile: vectors, peak pps/bps, source diversity.
• Collateral damage: who was affected and for how long.
• What worked and what did not, for example a missing upstream community or a threshold that fired late.
• Action items with owners and dates: new thresholds, prefix-level rules, upstream agreements, automation, a scrubbing option for attacks that exceed your link capacity.

Store the flow records and alert history with the report. They are the best input for tuning thresholds.

Common mistakes

• Blackholing the wrong IP or a whole prefix because the alert was read quickly.
• Using FlowSpec rules that were never tested against real flow data.
• Relying on bps thresholds only, and missing small-packet floods.
• No automatic expiry for RTBH or FlowSpec announcements.
• Management access over the same link that is under attack.
• Not rehearsing. Run a tabletop exercise or a controlled RTBH test at least quarterly.

Where NixMon fits

NixMon ingests NetFlow v5/v9, IPFIX and sFlow, applies per-IP and per-prefix bps/pps thresholds with sub-second analytics, and can trigger BGP blackhole or FlowSpec announcements, or act through the NixGuard on-prem firewall or NixGuard Edge. Attack alerts also go to the iOS and Android apps, which helps the on-call engineer start phase 1 quickly. You can try it with the 15-day free trial, no credit card required, and compare detection time against your current process.