[support] support Digest, Vol 126, Issue 26
Chris McAndrew
chris at csmcreative.com
Mon Jun 24 00:34:55 UTC 2013
Depends where you live and if you trust your neighbors.
On Jun 21, 2013 11:03 AM, <support-request at drupal.org> wrote:
> Send support mailing list submissions to
> support at drupal.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.drupal.org/mailman/listinfo/support
> or, via email, send a message with subject or body 'help' to
> support-request at drupal.org
>
> You can reach the person managing the list at
> support-owner at drupal.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of support digest..."
>
>
> Today's Topics:
>
> 1. Re: How to safeguard sites from unwanted users (Jamie Holly)
> 2. Re: How to safeguard sites from unwanted users (Kamal Palei)
> 3. Re: How to safeguard sites from unwanted users (Jamie Holly)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 Jun 2013 10:00:02 -0400
> From: Jamie Holly <hovercrafter at earthlink.net>
> Subject: Re: [support] How to safeguard sites from unwanted users
> To: support at drupal.org
> Message-ID: <51C45C62.1040807 at earthlink.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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.
> >
> >
> >
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 21 Jun 2013 19:45:03 +0530
> From: Kamal Palei <palei.kamal at gmail.com>
> Subject: Re: [support] How to safeguard sites from unwanted users
> To: support at drupal.org
> Message-ID:
> <
> CALO8XuVd7N5-GyRPn6Ra_h_CyqRt8HgQXb391b47FDfXqPtVWA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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/ ]
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.drupal.org/pipermail/support/attachments/20130621/f1de9b49/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Fri, 21 Jun 2013 10:49:27 -0400
> From: Jamie Holly <hovercrafter at earthlink.net>
> Subject: Re: [support] How to safeguard sites from unwanted users
> To: support at drupal.org
> Message-ID: <51C467F7.2030808 at earthlink.net>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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 (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/ ]
> >
> >
> >
> >
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.drupal.org/pipermail/support/attachments/20130621/41e08d76/attachment.html
>
> ------------------------------
>
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>
> End of support Digest, Vol 126, Issue 26
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20130623/d17241f5/attachment-0001.html
More information about the support
mailing list