• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Running plesk bin apache --listen-on-localhost true breaks PHP $_SERVER["SERVER_ADDR"];

danami

Silver Pleskian
Username:

TITLE

Running plesk bin apache --listen-on-localhost true breaks PHP $_SERVER["SERVER_ADDR"];

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Product version: Plesk Obsidian 18.0.56.2
OS version: AlmaLinux 9.2 x86_64
Build date: 2023/10/26 16:00
Revision: efc2bfd78637f11b087afdee6d383b777ff03a12

PROBLEM DESCRIPTION

After enabling the Apache listen on localhost with:
Code:
plesk bin apache --listen-on-localhost true

The PHP $_SERVER["SERVER_ADDR"] reports as "127.0.0.1" instead of the real server address. This breaks any PHP scripts that used the $_SERVER["SERVER_ADDR"]. (Like WHMCS license checks).

STEPS TO REPRODUCE

Run:
Code:
plesk bin apache --listen-on-localhost true

Run this PHP code:
Code:
<?php var_dump($_SERVER["SERVER_ADDR"]); ?>

ACTUAL RESULT

Only 127.0.0.01 is displayed: E.g
["SERVER_ADDR"]=> string(9) "127.0.0.1"

EXPECTED RESULT

It should report the real server address: E.g.
["SERVER_ADDR"]=> string(9) "192.168.1.123"

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
Some additional information from other users:

Code:
$_SERVER['REMOTE_ADDR'] is showing (127.0.0.1) localhost
$_SERVER['SERVER_ADDR'] is showing (127.0.0.1) localhost
$_SERVER['HTTP_X_FORWARDED_FOR'] is showing correct IP address of the server
$_SERVER['HTTP_X_REAL_IP'] is showing the correct IP address of the server
 
That'll be a challenge, because where should PHP know the real outside world address from when Apache only knows its next peering point Nginx? In my opinion the behavior is a correct consequence of the setting where Apache is shielded against other ports. It is what must be expected when Apache's world is limited to 127.0.0.1. It would be the same situation in a local network where a proxy delivers requests to the server. In such a case Apache would only know the proxy as a source of requests. Where should Apache look instead? The next proxy, e.g. Nginx? Or the next proxy in a LAN that comes between Nginx and the Internet? And how should it obtain that information?

So as I understand it here is that on the one hand, Apache must only react to requests coming from 127.0.0.1, yet it must return the real IP address of the request origin to PHP.

Filed as internal ID PPS-15149. It'll be interesting to see what developers make out of this case.
 
@Peter Debik Yes I agree that there isn't a way for Plesk developers to fix this. The big problem is that there are so many PHP applications that can't handle this new change. Webpros own WHMCS breaks entirely as it invalidates the their WHMCS license checks and remote client logging. My take is that this new functionality really shouldn't be enabled by default on new Plesk installs unless the administrator knows about these new limitations.
 
That'll be a challenge, because where should PHP know the real outside world address from when Apache only knows its next peering point Nginx?
Why, the same way it does when apache binds to the server's outside IP instead of loopback?
That's what mod_remoteip is for.
Like I wrote already, this is a misconfiguration of mod_remoteip. It must be told which servers set a trustworthy X-Forwarded-For:, otherwise anyone could make a request with this header already set and trick apache into using that address as the remote host. In our case, all requests incoming from 127.0.0.1 must come from a trustworthy source; we know that, but mod_remoteip must be explicitly told that it is:

At the end of /etc/apache2/plesk.conf.d/server.conf, there needs to be 127.0.0.1 added to the line RemoteIPInternalProxy.

At the moment, there is only the server's outside IP listed, which allowed mod_remoteip to rewrite requests that came from nginx connecting from that IP. Now that nginx uses 127.0.0.1, that IP must be put in there instead.
@Peter Debik Yes I agree that there isn't a way for Plesk developers to fix this.
Nope, it's actually pretty easy.
 
Why, the same way it does when apache binds to the server's outside IP instead of loopback?
That's what mod_remoteip is for.
Like I wrote already, this is a misconfiguration of mod_remoteip. It must be told which servers set a trustworthy X-Forwarded-For:, otherwise anyone could make a request with this header already set and trick apache into using that address as the remote host. In our case, all requests incoming from 127.0.0.1 must come from a trustworthy source; we know that, but mod_remoteip must be explicitly told that it is:

At the end of /etc/apache2/plesk.conf.d/server.conf, there needs to be 127.0.0.1 added to the line RemoteIPInternalProxy.

At the moment, there is only the server's outside IP listed, which allowed mod_remoteip to rewrite requests that came from nginx connecting from that IP. Now that nginx uses 127.0.0.1, that IP must be put in there instead.

Nope, it's actually pretty easy.
I have enabled apache to only listen on localhost as ports 7080 and 7081 were being exposed as shown Resolved - SECURITY - attack surface : ports 7080 and 7081. Now awstats appears to have stopped working.

I am a bit confused by your statement. Please can you elaborate how I can get working again?

What is the best practice here to ensure Plesk, site and awstats are working correctly?
 
/etc/nginx/plesk.conf.d/server.conf does

#ATTENTION!
#
#DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
#SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.

include "/etc/nginx/plesk.conf.d/ip_default/*.conf";
 
How does this make sense?

Question​

How can I use the new feature in Plesk 18.0.56 that allows Apache Web Server to listen on localhost on ports 7080 and 7081?

Answer​

In Plesk 18.0.56, we introduced a new feature (PPP-43250) that allows Apache Web Server to listen on localhost on ports 7080 and 7081. This feature was introduced as a security improvement to reduce the attack surface by ensuring that Apache is no longer publicly accessible on these ports, thereby enhancing the overall security of your server.

This answer seems contradictory as well?

What am I missing?

You state that exposing ports 7080 and 7081 improves security, but at the same time state that this feature was introduced to make these ports no longer available to improve the security of the server. Which is it?
 
What am I missing?
I agree it's not the best written knowledge base article. Pre Plesk version .56 Apache was accessible on these port publicly, after Plesk version .56 Apache is only locally accessible on these ports by default (for new installations that is).
 
I agree it's not the best written knowledge base article. Pre Plesk version .56 Apache was accessible on these port publicly, after Plesk version .56 Apache is only locally accessible on these ports by default (for new installations that is).
If I am reading this correctly it seems Plesk have changed the default in 18.0.56 and have changed again in 18.0.56.3. Not sure if anything else has changed?

The fix to change the default seems to have undesirable consequences either way.
 
I have enabled apache to only listen on localhost as ports 7080 and 7081 were being exposed as shown Resolved - SECURITY - attack surface : ports 7080 and 7081. Now awstats appears to have stopped working.
Why do you think that AWStats is in any way linked to the ports that the web server uses? AWStats is a log analyzer. It takes data from access_ssl_log, access_log and accumulates to make website statistics out of it. These logs are filled regardless of the port on which the web server listens. If AWStats does not work correctly, please open a new thread on why your AWStats stopped working, how you noticed it (what the exact symptoms are).
 
Why do you think that AWStats is in any way linked to the ports that the web server uses? AWStats is a log analyzer. It takes data from access_ssl_log, access_log and accumulates to make website statistics out of it. These logs are filled regardless of the port on which the web server listens. If AWStats does not work correctly, please open a new thread on why your AWStats stopped working, how you noticed it (what the exact symptoms are).
Yeah sorry my bad.

I think it just a delay after running plesk sbin statistics --calculate-all

Stats do appear to be there.

That said I also have metrics on the site and if nginx is serving the page without touching apache then it could also affect impressions on those pages. Not sure.
 
Username:

TITLE


Running plesk bin apache --listen-on-localhost true breaks PHP $_SERVER["SERVER_ADDR"];

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Product version: Plesk Obsidian 18.0.56.2
OS version: AlmaLinux 9.2 x86_64
Build date: 2023/10/26 16:00
Revision: efc2bfd78637f11b087afdee6d383b777ff03a12

PROBLEM DESCRIPTION

After enabling the Apache listen on localhost with:
Code:
plesk bin apache --listen-on-localhost true

The PHP $_SERVER["SERVER_ADDR"] reports as "127.0.0.1" instead of the real server address. This breaks any PHP scripts that used the $_SERVER["SERVER_ADDR"]. (Like WHMCS license checks).

STEPS TO REPRODUCE

Run:
Code:
plesk bin apache --listen-on-localhost true

Run this PHP code:
Code:
<?php var_dump($_SERVER["SERVER_ADDR"]); ?>

ACTUAL RESULT

Only 127.0.0.01 is displayed: E.g
["SERVER_ADDR"]=> string(9) "127.0.0.1"

EXPECTED RESULT

It should report the real server address: E.g.
["SERVER_ADDR"]=> string(9) "192.168.1.123"

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
With the following

<?php
var_dump($_SERVER["SERVER_ADDR"]);
var_dump($_SERVER["REMOTE_ADDR"]);
var_dump($_SERVER["HTTP_X_FORWARDED_FOR"]);
var_dump($_SERVER["HTTP_X_REAL_IP"]);
?>

When set to true I am getting:

string(9) "127.0.0.1" string(12) "81.xx.146.69" NULL string(12) "81.99.146.69"

When set to false

string(14) "yy.yy.yy.yy" string(12) "81.xx.146.69" NULL string(12) "81.xx.146.69" where yy.yy.yy.yy is my server IP address.

On my local it is like

string(13) "192.168.160.9" string(14) "192.168.160.11" string(13) "192.168.160.1" string(13) "192.168.160.1"
 
This is correct, but the AWStats issue with the localhost address was resolved in 18.0.56 #3. Are you using the latest Plesk version?
 
This is correct, but the AWStats issue with the localhost address was resolved in 18.0.56 #3. Are you using the latest Plesk version?
Version 18.0.57 Update #5, last updated on Dec 21, 2023 03:05 AM

AWstats does seem to be working now, albeit with a bit of delay which I think is normal as this is probably on a 24hr cron job. Sorry false negative.

Not sure there was the same delay before forcing localhost?

Also I had another issue on site but I think that turned out to be another issue after further investigation.

Thanks for confirming my output is good.
 
Back
Top