Analyser une attaque DDoS

Une attaque DDoS se manifeste par un trafic anormal visant votre IP publique ou votre service. HolyCloud applique une mitigation réseau en amont ; votre rôle consiste à constater l'incident, collecter des preuves et coopérer avec le support. Ce guide s'adresse aux administrateurs de VPS Linux et d'hébergement web.

Prérequis

• Accès SSH ou RDP au serveur (si encore joignable)
• Graphiques trafic dans l'espace client HolyCloud (si disponibles)
• Horodatage précis (fuseau Europe/Paris)

Voir aussi : Comprendre l'anti-DDoS HolyCloud.

Signes typiques d'une attaque

| Indicateur | Observation |

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

| Bande passante saturée | Interface à 100 %, latence extrême |

| Connexions massives | Milliers de SYN en SYN_RECV |

| UDP flood | Volume UDP vers port jeu/voice/DNS |

| HTTP flood | Requêtes GET/POST répétitives, User-Agent uniformes |

| Service up mais unreachable | Null route ou scrubbing côté opérateur |

Étape 1 : confirmer que c'est bien la cible

Depuis le VPS (Linux) :

uptime
ip -s link show eth0

Pic sur l'interface ? Comparez avec une baseline normale.

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

Nombre élevé de SYN_RECV → possible SYN flood.

Étape 2 : identifier le protocole et les 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 vers un port :

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

HTTP flood (échantillon) :

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

Comptez les IP sources :

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

Étape 3 : charge système

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

Si CPU/RAM restent bas mais le réseau explose, l'attaque est probablement réseau (L3/L4), pas applicatif.

Étape 4 : journal système et pare-feu

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

Pare-feu local (ne stoppe pas un gros DDoS amont, mais limite la casse) :

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

Étape 5 : espace client HolyCloud

1. VPS / Serveur dédié → graphiques bande passante.
2. Notez l'heure du pic et l'IP attaquée.
3. Vérifiez les notifications email (null route, mitigation).

Documenter pour le support

Préparez un rapport structuré :

IP impactée : 203.0.113.10
Début (CET) : 2026-06-20 14:32
Service : jeu / web / mail
Type observé : UDP 30120, ~800 Mbit/s
Impact : RDP inaccessible, HTTP 503
Actions client : tcpdump 2 min, ss -s joint

Pièces jointes utiles :

• Capture ss -s et ip -s link
• Extrait logs nginx (100 lignes autour du pic)
• Graphique bande passante panel

Mesures côté client (complément mitigation)

• Ne pas exposer d'IP inutiles ; utiliser CDN pour HTTP.
• Fermer ports non utilisés (pare-feu OS + panel HolyCloud).
• Jeux : limiter visibilité IP ; accepter offre avec anti-DDoS adapté UDP.
• Pendant l'attaque : éviter les redémarrages répétés (masquent les logs).

Rate-limit nginx (exemple zone — à adapter) :

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

Null route et GRE (rappel)

Si le support applique une null route, votre IP est volontairement injoignable jusqu'à la fin du pic. Ce n'est pas une panne disque.

Les offres GRE/scrubbing renvoient le trafic filtré — voir documentation tunnel GRE.

Dépannage post-attaque

| Situation | Action |

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

| IP toujours down après 1 h | Ticket — levée null route |

| Service lent | Redémarrer services ; vérifier connexions établies zombies |

| Faux positif | Pic légitime (TV, promo) — preuve logs légitimes |

ss -K dst 203.0.113.10  # prudence : tue connexions, à utiliser en maintenance

Besoin d'aide ?

Ouvrez un ticket prioritaire avec IP, horodatage CET, type de service et le rapport ci-dessus. HolyCloud ne peut pas analyser des logs sur votre poste local — joignez les extraits serveur.