Attaque DDoS définition : types, signes et protection

Une attaque par déni de service distribué vise à rendre un site, une API ou un service réseau indisponible. La requête « attaque ddos definition » revient souvent, mais la définition seule ne suffit pas : pour réagir, il faut distinguer les familles d’attaques et repérer les signaux visibles dans les journaux, les connexions et la bande passante.

Ce guide relie les notions de base à des indices observables sur un serveur. Il reste centré sur le DDoS, sans se transformer en guide général de durcissement.

Définition d’une attaque DDoS

Une attaque DDoS, pour Distributed Denial of Service, consiste à saturer une ressource en envoyant un volume massif de trafic ou de requêtes depuis plusieurs sources. L’objectif n’est pas forcément d’entrer dans le système, mais d’empêcher les utilisateurs légitimes d’accéder au service.

Dans la pratique, la cible peut être la connexion internet, un équipement réseau, la pile TCP/IP, un serveur web ou une application. Le résultat observable varie selon le type d’attaque : latence forte, erreurs 502 ou 503, coupures intermittentes, timeouts, ou service joignable mais inutilisable.

Le sujet s’inscrit dans une démarche plus large de Sécurité, mais un DDoS a ses mécanismes, ses signes et ses réponses immédiates.

Différence entre DoS et DDoS

Un DoS vient en général d’une source unique ou d’un nombre limité de sources. Un DDoS distribue la charge sur un grand nombre de machines, souvent compromises, parfois relayées par des services exposés sur internet. Cette distribution rend le filtrage plus difficile, car le trafic paraît provenir de nombreux points d’origine.

Autre différence concrète : dans un DoS simple, bloquer une adresse IP peut suffire. Dans un DDoS, cette réponse est souvent insuffisante, car les adresses changent ou sont trop nombreuses. Le travail consiste alors à filtrer par comportement, protocole, route HTTP, taux de requêtes, ou à absorber la charge en amont.

Les mesures de base de durcissement ne se limitent pas au DDoS, d’où l’intérêt de séparer ce sujet des mesures essentielles pour sécuriser un serveur.

Comment fonctionne une attaque DDoS

Le principe est simple : l’attaquant cherche un point de saturation, puis l’alimente avec assez de trafic ou de requêtes pour dépasser la capacité disponible. Cette capacité peut être celle du lien réseau, du pare-feu, du noyau, du serveur web, du pool d’applications, de la base de données, ou d’un endpoint précis.

Le trafic utilisé dépend de l’objectif. Certaines attaques envoient un très grand volume de paquets pour épuiser la bande passante. D’autres exploitent le fonctionnement des protocoles, par exemple en ouvrant ou en maintenant un grand nombre de connexions. D’autres encore ciblent l’application avec des requêtes HTTP ou API qui paraissent légitimes mais coûtent cher à traiter.

Quand une attaque ddos en cours touche l’application, le réseau peut sembler « tenir », alors que le serveur devient lent sous l’effet de requêtes coûteuses. À l’inverse, lors d’une saturation volumétrique, le serveur n’a parfois même plus l’occasion de journaliser correctement les événements, car le lien en amont est déjà plein.

Les trois grandes familles à distinguer

On regroupe classiquement les attaques DDoS en trois familles.

Volumétrique

La cible principale est la bande passante. Le symptôme typique est une montée brutale du trafic entrant ou sortant jusqu’à la saturation du lien. Côté serveur, les journaux applicatifs peuvent être peu parlants, car le problème se produit avant le traitement normal des requêtes.

Protocolaire

La cible est la pile réseau ou les équipements intermédiaires. Le but est d’épuiser les tables d’état, les files d’attente de connexions ou les ressources nécessaires au traitement des paquets. Ici, on voit souvent une hausse anormale des connexions semi-ouvertes, des resets, ou des erreurs au niveau TCP.

Applicative

La cible est le serveur web, l’API ou une fonction précise. Le trafic total n’est pas forcément énorme. En revanche, certaines routes consomment beaucoup de CPU, d’I/O, de mémoire ou d’accès base de données. C’est la famille la plus trompeuse, car elle peut ressembler à un pic de fréquentation réel.

Attaque DDoS exemple, ce que l’on observe selon le type

Un exemple simple d’attaque volumétrique : le trafic entrant monte soudainement bien au-delà du niveau habituel et le service devient inaccessible depuis plusieurs réseaux. Le CPU du serveur n’est pas forcément au maximum, car le goulet d’étranglement est souvent le lien ou l’équipement amont.

Un exemple protocolaire : le site répond par intermittence, les connexions se coupent, et les métriques réseau montrent une anomalie sur les ouvertures de session ou le traitement des paquets. Dans ce cas, le rôle du pare-feu face aux attaques réseau doit rester ciblé : il aide à filtrer certains comportements, mais ne remplace pas un filtrage en amont si le lien est saturé.

Un exemple applicatif : la page d’accueil reste accessible, mais une route de recherche, un endpoint d’API ou une page de connexion devient très lente. Les journaux montrent beaucoup de requêtes sur la même route, parfois avec des paramètres variés pour contourner le cache. On peut aussi observer des pics de CPU, de workers occupés, d’accès base de données et d’erreurs 429, 499, 502 ou 504 selon l’architecture.

Pour les services web publics, utiliser un CDN pour mieux absorber les pics de trafic peut réduire l’impact de certains scénarios, surtout côté HTTP, sans régler tous les cas.

Attaque DDoS en cours, quels signes voir côté serveur et côté réseau

Le premier signal est rarement un message explicite. On observe plutôt une combinaison d’indices.

• Côté réseau : bande passante proche de la capacité du lien, hausse brutale du nombre de paquets, latence qui grimpe, perte de paquets, connexions entrantes anormalement nombreuses.
• Côté système : augmentation des sockets ouvertes, files d’attente saturées, workers occupés en permanence, consommation CPU ou mémoire qui change brutalement.
• Côté application : même route appelée à cadence anormale, agents utilisateurs répétitifs ou incohérents, erreurs 4xx et 5xx en hausse, sessions qui expirent, temps de réponse irréguliers.
• Côté exploitation : alertes de supervision, plaintes simultanées d’utilisateurs situés sur plusieurs réseaux, tableau de bord de l’hébergeur qui signale un trafic anormal.

La bonne pratique consiste à corréler les sources : logs web, métriques d’interface, connexions actives, files d’attente applicatives et supervision. Si vous devez diagnostiquer une saturation ou une coupure réseau, cette corrélation évite de confondre un incident opérateur, un bug applicatif et un DDoS.

Comment se protéger d’une attaque DDoS

La question « comment se proteger d’une attaque ddos » n’a pas une réponse unique. La protection dépend du type d’exposition et du point de saturation visé.

• Prévoir une couche de protection en amont chez l’hébergeur ou l’opérateur, car un serveur seul ne peut pas filtrer ce qu’il ne reçoit déjà plus correctement.
• Mettre en place des limitations de débit par IP, par route ou par jeton d’API quand l’usage normal le permet.
• Réduire le coût des routes sensibles, avec cache, files d’attente, pagination, délais d’expiration adaptés et circuits de repli.
• Segmenter les services : séparer l’API, l’administration et le site public limite l’effet domino.
• Restreindre les surfaces d’exposition inutiles et durcir la publication des services.
• Surveiller les métriques réseau et applicatives pour détecter tôt les changements de profil.

Pour certains abus ciblant l’authentification ou des tentatives répétitives, on peut aussi mettre en place Fail2ban pour limiter certains abus. Cela aide sur des scénarios précis, mais ce n’est pas une protection générale contre un DDoS distribué important.

Que faire pendant l’attaque et juste après

Pendant l’incident, la priorité est d’identifier le point de saturation. Si le lien amont est plein, il faut escalader immédiatement vers l’hébergeur, l’opérateur ou la solution anti-DDoS en amont. Si l’application est la cible, les actions rapides sont différentes : limiter une route, activer des règles temporaires, augmenter le cache, réduire le coût des réponses, bloquer certains motifs de requêtes, ou isoler un service secondaire.

Il faut aussi conserver des traces : périodes exactes, métriques, extraits de logs, volumes constatés et changements appliqués. Sans ces éléments, le post-mortem reste approximatif. Quand l’incident se termine, on vérifie les journaux, les erreurs, les ressources saturées et la capacité de reprise. On ajuste ensuite les seuils d’alerte et les protections, en gardant à l’esprit qu’une attaque future peut changer de famille ou de vecteur.

Les limites sont réelles : sans filtrage en amont, certaines attaques volumétriques dépassent ce qu’un serveur ou un simple pare-feu local peut absorber. C’est le moment d’escalader, sans attendre, vers l’infrastructure qui contrôle le trafic avant son arrivée sur la machine cible.

En résumé, l’attaque ddos definition la plus utile est celle qui relie la théorie aux symptômes observables. Savoir distinguer volumétrique, protocolaire et applicative permet de choisir la première réponse adaptée, puis d’orienter l’escalade vers le bon niveau technique.

Questions frequentes

Qu'est-ce qu'une attaque en déni de service ?

Une attaque en déni de service vise à rendre un service indisponible pour ses utilisateurs légitimes. Elle surcharge une ressource, comme la bande passante, les connexions réseau ou l’application elle-même. Quand l’attaque est distribuée sur de nombreuses sources, on parle de DDoS. L’effet visible est souvent une lenteur extrême, des erreurs ou une indisponibilité complète.

Quelle est la différence entre les attaques DoS et DDoS ?

Une attaque DoS provient d’une source unique ou d’un nombre limité de sources. Une attaque DDoS répartit le trafic malveillant entre de nombreuses machines, ce qui complique le filtrage. Dans un DoS simple, bloquer une IP peut parfois suffire. Dans un DDoS, il faut souvent filtrer par comportement et s’appuyer sur une protection en amont.

Quels sont les signes d’une attaque DDoS en cours sur un serveur ?

Les signes fréquents sont une hausse soudaine de la bande passante, un grand nombre de connexions ouvertes, des pages lentes et des erreurs 5xx. Les journaux peuvent montrer des requêtes répétées sur une même route ou des pics d’accès incohérents. Sur le système, on voit parfois des files d’attente pleines, des workers saturés ou des sockets anormalement nombreuses. La corrélation entre logs, métriques réseau et supervision aide à confirmer le diagnostic.

Quelle différence entre une attaque volumétrique, protocolaire et applicative ?

Une attaque volumétrique cherche surtout à saturer le lien réseau avec beaucoup de trafic. Une attaque protocolaire vise le fonctionnement de la pile réseau ou des équipements intermédiaires, par exemple les connexions ou les tables d’état. Une attaque applicative cible le serveur web, l’API ou une route précise avec des requêtes coûteuses. La première réponse dépend donc du point exact de saturation.