Proxies - Mod

[polik]

Not 100% if this has been mentioned before but I notice that vBulletin have made a hack which allows the real IP to be shown when users use proxies.

I think this would make an excllent addition to IPB since you may have noticed that all NTL users use transparent proxies (by default I think) and you can't therefore ban a troublesome user since they all show up as using the same IP address.

Anyone got any views about this...?

[polik]

No-one agree? :(

[ellawella]

You are probably talking about a feature which uses the value of the x-forwarded-for header to determine the IP instead of the normal remote address method. x-forwarded-for is a header containing the IP of the machine making the request to the proxy. However, because it's a header, it can be faked. That's the flipside.

It should also be noted that only some proxies send this header. Most don't send anything at all, so you don't know what the real IP is. Anyway, the admin CP already carries a setting for dealing with this: "Enable X_FORWARDED_FOR IP matching?"

[polik]

Erm.... huh? :blush:

The problem is is that when I do an IP search for troublesome user X (uses NTL) it shows up all the members using NTL, and thus it's impossible to detect if user X has signed up for a secondary account.

[ellawella]

That's because they're dynamically assigned IPs. Do some reading on IP addresses and/or proxies.

[bfarber]

IPB already allows the logging of the X_FORWARDED_FOR IP address matching...however as the other poster pointed out, it can be faked, or the proxy can just not send it (a true anonymous proxy wouldn't send it of course).

Additionally, you'd need to have this enabled to have the IP stored instead of the regular REMOTE_ADDR

[SnowBlower]

I think it would be a good idea to have both displayed at the sametime, rather than just have one or the other.

[Guest Exiled]

Additionally, you'd need to have this enabled to have the IP stored instead of the regular REMOTE_ADDR

Could you please elaborate that. I'm at home, brain-dazed and doped up with a flu, but it sounds like ti might tie into something I'm working on.

[T22]

You are probably talking about a feature which uses the value of the x-forwarded-for header to determine the IP instead of the normal remote address method. x-forwarded-for is a header containing the IP of the machine making the request to the proxy. However, because it's a header, it can be faked. That's the flipside.

It should also be noted that only some proxies send this header. Most don't send anything at all, so you don't know what the real IP is. Anyway, the admin CP already carries a setting for dealing with this: "Enable X_FORWARDED_FOR IP matching?"

Where is the "Enable X_FORWARDED_FOR IP matching?" setting and how will it help you?

[Chaudhry]

Where is the "Enable X_FORWARDED_FOR IP matching?" setting and how will it help you?

Admin Panel--->TOOLS & SETTINGS-->Security and Privacy--> 3rd option

[chuck22]

if i enable this and a trouble user tries to register with a proxy i will still see his real IP?

[ellawella]

Not necessarily. Read the thread and/or do some research to inform yourself.

[chuck22]

Not necessarily what? btw u recommand enabling that option cuz i have it disabled <_<

[bfarber]

I think it would be a good idea to have both displayed at the sametime, rather than just have one or the other.

It would be nice, however it would be a decent change to how IPB currently works. IPB looks for this address if the setting is enabled, and sets the ip_address to this. We'd have to store both, etc. Something to consider (the *only* reason I haven't yet closed this topic), but not possible at present.

Could you please elaborate that. I'm at home, brain-dazed and doped up with a flu, but it sounds like ti might tie into something I'm working on.

What I meant by that was if you go and enable the setting now, it won't retroactively go back to find those addresses. The setting will only have effect moving forward.

Where is the "Enable X_FORWARDED_FOR IP matching?" setting and how will it help you?

It would help on a board that is primarily visited by AOL members, for example. Dialup AOL users go through a proxy, so often times several users can have the same IP, however the X_FORWARDED_FOR IP address is sent, thus allowing you to differentiate between them.

if i enable this and a trouble user tries to register with a proxy i will still see his real IP?

Not necessarily. As I said earlier, a true anonymous proxy wouldn't send it - it would defeat the purpose of that proxy. A valid internal proxy likely would however, if you were using an intranet proxy.

[chuck22]

so u recommand enabling that feature anyway? does it has any bad effect on the forum?

[ellawella]

We'd have to store both, etc. Something to consider (the *only* reason I haven't yet closed this topic), but not possible at present.

IPS should bear in mind that displaying the X_FORWARDED_FOR header by default could represent a security risk. Because it can be set to anything, due to being a header, potentially it could be used to inject HTML code into pages if it was displayed to admins/mods in the same place or near to the IPs next to posts in the topic view.

so u recommand enabling that feature anyway? does it has any bad effect on the forum?

Can you read?

[chuck22]

yes i can read, there is a program called HIDEIP and u just turn it on and it turn proxy on, if i use that program on a forum i'm banned BUT that option in the security section is turned on, i wont be able to acess?

[bfarber]

IPS should bear in mind that displaying the X_FORWARDED_FOR header by default could represent a security risk. Because it can be set to anything, due to being a header, potentially it could be used to inject HTML code into pages if it was displayed to admins/mods in the same place or near to the IPs next to posts in the topic view.

Can you read?

No, it won't be a security risk, because the IP is preg_matched for numeric values ;)

{ foreach( array_reverse( explode( ',', $_SERVER['HTTP_X_FORWARDED_FOR'] ) ) as $x_f ) { $x_f = trim($x_f); if ( preg_match( '/^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/', $x_f ) ) { $addrs[] = $x_f; } } }

		if ( $this->vars['xforward_matching'] )

IPB ensures it's a valid IP (well, to be specific it ensures you have 4 sets of numbers separated by a period between 1 and 3 numbers...technically someone could send 999.999.999.999 and still get through, but there is little point in having IP check beyond this).

Again, though, this is a setting. If you don't want to use it, don't. :) To date, I know of no instances where it has caused any problems.

If the X_FORWARDED_FOR address is available AND the setting is enabled, that will be used. If not HTTP_CLIENT_IP is checked, then REMOTE_ADDR, finally HTTP_PROXY_USER. Finally...

$this->ip_address = preg_replace( "/^([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})/", "\\1.\\2.\\3.\\4", $this->ip_address );

It's ensured to be in a valid IP address format, once again. I really don't think there is any security risk with this portion of the script.

[marcele]

It's ensured to be in a valid IP address format, once again. I really don't think there is any security risk with this portion of the script.

While I don't really think its a big deal .. it was even reported as an IP spoofing vulnerability for IPB a while back:
http://www.gulftech.org/?node=research&art...=00041-06162004

[ellawella]

Brandon - Thanks for the explanation, looks like there is definitely not scope for a security hole.

marcele - That report is from June 2004, in the present version of IPB the software only uses the value of X_FORWARDED_FOR if explicitly told to.

[bfarber]

Yes, the user has the option to enable it or not.

Unfortunately, when several of a board's users are behind a proxy (again, the AOL and intranets come to mind specifically) there is absolutely no other solution available. More than just the IP is validated during session validation - i.e., the session id in the ACP, and the member_login_key on the board level. This IP could be spoofed by users who know how to do such things, so if you are concerned about logging invalid IP addresses, just leave the setting disabled. :) Otherwise - really, worst case scenario, you will get incorrect IP's for a user determined not to let you know their IP address.