[support] How to safeguard sites from unwanted users
Jamie Holly
hovercrafter at earthlink.net
Sat Jun 22 05:08:26 UTC 2013
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 <mailto: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 <mailto: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
>> <mailto:fred at example.net> or joe at domain.test
>> <mailto: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/ ]
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20130622/bebb040a/attachment-0001.html
More information about the support
mailing list