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

[swiss]

Ich weiss

Wollte nur vorerst fragen ob das so in Ordnung ist. Bevor ich da etwas mache und im Nachhinein heisst es... "Ach nöö das Addon ist Müll das von XX ist viel besser" oder wie auch immer

Aberwenn es keine Einwände gibt, werde ich dass nach möglichkeiten morgen Abend mal integrieren. Sollte ja kein Problem sein

[makki]

Nun, auch wenn du es nicht glaubst; du hast SSH-Zugriff auf die Kiste
Wenns was gibt, das fehlt: sagen..

Makki

[swiss]

Naja ich dachte da z.B. an diesen: Extension:SpamBlacklist - MediaWiki

Wenn ich das richtig gelesen habe gibt es da die möglichkeit die Black-Liste automatisch aktualisieren zu lassen. Sollte schon einiges an Spam blocken können

[makki]

Na wiegesagt, so dramatisch ist das nicht: das wird seit Jahren teils händisch geprüft und das sind in jedem Einzelfall gehackte Server oder Botnetz-PC's die da reinlaufen..

Bei den Addons ist Wunschkonzert: sag mir welches Du gerne hättest, dann kommts rein (deswegen mag ich auch "cloud" nicht so gerne wie "mein Server, mein Netzwerk, meine HW" ) - ich kann da bis L1 machen, was ich eben für richtig halte..)

Makki

[swiss]

Ok. Naja bei uns ist ja auch der Kreis der aussländischen Nutzer nicht so gross. Da kann man gut auch mal halb Ammiland über IP Sperrren vom Server bannen ohne dass es gross auffallen würde. Anders wäre es, wenn das Projekt wirklich gross und international wäre. Dann wäre aber auch der administrative Aufwand viel grösser.

Die Frage wäre aber trotzdem, ob man nich vieleicht noch einen Spamfilter integrieren sollt (gibts AFAIK als Addon) damit die Spambeiträge nicht automatisch im Handbuch landen?

Ich beginne derweil mal mit dem löschen der Benutzer die ihre Mailadresse nicht bestätigt haben.

[makki]

Naja das mit den IP's bannen ist so eine sache.

Ah, das geht ganz gut, die üblichen verdächtigen (AS3320, .. ) Whitelisten (wobei es dort weltweit die meisten Zombies gibt..), das trifft 1x im Jahr den falschen..

Im Detail darf ich nicht sagen, wie es läuft aber: Wenn jemand z.B. 6x auf ein nichtexistierendes .php auf einem nicht-existierenden Server zugreift, naja, dann bekommt er halt 24h Timeout, dann darf ers nachm reconnect nochmal 3x probieren.. Nachdem das keine Menschen sondern Bots sind: geht

Makki

[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

[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]

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?

[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]

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.

[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]

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

[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]

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.