• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

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

danami

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.
 
Peter Debik said:
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?
Click to expand...
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.
danami said:
@Peter Debik Yes I agree that there isn't a way for Plesk developers to fix this.
Click to expand...
Nope, it's actually pretty easy.
 
mow said:
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.
Click to expand...
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.
Click to expand...

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?
 
2dareis2do said:
What am I missing?
Click to expand...
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).
 
Kaspar said:
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).
Click to expand...
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.
 
2dareis2do said:
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.
Click to expand...
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).
 
Peter Debik said:
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).
Click to expand...
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.
 
danami said:
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
Click to expand...
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?
 
Peter Debik said:
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?
Click to expand...
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.
 
You must log in or register to reply here.

Similar threads

HoracioS
Issue I can't enable Smart static files
Replies
4
Views
734
HoracioS
HoracioS
TorbHo
Resolved How to get ip address with apache listening to localhost
Replies
6
Views
948
TorbHo
TorbHo
E
After using Plesk to upgrade Mariadb from 10.5 to 10.11 Wordpress and other apps can no longer connect to 'localhost'
Replies
2
Views
642
Peter Debik
P
2
Issue index.php prepended to Drupal 10.1.x admin paths when running PHP as FPM Application served via Apache
Replies
3
Views
577
2dareis2do
2
T
Resolved SECURITY - attack surface : ports 7080 and 7081
2
Replies
30
Views
11K
2dareis2do
2
Back
Top