Manual:Combating spam/de

Wikis sind ein häufiges Ziel für Spammer, die ihre Produkte oder Webseiten aufgrund ihrer offenen Bearbeitungsnatur bewerben wollen. MediaWiki bietet eine Reihe von Funktionen, die dazu gedacht sind, Wiki-Spam zu blockieren.

Typische Werkzeuge gegen Wiki-Spam fallen in folgende Kategorien:


 * Einsatz von Benutzer-Validierung und/oder CAPTCHAs bei bestimmten Operationen, wie z.B. Seitenbearbeitungen, neue externe Links oder das Anlegen neuer Seiten
 * Blockierung von Robots und offenen Proxys von bekannten IP-Adressen (blacklist)
 * Blockierung von Bearbeitungen, die spezielle unerwünschte Schlüsselworte oder externe Links enthalten
 * Blockierung von Benutzernamen und Seitentiteln, die Muster enhalten, welche häufig von Spam-Bots benutzt werden
 * Blockierung von Bearbeitungen durch neue oder anonyme Benutzer auf häufig betroffenen Seiten
 * Freischaltung (Whitelist) von bekannten, gutwilligen Benutzern (Admins, regelmäßige Benutzer) bei gleichzeitger Einschränkung von neuen, unbekannten oder anonymen Benutzern
 * Automatisiertes Aufräumen oder Löschen (Nuke) bestehender Einträge von kürzlich blockierten Spam-Bots

Üblicherweise wird eine Kombination verschiedener Methoden benutzt, um zu versuchen die Anzahl von Spam, Roboter und Open-Proxy-Bearbeitungen zu beschränken, dabei aber die Auswirkungen auf die regulären Benutzer so gering wie möglich zu halten.

Individuelle Seiten-Beschränkungen
Häufig ist ein- und dieselbe Seite mehrfach von Spam-Bots betroffen. Häufige Muster, die bei Spam-Bot-Bearbeitungen beobachtet werden sind:


 * Name einer regulären Inhaltsseite desselben Wikis, an den '/' oder '/index.php' angehängt wird.
 * Diskussionsseite eines Artikels, häufig ausserhalb des Hauptnamensraums (Forum Diskussion: und Kategorie Diskussion: werden selten genutzt und sind daher beliebte Ziele)
 * Seiten in Forum: und Diskussion:

Die meisten missbräuchlichen Bearbeitungen in Wikis, die keine Registrierung zum Bearbeiten erfordern, stammen von anonymen Nutzern. Es lohnt sich daher, Seiten die von anonymen Benutzern erzeugt oder bearbeitet wurden, von der weiteren Bearbeitung durch anonyme Benutzer auszuschliessen. Typischerweise sind Seiten, die bereits in Special:Log/delete gelistet sind, gute Kandidaten für einen Seitenschutz.

Wie geht man vor:


 * Häufig mit Spam versehene Seiten können vor dem Bearbeiten durch neue oder anonyme Benutzer durch Sperrung für neue und nicht-registrierte Benutzer geschützt werden.
 * Zusätzlich kann dies mit der Einstellung für Auto-Confirmation kombiniert werden, die das Alter für nicht-neue Nutzer vorgibt.
 * Kaskadierter Seitenschutz kann auf Seiten genutzt werden, die Links zu den häufigst gespammten Seiten haben. Solche Seiten können als praktischer Trick extra zu diesem Zweck durch einen Admin angelegt werden.

Bearbeitungsfilter
MediaWiki stellt mit der Konfigurationsvariable $wgSpamRegex eine Methode zu Filterung von Bearbeitungen bereit, um unerwünschte Texte zu verhindern. Dies kann genutzt werden um Texte oder typische Text-Schnipsel, die häufig in Spam-Attacken verwendet werden, zu blockieren. Zum Beispiel:

blockiert Bearbeitungen, die versuchen versteckte oder überlaufende HTML-Elemente zu erzeugen - ein häufiger Trick von Massen-Spammern, um ihre Inhalte unauffällig zu platzieren.

Die AbuseFilter Erweiterung wird auf Wikimedia benutzt und stellt einen effektiven Anti-Spam-Filter dar.

SpamBlacklist
Eine populäre Erweiterung für MediaWiki ist die SpamBlacklist Erweiterung, die Bearbeitungen blockiert, die versuchen schwarzgelistete (verbotene) URLs einer Seite hinzuzufügen. Die TitleBlacklist Erweiterung kann auch nützlich sein, um das wiederherstellen von speziellen Gruppen von Seitentiteln zu verhindern.

CAPTCHA
Eine der üblicheren Methoden, automatisiertes Bearbeiten auszuschliessen, ist die Benutzung von CAPTCHAs. Die ConfirmEdit Erweiterung für MediaWiki stellt eine erweiterbare CAPTCHA-Grundstruktur zur Verfügung, das von einer Reihe von Ereignissen ausgelöst werden kann, z.B.:


 * alle Bearbeitungen
 * Bearbeitungen, die neue, unbekannte externe Links enthalten
 * Benutzerkonten-Erstellung

Die Erweiterung enthält einen Standardtest, der aber nur als Referenz-Implementierung und nicht für den produktiven Einsatz gedacht ist. Bei der Installation von Wikis sollte bei Benutzung von ConfirmEdit darauf geachtet werden, dass eines der fünf enthaltenen CAPTCHA-Module benutzt wird.

Weiterhin ist zu beachten, dass CAPTCHAs mehr als unerwünschte Bots aussperren können, z.B. Vorlese-Automaten oder andere Software, die Blinden oder Sehbehinderten die Benutzung ermöglicht. Eine der Optionen in CAPTCHA umfasst die "reCAPTCHA" Vorrichtung, die eine alternative Audio-CAPTCHA für solche Fälle enthält - aber einige Computer-Anwender scheitern an den Hör- und Lesetests, somit ist dies keine Komplettlösung. Sie sollten die Auswirkungen einer solchen Barriere beachten und gegebenenfalls eine alternative Einrichtung für die betroffenen Benutzer-Konten erstellen und dazu beitragen, das ist in einigen Ländern gesetzlich vorgeschrieben.

IP-Adressen Sperrlisten
Eine große Menge des problematischen Spam-Aufkommens stammt von IP-Adressen, die bereits als Bots oder offene Prodies wohlbekannt sind. Diese Bots führen typischerweise große Mengen von automatischen Benutzer-Anmeldungen bei Foren, kommentieren Spam auf Blogs und vandalieren Wikis (meist Link-Spam, aber auch Entfernung oder Ergänzung des Seiteninhalt mit zufälligen Texten, die auch den existierende Unicode-Text unlesbar machen kann). Werden die Letzten Änderungen zu lange unbeobachtet gelassen, so füllen sich die Bearbetungs-Kommentare mit häufig unlesbaren Buchstaben und der Wiki-Inhalt verwandelt sich in zufälligen Text und Link-Spam.

Eine relativ einfache CAPTCHA-Lösung mag das Problem signifikant reduzieren, ebenso wie die Blockierung von üblichen Spam-Seitentiteln. Diese Maßnahmen eliminieren allerdings nicht das Problem und führen stattdessen zu einer erhöhten Wiki-Sicherheitsstufe, was zu Problemen mit den Benutzern des Wikis führt.

Anstatt auf CAPTCHAs und andere einschränkende Maßnahmen zu vertrauen ist es vorteilhafter, die IP-Adressen vom Editieren auszuschließen, die bereits von anderen Webseiten-Betreibern als "übliche Verdächtige" bekannt sind. Viele solche IP-Adressen-Listen sind erhältlich, z.B. hat stopforumspam.com eine Liste von allen IPs als CSV, die ca. 200.000 IPs von bekannten Spam-Bots enthält, die einmal täglich aktualisiert wird.

Beispiel: Importieren von stopforumspam's IP Liste
Eine große Liste von Spam-Bots individuell einzugeben, ist viel zu aufwändig, aber eine bestehende Liste zu kopieren und zu verwenden kann mit einem Unixoiden Betriebssystem in wenigen Minuten getan werden.

Eine ausführliche Beschreibung mit einem entsprechenden Skript befindet sich auf der englischen Seite.

Honeypots, DNS BL's and HTTP BL's
140.000 Spammer erledigt. Nicht schlecht, aber jeder anständige BOFH wäre an diesem Punkt gelangweilt und fragt sich, wie wohl der 140.001-te Spammer blockiert werden kann.

Glücklicherweise gibt es dynamische Listen von Spambots, Open Proxies und anderen problematischen IPs, die frei erhältlich sind. Viele enthalten auch Benutzernamen oder e-mail-Adressen, die automatisch überprüft werden können.

Eine Form von Sperrlisten, die vielleicht MediWiki-Administratoren bekannt ist, ist DNS BL. Diese benutzt einen Domain Name Server, die DNS blacklist ist eine Datenbank von IP-Adessen. Ein einfacher Adress-Lookup kann feststellen, ob eine IP-Adresse von der gerade eine Bearbeitung oder Benutzeranmeldung stattfindet, eine Quelle von Spam oder anderem Missbrauch ist.

Die Einstellungen $wgEnableDnsBlacklist und $wgDnsBlacklistUrls in MediaWiki erlauben einen simplen Zugang zu einer DNS-Blacklist. Mit folgenden Einstellungen  in LocalSettings.php werden IP addresses die als HTTP-Spam gelistet sind, blockiert.

Die englische Seite enhält hier eine genaue Beschreibung der Funktionsweise von DNS BL.

Weitere Listen von Proxy- und Spambot IPs
Typischerweise liefert eine Suchmaschine auf eine Suchanfrage mit einer Spambot oder Open-Proxy-IP-Adresse eine Reihe von Listen, bei denen diese Adresse bereits als solches bekannt ist. In einigen Fällen stammen diese Listen dann von Anti-Spam-Seiten.

Während alle Klartext-Listen offener Proxys noch manuell in ihrem Wiki importiert werden müssen, kann ein Spambot-Suchwerkzeug als automatisiertes Skript konfiguriert werden, um eine der folgenden Datenbanken abzufragen:


 * 1) fSpamlist - fspamlist.com
 * 2) StopForumSpam - stopforumspam.com
 * 3) Sorbs - sorbs.net
 * 4) Spamhaus - spamhaus.org
 * 5) SpamCop - spamcop.net
 * 6) ProjectHoneyPot - projecthoneypot.org
 * 7) Bot Scout - botscout.com
 * 8) DroneBL - dronebl.org
 * 9) AHBL - ahbl.org
 * 10) s5h spam - forum.s5h.net

Es ist auch möglich, Benutzeranmeldungen von anonymisierten Zugängen wie z.B. den Tor-Proxies (Tor Project - torproject.org), oder Bugmenot-Benutzer, die eine E-Mail-Adresse zur einmaligen Benutzung verwenden (gelistet auf undisposable.net) auszuschliessen.

Siehe auch Blacklists Compared - 1 March 2008 und [spamfaq.net], die Listen von Blacklisten anbieten.

Es ist natürlich immer möglich, dass diese Listen falsch-positive Adressen enthalten. Einige Listen enthalten auch bekannte dynamisch-zugewiesene IP-Adress-Blocks, deren Ausschluss ein Wiki zu gut wie unbenutzbar machen kann.

To link to IP blacklist sites from the Special:Blockip page of your wiki (as a convenience to admins wishing to manually check if a problem address is an already-known 'bot): Um IP-Blacklist-Sites einfach von der Special:Blockip-Seite verwenden zu können (als praktische Unterstützung für den Admin) dienen folgende Konfigurationsänderungen:


 * 1) In LocalSettings.php einfügen: $wgNamespacesWithSubpages[NS_SPECIAL] = true;
 * 2) Folgender Text in MediaWiki:Blockiptext: " IP überprüfen bei Domain Tools, OpenRBL, Project Honeypot, Spam Cop, Spamhaus, Stop Forum Spam. "

Dies fügt Links zu "IP überprüfen bei Domain Tools, OpenRBL, Project Honeypot, Spam Cop, Spamhaus, Stop Forum Spam" auf der "Block-IP"-Seite ein.

Es ist zu beachten, dass die Blockierung von IP-Adressen nicht dasselbe ist wie das Blockieren von URLs von externen Links von Spam. Beide Verfahren sollten in Kombination genutzt werden um weitere Anti-Spam-Tools wie Titel oder Benutzernamen blacklists und Bestätigung von Bearbeitungen zu unterstützen, die zwischen Benutzern und Bots mittels (captcha, bad behaviour oder akismet) zu unterscheiden versuchen.

rel="nofollow"
In der Standardkonfiguration fügt MediaWiki rel="nofollow" an externe Links, um anzuzeigen dass diese Links von Benutzern eingefügt wurden, Spam enthalten könnten und daher nicht einen Page-Rank-Algorithmus beeinflussen sollten. Populäre Suchmaschinen wie Google halten sich an diesen Hinweis.

Dieses Verhalten kann systemweit mit $wgNoFollowLinks oder für einzelne Namensräume mit $wgNoFollowLinks abgeschaltet werden.

Die Benutzung des rel="nofollow" Attributs hält Spammer nicht davon ab, ihren Spam zu hinterlassen, aber es verhindert zumindest, dass sie von dem erhöhten Page-Rank profitieren. Daher reicht diese Massnahme nicht aus, um Spam zu verhindern.

Einschränkung von Bearbeitungsrechten
In einigen Fällen ist es ausreichend (und angemessen) das Recht auf Bearbeitung von Seiten auf angemeldete Benutzer zu beschränken. Dies kann eine Reihe von automatisierten Attacken ausschliessen. Das Verfahren kann dann mit CAPTCHAs (s. o.) oder Title-Blacklist kombiniert werden.

Es ist auch möglich, MediaWiki so zu konfigurieren, dass eine E-Mail-Verifikation notwendig ist, um bestimmte Seiten bearbeiten zu können.($wgEmailConfirmToEdit = true). Hierzu gibt es unter verhindern des Zugriffs mehr Informationen.


 * "Verhindern des Zugriffs" Überblick
 * $wgGroupPermissions Konfiguration

Selbst wenn Seitenbearbeitungen auf angemeldete Benutzer beschränkt sind, können Spammer automatisch Benutzerkonten anlegen und einen Wiki mit neuen Konten fluten. Dies kann weitestgehend verhindert werden, wenn für Anmeldung und Benutzerkonten-Erstellung ein externer Dienst, wie z.B. Extension:OpenID genutzt wird. Die Erstellung von lokalen Benutzerkonten muss dann folgendermaßen ausgeschlossen werden: $wgGroupPermissions['*']['createaccount'] = false;

Der  sollte dann modifiziert werden, um neue Benutzer darauf hinzuweisen, OpenID zu benutzen. Bestehende Benutzerkonten sind davon nicht betroffen und neue Benutzer haben häufig schon ein OpenID-Konto.

Siehe auch

 * Anti-Spam-Funktionen (engl.)
 * Spam Filter
 * Wiki spam
 * Manual:$wgSpamRegex
 * Manual:Combating vandalism

Erweiterungen

 * Extension:AbuseFilter
 * Extension:AkismetKlik
 * Extension:Bad Behavior
 * Extension:Check Spambots
 * Extension:ConfirmEdit und Extension:QuestyCaptcha
 * Extension:EmailAddressImage und Extension:EmailObfuscator
 * Extension:FlaggedRevs
 * Extension:GlobalBlocking
 * Extension:Nuke
 * Extension:SpamBlacklist und Extension:SpamRegex
 * Extension:TitleBlacklist