Attaque par déni de service (DoS / DDoS) : comprendre et se protéger
En quelques années, le nombre d'attaques par déni de service a quasiment doublé. Leurs conséquences vont du simple ralentissement à l'indisponibilité totale du système d'information. Quand la continuité de service est vitale, ce risque ne se néglige pas.
DoS, DDoS : de quoi parle-t-on ?
Une attaque par déni de service (DoS) vise à ralentir ou rendre indisponible un serveur ou une ressource. Les motivations varient : extorsion le plus souvent, mais aussi convictions idéologiques, politiques ou personnelles.
La différence avec un déni de service distribué (DDoS) tient au nombre de sources : dans un DoS, la victime est attaquée depuis un seul système ; dans un DDoS, l'attaquant mobilise une multitude de machines à la fois. Le DDoS est donc généralement plus rapide, plus difficile à bloquer et à tracer.
Point clé : on ne peut jamais empêcher totalement un DDoS si l'attaquant y consacre des moyens illimités. En revanche, de nombreuses attaques DoS exploitent des failles de configuration ou d'application que l'on peut, elles, corriger durablement. C'est précisément le terrain d'un test d'intrusion.
Les grands types d'attaques
Attaques protocolaires
Le SYN Flood sature un serveur de demandes de connexion jamais finalisées ; le Teardrop envoie des paquets fragmentés de façon anormale pour déstabiliser la cible. Elles exploitent les protocoles TCP/IP.
Attaques volumétriques
L'objectif est de saturer la bande passante de la victime, par exemple via un déluge de requêtes ICMP. Le réseau ne laisse alors plus passer que de rares requêtes légitimes.
Attaques applicatives (couche 7)
Le Slowloris garde un maximum de connexions ouvertes avec des requêtes HTTP volontairement lentes, jusqu'à épuiser la capacité du serveur à en accepter de nouvelles.
Abus de fonctionnalités
Une fonction d'export sans garde-fou, une API GraphQL autorisant des boucles de fragments, une « bombe XML »… Autant de fonctionnalités détournées pour épuiser les ressources.
Trois causes récurrentes derrière un DoS
Dans le contexte d'une application web, un déni de service exploitable résulte le plus souvent de l'une de ces trois faiblesses : une mauvaise configuration du serveur (par exemple un serveur ancien sans module de temporisation), une fonctionnalité mal implémentée (un traitement coûteux déclenchable en boucle), ou un composant vulnérable (une bibliothèque non mise à jour visée par une CVE). Bonne nouvelle : ces trois causes se corrigent, à condition de les avoir identifiées au préalable.
Tester le déni de service, avec méthode
Lors d'un pentest, on ne cherche pas à « écrouler » un service à coups de moyens : un DDoS y parviendra toujours. On recherche au contraire les cas précis où un attaquant isolé, avec une seule machine et quelques outils, pourrait suffire à provoquer l'indisponibilité. Ces tests se mènent dans un cadre maîtrisé : de préférence sur un environnement de test, sinon sur un créneau défini, avec une communication étroite avec l'équipe technique pour réagir vite et limiter l'impact. Dès que la faille est démontrée, on s'arrête : l'objectif est de la corriger, pas de nuire.
Se protéger, étape par étape
Durcir la configuration serveur
Activer les modules de temporisation (délais de réception, débits minimaux) pour fermer les connexions trop lentes, type Slowloris.
Limiter et répartir le trafic
Mettre en place du rate limiting et un ou plusieurs répartiteurs de charge (load balancers) pour ne pas surcharger un serveur unique.
Filtrer avec un pare-feu applicatif
Un pare-feu applicatif web (WAF) reconnaît et bloque le trafic malveillant avant qu'il n'atteigne le serveur.
Corriger les fonctionnalités à risque
Encadrer les traitements coûteux (un export à la fois), brider la profondeur des requêtes API, désactiver les entités externes XML.
Maintenir les composants à jour
Inventorier les versions, suivre les vulnérabilités majeures et appliquer un processus de patch management rigoureux.
Surveiller et préparer la reprise
Analyser le trafic pour détecter tôt une attaque, et intégrer le scénario dans votre plan de continuité et de reprise d'activité, en coordination avec votre réponse à incident.
Pourquoi se faire accompagner par BCIT ?
Des tests cadrés
Nous recherchons les dénis de service réellement corrigeables, dans un cadre maîtrisé qui protège votre activité.
De la résilience, pas de la peur
Notre objectif : réduire l'impact d'une attaque sur votre disponibilité, avec des mesures concrètes et priorisées.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Protégez la disponibilité de vos services
Prenons 15 minutes pour évaluer votre exposition au déni de service et définir les mesures qui renforceront concrètement votre résilience.
Attaque par déni de service (DoS / DDoS) : comprendre et se protéger
En quelques années, le nombre d'attaques par déni de service a quasiment doublé. Leurs conséquences vont du simple ralentissement à l'indisponibilité totale du système d'information. Quand la continuité de service est vitale, ce risque ne se néglige pas.
DoS, DDoS : de quoi parle-t-on ?
Une attaque par déni de service (DoS) vise à ralentir ou rendre indisponible un serveur ou une ressource. Les motivations varient : extorsion le plus souvent, mais aussi convictions idéologiques, politiques ou personnelles.
La différence avec un déni de service distribué (DDoS) tient au nombre de sources : dans un DoS, la victime est attaquée depuis un seul système ; dans un DDoS, l'attaquant mobilise une multitude de machines à la fois. Le DDoS est donc généralement plus rapide, plus difficile à bloquer et à tracer.
Point clé : on ne peut jamais empêcher totalement un DDoS si l'attaquant y consacre des moyens illimités. En revanche, de nombreuses attaques DoS exploitent des failles de configuration ou d'application que l'on peut, elles, corriger durablement. C'est précisément le terrain d'un test d'intrusion.
Les grands types d'attaques
Attaques protocolaires
Le SYN Flood sature un serveur de demandes de connexion jamais finalisées ; le Teardrop envoie des paquets fragmentés de façon anormale pour déstabiliser la cible. Elles exploitent les protocoles TCP/IP.
Attaques volumétriques
L'objectif est de saturer la bande passante de la victime, par exemple via un déluge de requêtes ICMP. Le réseau ne laisse alors plus passer que de rares requêtes légitimes.
Attaques applicatives (couche 7)
Le Slowloris garde un maximum de connexions ouvertes avec des requêtes HTTP volontairement lentes, jusqu'à épuiser la capacité du serveur à en accepter de nouvelles.
Abus de fonctionnalités
Une fonction d'export sans garde-fou, une API GraphQL autorisant des boucles de fragments, une « bombe XML »… Autant de fonctionnalités détournées pour épuiser les ressources.
Trois causes récurrentes derrière un DoS
Dans le contexte d'une application web, un déni de service exploitable résulte le plus souvent de l'une de ces trois faiblesses : une mauvaise configuration du serveur (par exemple un serveur ancien sans module de temporisation), une fonctionnalité mal implémentée (un traitement coûteux déclenchable en boucle), ou un composant vulnérable (une bibliothèque non mise à jour visée par une CVE). Bonne nouvelle : ces trois causes se corrigent, à condition de les avoir identifiées au préalable.
Tester le déni de service, avec méthode
Lors d'un pentest, on ne cherche pas à « écrouler » un service à coups de moyens : un DDoS y parviendra toujours. On recherche au contraire les cas précis où un attaquant isolé, avec une seule machine et quelques outils, pourrait suffire à provoquer l'indisponibilité. Ces tests se mènent dans un cadre maîtrisé : de préférence sur un environnement de test, sinon sur un créneau défini, avec une communication étroite avec l'équipe technique pour réagir vite et limiter l'impact. Dès que la faille est démontrée, on s'arrête : l'objectif est de la corriger, pas de nuire.
Se protéger, étape par étape
Durcir la configuration serveur
Activer les modules de temporisation (délais de réception, débits minimaux) pour fermer les connexions trop lentes, type Slowloris.
Limiter et répartir le trafic
Mettre en place du rate limiting et un ou plusieurs répartiteurs de charge (load balancers) pour ne pas surcharger un serveur unique.
Filtrer avec un pare-feu applicatif
Un pare-feu applicatif web (WAF) reconnaît et bloque le trafic malveillant avant qu'il n'atteigne le serveur.
Corriger les fonctionnalités à risque
Encadrer les traitements coûteux (un export à la fois), brider la profondeur des requêtes API, désactiver les entités externes XML.
Maintenir les composants à jour
Inventorier les versions, suivre les vulnérabilités majeures et appliquer un processus de patch management rigoureux.
Surveiller et préparer la reprise
Analyser le trafic pour détecter tôt une attaque, et intégrer le scénario dans votre plan de continuité et de reprise d'activité, en coordination avec votre réponse à incident.
Pourquoi se faire accompagner par BCIT ?
Des tests cadrés
Nous recherchons les dénis de service réellement corrigeables, dans un cadre maîtrisé qui protège votre activité.
De la résilience, pas de la peur
Notre objectif : réduire l'impact d'une attaque sur votre disponibilité, avec des mesures concrètes et priorisées.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Protégez la disponibilité de vos services
Prenons 15 minutes pour évaluer votre exposition au déni de service et définir les mesures qui renforceront concrètement votre résilience.