Difference between revisions of "Help:Spam Management"
(I have created a brief manual about spam management. It goes over the currently used tools, what they do, where to find them, and how to use them. Leave suggestions, questions, comments, etc on the talk page as I am looking to improve it further.)
Latest revision as of 04:05, 4 June 2018
Recurring spam is an issue that affects most dynamic websites, especially wikis like CryGaia. This page is designed to be a manual and source of information for administrators and editors on how to deal with incoming spam and understand what tools are currently in use. Most spam management is achieved through extensions. Users are encouraged to use the discussion page for any questions or comments about spam management on the wiki. Bug reports, suggestions, and collaboration are all welcome.
For a complete and up to date list of CryGaia’s installed extensions and software, check Special:Version.
By default, CryGaia requires all users to register in order to be able to edit and post articles. This is mainly a deterrent against vandalism, which is disruptive in a way similar to spam, as potential vandals cannot remain anonymous.
However, sometimes a flood of registrations come from spambots. If you see a flood of new user registrations with suspicious and similar usernames, they may possibly be spambots. Checking their user contributions to see if they’ve posted any spam works as a confirmation, but sometimes they may not create spam immediately because they may be getting blocked by some of the other anti-spam tools on the site. It is a good idea to keep watch on these users.
You can check a specific person’s contributions at Special:Contributions with either their IP address or username. Special:CheckUser can be used to find the IP address of a user and can be used for cross-referencing purposes. If an IP is frequently being used by spambots, it’s probably a good idea to block it to prevent it from creating more spam. You can also choose to see the contributions of new accounts only.
When in doubt, if it looks like a spambot, it probably is, and it should be safe to block the user. If a false positive occurs, you can simply unblock the user. You can unblock someone’s username or IP address at Special:Unblock. When doing so, please leave a reason to prevent any miscommunication between administrators.
When CryGaia first started, the wiki required user registration to begin editing but no email was required to sign up.
Email confirmation became required after the wiki first began dealing with spam attacks as an additional layer of verification. It is also useful for security purposes as sometimes user’s can forget their password and be unable to recover it with no registered email.
This is just another hurdle to go through, and most spambots can bypass email verification so additional tools are also required.
By default, CryGaia Wiki requires CAPTCHAs to be solved in multiple situations in order to prevent spam. These include new user registrations and all edits and contributions. Some users can be given permissions to be exempt from CAPTCHA prompts, like when promoting them to the Editor role.
Currently, the wiki uses google’s reCAPTCHA.
By default, the wiki adds rel=”nofollow” to all external links. This means that external links are provided by users and might potentially contain spam, and should not be used to affect Google search rankings.
This will not stop spammers from posting spam to pages, but it does reduce the incentive to spam as it removes their ability to benefit from increased page ranking.
The wiki has the TorBlock extension installed which blocks all edits coming from Tor exit nodes. This is to discourage and prevent people from using the anonymity Tor provides for vandalism and spam purposes. It makes spam and vandalism much easier to detect and manage.
The wiki has the AntiSpoof extension installed which blocks the creation of accounts with mixed-script, confusing, or similar usernames. Spambots often have confusing, mixed script usernames, and vandals may employ similar tactics in order to confuse administrators. This is a preventative measure so that these types of accounts cannot be created in the first place.
Every spammer is different. This means that there is no one size fits all approach to preventing and dealing with spam attacks. When simple preventative methods are not enough, we have tools available to manage incoming spam and reduce it’s impact, thus making cleanup much easier and quicker to do.
Individual page protection
Many times, specific pages are targeted in spam attacks. Some of the observed patterns in spambot created pagenames include talkpages, especially outside of the main namespace. Some of the most commonly created ones on the wiki are user talk pages.
Blocking edits to specific pages except by certain user groups can be done to prevent the re-creation of pages by spambots. Any page that frequently shows up in Special:Log/delete is a good candidate for protection.
High-traffic or widely used pages such as templates can also be given protection, primarily to prevent vandalism, rather than spam. A good example would be the front page of the wiki, which is the first thing anyone sees when entering the site, and any vandalism or spam directed at it would be extremely disruptive and should be avoided at all costs.
Semi-protected pages are the least restricting when it comes to editing. It restricts editing to all users without the auto-confirmed status. By default, all users are required to confirm their email before being allowed to edit pages.
Auto-confirmation is given based on two additional criteria:
- The account must be at least 1 day old
- The account must have made at least 10 edits
If it’s decided that semi-protection should be implemented for a page, it should first be only for a short duration, such as a few hours, days, or a week depending on the type of page affected and the type of vandalism or spam affecting it. If vandalism or spam continues after protection expires, it can be further extended. Sometimes an administrator might determine that a page should retain it’s protection status indefinitely. This should only be done for the most vandalized articles. Administrators are able and free to lift any indefinite protections as necessary.
There are no explicit rules on the criteria for semi-protection. Administrators should use their best judgement and common sense when deciding if an article should be protected or have it’s status lifted.
Guidelines for semi-protection
- Pages that have been given indefinite semi-protection must have been semi-protected previously. This shows that it is an ongoing problem, and that temporary semi-protection did not have a lasting effect.
- Spam or vandalism that resumes not long after protection is lifted demonstrates that the page in question is a high target for attacks and a good candidate for indefinite protection.
- If spam or vandalism is targeting something about a current event, the semi-protection status should be lifted after the event is over.
- The only way to determine if ongoing protection is necessary is by removing protection and seeing if vandalism/spam returns at previous levels. Indefinitely protected articles can have their status lifted from time to time. The administrator should carefully monitor such pages after removing semi-protection.
Fully protected pages, such as the main page of the wiki, cannot be edited by anyone other than administrators.
It is best to avoid this class of protection unless necessary as it can disrupt the editing of normal contributors. It should only be used for the main page and other pages that affect the entire wiki.
Move protection is a special category of protection that prevents users other than administrators from moving a page.
To protect a page, go to the top bar of the page in question and mouse over “more” to get a drop down menu next to the search bar. Select “protect” to be taken to a confirmation screen where you can choose what type of protection to use. Remember to enter the reason for protection before confirming.
To unprotect a page, do the exact same thing as before to bring up the confirmation screen. Simply check “default” to unprotect the page. Please remember to leave a reason before confirming.
The Abuse Filter extension allows privileged users (usually administrators) to create rules to target the specific types of spam affecting the wiki and automatically prevent the action and block the user. It examines the username, user’s age, the text added, links added, and so on. It is also useful in tackling human-assisted spam, but requires continued maintenance to remain effective against new types of attacks.
To manage filters and see their logs and history, go to Special:AbuseFilter.
Some examples of filters can be found here.
The above method can become quite cumbersome and require a lot of maintenance in the long run. While it is still a very useful tool, it is more efficient and recommended to keep an additional updated blacklist containing known, spamming URLs.
The SpamBlacklist extension creates an on-wiki blacklist that can be modified by administrators. It blocks all edits that contain any of the blacklisted URLs. Users without the permissions to edit the blacklist are welcome to add suggestions to the talk page for it.
The TitleBlacklist extension is also in use and has a similar function. Instead of being based on the content of edits, it acts as a blacklist for titles and page names in specific. It is highly useful in blocking the re-creation of pages often used for spam.
For best practices, when adding or removing anything from the blacklists or whitelists, you should leave a comment to let other users know what this is for.
Useful Links:MediaWiki:Titleblacklist | MediaWiki:Titlewhitelist
Adding new URLs to the spam blacklist can be a confusing procedure for a lot of users, so an extension has been installed that simplifies the process for those who do not or cannot go through the default method.
This extension creates a link on every diff page so that when an editor sees a page has been a victim of spam, they can click “add to Spam”, which then automatically extracts all the URLs the spammer has placed on the page, going over their most recent edits on the article, similar to Rollback. Then, for each URL detected, the tool prompts the user for what degree they want to blacklist the URL.
One of the biggest forms of spam on the site is by the creation of userpages for otherwise non-existent users.
With the extension NoBogusUserPages, the creation of userpages is blocked unless the person creating the userpage has the same username as the page being created.
By default, administrators are able to bypass this restriction.
Removal and hardcore measures
The following are methods for more tech-savvy administrators who know what they are doing. When used improperly that can cause more trouble than they are worth. Please be careful when using any of these and do not be afraid to ask for help, or to refer to the extension’s manual.
This extension creates the page Special:BlockBatch where administrators can block multiple users quickly and easily. Use with care, and always leave a reason.
Administrators can go to Special:Nuke in order to mass delete recently created pages by a user or IP address. Again, please use with care.
It is listed as Mass Delete on Special:SpecialPages.
This extension creates a new page Special:SpamRegex that allows administrators to filter out unwanted links or text. A list of all the currently blocked strings can also be viewed on the same page. Any of the expressions cannot be used in page content, edit summaries, or page move summaries depending on what was chosen by the user who blocked the text or links.
Users are presented with an explanatory message showing which part of their edit was not allowed.
This function is only available to the system administrator who maintains the server, and can not be edited on-site. When turned on, it checks IP Addresses of all edits against one or more DNS-Based blacklists. This requires no maintenance, but has the unfortunate side effect of sometimes having false positives.
Currently, this function is turned off due too many false positives.