Défendre un DDoS volumétrique et applicatif

Défendre un DDoS volumétrique et applicatif

Un déni de service distribué, ou DDoS (Distributed Denial of Service), vise à rendre un service indisponible en épuisant une ressource : bande passante, connexions, processeur, mémoire, files de traitement ou capacité d’une dépendance. La frontière entre attaque volumétrique et attaque applicative détermine l’emplacement de la défense, les métriques à surveiller et, surtout, ce qui cassera en premier.

Explication de la marmotte

Une attaque par saturation ressemble à une foule qui bloque toutes les entrées d’un magasin, tandis qu’une autre remplit le magasin avec des clients qui posent chacun une question interminable. Dans les deux cas, les vrais clients repartent, mais la réponse à apporter n’est pas la même.

→ Lire l’explication complète de la marmotte

DDoS volumétrique : saturer avant le service

Un DDoS volumétrique cherche à remplir les liens réseau en amont du service. L’attaquant n’a pas besoin de connaître l’application, son objectif est plus rustique : transmettre davantage de trafic que le lien, le pare-feu ou l’équipement de bordure ne peut absorber. Un serveur parfaitement dimensionné derrière une liaison saturée devient une décoration coûteuse.

Les attaques par réflexion et amplification exploitent des serveurs accessibles publiquement et mal configurés. L’attaquant usurpe l’adresse de la victime, envoie une petite requête à ces serveurs, puis les réponses convergent vers la cible. Le DNS (Domain Name System) et NTP (Network Time Protocol) ont longtemps servi à ce jeu, avec des réponses significativement plus volumineuses que les requêtes. Le mécanisme dépend de l’usurpation d’adresse source, donc du défaut de filtrage des paquets sortants par les réseaux émetteurs.

La détection repose sur des signaux relativement francs : hausse brutale des bits par seconde, des paquets par seconde, des flux UDP (User Datagram Protocol) entrants, ou déséquilibre entre trafic entrant et sortant. Les données de flux, comme NetFlow ou IPFIX (Internet Protocol Flow Information Export), permettent d’identifier les préfixes sources, protocoles et ports dominants sans capturer chaque paquet. Ce n’est pas une enquête philosophique : si le lien est plein, l’analyse locale arrive trop tard.

La défense primaire doit vivre hors du lien à protéger. Un fournisseur de mitigation en amont, souvent opéré via un CDN (Content Delivery Network), un transit scrubbing ou une annonce BGP (Border Gateway Protocol) redirigée vers un centre de nettoyage, absorbe et filtre le trafic avant sa livraison. Sans capacité externe contractualisée et testée, la promesse de filtrer sur site revient à vider une baignoire avec une cuillère alors que l’arrivée d’eau est sur le toit.

Le compromis est net : déléguer l’absorption réduit l’autonomie et introduit une dépendance réseau, mais protège la connectivité elle-même. Pour un service exposé à Internet avec une disponibilité métier réelle, ce compromis doit être accepté. Une protection locale seule ne couvre pas la saturation du dernier kilomètre ni celle des équipements opérateur.

Consulter aussi les menaces traitées par le site et les fondations de l’architecture réseau : un DDoS n’est jamais seulement un problème d’adresse IP, il révèle aussi les dépendances oubliées derrière l’adresse.

DDoS applicatif de couche 7 : épuiser le traitement

Un DDoS applicatif cible la couche 7 du modèle OSI (Open Systems Interconnection), celle où le service interprète une requête HTTP (Hypertext Transfer Protocol), applique des règles métier, interroge des dépendances et construit une réponse. Chaque requête peut être syntaxiquement valide, suivre une session existante et passer le chiffrement TLS (Transport Layer Security). Le trafic paraît normal jusqu’au moment où les pools de connexions, les workers ou la base de données cessent de répondre.

La cible la plus rentable est un chemin coûteux et peu borné : recherche textuelle sans limite, export de données, filtre combinatoire, génération de document, validation de jeton distante, récupération d’image à la volée. Une requête qui déclenche un scan complet de table ou une agrégation non indexée coûte davantage qu’une page statique. Multiplier cette requête depuis des clients distribués suffit à dégrader le service sans produire un pic de bande passante spectaculaire.

C’est pourquoi une alerte sur le débit réseau ne détecte pas ce type d’attaque. Les indicateurs déterminants sont le taux de requêtes par route, la latence par percentile, le nombre de requêtes en cours, la saturation des pools de connexions, les erreurs 429 et 503, la durée des requêtes en base et la profondeur des files asynchrones. Une moyenne de latence masque très bien un effondrement : le percentile 99 montre les clients sacrifiés pendant que la moyenne joue les innocents.

La détection doit comparer le comportement à une base de référence segmentée. Une route d’authentification ne se mesure pas comme un catalogue, un export ne se mesure pas comme une consultation, et un client authentifié ne se mesure pas comme une adresse anonyme. Segmenter par route, méthode, identité, jeton d’accès, clé d’API (Application Programming Interface), région et statut de réponse évite de confondre une campagne ciblée avec un pic légitime.

Le piège classique consiste à bloquer des adresses IP. Derrière un réseau mobile, une entreprise ou un relais partagé, une adresse peut représenter des centaines de personnes. À l’inverse, un botnet distribue une requête par adresse et rend cette limite presque décorative. La limitation par identité est plus précise après authentification ; avant authentification, il faut combiner adresse source validée, empreinte de session, réputation, preuve de travail éventuelle et quotas très stricts sur les routes coûteuses.

Limitation de débit applicative et admission contrôlée

Le rate limiting, ou limitation de débit, décide quelles requêtes peuvent entrer dans un budget donné. Ce n’est pas un pare-feu magique, contrairement à certaines slides où trois icônes de nuage résolvent aussi la météo. Il doit être défini par ressource protégée et par coût de traitement.

Un limiteur à fenêtre glissante ou à seau à jetons accepte un débit moyen tout en autorisant une rafale bornée. La clé de comptage doit correspondre à l’abus attendu : adresse IP pour une page publique légère, identifiant de compte pour une route authentifiée, clé API pour un partenaire, combinaison d’identité et de route pour un export. Pour une recherche coûteuse, limiter seulement le nombre de requêtes est insuffisant : imposer une taille maximale de requête, une pagination bornée, un délai maximal côté base et un coût maximal par appel.

La défense recommandée suit trois niveaux :

1. Filtrer en amont les anomalies grossières et absorber le volume avant l’infrastructure.
2. Appliquer à la passerelle des quotas par route et par identité, avec réponses 429 documentées et en-têtes Retry-After.
3. Borner le coût dans l’application et les dépendances : délais d’expiration, limites de concurrence, cache, index, coupe-circuit et files séparées.

Le compromis central oppose disponibilité immédiate et protection de capacité. Une limite trop basse rejette une montée en charge légitime ; une limite trop haute préserve l’illusion d’ouverture jusqu’à la chute générale. La bonne décision dépend de la capacité réservée par classe de service et du coût réel de chaque route. Les opérations vitales doivent disposer de budgets isolés, pas seulement d’un droit moral à passer devant.

Exemple : limiter une recherche coûteuse avec NGINX

NGINX peut appliquer une limitation avant que la requête n’atteigne l’application. Cette configuration suppose que le proxy reçoit l’adresse cliente réelle uniquement depuis un répartiteur connu. Sans cette condition, le client peut fournir un en-tête falsifié et choisir son propre quota, ce qui est une forme de démocratie assez peu souhaitable.

# Déclarer uniquement les réseaux des reverse proxies de confiance.
set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

# Autoriser 10 recherches par minute et une rafale de 3 par adresse cliente.
# La zone partagée conserve les compteurs entre workers NGINX.
limit_req_zone $binary_remote_addr zone=search_per_ip:10m rate=10r/m;

server {
    listen 443 ssl;
    server_name api.example.test;

    location = /api/search {
        limit_req zone=search_per_ip burst=3 nodelay;
        limit_req_status 429;

        proxy_pass http://application_upstream;
        proxy_read_timeout 5s;
    }
}

Tester depuis une machine de laboratoire avec une boucle curl permet de vérifier la réponse 429, mais ne valide pas la protection distribuée. Pour une route authentifiée, déplacer le compteur dans la passerelle applicative ou un magasin partagé, par exemple Redis, afin d’utiliser l’identifiant du compte plutôt que l’adresse. Le magasin de compteurs devient alors une dépendance critique : une indisponibilité doit conduire à une politique explicite, soit refuser temporairement les requêtes coûteuses, soit appliquer un quota local conservateur. Laisser passer sans limite au moindre incident de Redis revient à installer un coupe-circuit qui accélère quand le moteur fume.

Surface d’attaque, supervision et continuité

Une mitigation DDoS ne garantit ni la disponibilité de l’origine, ni la sécurité des comptes, ni l’intégrité des données. Un fournisseur en amont filtre le volume, mais une requête légitime peut toujours épuiser une base de données. Un rate limiter protège une route, mais ne corrige pas une requête SQL (Structured Query Language) non indexée. La disponibilité dépend aussi des zones DNS, certificats TLS, fournisseurs d’identité, files de messages et services tiers.

L’origine ne doit accepter le trafic qu’en provenance des plages documentées du fournisseur de protection. Sinon, l’attaquant contourne la protection en visant directement l’adresse d’origine. Cette règle impose une gestion rigoureuse des changements de plages, des entrées DNS et des règles de pare-feu. Une adresse d’origine exposée par un ancien enregistrement DNS ou un dépôt de configuration annule des semaines de réunions sur la résilience.

La supervision doit corréler les métriques réseau, proxy, application et dépendances. Déclencher uniquement sur les erreurs 5xx détecte l’incendie après l’effondrement. Déclencher sur une hausse de latence, de concurrence, de refus 429 et de requêtes coûteuses permet de dégrader volontairement avant la panne. Les journaux doivent conserver route, statut, durée, identité pseudonymisée et identifiant de corrélation, sans enregistrer les jetons d’accès ou en-têtes d’autorisation. Un journal qui stocke des secrets transforme un incident de disponibilité en incident de confidentialité, parce qu’une crise seule manquait manifestement de variété.

Le plan de continuité doit préciser qui active la mitigation amont, comment basculer les enregistrements DNS, quelles routes désactiver, quels quotas durcir et comment préserver les opérations prioritaires. Tester ce plan exige un environnement isolé, des scénarios de charge contrôlés et des critères de sortie mesurables. Une sauvegarde ne restaure pas une capacité de traitement, et une procédure non exercée n’est qu’un document qui attend son moment de gloire.

🐝 Ce qui arrive si on s’en passe

Sans défense en couches, la porte reste ouverte et l’indisponibilité se paie ailleurs que sur le lien réseau. Une saturation prolongée fait expirer les sessions et les renouvellements automatiques de certificats, retarde les tâches planifiées et provoque des rejeux massifs côté clients, qui amplifient la charge au moment du retour du service. Les files asynchrones accumulent un arriéré que la reprise ne résorbe pas sans priorisation, et les traitements partiellement exécutés laissent des états incohérents à réconcilier manuellement. Les journaux, submergés, sont échantillonnés ou tronqués : la traçabilité de l’incident disparaît en même temps que la capacité à distinguer une attaque d’un pic légitime. Une facturation au trafic ou à l’appel peut aussi transformer l’attaque en coût direct, sans plafond automatique pour l’interrompre.

🦫 Explication de la marmotte 🍫

Une attaque par déni de service cherche à empêcher les personnes normales d’utiliser un site ou une application. Dans une attaque volumétrique, de très nombreuses machines envoient des données vers la cible. Le lien réseau ou les équipements placés avant le service reçoivent plus de données qu’ils ne peuvent transmettre. Le service peut alors fonctionner correctement, mais personne ne parvient à l’atteindre.

Une autre forme d’attaque envoie des demandes qui ont l’air normales. Elles peuvent demander une recherche, un export ou une connexion. Chaque demande oblige le service à utiliser du processeur, de la mémoire ou une base de données. Si ces opérations sont coûteuses et nombreuses, les ressources se remplissent jusqu’à ce que les demandes ordinaires attendent trop longtemps ou échouent.

La première défense doit arrêter le trafic massif avant l’accès Internet de l’organisation. Ensuite, le service doit compter les demandes et refuser temporairement celles qui dépassent une limite. Les limites doivent être différentes selon l’action demandée et selon la personne ou le programme qui fait la demande.

Il faut aussi limiter le coût de chaque action : réduire la taille des recherches, arrêter les traitements trop longs et séparer les fonctions prioritaires des fonctions secondaires. Enfin, une équipe doit surveiller la vitesse, les erreurs et les temps d’attente. Si les limites ou le fournisseur de protection échouent, le plan prévu doit permettre de désactiver certaines fonctions pour préserver celles qui restent indispensables.

À lire aussi

• Menaces réseau, détection et réponse opérationnelleRelier attaques réseau, détection, triage, réponse à incident, DDoS et exploitation SOC sans transformer le site en manuel offensif.
• Sécuriser une API gateway comme point de contrôleArchitecture de sécurité d'une API gateway comme point de contrôle centralisé, avec ses limites, ses attaques et ses conditions d'exploitation.
• Empoisonnement de cache DNS de Kaminsky à SAD DNS et paradesComment une réponse forgée entre dans le cache d'un résolveur DNS, de l'attaque de Kaminsky de 2008 aux variantes récentes, et ce qu'arrêtent réellement la randomisation des ports, le codage 0x20, les cookies et DNSSEC.
• Attaque cache deception CDN et contre-mesuresDémonstration en laboratoire de l’attaque cache deception contre un CDN, ses conditions, ses impacts et les contre-mesures d’architecture.

Pages voisines

La citent

• Empoisonnement de cache DNS de Kaminsky à SAD DNS et parades
• Menaces réseau, détection et réponse opérationnelle
• BGP, Internet, anycast et sécurité des annonces
• Données, signaux, latence et fiabilité
• Sécuriser les caméras IP et le stockage vidéo cloud
• Sécuriser un load balancer cloud et la terminaison TLS

Défendre un DDoS volumétrique et applicatif

Elle cite

• ⇄Lien dans les deux sens :Comment contourner un rate limit par rotation d’en-têtes
• Circuit breaker et bulkhead contre la propagation des pannes
• Mettre en place un rate limiting anti-DDoS L7

⇄ : les deux pages se citent l’une l’autre.