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
| ------------ | ------------- |
|---|---|
| Saturated bandwidth | Interface at 100%, extreme latency |
| 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
- VPS / Dedicated server → bandwidth graphs.
- Note peak time and attacked IP.
- 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 -sandip -s linkcapture- 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
| ----------- | -------- |
|---|---|
| IP still down after 1 h | Ticket — null route lift |
| 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.