Hi @awack, thanks for the information.
It’d be great if I could see the current configuration and what IPs Wordfence is picking up for each of the detection options to assist further. You can visit the Wordfence > Tools > Diagnostics page and send the output to us at wftest @ wordfence . com. Click on “Send Report by Email”. Please add your forum username where indicated and respond here after you have sent it.
NOTE: It should look as follows – Screenshot of Tools > Diagnostic > Send by Email
Many thanks,
Peter.
Thread Starter
awack
(@awack)
TY Peter, I have sent it from one of the sites, this is happening on 3 sites we run via Liquid Web VPS. They tell us that WF is not configured correctly some how and that they are sending CF header etc.. So they simply want us to keep it on X-Forward. As you will see WF does sense ip and seems to want x-forward. This only happens on the WP sites i have at Liquid Web.
Thank you very much!
Hi @awack, thanks for sending that over.
I see that X-Forwarded-For is picking up the correct visitor IP to match what REMOTE_ADDR sees, but REMOTE_ADDR is the one stated as “in use” for the site you’ve sent us the diagnostic for. CF-Connecting-IP says “Configured but not valid”, although I would be inclined to say you could safely move to X-Forwarded-For if your host suggests and recommends this. Don’t forget to save using the button on the top-right of the page after you change it.
I see there’s a list of Trusted Proxies too. Are you using one of the Wordfence presets, does the host insert this information, or have you manually added them from the Liquid Web documentation? I don’t have any reason to believe that’s wrong, I just wanted to better understand the setup with this host.
Let us know if changing the IP detection method suppresses false-positives,
Peter.
Thread Starter
awack
(@awack)
Peter, Remote is in use because WF defaults to that after each scan,. Unless i tell it to ignore it. “Configured but not valid”, happens after a scan and the system then defaults back to remote. Yes it seems to run on x-forward for . we were just trying to make sure they were setup as WF wants it with CF header. But it does seem like Word fence is the issue here as it is being given the CF header from the Host. Yes all of the CF Proxy IPs are added per Word Fence Docs. The Ips come from Cloud flare. is there a reason not to add those to the proxy list?.. The Word fence Presets has no option for Cloudflare.
WE have just followed the Word fence help best practices.. When its running as X-forward- i still see false positives. But less.. I have set all 3 sites back to x-forward as that is the only thing wordfence seems to like. But i do think Wordfence has a bug that needs to be corrected. It should be able to see the CF-Header that Clod Flare is sending. Any thing else we shoudl try here ? IT will keep bugging us at every scan like this.. 🙁
Thanks for looking.
-
This reply was modified 1 month, 3 weeks ago by
awack.
Hi @awack,
Something is setting the correct IP address for the site already, which is why your IP is shown under REMOTE_ADDR. The first and last ranges in the Trusted Proxy list belong to Cloudflare so they don’t need to be there. There’s more information about how Wordfence gets IPs here: https://www.wordfence.com/help/dashboard/options/#general-wordfence-options
Also, our Cloudflare compatibility instructions (which don’t require their IPs as trusted proxies in Wordfence) are here: https://www.wordfence.com/help/advanced/compatibility/#cloudflare-compatibility
When you say that you still see the false-positives in the WAF, are you seeing IPs used by your host or server blocked in your Live Traffic page? Or are you referring to a different error message somewhere in the plugin?
Thanks again,
Peter.
Thread Starter
awack
(@awack)
even though we have had extensive discussion with LW, i think they are “Something is setting the correct IP address for the site already, which is why your IP is shown under REMOTE_ADDR.” So Should I leave it at remote then? Or Run it as X forward?
Life Traffic False Positives, looks like most are bots scanning for content.
Hi @awack,
Do you have an example of a hit you believe to be a false-positive with the feedback about why the WAF blocked it from Live Traffic? If there is a block, check the reason after expanding the entry with the eye icon in the corner. You can filter Live Traffic by “Blocked” so they’re easier to find. Some sites do see a lot of activity here though, even if the site isn’t widely-known.
It sounds like you might’ve been using the button in the scan result (or admin notice?) that says you should change the IP detection method originally. If REMOTE_ADDR wasn’t the correct option to choose, some hits could reach the site directly without going through Cloudflare. Access logs from the server might help us get a clear idea of the situation, especially if the WAF false-positives you share with us come from the same time period. If the IP in Live Traffic is different from the IP experiencing a 403 at the same timestamp (in the access logs), it would be a good comparison. Your host may be able to provide you with these if you can’t already get them from your hosting panel or filesystem.
Many thanks,
Peter.
Thread Starter
awack
(@awack)
Peter, i feel like my question is just not going to get an answer?
“So Should I leave it at remote then? Or Run it as X forward?”
The False positives seem to be undercontrolled now assuming i can believe what WF is telling me about the Ips its seeing.
Thank you !
Hi @awack,
We can’t answer the question definitively if we don’t know whether the host are setting REMOTE_ADDR based on other headers, so that’s why I was asking more questions.
If you think it’s working correctly with REMOTE_ADDR, that’s fine to continue using. If your host prefers or insists on X-Forwarded-For though, it looked to me like both of those headers were detecting the visitor IP correctly, it’s just the latter can be easier to spoof.
Thanks again,
Peter.
