Es scheint, dass einige Spammer, deren Gmail-Adressen blockiert sind, trotz Blockierung der kanonischen Version ihrer E-Mail-Adresse mit Variationen durch Punkte hindurchkommen.
Die Blockierung funktioniert also noch, aber nicht vollständig, da ich in den Protokollen weiterhin regelmäßige Treffer gegen den Eintrag sehe → gescreente E-Mails, jedoch nicht für alle Kombinationen. Der Benutzer konnte heute mit derselben blockierten Gmail-Adresse mehrere hundert Konten erstellen.
Die von den Spammern verwendeten Gmail-Punktvariationen scheinen zwischen 6 und 14 Punkten zu liegen, die E-Mail-Länge beträgt 19 Zeichen (vor dem @), sie verwenden keine Plus-Variationen (oder alle diese Variationen werden erfolgreich blockiert).
Möglicherweise relevant: Ich habe den Levenshtein-Abstand für Spammer-E-Mails auf 3 eingestellt (Standard ist 2). Discourse wurde kürzlich von 2.6.x auf 2.7.1 stable aktualisiert.
Hmm, ich habe vergessen, wie wir das bei diesem Punkt entschieden haben, @sam, aber das könnte ein Fehler sein, da du sagtest:
Das bedeutet, dass wenn evil.person+77@gmail.com blockiert wird, wir stattdessen evilperson@gmail.com blockieren. Wenn dann e.v.i.l.person@gmail.com versucht, sich unbemerkt einzuschleichen, wird es aufgrund der kanonischen Übereinstimmung blockiert.
Was passiert also, wenn sara.hanson@ etwas Schreckliches tut und sarah.anson@ in den Kreuzfeuer gerät? Das ist ähnlich wie bei joe98@ und joe99@, die meiner Meinung nach ebenfalls nicht als dieselbe E-Mail-Adresse betrachtet werden können. Ich vermute, dies hängt von der Zusammensetzung der Community und dem Ausmaß der manuellen Diskretion im Matching-Prozess ab.
“Plus-Adressierung” bezieht sich zumindest auf einen Ordner, der zum Postfach derselben E-Mail-Adresse gehört (vorausgesetzt, alles vor dem “+” ist identisch).
Vielleicht könnte man die Registrierung nach IP-Bereich einschränken? All dies hängt davon ab, wie ausgefeilt die Spammer sind. Aus der Let’s Encrypt-Community wissen wir, dass es dort einen Tracking-Thread gibt, der einige ziemlich weitreichende Spam-Taktiken beschreibt, die versucht wurden. Wir hatten sogar Fälle, in denen Personen zunächst technische Hilfe leisteten und erst Wochen später mit Spam aktiv wurden.
Interessant. Mir ist gar nicht bewusst gewesen, dass Gmail diese Unterscheidung tatsächlich trifft. Heute habe ich ein paar neue Dinge gelernt. Ich frage mich, warum sie das tun? Es scheint, als würde das ziemlich viel Platz verbrauchen. Sind nur Gmail-Adressen hier ein Problem?
Ich denke, wir sind bei „Ich fühle mich unwohl mit dem Ort, an dem wir gelandet sind, denn das ist ein Albtraum für den Support und wird nie verschwinden :)“ gelandet.
Meiner Meinung nach sollte es einer Website, die ein Spam-Vektor ist, erlaubt sein zu sagen: „Machen Sie alle meine E-Mails kanonisch“. Die Nachteile interessieren mich nicht.
Das bedeutet, dass diese beiden E-Mails beide den kanonischen Wert samsam@somewhere.com haben:
sam.sam@somewhere.com
samsam+11@somewhere.com
Wenn sam.sam@somewhere.com registriert wurde, kann samsam+11@somewhere.com nicht mehr registriert werden.
Das war meine ursprüngliche Lösung, die ich schließlich wieder rückgängig gemacht habe (obwohl sie speziell für Google angepasst war – was rückblickend nicht hart genug war).
Ich bin der Meinung, wir sollten diesen Punkt einfach hinter uns lassen, indem wir eine neue Site-Einstellung hinzufügen für:
„OMG, ich bin ein riesiger Spam-Vektor, schalte den Mega-Tinfoil-Modus ein“
Bezüglich des Bugs: Dinge können jetzt leicht durchschlüpfen, wenn man das Blockieren hinauszögert. Derzeit ist es ein 100 % reaktiver Prozess.
Das bedeutet, dass dies problemlos funktioniert (du kannst es gerne in der Konsole testen, @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
Das Problem ist:
# Hunderte von Konten erstellt
ScreenedEmail.block('examplemailaddress@gmail.com')
# Hunderte von Konten sind immer noch da
Ach ja, die ursprüngliche Anfrage, alle E-Mails mit Sonderzeichen hinter einer Site-Einstellung zu blockieren. Ich dachte, ich hätte das vorgeschlagen und es dir nicht gefallen? Ich kann mich nicht mehr erinnern.
Ich denke, das alles läuft darauf hinaus, dass @markersocial eine Funktion wünscht (erzwungene kanonische Zuordnung, wie ich sie ursprünglich implementiert habe), die keiner unserer Tausenden von gehosteten Kunden zu benötigen scheint.
Wir können die reaktive Funktion weiter verfeinern (Suche nach kanonischen Einträgen beim Blockieren und Aufforderung an den Administrator, lästige Konten zu löschen). Ich würde jedoch lieber erst einige wiederholte Beschwerden hören.
Eine auf Regex basierende Blockierung wird für @markersocial sicher nicht funktionieren, aber ich freue mich, wenn er das bestätigt.
Ich habe keine Reproduktion des Problems im ursprünglichen Beitrag und vermute stark, dass die problematischen Konten vor dem Hinzufügen der Blockierung erstellt wurden.
Ich kann bestätigen, dass die ursprüngliche Lösung perfekt funktioniert hat und dieses Problem mit Gmail-Adressen gelöst hat. Es wäre eine echte Lebensrettung, wenn dieser optionale Modus wieder eingeführt würde.
Spammer lernen ständig neue Techniken und umgehen weiterhin erfolgreich große Player wie Facebook, Instagram und Twitter. Das macht die meisten anderen Plattformen zum „Leichtmodus“. Für viele von ihnen ist dies ein Vollzeitjob, sodass es im Wesentlichen darauf hinausläuft:
Wenn etwas ausnutzbar ist und (die erforderlichen Ressourcen < der verdiente Gewinn), dann wird es ausgenutzt.
Sie können praktisch jede Maßnahme umgehen; die einzige Hoffnung besteht darin, die Kosten dafür so hoch zu treiben, dass es sich finanziell nicht mehr lohnt.
Die Möglichkeit, massenhaft Spam mit nahezu unbegrenzt vielen E-Mails/Konten zu versenden (vor der Erkennung und einer nachträglichen Blockierung der kanonischen Gmail-Adresse durch einen Moderator/Admin sowie dem manuellen Löschen ihrer Beiträge) ist sehr kosteneffizient. Noch mehr, wenn es kein 24/7-Moderatorenteam gibt.
Die Kosten, um Anti-Spam-Maßnahmen zu umgehen, sinken kontinuierlich. Ein Beispiel sind 4G/5G-Proxies: Für etwa 30–50 US-Dollar pro Monat können Menschen Zugriff auf praktisch unbegrenzte echte mobile IPs erhalten, von legitimen ISPs/ASNs, die automatisch/manuell rotieren und von ganzen Städten/Staaten legitimer Nutzer großer ISPs geteilt werden. 4G/5G-IPs werden von vielen Nutzern gleichzeitig geteilt.
Das Blockieren dieser ISPs/ASNs oder IPs ist nicht geeignet (man kann nicht einfach alle Nutzer von Verizon, AT&T usw. blockieren). Sie verwenden die IP in der Regel nur einmal und verwerfen sie dann. Die blockierten einzelnen IPs würden zudem legitime Nutzer blockieren, die zufällig dieselbe IP-Adresse teilen. IP-Blockaden werden langsam zu einer veralteten Praxis (ausgenommen ASNs bekannter Hosting-Unternehmen). Man kann die Spitze des Eisbergs in diesen Foren sehen:
Ich glaube, die Spammer bestehen aus einer Mischung aus vollständig oder teilweise selbst entwickelten Bots und manuellem Spam. Da Discourse zunehmend Marktanteile gewinnt – was eindeutig fantastisch wächst – würde es mich wundern, wenn es nicht zum Ziel kommerziell verfügbarer Bots würde.
Sobald Xrumer die neueste Version von reCAPTCHA unterstützt, würde ich sagen, dass die meisten Webmaster in Legacy-Foren einen starken Anstieg des Spams bemerken, da die Kosten für Spamming auf ein absolutes Minimum gesunken sind (man muss keine Captcha-Lösungs-API mehr verwenden, die ohnehin bereits sehr günstig pro 1.000 Lösungen ist):
http://botmasterlabs.net/buy1/
Leute können bereits eigene Plugins/Skripte erstellen, um praktisch jede Plattform mit Xrumer zu unterstützen. Aber wenn sie Discourse eines Tages „out of the box“ unterstützen:
Ich kann nicht behaupten, dabei unparteiisch zu sein, da ich selbst dringend Anti-Spam-Maßnahmen benötige. Der ursprüngliche Beitrag über den Gmail-Punkt-Trick wurde 2014 von jemand anderem erstellt, und es scheint, dass ein anderer Benutzer dies gelöst hat, indem er eine Genehmigung für die ersten x Beiträge erforderlich machte. Vielleicht gibt es also mindestens drei Benutzerberichte?
Entschuldigung für den Abschweif, zurück zum Thema.
Bezüglich des Regex-Blockierens für E-Mails: Ja, Sie haben recht. Es ist eine teilweise Lösung, aber aus folgenden Gründen nicht ideal:
Wenn man alle Gmail-Adressen mit einem Punkt oder mehr vor dem @ blockiert:
Es werden unvermeidlich echte, legitime Gmail-Nutzer blockiert, die entweder einen oder mehrere Punkte in ihrer Gmail-Adresse haben, was sehr häufig vorkommt.
Spammer können trotzdem mit nur einem Punkt viele Variationen erstellen. Beispielsweise hat Gmail eine maximale Länge von 30 Zeichen, z. B. 12345678901234567890123456789.0@gmail.com. Das ergibt 30 verwendbare Kombinationen mit einem einzigen Punkt.
Wenn man alle Gmail-Adressen mit zwei Punkten oder mehr vor dem @ blockiert:
Weniger legitime Gmail-Adressen werden blockiert, aber es werden dennoch legitime Gmail-Nutzer blockiert, die mehr als einen Punkt in ihrer E-Mail-Adresse haben.
Spammer können mit einer einzigen 30-Zeichen-Gmail-Adresse noch viel mehr Variationen erstellen. Ich schätze etwa 842 Kombinationen.
Ich kann bestätigen, dass die neuen Konten nach Aktivierung der Blockierung erstellt wurden, da das Blockierungsdatum der 1. Februar ist. Ich habe gestern die Erstellung neuer Konten beobachtet und dabei sowohl Fälle gesehen, in denen die Blockierungsregel neue, kürzliche Übereinstimmungen aufwies, als auch neue Registrierungen, die Kombinationen derselben E-Mail (nur Punkte) verwendeten.
Ich habe die Registrierungen über Nacht deaktiviert und heute Morgen wieder aktiviert. Bisher wurden heute 104 neue Konten mit Permutationen dieser Gmail-Adresse erstellt, und es werden weiterhin mehr registriert. Ich kann bestätigen, dass, sobald die Punkte aus den E-Mails dieser Konten entfernt werden, eine exakte Übereinstimmung mit dem blockierten Eintrag der Screened Emails vorliegt.
Ich habe versucht, die Blockierungen wie beschrieben in rails c zu testen. Hier wird es etwas seltsam.
Es scheint, dass einige Einträge wie beabsichtigt „true“ zurückgeben, während andere „false“ zurückgeben, selbst wenn die getestete E-Mail exakt mit der kanonisch blockierten E-Mail übereinstimmt. Für die Einträge, die „true“ zurückgeben, funktionierte alles wie vorgesehen, und es wurde für alle getesteten Variationen „true“ zurückgegeben. Aber bei den E-Mails, die „false“ zurückgeben, gaben alle getesteten Variationen ebenfalls „false“ zurück.
Ich habe versucht, Korrelationen zu finden. Ich kann bestätigen, dass diese nicht korreliert sind (oder zumindest nicht konsistent korreliert):
E-Mail-Länge (vor @)
E-Mail enthält Zeichen und Zahlen
Übereinstimmungen (Anzahl der Blockierungen)
Datum der Übereinstimmung
Es scheint jedoch eine Korrelation mit dem Blockierungs-Erstellungsdatum zu geben: Je älter, desto unwahrscheinlicher ist es, dass es funktioniert (gibt „false“ zurück). Einträge, die vor 9 Tagen erstellt wurden, gaben eine Mischung aus „true“ und „false“ zurück, und alle Einträge, die ich bisher getestet habe und die früher erstellt wurden (1 Stunde bis 8 Tage), geben „true“ zurück.
Vielleicht hängt das mit „max age unmatched emails“ zusammen? Ich denke, diese Option ist etwas neu; ich habe sie auf den Standardwert von 365 Tagen eingestellt.
Nun, wenn Sie detaillierte Schritte zur Reproduktion eines Fehlers angeben können, werden wir ihn definitiv beheben.
max age unmatched emails ist jedoch keine neue Einstellung – zusammen mit max age unmatched ips dient es dazu, wirklich alte Einträge in den Listen der geprüften IP-Adressen bzw. E-Mail-Adressen zu bereinigen, also Einträge, die seit einem Jahr nichts mehr übereinstimmen.
Ich verstehe, was du meinst. Ich glaube, eine der Hauptbedenken von @codinghorror gegenüber der ursprünglichen Implementierung war, dass wir eine spezielle Google-Logik mitführten. Das machte Jeff ziemlich nervös.
Ich denke, die Verfeinerung, dass „alles kanonisch wird, unabhängig von der Domain“, mildert dieses Anliegen etwas ab.
Zum Beispiel:
sam+982@sam.com – darf sich registrieren … zuerst sam@sam.com s.a.m.@sam.com – darf sich nicht registrieren … beim zweiten Mal habe ich festgestellt, dass sam@sam.com bereits registriert ist.
Das könnte eines Tages wieder eingeführt werden; wir müssen nur den Missbrauch an anderer Stelle finden. Beim letzten Mal, als ich das untersucht habe, sind wir bei unserem Hosting auf keinen solchen Missbrauch gestoßen.
Es scheint, als würde das ziemlich viel Platz verbrauchen. Sind nur Gmail-Adressen hier ein Problem?
