Si votre site « ne reçoit pas beaucoup de trafic, mais refuse simplement de se charger » — et que votre journal de pare-feu regorge de requêtes HTTP parfaitement normales — vous faites probablement face à une attaque CC.
Les attaques CC (Challenge Collapsar) sont le membre le plus trompeur de la famille DDoS. Elles n'ont pas besoin de débits en Tbps. Quelques centaines de machines infectées et quelques milliers de connexions suffisent à mettre hors ligne un site dépourvu de défense applicative — et comme tout semble normal, votre ingénieur d'astreinte peut perdre une heure à « redémarrer l'appli » avant que quelqu'un nomme le vrai problème.
Comment fonctionne une attaque CC
Le nom vient d'un ancien outil d'attaque appelé « Challenge Collapsar ». L'idée de base est brutalement simple :
Demandez en continu les pages de votre site qui consomment le plus de ressources serveur.
Exemples :
- Points de recherche exécutant une requête lente
LIKE '%term%'sur des millions de lignes - Pages de rapports agrégeant des données avec de lourdes jointures
- Points de téléchargement diffusant de gros fichiers depuis le disque
- Points de soumission écrivant dans la base à chaque requête
Les attaquants utilisent de grands pools de proxys IP pour frapper ces points simultanément et à répétition. Chaque requête individuelle a l'air légitime — une session valide, un User-Agent de vrai navigateur — mais votre CPU, votre pool de connexions à la base et vos services backend sont épuisés en quelques minutes. Prenons un point de recherche qui prend 400 ms en charge : un 200 requêtes par seconde soutenues du botnet sature le pool de connexions de votre base, et les vrais utilisateurs commencent à expirer à la page de connexion alors que la bande passante totale ne dépasse jamais 5 Mbps.
L'intuition clé : une attaque CC cible la consommation de ressources, pas la bande passante. C'est pourquoi acheter plus de bande passante ou une IP haute défense ne fait quasiment rien contre elle — ce n'est pas le tuyau qui manque, ce sont les requêtes que votre base peut traiter.
Attaques CC vs DDoS traditionnel
| Dimension | DDoS volumétrique | Attaque CC |
|---|---|---|
| Couche | L3 / L4 (réseau, transport) | L7 (application) |
| Volume de trafic | des centaines de Gbps à des Tbps | parfois seulement quelques Mbps |
| Signature de requête | paquets manifestement malformés | quasi identique aux vrais utilisateurs |
| Ressource ciblée | bande passante, table de connexions | CPU, mémoire, base, backend |
| Méthode de défense | nettoyage de bande, limitation de débit | analyse comportementale, défis bots, limitation précise |
| Difficulté de détection | relativement facile | extrêmement dure |
En une phrase : un DDoS volumétrique inonde votre maison ; une attaque CC envoie des espions à l'intérieur pour épuiser votre eau et votre électricité.
Pourquoi les attaques CC sont si dures à stopper
Trois raisons, chacune vainquant une défense naïve :
- Le trafic est trop faible pour déclencher des alarmes. La plupart des systèmes de surveillance fixent les seuils d'alerte par bande passante. Une attaque CC ne correspond même pas à votre pic normal, si bien que le tableau « bande passante OK » vous berce dans un faux sentiment de sécurité pendant que la base fond.
- Les requêtes sont légitimes. Les attaquants demandent des pages qui existent vraiment, avec des paramètres valides et des en-têtes bien formés. Il n'y a pas de paquet malformé pour qu'un pare-feu le rejette.
- Les sources sont distribuées et déguisées. Les attaquants louent de vrais pools de proxys résidentiels et imitent même les cookies de navigateur et les empreintes TLS — de simples listes noires d'IP échouent complètement, car les « mauvaises » IP sont les mêmes que celles de vos vrais clients.
Une stratégie de défense en quatre couches
Couche 1 : isolation des ressources
D'abord, assurez-vous que l'attaque ne peut pas atteindre ce qui est critique :
- Séparez les points gourmands en ressources (recherche, rapports, exports) des points métier essentiels, idéalement sur des pools de services différents, pour qu'une tempête de recherche ne puisse pas affamer le paiement.
- Ajoutez du cache et des résultats précalculés afin que des requêtes identiques renvoient une réponse en cache sans toucher à la base.
- Fixez des limites de concurrence par IP et des délais par point pour augmenter le coût de l'attaquant et plafonner les dégâts.
Couche 2 : limitation précise et bases de débit
N'appliquez pas de limitation uniforme — cela ne dégrade que les vrais utilisateurs pendant une vente. La bonne approche :
- Établissez une base de trafic normale par point (QPS, temps de réponse, mélange de signatures de requête).
- Dégradez automatiquement quand le trafic s'écarte de la base — file d'attente, cache, ou exigence de vérification — au lieu de bloquer brutalement.
- Appliquez des politiques plus strictes spécifiquement aux points de connexion et de soumission, où quelques centaines de requêtes par seconde font réellement mal.
Couche 3 : défis bots
Pour les points à forte valeur à protéger, ajoutez une vérification que les botnets ne peuvent pas passer facilement :
- Défis JS (les clients doivent exécuter un calcul — les pools de proxys résidentiels et les scripts headless peinent à passer à grande échelle, augmentant le coût par requête de l'attaquant).
- Empreinte comportementale (empreinte TLS, rythme de requête, absence des micro-pauses humaines qu'affiche un vrai navigateur).
- CAPTCHA si nécessaire, et seulement si nécessaire.
L'arbitrage : la vérification affecte l'expérience utilisateur. Activez-la pendant les attaques ou sur les points à risque uniquement, pas sur tout le site par défaut — sinon vous taxez vos propres clients pour combattre une menace absente.
Couche 4 : nettoyage professionnel avec intervention d'experts
Les attaques CC exigent généralement un ajustement des règles en temps réel pour être supprimées — les attaquants observent vos règles et s'adaptent en quelques minutes, changeant d'User-Agent ou basculant de la recherche vers les exports. Un jeu de règles statique devient vite obsolète. C'est précisément où un service de protection professionnel justifie son prix.
La couche de nettoyage en profondeur d'AwayDDoS modélise en continu le comportement applicatif, et nos experts en sécurité 7×24 interviennent activement pour ajuster les règles pendant une attaque plutôt que d'attendre votre ticket. Voir les solutions de protection pour les détails.
Une idée reçue courante
« J'ai mis un CDN devant, donc je suis à l'abri des CC. » — Un CDN atténue une partie du problème, mais il ne met en cache que les ressources statiques ; les requêtes dynamiques (la recherche, la connexion et les appels API que visent les attaques CC) sont transmises directement à votre origine. Ce dont vous avez vraiment besoin, c'est une analyse comportementale applicative en profondeur, pas seulement la mise en cache en périphérie.
Points clés à retenir
Ce qui rend les attaques CC dangereuses, c'est qu'elles sont extrêmement bon marché et extrêmement difficiles à identifier — un abonnement à des proxys résidentiels coûte quelques dollars par jour et peut ensevelir une base non protégée. S'en défendre ne consiste pas à acheter plus de bande passante ; il faut construire de la profondeur : isolation des ressources, limitation précise, défis bots et intervention d'experts travaillant ensemble.
Si votre site présente le schéma « faible trafic mais persistance à être injoignable », contactez-nous dès maintenant pour une analyse gratuite de la signature d'attaque. Nouveau sur le sujet ? Commencez par Qu'est-ce qu'une attaque DDoS ? Guide complet pour débutants.