Manual:Combating vandalism/fr


 * 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 .

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.

Preventative
To temporarily disable account creation and anonymous editing, a sysadmin can put this in LocalSettings.php:
 * - This helps against bad titles of pages and bad usernames
 * - Although Captchas are more helpful for spam, they're also somewhat helpful in dealing with vandalism in that the vandal may have to fill captchas for creating accounts, adding external links and so on. However, this will also inconvenience the genuine user, so captchas should be used and configured thoughtfully. A better option might be or VandalBrake2, which merely throttle editing rate.
 * Set to a positive value. This is useless if you don't have vandal(s) who share the same IP during a day, but on the other hand gives fewer problems if few users register from shared IPs in any given day.
 * - to prevent vandals from evading all other prevention measures by easily changing IPs using tor, if editing the wiki anonymously is not needed.
 * - if the wiki suffers from severe spamming websites which are recurring, have a pattern or are often already blocked by an existing blacklist (otherwise, maintaining the blacklist is not worth the effort).
 * - An extension that monitors behaviours on the wiki and is very customizable. Different kinds of rules can be created. To see examples of filters and the work they do, see Wikipedia's filter rules. Filters can also be configured not to be visible to the public.
 * - If multiple vandal user accounts are created from the same IPs in little time, raising this may help multiply the effect of your manual blocks with autoblock enabled. Useless for manual vandals who can change their IP easily, and for vandal bots which have many IPs; harmful (over some degree) if they come from shared IPs your legitimate users may use.
 * - Protect templates so only auto-confirmed users or sysops can edit templates
 * - Useful for combating anonymous vandalism on multiple wikis.
 * - Throttle anons' and newbies' activities.
 * Use to take away powers that newbies don't need. E.g., you could set   if you wanted to keep non-sysops from superseding your existing images with goatse images and the like.
 * - Useful for limiting anons and new users to editing a Draft: and/or Introduction: namespace.
 * : Sends all edits from new users to moderation. If/when the moderator approves the edit, it will appear in page history and RecentChanges. All pending edits from a vandal can be rejected in one click.
 * Lockdown

If you use, an admin can (with varying degrees of success depending on configuration and situation) quickly enable or disable IPs with a filter on:

(user_age == 0)

See for other ways to prevent access.

Edit approval

 * - approve changes to the stable version of a page
 * - a lightweight alternative to

Cleaning up
After dealing with spam, it's necessary to clean up existing spam. If you allow existing spam to remain, then antispam features may interfere with people attempting to make legitimate edits.

If the problem is limited to a few pages, it can be cleaned up by hand using normal administrative functions.

Standard cleanup tools
If you identified a set of pages to delete, the  script is helpful.

If the problem is limited to a few IPs or users, can systematically remove all their contributions. If submitted without a user or page pattern, the Nuke feature also allows you to list recently created pages and tick checkboxes for which ones to delete or not, which can be a very effective spam cleanup tool if you have a few valid pages and a lot of spam.

The maintenance script can be used to rollback all edits of a given user or IP, if these edits are the latest edits of a page.

adds similar block and deletion tools for the entire recent changes.

A slightly more drastic approach involves after the batch deletion, such as:


 * to purge deleted edits from your database,
 * to also purge accounts.

cleanup.php
If spam is widespread and performed by many users, you may find this useful. This script automatically goes back and removes matching spam on your wiki after you make an update to the spam blacklist. It does this by scanning the entire wiki, and where spam is found, it reverts to the latest spam-free revision.

Procedure:
 * 1) Copy cleanup.php to the extensions/SpamBlacklist folder
 * 2) Navigate to the extensions/SpamBlacklist subdirectory
 * 3) type "dir" to confirm that cleanup.php is in the directory
 * 4) type "php cleanup.php" to run the script
 * 1) type "php cleanup.php" to run the script

Other cleanup tools

 * : sysops can mass delete page created by a certain user or IP (included in standard download)
 * : so you can rename bad usernames (included in standard download)
 * Enable Rollback permissions by adding the following to your LocalSettings.php and give the  right in user rights management to trusted users, so they can revert vandalism easier when it happens:

Features bolded above are easy and quick to install and will help you a lot, so definitely install those.
 * : allows the finding of user IP addresses in order to block the underlying IP addresses of serial vandals.

Restrict editing
In some cases, it is sufficient (and appropriate) to restrict editing pages to those users who have created an account. This restriction will halt a number of automated attacks. This approach can be coupled with, for example, requiring a captcha during account registration, as described above, or blocking usernames matching a certain regular expression using the extension.

It is also possible to configure MediaWiki to require e-mail verification before editing certain pages. See the page for more details on these methods.



Even when editing is restricted to account holders, spammers can automatically create accounts and flood a wiki with new account spam. This can largely be avoided by disabling account creation and transferring authentication to a service such as. New account creation is disabled with this line in LocalSettings.php: The MediaWiki:Loginprompt can be updated from the default to suggest that new users create accounts with an OpenID. Current accounts are unaffected, and new users often already have an account with one of the OpenID providers.

Lock down (lazy solution)
You can disallow editing by anonymous users, forcing them to create an account with a username and sign in prior to editing. As a last resort, spam can be nearly eliminated by creating a "gated community" in which new users cannot create a new account and must request one from you.

People often naively suggest lock-down as the best solution to wiki spam. It does reduce spam, but it is a poor solution and a lazy solution, because you are introducing something which massively inconveniences real users. Having to choose a username and password is a big turn off for many people. The wiki way is to be freely and openly editable. This "soft security" approach is one of the key strengths of the wiki concept. Are you going to let the spammers spoil that?

...if so, you can easily lock down your MediaWiki installation by adding the following to your LocalSettings.php:

Note that this only reduces spam. MediaWiki installations are routinely targeted by spambots which perform automated registrations, and so this setting will result in a lot of bogus user accounts in the database, usually with names that follow some recognizable pattern. Spammers may create numerous sleeper accounts, which are accounts that do nothing and then are used for spam at a later time. You should combine this with other measures such as (see above) on user registration and/or.

Account creation by spammers may be reduced by transferring authentication to a service such as. New account creation is disabled with this line in LocalSettings.php: $wgGroupPermissions['*']['createaccount'] = false; The MediaWiki:Loginprompt can be updated from the default to suggest that new users create accounts with an OpenID. Current accounts are unaffected, and new users often already have an account with one of the OpenID providers.

Some spammers don't supply e-mail addresses, or supply invalid e-mail addresses. To deal with these, you can require e-mail validation before editing with :

As a last resort, spam can be almost entirely eliminated by creating a "gated community" where new users can't even register without asking you to set up an account for them. To do this, add the following to your LocalSettings.php:

You can then visit Special:UserLogin while signed in to create new accounts. See and  for more information.

Tips and Points to remember

 * One-time vandalism (or spam) from an IP address may deserve only a temporary block (1 month or a 1 week etc.) unless there is recurrent vandalism/spam from an IP address that is static.
 * Configure your protection systems such that they should not significantly inconvenience the average user.

Administration related shortcuts
Keep a page for administrators on the wiki related to quick links for dealing with vandalism. Click "Edit" for this section and copy the code below:
 * User related
 * User rename: Special:RenameUser (requires )
 * New users log: Special:Log/newusers
 * User list: Special:ListUsers
 * Block related
 * Block IP: Special:Block
 * IP block ranges (perform block ranges carefully and in most cases only temporarily such as 24 hours, 3 days, 2 weeks, 3 months and so on depending on the situation):
 * 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
 * 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)
 * 3) * 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)
 * 4) 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.
 * 5) Dans le cas des pages créées par le vandalisme ou des redirections, supprimer ces pages et ces redirections.
 * 6) 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