Détecter une attaque DDoS : quels signaux croiser ?

Définition du problème

Détecter un DDoS consiste à corréler les symptômes service avec des preuves réseau. Une seule métrique suffit rarement : un gros volume peut être légitime, et un petit flood haute PPS peut quand même casser l’infrastructure.

Le problème est aussi temporel. Si l’équipe confirme l’attaque seulement après le blackhole ou la panne totale, la disponibilité est déjà perdue. Le but est de déclencher l’analyse et la mitigation assez tôt.

Pourquoi la détection précoce compte

Une détection précoce réduit le downtime et évite les décisions paniques. Sans signaux clairs, les équipes redémarrent des serveurs, changent l’application ou bloquent de vrais utilisateurs pendant que l’attaque continue en amont.

Pour un hébergeur, cela protège aussi les autres clients. Pour un service gaming, cela préserve la confiance des joueurs. Pour une entreprise, cela évite qu’un incident technique devienne un problème commercial et réputationnel.

Ce qu’il faut surveiller

Surveillez Gbps, PPS, flows, destinations principales, distribution des sources, mix protocolaire, taux SYN, taux UDP, tailles de paquets, retransmissions, handshakes échoués et erreurs applicatives. La bonne vue est une timeline qui relie trafic réseau et impact service.

Les alertes doivent être différentes selon le service. Une plateforme web, un service DNS, un serveur Minecraft et un proxy FiveM n’ont pas le même comportement normal. Les baselines évitent les faux positifs et accélèrent la détection.

• détecter un DDoS exige de corréler trafic, erreurs applicatives, PPS, saturation et plaintes utilisateurs.

Cas concret

Une communauté gaming voit des joueurs timeout alors que le processus serveur tourne encore. Les graphes montrent un Gbps modéré mais une hausse PPS inhabituelle et des requêtes UDP répétées vers la même destination. Cela indique un flood plutôt qu’un simple bug applicatif.

Une plateforme B2B observe des handshakes TLS échoués et un CPU firewall élevé. L’application web n’est pas le premier goulot : il faut protéger l’edge TCP avant que l’application ne reçoive des sessions propres.

Erreurs fréquentes

La première erreur est d’attendre la panne totale pour agir. La deuxième est de regarder seulement la bande passante en ignorant PPS, connexions échouées et perte paquet.

Une autre erreur est de considérer chaque pic comme une attaque. Une bonne détection compare le trafic au comportement normal, à l’activité client, aux déploiements et aux événements de monitoring connus.