I doubt all these new registered users are real

[anonymous]

This is likely a bot working. Statistically, we had 1 or 2 new users per day. The register pattern is often very similar.

[Ryan J Ollos]

Maybe there are some things we can tweak with the SpamFilterPlugin. Started seeing many registered users at ​http://issues.apache.org/bloodhound around the same time, but quantity has been much higher there, possibly due to not running SpamFilterPlugin.

[Dirk Stöcker]

The created accounts are a small percentage of the real number of accounts tried to create. So spamfilter is working fine. Seems some spammer has new scripts, which try massive Trac account creating to improve spam throughput. Not much which can be done against this except removing the things getting through and waiting for the end.

I'll check and delete any account which also tried sending spam. The others will vanish when we cleanup unused accounts after some time.

but quantity has been much higher there, possibly due to not running SpamFilterPlugin.

Operating an openly available Trac instance without spamfilter is brave.

Closing as "fixed" as there is no "is monitored always" option.

[falkb]

Is the Captcha barrier always on?

[Dirk Stöcker]

Replying to falkb:

Is the Captcha barrier always on?

Yes/No. It comes up when minimum score is not reached. The spammer probably uses an auto-captcha solving server to skip this or sometimes there is not enough content to detect spam/ham. Detecting broken registering is very hard. Maybe minimum score should be adaptable for this, so it has some harder score than normal submissions.

[falkb]

Maybe they have reached the minimum score in the registered cases. Are you able to check that in the logging? What about always calling the captcha as finish of the registration? I wonder what advantage it brings to register a ghost account here. Maybe they just do a captcha cracking training on trac-hacks.org., this would make a little sense.

[Dirk Stöcker]

Replying to falkb:

Maybe they have reached the minimum score in the registered cases. Are you able to check that in the logging?

I'm doing so, but trac-hacks is relatively slow compared to other instances I run, so getting rid of the uninteresting entries (something like 10.000 a day) takes some time.

What about always calling the captcha as finish of the registration?

That's what I meant by adapting score for registering. Currently there is only one score for all types of transmissions.

I wonder what advantage it brings to register a ghost account here.

That's not the goal. Goal is to add spam tickets or wiki entries. But even when registered the SPAM is hard to get through and very seldom succeeds and in these cases is removed very fast by operators, so the only thing you see are account creations. That's specific to trac-hacks due to auto-generated home-page.

[Dirk Stöcker]

I updated the spamfilter plugin a bit, which may improve the performance, as now BlogSpam works again and some checks find the spammers who are so dumb to add HTTP links in registering process.

Also training should be a bit faster now, as the 2 dead services are gone.

@jun66j5: Training the spam entries (i.e. First click "Delete >90%) and then train remaining ones would be more effective than constantly updating the BadContent page.

[Dirk Stöcker]

A short note about the spam dimension at trac-hacks.org:

Since 17.05.2014:

• 709 870 submissions
• 99.7% Spam (0.3% Ham)
• 93.7% tests solved local (i.e. without remote assistance)

What comes through really is only a very small tip of the iceberg. :-)

[Ryan J Ollos]

Situation seems to have improved over past several days.

See also #11742.

[anonymous]

Awesome, Ryan. I wished there was a "traceroute back and imprison" mechanism...