Attaques par déni de service (DoS) : stratégies de prévention

Introduction

Les attaques par déni de service (DoS) ne sont pas subtiles. Elles n'essaient pas de voler des données ni de persister discrètement dans un système. Leur objectif est direct : rendre un service indisponible pour les utilisateurs légitimes. Pour les entreprises qui dépendent de la disponibilité en ligne—plates-formes SaaS, commerce électronique, API, systèmes financiers—les interruptions constituent le dommage.

Bien qu'étant l'une des classes d'attaques cybernétiques les plus anciennes, les attaques DoS restent efficaces parce que de nombreux systèmes sont encore conçus pour la fonctionnalité d'abord et la résilience ensuite. Ce post explique comment fonctionnent les attaques DoS, pourquoi elles réussissent encore et—plus important encore—comment les prévenir en utilisant des défenses pratiques et stratifiées.

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

Une attaque par déni de service (DoS) tente de saturer les ressources d'un système afin qu'il ne puisse plus répondre aux demandes légitimes. Cela peut cibler :

• Bande passante du réseau (trafic d’inondation)
• Ressources du serveur (CPU, mémoire, descripteurs de fichiers)
• Logique de l’application (requêtes coûteuses, abus d’authentification)

Lorsque l'attaque est distribuée sur de nombreuses sources, elle devient une attaque par déni de service distribué (DDoS). L'impact est le même ; la difficulté de mitigation augmente.

Types courants d'attaques par déni de service (DoS)

1. Attaques par inondation au niveau de la couche réseau

Ces attaques saturent la bande passante ou les piles réseau.

Exemples :

• Inondations SYN
• Inondations UDP
• Inondations ICMP

Ils visent à épuiser les tables de connexion ou à saturer la capacité de routage avant que le trafic n'atteigne même l'application.

2. Attaques au niveau de l'application

Ceux-ci sont plus dangereux parce qu'ils semblent légitimes.

Exemples :

• Inondations HTTP GET/POST
• Tentatives de force brute de connexion
• Abus d'API
• Requêtes de recherche ou de génération de rapports coûteuses

Les attaques au niveau de l'application contournent souvent les pare-feux de base parce que chaque requête est techniquement valide.

3. Attaques par épuisement des ressources

Les attaquants déclenchent délibérément des chemins de code qui consomment excessivement le CPU, la mémoire ou les connexions à la base de données.

Exemples :

• Hachage répétitif des mots de passe
• Téléversements de fichiers volumineux
• Requêtes de pagination illimitées
• Abus de génération de PDF/image

Pourquoi les attaques par déni de service fonctionnent-elles encore

Les attaques par déni de service réussissent non pas parce que les défenses n'existent pas, mais parce que les systèmes manquent souvent de :

• Limites de débit
• Validation des requêtes
• Plafonds de ressources
• Visibilité du trafic
• Conception consciente des coûts

De nombreuses applications font confiance au fait que les utilisateurs se comporteront de manière raisonnable. Les attaquants comptent sur cette confiance.

Stratégie de prévention ##  : Défense en profondeur

Il n'existe pas de solution unique contre les attaques par déni de service (DoS). Une prévention efficace nécessite des contrôles en couches, chacun conçu pour échouer en toute sécurité si une autre couche est submergée.

Couche 1 : Protection du réseau et des périmètres

Utiliser un proxy inversé ou un CDN

Un proxy inverse absorbe le trafic avant qu'il n'atteigne votre infrastructure.

Capacités :

• Filtrage du trafic
• Atténuation des bots
• Protection contre les attaques SYN flood
• Routage Anycast

Des fournisseurs tels que Cloudflare ou Akamai opèrent à l'échelle mondiale et peuvent gérer des volumes qu'aucun serveur unique ne peut.

Principe clé : votre serveur d'origine ne doit jamais être directement exposé.

Bloquer les abus évidents à la périphérie

Même sans règles WAF payantes, les protections de base aident :

• Bloquer les chemins d'administration courants qui n'existent pas
• Refuser les requêtes HTTP malformées
• Appliquer des limites de taille des requêtes
• Filtrer les agents utilisateurs non navigateurs lorsque cela est approprié

Le filtrage en périphérie réduit la charge avant même que la logique de l'application ne soit exécutée.

Couche 2 : Renforcement des Transports et de l'Infrastructure

Limite de débit à plusieurs niveaux

La limitation du taux devrait exister :

• À la périphérie
• Au serveur web
• À l'application

Différents seuils pour différents points de terminaison :

• Points de terminaison d'authentification : très stricts
• Pages publiques : plus indulgentes
• API : quotas basés sur les jetons

La limitation du débit ne consiste pas à arrêter toutes les attaques : il s'agit de rendre les attaques coûteuses et lentes.

Appliquer les limites de connexion

Au niveau du serveur :

• Limiter les connexions simultanées par IP
• Définir des délais d'attente keep-alive raisonnables
• Limiter la taille des corps de requête

Au niveau de la base de données :

• Limiter le nombre maximum de connexions
• Utiliser des pools de connexions
• Échouer rapidement au lieu de mettre en file d'attente indéfiniment

Couche 3 : Défenses au niveau de l'application

Protéger les opérations à coût élevé

Tout point de terminaison qui :

• Hache les mots de passe
• Génère des rapports
• Télécharge des fichiers
• Envoie des e-mails
• Interroge de grands ensembles de données

…doit être protégé.

Les contrôles comprennent :

• CAPTCHA ou preuve de travail
• Quotas de requêtes
• Minuteries de refroidissement
• Files d'attente de tâches asynchrones

Ne permettez jamais aux attaquants de déclencher à plusieurs reprises des travaux synchrones coûteux.

Échec fermé, pas ouvert

Lorsqu'un système est sous tension :

• Rejeter rapidement les nouvelles requêtes
• Retourner des codes d'erreur clairs
• Ne pas réessayer en interne dans des boucles

La dégradation progressive préserve la disponibilité pour les utilisateurs principaux au lieu de s'effondrer complètement.

Couche 4 : Observabilité et Détection

Surveillez ce qui compte

Les attaques par déni de service sont souvent visibles avant une panne complète.

Suivi :

• Taux de requêtes par point de terminaison
• Échecs d'authentification
• Pics de latence
• Saturation du CPU et de la mémoire
• Épuisement des connexions à la base de données

Les plateformes cloud comme Amazon Web Services fournissent des métriques et des alarmes natives qui devraient être activées dès le premier jour.

Journaliser avec intention

Les journaux doivent répondre :

• Quel point de terminaison est sollicité ?
• Depuis où ?
• À quel rythme ?
• Avec quelle taille de charge utile ?

Évitez de consigner les corps de requête complets pour les points de terminaison sensibles, mais consignez toujours suffisamment de métadonnées pour identifier les modèles d'abus.

Choix de conception architecturale qui réduisent le risque de DoS

• Les services sans état évoluent mieux sous charge
• La mise en cache réduit la pression sur le backend
• Le traitement asynchrone empêche l'accumulation des requêtes
• Les API idempotentes réduisent l'amplification des tentatives
• Les délais d'attente partout empêchent le verrouillage des ressources

La résistance aux attaques par déni de service dépend autant de l'architecture que des outils de sécurité.

S'aligner sur les normes de l'industrie

Des directives faisant autorité renforcent ces pratiques :

• NIST met l'accent sur la disponibilité comme pilier central de la triade CIA
• OWASP souligne la limitation du débit, le contrôle des ressources et la validation des entrées comme défenses web essentielles

La prévention des attaques par déni de service n'est pas une hygiène optionnelle — c'est l'ingénierie de sécurité de base.

Pensées finales

Les attaques DoS exploitent le déséquilibre : des requêtes bon marché contre un traitement coûteux. La solution est de rééquilibrer le système en faveur du défenseur.

Cela signifie :

• Filtrer tôt
• Limiter de manière agressive
• Concevoir pour l'échec
• Observer en continu

La disponibilité est une propriété de sécurité. Les systèmes qui ignorent cette réalité l'apprennent finalement à leurs dépens.

À Evolving Cyber, nous concevons des systèmes en ayant la disponibilité à l'esprit dès le premier jour — car un logiciel sécurisé qui ne peut pas rester en ligne n'est pas du tout sécurisé.

Références

• Attaque par déni de service — Wikipédia
• Aperçu de la protection DDoS de Cloudflare
• Meilleures pratiques de protection DDoS Cloudflare
• Meilleures pratiques AWS pour la résilience face aux attaques DDoS
• Solutions de protection DDoS Akamai
• Les dix principaux risques de sécurité des applications web selon l'OWASP
• Guide CISA sur les DDoS