Jump to content

Handbuch:Spam bekämpfen

From mediawiki.org
This page is a translated version of the page Manual:Combating spam and the translation is 62% complete.
Languages:

Wie alle aktuellen dynamischen Websites sind Wikis ein häufiges Ziel für Spammer, die Produkte oder Websites bewerben möchten. MediaWiki bietet eine Reihe von Funktionen zur Bekämpfung von Vandalismus im Allgemeinen. Auf dieser Seite beschäftigen wir uns speziell mit Wiki-Spam.

Überblick

Übliche Tools zur Bekämpfung von Wiki-Spam fallen normalerweise in folgende Kategorien:

  • Erfordern einer Anmeldung und/oder eines CAPTCHA für bestimmte Vorgänge, z. B. Bearbeitungen, Hinzufügen externer Links oder Erstellen neuer Benutzer
  • Blockieren von Bearbeitungen von bekannten IP-Adressen auf der schwarzen Liste oder IPs, auf denen Proxys ausgeführt werden
  • Blockieren von Bearbeitungen, die bestimmte unerwünschte Schlüsselwörter oder externe Links hinzufügen
  • Blockieren von bestimmten Benutzernamen und Seitentiteln, die häufig von Spambots verwendet werden
  • Blockieren von Bearbeitungen durch neue oder anonyme Benutzer für bestimmte, häufig anvisierte Seiten
  • Whitelisting von bekannten Redakteuren (wie Admins, regelmäßige Mitwirkende) und Einschränkungen für neue oder anonyme Benutzer
  • Bereinigungsskripte oder Massenlöschung (Erweiterung:Nuke ) vorhandener Posts von kürzlich gesperrten Spambots

Normalerweise wird eine Kombination verschiedener Methoden verwendet, um die Anzahl der Spam-, Roboter- und Open-Proxy-Bearbeitungen so gering wie möglich zu halten und gleichzeitig die Anzahl der Störungen zu begrenzen, die für rechtmäßige Benutzer der Website verursacht werden.

Beachte, dass viele dieser Funktionen standardmäßig nicht aktiviert sind. Wenn du eine MediaWiki-Installation auf deinem Server/Host ausführst, kannst nur du die erforderlichen Konfigurationsänderungen vornehmen! Bitte deine Benutzer auf jeden Fall, zu helfen, auf Wiki-Spam zu achten (und tu dies selbst). Es hilft, die Messlatte etwas höher zu legen. Du solltest jedoch auch beachten, dass keine dieser Lösungen als vollständig Spam-sicher angesehen werden kann. Das regelmäßige Überprüfen von "Letzte Änderungen" (Special:RecentChanges) ist eine effektive Maßnahme.

Schnellste Lösungen zum Ausprobieren

Spam zu bekämpfen sollte nicht zu schwer sein. Wenn du Spam schnell und drastisch reduzieren willst, solltest du zuerst diese paar Schritte ausprobieren.

Wenn du immer noch Probleme hast, lies den Rest dieser Seite für weitere Lösungen und schreibe eine Nachricht auf mediawiki-l für Hilfe.

Grundlagen der Antispam-Einrichtung

CAPTCHA

Eine der gängigsten Methoden, um automatisierte Beiträge auszusortieren, ist die Verwendung eines CAPTCHA, ein System, das versucht, Menschen von automatisierten Systemen zu unterscheiden, indem es den Benutzer auffordert, eine Aufgabe zu lösen, die für Maschinen schwierig ist. Die ConfirmEdit -Erweiterung für MediaWiki bietet ein erweiterbares CAPTCHA-Framework, das bei einer Reihe von Veranstaltungen ausgelöst werden kann, darunter

  • alle Bearbeitungen
  • Bearbeitungen, die neue, unerkannte externe Links hinzufügen
  • Benutzerregistrierung

Die Erweiterung wird mit einem Standardtest ausgeliefert, dieser ist jedoch eine Referenzimplementierung und nicht für die Verwendung in der Produktion gedacht. Wiki-Betreibern, die ConfirmEdit in einem öffentlichen Wiki installieren, wird empfohlen, eines der in der Erweiterung enthaltenen CAPTCHA-Module zu verwenden (insgesamt existieren fünf).

Die stabilsten CAPTCHAs, die heutzutage existieren, sind deine benutzerdefinierten QuestyCaptcha-Fragen, wenn du sie genau auf die Zielgruppe deines Wikis abstimmst und sie regelmäßig aktualisierst. ReCaptcha wird mittlerweile von den meisten Spammern überlistet[1]; das Asirra CAPTCHA, das den Benutzer auffordert, zwischen Katzen und Hunden zu unterscheiden, ist für die Benutzer besonders unangenehm, kann aber effektiv sein.

Es ist wichtig zu wissen, dass CAPTCHAs nicht nur unerwünschte Bots sperren können: Wenn ein Skript nicht in der Lage ist, ein CAPTCHA zu passieren, dann auch ein Bildschirmlesegerät oder eine andere Software oder Hilfe, die von Blinden oder Sehbehinderten verwendet wird. Eine der Optionen in CAPTCHA, das „reCAPTCHA“-Widget, enthält ein alternatives Audio-CAPTCHA für solche Fälle - einige Computernutzer/innen fallen jedoch bei Hörtests und Lesetests durch, daher ist dies keine vollständige Lösung. Du solltest die Auswirkungen einer solchen Barriere bedenken und den betroffenen Nutzerinnen und Nutzern möglicherweise eine Alternative bieten, um Konten zu erstellen und Beiträge zu leisten, was in einigen Ländern gesetzlich vorgeschrieben ist.[2]

Auch wird dein Wiki dadurch nicht vollständig vor Spam geschützt; Spammer zahlen etwa 0,80 bis 1,20 für jedes 1.000 gelöste CAPTCHA an Unternehmen, die menschliche Löser in Bangladesch, China, Indien und vielen anderen Entwicklungsländern beschäftigen.[3] Aus diesem Grund sollte sie mit anderen Mechanismen kombiniert werden.

rel="nofollow"

In der Standardkonfiguration fügt MediaWiki externe Links in Wiki-Seiten rel="nofollow" hinzu, um darauf hinzuweisen, dass diese von Nutzern erstellt wurden, Spam enthalten könnten und daher nicht zur Beeinflussung von Seitenranking-Algorithmen verwendet werden sollten. Beliebte Suchmaschinen wie Google honorieren dieses Attribut.

Du kannst dieses Verhalten mit der Variable $wgNoFollowLinks für die gesamte Website oder mit der Variable $wgNoFollowNsExceptions für jeden Namensraum abschalten.

Die Verwendung des Attribut rel="nofollow"s allein wird Spammer nicht davon abhalten, einer Seite Marketing "hinzuzufügen", es wird jedoch zumindest verhindern, dass sie durch einen höheren Page Rank davon profitieren. Dennoch sollte man sich nie auf sie als primäre Methode zur Spam-Kontrolle verlassen, da ihre Wirksamkeit von Natur aus begrenzt ist. Es tut nicht gut, Spam von deiner Website fernzuhalten.

Siehe NoIndexHistory. Beachte, dass die Kennzeichnung aller externen Links eine ziemlich harte Anti-Spam-Taktik ist, die du vielleicht nicht verwenden möchtest (schalte die Option rel=nofollow aus). Siehe Nofollow für eine Diskussion darüber. Es ist jedoch gut, dass du diese Einstellung als Standardinstallation hast. Das bedeutet, dass bequeme Administratoren, die nicht an Spam-Probleme denken, dazu neigen, diese Option zu aktivieren. Für weitere Informationen siehe Handbuch:Nofollow .

Antispam-Routine: maßgeschneiderte Maßnahmen

Jeder Spammer ist anders, auch wenn sie alle langweilig ähnlich aussehen. Wenn die allgemeinen Gegenmaßnahmen nicht ausreichen, solltest du, bevor du zu extremen Maßnahmen greifst, die Instrumente nutzen, die es dir ermöglichen, die spezifischen Probleme zu bewältigen.

Schutz einzelner Seiten

Often, the same page will be hit repeatedly by spambots. Common patterns observed in spambot-created pagenames include talk page, often outside main space (e.g. Category_talk: are little-used, so make common targets), and other discussion pages

As most abusive edits on wikis which don't require registration to edit are from anonymous sources, blocking edits to these specific pages by anyone other than established users can prevent re-creation of deleted spamdump pages. Typically, any page which is already a regular visitor to special:log/delete on an individual wiki is a good candidate for page protection.

  • Semi-protection of individual pages.
    • In addition, this can be combined with changing the minimum requirements for MediaWiki to identify users as 'autoconfirmed'.
  • Man kann einen Kaskadenschutz auf eine oder mehrere Seiten anwenden, die Links zu den am häufigsten gespammten Seiten haben. Mit diesem Trick kannst du auch eine praktische Liste für Administratoren einrichten.

Missbrauchsfilter

Erweiterung:Missbrauchsfilter ermöglicht es privilegierten Nutzern, Regeln zu erstellen, die auf die spezifische Art von Spam abzielen, die dein Wiki empfängt, und automatisch die Aktion zu verhindern und/oder den Nutzer zu blockieren.

Es kann viele Eigenschaften der Bearbeitung untersuchen, z.B. den Benutzernamen, das Alter des Nutzers, den hinzugefügten Text, die hinzugefügten Links und so weiter. Am effektivsten ist es, wenn du einen oder mehrere erfahrene Administratoren hast, die dir bei der Bekämpfung von Spam helfen wollen. Der Missbrauchsfilter kann sogar gegen von Menschen gesteuerte Spammer wirksam sein, muss aber ständig gewartet werden, um auf neue Arten von Angriffen zu reagieren.

Beispiele für die Bekämpfung von automatischem Spam findest du auf Handbuch:Spam bekämpfen/AbuseFilter-Beispiele .

SpamBlacklist

Der obige Ansatz wird zu mühsam, wenn du versuchst, mehr als eine Handvoll spammiger URLs zu blockieren. Ein besserer Ansatz ist eine lange schwarze Liste, die viele bekannte Spam-URLs enthält.

Eine beliebte Erweiterung für MediaWiki ist die SpamBlacklist -Erweiterung, die Bearbeitungen blockiert, die den Seiten URLs auf der schwarzen Liste hinzufügen: Sie ermöglicht es, eine solche Liste im Wiki mithilfe von privilegierten Benutzern zu erstellen, und erlaubt die Verwendung von Listen, die aus externen Quellen stammen (standardmäßig wird die umfangreiche m:Spam blacklist verwendet).

Die TitleBlacklist Erweiterung kann auch nützlich sein, um zu verhindern, dass bestimmte Seitengruppen neu erstellt werden, die von den Bots zum Abladen von Linkspam verwendet werden.

Offene Proxies

Offene Proxys sind vor allem deshalb eine Gefahr, weil sie als Mittel zur Umgehung von Gegenmaßnahmen eingesetzt werden, die auf bestimmte Missbraucher abzielen; siehe auch Keine offenen Proxys.

Es gibt einige Bots, z. B. auf Wikimedia-Wikis, die offene Proxy-IPs erkennen und blockieren, aber ihr Code ist oft nicht öffentlich. Die meisten dieser Sperren werden manuell durchgeführt, wenn der Missbrauch bemerkt wird. Daher ist es wichtig zu wissen, ob es sich bei einer missbräuchlichen IP um einen offenen Proxy oder etwas anderes handelt, um zu entscheiden, wie damit umzugehen ist; erst recht, wenn es sich um eine IP handelt, die von einem registrierten Nutzer verwendet wird und mit der Erweiterung CheckUser abgerufen wird.

Mehrere Erweiterungen, insbesondere die Erweiterung Tor block , blockieren eine Reihe von offenen Proxys.

Seit 1.22 ist $wgApplyIpBlocksToXff verfügbar, um Sperren effektiver zu erstellen.

Hardcore-Maßnahmen

Die folgenden Maßnahmen sind für technisch versierte Sysadmins gedacht, die wissen, was sie tun: Sie sind schwieriger festzulegen und zu überwachen; wenn sie schlecht umgesetzt werden, können sie zu alt sein, um noch effektiv zu sein, oder sogar kontraproduktiv für dein Wiki.

$wgSpamRegex

MediaWiki bietet die Möglichkeit, den Text von Bearbeitungen zu filtern, um unerwünschte Hinzufügungen zu sperren, und zwar über die Variable $wgSpamRegex . Damit kannst du zusätzliche Textausschnitte oder Markups sperren, die mit gängigen Spam-Angriffen in Verbindung stehen.

In der Regel wird sie verwendet, um URLs (oder Teile von URLs) auszuschließen, die du nicht verlinken möchtest. Users are presented with an explanatory message, indicating which part of their edit text is not allowed. Erweiterung:SpamRegex allows editing of this variable on-wiki. 

$wgSpamRegex = "/online-casino|buy-viagra|adipex|phentermine|adult-website\.com|display:none|overflow:\s*auto;\s*height:\s*[0-4]px;/i";

This prevents any mention of 'online-casino' or 'buy-viagra' or 'adipex' or 'phentermine'. The '/i' at the end makes the search case insensitive. It will also block edits which attempt to add hidden or overflowing elements, which is a common "trick" used in a lot of mass-edit attacks to attempt to hide the spam from viewers.

Apache configuration changes

In addition to changing your MediaWiki configuration, if you are running MediaWiki on Apache, you can make changes to your Apache web server configuration to help stop spam. These settings are generally either placed in your virtual host configuration file, or in a file called .htaccess in the same location as LocalSettings.php (note that if you have a shared web host, they must enable AllowOverride to allow you to use an .htaccess file).

Filtering by user agent

When you block a spammer on your wiki, search your site's access log by IP to determine which user agent string that IP supplied. For example:

grep ^195.230.18.188 /var/log/apache2/access.log

The access log location for your virtual host is generally set using the CustomLog directive. Once you find the accesses, you'll see some lines like this:

195.230.18.188 - - [16/Apr/2012:16:50:44 +0000] "POST /index.php?title=FlemmingCoakley601&action=submit HTTP/1.1" 200 24093 "-" ""

The user agent is the last quoted string on the line, in this case an empty string. Some spammers will use user agent strings used by real browsers, while others will use malformed or blank user agent strings. If they are in the latter category, you can block them by adding this to your .htaccess file (adapted from this page): 

SetEnvIf User-Agent ^regular expression matching user agent string goes here$ spammer=yes

Order allow,deny
allow from all           
deny from env=spammer

This will return a 403 Forbidden error to any IP connecting with a user agent matching the specified regular expression. Take care to escape all necessary regexp characters in the user agent string such as . ( ) - with backslashes (\). To match blank user agents, just use "^$".

Even if the spammer's user agent string is used by real browsers, if it is old or rarely encountered, you can use rewrite rules to redirect users to an error page, advising them to upgrade their browser: 

RewriteCond %{HTTP_USER_AGENT} "Mozilla/5\.0 \(Windows; U; Windows NT 5\.1; en\-US; rv:1\.9\.0\.14\) Gecko/2009082707 Firefox/3\.0\.14 \(\.NET CLR 3\.5\.30729\)"
RewriteCond %{REQUEST_URI} !^/forbidden/pleaseupgrade.html
RewriteRule ^(.*)$ /forbidden/pleaseupgrade.html [L]

Preventing blocked spammers from consuming resources

A persistent spammer or one with a broken script may continue to try to spam your wiki after they have been blocked, needlessly consuming resources.

By adding a deny from pragma such as the following to your .htaccess file, you can prevent them from loading pages at all, returning a 403 Forbidden error instead: 

Order allow,deny
allow from all
deny from 195.230.18.188

IP address blacklists

Ein Großteil des problematischen Spams, der auf MediaWiki Websites eingeht, stammt von Adressen, die anderen Webmastern schon lange als Bot- oder offene Proxy-Sites bekannt sind, obwohl dafür nur anekdotische Beweise existieren. Diese Bots generieren in der Regel eine große Anzahl automatischer Registrierungen auf Websites, Kommentarspam in Blogs und Seitenvandalismus in Wikis: meistens Linkspam, doch manchmal werden auch bestehende Inhalte gelöscht, mit zufälligen Kauderwelsch-Zeichen versehen oder so bearbeitet, dass der bestehende Unicode-Text zerstört wird.

Ein relativ einfaches CAPTCHA kann das Problem deutlich reduzieren, ebenso wie das Blockieren der Erstellung von bestimmten, oft gespammten Seiten. Diese Maßnahmen beseitigen das Problem jedoch nicht, und irgendwann wird die Verschärfung der Sicherheitsmaßnahmen für alle Nutzerinnen und Nutzer die legitimen Beitragszahlerinnen und Beitragszahler belästigen.

It may be preferable, instead of relying solely on CAPTCHA or other precautions which affect all users, to target specifically those IPs already known by other site masters to be havens of net.abuse. Many lists are already available, for instance stopforumspam.com has a list of "All IPs in CSV" which (as of feb. 2012) contains about 200.000 IPs of known spambots.

CPU-Nutzung und Überlastung

Beachte, dass Bots dein Wiki leicht überlasten können, wenn viele Prüfungen bei versuchten Änderungen oder Seitenaufrufen durchgeführt werden, und es dadurch stärker gestört wird, als wenn es ungeschützt wäre. Behalte die Ressourcenkosten für deine Schutzmaßnahmen im Auge.

DNSBL

Du kannst MediaWiki so einstellen, dass jede IP-Adresse, die du bearbeitest, mit einer oder mehreren DNSBLs (DNS-basierte Blacklists) abgeglichen wird, was keine Wartung erfordert, aber die Bearbeitungszeit leicht erhöht. For example, you can add this line to your LocalSettings.php to block many open proxies and known forum spammers: 

$wgEnableDnsBlacklist = true;
$wgDnsBlacklistUrls = array( 'xbl.spamhaus.org', 'dnsbl.tornevall.org' );

For details of these DNSBLs, see Spamhaus: XBL and dnsbl.tornevall.org. Für eine Liste von DNSBLs siehe Vergleich von DNS-Blacklists. Siehe auch Handbuch:$wgEnableDnsBlacklist , Handbuch:$wgDnsBlacklistUrls .

$wgProxyList

Warnung Warnung: Diese spezielle Technik erhöht die Ladezeit der Seite und die Serverlast erheblich, wenn die IP-Liste groß ist. Verwende sie mit Bedacht.

Du kannst die Variable $wgProxyList auf eine Liste von zu sperrenden IPs setzen. Diese kann regelmäßig von einer externen Quelle mit einem Cron-Skript wie dem folgenden aufgefüllt werden: 

#!/bin/bash
cd /your/web/root
wget https://www.stopforumspam.com/downloads/listed_ip_30_ipv46.gz
gzip -d listed_ip_30_ipv46.gz
cat > bannedips.php << 'EOF'
<?php
$wgProxyList = array(
EOF
sed -e 's/^/  "/; s/$/",/' < listed_ip_30_ipv46 >> bannedips.php
printf '%s\n' '");' >> bannedips.php
rm -f listed_ip_30_ipv46

Dann stellst du in deinem LocalSettings.php ein:: 

require_once "$IP/bannedips.php";

Vielleicht möchtest du diese Befehle in einer Datei namens z.B. updateBannedIPs.sh speichern, damit du sie regelmäßig ausführen kannst.

You can also use a PHP-only solution to download the ip-list from stopforumspam. Schau dir dazu das PHP-Skript hier an.

If you do this and you use APC cache for caching, you may need to increase apc.shm_size in your php.ini to accommodate such a large list.

Du hast soeben einhundertvierzigtausend Spammer verbannt, hoffentlich ohne störende Auswirkungen auf deine legitimen Nutzer, und den schlimmsten bekannten Spammern im Internet "Adieu" gesagt. Gut, dass wir ihn los sind! Das sollte die Dinge ein bisschen ruhiger angehen, zumindest für eine Weile...

Honeypots, DNS BLs and HTTP BLs

140.000 dead spammers. Not bad, but any proper BOFH at this point would be bored and eagerly looking for the 140,001st spam IP to randomly block. And why not?

Fortunately, dynamically-updated lists of spambots, open proxies and other problem IPs are widely available. Many also allow usernames or email addresses (for logged-in users) to be automatically checked against the same blacklists.

One form of blacklist which may be familiar to MediaWiki administrators is the DNS BL. Hosted on a domain name server, a DNS blacklist is a database of IP addresses. An address lookup determines if an IP attempting to register or edit is an already-known source of net abuse.

The $wgEnableDnsBlacklist and $wgDnsBlacklistUrls options in MediaWiki provide a primitive example of access to a DNS blacklist. Set the following settings in LocalSettings.php and IP addresses listed as HTTP spam are blocked: 

$wgEnableDnsBlacklist = true;
$wgDnsBlacklistUrls = array( 'xbl.spamhaus.org', 'opm.tornevall.org' );

The DNS blacklist operates as follows:

  • A wiki gets an edit or new-user registration request from some random IP address (for example, in the format '123.45.67.89')
  • The four IP address bytes are placed into reverse order, then followed by the name of the desired DNS blacklist server
  • The resulting address is requested from the domain name server (in this example, '89.67.45.123.zen.spamhaus.org.' and '89.67.45.123.dnsbl.tornevall.org.')
  • The server returns not found (NXDOMAIN) if the address is not on the blacklist. If it is on either blacklist, the edit is blocked.

The lookup in an externally-hosted blacklist typically adds no more than a few seconds to the time taken to save an edit. The use of the DNS blacklist only takes place during registration or page edits. This leaves the speed at which the system can service page read requests (the bulk of your traffic) unaffected.

While the original SORBS was primarily intended for dealing with open web proxies and email spam, there are other lists specific to web spam (forums, blog comments, wiki edits) which therefore may be more suitable:

  • .opm.tornevall.org. operates in a very similar manner to SORBS DNSBL, but targets open proxies and web-form spamming.

Much of its content is consolidated from other existing lists of abusive IPs.

  • .dnsbl.httpbl.org. specifically targets bots which harvest email addresses from web pages for bulk mail lists, leave comment spam or attempt to steal passwords using dictionary attacks.

It requires the user register with projecthoneypot.org for a 12-character API key. If this key (for example) were 'myapitestkey', a lookup which would otherwise look like '89.67.45.123.http.dnsbl.sorbs.net.' or '89.67.45.123.opm.tornevall.org.' would need to be 'myapitestkey.89.67.45.123.dnsbl.httpbl.org.'

  • Web-based blacklists can identify spammer's email addresses and user information beyond a simple IP address, but there is no standard format for the reply from an HTTP blacklist server.

For instance, a request for http://botscout.com/test/?ip=123.45.67.89 would return "Y|IP|4" if the address is blacklisted ('N' or blank if OK), while a web request for http://www.stopforumspam.com/api?ip=123.45.67.89 would return "ip yes 2009-04-16 23:11:19 41" if the address is blacklisted (the time, date and count can be ignored) or blank if the address is good.

With no one standard format by which a blacklist server responds to an enquiry, no built-in support for most on-line lists of known spambots exists in the stock MediaWiki package. Since rev:58061, MediaWiki has been able to check multiple DNSBLs by defining $wgDnsBlacklistUrls as an array.

Die meisten Betreiber von schwarzen Listen bieten nur sehr begrenzten Software-Support (oft für Nicht-Wiki-Anwendungen wie phpBB oder Wordpress). Da dieselben Spambots ähnliche Probleme auf den meisten Open-Content-Websites verursachen, werden die schlimmsten Angreifer, die MediaWiki-Sites angreifen, auch Tausende von Nicht-Wiki-Sites mit Spam in Blog-Kommentaren, Forenbeiträgen und Gästebucheinträgen angreifen.

Die automatische Abfrage mehrerer Blacklist-Seiten ist daher bereits weit verbreitet, um verschiedene andere Formen von Open-Content-Seiten zu schützen, und die Namen, Ränge und IP-Adressen der Spambots sind inzwischen nur allzu gut bekannt. Eine relativ kleine Anzahl von Spambots scheint für einen großen Teil des Gesamtproblems verantwortlich zu sein. Selbst dort, wo Admins keine Gefangenen machen, wurde ein Muster festgestellt, bei dem dieselbe Spambot-IP, die vor einer Sekunde Linkspam im Wiki gepostet hat, jetzt woanders Blog-Kommentare spammt und in ein paar Sekunden Forenbeiträge auf einer Seite auf der anderen Seite der Welt spammen wird. Ein gemeinsamer Eintrag auf einer externen Blacklist kann einen problematischen Bot davon abhalten, auf Tausenden von Websites zu posten.

Dadurch wird die Anzahl der einzelnen IPs, die von den lokalen Administratoren manuell gesperrt werden müssen, stark reduziert - ein Wiki und ein Forum nach dem anderen.

Aber was hat es mit den Honeypots auf sich?

Some anti-spam sites, such as projecthoneypot.org, provide code which you are invited to include in your own website pages.

Typischerweise enthalten die Seiten eine oder mehrere einzigartige, zufällige und versteckte E-Mail-Adressen oder Links, die nicht für deine menschlichen Besucher, sondern für Spambots bestimmt sind. Jedes Mal, wenn die Seite aufgerufen wird, werden die eingebetteten Adressen automatisch geändert. So können einzelne Spam-Mails direkt und eindeutig den IP-Adressen der Bots zugeordnet werden, die die Adressen von deinen Websites gesammelt haben. Die IP-Adresse, die der Bot verwendet hat, um deine Website aufzurufen, wird automatisch an die Betreiber des Blacklist-Dienstes übermittelt. Oft ist auch ein Link zu einem gefälschten "Kommentar" oder "Gästebuch" als Falle für Bots versteckt, die Spam in Webformularen posten. See Honeypot (computing).

Sobald die Adresse des Spammers bekannt ist, wird sie zu den Blacklists (siehe oben) hinzugefügt, damit du und andere in Zukunft einen unerwünschten Roboterbesucher weniger auf euren Seiten haben.

Während Honeypot-Skripte und Blacklist-Server einen Großteil der Identifizierung und Bekämpfung von Spambot-IPs automatisieren können, bieten die meisten Blacklist-Seiten Links zu Webseiten, auf denen man manuell nach Informationen über eine IP-Adresse suchen oder eine missbräuchliche IP als Spambot melden kann. It may be advisable to include some of these links on the special:blockip pages of your wiki for the convenience of your site's administrators.

More lists of proxy and spambot IPs

Wenn du die Adresse eines Bots oder offenen Proxys in eine Suchmaschine eingibst, erhältst du in der Regel viele Listen, auf denen diese missbräuchlichen IPs bereits gemeldet wurden.

In einigen Fällen sind die Listen Teil von Anti-Spam-Seiten, in anderen Fällen listet eine Seite, die die Verwendung offener Proxys befürwortet, nicht nur den Proxy auf, der zum Spammen deiner Wiki-Installation missbraucht wurde, sondern auch Hunderte anderer Proxys, die ebenfalls für den Missbrauch offen sind. It is also possible to block wiki registrations from anonymised sources such as Tor proxies (Tor Project - torproject.org), from bugmenot fake account users or from email addresses (listed by undisposable.net) intended solely for one-time use.

See also Blacklists Compared - 1 March 2008 and spamfaq.net for lists of blacklists. Bedenke, dass Listen, die für die Bekämpfung von Spam-E-Mails gedacht sind, viele Fehlalarme erzeugen, wenn sie zum Blockieren von Kommentarspam in Wikis oder anderen Webformularen eingesetzt werden. Die automatisierte Verwendung einer Liste, die alle bekannten dynamischen IP-Adressblöcke von Nutzern auf eine schwarze Liste setzt, könnte dein Wiki zum Beispiel fast unbrauchbar machen.

Um von der Seite Special:Blockip deines Wikis auf IP-Blacklist-Seiten zu verlinken (als Bequemlichkeit für Administratoren, die manuell prüfen wollen, ob eine Problemadresse ein bereits bekannter Bot ist):

  1. Füge eine Zeile zu LocalSettings.php hinzu, um sie einzustellen: $wgNamespacesWithSubpages [NS_SPECIAL] = true;
  2. Füge den folgenden Text in MediaWiki:Blockiptext ein, um ihn anzuzeigen:
"Check this IP at [http://whois.domaintools.com/{{SUBPAGENAME}} Domain Tools], [http://openrbl.org/?i={{SUBPAGENAME}} OpenRBL], [http://www.projecthoneypot.org/ip_{{SUBPAGENAME}} Project Honeypot], [http://www.spamcop.net/w3m?action=checkblock&ip={{SUBPAGENAME}} Spam Cop], [http://www.spamhaus.org/query/bl?ip={{SUBPAGENAME}} Spamhaus], [http://www.stopforumspam.com/ipcheck/{{SUBPAGENAME}} Stop Forum Spam]."

This will add an invitation to "check this IP at: Domain Tools, OpenRBL, Project Honeypot, Spam Cop, Spamhaus, Stop Forum Spam" to the page from which admins ask to block an IP. An IP address is sufficient information to make comments on Project Honeypot against spambots, Stop Forum Spam is less suited to reporting anon-IP problems as it requires username, IP and email under which a problem bot is attempting to register on your sites. The policies and capabilities of other blacklist-related websites may vary.

Note that blocking the address of the spambot posting to your site is not the same as blocking the URLs of specific external links being spammed in the edited text. Tu beides. Both approaches used in combination, as a means to supplement (but not replace) other anti-spam tools such as title or username blacklists and tests which attempt to determine whether an edit is made by a human or a robot (captchas or akismet) can be a very effective means to separate spambots from real, live human visitors.

If spam has won the battle

Du kannst den Krieg immer noch gewinnen! MediaWiki bietet dir die Werkzeuge dafür; konsolidiere einfach deine Positionen, bis du wieder angreifen kannst. See Handbuch:Vandalismus bekämpfen and in particular Cleaning up, Restrict editing.

See External links for other tools without MediaWiki support.

Weitere Ideen

This page lists features which are currently included, or available as patches, but on the discussion page you will find many other ideas for anti-spam features which could be added to MediaWiki, or which are under development.

Siehe auch

Erweiterungen

  • AbuseFilter — allows edit prevention and blocking based on a variety of criteria
  • A slimmed down ConfirmAccount can be used to moderate new user registrations, (doesn't require captchas).
  • CheckUser — allows, among other things, the checking of the underlying IP addresses of account spammers to block them. Ermöglicht die Massenblockierung von Spammern aus ähnlichen Orten.
  • HoneyPot
  • SpamRegex — allows basic blocking of edits containing spam domains with a single regex
  • StopForumSpam — allows for checking edits against the StopForumSpam service and allows for submitting data back to it when blocking users.
  • Category:Spam management extensions — category exhaustively listing spam management extensions
  • Content approval extensions — a set of extensions that prevent edits from being seen until they are approved by a moderator.

Nützlich nur für einige Wiki-Farmen:

Kommerzielle Dienste:

==== Im Installationsprogramm gebündelt.

Der Standard-Tarball, der zum Download verfügbar ist, enthält jetzt die meisten der wichtigsten Anti-Spam-Erweiterungen, darunter auch die folgenden:

  • ConfirmEdit — adds various types of CAPTCHAs to your wiki
  • Nuke — removes all contributions by a user or IP
  • SpamBlacklist — prevents edits containing spam domains, list is editable on-wiki by privileged users


Einstellungen


Einzelnachweise

  1. ↑ Beispiel: „Automatisch Captchas lösen: GSA Captcha Breaker + Mega Ocr (Solves Recaptcha!)“ sagt Benutzer Senukexcr.
  2. ↑ Zum Beispiel: Abschnitt 508 Standards für Elektronik und Informationstechnologie
  3. ↑ The New York Times 25 April 2010 Spammer bezahlen andere, um Sicherheitstests zu beantworten von Vikas Bajaj
Retrieved from "https://www.mediawiki.org/w/index.php?title=Manual:Combating_spam/de&oldid=6898592"