Sudden change of lockout behavior: uses server IP, not the “real” IP

What AIOWP says in a login lockout log:
user: abcd ip address: thi.sis.our.ser.ver

What Simple History plugin says happened is:

_server_http_x_forwarded_for_0 = thi.sis.our.ser.ver
_server_http_referer = https://our.website.com/wp-login.php
_server_remote_addr = our.rea.ldd.ress

What kind of server problem at the host could cause this?

The specific piece of code we added to wp-config.php back 2 years ago is this:

/** INSERTED Sept 2015 per James at Bluehost – Forwards Visitors’ True IP address to WordPress on Optimized Hosting for WordPress */
if($_SERVER[‘HTTP_X_REAL_IP’]){
$_SERVER[‘REMOTE_ADDR’] = $_SERVER[‘HTTP_X_REAL_IP’];
}

Um, yah. Interesting times. Any thoughts about what is going on? FYI: Bluehost has blocked access to the Varnish function for our storage and server, saying it’s offline. Could it be something with the server issue we’re having? Should I be looking to delete this hack of code from because perhaps it’s not necessary anymore? (who knows what’s going on in behind the curtain at Bluehost with our OWPH servers).

• This reply was modified 7 years, 3 months ago by lgpref. Reason: correction

Hi,
Yeah the question of how to get a client’s “real” IP is not easy to answer because of the spoofable nature of such a thing like an IP address.
As a matter of fact I think I will change our helper function which tries to obtain the IP address because it currently checks for the following $_SERVER variables in the order listed and returns the first valid address:
‘HTTP_CF_CONNECTING_IP’, ‘HTTP_CLIENT_IP’, ‘HTTP_X_FORWARDED_FOR’, ‘HTTP_X_FORWARDED’, ‘HTTP_X_CLUSTER_CLIENT_IP’, ‘HTTP_FORWARDED_FOR’, ‘HTTP_FORWARDED’, ‘REMOTE_ADDR’

But the problem with this is that the “HTTP_” variables can be more easily spoofed and “REMOTE_ADDR” is probably most reliable.
Also even if the various “HTTP_” variables are not spoofed, in some cases some may simply be populated with internal network IP addresses.
Having said that REMOTE_ADDR will not be accurate for visitors coming behind a proxy but that might be a small inconvenience considering the points made above.

So I’m not sure why you are seeing a sudden change in the IP address values returned but if you are so inclined you could play around and modify our “get_user_ip_address” function. (just ensure to make a copy of the original file in case you need to restore it)

• This reply was modified 7 years, 3 months ago by wpsolutions.

Hi there – thanks for looking at this issue.
If I was to modify the “get_user_ip_address” function, where would I do that? I’m a bit of a newbie on hacking things like wp-config and the like. Is it code in the .htaccess put there by the plugin? And, if you’re thinking about updating the plugin with changing the address, would you be doing that soonish (she asks plaintively)?

The thing that gets me about this is that no matter what IP address I log into WP Admin from, AIOWP Sec lets me in, but then logs me as coming from the server IP, which is blocked due to bot activity, because all login attempts are being logged by AIOWP as from the server IP. It’s like any logins to WP-ADMIN are all from the server IP. Once I log out, I can’t log back in again, because the server IP address has supplanted my actual IP in the lockdown table. If I use the Unlock Request function, it tells me that my IP address is not in the Locked Out table and can’t help me. Very frustrating. The only way to really edit the site is to log in, make the change, log out, log into cPanel, clear the entire Lockdown log (to get rid of the server IP without blocking bot traffic), and start over. (Not user-friendly, especially when I have at least 10 editors to accomodate.)

Our server still seems to have its Varnish function offline. We use WPRocket for cache management, which automatically hits the Varnish service. I don’t know if this is a server-side issue related to this ongoing server service issue at Bluehost. Still trying to get answers from them (eating up my day as I type this….)

so, I’m willing try anything today. Thanks.

FYI” Regarding proxy servers: Our main editing IP is within a proxy environment, which was working just fine until Thursday night. And, anywhere else I log in from regardless of IP set up gets redirected to the server IP. FWIW.

Spoke with hosting service. Varnish service is available. They are checking other issues and referring to this thread for details on IP issue. Thanks for any comment you may have.

Hi @wpsolutions – I heard back from our hosting service. This is what they say… I wonder what they mean by “dual proxy” arrangement? I find it surprising that your well-regarded plugin can’t work with Bluehost OWPH service, since it seems like that someone else would have mentioned it before.

“Looking into this it appears that the reason why the plugin is only picking up the servers IP is because of the proxied webserver setup unique to our OWHP platform, while I apologize for any inconvenience this may cause, this is not something that can be changed by the package. If you wish to view your traffic statistics you should be able to see them by using awstats in your cpanel. Alternatively you could contact the developer of that plugin to see if there is anyway to configure it to work with a dual webserver proxy setup. “

• This reply was modified 7 years, 3 months ago by lgpref.

@wpsolutions: I tried what you suggested, by looking to edit the order of the “get_user_ip_address” function. I put remote_addr ahead of _http_x_forwarded_for in the order, and the IPs worked correctly (I was able to log in, and AIOWP posted the correct IP address for my User Login log entry, matching what Simple History shows.)

If I wait for an hour or so, i should see another bot failed login on this site which might give us more data to see if that traffic handled correctly as well.

Do you have advice about whether this is a stable hack? Thanks for your advice.

— UPDATED 5:10pm pdt —- IP logging is working correctly for bot logins as well. Look forward to your advice on this subject. Thanks much!

• This reply was modified 7 years, 3 months ago by lgpref. Reason: added update

@wpsolutions: We updated to the most recent version (4.2.9), and glad to report that IP blocking/reporting is working just great. Thanks SO MUCH for being responsive and considering changes. Much appreciated – awesome work. Best wishes!

Call it closed.