[gschaider]

Originally Posted by wyldckat

Hi Bernhard,

About the problem with the spammer registrations - have you thought/checked the option of using something similar to this: http://www.paraview.org/Wiki/Special:RequestAccount !?

I want to keep the threshold for new contributors as low as possible. And if nobody approves the new accounts for 3 days my guess is that at least 34.76% of the people won't write what they originally wanted (BTW: did you know that 43% of all statistics used in an argument are made up)

What puzzles me about these accounts is that they got past the "security question" but never created any spam content (for which the same questions are used)

Originally Posted by wyldckat

As for the emails for confirmation, maybe it's due to something similar to this: http://www.cfd-online.com/Forums/sit...tml#post303417 post #6

I THINK the problem is that there currently is no reverse DNS lookup for the server. I will address that problem once the domain is registered with the new provider

[wyldckat]

Originally Posted by gschaider

What puzzles me about these accounts is that they got past the "security question" but never created any spam content (for which the same questions are used)

This happened with the comment system on our company's website. Somehow the spammers got through the custom captcha system, and somehow sent HTML based POST packages directly to the php comment script. But since there was a second layer of security (admin approval), they gave up after a couple of days.
Therefore, the issue might be on the final PHP script that handles the registration, which should require checking the captcha cookie as well...

[wyldckat]

Hi Bernhard,

Yesterday there was a big inflow on new users, mostly dummy ones.

I've been reading up on this subject and ended up with the following conclusions:

• This kind of question protection system should update its question list every once in a while, to keep trained bots away.
• "Hot pot" method of using a hidden second question can lead automated bots astray, since the second question isn't meant to be answered. But this isn't full proof neither.
• Since dummy users only register, it's possible that these are being used as a public form of indicating that a particular attack bot is up and running in a infected host.
  Additionally, yesterdays surplus can indicate that either the number of bots that infiltrate/attack has grown, or that other public areas have been closed and bots have been diverted to the existing pool of bulletin boards.
• An allegedly good way of keeping these kinds of dummy users at bay is with this extension: http://www.mediawiki.org/wiki/Extension:TitleBlacklist

There are a few wikis out there that (try to) explain how they are keeping spammers away for good... but the last one I remembered about, I went back to check and that one has apparently decided to switch to human based checking. It is this one: http://www.cookipedia.co.uk/recipes_...on_a_MediaWiki

Best regards,
Bruno

[wyldckat]

Note: I'm at this moment doing some adjustments to how version templates are created in openfoamwiki.net. I hope to have this resolved in the next 10-20 minutes...

edit: Problem solved, I think...

[gschaider]

Originally Posted by wyldckat

Hi Bernhard,

Yesterday there was a big inflow on new users, mostly dummy ones.

I've been reading up on this subject and ended up with the following conclusions:

• This kind of question protection system should update its question list every once in a while, to keep trained bots away.
• "Hot pot" method of using a hidden second question can lead automated bots astray, since the second question isn't meant to be answered. But this isn't full proof neither.
• Since dummy users only register, it's possible that these are being used as a public form of indicating that a particular attack bot is up and running in a infected host.
  Additionally, yesterdays surplus can indicate that either the number of bots that infiltrate/attack has grown, or that other public areas have been closed and bots have been diverted to the existing pool of bulletin boards.
• An allegedly good way of keeping these kinds of dummy users at bay is with this extension: http://www.mediawiki.org/wiki/Extension:TitleBlacklist

There are a few wikis out there that (try to) explain how they are keeping spammers away for good... but the last one I remembered about, I went back to check and that one has apparently decided to switch to human based checking. It is this one: http://www.cookipedia.co.uk/recipes_...on_a_MediaWiki

Best regards,
Bruno

Thanks. I'm back from vacation and will look into the matter. I had a look at the IPs the bot-accounts originate from (with http://www.mediawiki.org/wiki/Extension:CheckUser) and it seems I would have to Blacklist half china to get rid of them (they always use different IPs)

The title blacklist-extension is not an option I'm afraid. I can't think of a regexp that would block these false users and not leggit users.

[wyldckat]

Well, this isn't exactly a solution, but this old cartoon I know of came to mind just know: http://xkcd.com/810/

[gschaider]

Originally Posted by wyldckat

Well, this isn't exactly a solution, but this old cartoon I know of came to mind just know: http://xkcd.com/810/

It is possible that the invasion of illegal users was made possible by the last upgrade and an attempt to make the configuration better. Seems that I switched off
http://bad-behavior.ioerror.us/suppo...ion/mediawiki/

(Fun fact: did you know that "$IP" is not the same as '$IP' in PHP. Damn. I hate that 'language')

Whether this was the case: if there are no new users in the next 24h this would prove two things:
a) I should forbid my emacs to open any files ending with .php
b) BadBehaviour is working well

About xkcd: it is used in the documentation of real programming languages. You don't have to scroll too far down on http://docs.python.org/library/sqlite3.html

[wyldckat]

Originally Posted by gschaider

Whether this was the case: if there are no new users in the next 24h this would prove two things:
a) I should forbid my emacs to open any files ending with .php
b) BadBehaviour is working well

Either BadBehaviour is still not properly configured, or these spammers are using normal browsers. Nowadays it's pretty simple to create a plug-in for Firefox and other browsers, so I think it would be rather easy to create one that fools BadBehaviour At least by the description I read on the official site.

Originally Posted by gschaider

About xkcd: it is used in the documentation of real programming languages. You don't have to scroll too far down on http://docs.python.org/library/sqlite3.html

I didn't remember this one... niiiice

[gschaider]

Originally Posted by wyldckat

Either BadBehaviour is still not properly configured, or these spammers are using normal browsers. Nowadays it's pretty simple to create a plug-in for Firefox and other browsers, so I think it would be rather easy to create one that fools BadBehaviour At least by the description I read on the official site.

I noticed.

I'll keep it in and update it regularly (BB adapted quite well in the past).

Add some other things too but will avoid any threshold for leggit new users

[gschaider]

Originally Posted by gschaider

I noticed.

I'll keep it in and update it regularly (BB adapted quite well in the past).

Add some other things too but will avoid any threshold for leggit new users

For those interested: added two blacklist-services. Since then the number of bogus users per day dropped from 10+ to 2-4.

I checked with a dummy account: the user shows up on the RecentChanges as soon as he creates the account. But this doesn't mean that he confirmed his eMail and thus can't edit the pages. I found no easy way to check whether these users confirmed their EMail (without inspecting the database). For the time being I assume that they're not confirmed and all is well (I can live with a low single-digit number of bogus users per day)

[gschaider]

Originally Posted by gschaider

For those interested: added two blacklist-services. Since then the number of bogus users per day dropped from 10+ to 2-4.

I checked with a dummy account: the user shows up on the RecentChanges as soon as he creates the account. But this doesn't mean that he confirmed his eMail and thus can't edit the pages. I found no easy way to check whether these users confirmed their EMail (without inspecting the database). For the time being I assume that they're not confirmed and all is well (I can live with a low single-digit number of bogus users per day)

Those bogus users still get created. I'm finished with all measures that do not involve manually verifying users (and I don't want to do that as I want to keep the threshold for new users low).

Not sure how many people are really bothered by these bogus users populating the "Recent Changes"

[ngj]

Hi Bernhard,

I only have friendly changes on the Wiki-page, which I "run".

Have a nice weekend

Niels

[wyldckat]

Greetings to all!

Originally Posted by gschaider

Those bogus users still get created. I'm finished with all measures that do not involve manually verifying users (and I don't want to do that as I want to keep the threshold for new users low).

Not sure how many people are really bothered by these bogus users populating the "Recent Changes"

Well... I keep track of changes using an RSS reader... which gets a bit annoying at times to have to delete the dummy posts from the RSS reader...

Anyway, I forgot to mention this before, but by what I've seen, Bad Behaviour seems to be acting like it has Alzheimer's or something like that!
I say this because there have been days where only one or two dummy users appeared and it seemed to be because at least two real wiki users edited pages! For a single day, Bad Behaviour could tell apart between good guys and bad guys! As soon as a new day starts (or 24h goes by), there they come again...

Best regards,
Bruno

[gschaider]

Originally Posted by wyldckat

Greetings to all!


Well... I keep track of changes using an RSS reader... which gets a bit annoying at times to have to delete the dummy posts from the RSS reader...

Anyway, I forgot to mention this before, but by what I've seen, Bad Behaviour seems to be acting like it has Alzheimer's or something like that!
I say this because there have been days where only one or two dummy users appeared and it seemed to be because at least two real wiki users edited pages! For a single day, Bad Behaviour could tell apart between good guys and bad guys! As soon as a new day starts (or 24h goes by), there they come again...

Best regards,
Bruno

That would of course assume that there is always the same number of attempts at the site each day. Which I'm not sure if there is.

Anyway. It is not only Bad Behaviour. There are also two blacklist extensions (Project Honeypot and another). The question you all love. SimpleAntiSpam-extension. And a couple of settings that should make the bots slower. (only thing I haven't tried is http://www.mediawiki.org/wiki/Extension:AntiBot)

I once had a look at the pseudo-users and their IPs they came from. Never saw an IP twice (not even similar). The only thing that would block most of them would not allowing any connections from China. But that would be a bit extreme I think

Only way to clean the "Recent Changes"-history would be to regularily use the "Merge and Delete Users"-extension to "merge away" the dummy-users. But that would have to be done 24/7 ...

As long as the users are created but they can not edit it is not that bad. And as I said above: if people have to wait for a manual confirmation to register I'd think "that the terrorists won"

[akidess]

Originally Posted by gschaider

Not sure how many people are really bothered by these bogus users populating the "Recent Changes"

I have the same issue as Bruno with the RSS reader. Is there a setting to hide user creations from Recent Changes?

[gschaider]

Originally Posted by akidess

I have the same issue as Bruno with the RSS reader. Is there a setting to hide user creations from Recent Changes?

I'll look around whether there is an extension similar to http://www.mediawiki.org/wiki/Extens...tRecentChanges that produces a cruft-free RSS

[gschaider]

Originally Posted by gschaider

I'll look around whether there is an extension similar to http://www.mediawiki.org/wiki/Extens...tRecentChanges that produces a cruft-free RSS

OK. This doesn't work (my MySQL is too new for this extension). But I installed another extension (http://www.mediawiki.org/wiki/Extension:News) that has the latest changes http://openfoamwiki.net/index.php/Changes and can be accessed via an RSS-feed http://openfoamwiki.net/index.php?ti...anges&feed=rss (no user additions)

Don't know if with some template-trickery this can be made to look similar to RecentChanges (With new/type/old_len/new_len/minor described in http://www.mediawiki.org/wiki/Extension:News#Parameters) or at least be a bit more informative about the type of change done. I'll see whether the community of RSS-users (I'm looking in no particular direction, Anton) improves the feed. Then I'll write lock it and put a reference to it on the front page

[akidess]

I like it, thanks for your efforts Bernhard! I played around a bit with the parameters, but I think you already found the optimal setup.

- Anton

[wyldckat]

Bernhard, I know that Perfect is the enemy of good, but I wonder if the bots would stop registering dummy users if the "Special:RecentChanges" page was now disabled...

[gschaider]

Originally Posted by akidess

I like it, thanks for your efforts Bernhard! I played around a bit with the parameters, but I think you already found the optimal setup.

Well I improved it a bit (using an extension that I installed some time ago) to distinguish between edits and other changes