Skip to content

X-Forwarded-For from reverse proxy is not respected by container Nginx #130

Closed

Description

@melyux

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

  1. Run linuxserver/letsencrypt and use the /config/nginx/proxy-confs/nextcloud.subdomain.conf.sample to set up Nextcloud's nginx block.
  2. 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',
  ),
...
  1. 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

  1. Technikte commented on Jan 31, 2020

    @Technikte

    +1 and if possible nextcloud should use the user's real IP for the onboard login anti brute force stuff..like delayed login.

  2. aptalca commented on Jan 31, 2020

    @aptalca
    Member

    I've been giving this some thought.

    set_real_ip_from 172.16.0.0/12; does not cover all docker networks, but set_real_ip_from 172.0.0.0/8; would

    Most 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 a X-Forwarded-For header 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).

  3. aptalca commented on Jan 31, 2020

    @aptalca
    Member

    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

        set_real_ip_from 172.0.0.0/8;
        real_ip_header X-Forwarded-For;
    
  4. aptalca commented on Mar 3, 2020

    @aptalca
    Member

    This was implemented in #133

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions