Warum sollte er es nicht nutzen? Ich verstehe das nicht. Es löst sein Angriffsproblem.
In diesem Fall wäre der Marketplace vielleicht der beste Ort dafür?
Besser, wenn ein Drittanbieter es kaputt macht, als ein “offizielles” Plugin?
[quote=“Stephen, Beitrag: 42, Thema: 22627”]
Ist es nicht besser, wenn ein Drittanbieter es kaputt macht als ein „offizielles
Ja, aber ich glaube nicht, dass du seine Website nutzt.
Eine gewisse Anzahl ziviler Opfer ist im Krieg akzeptabel. Was macht es also aus, wenn 2 % der Nutzer sich nicht registrieren können, wenn du täglich mit Tausenden gefälschter E-Mails mit Plus-Adressierung überflutet wirst? Das ist ähnlich wie der „I’m under attack“-Modus von Cloudflare. Einige legitime Nutzer werden nicht hineingelassen. Das ist der Preis, den man für strengere Sicherheit zahlt.
Dein Argument ist, dass der „under attack“-Modus von Cloudflare nicht perfekt ist und daher nicht existieren sollte ![]()
Auf jeden Fall müsste ich noch zwei weitere legitime Berichte sehen, die belegen, dass dies ein großflächiges Problem ist, bevor ich etwas unternehme.
Verzeih mir, falls mir etwas Offensichtliches entgangen ist, aber wäre es nicht einfacher, reCAPTCHA auf dem Registrierungsbildschirm hinzuzufügen?
Das sind in der Regel menschliche Spammer. Im Vergleich zu 2010 gibt es heute eine ganze Menge davon. Captchas wirken gegen menschliche Gegner überhaupt nicht.
Okay… ich dachte, diese Art von “Gmail-Punkt-und-Plus”-Registrierung werde hauptsächlich von Bots durchgeführt…
Viele echte Menschen nutzen Dienste wie sharklasers et al. (die dies verwenden), um sich auf unserer Seite anzumelden, weil sie nicht möchten, dass ihr Benutzername mit ihrer realen Person verknüpft wird. Das hängt von den jeweiligen Umständen ab.
Der OP kann eine Lesezeit von 15 Minuten als Vertrauensvoraussetzung für das Posten festlegen, und die ersten 5 Beiträge müssten vom Personal genehmigt werden, das keine Bearbeitungsberechtigungen hat. Damit würde sein Problem, so würde ich wetten, sofort verschwinden.
Eine Sache, die ich hier sicherlich bestätigen möchte, ist, dass wir angemessene Ratenbegrenzungen für Kontoanmeldungen haben.
Eine einzelne IP-Adresse sollte nur erlaubt sein, N Konten pro Tag zu registrieren. Wir benötigen jedoch eine Art Umgehung / Seiteneinstellung für Fälle, in denen NAT dazu führt, dass viele Benutzer dieselbe IP-Adresse teilen.
Ich bevorzuge, dass . für Google normalisiert wird, während +etwas so bleibt, wie es ist. Wenn du das also umsetzen möchtest, lass die Administratoren wählen, was sie wollen.
Das ist bereits der Fall… das Problem hier ist, dass es der Mossad ist. Sie haben eine Vielzahl von IPs zur Verfügung.
Ich sehe Ratenbegrenzungen für:
- E-Mail-Login pro Stunde
- Aktualisierung der Aktivierungs-E-Mail
- Erneutes Senden der Aktivierungs-E-Mail
- Auflisten der zweiten Faktoren
- Aktivieren von TOTP
- Admin-Login
Es gibt keine spezifische Ratenbegrenzung für die Kontoerstellung, abgesehen von der standardmäßigen, IP-basierten Ratenbegrenzung.
Ich frage mich, ob @markersocial den Data Explorer installieren und die Registrierungs-IP-Adressen für die Flut von registrierten Nutzern auflisten kann. Ich möchte sicherstellen, dass diese von 100 verschiedenen IP-Adressen stammen und nicht nur von einer.
Ich würde dem gerne zustimmen, aber Google hat dieses Problem. Zumindest an der Universität, an der ich gearbeitet habe, konnte man keine Klasse für Gmail anmelden, da die Universität den gesamten Zugriff über ein einziges NAT abwickelte.
Ich vermute, dass eine NAT-Whitelist die meisten realen Probleme lösen würde, da es wahrscheinlich vorhersehbar ist, woher legitime Benutzer kommen.
Standardmäßig eine kleine (oder konfigurierbare) Anzahl von IPs pro Tag festzulegen, erscheint mir ziemlich sicher.
@sam – Bezüglich der IP-Adressen: Ich bestätige, dass ich die IP-Beschränkung bei Registrierung und Anmeldung verwende und eine große Liste gesperrter IP-Adressen habe. Ich kann Ihnen versichern, dass es sich nicht um Benutzer handelt, die in erheblichem Umfang Konten von denselben IP-Adressen aus erstellen. Ich wünschte, das wäre der Fall, dann wäre eine Sperrung möglich. Derzeit ist der einzige Weg, sie zu blockieren, die Schwarze Liste für alle Gmail-Anmeldungen.
—
@codinghorror Es gibt einen nicht-illegalen Dienst, der Ihnen für xxx USD pro Monat Zugriff auf xx,xxx,xxx eindeutige IP-Adressen gewährt. Es ist also für jeden einfach, eine große Anzahl von IP-Adressen zu erhalten, nicht nur für den Mossad
. Es gibt viele weitere legale Dienste, die ebenfalls große IP-Pools anbieten. Daneben gibt es noch illegale Dienste, die Botnetze vermieten.
Ich würde definitiv auf die neueste Version upgraden. Zumindest werden die Skripte für dieses Bonanza deutlich lästiger zu schreiben sein, angesichts meiner neuesten Herausforderungen und Honeypot-Änderungen.
Bitte gib uns auch hier regelmäßig Updates, damit wir mehr erfahren können.
Geht das aktuell noch weiter?
Vielen Dank, @sam, und entschuldige, dass ich mich noch nicht darum gekümmert habe.
Ja, es scheint nach wie vor sehr gut möglich zu sein, mit diesem Trick (2.5.0.beta1) viele Konten zu erstellen.
Beispielsweise hat jemand mit der Methode username+{zufälligerString}@gmail.com in den letzten 10 Stunden 748 Konten erstellt. Diese Person hat bereits Tausende von Konten unter dieser einzelnen Gmail-Adresse.
Der einzige Weg, um sie im Admin-Bereich zu entfernen, besteht für mich darin, jedes Konto einzeln aufzusuchen und zu sperren und/oder zu löschen. Das ist nicht sehr praktikabel, da derjenige einfach einen Knopf drücken und noch mehr Konten erstellen kann. ![]()
Sie scheinen über eine praktisch unbegrenzte Anzahl von IPs zu verfügen, daher sind IP-Sperren oder -Begrenzungen in diesem Fall weitgehend wirkungslos.
Außerdem erhalten wir weiterhin regelmäßig eine ganze Reihe von Registrierungen mit den Gmail-Punkt- und Plus-Tricks.
Viele Grüße!
Ich unterstütze die Hinzufügung einer Site-Einstellung @codinghorror, die die Unterstützung für doppelte Gmail-Konten deaktiviert. Technisch gesehen ist es eine Aufgabe von 15 bis 30 Minuten, diese Einstellung hinzuzufügen.
Danke @sam – ich habe dir eine PN mit einigen zusätzlichen Informationen gesendet, die hilfreich sein könnten~
Meine langjährige Erfahrung damit zeigt, dass die meisten automatisierten Spam-Bots (nicht alle, aber die überwältigende Mehrheit) dieselbe ‘HTTP_USER_AGENT’-Zeichenkette verwenden. Selbst einige Spam-Bots, die IP-Adressen fälschen können, nutzen oft denselben ‘HTTP_USER_AGENT’ (oder etwas so offensichtlich Falsches, dass es leicht zu erkennen ist).
Der Grund dafür ist, dass die meisten Bomber und Spammer einfach eine Bot-Spam-Software herunterladen und ausführen, ohne wirklich zu wissen, was sie tun. Ja, es gibt natürlich Ausnahmen, aber 99+ % der Spam-Bots sind lediglich Skripte/Programme, die von nicht wirklich versierten Spammern heruntergeladen und ausgeführt werden (sie sind im Allgemeinen keine Programmier-Giganten).
Tatsächlich sind diese ‘HTTP_USER_AGENT’-Zeichenketten manchmal wirklich offensichtlich. Natürlich ist theoretisch alles zu umgehen, aber in der Praxis hatten wir auf unseren Foren über Jahrzehnte hinweg sehr wenig Spam-Probleme (im Vergleich zu anderen Foren), da wir E-Mail-Adressen anhand verschiedener Kriterien bewerten und die offensichtlichen ablehnen (wir moderieren sie nicht; wenn der Score einen bestimmten Schwellenwert {Vertrauensniveau} überschreitet, lehnen wir die Registrierung einfach ab, denn wer möchte schon eine große Spam-Datenbank moderieren? Niemand.). Außerdem verwenden wir Akismet seit vielen Jahren aus einer Vielzahl von Gründen nicht, aber ich möchte nicht abschweifen ![]()
Auf unseren alten vB-Foren wird dies jedoch problemlos über ein PHP-Plugin erledigt, das sehr einfach zu modifizieren ist (und den guten Kampf in Echtzeit führt). Zeitweise nutzten wir einen Bayes’schen Klassifikator, doch im Laufe der Jahre habe ich bessere Methoden gefunden. Wir haben auch Cookies eingesetzt und erlauben Registrierungen nur von Clients, die die Cookie-Richtlinie akzeptiert haben (und gemäß unserer Datenschutzrichtlinie Cookies zulassen). Zudem können wir nach der Registrierung eines Benutzers ein Cookie auslesen und dies zur Erkennung mehrerer Anmeldungen nutzen. Das stoppt ehrlich gesagt die meisten Spam-Bots. Es ist keine Raketenwissenschaft und basiert im Allgemeinen nicht „nur auf IP-Adressen", um es offen zu sagen.
Übrigens: Die meisten Spam-Bots akzeptieren überhaupt keine Cookies, daher hilft das Blockieren von Clients, die keine Cookies zulassen, bereits sehr.
Ich will nicht zu „weise
… 30 Sekunden später …
![]()