Investigate a DDoS Attack
Validate telemetry, read attack evidence, identify affected targets and sources, and manage the incident lifecycle.
On this page
Use Attacks and Analytics to decide whether an alert represents harmful traffic, a legitimate peak, an internal problem, or incomplete telemetry. Preserve evidence before considering a network-changing response.
Do not mitigate from a notification alone. Confirm the exact target, fresh telemetry, address family, observation window, and independent device or interface evidence first.
First five minutes
- Open the incident and set its lifecycle to Investigating.
- Confirm that the source is healthy and the last verified record time is current.
- Check the target IP, protected prefix, IP version, first-seen time, and confidence.
- Compare peak BPS, PPS, and FPS with the learned baseline and independent counters.
- Record customer or service impact and identify the on-call decision owner.
Read the attack evidence
| Evidence | What to verify |
|---|---|
| Timeline and peak | Whether the signal is sustained, repeated, or a one-sample burst, and which metric crossed policy. |
| Targets | The exact protected destination, associated device, subscriber, session, service, and site. |
| Sources | Top source IPs, their contribution, public origin ASN, and whether any source belongs to the tenant. |
| Protocols and ports | Whether the traffic resembles UDP amplification, TCP connection pressure, ICMP, or a legitimate application pattern. |
| Direction and exporter | Which telemetry source observed the traffic and whether it is inbound to or outbound from protected space. |
An internal source is labelled for possible self-DDoS, misconfiguration, or compromise investigation; it is not automatically declared malicious.
Use ownership and routing context carefully
Public address ownership is resolved through the authoritative APNIC, ARIN, RIPE NCC, LACNIC, or AFRINIC service. Community intelligence can add expiring context, but RIR ownership is not reputation and a community match never authorises mitigation.
When the local ASN and public protected prefixes are configured, Connectivity can show observed AS paths, RPKI validity, globally observed origins, and PeeringDB declarations. Route-leak or hijack labels require network-engineer validation; flow records alone cannot prove either condition.
Decide the incident state
- Investigating: evidence is still being validated.
- Monitoring: the event is understood and being watched without a current network change.
- Resolved: traffic and affected service remain stable after the response or natural end of the event.
- False positive: the traffic is legitimate or the policy did not represent normal operations.
Do not mark an incident resolved as soon as a connector accepts a request. Confirm the effect through the traffic series, device or provider state, and service checks.
Common false-positive patterns
- Software distribution, backups, speed tests, or live events creating expected volume.
- New CDN or peering traffic missing a local ASN/CIDR classification.
- A stale or duplicated exporter producing misleading rates.
- Thresholds learned during an unusually quiet period.
- Internal loops, compromised subscribers, or misconfiguration producing outbound floods.
Evidence handoff checklist
- Incident ID, target, address family, and protected prefix
- First seen, last seen, observation window, and current lifecycle
- Baseline and peak BPS/PPS/FPS
- Top sources, protocols, ports, exporter, and affected service
- Independent verification, proposed action, expected impact, duration, and rollback owner
If a response is justified, continue with Mitigation and recovery.