[support] How to safeguard sites from unwanted users

Sat Jun 22 14:11:54 UTC 2013

Another option, depending on use case, I manage a Drupal site for an
Open Source community and I don't even care about the users.  The
users may register without admin approval but if they wish to add to
the wiki they must request access to post on the groups support list.
I then just add a role giving them permission to post.  I went from
many spam to zero in a matter of one day once I implemented that
policy.

Kamal, you may be interested in
https://drupal.org/project/user_verify; I haven't tried it but it
should help with lowering the SPAM user registration.  The idea is a
good one.

Earnie

On Sat, Jun 22, 2013 at 1:08 AM, Jamie Holly wrote:
> The problem you will still encounter is the random user names. I've got a
> list from one client of over 17,000 spam names that are random, and that's
> from about a 4 month period.
>
> IMHO the better option would be to just block them, then write a small
> module to run on cron and delete the blocked users more than X days old, if
> the names in the user table is of concern.
>
> Another option. With only 2 valid users in a week, set the site to where an
> admin has to validate an account. Let that run for a couple of weeks and
> there's a good chance the person spamming you will give up. After that, go
> ahead and open it back up.
>
> Jamie Holly
> http://www.intoxination.net
> http://www.hollyit.net
>
> On 6/22/2013 12:36 AM, Kamal Palei wrote:
>
> Hi Jamie
> True, but I just took a look at last 7 days data. For my site, new valid
> users 2 , and junk users are around 10. So in this rate if it goes, i will
> have more junk users than valid users.
>
> The only option that comes to my mind is, re-use the junk user space for new
> users (again it may be valid or junk user). But in the process always we
> will have less junk users.
>
> However I will do once I finish number of pending tasks.
>
> Best Regards
> Kamal
> Net Cloud Systems
> Bangalore-08
>
>
> On Fri, Jun 21, 2013 at 8:19 PM, Jamie Holly <hovercrafter at earthlink.net>
> wrote:
>>
>> Why go through all that? You're reinventing the wheel. Just block the
>> unwanted users and then a new user can not be created with the same name.
>>
>> Also consider that a vast majority of spammers use a program to randomly
>> generate a user name. That means that their are huge odds of them never
>> using the same name twice for registration.
>>
>> Jamie Holly
>> http://www.intoxination.net
>> http://www.hollyit.net
>>
>> On 6/21/2013 10:15 AM, Kamal Palei wrote:
>>
>> I am thinking of below solution.
>>
>> For my site, it is easy for us to find who are unwanted users using some
>> mechanism. I am planning to write a custom module, that will allow
>> administrator to list down unwanted users and these users references I will
>> keep in a separate table , lets call it table-a. When a new user registers,
>> I will check table-a, and if any entry found, I will use that entry's UID,
>> for new user. Thereby over the time, anytime you see the unwanted users in
>> my site will be less.
>>
>> Best Regards
>> Kamal
>> Net Cloud Systems, Bangalore-08
>>
>>
>> On Fri, Jun 21, 2013 at 7:30 PM, Jamie Holly <hovercrafter at earthlink.net>
>> wrote:
>>>
>>> The goal is to make it more difficult for people to register unwanted
>>> accounts. You aren't going to stop it completely. Email verification is
>>> just another hoop for them to jump through, one that is also accepted by
>>> a vast majority of regular users. It should always be used.
>>>
>>> Something I did for a client last year was a custom module. It did a few
>>> things. First we could set the number of registrations per IP in a given
>>> time frame. After that the account requires admin approval. It also
>>> recorded all the request headers so that I could look for a pattern,
>>> which I ended up finding. Once I was able to isolate that, I blocked
>>> that pattern from registering, which took a client's site from a few
>>> hundred spam registrations per day, down to one or two per week. Per my
>>> agreement with that client, I can't give out that pattern, but doing
>>> something similar on any site wouldn't be that complex.
>>>
>>> A common practice now is for companies to hire people to generate these
>>> accounts. They then use the accounts to spam your site. After that a
>>> company contacts you regarding the spam on your site, offering to "clean
>>> it up" and help your seo rankings. Very, very dirty indeed.
>>>
>>> The interesting part of that is what we found out. The registrations
>>> were happening from IP addresses all around the globe, yet the actual
>>> spam postings were mostly from U.S. IP addresses and over 70% were from
>>> hosting companies that offer VPS. We were successful in getting one
>>> hosting company to shut down an account, but most just ignore it.
>>>
>>> The whole morale of the story is vigilance. Things like CAPTCHA, email
>>> verification and keeping bad user accounts to prevent reuse of bad names
>>> and emails all give an extra layer of security (albeit not all that
>>> much). Or do you believe in leaving the front door of your home standing
>>> wide open, when you aren't there?
>>>
>>>
>>> Jamie Holly
>>> http://www.intoxination.net
>>> http://www.hollyit.net
>>>
>>> On 6/21/2013 1:56 AM, John Summerfield wrote:
>>> > On 12/06/2013 10:37 PM, Jamie Holly wrote:
>>> > > +1 to that! Also, they can't reuse the email. Make it harder on them,
>>> > > not easier.
>>> >
>>> > Reread gmail's rules about its email addresses. One can generate any
>>> > number of alternatives for any one email address. Besides, unless one
>>> > requires email addresses to be verified during registration, users can
>>> > use anything at all, even fred at example.net or joe at domain.test (both of
>>> > which _can_ be valid).
>>> >
>>> > Email hosts often allow +arbitrarySuffix to the localpart of email
>>> > addresses, but the "+" can be another arbitrary character, I've seen
>>> > hyphens used.
>>> >
>>> > And then there are some domains where everything is delivered, if not
>>> > to
>>> > a specific addressee then to a default address and that too is
>>> > configurable.
>>> >
>>> >
>>> >
>>> >
>>>
>>> --
>>> [ Drupal support list | http://lists.drupal.org/ ]
>>
>>
>>
>>
>>
>>
>> --
>> [ Drupal support list | http://lists.drupal.org/ ]
>
>
>
>
>
>
> --
> [ Drupal support list | http://lists.drupal.org/ ]

-- 
Earnie
-- https://sites.google.com/site/earnieboyd