Qu'est-ce qu'une attaque DDoS par inondation HTTP ?

Qu'est-ce qu'une attaque DDoS par inondation HTTP ?

Une inondation HTTP (HTTP flood) est une attaque DDoS au niveau de la couche applicative (couche 7). De nombreuses machines envoient des requêtes HTTP GET ou POST d'apparence ordinaire à un serveur web ou à une API, jusqu'à ce qu'il ne reste plus de capacité pour les vrais utilisateurs. Chaque requête est du HTTP valide : il n'y a aucun paquet malformé à écarter. Le dommage vient du travail que chaque requête déclenche sur le serveur, pas de la bande passante utilisée.

C'est une forme d'attaque DDoS applicative, qui fait partie de la famille plus large du déni de service distribué (DDoS). Cette entrée explique comment fonctionnent les inondations et comment s'en défendre. Ce n'est pas un guide pour en lancer une : attaquer des systèmes qui ne vous appartiennent pas est illégal.

Comment fonctionne une inondation HTTP

• Un botnet envoie le trafic. Les requêtes arrivent d'un très grand nombre d'appareils compromis ou de machines louées, si bien qu'aucune adresse IP ne se détache.
• Les requêtes semblent normales. Les en-têtes, les méthodes et les URL sont valides, et le user-agent est souvent copié d'un vrai navigateur.
• Les points d'accès coûteux sont visés. La recherche, les listes filtrées, la connexion et les recommandations coûtent bien plus cher au serveur qu'un fichier statique : un débit de requêtes modeste suffit à épuiser les processus de travail ou les connexions à la base de données.
• Le cache est contourné. Ajouter un paramètre aléatoire à chaque URL (par exemple ?q=chaussures&_=83721) fait paraître chaque requête nouvelle : elle traverse le CDN et atteint votre serveur d'origine.

Une inondation GET frappe les points d'accès en lecture. Une inondation POST frappe ceux en écriture, comme l'inscription ou le formulaire de contact, et pèse souvent plus lourd sur la base de données. Les attaques lentes comme Slowloris et RUDY sont voisines mais fonctionnent autrement : elles gardent des connexions ouvertes avec très peu de trafic, au lieu de produire un débit de requêtes élevé.

Exemple : une inondation sur une page de recherche

Prenons une boutique dont le point d'accès /search exécute une requête non mise en cache sur la base de données. Un jour normal, il traite quelques requêtes par seconde. Pendant une inondation, des milliers de clients appellent /search avec un terme aléatoire différent à chaque fois. Chaque requête manque le cache, le pool de connexions à la base se remplit et les appels du paiement commencent à expirer. Les navigateurs et les applications réessaient, ce qui ajoute de la charge. Rien n'a été « piraté » : le site a simplement manqué de capacité, c'est pourquoi les premiers signes sont généralement des réponses lentes et un taux d'erreurs en hausse.

Pourquoi les inondations HTTP sont difficiles à arrêter

• Elles ressemblent à un pic de trafic. Une rafale de requêtes venant de nombreuses IP peut être une campagne ou une inondation. Bloquer trop fort fait perdre des clients, bloquer trop peu laisse le site à terre.
• Le coût est déséquilibré. Une petite requête peut déclencher une requête de base de données et plusieurs appels en aval.
• L'autoscaling peut alourdir la facture. Si vous montez en charge selon le nombre de requêtes, vous risquez de payer pour servir le trafic de l'attaque. Fixez un maximum.

Comment se défendre contre une inondation HTTP

• Placer un point d'entrée en périphérie devant l'origine. Un CDN sert le contenu pouvant être mis en cache et absorbe les rafales avant qu'elles n'atteignent vos serveurs.
• Utiliser la limitation de débit du WAF. Un pare-feu applicatif web compte les requêtes par source et limite celles qui arrivent trop vite. Par exemple, les règles basées sur le débit d'AWS WAF regroupent les requêtes selon les critères que vous choisissez et appliquent une action quand une limite est dépassée.
• Soumettre les clients suspects à un défi. Un défi JavaScript ou un CAPTCHA filtre les robots qui n'exécutent pas de navigateur.
• Mettre en cache et normaliser les URL. Ignorez les paramètres qui ne changent pas la réponse pour que le contournement du cache ne marche plus.
• Limiter par session et par compte, pas seulement par IP, car un botnet change d'adresse.
• Protéger les points d'accès coûteux. Des délais d'expiration, un circuit breaker ou une réponse de secours en cache évitent qu'une dépendance lente fasse tomber tout le site.

Le plan pas à pas se trouve dans comment arrêter les attaques DDoS.

Erreurs courantes

• Limiter le débit uniquement par adresse IP.
• Fixer une limite sous votre vrai pic, de sorte qu'un lancement de produit la déclenche.
• Mettre en cache les fichiers statiques mais pas les pages coûteuses qui se trouvent derrière.
• Ne pas avoir de référence, si bien que personne ne sait à quoi ressemble « le double du débit normal ».
• Attendre que les clients signalent la panne.

Inondations HTTP, tests de charge et monitoring

Un test de charge n'est pas une simulation d'attaque et ne remplace ni un WAF ni une protection DDoS. Il peut en revanche montrer où votre propre application manque de capacité sous un trafic élevé mais légitime : quel point d'accès ralentit en premier, et si les limites et le cache se comportent comme prévu. Ne testez que des systèmes qui vous appartiennent ou pour lesquels vous avez une autorisation écrite, de préférence en préproduction. LoadFocus exécute des tests de charge avec JMeter et k6 depuis des régions cloud, et l'offre gratuite autorise jusqu'à 10 utilisateurs virtuels. La différence entre les deux types de tests est expliquée dans test de charge ou test de stress.

Le monitoring détecte une inondation tôt. Déclenchez des alertes sur le débit de requêtes, le taux d'erreurs et la latence p95 par rapport à une référence, et surveillez vos points d'accès publics avec le monitoring d'API. Si une limite bloque de vrais clients, ce guide sur la limitation de débit des API aide à lire les réponses 429. Les fournisseurs cloud ont leurs propres règles pour les simulations DDoS : AWS ne les autorise que via des partenaires agréés ou après accord préalable.

Questions fréquentes : attaques DDoS par inondation HTTP

Quelle différence entre une inondation HTTP et une attaque volumétrique ?

Une attaque volumétrique cherche à saturer la bande passante de votre réseau avec du trafic brut. Une inondation HTTP envoie des requêtes valides et épuise les ressources du serveur, comme les processus de travail, les connexions à la base de données et les quotas des API en aval, souvent avec bien moins de bande passante.

Comment distinguer une inondation HTTP d'un pic de trafic viral ?

Regardez la forme du trafic. Les pics organiques se concentrent généralement sur quelques pages, avec des référents, des navigateurs et des régions variés, et des visiteurs qui naviguent et achètent. Les inondations sont plutôt uniformes : user-agents similaires, URL étranges avec des paramètres aléatoires, pas de référent et pas de conversions.

Un CDN arrête-t-il une inondation HTTP ?

Il aide pour le contenu pouvant être mis en cache, mais les paramètres de contournement du cache et les points d'accès dynamiques atteignent toujours votre origine. Combinez le CDN avec la limitation de débit du WAF, des défis et des limites dans l'application.

Faut-il limiter le débit par IP ou par session ?

Les deux. Les limites par IP arrêtent les sources isolées, et les limites par session ou par compte arrêtent un botnet qui répartit les requêtes sur de nombreuses adresses.

Puis-je tester mon site face à une inondation HTTP ?

Vous pouvez tester la charge de votre propre application pour trouver ses limites de capacité, avec autorisation et de préférence en préproduction. Une vraie simulation DDoS est un service à part que les fournisseurs encadrent : demandez à votre fournisseur avant d'exécuter quoi que ce soit qui imite une attaque.