Community Support Forums — WordPress® ( Users Helping Users ) — 2011-05-13T03:15:14-05:00 http://www.primothemes.com/forums/feed.php?f=4&t=6380 2011-05-13T03:15:14-05:00 http://www.primothemes.com/forums/viewtopic.php?t=6380&p=14828#p14828 <![CDATA[Re: Brute Force IP Detection]]> Thanks for the follow-up John. Much appreciated buddy!

Gotchya. So it seems that Rackspace handles this NOT based on whether SSL is currently in use, but based on whether or not your account has SSL enabled period ( i.e. if your IP is SSL-enabled ). So you are correct, I've updated the code sample above. Based on this article ( May 2011 ): http://cloudsites.rackspacecloud.com/in ... address%3F

Statistics: Posted by Jason Caldwell — May 13th, 2011, 3:15 am


]]>
2011-05-11T19:02:25-05:00 http://www.primothemes.com/forums/viewtopic.php?t=6380&p=14655#p14655 <![CDATA[Re: Brute Force IP Detection]]>
You are the BOMB! This totally works:
Code:
$_SERVER["REMOTE_ADDR"] = $_SERVER["HTTP_X_FORWARDED_FOR"] 

In my environment, I see that "HTTP_X_FORWARDED_FOR" is set to the proper client IP regardless of whether the request arrives via http or https and "HTTP_X_CLUSTER_CLIENT_IP" is always the IP of the load balancer.

Just curious why your example sets REMOTE_ADDR to the load balancer IP over http and conditionally sets REMOTE_ADDR to the proper client IP over https?

Mahalo!
John

Statistics: Posted by johnleblanc — May 11th, 2011, 7:02 pm


]]>
2011-05-11T02:12:40-05:00 http://www.primothemes.com/forums/viewtopic.php?t=6380&p=14618#p14618 <![CDATA[Re: Brute Force IP Detection]]> Thanks for the excellent question.

Yea, I've seen this issue myself in the past. Most apps like s2Member ( in my opinion ), should just use $_SERVER["REMOTE_ADDR"], so that you don't have several plugins, all using a different set of techniques. In other words, ideally, you want your server to report this information inside $_SERVER["REMOTE_ADDR"], and ideally, every application you have running would use that standardized Super Global. This way all software that collects IP addresses, will use the same source ( i.e. whatever value your server places into $_SERVER["REMOTE_ADDR"] ).

Now, I'm aware that some Cloud Computing models do NOT fill this field correctly, but ( in my opinion ), the solution is not to change each individual piece of software, but rather, to implement something on your own to normalize the existing Super Global $_SERVER["REMOTE_ADDR"].

Here's how it's done on Rackspace Cloud Computing models.

1. Open your php.ini file ( or it can also be done via .htaccess ).
Using PHP.ini do this: auto_prepend_file = /path/to/remote-addr.php
Or, using .htaccess, do this: php_value auto_prepend_file /path/to/remote-addr.php

2. Create the /remote-addr.php file with this PHP code snippet.

For Rackspace, you would use something like this:
Code:
<?php
$_SERVER
["REMOTE_ADDR"] = $_SERVER["HTTP_X_CLUSTER_CLIENT_IP"];
?>
* No spaces or extra lines before or after <?php ?>


Or, if your Rackspace account has SSL enabled ( i.e. you have an SSL-enabled IP, use this )
Code:
<?php
$_SERVER
["REMOTE_ADDR"] = $_SERVER["HTTP_X_FORWARDED_FOR"];
?>


Reference articles:
http://cloudsites.rackspacecloud.com/in ... address%3F
http://stackoverflow.com/questions/3841 ... php-script
http://www.php.net/manual/en/ini.core.p ... epend-file

Statistics: Posted by Jason Caldwell — May 11th, 2011, 2:12 am


]]>
2011-05-10T21:17:23-05:00 http://www.primothemes.com/forums/viewtopic.php?t=6380&p=14606#p14606 <![CDATA[Brute Force IP Detection]]>
In certain setups (Rackspace Cloud sites, for instance), 'REMOTE_ADDR' reflects the IP address of a load balancer and the true client IP is in 'HTTP_X_FORWARDED_FOR'.

I discovered this today when a single user exceeded the failed login threshold and all users were locked out. :oops:

I'm wondering if you'd be willing to add a new filter within s2member/includes/classes/brute-force.inc.php so that users may define alternatives to $_SERVER["REMOTE_ADDR"] for user IP detection?

Mahalo!
John

Statistics: Posted by johnleblanc — May 10th, 2011, 9:17 pm


]]>