Protection anti-DDoS : comprendre et se protéger

Une protection DDoS pour site web vise à empêcher qu'une attaque par déni de service ne rende votre site inaccessible. Ces attaques sont simples à comprendre, mais leurs conséquences peuvent être lourdes : un site qui ne répond plus, des clients qui partent et une réputation ternie. Voici comment elles fonctionnent et les moyens éprouvés pour les contenir.

Qu'est-ce qu'une attaque DDoS et comment s'en protéger ?

DDoS signifie « déni de service distribué » (Distributed Denial of Service). Le principe consiste à submerger un serveur ou un réseau sous un tel flot de trafic qu'il ne parvient plus à répondre aux visiteurs légitimes.

Ce qui rend l'attaque « distribuée », c'est qu'elle n'émane pas d'une seule machine, mais de milliers d'appareils compromis — ordinateurs, serveurs ou objets connectés — pilotés à distance. Cet ensemble forme un réseau de machines zombies (botnet). Chaque appareil envoie des requêtes vers votre serveur, et l'accumulation massive finit par saturer les ressources.

Volumétrique ou applicative ?

On distingue deux grandes familles d'attaques, qui ne se neutralisent pas de la même façon.

Une attaque volumétrique vise à saturer la bande passante ou les capacités réseau : un volume de trafic supérieur à ce que la liaison peut absorber est injecté. Le serveur, même surdimensionné, devient injoignable car le canal réseau est congestionné.

Une attaque applicative cible directement la couche logicielle (couche 7) : les requêtes semblent légitimes, mais sollicitent intensément les ressources de calcul — par exemple des milliers d'appels simultanés sur une page lourde avec requêtes en base de données, ou une attaque « HTTP flood » qui multiplie les requêtes jusqu'à épuiser le processeur ou la mémoire.

La nuance est capitale : une attaque volumétrique se filtre en amont, au niveau du réseau, tandis qu'une attaque applicative exige d'inspecter le contenu même des requêtes.

Un exemple concret : une boutique en ligne victime d'une attaque volumétrique voit sa liaison réseau saturée et devient injoignable pour l'ensemble des visiteurs, sans qu'aucune requête n'ait nécessairement atteint le serveur web. À l'inverse, lors d'un « HTTP flood », les requêtes paraissent normales, mais leur volume excessif épuise le serveur applicatif, alors même que le réseau dispose encore de bande passante libre.

Le rôle du pare-feu applicatif (WAF)

Le pare-feu applicatif, ou WAF (Web Application Firewall), filtre le trafic HTTP/HTTPS en appliquant un ensemble de règles de sécurité. Il intercepte les requêtes correspondant à des schémas d'attaque connus — injections SQL, failles XSS, tentatives d'exploitation de vulnérabilités applicatives — avant qu'elles n'atteignent votre code.

C'est un complément indispensable, mais pas une solution unique : un WAF bien configuré écarte une grande partie du trafic malveillant applicatif, mais ne peut absorber à lui seul une saturation purement volumétrique. Ces deux couches de protection doivent impérativement se combiner.

CDN et absorption du trafic

Un CDN (Content Delivery Network) distribue vos contenus statiques (pages mises en cache, images, feuilles de style) depuis des serveurs relais situés au plus près des visiteurs. Face à une attaque, il joue un rôle stratégique : il absorbe et disperse le trafic sur une infrastructure mondiale massivement distribuée, ce qui dilue l'impact d'une attaque volumétrique bien avant qu'elle n'atteigne votre serveur d'origine.

C'est pourquoi de nombreuses architectures placent un CDN doté d'un pare-feu applicatif en coupure devant l'infrastructure : le trafic est filtré et mis en cache en périphérie réseau, et votre serveur d'origine ne traite que le trafic résiduel légitime. C'est le principe de la brique « CDN et pare-feu applicatif » intégrée à l'architecture haute disponibilité d'Atlas Hoster.

Limitation de débit et listes de blocage

Deux mécanismes complémentaires renforcent ce dispositif.

La limitation de débit (rate limiting) restreint le nombre de requêtes qu'une adresse IP ou un client peut émettre dans un intervalle de temps donné. Au-delà du seuil fixé, les requêtes excédentaires sont ralenties ou rejetées avec un code d'erreur HTTP 429. Ce mécanisme est particulièrement efficace contre les attaques applicatives fondées sur la répétition massive.

Les listes de blocage permettent de rejeter immédiatement le trafic en provenance d'adresses IP ou de sous-réseaux identifiés comme malveillants. C'est une mesure réactive, utile pendant un incident : notre guide sur le blocage d'une IP ou d'un domaine détaille sa mise en œuvre.

Par exemple, limiter une même adresse à quelques dizaines de requêtes par seconde permet d'écarter l'essentiel des attaques automatisées sans pénaliser la navigation des visiteurs légitimes.

Que faire pendant une attaque ?

Si votre site subit une attaque, procédez méthodiquement par étapes :

1. Confirmez qu'il s'agit bien d'une attaque (pic soudain de trafic atypique) et non d'une hausse d'audience légitime.
2. Activez les protections disponibles : limitation de débit, listes de blocage ou mode d'urgence « sous attaque » de votre CDN.
3. Prévenez votre hébergeur : son équipe technique peut intervenir au niveau du réseau ou du routage pour mitiger le flux.
4. Surveillez le retour à la normale, puis analysez les journaux d'accès pour adapter durablement vos règles de sécurité.

Conservez une trace détaillée de l'incident : les journaux réseau et serveur serviront à documenter l'événement et à affiner vos seuils de détection.

Si vous hébergez plusieurs sites sur un même compte, une attaque visant l'un d'eux peut dégrader les performances des autres. Isoler chaque application ou séparer les environnements — voir notre guide sur les domaines additionnels — évite la propagation de l'indisponibilité.

La meilleure défense demeure l'anticipation : une architecture conçue pour absorber les pics et filtrer le trafic hostile retrouve sa disponibilité bien plus rapidement. Sécurité et performance vont de pair : consultez notre article sur la haute disponibilité, notre guide de sécurité WordPress ainsi que notre article sur le passage en HTTPS.

Pour un hébergement déployant un CDN avec pare-feu applicatif devant votre infrastructure, découvrez l'offre haute disponibilité d'Atlas Hoster.

Les pièges à éviter

• Confondre pic légitime et attaque : une campagne marketing ou une mention dans les médias peut générer un afflux massif. Analysez la nature des requêtes avant d'appliquer des blocages stricts.
• Penser qu'un outil unique suffit : le WAF inspecte les requêtes applicatives, mais n'atténue pas la saturation de la bande passante. Les couches de défense doivent être cumulées.
• Attendre l'incident pour agir : les règles de filtrage et le routage sécurisé se préparent en amont.
• Bloquer trop largement : un filtrage géographique ou une liste de blocage mal calibrée risque d'écarter des clients légitimes.

Questions fréquentes

Une attaque DDoS peut-elle entraîner le vol de données ?

En principe, non. Une attaque DDoS cherche à saturer les ressources pour rendre le service indisponible, et non à dérober des données. Néanmoins, une attaque DDoS est parfois utilisée comme diversion pour détourner l'attention pendant une tentative d'intrusion ciblée : restez vigilant.

Un site à faible trafic peut-il être ciblé ?

Oui. La plupart des attaques sont automatisées et lancées par des outils scannant aveuglément le réseau. Tout site accessible en ligne peut être pris pour cible, que ce soit par opportunisme ou par erreur de ciblage.

Mon hébergeur me protège-t-il automatiquement ?

Cela dépend du niveau de service souscrit. La plupart des hébergeurs proposent une mitigation réseau élémentaire face aux très gros volumes, mais la protection fine contre les attaques applicatives nécessite souvent un CDN spécialisé et un WAF managé. Vérifiez les garanties de votre contrat avant d'y être confronté.