Repository navigation
X-Forwarded-For from reverse proxy is not respected by container Nginx #130
Description
Expected Behavior
Container's nginx logs should indicate the user's real IP, not the private IP of the reverse proxy (linuxserver/letsencrypt), as should the brute force logs.
Current Behavior
The container's nginx logs show every connection as coming from the reverse proxy's IP instead of the true origin of the connection (given by X-Forwarded-For headers). This makes filtering brute force attempts impossible.
Similar to nextcloud/docker#294. I was able to solve it in this container as well by editing /config/nginx/site-confs/default in the container and adding the following lines to the location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+|ocm-provider\/.+)\.php(?:$|\/) { block:
set_real_ip_from 10.0.0.0/8;
set_real_ip_from 172.16.0.0/12;
set_real_ip_from 192.168.0.0/16;
real_ip_header X-Forwarded-For;
This is also an issue in the linuxserver/unifi-controller container (events show all logins as coming from linuxserver/letsencrypt's internal, private IP address), it seems, but this particular issue looks like something that Ubiquiti has to fix on their end (and has been skimping on for years), from what I gathered. Luckily, for this Nextcloud container, it seems to be easily solved by adding the lines above.
Steps to Reproduce
- Run linuxserver/letsencrypt and use the
/config/nginx/proxy-confs/nextcloud.subdomain.conf.sampleto set up Nextcloud's nginx block. - Run linuxserver/nextcloud and use the typical setup for config.php:
...
'trusted_domains' =>
array (
0 => 'nextcloud.example.com',
),
'trusted_proxies' =>
array (
0 => '172.16.0.0/12',
),
...
- Look at the Nextcloud logs in /config/log/nginx/access.log and check the IP addresses.
Environment
OS: Debian Buster
CPU architecture: x86_64
How docker service was installed: docker-compose
Command used to create docker container (run/create/compose/screenshot)
-------------------------------------
_ ()
| | ___ _ __
| | / __| | | / \
| | \__ \ | | | () |
|_| |___/ |_| \__/
Brought to you by linuxserver.io
We gratefully accept donations at:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------
User uid: 1000
User gid: 1000
-------------------------------------
[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 20-config: executing...
[cont-init.d] 20-config: exited 0.
[cont-init.d] 30-keygen: executing...
using keys found in /config/keys
[cont-init.d] 30-keygen: exited 0.
[cont-init.d] 40-config: executing...
[cont-init.d] 40-config: exited 0.
[cont-init.d] 50-install: executing...
[cont-init.d] 50-install: exited 0.
[cont-init.d] 60-memcache: executing...
[cont-init.d] 60-memcache: exited 0.
[cont-init.d] 99-custom-files: executing...
[custom-init] no custom files found exiting...
[cont-init.d] 99-custom-files: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Activity
Technikte commentedon Jan 31, 2020
+1 and if possible nextcloud should use the user's real IP for the onboard login anti brute force stuff..like delayed login.
aptalca commentedon Jan 31, 2020
I've been giving this some thought.
set_real_ip_from 172.16.0.0/12;does not cover all docker networks, butset_real_ip_from 172.0.0.0/8;wouldMost importantly, we have to think about any potential implications for people not using it behind a reverse proxy and accessing the container directly.
For instance, if one is on a local 192.168.x.x and connects to the container directly, having
set_real_ip_from 192.168.0.0/16;is going to screw things up as there won't be aX-Forwarded-Forheader set.On the other hand, setting
set_real_ip_from 192.168.0.0/16;would only be beneficial if one is reverse proxying over the host mapped port (maybe not on the same docker network, or maybe on another machine).aptalca commentedon Jan 31, 2020
Perhaps we just add the following to cover the basics, users reverse proxying via docker network, which is what we recommend, others can manually edit since the file resides in the config folder
aptalca commentedon Mar 3, 2020
This was implemented in #133