Increased Attack Rate, why from 127.0.0.1?

Hi @elnath78

IP 127.0.0.1 is the loopback IP address and is for something in your server environment such as a reverse proxy.

Either Wordfence isn’t configured correctly to detect visiting client IP addresses:

https://www.wordfence.com/help/dashboard/options/#get-ips

Or, something running on your server is not correctly forwarding on visiting client IP addresses.

I would also like to have a look at your Wordfence diagnostics report. Please go to the top of the “Diagnostics” tab on the Wordfence “Tools” page. There will be a “SEND REPORT BY EMAIL” button to send the diagnostics report. Enter wftest [@] wordfence [dot] com as the email and elnath78 as the forum username please.

Hello @wfphil,

Im sending the emails right now from both the affected domains, here is a capture of the hack attemp for public view instead:

https://share.creoweb.it/7c64e108.jpg

Hi @elnath78

Before I saw your diagnostics report I suspected that your site is hosted at Cloudways. I see that both sites are hosted at Cloudways.

Wordfence appears to be detecting visiting IP address correctly. You can double check this by checking your IP address in this link below:

https://www.whatsmyip.org/

Now check the line Your IP with this setting in the How does Wordfence get IPs subsection in the General Wordfence Options section on the All Options page.

If the IP addresses match then what we have seen recently is Cloudways are using Varnish reverse proxy caching and Varnish is not always passing on correct visiting client IP addresses and thus Wordfence sometimes sees the 127.0.0.1 IP address of Varnish instead of the correct visiting client IP addresses.

You will have to ask Cloudways to investigate this intermittent issue as we have seen several cases of this.

Hi @wfphil,

They have Varnish enabled I think by default and I also have .htaccess rewrites on SSL websites. What surprises me is that all the hack/exploit attemps were not detected, coincidence? Or do they know a way to “exploit” the detection of their IP?

Like in what cases varnish fails in detecting the IP? Is there something that I should do to keep sleeping well and not worry about this?

Hi @elnath78

Thank you for the reply.

You will need to speak to Cloudways support about this intermittent issue and why the X-REAL-IP HTTP header is being set for some hits to your site and not others.

It appears from what we have seen before that Varnish hasn’t been configured correctly.

Thank you.

Hi @wfphil,

This is their answer, I don’t know if this is something “normal” or if they should just configure the Varnish differently. I start wondering on their reliability as hosting service, probably a good moment to get some more feedback about them:

“We would like to inform you that the following in the access logs are being showed because of the reverse proxy. You can easily easily fix that by adding this real IP code in the wp-config.php file of your application. Following is the code:”

# Use X-Forwarded-For HTTP Header to Get Visitor's Real IP Address
 
if ( isset( $_SERVER['HTTP_X_FORWARDED_FOR'] ) ) {
    $http_x_headers = explode( ',', $_SERVER['HTTP_X_FORWARDED_FOR'] );

    $_SERVER['REMOTE_ADDR'] = $http_x_headers[0];
}

Addiditonal Cloudways comment:

“I’d like to inform you that there is no issue from varnish configuration’s end and the local IP should be appear due to REMOTE_ADDR header and if you are using any plugin or any application then you can change the header value from REMOTE_ADDR to HTTP_X_FORWARDED_FOR or HTTP_X_REAL_IP and you are able to see the real IP accordingly.“

Hi @elnath78

If you use the X-REAL-IP setting in Wordfence then you shouldn’t be seeing 127.0.0.1 as the IP address intermittently in Live Traffic.

If you do use the code that Cloudways provided then it must be added to the wordfence-waf.php file if the firewall is in Extended Protection mode, or the WordPress wp-config.php file if the firewall is in Basic Protection Mode. Both files are in the root directory of your WordPress installation. You will need to set the Wordfence setting Use the X-Forwarded-For HTTP header. Only use if you have a front-end proxy or spoofing may result. It may be possible for an attacker to spoof their IP address with that code though.

Hi Phil (@wfphil),

> You will need to set the Wordfence setting Use the X-Forwarded-For HTTP header.

The code actually splits the HTTP_X_FORWARDED_FOR header and puts its first value into REMOTE_ADDR are you sure that with this code I should se to use HTTP_X_FORWARDED_FOR?

Also if I read it right, I should set X-REAL-IP as you suggested, is this option safe from spoofing considering my hosting and Varnish?

Hi @elnath78

I have an update from the team for you.

If you save the Wordfence option Use the X-Real-IP HTTP header. Only use if you have a front-end proxy or spoofing may result instead of the option Let Wordfence use the most secure method to get visitor IP addresses. Prevents spoofing and works with most sites then it should prevent Wordfence from seeing the incorrect 127.0.0.1 IP address and consistently see correct IP addresses visiting your site.

Therefore, you can remove the additional code provided from Cloudways and not have to use the Wordfence option Use the X-Forwarded-For HTTP header. Only use if you have a front-end proxy or spoofing may result.

Thanks.

Hi @wfphil,

Do you have an idea on why only XSS and similar attacks are able to spoof their IP into 127.0.0.1 where normal brute force attacks doesnt?

Hi @elnath78

It appears that the option Let Wordfence use the most secure method to get visitor IP addresses. Prevents spoofing and works with most sites. (Recommended) wasn’t always working correctly so you should no longer see any visits from IP 127.0.0.1 if you have set the Use the X-Real-IP HTTP header. Only use if you have a front-end proxy or spoofing may result setting.

• This reply was modified 5 years, 3 months ago by wfphil.

Hi @elnath78

I thought I would send you a follow up.

If you followed the instructions in my last reply and set the Use the X-Real-IP HTTP header. Only use if you have a front-end proxy or spoofing may result setting, did this resolve it and you have no longer seen any more visits from IP 127.0.0.1?

Thank you.

@wfphil

Hello,

Since you last reply was not answering my previous question but rather looked like a canned response, I was not sure how to consider it. However it seems XSS attacks have ended.

Hi @elnath78

Thnak you for the update that it is resolved.

It was certainly not a canned response. You asked why attackers were able to spoof their IP and I replied that the option Let Wordfence use the most secure method to get visitor IP addresses. Prevents spoofing and works with most sites. (Recommended) wasn’t always working correctly so you should no longer see any visits from IP 127.0.0.1 if you have set the Use the X-Real-IP HTTP header. Only use if you have a front-end proxy or spoofing may result setting.