Analyze a DDoS attack

A DDoS attack shows up as abnormal traffic targeting your public IP or service. HolyCloud applies upstream network mitigation; your role is to confirm the incident, collect evidence, and cooperate with support. This guide is for Linux VPS and web hosting administrators.

Prerequisites

• SSH or RDP access to the server (if still reachable)
• Traffic graphs in the HolyCloud client area (if available)
• Precise timestamp (Europe/Paris timezone)

See also: Understanding HolyCloud anti-DDoS.

Typical attack signs

| Indicator | Observation |

|------------|-------------|

| Saturated bandwidth | Interface at 100%, extreme latency |

| Mass connections | Thousands of SYN in SYN_RECV |

| UDP flood | UDP volume to game/voice/DNS port |

| HTTP flood | Repeated GET/POST, uniform User-Agents |

| Service up but unreachable | Null route or operator-side scrubbing |

Step 1: confirm you are the target

From the VPS (Linux):

uptime
ip -s link show eth0

Spike on the interface? Compare with a normal baseline.

ss -s
ss -tan state syn-recv | wc -l

High SYN_RECV count → possible SYN flood.

Step 2: identify protocol and ports

ss -tunlp | head -50
sudo tcpdump -i eth0 -c 200 -nn 'icmp or udp or tcp port 80 or tcp port 443'

UDP dominant on one port:

sudo tcpdump -i eth0 -nn udp and port 30120 -c 100

HTTP flood (sample):

sudo tail -f /var/log/nginx/access.log
# or Apache: /var/log/apache2/access.log

Count source IPs:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Step 3: system load

top -b -n 1 | head -20
vmstat 1 5
free -h

If CPU/RAM stay low but network explodes, the attack is likely network (L3/L4), not application-level.

Step 4: system journal and firewall

journalctl -k --since "30 min ago" | tail -50
dmesg -T | tail -30

Local firewall (does not stop large upstream DDoS, but limits damage):

sudo nft list ruleset | head -80
# or iptables -L -n -v

Step 5: HolyCloud client area

1. VPS / Dedicated server → bandwidth graphs.
2. Note peak time and attacked IP.
3. Check email notifications (null route, mitigation).

Document for support

Prepare a structured report:

Impacted IP: 203.0.113.10
Start (CET): 2026-06-20 14:32
Service: game / web / mail
Observed type: UDP 30120, ~800 Mbit/s
Impact: RDP unreachable, HTTP 503
Client actions: 2 min tcpdump, ss -s attached

Useful attachments:

• ss -s and ip -s link capture
• Nginx log excerpt (100 lines around peak)
• Panel bandwidth graph

Client-side measures (complement to mitigation)

• Do not expose unnecessary IPs; use a CDN for HTTP.
• Close unused ports (OS firewall + HolyCloud panel).
• Games: limit IP visibility; choose an offer with suitable UDP anti-DDoS.
• During attack: avoid repeated reboots (they hide logs).

Nginx rate-limit (example zone — adapt):

limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
limit_req zone=one burst=20 nodelay;

Null route and GRE (reminder)

If support applies a null route, your IP is intentionally unreachable until the peak ends. This is not a disk failure.

GRE/scrubbing offers return filtered traffic — see GRE tunnel documentation.

Post-attack troubleshooting

| Situation | Action |

|-----------|--------|

| IP still down after 1 h | Ticket — null route lift |

| Slow service | Restart services; check zombie established connections |

| False positive | Legitimate spike (TV, promo) — prove legitimate logs |

ss -K dst 203.0.113.10  # caution: kills connections, use in maintenance

Need help?

Open a priority ticket with IP, CET timestamp, service type, and the report above. HolyCloud cannot analyze logs on your local PC — attach server excerpts.