Jump to content

Recommended Posts

This is more theory than code but I was wondering if I wanted to make a secure website, game or web application etc and I wanted to use IP to protect what ever it was, how would I go about doing it. A lot of things on the web use IP's for security but I couldn't think through a perfect system of how to do it.

 

The easiest way I could think of is just to log each users IP every time they log in but what if they log in using a proxy and then stop using the proxy and therefore not have there real IP logged, should I just the IP on every page load? But then there's a problem if they always use a proxy IP and therefore I can never log their real IP and therefore 1 person could be 2 users and the IP's wouldn't show that. But then again it works the other way as well, what happens if 2 people have the same IP but are different people using different computers with a shared IP which some hosts do.

 

Finally what happens if I want to IP ban someone and it stops everyone from that IP accessing the website, say if it was a public library, school or again just a shared IP address.

What's the best way of using IP's for security?

Link to comment
https://forums.phpfreaks.com/topic/171212-using-ips-for-security/
Share on other sites

Things that I do:

 

1. Require a valid e-mail address (send verification links).

 

2. Require a non-free e-mail address (this can lower your audience the amount of participation so you have to analyze if it's best for you or not).  But I feel over the years, banning Yahoo!, Gmail, Hotmail and a few others have increased the quality of my community members.

 

3. Allow comments to be made by banned IP addresses.  You'll want to be able to look for patterns if people start saying they are banned.

 

Lastly, if you do manage to get a legitament IP, find who owns it.  I have called many ISP services to have action taken against malicious users.  I am not sure if it solved any of my problems, but I never heard from the users again!

IMO, I'm not sure this would be a good way to secure content as lots of ISPs have dynamic IPs for their customers.

However, if you were to secure content for just a session you could log the IP, and for that entire session the user is logged on have an ip check associated with the user and if any of them don't add up have it kill the script.

Example:

When user logs in:

$ipstore = gethostbyaddr();
//submit $ip to wherever you choose to store it (sql, file, cookie, session)

 

Then you could have a check on every page, or an include of a page that checks the ip.

Checker:

$ipchck = gethostbyaddr();
if($ipchck != $ipstore) {
die('Your ip did not match up to the stored ip you had on logging in!');
}

 

Something along those lines...

As for IP banning, I do run a site where I have to dish out the occasional IP ban, I usually clear the  IP deny from the .htaccess once a month, or when another user runs into a problem. Usually by that time the banned one has either lost interest and moved on, or has gotten over the ban. As for proxies, on my type of site they really aren't necessary unless the guests are up to no good, which they usually are when on a proxy, and I ban proxies automatically.

 

Those are my thoughts, hope it helps!

I dunno if this is true but its a possibility that there are too many people to each have a static ip. Also, its a lot safer having a dynamic IP. I use freedns.afraid.org and then use one of their background-service ip updaters that runs with the other services (rather than an app) this worked best for me when I had a dynamic ip- never really failed me either.

 

There is a way you can get the user's actual IP even if they're behind a proxy. I found this code, and it's probably the most popular approach.

 

function getRealIpAddr()
{
    if (!empty($_SERVER['HTTP_CLIENT_IP']))
    {
      $ip=$_SERVER['HTTP_CLIENT_IP'];
    }
    elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR']))   //this bit is a proxy-forwarded address
    {
      $ip=$_SERVER['HTTP_X_FORWARDED_FOR'];
    }
    else
    {
      $ip=$_SERVER['REMOTE_ADDR'];
    }
    return $ip;
}

 

I will say that if you just use email and ip address as protection, it's not gonna stop people. What you can do is have an admin approve section before that person can actually register, however that requires an admin to physically activate their account which could mean them having to wait. Waiting is bad in this day and age. What you can do is store a cookie, log their IP, check for a valid e-mail address (send email with activation link) and have a Captcha to stop adbots/spambots from signing up. The Cookie means that if the user has a dynamic IP, they will still not be able to access the site based on the script stopping anyone with that cookie in their browser. Obviously if they clear their cookies, this is rendered useless, but it's definately another stage of security- plus most rulebreakers (i.e. petty crimes like flaming, swearing, posting a bad link) will get the idea the first 5 attempts to access the site.

As for proxies, on my type of site they really aren't necessary unless the guests are up to no good, which they usually are when on a proxy, and I ban proxies automatically.

 

No offense, but you don't know what you're talking about.

 

http://www.phpfreaks.com/forums/index.php/topic,256583.msg1207033.html#msg1207033

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.