LinuxQuestions.org
Review your favorite Linux distribution.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 01-17-2010, 08:56 AM   #1
qwertyjjj
Senior Member
 
Registered: Jul 2009
Location: UK
Distribution: Cent OS5 with Plesk
Posts: 1,013

Rep: Reputation: 30
user bypassing demo restrictions


I have a user that has already used up a demo 24hr trial on my website.
At present, I only check the customer id and the IP address to search for duplicates.
On the whole this works but it's not foolproof. We now have 1 user from China that is changing their IP address everyday to get access to the free trial.
Any options on what to do?
I thought of downloading a cookie to their computer that the website could pick up - again not foolproff but most people don't disable cookies.
Any other options?

I could ban China temporarily until the user gives up but if they find another proxy to chain then their IP address will be different again.
 
Old 01-17-2010, 09:27 AM   #2
b0uncer
LQ Guru
 
Registered: Aug 2003
Distribution: CentOS, OS X
Posts: 5,131

Rep: Reputation: Disabled
Banning all connections from China, or any other source for that matter, is a bad idea because you're potentially banning a horde of "quality users" per one "bad user". I've personally seen way too many forums on the web that, when entered for the first time in my life, tell me my IP address (which is dynamic and thus changes from time to time) is banned and that I would have to contact an administrator to do anything with the site. Banning an area to target one or few users is just a bad idea.

Cookie is also useless. Even if people have cookies enabled, a lot of people (including me) clear them from time to time, perhaps even every single time they close their browser. Therefore it is just as useful (actually even less so) as your IP catcher. Considering the extents to which banks have gone here to identify their users and make sure that the sessions are not hijacked, I don't think you have any real options to restrict your demo to the trial time "completely" except one: have all the users register and have (human) staff check their identities somehow before accepting. Even that's not bullet proof (for example consider how many illegal immigrants there are in USA!) Checking a credit card number might be one way, but you'd need to do it with the credit card companies and that's sure to pay. It could also scare off at least some of your potential demo users, and still not be perfect (card numbers can be stolen...) You could also just limit the demo functionality somehow, but it depends on your product whether or not that's good for the business.

Edit: of course you can collect a warehouse of information from all your visitors and then statistically try to deduce whether or not the user in question is likely to have been there before...but as you may guess, anything that has to do with statistics is only so accurate, and in this case I don't really think it would be reliable enough. Konqueror for example allows changing the browser information sent, so you would only make it slightly more difficult to "get in", not impossible. Of course when you make it hard enough, even the persistent users might give up..

Last edited by b0uncer; 01-17-2010 at 09:33 AM.
 
Old 01-17-2010, 04:16 PM   #3
qwertyjjj
Senior Member
 
Registered: Jul 2009
Location: UK
Distribution: Cent OS5 with Plesk
Posts: 1,013

Original Poster
Rep: Reputation: 30
Quote:
Originally Posted by b0uncer View Post
Banning all connections from China, or any other source for that matter, is a bad idea because you're potentially banning a horde of "quality users" per one "bad user". I've personally seen way too many forums on the web that, when entered for the first time in my life, tell me my IP address (which is dynamic and thus changes from time to time) is banned and that I would have to contact an administrator to do anything with the site. Banning an area to target one or few users is just a bad idea.

Cookie is also useless. Even if people have cookies enabled, a lot of people (including me) clear them from time to time, perhaps even every single time they close their browser. Therefore it is just as useful (actually even less so) as your IP catcher. Considering the extents to which banks have gone here to identify their users and make sure that the sessions are not hijacked, I don't think you have any real options to restrict your demo to the trial time "completely" except one: have all the users register and have (human) staff check their identities somehow before accepting. Even that's not bullet proof (for example consider how many illegal immigrants there are in USA!) Checking a credit card number might be one way, but you'd need to do it with the credit card companies and that's sure to pay. It could also scare off at least some of your potential demo users, and still not be perfect (card numbers can be stolen...) You could also just limit the demo functionality somehow, but it depends on your product whether or not that's good for the business.

Edit: of course you can collect a warehouse of information from all your visitors and then statistically try to deduce whether or not the user in question is likely to have been there before...but as you may guess, anything that has to do with statistics is only so accurate, and in this case I don't really think it would be reliable enough. Konqueror for example allows changing the browser information sent, so you would only make it slightly more difficult to "get in", not impossible. Of course when you make it hard enough, even the persistent users might give up..
What information can I collect from their browser that would be identifiable?
I realise cookies could be deleted everytime the browser is closed but then the majority of people do not do this.
IP addresses change dynamically.
I have to keep the demo functionality as automated as it would take too long to setup accounts and check them manually. I can continue to close off the demo when I realise it's the same persistent user and it hasn't been a problem so far but some people will try to bypass the checks.

Someone once mentioned fingerprinting but apparently even these can change from time to time?
 
Old 01-17-2010, 06:07 PM   #4
Quakeboy02
Senior Member
 
Registered: Nov 2006
Distribution: Debian Linux 11 (Bullseye)
Posts: 3,407

Rep: Reputation: 141Reputation: 141
Are you using email validation? Sure, they can change their email, but it's a layer that takes up the abuser's time, but one-time users are used to using it.
 
Old 01-17-2010, 06:18 PM   #5
qwertyjjj
Senior Member
 
Registered: Jul 2009
Location: UK
Distribution: Cent OS5 with Plesk
Posts: 1,013

Original Poster
Rep: Reputation: 30
Quote:
Originally Posted by Quakeboy02 View Post
Are you using email validation? Sure, they can change their email, but it's a layer that takes up the abuser's time, but one-time users are used to using it.
Well, I use email validation only in the sense that if they have already used the demo then it is registered against their customer ID and therefore email address. They are getting around this by registering a new free email account and registering on the site a s a new customer and with new IP address.
Fortunately, they are not very inventive on their country origin or customer name so I can see it is a duplicate but that is purely coincidental, they could change their name if they wanted.
 
Old 01-17-2010, 07:16 PM   #6
smeezekitty
Senior Member
 
Registered: Sep 2009
Location: Washington U.S.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,339

Rep: Reputation: 231Reputation: 231Reputation: 231
Quote:
Originally Posted by qwertyjjj View Post
Well, I use email validation only in the sense that if they have already used the demo then it is registered against their customer ID and therefore email address. They are getting around this by registering a new free email account and registering on the site a s a new customer and with new IP address.
Fortunately, they are not very inventive on their country origin or customer name so I can see it is a duplicate but that is purely coincidental, they could change their name if they wanted.
That also implies they will be able to bypass cookies too.
BTW How do you know its the same user?
 
Old 01-17-2010, 07:33 PM   #7
qwertyjjj
Senior Member
 
Registered: Jul 2009
Location: UK
Distribution: Cent OS5 with Plesk
Posts: 1,013

Original Poster
Rep: Reputation: 30
Quote:
Originally Posted by smeezekitty View Post
That also implies they will be able to bypass cookies too.
BTW How do you know its the same user?
They could bypass cookies but how many people really delete cookies?
I know it's the same user as they tried a duplicate demo order, then a duplicate IP showed, then they registered under a new customer but with the same name. Once a day around the same time, they register under a new customer as the same firstname but made up 2nd name...obvious stuff for the moment - I just sent them an email to warn them but I'd prefer to have some checks pick up the possibles.
ANyone who knew what they were doing could bypass it more easily I reckon.
 
Old 01-17-2010, 07:35 PM   #8
smeezekitty
Senior Member
 
Registered: Sep 2009
Location: Washington U.S.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,339

Rep: Reputation: 231Reputation: 231Reputation: 231
Quote:
Originally Posted by qwertyjjj View Post
They could bypass cookies but how many people really delete cookies?
I know it's the same user as they tried a duplicate demo order, then a duplicate IP showed, then they registered under a new customer but with the same name. Once a day around the same time, they register under a new customer as the same firstname but made up 2nd name...obvious stuff for the moment - I just sent them an email to warn them but I'd prefer to have some checks pick up the possibles.
ANyone who knew what they were doing could bypass it more easily I reckon.
How about a name comparison?
 
Old 01-17-2010, 07:35 PM   #9
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Rocky 9.2
Posts: 18,359

Rep: Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751
Realistically, given they go to a lot of effort already (new IP & email), unless you supply the passwd to the user at first login, and they can't change it, I don't think you can stop them.
They can always register a new acct even then...
Also, even then they can share it ...
 
Old 01-17-2010, 07:45 PM   #10
qwertyjjj
Senior Member
 
Registered: Jul 2009
Location: UK
Distribution: Cent OS5 with Plesk
Posts: 1,013

Original Poster
Rep: Reputation: 30
Quote:
Originally Posted by chrism01 View Post
Realistically, given they go to a lot of effort already (new IP & email), unless you supply the passwd to the user at first login, and they can't change it, I don't think you can stop them.
They can always register a new acct even then...
Also, even then they can share it ...
I get past the sharing by not allowing 2 different IP addresses using the same login.
 
Old 01-17-2010, 07:46 PM   #11
qwertyjjj
Senior Member
 
Registered: Jul 2009
Location: UK
Distribution: Cent OS5 with Plesk
Posts: 1,013

Original Poster
Rep: Reputation: 30
Quote:
Originally Posted by smeezekitty View Post
How about a name comparison?
Maybe in a bit of SQL that I then have to check manually every day?
The demo is only 24hrs so they'd probably have some access but really this is just about making it more difficult for them.
 
Old 01-18-2010, 06:57 PM   #12
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Rocky 9.2
Posts: 18,359

Rep: Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751Reputation: 2751
What I meant was that if they are willing to change IP addresses to get a new demo acct, they are also willing to share (give) their IP address with their mates as in 'here's a working IP + email for the demo' and then the first guy creates a new acct as you've described...
 
Old 01-18-2010, 07:03 PM   #13
qwertyjjj
Senior Member
 
Registered: Jul 2009
Location: UK
Distribution: Cent OS5 with Plesk
Posts: 1,013

Original Poster
Rep: Reputation: 30
Quote:
Originally Posted by chrism01 View Post
What I meant was that if they are willing to change IP addresses to get a new demo acct, they are also willing to share (give) their IP address with their mates as in 'here's a working IP + email for the demo' and then the first guy creates a new acct as you've described...
The demo only lasts 24hrs and each login can only be used by 1 IP address.
 
Old 01-19-2010, 04:08 AM   #14
r0b0
Member
 
Registered: Aug 2004
Location: Europe
Posts: 608

Rep: Reputation: 50
What is the structure of IP addresses? They must be limited to a specific IP block. You can either block the whole block (no pun intended!) or put an extra verification step for requests from this block?
 
Old 01-19-2010, 02:29 PM   #15
b0uncer
LQ Guru
 
Registered: Aug 2003
Distribution: CentOS, OS X
Posts: 5,131

Rep: Reputation: Disabled
Quote:
Originally Posted by qwertyjjj View Post
The demo only lasts 24hrs and each login can only be used by 1 IP address.
Referring to my earlier post, IP addresses can and do change, and in some cases this can be quick. Many ISPs I know that give public IP addresses do try to keep it the same at least for some time, but at least the last dialup connection I had changed the IP every time I reconnected. Therefore you should assume, even though it isn't very probable, that some "good" customers may well have their IP change during that 24 hour demo time and thus will be unable to take full advantage of it...of course you could count on the number of such clients being low and give them a way to inform you that this has happened, in which case you could grant them extra time. But it's more work, again.

Quote:
Originally Posted by r0b0 View Post
What is the structure of IP addresses? They must be limited to a specific IP block. You can either block the whole block (no pun intended!) or put an extra verification step for requests from this block?
Again, even if you block one block, you're potentially blocking hundreds of IP addresses at minimum. I wouldn't go there unless it's the very last chance.

As to what information can be collected from the visitor, see for example this page. There are plenty. You could try to turn this into a sort of fingerprint, but it is easily cheated and not too reliable.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
User name restrictions AndeAnderson Linux - Newbie 4 04-11-2005 03:29 PM
First time user needs help with bypassing a start up screen. aNi-DiFrAnCo Linux - Newbie 27 07-23-2004 07:41 PM
unreal 2004 demo(permission restrictions) nugzie Linux - Software 1 02-17-2004 02:13 PM
User restrictions on RH9 B|uSmurf Linux - Software 1 10-21-2003 07:24 AM
user Restrictions jpc82 Linux - Security 1 02-04-2002 01:35 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 06:35 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration