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.

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. This changes the dynamics of vandalism for small wiki websites.

Contents

[edit] Types of attacks

  • Bot flood attacks: A vandal may attempt to run a bot that can edit/move and create pages at a high speed.
  • 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)

[edit] Solutions and Suggestions

[edit] Preventative

  • 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: A light weight alternative for AbuseFilter, which has more features
  • $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.
Lockdown

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

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

See Manual:Preventing access for other ways to prevent access.

[edit] Notification

[edit] Edit approval

[edit] Cleaning up

  • Extension:Nuke: sysops can mass delete page created by a certain user or IP
  • RevisionDelete: with this feature it is possible to hide certain parts of a revision.
  • Extension:Renameuser - so you can rename bad user names
  • 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.

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

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

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

[edit] Typical steps for dealing with vandalism

  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

[edit] See also

Personal tools
Namespaces

Variants
Actions
Navigation
Support
Download
Development
Communication
Print/export
Toolbox