DDoS analysis tools: what to run
during and after an attack

Back to Blog

Phase 1: During the Attack

During an active flood, your priorities are: confirm it is actually an attack, quantify the severity, identify the attack type quickly enough to apply a mitigation, and avoid doing anything that makes the server less stable. Running a full packet capture during a 400,000 PPS attack will exhaust your disk I/O and make things worse. Use lightweight tools that read from counters or sample traffic rather than capturing everything.

nload — Interface-level bandwidth in real time

nload is the fastest way to get a visual sense of current bandwidth on each interface. It requires almost no CPU and reads from kernel counters.

nload eth0 -u M

The -u M flag sets the unit to Mbps. You will see current, average, minimum, maximum, and total transfer for inbound and outbound. If inbound is pegged at or near your interface's rated speed, the attack may be saturating your uplink before mitigation is even possible. That is a transit provider problem, not a firewall problem.

iftop — Per-connection bandwidth breakdown

Once you know traffic is anomalous, iftop shows you the top source IPs by bandwidth consumption:

iftop -i eth0 -P -n -B

The -P flag shows port numbers, -n disables DNS resolution (essential during an attack — DNS lookups will time out and slow the display), and -B shows bytes instead of bits. Look for the top few source IPs. If a single IP or a small handful of IPs account for the majority of traffic, you have a simpler mitigation path.

ss — Socket state and connection counts

For TCP-based attacks, ss gives you a live view of socket states. During a SYN flood, your SYN_RECV count climbs rapidly:

# Count sockets by state
ss -s

# Show top source IPs in SYN_RECV state
ss -n state syn-recv | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

If ss -s shows tens of thousands of SYN_RECV sockets, your connection table is under pressure. The second command shows which source IPs are generating those half-open connections. During a SYN flood, you will often see thousands of different spoofed source IPs each contributing one or two SYN_RECV entries.

iptraf-ng — Protocol-level traffic breakdown

iptraf-ng gives you a real-time breakdown of traffic by protocol (TCP/UDP/ICMP) and by port. It is more useful than iftop when you need to understand the protocol mix rather than the per-IP breakdown:

iptraf-ng -i eth0

Navigate to IP traffic monitor. During a UDP flood, you will see UDP counts dominating. During a DNS amplification attack, you will see large UDP packets arriving from source port 53. This protocol-level view takes about 30 seconds to give you an accurate picture.

nethogs — Per-process bandwidth

nethogs is useful when you suspect a process on the server itself is generating attack traffic (compromised server, misconfigured script):

nethogs eth0

This shows bandwidth grouped by process and PID. If a PHP script or a background job is responsible for outbound traffic that is triggering upstream abuse complaints, nethogs will find it immediately.

Phase 2: Post-Mortem Analysis

After the attack ends, your goals shift from triage to understanding. What was the attack type? What were the source IPs? How long did it last, and what was the peak intensity? This data is needed for abuse reports, upstream mitigation requests, and improving your defenses.

tshark — Command-line Wireshark for large captures

Wireshark's GUI is impractical for multi-gigabyte PCAPs from a DDoS incident. tshark is the command-line equivalent and processes large files efficiently. Some essential one-liners:

# Top 20 source IPs by packet count
tshark -r attack.pcap -T fields -e ip.src \
  | sort | uniq -c | sort -rn | head -20

# Distribution of destination ports
tshark -r attack.pcap -T fields -e udp.dstport \
  | sort | uniq -c | sort -rn | head -20

# Average packet size
tshark -r attack.pcap -T fields -e frame.len \
  | awk '{s+=$1;c++} END {print s/c " bytes avg"}'

# Filter to just the attack traffic window
tshark -r attack.pcap -Y "frame.time >= \"2026-01-28 02:14:00\" \
  && frame.time <= \"2026-01-28 02:17:30\""

capinfos — PCAP statistics at a glance

Before digging into a PCAP, run capinfos to understand what you are working with:

capinfos attack.pcap

This prints the capture duration, total packets, total bytes, average PPS, and average Mbps. It takes under a second even on a 10GB file. The average PPS and Mbps numbers from capinfos are exactly what you need for an abuse report to your ISP or transit provider.

Wireshark display filters for DDoS traffic

When you do open a PCAP in Wireshark — ideally on a workstation, not the production server — these display filters isolate common attack patterns quickly:

# UDP flood - large packets to a specific port
udp.dstport == 27015 && udp.length > 500

# DNS amplification - responses from port 53 with TC flag
dns.flags.response == 1 && dns.flags.truncated == 1

# SYN flood - TCP SYN packets with no ACK
tcp.flags.syn == 1 && tcp.flags.ack == 0

# NTP amplification - mode 2 responses (large)
ntp.ctrl.monlist_response

# ICMP flood
icmp.type == 8 && frame.len > 100

ntopng — Flow-level analysis and geographic visualization

ntopng processes pcap files or live traffic and provides flow-level analysis with geographic source mapping. For large-scale attacks involving thousands of source IPs, the geographic distribution is often diagnostic. A UDP flood coming entirely from ASNs in specific countries is a different threat model than a globally distributed botnet attack.

ntopng -i attack.pcap --dont-change-user -d /tmp/ntopng-data

After processing, the web interface at port 3000 shows flow data, top talkers, and protocol breakdown. The AS-level distribution view is particularly useful for building upstream null-route or RTBH (remotely triggered blackhole) requests.

What Flowtriq Gives You Automatically vs What Still Needs CLI Tools

It is worth being honest about the division of labour here. Flowtriq's built-in analysis covers the high-value information automatically:

• Attack classification: UDP flood, SYN flood, DNS amplification, NTP amplification, ICMP flood, HTTP flood — identified within the first 2 seconds.
• Duration, peak PPS, peak Mbps: Logged automatically for every incident.
• PCAP capture: Flowtriq captures the first 60 seconds of attack traffic in a ring buffer. Download from the incident page without touching the server.
• Source IP distribution summary: The incident report shows whether the attack came from a small number of sources or a distributed botnet.
• Historical comparison: Whether this attack was larger or smaller than previous incidents on the same node.

What you still need CLI tools for: deep packet inspection of specific packet headers, filtering to exact traffic windows within a long capture, and custom flow analysis for unusual attack patterns that Flowtriq's classifier has not seen before. The combination of Flowtriq's automatic analysis and the CLI tools above covers the vast majority of post-incident investigation without requiring a dedicated SIEM or expensive flow analysis platform.

A Step-by-Step Analysis Workflow

Here is the sequence that covers most incidents efficiently:

1. During attack: Open Flowtriq dashboard. Check incident type and severity. If Critical, apply immediate mitigation (iptables rule or upstream null-route request).
2. During attack: Run nload eth0 -u M to confirm the PPS/BPS numbers Flowtriq is reporting. If your uplink is saturated, notify the transit provider immediately — server-side mitigation will not help.
3. During attack: Run ss -s if the attack type is SYN flood to monitor connection table pressure.
4. After attack: Download the PCAP from the Flowtriq incident page.
5. After attack: Run capinfos on the PCAP to get summary statistics for any abuse reports.
6. After attack: Run tshark top-source-IPs query. If 5 or fewer IPs account for more than 50% of traffic, submit abuse reports to their respective hosting providers via their ASN's abuse email (look up via whois).
7. After attack: If the attack was sophisticated or you are preparing a transit provider request, run ntopng against the PCAP for AS-level flow data.

Back to Blog

Related Articles