IPFYI

Active DDoS Attack Response

Advanced Security

Your server or network is under an active Distributed Denial-of-Service attack. Legitimate traffic cannot reach your services because attack traffic is saturating bandwidth, exhausting connection tables, or overwhelming application-layer resources. Every minute of downtime costs revenue and erodes user trust.

Symptoms

  • ⚠ Server or network unreachable — ping timeouts and HTTP connection refused
  • ⚠ Network interface showing near-100% utilisation (Gbps-level inbound traffic)
  • ⚠ Firewall/router logs flooded with packets from thousands of source IPs
  • ⚠ CPU usage at 100% on the network interrupt and softirq kernel threads
  • ⚠ Application logs stop growing because the process cannot accept new connections
  • ⚠ Upstream provider notifies you of traffic anomaly or begins null-routing your IP

Possible Root Causes

  • • Volumetric attack: botnet sending massive UDP/ICMP flood to saturate upstream bandwidth
  • • SYN flood: half-open TCP connections exhausting the server's connection table (syncookies disabled)
  • • DNS/NTP/memcached amplification: attacker spoofs victim's IP to trigger large amplified responses
  • • Application-layer (L7) HTTP flood: high request rate targeting expensive endpoints (search, login)
  • • Unmitigated exposure: no upstream DDoS scrubbing service (Cloudflare, AWS Shield) in front of origin

Diagnosis Steps

1. Identify attack type and traffic volume

# Check current interface traffic rates (requires nload or iftop)
sudo nload eth0
sudo iftop -i eth0 -n

# If those aren't available, use /proc/net/dev
cat /proc/net/dev | grep eth0   # Bytes in/out — run twice 1s apart to see rate

# Count packets per second arriving on the interface
sudo tcpdump -i eth0 -nn -q 2>/dev/null | head -1000 | wc -l  # rough pps estimate

2. Identify the attack vector

# SYN flood: look for excessive half-open connections
ss -s   # Summary: show SYN-RECV count — normal is <100, attack = tens of thousands

# UDP flood / amplification: count UDP packet destinations
sudo tcpdump -i eth0 -nn -c 10000 udp 2>/dev/null | awk '{print $5}' | cut -d. -f5 | sort | uniq -c | sort -rn | head -10

# HTTP/application-layer flood: count requests per source IP from access log
sudo tail -10000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# DNS amplification: check if you have an open resolver being abused
sudo tcpdump -i eth0 -nn port 53 -c 1000 2>/dev/null | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -10

3. Identify source IP patterns

# Top source IPs (may be spoofed in volumetric attacks)
sudo tcpdump -i eth0 -nn -c 50000 2>/dev/null | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -30

# Check if attack is from a single ASN (use whois on top IPs)
whois 198.51.100.0 | grep -i "org-name\|netname\|country"

4. Check current firewall and connection state

# Count states (SYN_RECV spike = SYN flood)
ss -s

# Check iptables hit counters
sudo iptables -L -n -v | head -30

# Check if upstream null-route is active
ip route show | grep blackhole

Solution

Immediate triage (first 5 minutes)

# Enable SYN cookies to resist SYN flood
echo 1 | sudo tee /proc/sys/net/ipv4/tcp_syncookies

# Increase connection backlog limits
echo 65535 | sudo tee /proc/sys/net/core/somaxconn

# Drop packets from obvious attack sources quickly
sudo iptables -A INPUT -s ATTACKER_IP_RANGE/24 -j DROP

# Rate-limit ICMP globally
sudo iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 10/s -j ACCEPT
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

SYN flood mitigation

# iptables SYN rate limiting
sudo iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j ACCEPT
sudo iptables -A INPUT -p tcp --syn -j DROP

# Or use SYNPROXY (kernel 3.12+) for transparent SYN validation
sudo iptables -t raw -A PREROUTING -p tcp --syn -j CT --notrack
sudo iptables -A INPUT -p tcp --syn -m state --state UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
sudo iptables -A INPUT -m state --state INVALID -j DROP

HTTP flood mitigation (application layer)

# Nginx rate limiting (add to server block, reload nginx)
# limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
# limit_req zone=one burst=20 nodelay;

# Block obvious bot signatures
sudo grep -h "" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10 \
  | awk '{print $2}' | xargs -I{} sudo iptables -A INPUT -s {} -j DROP

Escalate to upstream/CDN scrubbing

  • Cloudflare: Enable 'Under Attack Mode' in the Cloudflare dashboard — adds a JS challenge to all visitors.
  • AWS Shield Advanced: Contact AWS support to activate enhanced DDoS response and Route 53 failover.
  • Contact your ISP/datacenter: Request upstream null-routing for the target IP and failover to a clean IP.

Prevention

  • Put a DDoS scrubbing proxy in front of your origin: Cloudflare, AWS CloudFront, or Akamai absorb volumetric attacks before traffic reaches your server — your server IP should never be exposed in DNS.
  • Enable SYN cookies permanently: Add net.ipv4.tcp_syncookies = 1 to /etc/sysctl.conf and apply with sysctl -p.
  • Close unnecessary UDP ports: Disable NTP amplification (restrict default noquery in ntp.conf) and DNS recursion (recursion no; in BIND).
  • Rate-limit at the CDN/WAF layer: Configure request-rate rules per IP at the CDN edge — much cheaper than blocking at origin.
  • Prepare a runbook: Document escalation contacts (ISP NOC, CDN support), pre-written iptables drop rules, and a secondary origin IP ready to swap to during an incident.

Related Protocols

TCP UDP ICMP HTTP DNS NTP

Related Terms

ddos syn-flood amplification-attack firewall botnet

More in Security

BGP Prefix Hijacking Detection Advanced Detecting and Responding to Port Scans Intermediate Expired SSL Certificate in Production Beginner IP Address Blacklisted on RBL Intermediate Open DNS Resolver Being Abused Intermediate SSH Brute-Force Attack Detection Intermediate