Manual:Combating vandalism

From MediaWiki.org
Jump to: navigation, search
Is your site being vandalized? Please leave a message on the talk page or the forum, or the mediawiki-l email list to get advice. See also Manual:Combating spam.

When you install a fresh copy of MediaWiki, it is susceptible to different kinds of intentional vandalism. Due to the nature of a wiki website, no matter how many protections are present, vandalism will always be present to a certain extent. This page will describe how to limit it. Note that Wikipedia is much larger than other websites that install MediaWiki; it has many more edits than the average wiki, but also more users to monitor vandalism. The dynamics of vandalism for small wiki websites is different.

Types of attacks[edit | edit source]

  • Bot flood attacks: A vandal may attempt to run a bot that can edit/move and create pages at a high speed, or upload unwelcome versions of images. This is the most frequent kind of vandalism on most wikis and usually done for spam purposes: see Manual:Combating spam for specific advice.
  • Bad user names: user names can be renamed using the Rename User extension. Always rename a user first and then do other actions (block and reverts). This will keep the logs and recent changes as clean as possible.
  • Removal of content (partial or complete)
  • Template vandalism: a vandal may edit commonly used templates to affect a large number of pages. To deal with this, protect the most commonly used templates which can be seen from Special page: [[Special:MostLinkedTemplates]] (for example on this wiki)

Solutions and Suggestions[edit | edit source]

Preventative[edit | edit source]

  • Extension:Title Blacklist: This helps against bad titles of pages and bad user names
  • Extension:ConfirmEdit and Extension:QuestyCaptcha: 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 $wgRateLimits or VandalBrake2, which merely throttle editing rate.
  • Set $wgAccountCreationThrottle 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 less problems if few users register from shared IPs in any given day.
  • Extension:TorBlock to prevent vandals from evading all other prevention measures by easily changing IPs using tor, if editing the wiki anonymously is not needed.
  • Extension:SimpleAntiSpam should block some bots and not affect users at all.
  • Extension:SpamBlacklist 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).
  • Extension:AbuseFilter: 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.
  • Extension:Bad Behavior: An automatic first defense line blocking all requests by known spammers identified via HTTP headers, IP address, and other metadata.
  • $wgAutoblockExpiry: 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.
  • Extension:AntiBot: May be useful in dealing with bot vandalism
  • $wgNamespaceProtection: Protect templates so only auto-confirmed users or sysops can edit templates
  • Extension:GlobalBlocking: Useful for combatting anonymous vandalism on multiple wikis.
  • $wgRateLimits: Throttle anons' and newbies' activities.
  • Use user rights to take away powers that newbies don't need. E.g., you could set $wgGroupPermissions['reupload']['*'] = false; if you wanted to keep non-sysops from superseding your existing images with goatse images and the like.
  • Extension:Lockdown: Useful for limiting anons and new users to editing a Draft: and/or Introduction: namespace.
Lockdown

To temporarily disable account creation and anonymous editing, a sysadmin can put this in LocalSettings.php:

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

If you use Extension:AbuseFilter, 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 Manual:Preventing access for other ways to prevent access.

Notification[edit | edit source]

Edit approval[edit | edit source]

If vandalism has won the last battle on your wiki[edit | edit source]

Cleaning up[edit | edit source]

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[edit | edit source]

If you identified a set of pages to delete, the maintenance/deleteBatch.php script is helpful.

If the problem is limited to a small number of IPs or users, Extension:Nuke 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.

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

cleanup.php[edit | edit source]

If spam is widespread and performed by many users, you may find this spam cleanup extension 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. Login using PUTTY.
  3. Navigate to the extensions/SpamBlacklist subdirectory
  4. type "dir" to confirm that cleanup.php is in the directory
  5. type "php cleanup.php" to run the script

Other cleanup tools[edit | edit source]

  • Extension:Nuke: sysops can mass delete page created by a certain user or IP (included in standard download)
  • Extension:Renameuser: so you can rename bad user names (included in standard download)
  • Enable Rollback permissions by adding the following to your LocalSettings.php and give the rollback right in user rights management to trusted users, so they can revert vandalism easier when it happens:
$wgGroupPermissions['rollback']['rollback'] = true;
  • Extension:Recent Changes Cleanup: enables administrators to keep their Recent Changes page free of vandalism related entries (always the last step).
  • Extension:CheckUser: allows the finding of user IP addresses in order to block the underlying IP addresses of serial vandals.
  • CleanMediawiki.sh: deletes specified user accounts ID and their pages, revisions, changes, and related indexes and cache.

Features bolded above are easy and quick to install and will help you a lot so definitely install those.

Restrict editing[edit | edit source]

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 Username Blacklist extension.

It is also possible to configure MediaWiki to require e-mail verification before editing certain pages ($wgEmailConfirmToEdit = true). See the preventing access 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 Extension:OpenID. 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.

Preventing adding links by untrusted users[edit | edit source]

Extension:NotEvil allows you to prevent adding links except by an on-wiki list of trusted users. This solution is particularly appropriate for wikis where external links are rarely added by legitimate users. Some users have found it useful to modify the regular expression '/http:\//' to a broader one capturing links with the protocol omitted.

Note that this extension is very basic - it is somewhat difficult to install and requires further development (e.g. it should be using user groups instead of an on-wiki user list).

Lock down (lazy solution)[edit | edit source]

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 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:

#Force people to register before they are allowed to edit
$wgGroupPermissions['*']['edit'] = false; 
$wgShowIPinHeader = false;

Note that this only reduces spam. MediaWiki installations are routinely targeted by spam bots 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 a large number of 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 CAPTCHAs (see above) on user registration and/or blocking spammer IPs.

Account creation by spammers may be reduced by transferring authentication to a service such as Extension:OpenID. 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 Manual:$wgEmailConfirmToEdit:

$wgEmailConfirmToEdit = true;

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:

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

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

Tips and Points to remember[edit | edit source]

  • 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[edit | edit source]

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
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):
    • Table of sample ranges
    • Most commonly used (sample blocks):
      • IPv4
        • 69.208.0.0/16 (for blocking 69.208.x.x)
        • 69.208.52.0/24 (for blocking 69.208.52.x)
      • IPv6
        • 2001:db8::/64 (for blocking 2001:db8:0:0:x:x:x:x)
        • 2001:db8:90:ac:fdec:9aec::/96 (for blocking 2001:db8:90:ac:fdec:9aec:x:x)
  • Block log: Special:Log/block
  • Unblocking and list of current blocks: Special:BlockList
Other shortcuts
  • Hide Revisions: For hiding bad usernames still left in logs or bad edit comments etc

Typical steps for dealing with vandalism[edit | edit source]

  1. Rename user if bad username
  2. Block username indefinitely (or whatever you think is appropriate)
    • Or if its an IP, block the IP temporarily (indefinite IP blocks are not recommended in most cases)
  3. Revert edits made by that user by checking the contribs. Note if you have renamed the user, the new username will have the contribs, not the original username.
  4. In the case of pages created by vandalism or redirects, delete those pages and redirects.
  5. Hide revisions if needed. This is helpful in hiding the edit comments or bad usernames for an edit so the page logs will remain clean
  6. Clean up recent changes and get rid of all the junk

See also[edit | edit source]