Jump to content

Manuel:Combattre le spam

From mediawiki.org
This page is a translated version of the page Manual:Combating spam and the translation is 100% complete.
Outdated translations are marked like this.

Comme tous les sites Web dynamiques actuels, les wikis constituent une cible courante pour les spammeurs souhaitant promouvoir des produits ou des sites Web. MediaWiki propose un certain nombre de fonctionnalités conçues pour lutter contre le vandalisme en général. Sur cette page nous traitons particulièrement du vandalisme dans les wikis, qui est souvent automatisé.

Résumé

Les outils couramment utilisés pour lutter contre le spam de wikis appartiennent généralement aux catégories suivantes :

  • Nécessité d'une connexion et/ou d'un CAPTCHA pour certaines opérations, telles que des modifications, l'ajout de liens externes ou la création d'un nouvel utilisateur.
  • Blocage des modifications des adresses IP connues figurant sur la liste noire ou des adresses IP exécutant des serveurs mandataires (proxys) ouverts
  • Blocage des modifications pour ajouter des mots-clés ou des liens externes spécifiques non désirés
  • Blocage de modèles de nom d'utilisateur et de titre de page spécifiques couramment utilisés par les robots spammeurs
  • Blocage des modifications apportées par les nouveaux utilisateurs ou les anonymes à des pages spécifiques souvent ciblées
  • Mise en liste blanche des contributeurs reconnus pour leur bonne foi (tels que les administrateurs ou les contributeurs réguliers) et restrictions imposées aux contributeurs nouveaux ou anonymes.
  • Nettoyer les scripts ou les suppressions en masse (Extension:Nuke ) des billets existants réalisés par les robots spammeurs récents.

Normalement on utilise une combinaison des différentes méthodes pour maintenir le spam et les modifications faites par robot et proxy ouverts, à un niveau minimal, afin de limiter le nombre de détections signalées sur des utilisateurs tout à fait légitimes du site.

Notez que beaucoup de ces fonctionnalités ne sont pas activées par défaut. Si vous faites l'installation de MediaWiki sur votre serveur ou votre hôte, alors c'est vous seul qui pouvez faire les modifications nécessaires de la configuration. Par tous les moyens, demandez à vos utilisateurs de vous aider en surveillant le spam du wiki (faites-le aussi vous-même); les spams actuels peuvent atteindre facilement même les plus petites communautés. Cela permet de monter un peu la barre. Notez-bien qu'aucune de ces solutions ne vous garantit d'être débarassé du spam à 100%. Il est utile de vérifier régulièrement Modifications récentes (Special:RecentChanges).

Solutions de test rapide à essayer d'abord

Combattre le vandalisme ne devrait pas être difficile. Si vous souhaitez réduire le vandalisme rapidement et de manière drastique, essayez d'abord ces quelques étapes.

Si vous rencontrez encore des difficultés, lisez le reste de cette page pour envisager d'autres solutions et postez un message sur mediawiki-l pour obtenir de l'aide.

Bases de la configuration antispam

Les CAPTCHAs

L'une des méthodes les plus communes pour refuser les soumissions automatiques est d'utiliser un CAPTCHA, c'est à dire un système qui essaie de faire la différence entre les humains et les automates, en demandant à l'utilisateur de résoudre une tâche difficile pour les machines. L'extension ConfirmEdit pour MediaWiki fournit un environnement CAPTCHA extensible pouvant être dirigé par un certain nombre d'événements dont :

  • toutes les modifications
  • les modifications qui ajoutent de nouveaux liens non reconnus
  • l'inscription des utilisateurs

L'extension est livrée avec un test par défaut; c'est une préférence d'implémentation mais qui n'est pas prévue pour être en production. Nous conseillons aux opérateurs qui installent ConfirmEdit sur un wiki public d'utiliser un des modules CAPTCHA contenu dans l'extension (il y en a cinq au total).

Les CAPTCHAs les plus robustes actuellement disponibles sont vos questions personnalisées QuestyCaptcha, si vous les adaptez rigoureusement à l'audience de votre wiki et les mettez à jour régulièrement. Aujourd'hui, ReCaptcha est déjoué par la plupart des spammeurs [1]; le CAPTCHA Asirra qui demande à l'utilisateur de distinguer des chats et des chiens est particulièrement odieux aux utilisateurs mais peut être efficace.

Il est important de noter que les CAPTCHAs peuvent bloquer bien plus que des robots indésirables : quand un script ne peut pas résoudre un CAPTCHA, comme dans le cas d'un lecteur d'écran, ou autre logiciel ou aide utilisée par les personnes aveugles ou aux facultés visuelles ammoindries. Une des options des CAPTCHA, le widget reCAPTCHA, comprend une alternative audio du CAPTCHA couvrant ces cas - mais certains utilisateurs d'ordinateur échouent aux tests d'audition et aux tests de lecture, donc ceci n'est pas non plus une solution complète. Vous devez prendre en compte les implications d'une telle barrière, et fournir éventuellement des moyens alternatifs aux utilisateurs concernés qui créent des comptes et contribuent, ce qui est une demande légale dans cetaines jurisdictions.[2]

Cela ne rendra pas pour autant votre wiki exempt de tout spam; selon Wikipedia « Les spammeurs paient environ 0,80$ à 1,20$ pour 1 000 CAPTCHAs résolus aux compagnies employant des résolveurs humains au Bangladesh, Chine, Inde, et beaucoup d'autres nations en développement. »[3] Pour cette raison elle doit être combinée avec d'autres mécanismes.

rel="nofollow"

Dans la configuration par défaut, MediaWiki ajoute rel="nofollow" aux liens externes des pages wiki, pour indiquer qu'ils sont fournis par l'utilisateur, qu'ils peuvent contenir du spam, et que par conséquent ils ne doivent pas être utilisés pour influencer les algorithmes de classement des pages. Les moteurs de recherche populaires tels que Google satisfont à cet attribut.

Vous pouvez désactiver ce comportement sur l'ensemble du site en utilisant $wgNoFollowLinks , ou sur tout un espace de noms donné en utilisant la variable de configuration $wgNoFollowNsExceptions .

L'utilisation de l'attribut rel="nofollow" seul ne va pas empêcher les spammeurs d'essayer d'ajouter de la publicité à une page, mais il les empêchera au moins de bénéficier d'un rang de page augmenté ; nous savons avec certitude que certains le vérifient. Néanmoins, il ne faut jamais s'y fier en tant que méthode principale de contrôle du spam car son efficacité est intrinsèquement limitée. Elle n'empêche pas que votre site soit vandalisé.

Voir NoIndexHistory. Notez que si vous l'appliquez sur les liens externes, c'est plutôt une tactique assez lourde de gestion des spams que vous pouvez décider de ne pas utiliser (désactivez l'option rel=nofollow). Voir Nofollow pour un débat sur la question. Il est bon néanmoins de l'avoir par défaut à l'installation. Cela signifie que les administrateurs paresseux qui ne se préoccupent pas des problèmes de spam, auront tendance à laisser cette option activée. Pour plus d'informations, voir les Manuel:Nofollow .

Routines antispam : les mesures adaptées

Chaque spammeur est différent bien qu'ils soient tous semblables de façon ennuyeuse. Si les contre-mesures générales ne sont pas suffisantes et avant de passer aux étapes extrêmes, utilisez les outils permetant de traiter les problèmes spécifiques qui se présentent.

Protection individuelle des pages

Souvent c'est la même page qui est attaquée de manière répétée par les robots spammeurs. Des motifs communs observés dans les noms des pages créées par les robots spammeurs comprennent les pages de discussion, souvent externes à l'espace main: (par exemple 'Category_talk:' est peu utilisé, et donc fait des cibles communes), et les autres pages de discussion

Comme la plupart des modifications abusives sur les wikis qui ne nécessitent pas d'enregistrement pour modifier, sont faites par des sources anonymes, le blocage des modifications de ces pages spécifiques par tout utilisateur autre que les utilisateurs établis, peut empêcher la recréation des pages spammées qui ont été supprimées. Typiquement toute page qui est déjà un visiteur régulier de special:log/delete sur un wiki individuel, est un bon candidat pour la protection de page.

  • Semi-protection des pages individuelles.
    • En plus ceci peut être combiné avec une modification des contraintes minimales pour que MediaWiki identifie les utilisateurs comme étant 'autoconfirmés'.
  • Vous pouvez appliquer la protection en cascade à l'une ou plusieurs pages possèdant des liens vers les pages le plus souvent vandalisées. Vous pouvez également utiliser cette astuce pour construire une liste pratique utilisable par les administrateurs.

Filtre anti-abus

Extension:AbuseFilter permet aux utilisateurs privilégiés de créer les règles pour cibler le type spécifique de spam reçu par votre wiki, et empêcher automatiquement l'action et / ou le blocage de l'utilisateur.

Il peut examiner plusieurs propriétés de la modification, telle que le nom d'utilisateur, son age, le texte ou les liens ajoutés, etc. Il est le plus efficace lorsque vous avez un ou plusieurs administrateurs expérimentés qui souhaitent vous aider à combattre le spam. Le filtre anti-abus peut être efficace même pour des spammeurs assistés par des humains, mais cela demande une maintenance continue pour répondre aux nouveaux types d'attaques.

Manuel:Combating spam/exemples AbuseFilter donne des exemples sur la manière de combattre le vandalisme automatisé.

Liste noire des spammeurs

L'approche ci-dessus deviendra trop lourde si vous essayez de bloquer plus d'une poignée d'URL de spam. Une meilleure approche est d'utiliser une longue liste noire contenant les URLs connues pour générer du spam.

Une extension populaire pour MediaWiki est l'extension SpamBlacklist qui bloque les modifications qui ajoutent aux pages des URLs se trouvant en liste noire : elle permet de construire une telle liste sur le wiki avec l'assistance des utilisateurs privilégiés, et permet l'utilisation des listes récupérées à partir des sources externes (par défaut, elle utilise la liste noire extensive).

L'extension TitleBlacklist peut être également utile comme moyen pour empêcher la recréation de groupes spécifiques de pages utilisés par les robots pour fournir les liens spammeurs.

Serveurs mandataires ouverts

Les proxy ouverts sont un danger particulièrement parce qu'ils sont utilisés comme mannière de contourner les contre-mesures ciblant des abuseurs spécifiques; voir aussi No open proxies.

Il existe certains robots tels ceux des wikis Wikimedia qui détectent et bloquent les adresses IP des proxy ouverts mais leur code est souvent non public. La plupart de tels blocages sont réalisés manuellement lorsque l'abus est signalé. Il est alors important de pouvoir dire si une adresse IP qui abuse correspond à un proxy ouvert ou a autre chose, pour décider du traitement à appliquer ; de plus, si l'adresse IP est celle d'un utilisateur enregistré, elle est récupérée avec l'extension CheckUser .

Plusieurs extensions, particulièrement l'extension Tor block , bloquent un intervalle de proxy ouverts.

Depuis la 1.22, $wgApplyIpBlocksToXff est disponible pour rendre les blocages plus efficaces.

Mesures du noyau

Les mesures suivantes concernent les administrateurs système plus avisés qui savent ce qu'ils font : elles sont plus difficiles à configurer proprement et à gérer; si elles sont mal implémentées elles peuvent s'avérer trop anciennes pour être encore efficaces, ou même être contre-productives pour votre wiki.

$wgSpamRegex

MediaWiki fournit, via le paramètre de configuration $wgSpamRegex , un moyen pour filtrer le texte des modifications et bloquer les ajouts non souhaités. Vous pouvez utiliser ceci pour bloquer des parties de texte supplémentaires ou des balises associées fréquemment aux attaques de spam.

Typiquement ceci est utilisé pour exclure des URLs (ou des parties d'URL) que vous ne souhaitez pas rendre accessibles par les utilisateurs. Les utilisateurs reçoivent un message d'explication indiquant la partie refusée de leur modification. Extension:SpamRegex permet de modifier cette variable sur le wiki.

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

Ceci empêche toute mention de 'online-casino', 'buy-viagra', 'adipex' ou 'phentermine'. Le suffixe '/i' end la recherche insensible à la casse. Cela bloquera aussi les modifications qui essaient d'ajouter des éléments masqués ou en surnombre, ce qui est une pratique commune utilisée par beaucoup d'attaques en masse pour essayer de dissimuler les spammeurs des autres autilisateurs.

Modifications de la configuration Apache

En supplément de la modification des paramètres MediaWiki, si vous exécutez MediaWiki sous Apache, vous pouvez adapter également les paramètres de votre serveur web Apache pour vous aider à combattre le spam. Ces paramètres sont généralement soit placés dans votre fichier de configuration de votre hôte virtuel, ou dans un fichier appelé .htaccess au même emplacement que LocalSettings.php (notez que si vous avez un hôte web partagé, ils doivent activer AllowOverride pour vous permettre d'utiliser un fichier .htaccess).

Filtrage par agent utilisateur

Lorsque vous bloquez un spammeur sur votre wiki, regardez le journal des accès par adresse IP de votre site pour déterminer la chaîne de l'agent utilisateur soumise par cette adresse IP. Par exemple :

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

L'emplacement du journal des accès pour votre hôte virtuel est généralement déclaré en utilisant la directive CustomLog. Une fois les accès trouvés, vous verrez quelques lignes comme celles-ci :

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

L'agent utilisateur est la dernière chaîne de caractères entre guillemets de la ligne, dans ce cas une chaîne vide. Certains spammeurs vont utiliser la chaîne de l'agent utilisateur qui sert aux navitageurs réels, alors que d'autres utiliseront des chaînes mal formées ou vides. Pour cette dernière catégorie, vous pouvez les bloquer en ajoutant ceci dans votre fichier .htaccess (adapté de cette page) :

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

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

Ce qui renverra une erreur 403 Forbidden à toute adresse IP qui se connecte avec un agent utilisateur correspondant à l'expression régulière fournie. Veillez à bien échapper avec des anti-slash '\' tous les caractères nécessaires dans les expressions régulières de la chaîne de l'agent utilisateur, tels que . ( ) - Pour couvrir les agents utilisateurs mis à blanc, utilisez simplement use « ^$ ».

Même si la chaîne de l'agent utilisateur du spammeur est utilisée par les navigateurs réels, quand ils sont anciens ou rarement rencontrés vous pouvez utiliser les règles de réécriture pour rediriger les utilisateurs vers la page d'erreur, en les conseillant de mettre à jour leur navigateur :

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]

Empêcher des contrevenants bloqués d'utiliser des ressources

Un spammeur obstiné, ou avec un script en erreur, peut continuer à vandaliser votre wiki même après qu'il ait été bloqué et cela consomme des ressources inutilement. En ajoutant dans votre fichier .htaccess, un pragma 'deny from' tel que le suivant, vous pouvez les empêcher de charger systématiquement les pages et renvoyer une erreur '403 Forbidden' à la place :

Order allow,deny
allow from all
deny from 195.230.18.188

Listes noires d'adresses IP

La plupart des spams les plus problématiques reçus sur les sites MediaWiki proviennent d'adresses connues depuis longtemps des autres webmasters, comme correspondant à des robots ou des sites de proxy ouverts, bien que cela ne soit qu'une évidence anectotique pour ceci. Ces robots génèrent typiquement un grand nombre d'enregistrements automatiques sur les sites de forum, de spams de commentaires dans les blogs et de vandalisme sur les pages des wikis : spam des liens le plus souvent, bien que le contenu existant soit quelques fois effacé, ou complété avec des caractères aléatoires quelconques ou modifié de sorte à casser le texte Unicode existant.

Un CAPTCHA relativement simple peut réduire le problème de manière significative mais aussi bloquer la création de certaines pages souvent vandalisées. Ces mesures n'éliminent pas complètement le problème néanmoins elles renforçent la sécurité de tous les utilisateurs au détriment parfois des contributeurs légitimes.

Il serait préférable, au lieu de s'en remettre uniquement à CAPTCHA ou aux autres précautions qui touchent tous les utilisateurs, de cibler particulièrement ces adresses IP déjà connues des autres maîtres de sites pour être le paradis du net.abuse. Plusieurs listes sont déjà disponibles, par exemple stopforumspam.com possède une liste de « Toutes les adresses IPs en CSV » qui (en février 2012) contient environ 200 000 adresses IPs de robots spammeurs connus.

Utilisation du CPU et surcharge

Notez-bien que lorsque plusieurs contrôles sont réaliés sur les tentatives de modification ou d'affichage de pages, les robots peuvent facilement surcharger votre wiki et l'interrompre plus que si la protection n'avait pas eu lieu. Soyez vigilent sur le coût des ressources utilisées pour vos protections.

DNSBL

Vous pouvez demander à ce que MediaWiki vérifie que chaque adresse IP qui fait des modifications soit comparée à une ou plusieurs listes noires basées sur les DNS (DNS-based blacklists - DNSBLs), ce qui ne demande pas de maintenance mais augmente sensiblement le délai de réponse. Par exemple vous pouvez ajouter cette ligne à votre fichier LocalSettings.php pour bloquer beaucoup de proxy ouverts et les spammeurs des forums :

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

Pour les détails de ces DNSBLs, voir Spamhaus: XBL et dnsbl.tornevall.org. Pour une liste de DNSBLs, voir Compaison des listes noires DNS. Voir aussi Manuel:$wgEnableDnsBlacklist et Manuel:$wgDnsBlacklistUrls .

$wgProxyList

Avertissement Avertissement : Cette technique particulière va augmenter sensiblement le temps de chargement de la page ainsi que la charge du serveur si la liste des adresses IP est longue. A utiliser donc avec précaution.

Vous pouvez indiquer dans la variable $wgProxyList une liste d'adresses IP à bannir. Ceci peut être rempli périodiquement à partir d'une source externe en utilisant un script lancé par cron tel que le suivant :

#!/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

Puis déclarez dans votre LocalSettings.php :

require_once "$IP/bannedips.php";

Vous pouvez enregistrer ces commandes dans un fichier tel que updateBannedIPs.sh, de sorte à pouvoir l'exécuter périodiquement.

Vous pouvez aussi choisir une solution pur PHP pour télécharger la liste des adresses IP à partir de stopforumspam. Pour faire cela voyez le script PHP disponible ici.

Si vous le faites et que vous utilisez en plus le cache APC, il est possible que vous deviez augmenter apc.shm_size dans php.ini pour accepter une liste aussi longue.

Vous avez simplement bloqué cent quarante mille spammeurs, nous l'espérons sans effet de bord négatif sur vos utilisateurs légitimes, et dit « adieu » à beaucoup des pires vandales connus de l'Internet. Bon débarras ! Ce qui devrait rendre la situation plus calme au moins pour un certain momment...

Pots de miel, DNS BLs et HTTP BLs

140 000 spammers ont été supprimés. Pas mal, mais tout opérateur BOFH un peu obsédé sera à ce point ennuyé et cherchera une 140 001e adresse IP de spammeur à bloquer au hasard. Et pourquoi pas ?

Heureusement les listes de robots spammeurs mises à jour automatiquement, les proxy ouverts et les adresses IP posant problème sont largement disponibles. Beaucoup permettent aussi que les noms d'utilisateurs ou les adresses courriel (pour les utilisateurs connectés) soient automatiquement vérifiés avec ces mêmes listes noires.

Une forme de liste noire familière aux administrateurs MediaWiki est la DNS BL. Une liste noire DNS est hébergée sur un serveur de noms de domaines et consiste en une base de données d'adresses IP. La recherche d'une adresse détermine si une adresse IP qui essaie de s'enregistrer ou de modifier est une source déjà connue d'abus sur le réseau.

Les options $wgEnableDnsBlacklist et $wgDnsBlacklistUrls de MediaWiki fournissent un exemple de primitive pour accéder à la liste noire d'un DNS. Initialisez les paramètres suivants dans LocalSettings.php et les adresses IP listées comme spam HTTP sont bloquées :

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

La liste noire du DNS fonctionne ainsi :

  • Un wiki reçoit une demande de modification ou d'enregistrement d'un nouvel utilisateur pour une adresse IP aléatoire (par exemple, sous le format '123.45.67.89')
  • Les quatre octets de l'adresse IP sont placés dans l'ordre inverse, et sont suivi du nom du serveur DNS de liste noire désiré.
  • L'adresse résultante est demandée au serveur de noms de domaine (dans cet exemple,'89.67.45.123.zen.spamhaus.org.' et '89.67.45.123.dnsbl.tornevall.org.')
  • Le serveur renvoie 'not found (NXDOMAIN)' si l'adresse n'appartient pas à la liste noire. Si elle est dans l'une quelconque de ces listes, la modification est bloquée.

La vérification dans une liste noire hébergée extérieurement n'ajoute pas plus de quelques secondes au temps nécessaire à l'enregistrement de la modification. A la différence des paramètres $wgProxyKey , qui doivent être chargés à chaque lecture ou écriture de page, l'utilisation de la liste noire DNS ne se fait que lors de l'inscription ou de la modification des pages. Ceci ne change pas la vitesse à laquelle le système répond aux demandes de lecture des pages (c'est le principal de votre traffic).

Alors que le projet original SORBS (Spam and Open Relay Blocking System) était initialement fait pour s'attaquer aux proxy web ouverts et aux pourriels, il existe d'autres listes spécifiques pour le spam du web (les forums, commentaires de blog, modifications du wiki) qui pourraient être plus adaptées à cela :

  • .opm.tornevall.org. opère d'une manière très similaire aux DNSBL de SORBS, mais cible les proxy ouverts et le vandalisme des formulaires web. La plupart de son contenu est consolidé avec d'autres listes existantes d'adresses IP.
  • .dnsbl.httpbl.org. cible particulièrement les robots qui ramassent les adresses courriel sur les pages web pour créer des listes d'envoi de courriel en masse, ou laisser des commentaires de spam ou essayer de voler les mots de passe en utilisant l'attaque des dictionnaires. Elle nécessite que l'utilisateur soit enregistré avec projecthoneypot.org pour un clé d'API sur 12 caractères. Si cette clé (par exemple) était 'myapitestkey', une recherche qui autrement ressemblerait à '89.67.45.123.http.dnsbl.sorbs.net.' ou '89.67.45.123.opm.tornevall.org.' devrait être 'myapitestkey.89.67.45.123.dnsbl.httpbl.org.'
  • les listes noires basées sur le web peuvent identifier les adresses courriel des spammeurs et les informations utilisateurs derrière une simple adresse IP, mais il n'y a pas de format standard pour la réponse provenant des serveurs HTTP de listes noires. Par exemple, une requête sur http://botscout.com/test/?ip=123.45.67.89 retournerait "Y|IP|4" si l'adresse est en liste noire ('N' ou blanc si OK), alors qu'une requête web pour http://www.stopforumspam.com/api?ip=123.45.67.89 retournerait "ip yes 2009-04-16 23:11:19 41" si l'adresse est en liste noire (l'heure, la date et le compteur peuvent être ignorés) ou blanc si l'adresse est bonne.

Comme il n'y a pas de format standard avec lequel un serveur de liste noire puisse répondre à une requête, il n'existe pas non plus de support intégré pour la plupart des listes de robots spammeurs dans le paquet MediaWiki en stock. Depuis la rev:58061, MediaWiki peut vérifier de multiple DNSBLs si $wgDnsBlacklistUrls est défini en tant que tableau.

La plupart des opérateurs de listes noires ne fournissent qu'un support très limité (souvent destiné aux applications non wiki telles que phpBB ou Wordpress). Comme les mêmes robots spammeurs créent des problèmes similaires sur la plupart des sites web à contenu ouvert, les pires assaillants qui attaquent les sites MediaWiki vont aussi s'occuper à cibler des milliers de sites qui ne sont pas des wikis pour les vandaliser par des commentaires de blog, des billets sur les forums et des accès au livre d'or.

C'est pourquoi l'interrogation automatique de multiples sites de liste noire est déjà largement utilisée pour protéger différentes autres formes de sites à contenu ouvert et les noms des robots spammeurs, leurs rangs et leurs adresses IP sont à présent déjà trop bien connus. Finalement le pourcentage de robots spammeurs est relativement très faible par rapport au pourcentage général du problème. Là même où les administrateurs ne font aucun prisonnier, un modèle où la même adresse de robot spammeur qui a posté le spam des liens sur le wiki il y a une seconde, est qui est en train de vandaliser les commentaires de blog ailleurs maintenant, puis va spammer les billets du forum dans quelques secondes maintenant sur un site à l'autre bout du monde, est particulièrement bien repérée. Une seule entrée de la liste noire externe partagée peut faire taire un robot qui pose problème en adressant des milliers de sites.

Ceci réduit de beaucoup le nombre d'adresses IP individuelles devant être bloquées manuellement, un wiki et un forum à la fois, par les administrateurs locaux.

Mais qu'est-ce ceci par rapport aux pots de miel ?

Quelques sites anti-spam, tels que projecthoneypot.org fournissent du code que vous êtes invité à inclure dans les pages de votre propre site.

Typiquement il s'agit de pages qui contiennent une ou plusieurs adresses courriels ou liens uniques, choisis au hasard et cachés, qui ne concernent pas les visiteurs humains mais faits pour les robots spammeurs. A chaque fois que la page est demandée, les adresses incluses sont automatiquement modifiées, permettant aux éléments de spam individuels d'être directement et associés de manière conclusive aux adresses IP des robots qui ont récupéré les adresses de vos sites. L'adresse IP utilisée par le robot pour afficher votre site est automatiquement transmise aux opérateurs du service des listes noires. Souvent un lien vers un 'commentaire' factice ou un 'livre d'or' est également caché pour piéger les robots qui envoient du spam vers les formulaires web. Voir le Pot de miel (en informatique).

Dès que l'adresse du spammeur est connue, elle est ajoutée aux listes noires (voir ci-dessus) si bien que vous et les autres utilisateurs auront à l'avenir, un robot visiteur non désiré de moins sur vos sites.

Alors que les scripts des pots de miel et des serveurs de liste noire peuvent automatiser la majorité des tâches d'identification et de traitement des adresses IP des robots spammeurs, la plupart des sites de liste noire ne fournisdent que des liens vers les pages web où vous pouvez manuellement chercher les informations à propos d'une adresse IP ou rapporter une adresse IP qui abuse en tant que robot spammeur. Il est conseillé d'inclure certains de ces liens dans les pages special:blockip de votre wiki pour en informer vos administrateurs de site.

Davantage de listes d'adresses IP de serveurs mandataires et de robots spammeurs

Typiquement en fournissant l'adresse de n'importe quel robot ou proxy ouvert à un moteur de recherche, on recevra plusieurs listes où figureront déjà ces adresses IP abusives.

Dans certains cas, les listes feront partie des sites anti-spam, dans d'autres, un site défendant l'utilisation des proxy ouverts ne listera pas que le proxy abusé qui a été utilisé pour vandaliser l'installation de votre wiki mais des centaines d'autres proxy qui comme lui sont ouverts aux abus. Il est également possible de bloquer les inscriptions au wiki à partir de sources anonymes telles que les proxy Tor (projet Tor - torproject.org), à partir d'utilisateurs de comptes factices bugmenot ou d'adresses courriel (listées par undisposable.net) à utilisation unique.

Voir aussi la Comparaison des listes noires - 1er mars 2008 et spamfaq.net pour les listes noires elles-mêmes. Rappelez-vous que les listes qui normalement servent à détecter le spam des courriels, vont générer beaucoup de faux positifs si elles sont utilisées pour bloquer le spam des commentaires sur les wikis ou autres formulaires web. L'utilisation automatisée d'une liste qui placerait en liste noire tous les blocages dynamiques des adresses IP d'utilisateurs par exemple, pourrait garantir votre wiki mais il ne serait pas utilisable.

Pour pointer vers les sites d'adresse IP en liste noire à partir de la page Special:Blockip de votre wiki (comme moyen pratique pour les administrateurs souhaitant vérifier manuellement si une adresse problématique correspond à un robot déja connu) :

  1. Ajoutez une ligne à LocalSettings.php pour définir : $wgNamespacesWithSubpages [NS_SPECIAL] = true;
  2. Ajouter le texte suivant dans MediaWiki:Blockiptext pour l'afficher :
"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]."

Ceci va ajouter une invitation au message de demande de vérification Check this IP at: Domain Tools, OpenRBL, Project Honeypot, Spam Cop, Spamhaus, Stop Forum Spam à la page à partir de laquelle les administrateurs demandent le blocage d'une adresse IP. L'adresse IP est une information suffisante pour faire des commentaires sur le Projet du pot de miel contre les robots spammeurs, Stop Forum Spam est moins adapté au rapports des problèmes venant des adresses IP anonymes car il nécessite le nom de l'utilisateur, l'adresse IP et l'adresse courriel avec lesquels un robot problématique a tenté de d'enregistrer sur votre site wiki. Les politiques et les possibilités des autres sites web relatifs aux listes noires peuvent être différentes.

Notez-bien que bloquer l'adresse du robot spammeur qui vous attaque n'est pas la même chose que bloquer les URLs des liens externes spécifiques étant vandalisés dans le texte modifié. Faites les deux. Les deux approches utilisées de manière combinée en tant que moyen complémentaire (mais pas de substitution) à d'autres outils anti-spam tels que les listes noires des titres ou des utilisateurs et les tests qui tentent de déterminer si une modification est faite par un humain ou un robot (captchas ou akismet) peuvent s'avérer être un moyen très efficace pour distinguer les robots spammeurs des visiteurs humains bien réels.

Et si le vandale gagnait la bataille ?

Vous pouvez encore gagner la guerre ! MediaWiki vous offre les outils pour le faire; il suffit que vous consolidiez vos positions jusqu'à ce que vous soyez prêts à attaquer à nouveau. Voir Manuel:Combattre le vandalisme et en particulier les sections Nettoyage et Restreindre les modifications.

Voir la section des Liens externes pour d'autres outils mais ils n'ont pas leur support dans MediaWiki.

Autres idées

Cette page liste les fonctionnalités actuellement incluses ou disponibles en tant que patches, mais sur la page de discussion vous trouverez beaucoup d'autres idées de fonctionnalités anti-spam qui pourraient être ajoutées à MediaWiki, ou qui sont en cours de développement.

Voir aussi

Extensions

  • AbuseFilter — permet d'empêcher les modifications et bloque d'après une variété de critères
  • Une version allégée de ConfirmAccount peut être utilisée pour modérer l'enregistrement des nouveaux utilisateurs (ne nécessite pas de Captchas).
  • CheckUser — permet entre autre de vérifier les adresses IP sous-jascentes des comptes spammeurs afin de les bloquer. Permet de bloquer en masse les spammeurs d'endroits similaires.
  • HoneyPot
  • SpamRegex — permet le blocage de base à l'aide d'une simple expression régulière, des modifications contenant les domaines de spam
  • StopForumSpam — permet de vérifier les modifications à l'aide du service StopForumSpam et de lui renvoyer les données quand vous bloquez des utilisateurs.
  • Category:Spam management extensions — catégorie regroupant de manière exhaustive les extensions gèrant les listes de spam
  • Content approval extensions ne pas montrer les modifications tant qu'elles n'ont pas été approuvées par un modérateur.

Utile seulement avec certaines fermes de wikis :

Services commerciaux :

Fournies avec l'installateur

Dorénavant les archives tar disponibles au Téléchargement contiennent la plupart des extensions principales anti-spammeurs entre autres les suivantes :

  • ConfirmEdit — ajoute différents types de CAPTCHAs sur votre wiki
  • Nuke — supprime toutes les contributions d'un utilisateur ou d'une adresse IP
  • SpamBlacklist — empêche les modifications contenant des domaines de spam, la liste est modifiable sur le wiki par les utilisateurs privilégiés


Paramètres

Liens externes


Références

  1. Exemple : « résoudre automatiquement les captchas : GSA Captcha Breaker + Mega Ocr (résoud les Recaptcha !) » comme le dit l'utilisateur Senukexcr.
  2. Par exemple la Section 508 des standards de l'électronique et de la technologie de l'information
  3. Le New York Times du 25 avril 2010 Des vandales paient d'autres personnes pour répondre aux tests de sécurité par Vikas Bajaj