Manuel:Combattre le vandalisme

Votre site a-t-il été vandalisé ? Laissez votre message sur la page de discussion, le forum, ou encore la liste de diffusion par courriel mediawiki-l afin d'obtenir de l'aide. Voir aussi Manuel:Combattre le spam .

Lorsque vous installez une nouvelle copie de MediaWiki, elle peut devenir la cible de différents types de vandalismes. De par la nature même des sites web, et peu importe le nombre de sécurités déployé, le vandalisme sera toujours présent jusqu'à un certain niveau. Cette page explique comment vous pouvez le limiter. Notez que Wikipedia est beaucoup plus gros que les autres sites web qui installent MediaWiki; il est modifié beaucoup plus souvent que la moyenne des wikis et regroupe davantage d'utilisateurs à gérer pour le vandalisme. La dynamique du vandalisme pour les sites web des petits wikis est différente.

Types d'attaques

• Attaque en masse par robot : un vandale peut essayer d'exécuter un robot dont le rôle est de modifier, renommer, créer des pages à une grande vitesse, ou encore téléverser des versions illicites d'images. C'est le type de vandalisme le plus fréquent sur la plupart des wikis, et c'est fait habituellement pour spammer : voir Combattre le spam pour des conseils adaptés.
• Noms d'utilisateur inconvenants : les utilisateurs peuvent être renommés en utilisant l'extension Rename User. Renommez toujours l'utilisateur en priorité, ensuite seulement faites les autres actions (bloquez et annulez ses contributions). Cela va garder les journaux et les modifications récentes aussi cohérents que possible.
• Suppression du contenu (partiel ou complet)
• Vandalisme des modèles : un vandale peut modifier les modèles utilisés partout et ainsi perturber beaucoup de pages. Pour contrer cela, protégez les modèles les plus utilisés dont la liste est donnée sur la page [[Special:MostLinkedTemplates]] (par exemple sur ce wiki)

Identifier la dégradation et le piratage

La première chose est de déterminer si le site est actuellement compromis, c'est à dire a été vandalisé. Allez sur différentes pages pour voir si les dégradations sont partout. Si de multiples pages sont dégradées, il est possible qu'un modèle commun ou même la notice du site ont été vandalisés.

Pour déterminer si le site est encore en train de charger, ouvrez la console développeur du navigateur et vérifiez le HTML. Si le HTML contient le contenu de la page, alors le site n'est probablement pas compromis.

Solutions et suggestions

Prévention

• Extension:TitleBlacklist - Ceci vous aide à propos des mauvais titres de page et de noms d'utilisateurs
• Extension:ConfirmEdit et Extension:QuestyCaptcha - Bien que les Captcha soient plus utiles contre le spam, ils sont également quelque peu utiles aussi contre le vandalisme dans la mesure où le vandale peut avoir à répondre aux Captcha pour créer des comptes, ajouter des liens externes, etc. Cependant, cela gênera également l'utilisateur véritable, les Captcha doivent donc être utilisés et configurés de manière réfléchie. Une meilleure option pourrait être $wgRateLimits ou VandalBrake2, ce qui limiterait simplement le taux d'édition.
• Initialiser $wgAccountCreationThrottle à une valeur positive. Ceci est inutile si vous n'avez pas de vandales qui se partagent la même adresse IP au cours d'une journée, mais cela pose en revanche quelques problèmes si certains utilisateurs s'inscrivent à partir d'adresses IP partagées au cours d'une journée donnée.
• Extension:TorBlock - pour empêcher les vandales d'échapper à toutes les autres mesures de prévention en changeant facilement les adresses IP à l'aide de Tor, si la modification du wiki de manière anonyme n'est pas demandée.
• Extension:SpamBlacklist - si le wiki souffre de sites web de spam sévères qui sont récurrents, ont un schéma ou sont souvent déjà bloqués en liste noire (sinon, maintenir la liste noire n'en vaut pas la peine).
• Extension:AbuseFilter - Extension qui contrôle les comportements sur le wiki et qui est très adaptable. Différents types de règles peuvent être créés. Pour des exemples de filtres et la manière dont ils fonctionnent, voir les règles des filtres Wikipedia. Les filtres peuvent aussi être configurés pour ne pas apparaître au public.
• $wgAutoblockExpiry - Si plusieurs comptes utilisateur de vandales sont créés à partir des mêmes adresses IP en peu de temps, augmenter ce nombre peut aider à multiplier l'effet de vos blocages manuels avec le blocage automatique activé. Inutile pour les vandales manuels qui peuvent changer leur IP facilement, et pour les robots vandales qui ont de nombreuses IP ; nuisible (dans une certaine mesure) s’ils proviennent d’adresses IP partagées que vos utilisateurs légitimes peuvent utiliser.
• $wgNamespaceProtection - Protéger les modèles de sorte que seuls les utilisateurs auto-confirmés ou les administrateurs système puissent les mettre à jour
• Extension:BlocageGlobal - Utile pour combattre le vandalisme anonyme sur plusieurs wikis.
• $wgRateLimits - Limiter les activités des utilisateurs anonymes ainsi que celles des débutants.
• Utiliser les droits utilisateur pour retirer aux débutants les droits dont ils n'ont pas besoin. Par exemple vous pouvez positionner $wgGroupPermissions['reupload']['*'] = false; si vous voulez empêcher ceux qui ne sont pas des administrateurs système, de remplacer vos images existantes par des images du site goatse ou équivalentes.
• Extension:Lockdown - Utile pour limiter les utilisateurs anonymes et les nouveaux venus, à faire leurs modifications dans l'espace de noms Draft: et / ou Introduction:.
• Extension:Moderation : Envoie toutes les modifications des nouveaux utilisateurs à la modération. Si, ou lorsque le modérateur approuve la modification, celle-ci apparaîtra dans l'historique de la page et dans la liste des Modifications récentes. Toutes les modifications d'un vandale peuvent être rejetées d'un seul clic.

Lockdown

Pour désactiver temporairement la création de comptes et les modifications anonymes, un administrateur système peut indiquer ceci dans le fichier LocalSettings.php :

$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;

Si vous utilisez Extension:AbuseFilter , un administrateur peut (avec différents degrés de succès selon la configuration et la situation) activer ou désactiver rapidement les adresses IP avec un filtre sur :

(user_age == 0)

Voir Manuel:Empêcher l'accès pour les autres moyens.

Approbation des modifications

• Extension:FlaggedRevs - approuver les modifications de la version stable d'une page
• Extension:Approved Revs - une alternative à faible coût pour FlaggedRevs

Si le vandalisme n'a pas gagné la dernière bataille sur votre wiki

Nettoyage

Après avoir combattu le spam, il est nécessaire de réparer les dégâts. Si vous laissez en place spam existant, les fonctionnalités antispam pourront interférer avec les personnes qui tenteront d'apporter des modifications légitimes.

Si le problème se limite à quelques pages, il peut être résolu manuellement à l'aide des fonctions administratives standard.

Outils standards de nettoyage

Si vous disposez d'un ensemble de pages à supprimer, le script maintenance/deleteBatch.php peut vous aider.

Si le problème se limite à quelques adresses IP ou utilisateurs, Extension:Nuke peut systématiquement supprimer toutes leurs contributions. S'il est soumis sans modèle utilisateur ou de page, la fonctionnalité Nuke vous permet également de lister les pages récemment créées et de cocher les cases pour savoir lesquelles supprimer ou non, ce qui peut être un outil de nettoyage du spam très efficace si vous avez quelques pages valides avec beaucoup de spam.

Le script de maintenance rollbackEdits.php peut être utilisé pour annuler « toutes » les modifications d'un utilisateur ou d'une adrresse IP donnée, si ces modifications sont les « dernières » modifications d'une page.

Extension:SmiteSpam ajoute des outils de blocage et de suppression similaires pour l'ensemble des modifications récentes.

Une approche légèrement plus radicale implique les scripts de maintenance après la suppression par lots, telle que :

• deleteArchivedRevisions.php pour purger les modifications supprimées de votre base de données,
• removeUnusedAccounts.php pour purger également les comptes.

cleanup.php

Si le spam est largement répandu et réalisé par plusieurs utilisateurs, l'extension SpamBlacklist peut vous être utile. Ce script revient automatiquement en arrière et supprime le spam correspondant sur votre wiki après que vous ayiez mis à jour la liste noire du spam. Pour ce faire, il analyse l'intégralité du wiki et là où du spam est trouvé, il revient à la dernière révision sans spam.

Procédure :

1. Connectez-vous en utilisant OpenSSH.
2. Accédez au sous-répertoire extensions/SpamBlacklist
3. tapez "dir" pour confirmer que cleanup.php est présent dans le répertoire
4. entrez "php cleanup.php" pour exécuter le script

Autres outils de nettoyage

• Extension:Nuke : les administrateurs système peuvent supprimer en masse les pages créées par un utilisateur donné ou par une adresse IP (présente dans le téléchargement standard)
• Extension:Renameuser : afin que vous puissiez renommer les mauvais noms d'utilisateur (inclus dans le téléchargement standard)
• Activez les autorisations de restauration en ajoutant ce qui suit à votre LocalSettings.php et accordez le droit « rollback  » dans la gestion des droits d'utilisateur aux utilisateurs de confiance, afin qu'ils puissent annuler plus facilement le vandalisme lorsqu'il se produit :

$wgGroupPermissions['rollback']['rollback'] = true;

• Extension:CheckUser : permet de trouver les adresses IP des utilisateurs afin de bloquer les adresses IP sous-jacentes des vandales en série.

Les fonctionnalités en gras ci-dessus sont faciles et rapides à installer et vous aideront beaucoup, alors installez-les définitivement.

Modifications restreintes

Dans certains cas, il est suffisant (et approprié) de restreindre l'édition des pages aux utilisateurs ayant créé un compte. Cette restriction mettra fin à un certain nombre d'attaques automatisées. Cette approche peut être associée, par exemple, à l'exigence d'un Captcha lors de l'enregistrement du compte, comme décrit ci-dessus, ou au blocage des noms d'utilisateur correspondant à une certaine expression régulière à l'aide de l'extension TitleBlacklist .

Il est également possible de configurer MediaWiki pour exiger la vérification du courriel avant de modifier certaines pages (Manuel:$wgEmailConfirmToEdit ). Voir la page preventing access pour le détail de ces méthodes.

• Manuel:Empêcher l'accès
• $wgGroupPermissions

Même lorsque l'édition est limitée aux titulaires de comptes, les spammeurs peuvent automatiquement créer des comptes et inonder un wiki avec des spams de nouveaux comptes. Cela peut être largement évité en désactivant la création de compte et en transférant l'authentification vers un service tel que Extension:OpenID Connect . La création de nouveaux comptes est désactivée avec cette ligne dans LocalSettings.php :

$wgGroupPermissions['*']['createaccount'] = false;

MediaWiki:Loginprompt peut être mis à jour par défaut pour suggérer aux nouveaux utilisateurs de créer leur compte avec un OpenID. Les comptes courants ne sont pas affectés et les nouveaux utilisateurs ont souvent déjà un compte auprès de l'un des fournisseurs OpenID.

Verrouillage (solution radicale)

Vous pouvez interdire la modification par les utilisateurs anonymes, en les obligeant à créer un compte avec un nom d'utilisateur et à se connecter avant de procéder aux modifications. En dernier recours, le spam peut être presque éliminé en créant une « communauté fermée » dans laquelle les nouveaux utilisateurs ne peuvent pas créer de nouveau compte et doivent vous le demander.

Les gens suggèrent souvent naïvement le verrouillage comme étant la meilleure solution au spam des wikis. Cela réduit effectivement le spam, mais c'est une mauvaise solution et une solution paresseuse, car vous introduisez quelque chose qui « indispose énormément les utilisateurs de bonne foi ». Devoir choisir un nom d’utilisateur et un mot de passe est un obstacle conséquent pour de nombreuses personnes. La méthode wiki est qu'il soit librement et ouvertement modifiable. Cette approche de « sécurité douce » est l'une des principales forces du concept wiki. Allez-vous laisser les spammeurs gâcher cela ? Si c'est le cas, vous pouvez facilement verrouiller votre installation MediaWiki en ajoutant ce qui suit à votre LocalSettings.php :

#Obliger les utilisateurs à s'inscrire avant d'être autorisés à modifier
$wgGroupPermissions['*']['edit'] = false;

Notez que cela ne fait que réduire le spam. Les installations MediaWiki sont régulièrement ciblées par des robots spammeurs qui effectuent des enregistrements automatisés, et ce paramètre entraînera donc de nombreux faux comptes d'utilisateurs dans la base de données, généralement avec des noms qui suivent un modèle reconnaissable. Les spammeurs peuvent créer de nombreux « comptes dormants », c'est-à-dire des comptes qui ne font rien et qui seront ensuite utilisés ultérieurement pour le spam. Vous devez combiner cela avec d'autres mesures telles que les CAPTCHAs (voir ci-dessus) à l'enregistrement des utilisateurs et / ou le blocage des adresses IP des spammeurs.

La création de comptes par les spammeurs peut être réduite en transférant l'authentification vers un service tel que Extension:OpenID Connect . La création de nouveau compte est désactivée avec cette ligne dans LocalSettings.php :

$wgGroupPermissions['*']['createaccount'] = false;

MediaWiki:Loginprompt peut être mis à jour par défaut pour suggérer aux nouveaux utilisateurs de créer les comptes avec un OpenID. Les comptes courants ne sont pas affectés et les nouveaux utilisateurs ont souvent déjà un compte auprès de l'un des fournisseurs OpenID.

Certains spammeurs ne fournissent pas d'adresses courriel ou fournissent des adresses courriel non invalides. Pour y remédier, vous pouvez exiger une validation par courriel avant de modifier avec Manuel:$wgEmailConfirmToEdit  :

$wgEmailConfirmToEdit = true;

En dernier recours, le spam peut être presque entièrement éliminé en créant une « communauté fermée » dans laquelle les nouveaux utilisateurs ne peuvent même pas s'inscrire sans vous demander de leur créer un compte. Pour faire cela, ajoutez ce qui suit dans votre fichier LocalSettings.php:

#Disallow creating accounts
$wgGroupPermissions['*']['createaccount'] = false;

Vous pouvez ensuite afficher Special:UserLogin lorsque vous êtes connecté pour créer de nouveaux comptes. Voir Manuel:Droits utilisateurs et Manuel:Empêcher l'accès pour plus d'informations.

Conseils et points à retenir

• Le vandalisme ponctuel (ou spam) provenant d'une adresse IP peut ne mériter qu'un blocage temporaire (1 mois ou 1 semaine, etc.), sauf en cas de vandalisme / spam récurrent provenant d'une adresse IP statique.
• Configurez vos systèmes de protection de manière à ce qu'ils ne gênent pas de manière significative l'utilisateur standard.

Raccourcis relatifs à l'administration

Gardez une page pour les administrateurs sur le wiki relative aux liens rapides pour faire face au vandalisme. Cliquez sur « Modifier » pour cette section et copiez le code ci-dessous :

Relatif à l'utilisateur

• renommage de l'utilisateur : Special:RenameUser
• journal des nouveaux utilisateurs : Special:Log/newusers
• Liste des utilisateurs : Special:ListUsers

Relatif au blocage

• blocage des adresses IP : Special:Block
• Intervalles de blocage des adresses IP (évaluez ces intervalles de blocage avec soin et dans la plupart des cas seulement temporairement, par exemple pour 24 heures, 3 jours, 2 semaines, 3 mois, etc. en fonction de la situation) :
  • Table des exemples d'intervalles
    • Intervalles d'adresses IPV6
  • Les plus souvent utilisés (exemples de blocages) :
    • IPv4
      • 69.208.0.0/16 (pour bloquer 69.208.x.x)
      • 69.208.52.0/24 (pour bloquer 69.208.52.x)
    • IPv6
      • 2001:db8::/64 (pour bloquer 2001:db8:0:0:x:x:x:x)
      • 2001:db8:90:ac:fdec:9aec::/96 (pour bloquer 2001:db8:90:ac:fdec:9aec:x:x)
• Journal des blocages : Special:Log/block
• Déblocage et liste des blocages actuels : Special:BlockList

Autres raccourcis

• Masquer les révisions : pour cacher les noms inconvenants d'utilisateur encore présents dans les journaux ou les commentaires des mauvaises modifications etc

Etapes typiques de la gestion du vandalisme

1. Renommer l'utilisateur si le nom d'utilisateur ne convient pas.
2. Bloquer un nom d'utilisateur indéfiniment (ou pour une durée qui vous semble convenable)
   • Ou s'il s'agit d'une adresse IP, bloquer cette adresse IP temporairement (les blocages infinis ne sont pas recommandés dans la plupart des cas)
3. Annuler les modifications faites par cet utilisateur en vérifiant les contributions. Notez que si vous avez renommé l'utilisateur, les contributions sont attribuées au nouveau nom d'utilisateur et non plus à l'ancien.
4. Dans le cas des pages créées par le vandalisme ou des redirections, supprimer ces pages et ces redirections.
5. Masquez les révisions si nécessaire. Ceci nous aide à masquer les commentaires des modifications, ou les noms inappropriés des utilisateurs pour les modifications, afin que les journaux des pages restent propres

Voir aussi

• Manuel:Sécurité
• Manuel:Combattre le spam : traite de la forme de vandalisme la plus courante, que tout le monde déteste