Administrative and Maintenance Tools - Proxy to Real IP Conversion

This modification is no longer available or supported.

This hack makes the forum always use the members real ip when a proxy is detected, meaning that all existing ip functions should continue to work, basically ignoring the proxy server (other than recording it's presence).

i.e.

* The real ip (or host) is displayed in the who's online page.
* The real and proxy server ip's are accesible for each post, the button is red for members using a proxy server.
* The real ip is searchable in the admin/mod cp (but not the proxy ip).
* The real ip can be banned by admins.

etc etc ......

Note: Obviously this hack relies on the proxy server passing the correct http variables to allow detection.

If a proxy is detected, then a red ip icon is displayed instead of the standard one. This mod will also detect if the ipinfo hack is installed and adjust itself to call the ipinfo code.


History:

v2.20 : Updated for vb 3.6. IP Info detection added.
v2.21 : Dependancies updated for 3.6.0 Gold.
v2.22 : Updated for Version Checking.
v2.23 : Fixed bug causing wrong ip in WOL display.
v2.24 : Rewritten slightly to fix a minor issue with spiders.
v2.25 : Updated for changes in vB 3.6.4.


Remember that this modification involves changes to the class_core.php file - if you upgrade your vbulletin, you must reapply those changes.

Please do not post asking why this does not work with some proxy servers, the answer is already in the notes above, and also in Post #160.

[Paul M]

I don't quite follow how this would work, as all requests to the final server (i.e. your server) will be on port 80, regardless of what ports were used before that.

[GNDI]

if you backtrace the connection, you will be able to see if it was connected through port 80 or an alternative just view your own log file

[Paul M]

Nope, 99% of the worlds webservers only listen on port 80 (for http) so your logs will only show port 80.

[The Finman]

Originally Posted by Paul M

I don't quite follow how this would work, as all requests to the final server (i.e. your server) will be on port 80, regardless of what ports were used before that.

You know...I may be remembering this incorrectly and I may also be explaining it incorrectly as well.


This is what I remember that it did.

Let's grab a "fresh" proxy list

Anonymous List:

89.34.43.181:6588
89.34.32.224:6588
202.68.151.108:6588
220.226.63.254:8008
58.143.98.224:8080
222.235.104.129:8080

http://www.proxy-list.net/show-proxy...0eb7fa884d1b19

The first proxies on that list are connected at port: 6588 and the remaining three are connected via port: 8080

This is where I am having trouble explaining this, as I know what it did...I'm just not sure how it was done.

He used UBB Classic (which was completely written in PERL until the later versions that used PHP as an accelerant), the server was Linux and I do know that he often relied on .htaccess files to handle problem boards linking to him, the "hot" linking of images on his server, Etc.

He had a script that somehow was able to detect proxies that were connected at other ports besides port 80.

How he was able to do this exactly is what I am not sure of and was why I was over at UBB Developers seeing if I could find it.

I was a Moderator on his UBB board and one day I was unable to connect to the board because I had left my connection to a proxy server on. I asked him and he said it was a "script" that was able to block most proxies. A few weeks later I noticed that I was able to connect and post using a proxy server, and I asked him if he had disabled the proxy script, he said that he hadn't...I asked him why I was able to connect presently as I was posting to him behind a proxy. He asked me what port I was connected on and I told him port 80, he confided in me that the port 80 was the only proxy connection that the script failed to block, and he asked me not to mention it as it had seriously cut down on the number of problem posters/troll that were posting using a proxy that used a port connection of 80.

I really wish I could find him, as I am not sure if my memory regarding the event is faulty or that I was just too "green" at the time to understand it.

He was a very quiet person and was not prone to bragging or lying which is why I am treading very gingerly in describing that event. He was very good at writing his own scripts in PERL (and I know he used to contribute to UBB Developers which is why I went there looking first).

I remember also, because I asked him about learning PERL (remember this was about 4 years ago) and he told me at the time to concentrate on PHP instead.

So, what I am carefully trying to say without looking silly...is that he was able to detect and block proxy servers that the user had connected to using a port other than 80. He was able to block those proxy connections, but the "Achilles heel" (so to speak) was proxy connections that used standard (http - port 80) connections. I don't know know if it was a script he wrote in PERL (I don't think UBB was using PHP yet at that time), or if had configured something on their server to detect and block it directly.

I do know that like so many proxy fixes that people have developed to try and fix/stop the problem that his also didn't work 100% either.

I have recently been looking at various ways other people (such as yourself) have approached the problem, and I remembered the way he approached it and I was thinking if his way (again, I remember pretty clearly the details of what it did...I'm just not sure of the details of how he did it ) could be combined with your method, that even though it still would be 100%, if it was possible...it would still be pretty damn powerful.


Like I said, I do remember that he asked me not to say or mention the flaw, or post about it on the board which I helped moderate and that he owned/ran, as he said that the majority of proxies that the users connect too, don't use port 80 and that the "script" (I am almost positive that he called it a script) was able to stop all those with that one exception being those that connected to the proxy they were using via port 80.

But maybe it wasn't a script...maybe have been something he did at the server itself (similar to the way that .htaccess works).

Or, maybe my memory really is that faulty.

[Paul M]

<u>vBulletin 3.6.4</u>

Version 2.25 Uploaded.

An extra step has been added to the class_core.php edits to take account of new code added to this file in vB version 3.6.4. When upgrading to 3.6.4 you should start with a fresh copy of class_core and apply all the edits.

[Shazz]

SO if where still back on 3.6.2 we should just stay with what we got?

[Total666]

Step 3.

In class_core.php ;

Find ;

// define session constants
define('SESSION_IDHASH', md5($_SERVER['HTTP_USER_AGENT'] . vB_Session::fetch_substr_ip($registry->alt_ip))); // this should *never* change during a session
define('SESSION_HOST', substr($registry->ipaddress, 0, 15));

Replace with ;

// Paul M - Define session constants
define('SESSION_HOST', substr(IPADDRESS, 0, 15));
define('SESSION_IDHASH', md5($_SERVER['HTTP_USER_AGENT'] . vB_Session::fetch_substr_ip(IPADDRESS)));

Mine with 3.64 is differnet ..

// define session constants
define('SESSION_HOST', substr($registry->ipaddress, 0, 15));

if (!defined('SESSION_IDHASH'))
{
define('SESSION_IDHASH', md5($_SERVER['HTTP_USER_AGENT'] . $this->fetch_substr_ip($registry->alt_ip))); // this should *never* change during a session
}

What I'm trying to say is that my code is not the same , the last two are not in the same location .. Total

[Paul M]

You're right, I hadn't noticed that had changed as well.

I've uploaded a new set of instructions for both changes.

[Total666]

Thanks man , I thought that either I went insane or my carbon monxide detector was faulty ( or both ) .. Total

[Shazz]

If where using 3.6.2
Should we just stay put on the release before this new one ?