Qu'est-ce qu'une attaque DDoS applicative ?

Qu'est-ce qu'une attaque DDoS applicative ?

Une attaque DDoS applicative, aussi appelée attaque de couche 7 ou L7, submerge une application web ou une API de requêtes qui ressemblent à celles d'utilisateurs normaux. Au lieu de saturer le réseau, elle épuise ce dont l'application a besoin pour répondre : threads de travail, CPU, connexions à la base de données et mémoire. Chaque requête est petite, si bien que le volume de trafic seul trahit à peine l'attaque.

C'est le cousin discret des attaques volumétriques, qui saturent la bande passante aux couches 3 et 4. Voir la vue d'ensemble du DDoS et l'entrée sur le HTTP flood, la forme L7 la plus courante.

Comment fonctionnent les attaques applicatives

L'attaquant contrôle un botnet d'appareils compromis ou de machines cloud louées. Chaque bot envoie des requêtes peu coûteuses à émettre et coûteuses à traiter. Schémas courants :

• HTTP flood : un débit élevé de requêtes GET ou POST vers des endpoints coûteux comme la recherche, la connexion ou une page d'accueil dynamique.
• Slowloris : de nombreuses connexions maintenues ouvertes en envoyant les en-têtes extrêmement lentement, jusqu'à ce que le serveur n'ait plus de place libre.
• RUDY (R-U-Dead-Yet) : la même idée avec le corps des requêtes POST, envoyé au compte-gouttes.
• Cache busting : une chaîne de requête unique à chaque appel (?x=8841) pour qu'un CDN ne puisse pas répondre depuis son cache et que chaque requête atteigne votre origine.
• Abus d'API : appels répétés à des endpoints coûteux (rapports, exports, agrégations) qu'aucun utilisateur réel n'appellerait aussi souvent.

Exemple : un endpoint de recherche

Supposons que /search?q=... exécute une requête sans cache de 200 ms et que votre appli ait 20 workers. Cela fait au mieux environ 100 recherches par seconde (chiffres à titre d'illustration). Un botnet qui envoie 150 recherches par seconde n'atteint jamais votre limite de bande passante, pourtant le pool de workers est plein, la file grandit et les vrais visiteurs voient des timeouts et des erreurs 503. La courbe de trafic paraît banale ; celle de la latence, non.

Pourquoi la couche 7 est plus difficile à défendre que les couches 3/4

• Chaque requête est valide. Rien de malformé, rien à rejeter en bordure de réseau.
• Les bots ressemblent à des navigateurs. Avec des user agents réalistes, bloquer par UA est peu efficace.
• Les sources sont dispersées. Les botnets utilisent de nombreuses adresses, bloquer les IP une à une revient à courir après des fantômes.
• Le normal dépend de votre appli. Il faut connaître votre débit habituel par session et par endpoint pour repérer l'anormal.

Comment se défendre

• Limiter le débit en bordure et dans l'appli. Un pare-feu applicatif web (WAF) peut limiter par IP, session et endpoint. Gardez aussi une limite côté application au cas où du trafic contournerait la bordure. Répondez avec 429 Too Many Requests et un en-tête Retry-After. Le guide sur la limitation de débit des API détaille causes et solutions.
• Challenger les clients suspects. Un CAPTCHA ou un défi JavaScript écarte les bots simples avant qu'ils n'atteignent du code coûteux.
• Mettre en cache ce qui peut l'être. Cachez les réponses GET anonymes et laissez les cookies hors de la clé de cache pour les pages non personnalisées.
• Rendre les endpoints coûteux moins chers. Index, limites de pagination et timeouts évitent qu'une requête immobilise un worker longtemps.
• Surveiller la latence, pas seulement le trafic. Alertez sur la latence p95, le taux d'erreurs et la saturation des workers. La liste complète est dans comment arrêter les attaques DDoS.

Erreurs courantes

• Se reposer uniquement sur le blocage d'IP face à un botnet distribué.
• Ne limiter que la page de connexion et laisser la recherche, l'export et les routes d'API ouverts.
• Limiter derrière un proxy ou un CDN sur l'adresse du proxy plutôt que sur celle du vrai client, de sorte que tout le monde partage un seul compteur.
• Ne pas avoir de référence du trafic normal, donc personne ne sait à quoi ressemble l'anormal.
• Croire que le CDN absorbe tout alors que les endpoints non cachables atteignent directement l'origine.

Rôle des tests de charge et de la supervision

Un test de charge n'est pas une simulation de DDoS, et LoadFocus ne simule pas d'attaques DDoS. Un test de charge montre comment votre propre application se comporte à un niveau de trafic que vous choisissez, depuis des régions cloud connues, et uniquement sur des systèmes que vous êtes autorisé à tester. C'est utile en défense : vous savez combien de requêtes par seconde vos endpoints coûteux supportent et si vos limites répondent par un 429 plutôt que par des timeouts. Lisez test de charge ou test de stress pour le préparer, puis lancez-le avec les tests de charge LoadFocus. Associez-le à la supervision d'API pour être alerté quand un endpoint ralentit ou échoue (les checks gratuits s'exécutent toutes les 5 minutes).

Questions fréquentes : DDoS applicatif

Quelle taille faut-il à une attaque L7 ?

Moins que ce que beaucoup imaginent. La limite est le travail que fait votre appli par requête, pas la bande passante. Un endpoint qui déclenche une grosse requête SQL peut être épuisé par un débit de requêtes modeste.

Quelle différence entre DDoS L7 et HTTP flood ?

Le HTTP flood est un type de DDoS L7, le plus courant. Slowloris, RUDY, le cache busting et l'abus d'API sont d'autres types à la même couche.

Un CDN arrête-t-il les attaques applicatives ?

Il aide pour les pages cachables et inclut souvent de la limitation de débit et des règles anti-bots. Il n'aide pas pour les requêtes non cachables comme les connexions, les recherches ou les appels d'API, qui atteignent toujours votre origine tant qu'elles ne sont pas limitées.

Faut-il limiter par IP, par session ou les deux ?

Les deux. Les limites par IP arrêtent les bots simples. Les limites par session ou par compte arrêtent les attaques distribuées où chaque adresse n'envoie que quelques requêtes.

Comment distinguer une attaque d'un pic de trafic ?

Comparez à votre référence : quels endpoints sont visés, depuis quelles régions, avec quels user agents, et comment évoluent les erreurs. Les attaques sont plutôt uniformes (mêmes chemins, même user agent), tandis que les vrais pics sont variés et ont une cause, comme une campagne ou un lancement.