Protection DDoS : défense en couches

Une attaque par déni de service distribué ne cherche pas à voler vos données. Elle cherche à empêcher vos clients d'entrer, et elle y parvient en saturant la ressource qui s'épuise la première : la bande passante, la table de connexions, le processeur ou le pool de connexions à la base de données.

Aucun produit isolé ne règle donc la question. Chaque famille d'attaque consomme une ressource différente, et chaque couche de défense couvre une défaillance précise. Ce qui suit reprend l'ordre réel dans lequel les couches arrêtent une attaque, puis la séquence à appliquer quand elle est déjà en cours.

Ce qu'une attaque DDoS épuise vraiment

Famille	Exemples	Ce qu'elle sature	Où la bloquer
Volumétrique	Floods UDP, amplification DNS et NTP, balayage de plages	Le lien réseau	En amont, chez l'hébergeur ou dans un réseau de scrubbing
Protocole	SYN flood, ACK flood, floods de connexions	Tables de connexions des serveurs et répartiteurs	Limites en périphérie, réglage du noyau, SYN cookies
Applicatif (L7)	Flood HTTP, cache busting, slowloris, abus d'API	Processeur, workers, connexions à la base	CDN et WAF, cache, limites par route

La conséquence est désagréable : si l'attaque dépasse la taille de votre lien, rien de ce que vous réglez sur le serveur ne compte. Les paquets ont gagné avant qu'une règle locale les voie. La mitigation volumétrique doit donc vivre en amont ; le reste, vous pouvez le durcir vous-même.

Pourquoi les PME sont des cibles rentables

La cible naturelle a longtemps été la grande entreprise. Le calcul de l'attaquant a changé : louer de la capacité d'attaque coûte peu et ne demande aucune compétence réseau. Les panneaux de stress se vendent comme des tests de charge, facturés à l'heure, si bien que le coût d'une tentative est dérisoire.

Une PME réunit exactement ce que ce marché recherche. Personne de garde : une attaque lancée un vendredi soir dispose de douze heures d'avance. Aucune marge d'improvisation : le même prestataire héberge le site, la messagerie et la facturation, donc si le lien tombe, l'activité entière tombe avec lui. Et l'urgence commerciale : un commerce qui ne vend pas pendant trois jours accepte des discussions qu'une entreprise dotée de ses propres centres de données n'écouterait même pas.

S'y ajoute un facteur technique rarement anticipé : en hébergement mutualisé, le voisin attaqué vous emporte. Beaucoup de balayages massifs ne visent d'ailleurs personne en particulier ; ils parcourent des plages entières d'adresses et le commerce présent ce jour-là perd sa matinée. Le panorama annuel de la cybersécurité va dans le même sens : moins de barrières à l'entrée, plus d'incidents de petite taille.

Couche 1 : mitigation en amont, CDN et anycast

Toute défense sérieuse commence par de la capacité que vous ne possédez pas. Un réseau de scrubbing répartit le trafic d'attaque sur des dizaines de points de présence, le filtre et ne renvoie que les requêtes légitimes vers votre serveur.

Placez le trafic public derrière une CDN ou un reverse proxy avec mitigation intégrée (Cloudflare, CloudFront avec Shield, Azure Front Door, Gcore, Bunny ou Fastly).
Demandez à votre hébergeur quelle capacité de mitigation se trouve devant votre adresse IP et si elle est permanente ou déclenchée à la détection. Une protection à la demande laisse un trou au moment précis où tout commence.
Privilégiez l'anycast : il dilue les floods volumétriques géographiquement au lieu de demander à un seul centre de données de les absorber.

L'erreur classique consiste à croire que la CDN suffit. C'est la première couche, pas la seule.

Couche 2 : verrouiller l'IP d'origine

C'est l'étape que presque toutes les équipes sautent, et elle annule silencieusement la précédente. Si l'attaquant découvre l'adresse réelle du serveur, il contourne la CDN et frappe directement l'origine : c'est le direct-to-origin, et cela ne demande aucun outil sophistiqué.

L'adresse d'origine fuit par des chemins très prévisibles : l'historique DNS, avec les anciens enregistrements A d'avant le passage derrière le proxy ; les journaux de transparence des certificats, qui gardent la trace des certificats émis pour le nom d'origine ; les sous-domaines du type mail., vpn., ftp. ou dev., qui pointent souvent vers la même machine ; les en-têtes de courrier, où l'IP apparaît dans les lignes Received: ; et les enregistrements hérités MX, SPF ou TXT qui visent une infrastructure hors CDN.

Que faire : faites tourner l'IP d'origine une fois la CDN en production, limitez le pare-feu aux plages publiées par la CDN sur les ports 80 et 443, puis revérifiez votre exposition chaque trimestre. Dix minutes de contrôle valent mieux que n'importe quelle nouvelle règle.

Couche 3 : WAF et limitation de débit

Un pare-feu réseau voit une connexion TCP valide et la laisse passer. Un WAF lit la requête HTTP, là où se logent les attaques applicatives : requêtes malformées, tentatives d'exploitation, vagues de robots contre le formulaire de connexion ou le moteur de recherche.

Activez d'abord les jeux de règles managés — OWASP et le renseignement de votre fournisseur — puis ajoutez des règles propres à votre application : refus des corps surdimensionnés sur les routes d'upload, challenge sur l'administration, et limites par point d'entrée plutôt que par site entier.

La limitation de débit est le contrôle le plus rentable dont vous disposez, et le plus mal réglé. Une limite posée uniquement sur le serveur web ne sert à rien contre un trafic qui sature d'abord le réseau, et une limite qui ne regarde que l'IP fait peu contre un botnet à des milliers d'adresses sources. Étalez les règles : en périphérie, par IP, par ASN et, le cas échéant, par pays ; dans l'application, par session, par clé d'API et par utilisateur authentifié ; par route, avec des plafonds serrés sur la connexion, la réinitialisation de mot de passe, la recherche et le paiement. Préférez les seaux à jetons ou les fenêtres glissantes aux plafonds fixes par seconde, et renvoyez un 429 accompagné de Retry-After pour que le client légitime recule au lieu d'insister.

Couche 4 : cache, capacité contractuelle et contacts chez le fournisseur

Une requête servie depuis le cache n'atteint jamais l'origine : elle ne consomme ni worker ni connexion à la base. Tout ce qui peut être statique doit l'être, images, CSS, JavaScript et HTML destiné aux visiteurs anonymes compris.

Deux détails comptent pendant l'attaque. Le cache busting est une technique d'attaque : des chaînes de requête aléatoires forcent chaque appel à remonter jusqu'à l'origine, donc configurez la CDN pour ignorer les paramètres inutiles sur les routes cacheables. Et le taux de succès du cache est un indicateur de sécurité : s'il chute de 85 % à 20 % en pleine crise, vous payez le coût d'origine pour du trafic hostile.

La capacité, elle, s'achète par contrat et non par optimisme. Si chaque heure d'indisponibilité vous coûte de l'argent, exigez un SLA de scrubbing, un seuil déclencheur défini, des contacts d'escalade nommés et un niveau de support qui décroche pendant l'attaque ; gardez le numéro de compte là où la personne d'astreinte le trouvera sans chercher. Et si l'attaque joue sur l'état, revenez aux réglages ennuyeux : SYN cookies actifs, tcp_max_syn_backlog et somaxconn ajustés à votre concurrence réelle, plafond de connexions par source en périphérie.

À quoi ressemble une attaque dans les journaux

On ne défend pas ce qu'on ne voit pas. Avant l'incident, notez à quoi ressemble la normale : requêtes par seconde, octets entrants et sortants, part de 4xx et de 5xx, latence p95, connexions ouvertes, URL les plus demandées. Ensuite, alertez sur l'écart et non sur la valeur absolue : un pic à cinq fois le trafic habituel avec un taux d'erreur stable ressemble à une campagne marketing qui fonctionne, tandis qu'un volume plat avec latence et connexions qui montent sent l'épuisement d'état.

Les signaux qui reviennent presque toujours :

Une seule URL concentrant une part anormale du trafic : recherche, connexion ou point d'entrée d'API.
Des milliers d'adresses différentes avec la même signature d'agent utilisateur, ou aucune.
Une latence qui grimpe alors que le nombre d'utilisateurs uniques ne bouge pas.
Un trafic entrant très supérieur à ce que le serveur déclare avoir servi.
Des erreurs 499, 502 et 504 sur le répartiteur et des délais dépassés côté base.

Ces schémas correspondent aux mêmes tactiques et techniques adverses que documente tout rapport d'incident.

Séquence d'incident : détecter, contenir, communiquer, revoir

Détecter. Confirmez qu'il s'agit d'une attaque et non d'une campagne qui marche. Regardez la composition du trafic avant de bloquer quoi que ce soit.

Contenir. Ouvrez un ticket chez l'hébergeur ou le support de la CDN immédiatement : la mitigation en amont met du temps à s'activer. Activez ensuite le mode under attack, les règles managées, des limites resserrées et un challenge JavaScript sur les routes les plus touchées, puis vérifiez que l'origine n'accepte plus que le trafic de la CDN.

Communiquer. La page de statut d'abord, les canaux de support ensuite. Le silence fait plus de dégâts que l'attaque : un client informé attend, un client laissé sans nouvelles s'en va.

Revoir. À froid, reconstituez la chronologie, identifiez la couche qui a lâché en premier et le coût réel de l'heure d'indisponibilité. Mettez le runbook à jour et conservez journaux, captures de paquets et horodatages : ils servent à l'hébergeur, à l'assureur et à toute réclamation ultérieure.

Check-list avant l'attaque

Contrôle	État attendu	Comment le vérifier
Mitigation en amont	CDN ou scrubbing devant tout le trafic public	Résolution DNS depuis l'extérieur du réseau
IP d'origine	Renouvelée, pare-feu limité aux plages de la CDN	Scan externe et historique DNS
WAF	Règles managées plus règles maison	Test contrôlé sur une route protégée
Limites de débit	Périphérie, application et routes coûteuses	Test de charge à seuil connu
Visibilité	Alertes RPS, erreurs, latence, connexions	Exercice d'alerte
Runbook	Une page, à jour, avec des responsables nommés	Lecture à voix haute par un non-rédacteur

Chaque case vide est une brèche concrète. Si vous préférez ne pas improviser la suivante, parlons de votre situation et regardons votre exposition avant le prochain pic.

Plainte et obligations légales en France

Une attaque DDoS n'est pas une farce : c'est une infraction pénale. L'article 323-2 du Code pénal réprime le fait d'entraver ou de fausser le fonctionnement d'un système de traitement automatisé de données, et l'article 323-1 vise l'accès frauduleux à un tel système ; les peines sont aggravées lorsque les faits concernent des données personnelles ou un système d'intérêt public. La voie pénale existe donc, mais elle réclame des preuves plutôt que de l'indignation.

L'ordre est toujours le même : on préserve d'abord les éléments — journaux horodatés, captures de paquets, copie du message d'extorsion s'il y en a un — puis on notifie. Si le service touché traite des données personnelles, le RGPD impose d'évaluer la notification à la CNIL dans les 72 heures suivant la prise de connaissance de la violation. En parallèle, l'ANSSI, via son CERT-FR, coordonne le traitement des incidents signalés, et le dépôt de plainte se fait auprès de la police ou de la gendarmerie, de préférence accompagné des journaux.

Rien de cela n'arrête l'attaque à soi seul. En revanche, cela transforme l'incident en dossier : utile pour l'assureur, pour la relation avec l'hébergeur, et pour expliquer à un client ce qui s'est passé et quand.

Questions fréquentes

Peut-on empêcher totalement une attaque DDoS ?

Non. N'importe qui peut envoyer du trafic vers un service public, et cette asymétrie ne se referme pas. L'objectif réaliste est d'absorber et de filtrer sans faire tomber les utilisateurs légitimes.

Une CDN suffit-elle à arrêter une attaque DDoS ?

Elle absorbe les floods volumétriques et une bonne part de l'abus applicatif, mais elle ne corrige ni l'exposition de l'origine ni l'épuisement d'état. C'est une couche, pas la solution.

Comment distinguer une attaque d'un pic légitime ?

Regardez la composition, pas le volume. Un pic concentré sur une zone géographique ou une seule URL, avec des agents utilisateur étranges, une latence qui monte et un taux de conversion plat, est une attaque ; un pic réparti sur vos sources habituelles est souvent une campagne qui fonctionne.

Que doit faire une PME en premier ?

Placer le trafic derrière une CDN avec mitigation, verrouiller l'IP d'origine, activer les règles managées du WAF et écrire un runbook d'une page.

Faut-il un prestataire de mitigation dédié ?

Seulement si l'heure d'indisponibilité coûte plus cher que le contrat. Commencez par l'offre CDN, mesurez votre exposition réelle, montez d'un cran quand les chiffres le justifient.

Lectures liées

Si vous voulez qu'un tiers relise votre configuration de périphérie, vos limites et votre runbook avant le prochain incident, parlons de votre situation.