Aller au contenu principal

Guide IPv4

Attaques DoS et DDoS : différences et réponse

Stephanie
Différence entre les attaques DoS et DDoS

Réponse rapide : DoS ou DDoS

Un DDoS est une forme distribuée de déni de service

DoS décrit une atteinte à la disponibilité ; DDoS décrit une technique DoS utilisant de nombreux systèmes. Le nombre de sources aide à classer l’événement, mais la couche saturée, le trafic, la capacité amont et les responsables déterminent la réponse.

  • Sources : un DoS simple peut avoir une seule source apparente. Le trafic DDoS provient de systèmes ou services réflecteurs distribués ; certaines adresses peuvent être usurpées, partagées ou appartenir à des intermédiaires légitimes.
  • Couches : les attaques volumétriques, par réflexion, sur l’état du protocole, les connexions, les requêtes applicatives ou à faible débit saturent des ressources différentes. Un incident peut combiner plusieurs formes.
  • Preuves : conservez une télémétrie synchronisée du réseau, de la périphérie et de l’application. Identifiez protocoles, ports, points d’accès, coût des requêtes, erreurs, latence, files, dépendances et première ressource saturée.
  • Réponse : contactez rapidement le FAI, l’hébergeur ou cloud, le CDN ou le prestataire d’atténuation. Un filtrage local ne libère pas une liaison amont déjà saturée.

Que sont les attaques DoS et DDoS ?

Une attaque par déni de service (DoS) est une action délibérée qui empêche ou dégrade sensiblement l’accès légitime à un service ou à une ressource. La contrainte peut toucher la capacité réseau, l’état des protocoles ou des connexions, le calcul, le stockage, une dépendance ou un point de terminaison applicatif. Une source unique est fréquente dans les cas simples, mais le nombre de sources ne définit pas une attaque DoS.

Une attaque par déni de service distribué (DDoS) est une technique DoS qui coordonne du trafic ou des requêtes provenant de nombreux systèmes. Cette distribution peut compliquer le filtrage, l’attribution et la planification de capacité, mais la couche touchée, la validité du trafic, la capacité amont et le dispositif d’atténuation déterminent la réponse utile.

DoS ou DDoS : les différences opérationnelles

Attaque DoS

  • Sources : l’événement peut provenir d’une source ou d’un petit groupe, mais une adresse IP apparente peut être usurpée, traduite, mandatée ou appartenir à un chemin de réflexion.
  • Preuves : identifier la ressource et la couche contraintes : lien, état de connexion ou de protocole, calcul, base de données, cache, dépendance ou point de terminaison applicatif.
  • Réponse : une source étroite peut parfois être bloquée, mais une protection durable demande validation, contrôle des débits et des états, capacité suffisante et procédure d’escalade amont.

Attaque DDoS

  • Sources : le trafic ou les requêtes arrivent de nombreux systèmes, réseaux, régions ou services réflecteurs ; tous les hôtes participants ne sont pas nécessairement malveillants en connaissance de cause.
  • Preuves : comparer la télémétrie en périphérie, réseau et applicative pour identifier protocoles, ports, chemins de requête, ratios de réponse, répartition des sources et véritable goulot d’étranglement.
  • Réponse : coordonner tôt avec le FAI, l’hébergeur ou fournisseur cloud, le CDN ou le prestataire d’atténuation ; filtrer localement ne libère pas un lien amont déjà saturé.

Schémas d’attaque DoS et DDoS

  • Saturation volumétrique ou de ressources : le trafic consomme la bande passante, la capacité de traitement des paquets, les connexions, le calcul, la mémoire, le stockage ou une dépendance. Mesurer la première ressource saturée au lieu de supposer que chaque pic est un flot de bande passante.
  • Réflexion et amplification : des requêtes portant l’adresse usurpée de la victime amènent des services tiers à lui envoyer des réponses plus volumineuses. Conserver protocoles, ports, ratios requête-réponse et observations amont avant de modifier les filtres.
  • Trafic distribué de botnet : des appareils compromis peuvent coordonner du trafic sur de nombreux réseaux. La diversité des sources n’identifie pas le contrôleur, et bloquer des pays ou réseaux entiers peut exclure des utilisateurs légitimes sans soulager la contrainte.
  • Épuisement lent ou à faible débit : peu de connexions ou de requêtes peuvent retenir un état applicatif ou protocolaire rare. Suivre leur durée, la concurrence, les files, les délais, les processus et les dépendances.
  • Flots de requêtes applicatives : des requêtes syntaxiquement valides peuvent viser des chemins coûteux comme la recherche, la connexion, les API ou les défauts de cache. Utiliser le coût du point de terminaison, le cache, l’identité, la session et la télémétrie applicative, pas seulement l’adresse IP source.

Comment préparer et gérer un incident DoS ou DDoS

  1. Cartographier le service et les points de défaillance : répertorier les points de terminaison critiques, le DNS, les chemins périphérie-origine, les liens amont, l’authentification, les bases, les files, les dépendances, les limites de capacité et l’impact d’un mode dégradé.
  2. Établir des références et des alertes : conserver une télémétrie synchronisée en périphérie, réseau et applicative. Alerter sur la saturation, les erreurs, la latence, les files, l’état des connexions, le coût des requêtes, les défauts de cache et les dépendances, pas uniquement sur le volume.
  3. Préparer l’aide amont : consigner les contacts 24/7, identifiants de compte, étapes d’activation, options de diversion ou de nettoyage, seuils, autorités de changement et routes de repli du FAI, de l’hébergeur ou du cloud, du CDN et de tout prestataire d’atténuation.
  4. Adapter les contrôles à la couche : les contrôles réseau et transport traitent les flux usurpés, réfléchis, protocolaires ou liés à l’état des connexions ; les contrôles applicatifs traitent les routes coûteuses, sessions, identités et comportements abusifs. Mise à l’échelle et correctifs répondent à certaines contraintes, pas à tout un plan DDoS.
  5. Rédiger et tester le plan d’intervention : attribuer le commandement de l’incident, l’escalade fournisseur, la collecte de preuves, la communication, les modes dégradés, le basculement, le retour arrière et la validation de reprise. Tester sans envoyer de trafic vers la production ni dépasser un périmètre autorisé.
  6. Pendant l’incident : confirmer sécurité et autorité, contacter tôt le fournisseur amont ou d’atténuation, préserver télémétrie et horodatages, protéger l’accès d’administration, appliquer les contrôles validés les plus étroits, surveiller les autres alertes et vérifier la reprise avant de clôturer.

Construire un plan de réponse au déni de service testé

Aucun contrôle n’élimine le risque de déni de service. Un plan exploitable identifie le service et son goulot d’étranglement, sépare les preuves réseau et applicatives, prépare la coordination amont, définit le fonctionnement dégradé et la reprise, puis fait l’objet d’exercices avant un incident. Utiliser les recommandations actuelles de l’autorité cyber nationale et des fournisseurs, et maintenir contacts, seuils, schémas et procédures sous contrôle des changements.

Rôle d’i.lease

i.lease peut soutenir les registres d’espace d’adressage, la coordination du routage, la réputation et les opérations d’abus dans un périmètre convenu. Il ne s’agit pas d’un service d’atténuation DDoS ou de réponse aux incidents en urgence : une attaque active relève du fournisseur réseau, d’hébergement, de cloud, de CDN ou d’atténuation qui transporte le trafic.

Consulter le guide d’exploitation IPv4