Il y a bien plus que cela dans la liste, des idées ?
J’ai vu cela aujourd’hui dans les journaux d’un de nos clients, donc ce n’est pas qu’une coïncidence.
EDIT : Non, je pense que c’est une coïncidence. La recherche de ymwears.cn montre d’autres plaintes concernant le spam de référence, comme celles-ci (plus d’un an) : Relevanssi shows weird search queries on my page | WordPress.org et Block specific referrer or agent to enter url | WordPress.org
J’ai eu un client qui s’est plaint de cela le mois dernier. J’ai bloqué quelques adresses IP et envisagé de configurer fail2ban pour bloquer les adresses IP qui recherchaient certaines de ces URL, mais je n’ai jamais rien fait concrètement. J’ai examiné la possibilité de bloquer par région géographique, mais il semblait que vous ayez besoin d’une base de données à 20 $ par mois pour y parvenir.
Le spam de référents est un problème assez majeur auquel même les grands acteurs (à savoir Google Analytics) ne parviennent pas à lutter à 100 % avec succès. Pour l’instant, la seule chose qui me vient à l’esprit est de supprimer manuellement ces entrées.
Puisque ces sites semblent être - du moins en partie - identiques sur plusieurs sites Discourse indépendants (étant donné que nos captures d’écran montrent pratiquement la même liste), peut-être qu’une liste noire (dynamique) serait une bonne idée ? @codinghorror, as-tu une suggestion ?
Nous avons observé, traité et atténué ce problème à grande échelle depuis des années. Au fil des dernières années, nous avons constaté que la méthode la plus fiable pour bloquer les bots malveillants consiste à les bloquer en fonction de la chaîne d’agent utilisateur (UA), parfois en combinaison avec des informations géolocalisées (geoip).
Nous avons bloqué des centaines de millions de requêtes provenant de bots chinois au fil des ans, et nous avons rarement constaté que le blocage des adresses IP fonctionne aussi bien sur la durée que le blocage des clients basé sur les chaînes UA.
Voici un extrait d’un code que nous utilisons sur l’un de nos sites à titre d’exemple :
$user_agents = explode('|',$string_of_bad_user_agents,-1);
$hide_content_useragent = $_SERVER['HTTP_USER_AGENT'];
$IS_A_BAD_BOT = FALSE;
foreach($user_agents as $hcag) {
trim($hcag);
if (preg_match("/$hcag/i", "$hide_content_useragent")) {
$IS_A_BAD_BOT = TRUE;
break;
}
}
Presque tous (mais pas tous) les bots malveillants utilisent des chaînes UA qui peuvent être assez facilement identifiées et bloquées (à notre époque actuelle ; je ne sais pas ce qu’il en sera dans le futur, car les choses évoluent). C’est pourquoi nous avons abandonné il y a des années la méthode consistant à bloquer les bots malveillants en fonction des adresses IP. La raison de cet abandon est que de nombreux pays, comme la Chine, la Russie, la Corée du Nord, et bien d’autres, font désormais fonctionner leurs fermes de bots à partir de serveurs situés dans d’autres pays. Les adresses IP ne sont pas un bon indicateur de l’origine réelle ou de l’intention. De plus, en bloquant de vastes plages d’adresses IP, on risque de bloquer des adresses légitimes, empêchant ainsi l’accès aux utilisateurs autorisés.
Par exemple, la Chine exploite d’énormes fermes de serveurs de bots depuis le Brésil et d’autres pays plus proches (géographiquement des États-Unis) afin de masquer leur origine et de récupérer les données plus rapidement (réseau Internet plus court).
Parfois, les données WHOIS correspondent à une adresse physique chinoise, nord-coréenne ou russe (par exemple), mais d’autres fois, elles ne le font pas et utilisent des adresses physiques locales. Nous avons observé de nombreux bots chinois malveillants enregistrés auprès de sociétés brésiliennes (au cours des dernières années) où nous avons pu voir (et confirmer) que les chaînes d’agent utilisateur correspondaient à des bots malveillants originaires de Chine. De plus, lorsque nous effectuons des recherches Google sur ces chaînes UA, nous constatons que d’autres ont également identifié de nombreuses chaînes UA similaires comme étant chinoises (par exemple).
En résumé, bien que beaucoup de personnes se tournent immédiatement vers le blocage des adresses IP pour contrer l’activité des bots malveillants, la plupart des fermes de bots sophistiquées sont très compétentes pour faire fonctionner leurs bots depuis d’autres pays. Il est facile de configurer un VPS dans la plupart des pays, et bien sûr, plus le bot est proche du pays ciblé, plus il peut extraire de données. Les VPS peuvent apparaître et disparaître en quelques minutes, et les logiciels de bots peuvent être déployés très rapidement dans presque n’importe quel centre de données VPS à l’échelle mondiale.
Ces dernières années, le blocage basé sur la chaîne UA s’est avéré être la méthode la plus fiable (parfois combinée à des informations géolocalisées, parfois non) ; mais bien sûr, les spammeurs, les maîtres de bots et leurs agents commencent également à masquer les chaînes UA, tout comme ils le font depuis de nombreuses années avec leurs adresses IP.
J’espère que cela vous aidera.
Salutations et bonne chasse aux bots !
Oui, je suis tout à fait d’accord : le blocage par adresse IP n’est pas efficace.
Le blocage basé sur l’agent utilisateur fonctionne généralement assez bien, sauf lorsque les spammeurs le modifient constamment.
C’est pourquoi j’ai pensé à simplement ajouter à la liste noire l’URL réelle qui fait l’objet de spam par référent.
Cela semble « plus juste » car nous ne bloquons pas quelque chose sur la base d’une hypothèse sous-jacente (par exemple : « cet agent utilisateur fournit un mauvais référent, donc nous ne lui faisons pas confiance »), mais nous bloquons réellement ce que nous souhaitons bloquer (« nous constatons que ce site web fait l’objet de spam par référent sur plusieurs sites Discourse, alors ne l’ajoutons pas à notre base de données »). En tout cas, il est plus difficile de contourner cette méthode.
Bonne réflexion.
Il n’existe pas de solution universelle pour arrêter les bots malveillants et frauduleux ; chaque site doit évaluer quelles mesures de contrôle fonctionnent le mieux pour lui.
Sur un sujet similaire…
Les sites qui reposent principalement sur des listes noires et des bases de données de spam ou de bots malveillants peuvent également rencontrer des problèmes. Par exemple, supposons que quelqu’un n’aime pas le site www.our-arch-rival.com parce que ce site est un concurrent (ou simplement parce qu’il nous a énervé ou offensé). Certaines personnes soumettront alors le site www.our-arch-rival.com à une liste noire ou à une base de données, et d’autres sites filtreront un site légitime à cause de cette sorte de « mauvaise conséquence » découlant de la méthode des listes noires dans les bases de données.
Ensuite, bien sûr, les partisans des listes noires diront : « Vous pouvez vous rendre sur les sites de mise en liste noire et soumettre un rapport pour demander la suppression », mais pour de nombreux sites actifs depuis longtemps et très occupés, cela peut être une perte de temps considérable.
En général, il est important d’analyser le problème et de créer une stratégie d’atténuation basée sur le scénario, car chaque « adversaire » est différent. C’est l’ancienne maxime « Connais ton ennemi » de Sun Tzu et de L’Art de la guerre. Chaque situation est légèrement différente dans le monde réel et, malheureusement, il faut des compétences d’analyse de la part des administrateurs système pour créer des stratégies d’atténuation optimales contre les activités cybernétiques malveillantes ou indésirables.
C’est aussi une bonne raison d’exécuter Discourse derrière un proxy inverse, car le proxy inverse est un endroit idéal pour analyser, classifier et contrôler les activités malveillantes avant que ce trafic n’atteigne l’application Discourse.
Cela peut être un travail à temps plein en 2020 que de tenter de contrôler et d’atténuer les bots malveillants et autres activités malveillantes dans le cyberespace. Dès que les administrateurs trouvent une bonne stratégie de détection et d’atténuation, les spammeurs et les scrapers s’adaptent et trouvent des moyens de la contourner. J’ai tendance à conseiller aux gens de surdimensionner leurs serveurs pour s’assurer qu’ils disposent de suffisamment de marge, car ce genre de problèmes dans le cyberespace ne fera qu’empirer avec le temps, et non s’améliorer.
Prêt à jouer !
Ce qui est une autre raison d’éviter la mise sur liste noire par adresse IP : les spammeurs sauront que vous prenez des mesures.
Je pense pouvoir bloquer la plupart des spammeurs via Cloudflare, mais je ne suis pas sûr de ce qu’il faut mettre dans les règles pour l’agent du navigateur.
@neounix, que veux-tu dire par « chaînes UA » ? Et comment peuvent-elles être utilisées dans les règles de pare-feu de Cloudflare ?
Mais ce n’est même pas du spam de référence, n’est-ce pas ? C’est simplement qu’ils effectuent une recherche pour cette URL, donc cela ne fait rien en réalité, n’est-ce pas ? Est-ce que je comprends complètement mal ce rapport ? Il n’est accessible qu’aux administrateurs, c’est bien ça ?
Tu as raison @pfaffman, le rapport semble concerner uniquement les recherches effectuées sur le forum. Il inclut également le CTR, ce qui n’aurait pas de sens s’il s’agissait d’un rapport de référence.
Non, techniquement, ce n’est pas du spam de référent, mais je ne suis pas sûr qu’il existe un terme précis pour ce type exact d’abus. Je pense que cela ressemble beaucoup au spam de référent, mais uniquement pour un rapport de requêtes de recherche ?
Le spam de référent ne fait jamais rien ; il est conçu uniquement pour apparaître dans les rapports.
Voilà…
En HTTP, la chaîne User-Agent est souvent utilisée pour la négociation de contenu, où le serveur d’origine sélectionne le contenu ou les paramètres opérationnels appropriés pour la réponse. Par exemple, la chaîne User-Agent peut être utilisée par un serveur web pour choisir des variantes en fonction des capacités connues d’une version particulière de logiciel client. Le concept d’adaptation du contenu est intégré à la norme HTTP dans RFC 1945 « afin d’adapter les réponses pour éviter certaines limitations des agents utilisateurs. »
La chaîne User-Agent est l’un des critères selon lesquels les robots d’indexation web peuvent être exclus de l’accès à certaines parties d’un site web en utilisant la norme d’exclusion des robots (fichier robots.txt).
Comme pour de nombreux autres en-têtes de requête HTTP, les informations contenues dans la chaîne « User-Agent » contribuent aux informations que le client envoie au serveur, car cette chaîne peut varier considérablement d’un utilisateur à l’autre. [5]
Référence :
@Yassine_Yousfi, il existe une multitude de références sur Internet concernant les chaînes User-Agent (UA) HTTP et leur utilisation de diverses manières, notamment comme capteur pour détecter les bots et autres activités cybermalveillantes.
Bonnes chasses aux bots !
Notes :
- Vous pouvez consulter la
vue Discoursedes agents utilisateurs de bots ici (certaines chaînes UA sont tronquées) :
https://discourse.your-great-domain.com/admin/reports/web_crawlers
-
Aucun algorithme de détection ne peut détecter tous les bots avec une précision de 100 %.
-
Vous pouvez également récupérer les chaînes UA à partir de vos fichiers journaux du serveur web et d’autres méthodes.
Voir aussi :