How to Report a DDoS Attack to Your ISP: Evidence, Templates, and Escalation Steps

A DDoS (Distributed Denial-of-Service) attack floods your server or network with traffic from many sources simultaneously, overwhelming your infrastructure until legitimate users can no longer reach your services. During an active attack, first contact your own host or ISP for mitigation. Reports to reflector operators or corroborated source networks can then support investigation; a packet’s apparent source alone does not establish responsibility. For a complete overview of the abuse reporting process, see my complete guide to reporting IP abuse.

In this guide, I walk through exactly how to identify a DDoS attack in your logs, collect the evidence an ISP abuse desk needs to act, and file a report that gets results rather than getting ignored.

How to Identify a DDoS Attack

Before you report anything, you need to confirm that what you are experiencing is actually a DDoS attack and not a traffic spike from legitimate users, a misconfigured monitoring bot, or a single-source DoS. Here are the indicators and commands I use to make that determination.

One important check first: if the heavy traffic is coming from a single IP or a small number of IPs, check the User-Agent string in your access logs before jumping to a DDoS conclusion. Aggressive web crawlers, SEO audit tools like Screaming Frog, or AI training bots like GPTBot and ClaudeBot, can generate thousands of requests per minute and look a lot like a denial-of-service attack. Look up the source IP with the IP Location tool to see if it belongs to a known crawling service. If it does, the fix is robots.txt or rate limiting, not an abuse report. See my guide to identifying and managing web crawlers for the full rundown.

Bandwidth and Connection Indicators

The first sign of a DDoS attack is usually one of these:

• Sudden bandwidth saturation: your network utilization jumps from normal levels to near-maximum capacity
• Connection table exhaustion: your firewall or load balancer runs out of connection tracking entries
• Service degradation without CPU cause: your application is unresponsive but CPU and memory are normal, indicating the bottleneck is network-level
• Massive spike in connections from diverse IPs: unlike a single-source DoS, DDoS traffic comes from hundreds or thousands of distinct source addresses

CLI Commands for Live Investigation

Use these commands to get a real-time picture of what is hitting your server:

# Count connections per source IP, sorted by volume
# IPv4 only: splitting on the first colon breaks IPv6 addresses, which
# contain colons themselves. For a dual-stack host use `ss` instead.
netstat -4 -ntu | awk 'NR>2 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# IPv4 + IPv6, splitting on the LAST colon so v6 addresses survive:
ss -Htn state established | awk '{print $4}' | sed 's/:[0-9]*$//' | sort | uniq -c | sort -rn | head -20

# Watch bandwidth per interface in real time
iftop -i eth0 -n

# Capture 60 seconds of traffic on port 80 for later analysis.
# Use `timeout` for a real time bound: tcpdump's -c flag counts PACKETS,
# not seconds, so `-c 100000` can finish in milliseconds under a flood.
timeout 60 tcpdump -i eth0 -w /tmp/ddos-capture-$(date +%Y%m%d-%H%M%S).pcap port 80

# Check SYN flood (half-open connections)
netstat -n | grep SYN_RECV | wc -l

# Monitor UDP traffic volume
tcpdump -i eth0 -n udp -c 1000 | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

Log Patterns That Confirm a DDoS

SYN flood (protocol attack). thousands of half-open connections from spoofed or diverse IPs:

$ netstat -n | grep SYN_RECV | wc -l
14832

HTTP flood (application layer). repetitive requests hitting the same endpoint:

203.0.113.45 - - [09/Apr/2025:14:22:01 +0000] "GET /api/search?q=test HTTP/1.1" 200 4521
198.51.100.78 - - [09/Apr/2025:14:22:01 +0000] "GET /api/search?q=test HTTP/1.1" 200 4521
192.0.2.201 - - [09/Apr/2025:14:22:01 +0000] "GET /api/search?q=test HTTP/1.1" 200 4521
# Thousands of identical requests from different IPs within the same second

UDP flood. massive volume of UDP packets from random ports:

$ tcpdump -i eth0 -n udp -c 10
14:22:03.445123 IP 203.0.113.12.41923 > 10.0.1.5.80: UDP, length 512
14:22:03.445124 IP 198.51.100.33.29471 > 10.0.1.5.80: UDP, length 512
14:22:03.445125 IP 192.0.2.88.55102 > 10.0.1.5.80: UDP, length 512
14:22:03.445126 IP 203.0.113.201.38291 > 10.0.1.5.80: UDP, length 512

If you see traffic coming from DNS resolvers on port 53, you may be the target of a DNS amplification attack, which exploits open resolvers to multiply attack traffic by 50-70x.

Evidence Gathering Checklist

ISP abuse desks receive hundreds of reports daily. The ones that get acted on quickly are the ones with clean, specific evidence. Before you write your report, gather the following:

• Packet captures (pcap files): capture at least 60 seconds of attack traffic with tcpdump. This is the single most important piece of evidence because it contains source IPs, packet sizes, protocols, and timing.
• Firewall and access logs: export the relevant time window from your firewall (iptables, pf, or cloud security group logs) and web server (nginx/Apache access logs).
• NetFlow or sFlow data: if your router supports it, NetFlow records provide aggregate traffic statistics without the overhead of full packet captures.
• Bandwidth graphs: screenshots or exports from your monitoring tool (Grafana, PRTG, Cacti) showing the traffic spike with clear timestamps.
• Timestamps in UTC: normalize all timestamps to UTC. ISPs operate across time zones, and ambiguous timestamps delay investigations.
• Top source IPs: extract and list the top 20-50 source IP addresses by packet or byte count from your captures.
• Target IP and port: your public IP address and the port(s) being targeted. Use What's My IP Address if you need to confirm your public-facing IP.
• Attack duration: start time, end time (or "ongoing"), and any intermittent patterns.

Save everything with UTC timestamps in the filenames. For example: ddos-capture-20250409-142200Z.pcap.

Finding the Abuse Contact for Attacking IPs

Once you have your list of top source IPs, you need to find out which ISPs or hosting providers own them. The fastest way to do this is with the IP Location tool on this site, paste any IP address and it returns the ASN, organization, ISP name, and abuse contact information.

For bulk lookups, use the whois command:

# Look up a single IP
whois 203.0.113.45 | grep -i abuse

# Batch lookup for top offending IPs
for ip in 203.0.113.45 198.51.100.78 192.0.2.201; do
  echo "=== $ip ==="
  whois $ip | grep -iE 'abuse|orgname|netname'
done

Most WHOIS records include an OrgAbuseEmail or abuse-mailbox field. You can also check the RIPE, ARIN, APNIC, LACNIC, or AFRINIC databases directly depending on the IP range.

Group the attacking IPs by ISP. If 200 of your top source IPs belong to the same hosting provider, send one consolidated report to that provider with all 200 IPs listed. This is far more effective than sending 200 individual reports.

Do not scan apparent source addresses to establish responsibility: spoofed addresses may name innocent systems, and open ports do not prove compromise. Preserve the traffic you received and let authorized network operators correlate it with their own flow and customer records.

DDoS Abuse Report Email Template

Here is a template I use for reporting DDoS attacks to ISP abuse desks. Copy it, fill in the placeholders, and attach your evidence files.

Subject: DDoS Attack Report — [ATTACK_TYPE] from your network [YOUR_ASN_REFERENCE]

Dear Abuse Team,

I am reporting a DDoS attack originating from IP addresses within your
network (AS[ATTACKER_ASN] / [ISP_NAME]).

ATTACK SUMMARY
- Target IP:        [YOUR_SERVER_IP]
- Target port(s):   [TARGET_PORTS]
- Attack type:      [ATTACK_TYPE: e.g., UDP flood / SYN flood / HTTP flood]
- Start time:       [START_TIME_UTC] UTC
- End time:         [END_TIME_UTC or "Ongoing"]
- Peak bandwidth:   [PEAK_BPS, e.g., 12 Gbps]
- Peak packet rate: [PEAK_PPS, e.g., 8.5 Mpps]

SOURCE IPs FROM YOUR NETWORK
[IP_1] — [PACKET_COUNT] packets / [BYTE_COUNT] bytes
[IP_2] — [PACKET_COUNT] packets / [BYTE_COUNT] bytes
[IP_3] — [PACKET_COUNT] packets / [BYTE_COUNT] bytes
(Full list attached in CSV format)

EVIDENCE ATTACHED
1. Packet capture: ddos-capture-[TIMESTAMP].pcap (60-second sample)
2. Source IP list:  attacking-ips-[ASN].csv
3. Bandwidth graph: bandwidth-spike-[TIMESTAMP].png

The attack is causing service disruption to our infrastructure. I
request that you investigate the listed source IPs and take appropriate
action to stop the malicious traffic.

Please confirm receipt of this report and provide a reference number
for tracking.

Regards,
[YOUR_NAME]
[YOUR_ORGANIZATION]
[YOUR_EMAIL]
[YOUR_PHONE — optional]

Tips for making the template effective:

• Include hard numbers (Gbps, Mpps, packet counts). ISPs prioritize reports with quantified impact.
• Attach evidence as files rather than pasting raw logs into the email body. Pcap files are the gold standard.
• Mention your own IP and ASN so the abuse team can verify you are the actual victim.
• Keep the tone factual and professional. Angry emails get deprioritized.

Where to Report a DDoS Attack

DDoS attacks warrant reporting to multiple parties depending on severity and duration. Here is where to send your reports, in priority order:

For botnet-driven DDoS attacks where the source IPs appear to be compromised home routers or IoT devices, also see my guide on reporting malware and botnet C2 traffic.

Sub-Scenarios: Reporting by Attack Type

Different DDoS attack types require slightly different evidence and reporting approaches. Here is what to focus on for each.

Volumetric Attacks (UDP/ICMP Flood)

Volumetric attacks overwhelm your bandwidth with sheer traffic volume, typically using UDP or ICMP packets.

Key evidence: Bandwidth graphs showing the spike, pcap showing UDP/ICMP packets from diverse sources, NetFlow data showing aggregate traffic volume. Mention the peak Gbps figure prominently. This is the metric ISPs care about for volumetric attacks.

Reporting note: A spoofed source prefix can belong to an innocent network; it does not identify the attacker’s network or prove that the visible ASN failed BCP 38. RFC 2827 explains this attribution problem. During an active attack, contact your own host or upstream for mitigation and path-based investigation. For reflection, observed reflector operators can also help stop their responses.

Protocol Attacks (SYN Flood, Ping of Death)

Protocol attacks exploit weaknesses in network protocols to exhaust connection state tables on firewalls, load balancers, and servers.

Key evidence: Connection table counts (netstat -n | grep SYN_RECV | wc -l), firewall logs showing dropped SYN packets, pcap filtered to show TCP SYN without corresponding ACKs. Report the rate of half-open connections per second.

Reporting note: SYN source addresses can be forged. Report the observed fields and the possibility of spoofing to your own provider; do not accuse the visible address owner of originating the traffic without corroboration.

Application Layer Attacks (HTTP Flood, Slowloris)

Application layer attacks target your web server with requests that appear legitimate but are designed to exhaust server resources.

Key evidence: Web server access logs showing the request pattern (identical URLs, unusual User-Agent strings, abnormal request rates per IP), HTTP status code distribution. These attacks are harder to prove because each individual request looks normal.

Reporting note: Application layer attacks often come from real compromised machines (botnets), not spoofed IPs. This means the source IPs in your logs are accurate, and the ISP can actually identify and notify the compromised customers. Mention specific request patterns, ISPs can correlate these across multiple abuse reports.

If you are seeing reconnaissance activity like port scanning before the DDoS, include that evidence too. Pre-attack scanning strengthens your report.

DNS Amplification

DNS amplification uses open resolvers to reflect and amplify traffic toward your server. The source IPs you see are the resolvers, not the attacker.

Key evidence: Pcap showing DNS response packets from port 53 that you never queried, the query names and types used, and the list of resolver IPs. For a full breakdown of this mechanism, see my DNS amplification attack guide.

Reporting note: Report to two parties: (1) the operators of the open resolvers being abused (so they can restrict recursive queries) and (2) the network allowing the spoofed queries to originate (if identifiable via NetFlow backtracking). Tools like the IP Location lookup can help you identify the organizations running the exploited resolvers.

What to Expect After Reporting

ISP abuse desks handle a high volume of reports, and response times vary widely. Here is a realistic timeline based on my experience:

Follow-up cadence I recommend:

1. After 24 hours: reply to the ticket asking for a status update. Reattach the original evidence.
2. After 72 hours with no response: escalate to the upstream transit provider. Include proof that you reported to the source ISP first.
3. After 7 days: file with your national CERT/CSIRT and, for serious attacks, law enforcement.
4. For ongoing attacks: update your original ticket every 24 hours with fresh evidence (new pcap captures, updated bandwidth graphs). This demonstrates the attack is continuing and raises the priority.

Some ISPs, particularly those in jurisdictions with weak abuse enforcement, may never respond. In those cases, the most practical solution is to block the entire ASN at your firewall or work with your DDoS mitigation provider to filter it.

Prevention and Mitigation Tips

While reporting is important for stopping active attacks and holding attackers accountable, you should also invest in proactive DDoS protection:

• DDoS mitigation services: Cloudflare, AWS Shield, Akamai Prolexic, and similar services can absorb volumetric attacks before they reach your infrastructure. Even the free tiers offer significant protection.
• Rate limiting: implement rate limiting at your web server, API gateway, and firewall levels. This blunts application-layer attacks.
• Anycast routing: if you operate your own network, anycast distributes incoming traffic across multiple points of presence, making it much harder for an attacker to saturate a single location.
• Connection limits: configure your firewall to limit the number of concurrent connections per source IP and the rate of new connections per second.
• SYN cookies: enable SYN cookies (net.ipv4.tcp_syncookies = 1 on Linux) to handle SYN floods without exhausting your connection table.
• Blackhole routing: work with your ISP in advance to set up remote-triggered blackhole (RTBH) routing, which lets you quickly null-route traffic to a targeted IP during an attack.
• Incident response plan: document your DDoS response runbook before an attack happens. Know who to call, what evidence to capture, and where to report. Having this ready cuts your response time from hours to minutes.

This article is part of the IP Abuse Reporting Guide. See also: Report Malware and Botnet C2 Traffic, Report Port Scanning and Network Reconnaissance.