wiki on linixtv.org locked
Hi there,
Yesterday a stupid kid vandalized a bunch of pages on the linuxtv wiki and a sysop locked to database to undo the damage.
I would have preferred to undo that damage by simply taking a look at the users contribution page and using the handy-dandy undo function as a mere wiki user.
It would have deprived that individual the satifaction of gaining the sysop's attention with his anti-social behavior, but thats probably a policy decision that is not mine to make.
Anyway .. Now, after about 24h the wiki is still locked. Any reason for that?
cheers
-henrik
Quoted 11 lines · H. Langos
Yesterday a stupid kid vandalized a bunch of pages on the linuxtv wiki and a sysop locked to database to undo the damage.
I would have preferred to undo that damage by simply taking a look at the users contribution page and using the handy-dandy undo function as a mere wiki user.
It would have deprived that individual the satifaction of gaining the sysop's attention with his anti-social behavior, but thats probably a policy decision that is not mine to make.
The damage was done by a bot script and it affected as many pages as the edit rate limiter would allow it to do until I noticed it. If you search for "GRAWP'S MASSIVE" you'll see this is not limited to linuxtv.org.
Quoted 2 lines
Anyway .. Now, after about 24h the wiki is still locked. Any reason for that?
It is locked until I had time to take measures to prevent similar damage from happening again right away. I'm open to suggestions if someone has experience with this.
Johannes
hi johannes,
thank you for your quick reply.
Quoted 9 lines · Johannes Stezenbach
Quoted 3 lines · H. Langos
Yesterday a stupid kid vandalized a bunch of pages on the linuxtv wiki and a sysop locked to database to undo the damage.
...
The damage was done by a bot script and it affected as many pages as the edit rate limiter would allow it to do until I noticed it. If you search for "GRAWP'S MASSIVE" you'll see this is not limited to linuxtv.org.
ah, ok .. so it is a stupid kid with scripting knowledge. :-)
Quoted 6 lines
Quoted 2 lines
Anyway .. Now, after about 24h the wiki is still locked. Any reason for that?
It is locked until I had time to take measures to prevent similar damage from happening again right away. I'm open to suggestions if someone has experience with this.
first of all. please, replace "sigh..." with a more informative locking message.
the next step would be to update the mediwiki software to 1.11.1 if you have $wgEnableAPI = true, that is. (i know it is only a XSS that hits internet explorer users .. but hey, they are people, too ;-)
if i remember right, the linuxtv wiki only allows editing to registered users. therefore you could simply temporarily disable new user registration and enable editing again for registered users.
then i'd suggest installing the reCAPTCHA extention. not only will it prevent bots from registering, you also help to digitize old books.
http://recaptcha.net/plugins/mediawiki/
with that in place you can re-enable new user registration. you can even make logins optional and require captcha solving for anonymous edits. this would probably improve the wiki in general as new users would not jump through yet another loop just in order to help other users... i know, new users can cost more time than they are worth but hope springs eternaly :-)
cheers
-henrik
Quoted 4 lines · H. Langos
the next step would be to update the mediwiki software to 1.11.1 if you have $wgEnableAPI = true, that is. (i know it is only a XSS that hits internet explorer users .. but hey, they are people, too ;-)
I will update to 1.14.0. This is the current version, and it is also used by wiki.kernel.org (there is a secret plan to eventually move the wiki there). And all the shiny new anti-spam extensions don't seem to work with 1.11 anymore...
Quoted 3 lines
if i remember right, the linuxtv wiki only allows editing to registered users. therefore you could simply temporarily disable new user registration and enable editing again for registered users.
I will do the update first.
Quoted 4 lines
then i'd suggest installing the reCAPTCHA extention. not only will it prevent bots from registering, you also help to digitize old books.
Looked at that and noticed they don't provide any statement regarding confidentiality / data protection. Who knows if they aren't creating a huge database of who did what in Wikis and Blogs around the net...
Besides that, this wouldn't have stopped the present attack since the bot used does a manual login assisted by a human user. To thwart that I'd have to enable the captcha for every page save...
Johannes
Quoted 10 lines · Johannes Stezenbach
Quoted 4 lines · H. Langos
the next step would be to update the mediwiki software to 1.11.1 if you have $wgEnableAPI = true, that is. (i know it is only a XSS that hits internet explorer users .. but hey, they are people, too ;-)
I will update to 1.14.0. This is the current version, and it is also used by wiki.kernel.org (there is a secret plan to eventually move the wiki there). And all the shiny new anti-spam extensions don't seem to work with 1.11 anymore...
reCAPTCHA seems to work with anything newer than 1.7.
Quoted 9 lines
Quoted 3 lines
if i remember right, the linuxtv wiki only allows editing to registered users. therefore you could simply temporarily disable new user registration and enable editing again for registered users.
I will do the update first.
Quoted 3 lines
then i'd suggest installing the reCAPTCHA extention. not only will it prevent bots from registering, you also help to digitize old books.
Quoted 6 lines
Quoted 1 line
Looked at that and noticed they don't provide any statement regarding confidentiality / data protection. Who knows if they aren't creating a huge database of who did what in Wikis and Blogs around the net...
I'd rather take a look at the code to see what kind of data is sent off-site. My guess is that there isn't any identification data involved at all. but you are right. they could add that to their faq.
OTAH they are a university project and probably didn't approach the whole thing with sufficient paranoia to think about such a question ;-)
Quoted 3 lines
Besides that, this wouldn't have stopped the present attack since the bot used does a manual login assisted by a human user. To thwart that I'd have to enable the captcha for every page save...
hmm, manualy asisted bots are nasty. but maybe there is a way to lower the limit of edits that can be done automatically. maybe a soft limit that would trigger captcha usage way before hitting the hard limit that stoped the bot this time....
cheers
-henrik
Quoted 8 lines · H. Langos
Quoted 7 lines · Johannes Stezenbach
Quoted 4 lines · H. Langos
if i remember right, the linuxtv wiki only allows editing to registered users. therefore you could simply temporarily disable new user registration and enable editing again for registered users.
I will do the update first.
...and of course I ran into problems when updating the extensions, and then ran out of time. So for the moment I followed your suggestion and enabled editing but disabled account creation.
Johannes
Quoted 8 lines · Johannes Stezenbach
Quoted 7 lines · H. Langos
Quoted 6 lines · Johannes Stezenbach
Quoted 4 lines · H. Langos
if i remember right, the linuxtv wiki only allows editing to registered users. therefore you could simply temporarily disable new user registration and enable editing again for registered users.
Quoted 5 lines
Quoted 1 line
Quoted 1 line
I will do the update first.
...and of course I ran into problems when updating the extensions, and then ran out of time. So for the moment I followed your suggestion and enabled editing but disabled account creation.
Thank you very much!
I already started working again.
cheers
-henrik
BTW: Is there a namespace for experiments? Something equivalent to the Sandbox web in TWiki ? ( A single page will not do as I need to test templates/includes )