Audit trail Viewer showing site IP for all logins

Hi… not sure what to suggest here. You’ll have to narrow down the conflict manually – I’d be keen to hear what you find.

I have gone through all the troubleshooting steps you lay out in your support forum (disabling modules 1 by 1, etc) I’ve disabled plugins 1 by 1, I did a reset of the plugin per your forum, I even uninstalled and dropped all the tables and reinstalled. Still the same issue. My hosting company has just thrown their hands up and blame you (they are useless, but it’s the clients choice) The site is on a VPS and I was having trouble SSL failing because of too many redirects. The host fixed it saying it was endurance page cache. But they also added this to the wp-config file:
/* Allows IP to be passed from remote host to server */
if (isset($_SERVER[“HTTP_X_REAL_IP”]))
$_SERVER[“REMOTE_ADDR”] = $_SERVER[“HTTP_X_REAL_IP”];
/* Allows SSL request to pass through nginx proxy */
if ($_SERVER[‘HTTP_X_FORWARDED_PROTO’] == ‘https’)
$_SERVER[‘HTTPS’]=’on’;
My htaccess no longer has the 301’s in it and instead they are using that. Is that the cause? I’ve asked them but they can’t or won’s answer me.
Thank you for your time Paul, sorry for the rambling reply.

Hi,

Not sure what the cause is.

But you can experiment with removing those lines from your wp-config.php your host added and see if there is any improvement.

Before you start with experimenting, have a backup of the wp-config.php, just in case if something goes wrong and breaks your site.

Regards,
Jelena

Thank you for taking the time to reply. I have spent several hours researching this, including 3+ hours on the phone with my hosting company. They claim that this is the standard way they pass requests for SSL on VPS. I was able to get them to elevate a ticket to a top level server tech to address the issue. The plugin seems to be functioning as it should, aside from audit trail viewer (which is my favorite part) so for now I wait.

Hi,

Thank you for the update.

Keep us posted.

Regards,
Jelena

• This reply was modified 7 years, 6 months ago by Jelena.

This is what my hosting company has come back with –
Regrettably, we are unable to troubleshoot 3rd party plugins. For any support regarding the Firewall plugin, you will need to reach out to the developers. You can also provide them with the error:
Call to undefined method ICWP_WPSF_FeatureHandler_Statistics::getReportingTableName()
/wp-content/plugins/wp-simple-firewall/src/processors/statistics_reporting.php on line 15

I thought maybe I was using old php, but I’m at 5.6.30. That is “old” but it’s the best I can do for now. Thoughts?

Unfortunately that sort of hand-washing response is common enough. I’m not sure how to help you with this. Each server configuration is different and we have numerous options built within the plugin to try and obtain the correct visitor IP address for this very reason.

As to that error, I can’t replicate it, so I suspect they were playing about with something and it generated this error while they were messing with something. I can’t see how they were able to create it.

I honestly not sure of the next step here.

Thank you for your time.

Hello,

I am having this exact same problem with the Audit Trail Viewer. Just a couple of weeks ago, the website started showing its server’s IP as the IP of every logged in user.

I contacted the hosting company to know what is causing it, and they said that there were some global changes made to Nginx and OHWP servers that might have affected how the Shield Security plugin obtains users’ IPs. They said I would need to change the method in which IPs are obtained on the plugin’s settings page …but there is no way to do this in the setting options, correct?

The support staff also stated the following: “The nginx configuration is set to display the real IP of the visitor. I’m not sure how the plugin developer pulls the data.”

Based on their investigation of the issue, they were able to narrow the problem down to the manner in which IPs are being pulled.

Which method does the Shield Security plugin use to obtain IPs?

Unfortunately, Wp-Simple-Firewall (AKA Shield) uses a very insecure way of gathering IP addresses. (As a side-effect also allowing anyone wanting to, to spoof it with fake information.)

Most of the below headers should ONLY be used when they are known to be trust-worthy. Such as when a trusted front-end caching- or reverse-proxy is KNOWN to be setting them.

@melodies, In your case with a Nginx front, the hosting company will have put the “real visitor IP” into a header with one of the names below. Such as “HTTP_X_REAL_IP”, which is apparently used in @doit686868’s case. They could have chosen another, but they know which. As a site-owner, one has to pick the header that is trust-worthy AND reliable for that particular hosting setup, if REMOTE_ADDR cannot be used. All others (except REMOTE_ADDR) can be spoofed by a visitor by simply sending that header with a random IP in it. ??

What is happening is that because you have front caching (or reverse-proxy) server, the only 100% trustworthy header (REMOTE_ADDR, from the TCP connection) will ALWAYS show that your front-caching server is your visitor, and the real visitor’s IP is then passed along by the fronting server in one of the other HTTP headers.
Wp-simple-firewall grabs whatever it finds first as if it is the real visitor IP. Logs it, might block it if it misbehaves, …, …

This is the order of priority it uses for grabbing IPs from headers:

				'HTTP_CF_CONNECTING_IP',
				'HTTP_X_FORWARDED_FOR',
				'HTTP_X_FORWARDED',
				'HTTP_X_REAL_IP',
				'HTTP_X_SUCURI_CLIENTIP',
				'HTTP_INCAP_CLIENT_IP',
				'HTTP_FORWARDED',
				'HTTP_CLIENT_IP',
				'REMOTE_ADDR'

Without a configuration to “lock down” which headers should be considered true and valid, the results can get kind of random, plus as mentioned it allows for bad guys to spoof the security by passing along random IPs in the headers, rather than their own.

Wow, thank you Caleb. Although it doesn’t solve my problem, it gives me a much better understanding of what is going on. I really appreciate the time and detail you gave.

@doit686868, Well.. ??
Actually solving the problem can only be done by the Shield folks providing a way to “lock down” which headers should be accepted and used as valid on individual sites. Which is VERY specific to various hosting setups. (Direct connect, reverse-proxy, caching front, Managed WordPress, …, …)
Things only the local site-owner can know, and frequently cannot be detected by the plugin other than by guessing.. ??

Apparently in the particular configurations for you and @melodies, the fronting server is passing along one or multiple headers trying to tell y’all about the outside visitor (as they should), but Shield is making the wrong picks from those headers.

The hosting company support folks are right.. There is nothing they can do. They cannot and SHOULD NOT turn off sending those headers, because that would simply end up with the plugin banning all access to your site. The front-server’s IP address would get blocked, since that is physically the only “visitor” you actually have (by REMOTE_ADDR). It would then get blamed for all bad accesses, rather than the “real visitor” listed in the headers. ??

Only the plugin owner can fix this.
By making the “simple configuration” less “simple”. ??

That’s a good point Caleb… providing an option for a user to select which one is the preferred is probably best. Most folk wont know what to select here, but for those with a problem, they can choose. I’ll put that into the next release (v5.14). As you say, it makes it less simple, but there’s no way for us to predict this sort of change and future adjustments.

Thanks for sharing your thoughts and suggestion on that!

• This reply was modified 7 years, 6 months ago by Paul.

As you said. No way to know.
The plugin (and you) cannot know what is valid and trust-worthy to the individual sites, unless it is a direct-connect setup.
Unfortunately that is something the site-owner has to investigate (ask their hosting provider). Unavoidably making their life more complex. ??

Adding to the complexity is the fact that some site visitors, even in the site-direct-connect cases actually arrive by a valid proxy. Where the address might need to be translated before blocking happens, or thousands of potential visitors could be killed off in a single blocking action.

For example, all mobile visitors arriving from AT&T Wireless and some other ISPs will arrive by proxy, with a standard header carrying the “real visitor” IP address. ??
Block the proxy IP, rather than the real visitor, and magically all (or most) mobile visitor’s from that provider would vanish from the site, because the AT&T proxy’s IP-address got “blamed” and blocked. So even in a direct-connect case, it can be unsafe to merely choose “use REMOTE_ADDR only”.

Fortunately, not too many bad guys show up on Wireless IP addresses, unless they spoof the headers. No one wants to pay wireless data fees for their hacking activities. ??

The Internet is such a cool (and tricky) place, Eeh. ??

@crudhunter — Thank you for the detailed explanations and suggestions ??

@paultgoodchild — Thank you for the next release fix ??