Il semble que le blocage fonctionne toujours, mais pas entièrement, car je vois encore des correspondances régulières avec l’enregistrement dans les journaux → e-mails filtrés, mais pas pour toutes les combinaisons. L’utilisateur a pu créer plusieurs centaines de comptes aujourd’hui en utilisant le même Gmail bloqué.
Les variations de points Gmail qu’ils utilisent semblent contenir entre 6 et 14 points, la longueur de l’e-mail est de 19 caractères (avant @), ils n’utilisent pas de variations avec le signe + (ou toutes ces variations sont bloquées avec succès).
Cela pourrait être pertinent : j’ai défini la distance de Levenshtein pour les e-mails des spammeurs à 3 (la valeur par défaut est 2). Discourse a récemment été mis à jour de la version 2.6.x à la version stable 2.7.1.
Hmm, j’oublie où nous en étions restés sur ce point, @sam, mais cela pourrait être un bug, puisque vous avez dit
Cela signifie que si evil.person+77@gmail.com est bloqué, nous bloquerons à la place evilperson@gmail.com. Ensuite, lorsque e.v.i.l.person@gmail.com tentera de se faufiler, il sera bloqué en raison de la correspondance canonique.
Que se passe-t-il donc lorsque sara.hanson@ fait quelque chose de terrible et que sarah.anson@ se retrouve pris dans la crossfire ? C’est tout comme pour joe98@ et joe99@ : je ne suis pas sûr qu’on puisse les considérer comme la même adresse e-mail non plus. Je suppose que cela dépend de la composition de la communauté et du niveau de discrétion manuelle appliqué dans le processus d’appariement.
L’« adressage par ajout » (plus addressing) fait au moins référence à un dossier appartenant à la boîte aux lettres de la même adresse e-mail (étant donné que tout ce qui précède le « + » est identique).
Peut-être faudrait-il bloquer les inscriptions par plage d’adresses IP ? Tout cela dépend de la sophistication des spammeurs. En venant de la communauté Let’s Encrypt, nous avons un fil de discussion qui détaille certaines tactiques de spam assez larges qui ont été tentées. Nous avons même eu des personnes qui ont fourni une aide technique réelle avant de spammer plusieurs semaines plus tard.
Intéressant. Je ne réalisais pas que Gmail faisait cette distinction. J’ai appris pas mal de nouvelles choses aujourd’hui. Je me demande pourquoi ils feraient cela ? Cela semble occuper pas mal d’espace. Les adresses Gmail sont-elles la seule préoccupation ici ?
Je pense que nous en sommes arrivés à : « Je suis mal à l’aise avec la situation dans laquelle nous nous trouvons, car c’est un cauchemar pour le support et cela ne disparaîtra jamais ».
Je pense que si un site est un vecteur de spam, il devrait pouvoir dire « rendez toutes mes adresses e-mail canoniques », peu importe les inconvénients.
Cela signifie que ces deux e-mails ont tous les deux pour adresse canonique samsam@somewhere.com :
sam.sam@somewhere.com
samsam+11@somewhere.com
Si sam.sam@somewhere.com s’est enregistré, samsam+11@somewhere.com ne pourra plus s’inscrire.
C’était ma solution initiale, que j’ai finie par annuler (bien qu’elle ait fait une exception pour Google – ce qui, en y repensant, n’était pas assez strict).
Je pense que nous devrions simplement tourner la page en ajoutant un nouveau paramètre de site pour :
« OMG je suis un énorme vecteur de spam, activez le mode super feuille d’aluminium »
Concernant le bug, des choses peuvent facilement passer à travers si vous attendez pour bloquer. Le processus est actuellement 100 % réactif.
Cela signifie que cela fonctionne parfaitement (n’hésitez pas à tester dans la console @markersocial) :
./launcher enter app
rails c
ScreenedEmail.block('examplemailaddress@gmail.com')
ScreenedEmail.should_block?('e.x.a.m.pl.e.m.ai.lad.dre.ss@gmail.com')
# true
Le problème est le suivant :
# Des centaines de comptes créés
ScreenedEmail.block('examplemailaddress@gmail.com')
# Des centaines de comptes sont toujours là
Ah oui, la demande initiale consistait à bloquer tous les e-mails contenant des caractères spéciaux, via un paramètre du site. J’avais cru proposer cela et que cela ne vous plaisait pas ? Je ne m’en souviens plus.
Je pense que tout cela se résume au fait que @markersocial souhaite une fonctionnalité (canonicalisation forcée, comme je l’avais initialement implémentée) dont aucun de nos milliers de clients hébergés ne semble avoir besoin.
Nous pouvons continuer à affiner la fonctionnalité réactive (recherche de canonicals lors du blocage et demande à l’administrateur de supprimer les comptes indésirables). Cependant, je préférerais entendre d’abord plusieurs plaintes similaires.
Le blocage basé sur les expressions régulières ne fonctionnera certainement pas pour @markersocial, mais je suis ravi qu’il puisse le confirmer.
Je n’ai pas de reproduction du problème mentionné dans l’OP et je soupçonne fortement que les comptes problématiques ont été créés avant l’ajout du blocage.
Je peux confirmer que la correction initiale fonctionnait parfaitement et a résolu ce problème avec les adresses Gmail. Ce serait une véritable bouée de sauvetage si ce mode optionnel était rétabli.
Les spammeurs apprennent constamment de nouvelles techniques et continuent à tromper avec succès de grands acteurs comme Facebook, Instagram et Twitter. Cela rend la plupart des autres plateformes « mode facile ». Pour beaucoup d’entre eux, c’est un travail à temps plein, ce qui revient essentiellement à :
Si exploitable et (ressources requises < argent gagné), alors cela sera exploité.
Ils peuvent contourner pratiquement n’importe quelle mesure ; le seul espoir est d’augmenter les coûts de telle sorte que cela ne soit plus financièrement rentable.
Être capable de spammer en masse avec presque un nombre illimité d’e-mails/comptes (avant détection et blocage rétroactif par un modérateur/admin de leur adresse Gmail canonique, suivi de la suppression manuelle de leurs publications) est très rentable. Encore plus s’il n’y a pas d’équipe de modérateurs disponible 24h/24 et 7j/7.
Le coût pour contourner les mesures anti-spam continue de diminuer. Un exemple : les proxies 4G/5G. Pour environ 30 à 50 $ par mois, les gens peuvent obtenir accès à des adresses IP mobiles réelles pratiquement illimitées, provenant de FAI/ASN légitimes qui tournent automatiquement ou manuellement et sont partagées par des villes ou états entiers d’utilisateurs légitimes de grands FAI. Les adresses IP 4G/5G sont partagées par de nombreux utilisateurs simultanément.
Bloquer ces FAI/ASN ou adresses IP n’est pas approprié (on ne peut pas simplement bloquer tout le monde utilisant Verizon, AT&T, etc.). Ils utilisent généralement l’adresse IP une seule fois avant de la jeter. Les adresses IP individuelles bloquées provenant de là bloqueront également des utilisateurs légitimes qui partagent cette adresse IP au hasard. Le blocage par adresse IP devient progressivement une pratique obsolète (à l’exception des ASN des sociétés d’hébergement connues). Vous pouvez voir le début de l’iceberg sur ces forums :
Je pense que les spammeurs sont un mélange de bots entièrement ou partiellement développés en interne et de spam manuel. Comme Discourse gagne plus de parts de marché, ce qui est clairement le cas avec une croissance fantastique, je serais surpris qu’il ne devienne pas une cible de bots disponibles commercialement.
Dès que Xrumer prendra en charge la dernière version de reCAPTCHA, je dirais que la plupart des webmasters sur des forums anciens remarqueront une forte augmentation du spam en raison du coût extrêmement bas du spam (plus besoin d’utiliser une API de résolution de captcha, qui sont déjà très peu chères par 1 000 résolutions) :
http://botmasterlabs.net/buy1/
Les gens peuvent déjà créer leurs propres plugins/scripts pour prendre en charge pratiquement n’importe quelle plateforme en utilisant Xrumer. Mais s’ils prennent en charge Discourse nativement un jour :
Je ne peux pas prétendre être impartial sur ce sujet, car j’ai directement besoin de mesures anti-spam. Le post original sur l’astuce du point Gmail a été créé par quelqu’un d’autre en 2014 et il semble qu’un autre utilisateur ait résolu ce problème en exigeant une approbation pour les x premiers messages, donc peut-être y a-t-il au moins trois rapports d’utilisateurs ?
Désolé pour cette digression, revenons au sujet.
Concernant le blocage par expressions régulières pour les e-mails, oui vous avez raison. C’est une solution partielle, mais pas idéale pour les raisons suivantes :
Si on bloque tous les Gmail avec 1 point ou plus avant @ :
Cela bloquera inévitablement de vrais utilisateurs légitimes de Gmail qui ont soit 1 soit plusieurs points dans leur adresse Gmail, ce qui est très courant.
Les spammeurs peuvent encore créer un grand nombre de variations avec un seul point. Par exemple, Gmail a une longueur maximale de 30 caractères, par exemple 12345678901234567890123456789.0@gmail.com aura 30 combinaisons utilisables avec un seul point.
Bloquer tous les Gmail avec 2 points ou plus avant @ :
Moins d’utilisateurs légitimes de Gmail bloqués, mais cela bloquera toujours des utilisateurs légitimes de Gmail ayant plus d’un point dans leur adresse e-mail.
Les spammeurs peuvent créer beaucoup plus de variations avec un seul Gmail de 30 caractères. Je pense à environ 842 combinaisons ou plus.
Je peux confirmer que les nouveaux comptes sont passés après que le blocage ait été actif, car la date de création du blocage est le 1er février. Je surveillais la création de nouveaux comptes hier en voyant à la fois des cas où la règle de blocage avait de nouvelles correspondances récentes ainsi que de nouvelles inscriptions utilisant des combinaisons de la même adresse e-mail (points uniquement).
J’ai désactivé les inscriptions pendant la nuit et les ai réactivées ce matin. Ils ont créé 104 nouveaux comptes aujourd’hui avec des permutations de cette adresse Gmail et continuent de s’inscrire davantage. Je peux confirmer que, une fois les points supprimés des adresses e-mail de ces comptes, il s’agit d’une correspondance exacte avec l’enregistrement bloqué des e-mails filtrés.
J’ai essayé de tester les blocages dans rails c comme décrit, c’est là que cela devient un peu étrange.
Il semble donc que certains enregistrements retournent « true » comme prévu, tandis que d’autres retournent « false » même si l’e-mail testé correspond exactement à l’e-mail bloqué canonique. Pour les enregistrements qui retournent « true », cela a fonctionné entièrement comme prévu et a retourné true pour toutes les variations que j’ai testées. Mais pour les e-mails qui retournent false, toutes les variations que j’ai testées ont également retourné false.
J’essayais de trouver des corrélations. Je peux confirmer qu’il n’y a pas de corrélation (ou du moins pas de corrélation cohérente) avec :
La longueur de l’e-mail (avant @)
L’e-mail contenant des caractères et des chiffres
Le nombre de correspondances (nombre de fois bloqué)
La date de correspondance
Il semble cependant qu’il y ait une corrélation avec la date de création du blocage, les plus anciens étant moins susceptibles de fonctionner (retournent false). Les enregistrements créés il y a 9 jours ont retourné un mélange de true/false, et tous les enregistrements que j’ai testés jusqu’à présent créés avant cela (1h-8j) retournent true.
Cela pourrait peut-être être lié à « max age unmatched emails » ? Je pense que cette option est quelque peu nouvelle, je l’ai réglée sur la valeur par défaut de 365 jours.
Eh bien, si vous pouvez fournir des étapes de reproduction détaillées pour un bug, nous le corrigerons certainement.
max age unmatched emails n’est pas un nouveau paramètre ; tout comme max age unmatched ips, il s’agit d’un outil permettant de nettoyer les anciennes entrées dans les listes d’adresses IP et d’e-mails filtrées, à savoir les entrées qui n’ont correspondu à rien depuis un an.
Je vous comprends tout à fait. Je pense que l’une des principales objections de @codinghorror concernant la mise en œuvre initiale était que nous avions une logique spécifique à Google. Cela rendait Jeff assez mal à l’aise.
Je suppose que l’affinement consistant à « tout rendre canonique, quel que soit le domaine » atténue un peu cette préoccupation.
Par exemple :
sam+982@sam.com → autorisé à s’inscrire … d’abord sam@sam.com s.a.m.@sam.com → non autorisé à s’inscrire … la deuxième fois, j’ai remarqué sam@sam.com et que ce canonique était déjà enregistré.
Cela pourrait revenir un jour ; il nous suffit de trouver cette forme d’abus ailleurs. La dernière fois que j’ai enquêté, nous n’avions pas constaté cet abus sur notre hébergement.
Je n’ai que peu de temps pour poster aujourd’hui, mais je voulais partager quelques informations supplémentaires avant de répondre plus en détail.
J’ai constaté que la suppression d’un enregistrement qui renvoyait « false » dans les journaux → e-mails filtrés (autorisés), puis le blocage à nouveau de l’e-mail (en supprimant l’utilisateur + en bloquant sur la page d’administration de l’utilisateur) a fait en sorte qu’une règle précédemment défaillante renvoie désormais systématiquement « true » pour la correspondance directe et ses variantes.
Cela semble correspondre à l’observation selon laquelle le problème concerne les anciens enregistrements. Il faudra effectuer davantage de tests.
Cela semble occuper pas mal d’espace. Les adresses Gmail sont-elles la seule préoccupation ici ?
».
