Extorsion DDoS : ce qui arrête vraiment une attaque contre un site de petites annonces pour adultes, et ce qui n'y arrive pas
Le matin où l'annuaire cesse de se charger sans raison identifiable
Cela commence presque toujours de la même façon. Le site est lent, puis il ne se charge plus du tout, puis il revient pendant dix minutes avant de retomber. Le tableau de bord d'hébergement ne montre rien d'anormal : pas de déploiement raté, pas de base de données saturée, pas de certificat expiré. Un ticket envoyé à l'hébergeur reçoit en réponse que tout semble normal de son côté, ce qui est techniquement vrai et totalement inutile, car le problème n'est pas de son côté, il est sur le fil entre internet et son infrastructure.
Ce qui se passe réellement, dans l'immense majorité de ces cas, est une attaque par déni de service distribué : un flot de trafic, généralement issu de milliers d'appareils compromis, destiné à empêcher le site de répondre aux visiteurs réels. Ce n'est ni rare ni exotique. L'équipe de renseignement sur les menaces de Cloudflare a déclaré avoir mitigé environ 5 343 attaques DDoS au niveau réseau chaque heure sur son réseau au premier semestre 2026, soit environ 128 000 par jour. La plupart de ces attaques sont courtes et de faible ampleur par rapport aux plus gros incidents jamais enregistrés : 96,62 % sont restées sous les 500 Mbps, et 90,60 % se sont terminées en moins de dix minutes. « Faible » reste toutefois relatif : une attaque de 100 Mbps suffit à mettre à genoux un serveur ordinaire non protégé, soit une fraction de ce qui s'observe un soir de semaine banal contre des sites dont personne n'a jamais entendu parler.
La raison commerciale derrière une attaque donnée compte presque toujours moins que ce que les opérateurs imaginent. Il peut s'agir d'un annuaire concurrent cherchant à mettre hors ligne un rival pendant un week-end chargé, d'un annonceur banni se vengeant via un service d'attaque à la demande bon marché, d'un opportuniste désœuvré ayant trouvé le site par un scan aléatoire, ou de l'ouverture d'une tentative d'extorsion. La réponse qui protège vraiment le site est presque identique quel que soit le motif, ce qui est une bonne nouvelle, car ce motif n'est presque jamais confirmé.
Les annuaires de petites annonces sont une cible plus facile que leurs propriétaires ne le pensent généralement. Beaucoup tournent sur un seul VPS économique choisi précisément parce qu'il acceptait l'activité au départ, avec un DNS pointant directement vers ce serveur parce que personne n'a songé à faire autrement lors de la configuration du domaine. Les revenus dépendent de la disponibilité d'une manière qu'un site vitrine ne connaît pas : chaque heure hors ligne est une heure de renouvellements manqués, d'inscriptions abandonnées, et d'annonceurs qui ouvrent l'onglet d'un concurrent plutôt que de revenir vérifier si le site d'origine s'est rétabli.
La demande de rançon, et pourquoi la payer ne règle rien
Certaines attaques s'accompagnent d'une exigence. Ce schéma, connu dans le secteur de la sécurité sous le nom de ransom DDoS ou RDoS, commence généralement par une courte attaque de démonstration ou une menace directe par courriel, suivie d'une instruction de paiement d'une somme, presque toujours en cryptomonnaie, pour stopper une attaque plus importante ou en éviter le déclenchement. Des groupes construits exactement sur ce scénario, DD4BC et l'Armada Collective parmi les premiers, l'utilisent depuis environ 2014, et des acteurs plus récents reprennent toujours la même structure parce qu'elle continue de fonctionner assez souvent pour que l'effort en vaille la peine.
Payer semble la sortie la plus rapide quand chaque heure d'interruption coûte de vrais renouvellements, et c'est exactement la pression que l'exigence est conçue pour créer. Le problème est que rien dans la transaction n'oblige l'attaquant à faire quoi que ce soit. Il n'y a pas de contrat de support derrière une demande de rançon. Le cas le plus souvent cité en guise d'avertissement est celui de ProtonMail en 2015, qui a payé et a vu les attaques continuer malgré tout, concluant ensuite publiquement que le paiement n'avait rien acheté. Les chercheurs en sécurité qui suivent ces groupes rapportent ce même schéma assez souvent pour le traiter comme le résultat par défaut, pas comme l'exception.
Payer change aussi la façon dont le compte est perçu la fois suivante. Une cible connue pour payer est une cible plus attrayante, pour le même groupe comme pour d'autres qui l'apprennent via les mêmes marchés criminels qui vendent des services d'attaque à la demande. L'incitation ainsi créée va exactement dans la mauvaise direction pour une activité qui préférerait ne jamais revivre cela.
Ce qui aide réellement pendant une exigence active est ennuyeux et procédural : conserver le message avec tous ses en-têtes plutôt que simplement le lire et le supprimer, prévenir immédiatement l'équipe anti-abus ou sécurité de l'hébergeur et de la CDN, car ils suivent peut-être déjà le même attaquant chez d'autres clients, et déposer un signalement auprès de l'unité de police compétente en cybercriminalité même sans attendre de suite rapide, car ce sont les signalements agrégés qui permettent, à terme, aux agences et aux fournisseurs d'infrastructure d'agir contre les groupes récidivistes. Rien de tout cela n'arrête l'attaque en soi. La section suivante explique ce qui l'arrête vraiment.
Ce qui arrête vraiment le trafic avant qu'il n'atteigne le serveur
La solution qui fonctionne est architecturale, pas négociable : placer un réseau de diffusion de contenu ou un proxy inverse devant le site, pour que le trafic d'attaque soit absorbé et filtré en périphérie, grâce à la capacité mondiale d'un fournisseur, avant d'atteindre le petit serveur qui exécute réellement le code de l'annuaire. C'est le même rôle qu'un CDN joue déjà pour la performance ordinaire, étendu à un trafic activement hostile plutôt que simplement élevé.
Le coût est ici un obstacle moindre que ce que les opérateurs imaginent souvent. Les grands fournisseurs de CDN incluent couramment une mitigation DDoS au niveau réseau active en permanence dans leur offre gratuite, comme partie du service de base plutôt que comme option payante, précisément parce qu'absorber ce type de trafic à grande échelle leur coûte moins cher pour tout le monde que d'examiner et de facturer chaque attaque individuellement. La protection de base dont a besoin un site de petites annonces est souvent déjà disponible sans coût supplémentaire. Le problème n'est presque jamais le prix. C'est la configuration.
L'erreur de configuration la plus courante est de laisser découvrable l'adresse IP réelle du serveur d'origine, même après avoir placé un CDN devant le domaine principal. Un enregistrement de serveur de messagerie, un ancien sous-domaine de test, un panneau d'administration sur son propre nom d'hôte, ou un enregistrement DNS que personne n'a pensé à mettre à jour lors de la configuration du CDN peuvent encore pointer directement vers l'origine. Un attaquant qui trouve cette IP, souvent par rien de plus sophistiqué qu'une recherche dans l'historique DNS passif, attaque directement le vrai serveur et contourne entièrement le CDN censé le protéger. La solution est un audit complet de tous les enregistrements DNS du domaine, en vérifiant que chacun passe bien par le CDN ou n'a réellement pas besoin d'être public, puis de traiter l'IP d'origine comme quelque chose à dissimuler activement, et non comme un détail de fond dont personne ne se souvient après le jour de la configuration.
Cette configuration doit être testée avant une attaque, pas pendant. Un opérateur qui n'a jamais réellement vérifié que chaque enregistrement passe par le CDN, ou qui ne sait pas de mémoire vers quel second CDN l'activité basculerait si l'actuel tombait, découvre les failles au pire moment possible. Repasser la configuration une fois, un après-midi tranquille, coûte une heure. Découvrir une faille en plein milieu d'une attaque coûte bien plus que cela.
Choisir un prestataire qui veut vraiment garder le compte
Tous les fournisseurs de CDN ou anti-DDoS ne traitent pas le contenu pour adultes légal de la même façon, et cela vaut la peine de le vérifier avant de construire une infrastructure autour de l'un d'eux, pas après. Certains des plus grands fournisseurs d'infrastructure gèrent leur service de sécurité et de routage du trafic d'une manière réellement neutre quant au contenu, servant presque tout matériel légal sans isoler par catégorie le contenu pour adultes, ce qui explique en partie pourquoi ils attirent parfois des critiques publiques pour la poignée de sites qu'ils finissent par protéger. D'autres inscrivent une interdiction nette du matériel « obscène ou pornographique » directement dans leur charte d'utilisation acceptable standard, le même type de clause que l'on retrouve dans les contrats d'hébergement et d'enregistrement de domaines pour ce secteur. La réputation d'un fournisseur axé sur la sécurité plutôt que sur le contenu ne dit pas à un opérateur dans quelle catégorie il se situe ; seule la lecture de la politique réelle le dit.
C'est la même marge de discrétion qui décide déjà si un hébergeur, un CDN ou un registraire jugent qu'une activité de petites annonces n'est pas la bienvenue sur leur infrastructure, un niveau plus proche de la question spécifique de la mitigation DDoS que de l'hébergement en général. Un fournisseur qui accepte le compte aujourd'hui sous une clause vague ou jamais mise à l'épreuve peut toujours agir sur cette clause plus tard, et un opérateur qui ne découvre le type de fournisseur choisi qu'après un avis de résiliation a déjà perdu la possibilité de choisir calmement une alternative.
La vérification pratique est simple et prend quelques minutes : chercher dans la charte d'utilisation acceptable ou les conditions de service du fournisseur les mots adult, pornographic, obscene et escort avant de signer, plutôt que de supposer qu'un prestataire de sécurité est neutre par défaut simplement parce qu'il n'est ni un prestataire de paiement ni une banque. Si la politique est silencieuse, ce silence n'est pas non plus une garantie, juste une clause que personne n'a encore mise à l'épreuve. Garder un second fournisseur en tête, avec une configuration DNS capable de basculer vers lui en une heure plutôt qu'en une journée, compte ici exactement autant que pour l'hébergement en général.
Ce que coûte vraiment une coupure, une fois terminée
Même une attaque rapidement mitigée laisse des coûts qui apparaissent après l'arrêt du trafic. Un site instable pendant quelques heures, plutôt que totalement hors ligne, peut quand même casser les processus silencieux de fond qui font tenir une activité par abonnement : un réseau de cartes qui tente d'atteindre un webhook de facturation pendant une coupure intermittente se comporte comme une tentative de renouvellement qui n'atteint jamais le réseau de la carte, et l'annonceur de l'autre côté ne voit qu'une carte refusée, sans savoir que la cause réelle était une attaque qui n'avait rien à voir avec lui.
Les moteurs de recherche sont tout aussi impitoyables dans la distinction entre « sous attaque » et « en cessation d'activité ». Un domaine inaccessible pendant une période prolongée est traité par un robot d'indexation de la même façon dans les deux cas, et les pages qui se classaient bien avant la coupure ne reviennent pas nécessairement à la même position une fois le site rétabli, ajoutant un second coût, plus lent, par-dessus les heures réellement perdues.
Un avis bref et clair aux annonceurs ne coûte rien et évite un résultat pire que l'attaque elle-même : un annonceur qui voit des erreurs intermittentes sans explication a tendance à penser que l'activité a discrètement échoué et commence à regarder un concurrent, tandis que le même annonceur, informé clairement que le site est sous attaque, que la facturation est suspendue pendant la perturbation et que le service reviendra dans un délai annoncé, patiente généralement plutôt que de partir.
La version utile de cet article est celle qu'on lit avant que tout cela n'arrive, pas pendant. Vérifiez, dès aujourd'hui, que chaque enregistrement DNS pointant vers le site passe par un CDN plutôt que d'exposer directement l'origine. Vérifiez que la mitigation DDoS de niveau de base du CDN est réellement activée et non simplement supposée l'être, car certains fournisseurs la laissent désactivée par défaut sur certaines offres. Notez, dans un endroit qui survit à la mise hors ligne du site principal, les véritables contacts de support et anti-abus de l'hébergeur et du CDN, avec les numéros de compte à côté. Rien de tout cela n'est assez coûteux ou technique pour nécessiter un spécialiste. Il faut simplement que cela se fasse avant l'arrivée de la première exigence, car il n'existe aucune version de ce problème qui devienne plus facile à résoudre une fois qu'il est déjà en train de se produire.
