Comment j’ai finalement bloqué le trafic de robots en Chine et à Singapour à l’aide de Cloudflare

Au cours des derniers mois, on a constaté une augmentation notable des conversations publiques sur les forums de webmasters, les communautés d’hébergement et les canaux de sécurité concernant le trafic agressif de robots en provenance de Chine et de Singapour. Je peux le confirmer de première main. Ce qui a commencé pour moi début octobre comme un vague sentiment que quelque chose allait désactivé s’est rapidement transformé en l’un des problèmes d’infrastructure les plus frustrants auxquels j’ai été confronté depuis des années.

Au cours d’une journée typique, mes sites reçoivent environ un millier de visites humaines réelles. Presque du jour au lendemain, ce nombre a été gonflé par des centaines de milliers de demandes par jour. Aux heures de pointe, le trafic était effectivement 500 fois supérieur au volume normal. Ce n’étaient pas des robots occasionnels ou des grattoirs polis. Ils martelaient des milliers de URL par heure, dont beaucoup n’existaient pas, conduisant 404mâchant PHP travailleurs, saturant les connexions aux bases de données et augmentant tranquillement CDN les coûts en cours de route.

Il ne s’agissait pas de former des robots. Si c’était pour gratter IA formation, l’intégralité du site aurait pu être copiée en quelques minutes. Le comportement était plus proche d’une attaque d’épuisement des ressources, mais manquait de motif clair ou de signature unique identifiable. Pire encore, j’étais loin d’être seul. Dans les communautés Reddit, Slack et WordPress, d’innombrables propriétaires de sites ont signalé des modèles presque identiques, pointant souvent vers les mêmes sources géographiques.

Ce qui suit explique comment je l’ai finalement arrêté sans bloquer purement et simplement des pays entiers, et pourquoi les contrôles basés sur les défis de Cloudflare se sont avérés la seule solution fiable.

Pourquoi ce trafic était si difficile à arrêter

L’un des aspects les plus frustrants de ce modèle d’attaque était sa capacité d’adaptation. Personne bloquante Adresses IP était inutile. Chaque fois qu’une liste de blocage était appliquée, de nouvelles adresses IP apparaissaient immédiatement. La limitation du débit a aidé brièvement, mais les robots ont distribué les requêtes plus largement. Le filtrage des agents utilisateurs était inefficace car les requêtes imitent suffisamment bien les navigateurs légitimes pour pouvoir passer à travers.

À un moment donné, le volume était si intense que j’ai été obligé de retirer redirections génériques et désactivez temporairement la recherche sur site. Les robots généraient des milliers de requêtes de recherche par heure et sondaient des URL qui n’existaient pas. Même si les demandes n’étaient pas valides, WordPress a quand même dû travailler pour les rejeter, et ce travail s’accumule rapidement sous une charge soutenue.

C’est là que beaucoup de gens diagnostiquent mal le problème. Le serveur n’est pas lent. La demande n’est pas non optimisé. L’infrastructure est exploitée à une échelle qu’elle n’a jamais été conçue pour absorber de manière continue.

Pourquoi la mise en cache des actifs CDN à elle seule ne suffit pas

Comme beaucoup d’éditeurs, j’utilisais déjà Lapin comme un CDN traditionnel, principalement pour les actifs statiques. Dans cette configuration, Bunny accélère la livraison mais permet toujours à la plupart des requêtes d’atteindre le serveur d’origine. Lorsque l’attaque cible des URL dynamiques, des points de terminaison de recherche ou des chemins inexistants, la mise en cache offre peu de protection.

Le tournant s’est produit lorsque j’ai réalisé que j’avais besoin d’un CDN qui agisse comme un véritable pare-feu frontal, et pas seulement comme une couche de performances. J’ai passé des heures à essayer de configurer Bunny là-dessus, sans succès. Je suis sûr que des personnes ayant plus d’expérience en NGINX et en infrastructure auraient pu le comprendre, mais c’était au-dessus de ma tête. Et si vous êtes un expert en infrastructure, il existe d’excellentes ressources qui suivent les adresses IP exactes qui devraient être bloquées.

Voleroù je gère WordPress sur Linode, offre une profondeur Flare nuageuse intégration qui place Cloudflare directement devant le site, permettant aux règles de pare-feu, à l’atténuation des robots et aux défis de s’exécuter avant même que le trafic n’atteigne PHP ou MySQL. Cette distinction est importante. C’est la différence entre absorber une attaque et la prévenir.

Identifier le modèle géographique

Une fois Cloudflare entièrement intégré, la visibilité à elle seule était révélatrice. La majorité du trafic abusif était concentrée autour de deux pays : la Chine et Singapour. Cela ne signifie pas que tout le trafic provenant de ces régions est malveillant. J’ai des lecteurs et partenaires légitimes dans le monde entier. Mais le type d’abus était indubitable, soutenu et extrêmement disproportionné par rapport au comportement réel des utilisateurs.

Avec cette clarté, l’objectif est devenu évident. J’avais besoin d’un moyen de ralentir ou d’arrêter le trafic automatisé en provenance de ces régions sans bloquer définitivement de vraies personnes.

Pourquoi les défis interactifs fonctionnaient lorsque les blocs échouaient

Cloudflare propose plusieurs options d’atténuation, mais le blocage pur et simple est un instrument brutal. Je n’ai jamais voulu refuser l’accès uniquement pour des raisons géographiques. Au lieu de cela, j’ai utilisé un défi interactif.

Un défi interactif oblige le visiteur à effectuer une vérification basée sur le navigateur avant de continuer. Les vrais utilisateurs passent presque instantanément. Les systèmes automatisés échouent, bloquent ou abandonnent complètement la demande. Plus important encore, cela se produit à la périphérie de Cloudflare, et non sur votre serveur.

Cette seule étape a tout changé. Après avoir lancé le défi hier soir, j’ai constaté une baisse constante. Mais le nombre de demandes est effrayant en 24 heures !

Quelques minutes après l’activation de la règle, la charge du serveur s’est normalisée. Connexions à la base de données stabilisées. Les coûts du CDN ont cessé de grimper. Les robots ne se sont pas adaptés.

Comment configurer la règle Cloudflare

La règle elle-même est étonnamment simple. À l’intérieur de Cloudflare Sécurité > Règles de sécuritécréez une nouvelle règle avec la logique suivante.

La condition vérifie si le pays du visiteur est la Chine ou Singapour. L’action applique un défi interactif. Placez la règle en haut de votre liste de pare-feu afin qu’elle s’exécute avant toute règle plus large.

En coulisses, Cloudflare traduit cela en une condition similaire à la vérification si le code du pays source est CN ou SG. Vous n’avez pas besoin d’écrire des expressions brutes, sauf si vous le souhaitez. L’interface le gère proprement.

Le détail critique est de choisir un défi interactif ou géré plutôt qu’un bloc. Les défis préservent l’accès tout en éliminant l’automatisation.

Pourquoi cela a finalement résolu le problème

Une fois que Cloudflare a agi comme un véritable gardien, l’attaque a perdu son influence. Les robots n’étaient plus capables de générer des requêtes illimitées à un coût négligeable. Chaque requête nécessitait des capacités de calcul et de navigateur dont ils ne disposaient pas.

Tout aussi important, cette solution a été évolutive. La rotation des adresses IP n’a plus d’importance. Les modèles de requêtes n’ont plus d’importance. Même si le trafic a légèrement changé selon la zone géographique, les analyses de Cloudflare ont rendu simple l’adaptation de la règle.

Plus important encore, les visiteurs légitimes n’ont pas été affectés. Les vrais utilisateurs sont passés sans problème, souvent sans même se rendre compte qu’un défi s’était produit.

Un avertissement plus large pour les éditeurs

Ce qui m’inquiète le plus, c’est le nombre d’éditeurs indépendants et de petites entreprises qui sont contraints de prendre des décisions en matière d’infrastructure qu’ils n’avaient jamais anticipées. Ce type de trafic peut discrètement mettre un site en faillite en raison des excédents d’hébergement et des coûts CDN sans jamais le mettre complètement hors ligne.

Il ne s’agit pas de Référencementl’indexation ou IA entraînement. Il s’agit de systèmes automatisés exploitant l’ouverture du Web à grande échelle. Si vous rencontrez des pics de trafic soudains qui n’entraînent pas de conversion, n’engagent pas et n’ont pas de sens, faites confiance à votre instinct. Regardez la répartition géographique. Regardez les chemins de requête. Regardez les anomalies de coûts.

Vous n’êtes probablement pas seul.

Pensées finales

Je n’ai jamais voulu bloquer des pays, et je ne l’ai toujours pas fait. Ce que j’ai bloqué, c’était une automatisation se faisant passer pour du trafic légitime. L’approche basée sur les défis de Cloudflare m’a permis de préserver l’ouverture tout en défendant l’infrastructure, et c’était la première solution qui a réellement résisté à une pression soutenue.

Si vous constatez un trafic massif et inexpliqué en provenance de Chine ou de Singapour et que rien d’autre n’a fonctionné, cette approche mérite d’être sérieusement envisagée. Cela a mis fin à des mois de frustration pour moi en un seul après-midi et a rétabli le contrôle sur des ressources qui étaient devenues hors de portée.