Some more thoughts on this Wiki-sabotage problem....
So, the dust seems to have settled from that last batch of spamming. I've got everything recovered, I think.... (Except for the pages that need deleting.) Thus, a few thoughts: It occurs to me that the reason my "URGENT" emails haven't had any response from the Wiki administrators is that you're all in Europe, and probably in bed asleep right now! Thus: Would it be useful to give me administrative privileges on the Wiki, so that I could do damage control if something like this arises again at this sort of hour? What, other than firefighting, is the right way to deal with this in the future? This particular attack consisted of (to date) three different waves of about 50 edits each; most of these came from a logged-in user, so I can't tell what IP addresses were being used, but a number of the edits weren't logged in. Those edits came, nearly simultaneously, from several dozen different IP addresses, with only one or two from each -- clearly, blocking by IP address is not going to solve the problem. Incidentally, from that (and the actual character of the edits), I'm fairly sure that what's going on is not a real user making the edits, but a series of bots on a number of compromised computers. I seriously doubt the intent is sabotage as such; the intent appears to be to add invisible links to the end of the Wiki pages, and the text-deletion seems merely a side-effect of very badly-programmed bots. - Brooks
Hello out there,
It occurs to me that the reason my "URGENT" emails haven't had any response from the Wiki administrators is that you're all in Europe, and probably in bed asleep right now!
Well, not quite. I didn't respond, because I came back from a party, and I promised not to write _any_ email after a party... But as you have seen, I have tried to revert some changes (but obviously missed some that you fixed).
What, other than firefighting, is the right way to deal with this in the future?
When I woke up this morning, I thought that I can just reinstall a database backup from the day before the attack started. This would make any of our reverting lost, but also the spam. Was there any 'good' change in the wiki since the last few days? I guess, no.
be to add invisible links to the end of the Wiki pages, and the text-deletion seems merely a side-effect of very badly-programmed bots.
Actually, I think that the page deletion is part of the game. I have no clue what to do with the spamming. So far it was quite ok to remove the spamming by hand. But this is beyond manual work that can be done in a minute or two. I could make only logged-in users change pages and validate the email address or approve new users by hand. But this, IMO, violates the principal that makes the wiki so efficient. I'll (try to) update the mediawiki software today and let's see what it can do. I'll come back to you, Brooks. Patrick -- ConTeXt wiki and more: http://contextgarden.net
Hello, Patrick! At 02:15 AM 10/10/2005, Patrick Gundlach wrote:
What, other than firefighting, is the right way to deal with this in the future?
When I woke up this morning, I thought that I can just reinstall a database backup from the day before the attack started. This would make any of our reverting lost, but also the spam. Was there any 'good' change in the wiki since the last few days? I guess, no.
That seems like a good idea, indeed. Here's what I found for "good" changes: I made a tiny typo correction on the Installation Hints page (a period after the 2004 in the "General Hints" section.) On Oct. 6, an anonymous user (80.117.100.56) changed the Typescripts page to add "[gentium]" to the first \typescripts line in the first example of each section, making them % load mapfile \starttypescript [map] [gentium] [\defaultencoding] \loadmapfile [\defaultencoding-sil-gentium.map] and % and then use that data within the typescript: \starttypescript [map] [gentium] [ec,texnansi,8r,t5,t2a,t2b,qx] \loadmapfile [\typescripttwo-sil-gentium.map] Other than those -- which will be easy to put back if needed -- the most recent "real" change was Taco's extra information on User:Taco/Bib on September 30th.
be to add invisible links to the end of the Wiki pages, and the text-deletion seems merely a side-effect of very badly-programmed bots.
Actually, I think that the page deletion is part of the game. I have no clue what to do with the spamming. So far it was quite ok to remove the spamming by hand. But this is beyond manual work that can be done in a minute or two. I could make only logged-in users change pages and validate the email address or approve new users by hand. But this, IMO, violates the principal that makes the wiki so efficient.
Indeed; I agree. I'm pretty sure that this could have been blocked after the fact if we had the ability to block on certain bits of text in the edit -- for instance, nearly all of these edits were adding a "<div>" tag, so blocking text containing "<div>" tags would probably have stopped it. (Ideally, we'd do the blocking after the text gets wikified, so that any "<div>" tags in code blocks get converted to "%lt;div>" and thus not blocked....) Incidentally, if you do a Google search on the bits of text that this spammer is including ("WTHPD1"), you'll find thousands of other Wikis that have identical additions. - Brooks
Brooks Moses wrote:
So, the dust seems to have settled from that last batch of spamming. I've got everything recovered, I think.... (Except for the pages that need deleting.)
Thus, a few thoughts:
It occurs to me that the reason my "URGENT" emails haven't had any response from the Wiki administrators is that you're all in Europe, and probably in bed asleep right now! Thus: Would it be useful to give me administrative privileges on the Wiki, so that I could do damage control if something like this arises again at this sort of hour?
sounds ok to me
What, other than firefighting, is the right way to deal with this in the future? This particular attack consisted of (to date) three different waves of about 50 edits each; most of these came from a logged-in user, so I can't tell what IP addresses were being used, but a number of the edits weren't logged in. Those edits came, nearly simultaneously, from several dozen different IP addresses, with only one or two from each -- clearly, blocking by IP address is not going to solve the problem.
hm, a pitty
Incidentally, from that (and the actual character of the edits), I'm fairly sure that what's going on is not a real user making the edits, but a series of bots on a number of compromised computers. I seriously doubt the intent is sabotage as such; the intent appears to be to add invisible links to the end of the Wiki pages, and the text-deletion seems merely a side-effect of very badly-programmed bots.
maybe wiki's need some spam testing features; maybe an option is to use different internal tags (id in html pages) for the edit buttons and such so that bots cannot trigger the right sequences Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (3)
-
Brooks Moses -
Hans Hagen -
Patrick Gundlach