Help debug trusted_proxies with more verbose output

[klemenkobetic]

Is your feature request related to a problem? Please describe.
I lost a lot of time trying to debug trusted_proxies. Help debug trusted_proxies with more verbose output.

Describe the solution you'd like

The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy. If not, this is a security issue and can allow an attacker to spoof their IP address as visible to the Nextcloud. Further information can be found in the [documentation ↗](https://docs.nextcloud.com/server/24/go.php?to=admin-reverse-proxy).

I belive this comes from the function 'forwardedForHeadersWorking' which is in './apps/settings/lib/Controller/CheckSetupController.php' file, starting in line 351.

I'm thinking if the output could be a little bit more clear, showing the wrong url. Prepending the upper message with something like 'URL 'https://example.com' is not in the trusted_proxies hosts.'

[kesselb]

Did you mean trusted_domains?

[klemenkobetic]

Sry, trusted_proxies.

[bernd-wechner]

I am seeing this same message:

The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy.

And I don't like it. It's not clear enough and the bold bit is concerning. I am indeed accessing Nextcloud form a trusted proxy. As best I understand it because my server is running behind a NAT firewall and a reverse proxy forwards requests to the Nextcloud server (and any number of other web services here too) I followed this:

https://docs.nextcloud.com/server/27/admin_manual/configuration_server/reverse_proxy_configuration.html

and configured my system appropriately. config.php contains:

  'trusted_proxies' =>
  array (
    0 => '192.168.0.1',
    1 => '192.168.0.11',
  ),

Because the first is the gateway running a reverse proxy and the second is just a desktop on the LAN that I test from.

Basically, if I have elected to run from behind a trusted proxy this is a configured a fine situation and I don't want to see a concerning amber warning.

Looking into it here's the code that runs:

server/apps/settings/lib/Controller/CheckSetupController.php

Line 290 in 3c0b417

private function forwardedForHeadersWorking(): bool {

and returns false to trigger the warning.

From which I must conclude, given I have set trusted_proxies to be an array, that: $this->request->getHeader('REMOTE_ADDR') is not in the array and that $this->request->getHeader('REMOTE_ADDR') == $this->request->getRemoteAddress(). What am I to make of this. I would be awesome to see the values of $this->request->getHeader('REMOTE_ADDR') and $this->request->getRemoteAddress(). Don't know if I'll find/make time to set up PHP debugging .... we shall see.

I'd love to know if I'm reading the logic right here, and why I'm getting a False back for a properly configured reverse proxy.

[joshtrichards]

@klemenkobetic:

I'm thinking if the output could be a little bit more clear, showing the wrong url. Prepending the upper message with something like 'URL 'https://example.com/' is not in the trusted_proxies hosts.'

The URL isn't relevant for trusted_proxies. You may be confusing it with trusted_domains. The particular warning your reporting about here is triggered by an issue with your trusted_proxies (not domains) and one of the following scenarios:

1. the absence of trusted_proxies in your configuration... but the presence of proxy headers in your connections to Nextcloud Server

2. the presence of trusted_proxies in your configuration... but the HTTP socket IP address of the connection (REMOTE_ADDR) not matching any of the configured trusted_proxies (indicating a proxy connection that isn't listed in your trusted_proxies)

3. the presence of trusted_proxies in your configuration... but the socket IP address of the connection (REMOTE_ADDR) matching one of the configured trusted_proxies (which is fine)... and either the presence of proxy headers indicating you are connecting directly from the proxy (unusual outside of a lab setting) or a lack of proxy headers (indicating an IP is listed in your trusted_proxies that isn't really a proxy)

We should perhaps consider making the warning more specific, alluding to which of the above scenarios we detected I guess.

@bernd-wechner:

Because the first is the gateway running a reverse proxy and the second is just a desktop on the LAN that I test from.

Remove the desktop on the LAN that you test from if it's just a client device. It shouldn't be in your trusted_proxies. I'm guessing you ran the tests from this desktop. That would have triggered scenario three as described above in my reply to @klemenkobetic.

As best I understand it because my server is running behind a NAT firewall and a reverse proxy forwards requests to the Nextcloud server (and any number of other web services here too)

That's fine. Nothing strange about that.

Now if your proxy happens to be outside your NAT and if you happen to have a bunch of users (or just devices) accessing your Nextcloud from behind the same single NAT IP address (from your proxy's perspective) it's possible you might trigger some rate limiters (or brute force protection if any of those devices/users have invalid or expired passwords). But that's addressable by either:

a) Best: Using Split horizon DNS so that your internal LAN users don't leave your network and bypass any external proxy
b) If needed: Setting up an internal proxy along with (a) if deemed a requirement for your particular circumstances
b) Okay: Whitelisting your NAT IP address in your bruteforcesettings

I would be awesome to see the values of $this->request->getHeader('REMOTE_ADDR') and $this->request->getRemoteAddress()

REMOTE_ADDR will always contain the IP address of the HTTP socket connection (so whatever the last hop is - either the client's actual IP if no intermediate proxy or the proxy's IP if a proxy is involved in that connection).

The entire point of configuring trusted_proxies correctly is so that the getRemoteAddress() function can determine and provide the real client IP address - whether there is a proxy involved or not - to the various subsystems that need it (client IP address logging and brute force protection for example). If configured incorrectly, either all connections going through a proxy will appear to originate the from the same end-device IP address or client IP addresses become vulnerable to spoofing.

[bernd-wechner]

Thanks muchly. Will investigate. My timeline may be this week if I can squeeze it in or early December ... so bookmarking this.

[bernd-wechner]

Remove the desktop on the LAN that you test from if it's just a client device. It shouldn't be in your trusted_proxies. I'm guessing you ran the tests from this desktop. That would have triggered scenario three as described above in my reply to @klemenkobetic.

And kudos, removing my desktop PC's IP address from trusted proxies, restarting php, and then reloading the overview page and the error message was gone.

Alas, I cannot update.And I suspect it's failing because of this message on the overview:

Some files have not passed the integrity check. Further information on how to resolve this issue can be found in the documentation ↗. (List of invalid files… / Rescan…)

which is a direct consequence of this:

#40082

I may try unpatching that to try an update.

But it may not be the reason as:

[bernd-wechner]

Skip that. Turns out I just had to chown the whole web tree and the updated worked. I suspect my edit to the config file in fact left the permissions on it awry. One of those sudo risks.