Manual:Combating vandalism

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

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 Combating spam for specific advice.
Bad usernames: Users 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 many pages. To deal with this, protect the most commonly used templates which can be seen from page [[Special:MostLinkedTemplates]] (for example on this wiki)

Identifying defacement/hacking

The first thing to do is determine whether the site was actually compromised, or "hacked" as some would say. Try going to different pages to see if the defacement is on all of them. If multiple pages are defaced, then it is possible that a common template or the sitenotice was vandalized.

To determine whether the site is still loading, open the developer console in the browser and check the HTML. If the HTML includes the page content, then the site is probably not compromised.

Solutions and Suggestions

Preventative

Extension:TitleBlacklist - This helps against bad titles of pages and bad usernames
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 fewer 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: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.
$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.
$wgNamespaceProtection - Protect templates so only auto-confirmed users or sysops can edit templates
Extension:GlobalBlocking - Useful for combating 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.
Extension:Moderation : 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

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.

Edit approval

Extension:FlaggedRevs - Approve changes to the stable version of a page
Extension:Approved Revs - A lightweight alternative to FlaggedRevs

If vandalism has won the last battle on your wiki

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 maintenance/deleteBatch.php script is helpful.

If the problem is limited to a few 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.

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

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

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

deleteArchivedRevisions.php to purge deleted edits from your database,
removeUnusedAccounts.php to also purge accounts.

cleanup.php

If spam is widespread and performed by many users, you may find this maintenance script in the SpamBlacklist 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:

Login using OpenSSH.
Navigate to the extensions/SpamBlacklist subdirectory
Type "dir" to confirm that cleanup.php is in the directory
Type "php cleanup.php" to run the script

Other cleanup tools

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 usernames (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: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.

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 TitleBlacklist extension.

It is also possible to configure MediaWiki to require e-mail verification before editing certain pages (Manual:$wgEmailConfirmToEdit ). 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 Connect . New account creation is disabled with this line in LocalSettings.php:

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

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:

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

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 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 Connect . New account creation is disabled with this line in LocalSettings.php:

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

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

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
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):
- Table of sample ranges
  - IPv6 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

Rename user if a bad username
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)
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.
In the case of pages created by vandalism or redirects, delete those pages and redirects.
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