Le trafic monte soudainement en flèche, les pages tournent, les API expirent — ces symptômes peuvent être une promo réussie ou un DDoS. La différence compte, car elle décide si vous dépensez le mauvais budget : traitez une attaque comme un problème de montée en charge et la bande passante achetée est pulvérisée en une seconde ; traitez un pic comme une attaque et vous bloquez les vrais utilisateurs et blessez la conversion. Voici un diagnostic pratique en trois axes.
Axe 1 : D'où vient le trafic — dispersion des sources
C'est le découpage le plus rapide.
- Trafic normal : concentré sur votre vraie base d'utilisateurs — mêmes régions, mêmes réseaux (ASN), mêmes heures d'activité. Vos tables de connexions ou flux montrent une distribution d'IP « visages familiers ».
- Trafic DDoS : vient de milliers de blocs réseau inconnus, souvent à travers de nombreux pays et ASN bizarres. Quelques IP vous frappant à haute fréquence ressemblent plutôt à un robot ou un abus unique, pas à une attaque distribuée.
Vérifiez l'intuition : si « le volume de requêtes monte en flèche » et la dispersion des IP sources monte en flèche ensemble, ce n'est presque certainement pas humain.
Axe 2 : À quoi ressemble le trafic — signature protocole et paquets
Le trafic métier normal est surtout du HTTP/HTTPS avec un mélange de protocoles fluide. Surveillez ces formes :
- UDP / ICMP lourd : vous êtes un service web pourtant noyé dans UDP ou ICMP — volumétrique ou réflexion/amplification classique (services ouverts comme NTP, DNS, SSDP, Memcached abusés pour multiplier le trafic 50x ou plus).
- Déséquilibre SYN / ACK : la bande passante n'est pas pleine, mais SYN_RECV s'accumule et la table de connexions est épuisée — attaque protocole ; pare-feux et répartiteurs de charge tombent d'abord.
- Requêtes qui « paraissent parfaitement normales » : toutes les GET/POST valides, mais martelant un point coûteux (recherche, connexion, captcha) — CC de couche applicative, quasi invisible de la seule forme du trafic, capturée seulement par les anomalies de coût et les règles comportementales.
Axe 3 : Ce qu'il a fait au business — corrélation
Cet axe décide à quel point vous devriez vous inquiéter. Comparez avec ce tableau :
| Métrique | Variation normale | Attaque soupçonnée |
|---|---|---|
| Volume de requêtes | lié à une campagne, explicable | hausse inexpliquée 10x+ |
| Taux d'erreur | faible et stable | pic de 5xx / expirations |
| IP sources | votre vraie base d'utilisateurs | grand volume de blocs réseau inconnus |
| Connexions | correspond à l'échelle des utilisateurs | table de connexions au maximum |
| commandes / requêtes | conserve son ratio normal | requêtes en hausse, conversions plates |
La clé : si « la hausse de requêtes » est accompagnée d'erreurs en hausse + sources dispersées + ratio de conversion en baisse, c'est une attaque, pas un pic.
Trois classes d'attaque, comment les distinguer
- Volumétrique : bande passante saturée, sortie près de son plafond. UDP / réflexion-amplification ; une seule sortie ne peut simplement pas l'absorber — le plus visible, et le plus brutal.
- Protocole : la bande passante peut être correcte, mais les tables de connexions/sessions ou l'état du pare-feu sont épuisés par les SYN / ACK floods. Le serveur « n'est pas complètement hors ligne mais totalement non réactif » est généralement celui-là.
- Couche applicative (CC) : le trafic paraît normal mais brûle sans relâche la base, la connexion ou la recherche. Le plus dur à repérer d'un coup d'œil car chaque requête est légitime — seules les « anomalies de coût » et les règles comportementales le capturent.
Checklist de confirmation en 60 secondes
- Voyez-vous « sources dispersées + erreurs en hausse + bande passante ou connexions saturées » toutes en même temps ?
- Au même moment, les vrais utilisateurs sont-ils totalement incapables de vous joindre (pas seulement lents) ?
- Après avoir limité le débit d'une seule IP, la pression globale baisse-t-elle nettement ? (Si oui, c'est probablement un abus unique ; si non, probablement distribué.)
- Le mélange de protocoles montre-t-il un UDP / SYN lourd ne correspondant pas à votre type d'activité ?
Si les trois premiers sont touchés, vous pouvez basicement l'appeler une attaque DDoS ou CC. Une fois confirmé, passez à Votre site est sous une attaque DDoS : plan de riposte en 15 minutes.
Pourquoi confirmer « une minute plus tôt »
Confirmez une minute plus tôt, intégrez le scrubbing une minute plus tôt, perdez une minute de moins. Beaucoup d'équipes s'attardent dans le débogage « mon code est-il cassé ? » et ne réalisent qu'une demi-heure plus tard que c'est une attaque — et cette demi-heure de commandes et de joueurs ne revient pas. Si vous évaluez encore la protection, voyez Protection DDoS gratuite ou pro : que choisir, ou contactez-nous pour une évaluation préliminaire gratuite.