By Cromicon on

Hi

Could I draw your attention to this post please? http://drupal.org/node/71881

It describes issues that occur when drupal doesn't detect the actual IP address of a user if their ISP uses a proxy.

What module would need to be modified for this and has anyone already done it? Are there any plans for this modification to reach core?

Thanks.

⋅ Categories: Drupal 4.6.x

Comments

Michael M’s picture

Michael M commented

A quick and dirty method is putting this in the index.php file (making sure that every page loads it):

if ($_SERVER['HTTP_X_FORWARDED_FOR'] != '') {
  $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
}

Despite the fact that this might work, I personally wouldn't recommend it without further comments, testing, etc.

Cromicon’s picture

Cromicon commented

Thank you so much! I've put it on the site for testing and will update this tomorrow with some results (preliminary indicate watchdog reports correct ip) but I'm off to climb Snowdon for the next few days and will do further testing when I get back and check the logs and so on.

Cromicon’s picture

Cromicon commented

Further testing indicates troll.module is fubarred with this but then again it has it's own hardcoded http referrer functions and is not core (to 4.6.8). Also after several logouts, cache clearing and logins it appears the proxy server is still recognised at intermittent intervals, a page refresh usually reports the correct ip.

I think that may be due to the session timeout length more than anything else perhaps? Anyway, a break away for a few days should sort that out and proper testing can be done then.

I have to say that I'm really gratetful for that snippet. It was on the tip of my tongue but I lack the coding knowledge, however you've helped me a great deal in showing how it works. Thank you.

desm0n’s picture

desm0n commented

I would imagine something in core would override this ?

Seems a great attempt but can it really be that simple ?

Cromicon’s picture

Cromicon commented

It seems to be working fine for me now. Have you tried it desm0n?

desm0n’s picture

desm0n commented

Seems to work perfectly actually.

I have to admit to not extensively testing but its looking very much like it works.

heine’s picture

heine commented 
if ($_SERVER['HTTP_X_FORWARDED_FOR'] != '') {
  $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
}

This code opens a security hole the size of a barn door. Do not use it.

--
The Manual | Troubleshooting FAQ | Tips for posting | Make Backups! | Consider creating a Test site.

desm0n’s picture

desm0n commented

OH DEAR, removed pending further discussion.

Can you enlighten on what security it could compromise ?

halkeye’s picture

halkeye commented

HTTP_X_FORWARDED_FOR can be set to anything anyone feels like, cheap man's spoofing setup
its just a standard http header

Cromicon’s picture

Cromicon commented

Could a version of this be used instead and how would it be integrated?

function GetIP()
{
if (getenv("HTTP_CLIENT_IP") && strcasecmp(getenv("HTTP_CLIENT_IP"), "unknown"))
$ip = getenv("HTTP_CLIENT_IP");
else if (getenv("HTTP_X_FORWARDED_FOR") && strcasecmp(getenv("HTTP_X_FORWARDED_FOR"), "unknown"))
$ip = getenv("HTTP_X_FORWARDED_FOR");
else if (getenv("REMOTE_ADDR") && strcasecmp(getenv("REMOTE_ADDR"), "unknown"))
$ip = getenv("REMOTE_ADDR");
else if (isset($_SERVER['REMOTE_ADDR']) && $_SERVER['REMOTE_ADDR'] && strcasecmp($_SERVER['REMOTE_ADDR'], "unknown"))
$ip = $_SERVER['REMOTE_ADDR'];
else
$ip = "unknown";
return($ip);
}
desm0n’s picture

desm0n commented

I hope someone can come up with a solution to this issue as its becoming quite annoying to say the least.

It was great to actually start to see real IP's with the method posted but as security is paramount we need a new, permanant solution to the problem.

I think this needs to be added to core in some fashion and hopefully with the snippet above, someone may be able to offer us a solution.

halkeye’s picture

halkeye commented

Honestly, there is no sure fire way of detecting the original ip, and even then, most of the time that'd be useless information.

24.113.49.51 => proxy
192.168.3.1 => User

How does 3.1 have any use to you?

rest of the time, that is the idea behind anonymizor proxies,even if you could get data about the original user, it'd probably be bogus anyways.

desm0n’s picture

desm0n commented

I beg to differ here.

Granted that people can spoof their IP but most members don't or wouldn't have a clue how to.

IP disclosure is fundemntal to gain info on potential abusive users (and this is just one point for trying to locate a real IP). Vbulletin, phpbb etc all do this as standard and i believe so should drupal.

My demographics are localised and within a 20 mile radius. Each member that logs on is usually using the same ISP in the same location so every single IP address is the same, due to the IP's proxy server that members cannot turn off. This isn't something you'd expect and makes things like annonymous polls useless.

I really hope there is a solution to this but i still believe it needs to be included in core.

Cromicon’s picture

Cromicon commented

24.113.49.51 => proxy
192.168.3.1 => User

How does 3.1 have any use to you?

I appreciate what you are saying and agree with most of it. However Joe Public is usually unaware of certain techniques but Joe Hacker is.

What about having both IP's identified so the admin can choose?

Currently, most ISP's have a dedicated proxy ip so using your example it would go as follows:

24.113.49.51

Then the ISP has also issued the user with a leased IP, in the case of NTL it usually lasts 3 months or more, in some cases users have dedicated IP's through them. The ip of the user would be:

24.113.49.107

If we had an naughty user, using the present system we'd have to knock out 24.113.49.51 which would ban ALL of those people on the proxy and not the individual on 24.113.49.107.

What we want to do is identify individual users behind proxies and not just ban the proxy which would ultimately ban a swathe of people. In this example it's only 255 but in real life there is usually more IP addresses funneled through the one proxy. It's even worse if the person is on your proxy because you'd end up banning yourself.

Currently I swap in the previously posted solution when I get a naughty user to identify their IP correctly then IP ban at .htaccess level and swapout the script again. However, as mentioned, this is not ideal and yet other CMS's manage it. Why can't Drupal and why can't it change? Proxies are on the increase and this does need to be flagged. It's a major issue in euro countries already and I'm surprised this hasn't been flagged up stateside. If I had the expertise I'd help but I don't.

desm0n’s picture

desm0n commented

I'm very surprised too in all honesty. Either drupal communities are the most well behaved or other countries don't use a proxy as we do :) Either way this does need to be included in core i feel as its a problem that isn't going to go away.

Again i echo the previous poster in that if i could code it i would. I am however willing to put it through beta tests.

I've opened a feature request to see if we can get this in core.

http://drupal.org/node/73495

Cromicon’s picture

Cromicon commented

Just to clarify that example you gave a little.

"24.113.49.51 => proxy
192.168.3.1 => User"

We aren't talking about internal networks as indicated by the 192.168 prefix, we are talking about the common practise of a leased IP with duration of 3 - 6 - 12 months to indefinate of the user of say 24.113.xxx.xxx hiding behind the proxy that the ISP uses of 24.113.49.51.

In context, banning the proxy IP is like cracking a walnut with a sledgehammer. We need to be able to ban/identify the leased IP behind the proxy, not the internal network IP of the user (192.168.xxx.xxx) as that is pointless.

Alexflu’s picture

Alexflu commented

but isn't there a website to do this? trying to bypass a router and access your real ip and other people to do so?
http://www.portforward.com/routers.htm this is the sight