SourceForge beendet Unterstützung für Hosted Apps => kein Wiki mehr

[makki]

Wiki

Ich hab jetzt endgültig zugemacht, Neuregistrierung gibts nur noch über die Admins (me, ChrisM, swiss, vento, ...)

Für intern: Manual:Preventing access - MediaWiki

Ich arbeite an einer Fail2Ban-Regel mit einer handvoll Honeypots in der nähe.. 90% erwische ich schon aber das wären immernoch 3 Spammer/Woche - zuviel für meine nerven..

Makki

[swiss]

Hallo makki

Hast du dir mal die Benutzerliste angesehen? Ich befürchte dass 50% "schläfer accounts" sind. Seltsam ist, dass pro Tag 3-4 Registrierungen stattgefunden haben und das über Monate und mit den seltsamsten Namen... Wenn ich heute abend dazu komme geje ich dem Verdacht mal nach. Wenn dem wirklich so ist, wird das Spamen auch in nächstet Zeit weiter gehen ausser du sperrst die "writeapi" für die Gruppe alle

[vento66]

Oder wir sperren mal auf Verdacht die üblichen Verdächtigen. Wenn wir jemanden unschuldigen erwischen, so kann er sich ja gern melden, und wird natürlich wieder freigeschaltet.


Sent from my IPhone using Tapatalk

[vento66]

Oder wir sperren mal auf Verdacht die üblichen Verdächtigen.

Done! Ich hab jetzt mal sehr willkürlich angefangen die ersten User zu sperren. Wer zu unrecht darunter gefallen sein sollte, den bitte ich um entschuldigung! Eine kurze Mail an mich und es wird selbstverständlich wieder geändert!

[swiss]

Hallo Vento

Habe mir mal erlaubt die DB durchzusehen. Theoretisch könnte man mal alle Benutzer löschen deren Mailadresse nicht bestätigt wurde. Dann fliegen schon mal ca. die Hälfte bis 2/3 der falschen Benutzer raus. Dann wird es meiner Meinung nach auch wesentlich übersichtlicher. Es handelt sich um rund 80 Accounts von insgesammt 270 registrierten.

Allerdings mach ich mal noch nichts bis wir das ordentlich diskutiert und mehrheitlich beschlossen haben

[makki]

Macht ruhig, steht ja ggfs. alles im Log.. Ich glaube eher das >90% der User fakes/spammer sind..

Deren Intention stellt mich allerdings immernoch vor ein Rätsel: Vermute die testen nur - und das faszinierenderweise IMHO händisch nach den Logs..

Wobei ich das dazu benutze, für die Honeypots zu lernen damit sie garnicht soweit kommen Ist noch nicht "heiss aktiv" aber wird..
(Primär gehts da natürlich um anderes, was wir und unsere Kunden so nutzen, WP, Typo3, ... SQL-Injection, Brute-force auf SSH/POP3/SMTP usw. - die Freunde erde ich am liebsten global gleich im Backbone auf Layer3/IP-Ebene - das witzige ist: es gibt durchaus deckungsgleichheit mit den Wiki-Spammern)

Wenn man deren treiben auf 6000 IP's mal auswertet, schon lustig..
Gute sysadmins sind ja ansich faule Menschen, die wollen solche Kerles am liebsten mit ner RegExp dauerhaft erschlagen

Makki

[swiss]

Naja das mit den IP's bannen ist so eine sache. Die wehnigsten haben eine feste IP. Wenn ich spamen wollte und meine IP geblokt wird, baue ich einfach die Verbindung zum Privider neu auf und erhalte dabei auch eine neue IP. Und es könnte geschehen, dass plötzlich unschuldige Interessente ausgespert werden weil ihre neue IP zufälligerweise zuvor von einem Spamer missbraucht wurde.

Da bräuchte es meiner Meinung nach in einem offenen System andere Mechanismen...

- Cabtcha für die Registrierung
- 2 Tage limit für die Mailbestätigung sonst automatische löschung
- Spamfilter mit automatischer Sperrung bei Spamverdacht
- Spamfilter der verdächtige Versionen nicht automatisch veröffentlicht sondern ein Mail an die Admins sendet die dann über löschen und veröffentlichen entscheiden.

Mit diesen paar Massnamen vergeht den Spern ganz schnell der Spass. Vor allem wenn Spambeiträge nicht automatisch veröffentlicht werden und sie sich immer von Hand registrieren müssen. Die Frage wäre, wie man das umsetzen könnte. Es gibt zwar entsprechende Addons zum Wiki aber in wie weit sie die Anforderungen erfüllen weiss ich auch nicht.

[dombn]

Nur lass die Captchas weg, die Teile nerven eher als dass sie etwas bringen. Ziemlich viele sind leichter maschinell, als von Menschen zu lösen. Alternativ gibt es Spammer, die Menschen zum Lösen einsetzen, indem sie ihnen entweder ein »attraktives« Ziel (meist etwas mit nackter Haut oder teilweise auch nur ein paar Cent) hinter dem Captcha anbieten.

Bessere Lösungen verwenden, z.B.

• Token (ganz simpel ein zufälliger Wert, der sich je Anfrage ändert)
  Spammer fliegen auf die Nase, da diese meist automatisiert nur die Formularinhalte senden
• Zeitsperren (alles was zu schnell ausgefüllt wurde, wird abgewiesen)
  Hält viel Spam ab, da die Bots in der Regel möglichst schnell ihre Daten einsenden und dann weiter ziehen
• Honeypot-Felder (Felder die leer bleiben sollen, aber von Bots ausgefüllt werden)
• oAuth (»Fremdautentifizierung«)

[swiss]

Hallo dombn

Naja wenn die Captchas nur für die Registrierung eingesetzt werden dann belastet es jeden Benutzer nur 1 mal in sienem Leben. Der Spamer ist selber Schuld wenn er immer wieder von Hand einen Account anlegen muss. Und JA... Es gibt viele schlechte Captchas aber auch einige die was taugen.

Es ist ja auch nur eine Massname in einem ganzen. Jede der Massnamen für sich bringt nicht viel aber zusammen können sie sehr wirkungsvoll sein.

Token finde ich nicht gut. Das Belastet die unschuldigen Benutzer zusehr. Ich will nicht für jeden kleinen Typo-fix einen Tokencode eingeben müssen. Dazu kommt, dass ein Token nur etwas bringt, wenn er über einen getrennten Kanal übermittelt, Generiert oder ausgegeben wird. Wenn du doof gesagt den Tokencode auf der Webseite ausgiebst, ist das überhaubt keine Hürde für Spamer.

Das Ziel sollte sein die Spamer möglichst effektiv zu bekämpfen mit Mitteln die die normalen Benutzer möglichst wehnig belasten/belästigen. Das ist auch immer wieder eine Gratwanderung... Aber lösbar

[greentux]

Wärs eigentlich so schlimm, die Accounts wie beim SVN manuell anzulegen?
Ich wein, im Wiki werden vl. 5-10 Leute was eintragen. Das sollte jedwede Aufwände für Captchas und Co aufwiegen.

[swiss]

Naja das ist momentan auch so. Allerdings hält das warscheinlich wieder den einen oder anderen davon ab uns spontan zu unterstützen.

Die Frage ist immer, was man will. War ja auch nur eine Idee. Desshalb diskutieren wir ja hier. Vieleicht hat ja jemand zufälligerweise "DEN MASTERPLAN"

Am Ende wird es aber immer ein Kompromiss bleiben. Egal welche Lösung am Ende dabei herauskommt.

[dombn]

Hallo dombn
[…]Token finde ich nicht gut. Das Belastet die unschuldigen Benutzer zusehr. Ich will nicht für jeden kleinen Typo-fix einen Tokencode eingeben müssen. Dazu kommt, dass ein Token nur etwas bringt, wenn er über einen getrennten Kanal übermittelt, Generiert oder ausgegeben wird. Wenn du doof gesagt den Tokencode auf der Webseite ausgiebst, ist das überhaubt keine Hürde für Spamer.[…]

Hups, ich wusste ich hätt's deutlicher schreiben sollen:

• gemeint war kein Hardwaretoken, das wäre wohl etwas überzogen
  (nichts gegen eine Yubikey-Unterstützung, aber das meinte ich in dem Fall gar nicht)
• Gemeint war tatsächlich ein unsichtbarer Tokencode im Formular. Alleine die Maßnahme schützt schon ziemlich zuverlässig gegen sehr viele Spambots, die machen sich nämlich meist nicht die Mühe zuerst das aktuelle Token abzufragen. Stattdessen senden sie ewig lang verschiedene Daten mit ewig alten Token = die Daten werden einfach verworfen.
• Zusammen mit der »Zeitsprüfung« können meiner Erfahrung nach die meisten automatisierten Spambots abgewiesen werden.

Allerdings helfen beide Maßnahmen im Prinzip nur gegen maschinelle Spambots. Aber gegen menschliche Spammer helfen auch die Captchas nicht.



Gute Erfahrung habe ich auch mit dem Project Honeypot gemacht. Es lässt sich einfach integrieren und bietet einen guten Schutz. Es hilft auch gegen manuelle/menschliche Spammer.

[swiss]

Ach soo Ok das ist etwas anderes. Also eine Art SessionID für jeden EDIT.

Aber wie gesagt. Keine Massname für sich bringt die Lösung. Desshalb würde ich für die Menschlichen Spamer ja zusätzlich noch einen Spamfilter mit automatischer "Zensierung" und Autoblockierung vorschlagen.

So unter dem Motto... Wenn da mehrere Schlagwörter wie "Best Offer", "Price" "Buy" usw.. vorkommen, bracht der Beitrag die manuelle Freischaltung durch die Admins, damit der Beitrag überhaubt in's Wiki übernommen wird. Denn wenn die menschlichen Spamer merken, dass keiner ihrer Spambeiträge auch nur kurz im Wiki erscheint verlieren sie sehr schnell das Interesse. Oder stelle ich mir das zu einfach vor?

[fanta2k]

Die einfachste spamkontrolle die idr 99% des spams tilgt ist einfach eine kontrolle ob im ersten beitrag/edit ein externer link enthalten ist.

Oder stelle ich mir das zu einfach vor?

da spammer idr bots sind ,ist denen das egal - es werden fröhlich neue accounts und posts abgesetzt.

jenachdem welche spambots es auf einen abgesehen haben, hilft auch recaptcha usw nichtsmehr.

[swiss]

Jup aber gegen Bots müsste man ja wieder angepasste Metoden wie die E-Mail Validierung (und sperrung der Spamer Mailadressen) ev. ein gutes Captcha zur Registrierung und Autoblockierung des Accounts bei Spamverdacht einsetzen.

Ich denke dass keiner einen solchen Aufwand (softwaretechnisch oder mit menschlichen Resourcen) betreibt, wenn die Spambeiträge nie veröffentlicht werden da durch den Spamfilter schon im vorfeld abgefangen.

Das mit den Links ist etwas schwierig umzusetzen da in jedem Beitrag dutzende Links stecken und auch Vreweise zu externen Inhalten durchaus gewollt/beabsichtigt sind wenn sie imZusammenhang mit der CV stehen.

Hoby Spamer werden sich vieleicht 1-2 mal neu registrieren und wenn sie feststellen, dass ihr Gespame nichts bewirkt automatisch damit aufhören.

Professionelle Spamer haben bestimmt die Möglichkeit die meisten Hürden wie die Mailvalidierung und Captchas zu umgehen. Doch auch das muss ein gewisser Aufwand seitens der Spamer aufgebracht werden und wenn die merken dass die Spambeiträge automatisch zensiert werden, werden diese ihre Energie und Resourcen bestimmt auf andere Platformen mit mehr Publikum konzentrieren und uns in Ruhe lassen.

"Was keinen Effekt erziel verliert irgend wann an Reiz". Es ist wie mit Tresoren. Jeder Tresor kann geknackt werden. Der Aufwand muss einfach höher sein als der Ertrag