Un site qui ne répond plus n’est pas forcément victime d’une panne matérielle. Une attaque DoS, ou attaque par déni de service, cherche à rendre un service inaccessible en épuisant ses ressources : capacité réseau, connexions disponibles, mémoire ou puissance de calcul. Quand les demandes proviennent de nombreuses machines, il s’agit d’une attaque DDoS, c’est-à-dire d’une attaque distribuée, plus difficile à isoler et à filtrer à la source.
La distinction change la réponse opérationnelle. Une source unique peut parfois être bloquée assez vite ; un botnet réparti entre de nombreux appareils compromis oblige à mobiliser l’hébergeur, le fournisseur d’accès ou un service spécialisé. Pour une PME, le bon réflexe n’est pas d’ajouter de la bande passante au hasard : il faut connaître le trafic habituel, identifier les composants exposés et préparer une procédure d’escalade avant l’incident.
En bref
- Une attaque DoS surcharge un service depuis une source ; une attaque DDoS coordonne plusieurs sources.
- La saturation réseau n’est qu’un scénario : une application peut aussi être ralentie par des requêtes coûteuses à faible volume.
- Mesurer le trafic normal aide à distinguer un pic légitime d’un trafic malveillant.
- Action utile : vérifiez qui peut filtrer le trafic en amont de votre serveur cible et gardez son contact d’urgence à portée de main.
Attaque DoS et déni de service : le principe de la saturation
Le déni de service vise la disponibilité. Un service reçoit plus de demandes qu’il ne peut en traiter, ou des demandes qui mobilisent ses ressources trop longtemps. Les utilisateurs légitimes obtiennent alors des délais excessifs, des erreurs ou une indisponibilité de service complète.
Imaginez une boutique en ligne dont le serveur gère normalement les connexions des clients, les recherches de produits et les paiements. Si une seule machine envoie un flot de requêtes, elle peut occuper les connexions ou saturer une partie du réseau. La boutique paraît hors ligne, même si ses données restent intactes.
Le trafic visé peut agir à différents niveaux. Un volume important de paquets peut encombrer le lien réseau ; des demandes de connexion inachevées peuvent retenir des ressources ; une fonction applicative coûteuse, comme une recherche complexe, peut épuiser le processeur sans produire un débit spectaculaire. Réduire le phénomène à « trop de trafic » ferait donc manquer une partie du diagnostic.
Une panne et une attaque peuvent aussi se ressembler dans les premières minutes. Un lancement commercial, une intégration partenaire ou un défaut logiciel provoquent parfois un pic inhabituel. La différence se construit avec les mesures : origine et répartition des requêtes, chemins sollicités, taux d’erreur, consommation des ressources et évolution dans le temps.
DoS ou DDoS : ce que change une attaque distribuée
La différence centrale tient au nombre et à la répartition des sources. Dans un DoS classique, le trafic vient d’un point d’émission. Dans un DDoS, de nombreux appareils transmettent des demandes vers une même cible. Ces appareils peuvent appartenir à un botnet, réseau de machines compromises pilotées à distance.
Cette dispersion complique le filtrage. Bloquer une adresse IP peut réduire une partie du flux, mais les autres sources continuent. De plus, les adresses visibles ne désignent pas nécessairement les personnes qui organisent l’attaque : elles peuvent appartenir à des appareils infectés ou à des relais. La réponse doit donc s’appuyer sur la coopération des opérateurs et sur des filtres placés avant le réseau de l’entreprise.
| Critère | DoS | DDoS |
|---|---|---|
| Origine apparente | Une source principale | Sources multiples et dispersées |
| Filtrage | Souvent plus direct à l’échelle locale | Requiert fréquemment un filtrage en amont |
| Analyse | Corrélation plus simple à établir | Sources nombreuses, attribution plus complexe |
| Impact possible | Limité par la capacité de la source | Peut dépasser rapidement les capacités de la cible |
La comparaison n’est pas une règle absolue. Une attaque issue d’une seule source peut exploiter une faiblesse applicative et causer une panne, tandis qu’un grand volume réparti peut être absorbé par une infrastructure bien conçue. Le type de défense se choisit selon le service exposé, pas seulement selon l’étiquette DoS ou DDoS.
Des attaques réseau aux requêtes applicatives
Les attaques volumétriques cherchent à consommer la capacité disponible du lien ou du réseau. Les attaques de protocole exploitent le coût de gestion des communications, notamment dans les couches réseau et transport du modèle OSI. Dans les deux cas, les équipements doivent traiter un volume ou un état de connexion qui dépasse leurs limites.
Les attaques de couche applicative ciblent plutôt un service précis : page de connexion, interface de programmation ou fonction de recherche. Des demandes qui ressemblent à celles d’un utilisateur ordinaire peuvent maintenir des connexions ouvertes ou déclencher des traitements coûteux. Une surveillance limitée au débit total ne suffit pas toujours à repérer ce scénario.
Les attaques par fragmentation IP malformée, parfois désignées par le terme Teardrop, relèvent d’un cas historique lié au réassemblage de paquets. Les systèmes actuels ont largement corrigé les vulnérabilités connues associées à ces variantes ; elles restent utiles pour comprendre le principe, mais ne doivent pas détourner l’attention des risques actuels liés aux protocoles et aux applications exposées.
Pour une équipe produit, la bonne question est concrète : quelle opération coûte le plus cher au serveur, et peut-elle être appelée sans contrôle suffisant ? Des limites de débit, des délais d’expiration cohérents, la mise en cache et la protection des API réduisent l’impact, à condition de ne pas bloquer les clients légitimes.
Détecter une saturation réseau sans confondre panne et attaque
Une référence de trafic normal rend l’alerte exploitable. Il faut suivre les volumes entrants et sortants, les connexions simultanées, les codes d’erreur, la latence et la charge des services. Une hausse du trafic vers une seule route applicative n’a pas la même signification qu’un pic uniforme sur tout le réseau.
Dans une PME fictive qui exploite un portail de maintenance industrielle, l’équipe constate un lundi matin une hausse des erreurs de connexion. Le débit global reste raisonnable, mais les connexions ouvertes s’accumulent et le traitement de l’authentification ralentit. Cette combinaison oriente l’enquête vers la couche applicative plutôt que vers une simple saturation de bande passante.
Un tableau de bord utile associe les métriques réseau aux journaux applicatifs et à l’état des dépendances. Il faut aussi conserver une chronologie : début des symptômes, changements récents, alertes déclenchées et actions de filtrage. Sans cette trace, une équipe peut couper une intégration légitime tout en laissant l’origine du problème intacte.
Le guide de l’IETF sur les attaques par déni de service présente les enjeux généraux de ce type de menace. Pour l’exploitation quotidienne, les seuils doivent être ajustés à partir des mesures propres au service : une règle copiée d’un autre environnement provoque souvent des faux positifs.
Protection contre les attaques DoS et DDoS : préparer la réponse
La protection contre les attaques repose sur plusieurs couches. Un pare-feu applicatif peut filtrer certaines requêtes ; un réseau de diffusion de contenu peut absorber ou répartir une partie du trafic ; l’équilibrage de charge évite qu’un seul serveur prenne toute la pression. Aucun de ces mécanismes ne remplace un accord clair avec l’hébergeur ou le fournisseur réseau sur le filtrage en amont.
Augmenter la capacité peut donner du temps, mais ne corrige pas une fonction applicative qui consomme trop de ressources. La mise à l’échelle doit s’accompagner de limites de débit, de contrôles adaptés et de tests autorisés dans un environnement maîtrisé. Un test de charge mal cadré contre un service public peut perturber des tiers et n’est pas une méthode acceptable.
- Établir une base de référence du trafic et documenter les variations habituelles.
- Recenser les services exposés, les dépendances et les contacts d’escalade.
- Définir à l’avance les critères de limitation, de filtrage et de retour à la normale.
- Tester le plan de réponse avec des exercices contrôlés et approuvés.
Au déclenchement d’une alerte, l’équipe doit confirmer l’étendue de l’incident, préserver les journaux et contacter l’opérateur si le trafic dépasse le lien disponible. Filtrer uniquement sur la base d’adresses IP peut être insuffisant, voire couper des utilisateurs légitimes. La décision doit s’appuyer sur des indicateurs observables et sur un responsable clairement désigné.
Une défense bien préparée ne promet pas qu’aucune panne ne surviendra. Elle réduit le temps passé à chercher qui appeler et quelle mesure prendre, au moment où chaque minute compte.
Quelle est la différence entre une attaque DoS et une attaque DDoS ?
Une attaque DoS provient généralement d’une source principale, tandis qu’une attaque DDoS répartit le trafic entre plusieurs machines. Cette dispersion complique le filtrage et l’identification des sources.
Une attaque DDoS signifie-t-elle toujours un très gros volume de trafic ?
Non. Certaines attaques visent des fonctions applicatives coûteuses et peuvent gêner un service avec un débit modéré. Il faut examiner la latence, les connexions et les journaux applicatifs, pas seulement le volume réseau.
Un pare-feu suffit-il à bloquer une attaque DoS ?
Un pare-feu peut filtrer certains flux, notamment lorsqu’une source est identifiable. Si le lien réseau est saturé avant que le trafic atteigne le pare-feu, une intervention de l’hébergeur ou de l’opérateur est souvent nécessaire.
Que faut-il préparer avant un incident DDoS ?
Établissez le profil de trafic normal, recensez les services critiques et consignez les contacts d’escalade. Définissez aussi qui peut activer les protections et comment préserver les journaux pendant l’incident.