Hi all, This is my first contribution, I have a few queries and I hope somebody can help me find the solutions or information I need.
Problem: I have a mediawiki running on a hosted web server ( ie not on my own computer ) which is being repeatedly spammed by a bot or bots which not only edits multiple pages inserting hundreds of porn links and so on, but also creates lots of new pages and talk pages.
according to the version page, the wiki is running on
MediaWiki (http://wikipedia.sf.net/): 1.3.5 PHP (http://www.php.net/): 4.3.10 (apache) MySQL (http://www.mysql.com/): 4.0.24-standard-log
I can access the database using phpMyAdmin 2.6.3
The spammer(s) use IP addresses which vary, but always begin with 69.50.
So what I can do for now, after a spam attack, is to log in as WikiSysop, block the individual IP number, go through reverting all the pages and deleting the newly created ones. Then I go to the phpMyAdmin page and run a few stored scripts which delete all the unwanted edits from both 'old' and 'recentchanges' , empty archive , and then the database is back to normal without expanding unmanageably.
My main question is :
How can I block the entire range of IP addresses like 69.50.* ??
Any help much appreciated, as I am determined to try and keep this wiki open to all and not concede to the spambots.
you could: 1. enable blocking of ip blocks (see defaultsettings.php) then block 69.50.0.0/16
2. change your settings to only allow people who are logged in to edit
3. run a wiki bot, give that bot the ability to block suspected spammers (this is what i do)
The first will only help for a short while, there are many spammers, with all the wiki-mania going on on the web spammers see a great opertunity to increase their google rank
the second works pretty well (there are a few bots that get through, but no plan is perfect), but for a wiki that is starting out i concider this an early death to the wiki unless you already have a good readership and editorship
the 3rd works, but there are no public bots specifically made for this that i know of off hand, I am currently building mine by hand and will be releaseing it to the public when i feel its ready, if you want a preview copy .. mail me and i'll see what i can do (my current version is very rudimentary but blocks 95% of spammers, it still dosent auto revert)
Mike Valstar http://gentoo-wiki.com
Andy Roberts wrote:
Hi all, This is my first contribution, I have a few queries and I hope somebody can help me find the solutions or information I need.
Problem: I have a mediawiki running on a hosted web server ( ie not on my own computer ) which is being repeatedly spammed by a bot or bots which not only edits multiple pages inserting hundreds of porn links and so on, but also creates lots of new pages and talk pages.
according to the version page, the wiki is running on
MediaWiki (http://wikipedia.sf.net/): 1.3.5 PHP (http://www.php.net/): 4.3.10 (apache) MySQL (http://www.mysql.com/): 4.0.24-standard-log
I can access the database using phpMyAdmin 2.6.3
The spammer(s) use IP addresses which vary, but always begin with 69.50.
So what I can do for now, after a spam attack, is to log in as WikiSysop, block the individual IP number, go through reverting all the pages and deleting the newly created ones. Then I go to the phpMyAdmin page and run a few stored scripts which delete all the unwanted edits from both 'old' and 'recentchanges' , empty archive , and then the database is back to normal without expanding unmanageably.
My main question is :
How can I block the entire range of IP addresses like 69.50.* ??
Any help much appreciated, as I am determined to try and keep this wiki open to all and not concede to the spambots.
Thanks for the prompt reply, Mike.
With your information I googled for "defaultsettings.php" and found it in the 'includes' directory. I then copied the line
$wgSysopRangeBans = false; # Allow sysops to ban IP ranges
to my localsettings.php file and changed false to true.
This then enabled me to block 69.50.0.0/16 which I hope will get me over one longstanding and persistent problem.
I shall remain susbscribed to this helpful mailing list in order to keep up with developments in the forthcoming struggles against spambots, particularly if some kind of shared blacklist or bot detection strategy evolves.
Thanks again for the help.
Andy Roberts http://blog.ultralab.net/~blogger/andy/ http://www.ukcider.co.uk
On 9/2/05, Mike Valstar mikevalstar@gentoo-wiki.com wrote:
you could:
- enable blocking of ip blocks (see defaultsettings.php) then block
69.50.0.0/16
change your settings to only allow people who are logged in to edit
run a wiki bot, give that bot the ability to block suspected spammers
(this is what i do)
The first will only help for a short while, there are many spammers, with all the wiki-mania going on on the web spammers see a great opertunity to increase their google rank
the second works pretty well (there are a few bots that get through, but no plan is perfect), but for a wiki that is starting out i concider this an early death to the wiki unless you already have a good readership and editorship
the 3rd works, but there are no public bots specifically made for this that i know of off hand, I am currently building mine by hand and will be releaseing it to the public when i feel its ready, if you want a preview copy .. mail me and i'll see what i can do (my current version is very rudimentary but blocks 95% of spammers, it still dosent auto revert)
Mike Valstar http://gentoo-wiki.com
Andy Roberts wrote:
Hi all, This is my first contribution, I have a few queries and I hope somebody can help me find the solutions or information I need.
Problem: I have a mediawiki running on a hosted web server ( ie not on my own computer ) which is being repeatedly spammed by a bot or bots which not only edits multiple pages inserting hundreds of porn links and so on, but also creates lots of new pages and talk pages.
according to the version page, the wiki is running on
MediaWiki (http://wikipedia.sf.net/): 1.3.5 PHP (http://www.php.net/): 4.3.10 (apache) MySQL (http://www.mysql.com/): 4.0.24-standard-log
I can access the database using phpMyAdmin 2.6.3
The spammer(s) use IP addresses which vary, but always begin with 69.50.
So what I can do for now, after a spam attack, is to log in as WikiSysop, block the individual IP number, go through reverting all the pages and deleting the newly created ones. Then I go to the phpMyAdmin page and run a few stored scripts which delete all the unwanted edits from both 'old' and 'recentchanges' , empty archive , and then the database is back to normal without expanding unmanageably.
My main question is :
How can I block the entire range of IP addresses like 69.50.* ??
Any help much appreciated, as I am determined to try and keep this wiki open to all and not concede to the spambots.
MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
What about developing a Turing's test? like those images of words in Slashdot. they work, doesn't it?
It could be a little boring if you have to put the word/number every time you record the changes, but I think it is interesting
What about developing a Turing's test? like those images of words in Slashdot. they work, doesn't it?
Not anymore. There are already bots that can defeat CAPTCHA.
On 9/2/05, Morbus Iff morbus@disobey.com wrote:
What about developing a Turing's test? like those images of words in Slashdot. they work, doesn't it?
Not anymore. There are already bots that can defeat CAPTCHA.
They're also controversial in that they are problematical to handicapped humans who might not be able to decipher them even with mechanical aids.
I recently ran across a paper on the problem which put the shoe on the other foot by showing a captcha which asked you to decode a word which seemed to be encoded in Braille.
On 9/2/05, Andy Roberts aroberts@gmail.com wrote:
Thanks for the prompt reply, Mike.
With your information I googled for "defaultsettings.php" and found it in the 'includes' directory. I then copied the line
$wgSysopRangeBans = false; # Allow sysops to ban IP ranges
to my localsettings.php file and changed false to true.
This then enabled me to block 69.50.0.0/16 which I hope will get me over one longstanding and persistent problem.
I shall remain susbscribed to this helpful mailing list in order to keep up with developments in the forthcoming struggles against spambots, particularly if some kind of shared blacklist or bot detection strategy evolves.
Consider
http://meta.wikimedia.org/wiki/SpamBlacklist_extension
This blacklists the payloads rather than the carriers. In other words it checks for urls which wikispammers try to insert into articles and prevents them from saving the page.
I've found it quite effective, particularly when using a listed based on that kept by chongqed.org
On 9/3/05, Rick DeNatale rick.denatale@gmail.com wrote:
Consider
http://meta.wikimedia.org/wiki/SpamBlacklist_extension
This blacklists the payloads rather than the carriers. In other words it checks for urls which wikispammers try to insert into articles and prevents them from saving the page.
I've found it quite effective, particularly when using a listed based on that kept by chongqed.org
Thanks, this method looks ideal in some ways.
Unfortunately it says "reportedly requires Mediawiki version 1.4.1 or greater" and I'm running 1.3.5 so I will have to investigate what is required to upgrade first.
I had a feeling this might end up as my second question:
Can the mediawiki database be retained as it is when installing a new version of the mediawiki software or does the whole thing need to be exported and re-imported afterwards somehow?
Andy Roberts wrote:
Can the mediawiki database be retained as it is when installing a new version of the mediawiki software or does the whole thing need to be exported and re-imported afterwards somehow?
You must surely backup your database first!
After that, just be sure to install MediaWiki with the /config script, and point it to your current database. 1.4.9 or 1.5rc4 installers should upgrade you to the newest db schema (which is different for 1.4.x and 1.5.x).
You'll probably want to merge your old LocalSettings.php customization into the new one generated by the installer manually. I don't remember any major differences from 1.3.x to 1.4.x for that.
Good luck. :)
Hínandil
Maybe we could use rate control to reduce spam. phpBB has a similar control I believe. I don't know how effective these schemes are but it might help ease the pain of reverting everything back. This probably requires a new table with ip addresses/user-ids and the time of last update. Whenever a new update is submitted: . check the time of previous update attempt if exists in the table from this user or ip . if the time between these two requests is too short, show a warning that the user has to wait a minute or whatever to send a new update
How long the program should wait can be determined empirically. It should be made sure that whenever a warning is shown, user's contributions are not lost. it would be really frustrating to lose it because of a stupid software thinking you're a bot. And this table can be cleared periodically, say every hour, to remove old records.
Mike Valstar wrote:
you could:
- enable blocking of ip blocks (see defaultsettings.php) then block
69.50.0.0/16
change your settings to only allow people who are logged in to edit
run a wiki bot, give that bot the ability to block suspected spammers
(this is what i do)
The first will only help for a short while, there are many spammers, with all the wiki-mania going on on the web spammers see a great opertunity to increase their google rank
the second works pretty well (there are a few bots that get through, but no plan is perfect), but for a wiki that is starting out i concider this an early death to the wiki unless you already have a good readership and editorship
the 3rd works, but there are no public bots specifically made for this that i know of off hand, I am currently building mine by hand and will be releaseing it to the public when i feel its ready, if you want a preview copy .. mail me and i'll see what i can do (my current version is very rudimentary but blocks 95% of spammers, it still dosent auto revert)
Mike Valstar http://gentoo-wiki.com
Andy Roberts wrote:
Hi all, This is my first contribution, I have a few queries and I hope somebody can help me find the solutions or information I need.
Problem: I have a mediawiki running on a hosted web server ( ie not on my own computer ) which is being repeatedly spammed by a bot or bots which not only edits multiple pages inserting hundreds of porn links and so on, but also creates lots of new pages and talk pages.
according to the version page, the wiki is running on MediaWiki (http://wikipedia.sf.net/): 1.3.5 PHP (http://www.php.net/): 4.3.10 (apache) MySQL (http://www.mysql.com/): 4.0.24-standard-log
I can access the database using phpMyAdmin 2.6.3
The spammer(s) use IP addresses which vary, but always begin with 69.50. So what I can do for now, after a spam attack, is to log in as WikiSysop, block the individual IP number, go through reverting all the pages and deleting the newly created ones. Then I go to the phpMyAdmin page and run a few stored scripts which delete all the unwanted edits from both 'old' and 'recentchanges' , empty archive , and then the database is back to normal without expanding unmanageably.
My main question is :
How can I block the entire range of IP addresses like 69.50.* ??
Any help much appreciated, as I am determined to try and keep this wiki open to all and not concede to the spambots.
MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
The most heavy solution would be to force edits by logged in users and have a user only creatable by an administrator.
There have also been some nice hacks floating about to allow anonymous edits only to talk pages. I rather like the combination of these ideas for the beginnings of spam prevention.
Then denying the wholesale dump of links into talk pages via some other spam prevention mechanism.
Also, it would be nice to rewrite talk pages into a folder and tell google via robots.txt not to rank anything in that folder.
But all of this just adds layers upon layers of complexity.. =/
mediawiki-l@lists.wikimedia.org