Slawomir:
Can you please post the code diffs for the changes you describe?
Thanks -- David
On 11/14/2016 8:09 AM, TJM wrote:
Hello,
I've been dealing with huge amounts of spam accounts for the past few months,
averaging at 500k or more registration attempts weekly. My project was hit by some
kind
of large botnet. I had to modify lots of things but currently it looks like I'm
winning the battle.
Here's what I did + some thoughts:
1. Inactive, empty accounts *will* wake up in the future to post spam.
Before they started creating fake teams full of links, I had already like 20k+ of
them,
some were registered more than a year ago (!)
I have deleted tons of them, mostly by checking their emails against StopForumSpam
database,
yet still there are leftovers that wake up every now and then.
2. I added a requirement to have a host attached before the user can create
team.
This immediately stopped like 99,99% of the spam. I had the profile RAC/credits
requirement
earlier.
Now I'm going to change it to require at least 1 credit, with an explanation and
contact info
for users without credits who want to create team for some reason. To override my
filter,
I use 'email_validated' db field to manually verify accounts if someone asks to.
Every attempt to create a team without meeting the requirements is logged, the web
form actually
accepts the data so I have something to report back to StopForumSpam. Every now
and then
I'm checking the log, which has a nice "report to SFS" and "delete account"
buttons next to each user name.
3. reCaptcha doesn't work for me at all. The only difference between having it
enabled/disabled
is the number of requests made to create an account, somehow they pass through
with failure to
success ratio of ~10:1. I had reCatpcha enabled all the time and even recently
updated to the lastest API,
which didn't help at all.
4. All registration attempts go through StopForumSpam API. It actually works very
well, many of the spammers
slip through the IP filter but then fail email address check which is the most
important IMO.
On average, for me it stops more than 95% of the registrations, but it heavily
depends on email domain used
- some are trying to register account with email domain that is flagged as 'toxic'
and then no one will
go through; another spam wave may use something like hotmail and then it will be
accepted if it's not (yet) listed.
5. I have a background daemon that randomly picks up empty (no hosts) accounts
from the db and checks
their email_addr against SFS. This will be changed because now they're smarter and
they make accounts with fake hosts.
Sooner or later this script kills almost all accounts that slipped through
registration because their data was not listed
on SFS during registration.
On deletion, it removes account, forum posts, profile and team(s) (only if it has
0 total_credits). It is not uncommon
to have more than 1 team created by single account, AFAIR I had one with ~6k teams
and hundreds
of accounts which created more than one.
6. For all "deny" action when something suspicious is detected, I set a very
long, random wait
time, of 20-60s before returning warning or error. It slows down the spam a lot.
I bet if everyone did that, the spambots would quickly run out of resources.
7. I also use local copy of the SFS database dumps of spam IP addresses as a quick
way to display 403
on some of the critical pages (registration, profile/team creation, forums and a
couple of others).
Regards,
Slawomir Rzeznicki
Enigma@Home
On Mon, 14 Nov 2016 10:10:05 +0100
Christian Beer <[email protected]> wrote:
On 11.11.2016 22:46, David Anderson wrote:
The create-account RPC is used by
- account managers (BAM!, etc.)
- the BOINC client
If it were just account managers we could add some kind of access control
(i.e. accept RPCs only from known AMs).
But this would break the client.
What to do about this?
Suggestions are welcome.
I don't think account creation is the right place to fix it. Especially
since it will break older Clients.
The question is what do the spammers want? They want to place links on
the webpage. There are currently only two ways to do this.
1. via a publicly accessible profile on a project that is not screening
profiles and does not have reCaptcha enabled for profile creation. The
Client does not do that. If reCaptcha is enabled this is secured.
2. via a forum post wether through the post or through the signature, we
already have measures against this, we should find out why they are not
effective anymore
3. through the URL attribute of the user table, which currently deems to
be not used by the spammers because it is not visible without a profile
(???) I didn't look in detail where this url is used.
4. By creating teams. This is currently also happening and I wonder if
creating the useless accounts should lure us away from the accounts that
create spam teams?
I know this is an arms race but I also think that breaking old clients
would mean to nuke the battlefield instead of putting on more armor. We
are on the defensive here and can't really attack back.
Regards
Christian
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
