Every DDoS attack has a signature — a pattern of traffic behavior that distinguishes it from legitimate load. The problem is that engineers often see the downstream symptom (latency spike, CPU alarm, bandwidth alert) rather than the attack itself. By the time they correlate the symptom back to a cause, minutes have passed. The goal of this guide is to give you the mental model to move faster: see a symptom, immediately know what to look for, and act.
Symptom 1
Sudden bandwidth saturation — inbound link hits 95-100%
Likely cause
Volumetric UDP flood or UDP amplification attack. Large-packet UDP traffic (1400-1480 bytes) from spoofed or reflector source IPs saturates the transit link before the traffic even reaches your host.
What Flowtriq shows
Inbound BPS and PPS spike simultaneously. Classification: "UDP Flood" or "Amplification Attack." Source port distribution shows concentration on UDP/19 (Chargen), UDP/123 (NTP), UDP/11211 (Memcached), or UDP/53 (DNS) depending on the reflector type. Triggered PCAP will show oversized UDP datagrams and a small set of source IPs.
Mitigation
Host-level iptables rules won't help once the link is saturated — the traffic is filling your pipe before it reaches your server. Contact your upstream provider immediately for null routing or scrubbing. As a parallel action, apply
iptables -I INPUT -p udp --dport <your service port> -m hashlimit --hashlimit-upto 10000/sec --hashlimit-burst 20000 --hashlimit-mode srcip --hashlimit-name udp_limit -j ACCEPT; iptables -I INPUT -p udp --dport <port> -j DROP to rate-limit what does get through.
Symptom 2
CPU spike with low or normal bandwidth
Likely cause
SYN flood or connection exhaustion attack. The attacker sends a high rate of TCP SYN packets (commonly 50,000-500,000 per second) from spoofed source IPs. Each SYN causes the kernel to allocate a TCP control block, send a SYN-ACK, and wait for the final ACK that never arrives. The connection backlog fills; the kernel spends CPU maintaining these half-open states.
What Flowtriq shows
High PPS with low BPS — the packets are tiny (40-60 bytes each). Classification: "SYN Flood." The incident page shows PPS climbing while BPS remains low, a ratio that definitively rules out legitimate traffic. PCAP shows TCP SYN packets with no corresponding ACKs.
ss -s on the host will show SYN-RECV sockets numbering in the thousands.
Mitigation
Enable SYN cookies immediately:
sysctl -w net.ipv4.tcp_syncookies=1. This allows the kernel to handle SYN flood conditions without exhausting the SYN backlog. Also reduce the SYN-ACK retries: sysctl -w net.ipv4.tcp_synack_retries=1. Rate-limit new connections with iptables: iptables -I INPUT -p tcp --syn -m limit --limit 1000/s --limit-burst 3000 -j ACCEPT; iptables -I INPUT -p tcp --syn -j DROP.
Symptom recognized. Attack classified. Alert sent. In under 2 seconds.
Flowtriq detects attacks like this in under 2 seconds, classifies them automatically, and alerts your team instantly. 7-day free trial.
Start Free Trial →Symptom 3
A single port is being hammered — all other services are fine
Likely cause
Application-layer flood targeting a specific service, or botnet C2 activity scanning for a vulnerable service. Attackers increasingly target specific high-value ports — game server ports (UDP/27015), media streaming ports, or known API endpoints — to maximize disruption to that service without necessarily saturating the whole link.
What Flowtriq shows
Per-port traffic breakdown shows disproportionate packet volume to one destination port. Source IP distribution is typically broad (botnet) with each source contributing equally — a flat distribution is a botnet fingerprint. PCAP shows identical or nearly identical packet payloads from many sources, confirming automated tooling.
Mitigation
Rate-limit or temporarily block the targeted port from external sources while the service is not in use. If the service must remain available, use per-IP rate limiting with connlimit or hashlimit iptables modules. If it is a botnet scan, temporarily blocking the port and monitoring for lateral movement is appropriate.
Symptom 4
Traffic arriving on UDP/123 from a dozen source IPs
Likely cause
NTP amplification attack. The attacker sends NTP monlist requests (37 bytes) with your IP spoofed as the source to misconfigured NTP servers. Those servers respond to you with up to 482-byte monlist responses — a 13x amplification factor. You see inbound UDP/123 traffic from legitimate NTP server IPs that you never queried.
What Flowtriq shows
Classification: "NTP Amplification." Flowtriq identifies the source port pattern (all traffic arriving on UDP/123 from multiple IPs, none of which are your configured NTP servers). The incident shows the source IP list — these are real NTP servers being abused, not spoofed. PCAP shows NTP response packets containing monlist data.
Mitigation
Drop inbound UDP/123 traffic from addresses not in your authorized NTP server list:
iptables -I INPUT -p udp --sport 123 -m set ! --match-set ntp_servers src -j DROP. Your server should not be receiving NTP responses unless it sent a request first. Report the abused NTP servers to abuse contacts — they likely have monlist enabled and need to disable it.
Symptom 5
Massive inbound UDP traffic, all on port 53, large responses
Likely cause
DNS amplification attack. Attackers send small DNS queries (typically 40 bytes) for ANY or DNSKEY records to open resolvers, with your IP spoofed as source. The resolvers send large responses (up to 4,096 bytes with EDNS0) to your IP — an amplification factor of up to 100x.
What Flowtriq shows
Classification: "DNS Amplification." The PCAP in the incident shows DNS response packets (QR flag set, no corresponding query from your host) with large ANSWER sections. Source ports will be UDP/53 across many source IPs — the open resolvers being abused. Packet size distribution will show a spike at 1000-4000 bytes, unusually large for DNS.
Mitigation
Block inbound UDP/53 from sources you did not query. If you do not run a DNS resolver on this host, drop all inbound UDP/53:
iptables -I INPUT -p udp --sport 53 -j DROP. This is safe if your host uses an internal resolver or resolves via the OS to a separate DNS server not on this IP.
Symptom 6
Traffic peaks every few minutes, then drops — a pattern of waves
Likely cause
Pulsing flood (also called carpet bombing or pulse wave DDoS). The attacker sends bursts of high-volume traffic at regular intervals rather than a sustained flood. This is designed to exhaust your mitigation budget, prevent scrubbing services from engaging (many require sustained traffic to activate), and degrade service without triggering simple threshold-based alerts that require sustained high traffic.
What Flowtriq shows
The incident timeline shows a sawtooth or square-wave pattern in the BPS/PPS graph — this is characteristic of pulsing attacks and immediately distinguishable from legitimate traffic surges, which do not follow metronomic intervals. Flowtriq detects each pulse as a new anomaly within 2 seconds of onset, alerting before each wave causes service degradation.
Mitigation
Pulsing floods require proactive mitigation that stays in place between pulses — not reactive mitigation that races to engage after each wave starts. Pre-position upstream scrubbing or blackhole routing once the first pulse is detected. Use Flowtriq's alert webhooks to auto-trigger your mitigation provider's API when an attack is confirmed.
Symptom 7
One node in a cluster is being hit; the others are fine
Likely cause
Targeted attack on a specific IP. The attacker knows (or has discovered via DNS enumeration, BGP looking glasses, or connection tracing) the individual IP of the target server. Anycast or load-balanced setups do not fully protect individual nodes — the physical IP is always discoverable to a determined attacker.
What Flowtriq shows
Only the agent on the affected node triggers an incident. This is immediately obvious in the Flowtriq dashboard when you have multiple nodes monitored — the incident appears under one node while the others show normal traffic. The targeted nature of the attack is itself significant threat intelligence: the attacker has prior knowledge of your infrastructure.
Mitigation
Failover traffic to unaffected nodes if possible. Apply null routing for the targeted IP at your upstream provider. Consider IP rotation for the affected node after mitigation. Review how the IP was discovered — Shodan, DNS history, and SSL certificate transparency logs are common enumeration sources.
Symptom 8
Alert fires at 3am; traffic looks normal during business hours
Likely cause
Scheduled botnet attack timed for minimum staffing. This is a deliberate tactic — attackers know that incidents detected at 3am take longer to resolve because on-call engineers are slower to respond and upstream providers have reduced staffing. The attack may be a probe to test your detection and response capabilities before a larger attack during business hours.
What Flowtriq shows
Flowtriq's dynamic baselines learn that your 3am traffic should be very low, making even a modest attack clearly anomalous at that hour — traffic that would be unremarkable at peak hours triggers an alert at off-hours. The PagerDuty and SMS integrations ensure the alert reaches an on-call engineer within seconds regardless of the hour.
Mitigation
Configure escalation policies in Flowtriq to ensure off-hours alerts reach an on-call engineer directly, not just a Slack channel. Review the PCAP from the incident the following morning — even a short probe gives you attack signatures, source IP ranges, and botnet characteristics that can inform preemptive firewall rules.
Remember: the same underlying attack type can produce different symptoms depending on your infrastructure. A SYN flood against a node with SYN cookies enabled shows as high CPU but no SYN-RECV accumulation. A volumetric flood hitting a 10GbE node on a 1GbE uplink saturates the ISP side before the host sees any symptoms. Always correlate what Flowtriq's classification engine reports with your host-level observations to get the complete picture.
Protect your infrastructure with Flowtriq
Per-second DDoS detection, automatic attack classification, PCAP forensics, and instant multi-channel alerts. $9.99/node/month.
Start your free 7-day trial →