Manual:Combating vandalism/gu


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

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):
 * 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)
 * અવરોધ નોંધણી: 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
 * Other shortcuts
 * Hide Revisions: For hiding bad usernames still left in logs or bad edit comments etc

Typical steps for dealing with vandalism

 * 1) Rename user if bad username
 * 2) Block username indefinitely (or whatever you think is appropriate)
 * 3) * Or if its an IP, block the IP temporarily (indefinite IP blocks are not recommended in most cases)
 * 4) 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.
 * 5) In the case of pages created by vandalism or redirects, delete those pages and redirects.
 * 6) 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