Where to find access log with attacker IP addresses in docker enviroment

Hello,

I am logging with Caddyfile to file and it is logging as expected. But all log entries are from
handled request {“request”: {“remote_ip”: “172.17.0.1”,

How can I force showing the real IP?

Thanks


  log    {
       output file  /data/log/nextcloud.log
       format console {
              time_format wall_milli
              }
  }

Please fill out the help topic template, as per the forum rules.

It’s hard to give a precise answer without seeing complete details of your setup.

1 Like

1. Output of caddy version:

[2.6.2]

2. How I run Caddy:

in a docker container on a debian host

a. System environment:

Docker version 20.10.5+dfsg1, build 55c4c88
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye

b. Command:

docker run -d \
  --name caddy \
  --restart=always \
 --net=host \
  -v /var/docker/config/caddy/caddyfile:/etc/caddy/ \
  -v /var/docker/config/caddy/data:/data \
  -v /var/docker/config/caddy/config:/config \
  -v /media/daten/WEBSERVICEDATEN/caddy/www/:/srv \
  -p 80:80 \
  -p 443:443 \
  -e ACME_AGREE=true \
  caddy:2.6.2

c. Service/unit/compose file:

see above

d. My complete Caddy config:

#NEXTCLOUD on SRV-WEB - external
nc.broehlis.de {
 reverse_proxy  192.168.100.13:8020
  tls ycsadssca@yahoo.com
  encode gzip

  redir /.well-known/carddav /remote.php/dav 301
  redir /.well-known/caldav /remote.php/dav 301
  redir /.well-known/webfinger /index.php/.well-known/webfinger 301
  redir /.well-known/nodeinfo /index.php/.well-known/nodeinfo 301

  header {
         Referrer-Policy             strict-origin-when-cross-origin
         X-Content-Type-Options      nosniff
         X-Frame-Options             SAMEORIGIN
  }
  reverse_proxy nextcloud

  log    {
       output file  /data/log/nextcloud.log
       format console {
              time_format wall_milli
              }
  }

}

3. The problem I’m having:

I am logging with Caddyfile to file and it is logging as expected. But all log entries are from
handled request {“request”: {“remote_ip”: “172.17.0.1”,

How can I force showing the real IP?

4. Error messages and/or full log output:

 2022/11/06 12:47:13.187 INFO    http.log.access.log2    handled request {"request": {"remote_ip": "127.0.0.1", "remote_port": "55668", "proto": "HTTP/1.1", "method": "PROPFIND", "host": "nextcloud.broehlis.de", "uri": "/remote.php/dav/files/homer/", "headers": {"Accept": ["*/*"], "Content-Type": ["text/xml; charset=utf-8"], "X-Request-Id": ["3eb54063-3acc-462d-a4d8-d1d717e53829"], "Accept-Encoding": ["gzip, deflate"], "Authorization": [], "User-Agent": ["Mozilla/5.0 (Windows) mirall/3.4.0stable-Win64 (build 20211129) (Nextcloud, windows-10.0.19043 ClientArchitecture: x86_64 OsArchitecture: x86_64)"], "Connection": ["Keep-Alive"], "Accept-Language": ["de-DE,en,*"], "Depth": ["0"], "Cookie": [], "Content-Length": ["105"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "nextcloud.broehlis.de"}}, "user_id": "", "duration": 0.066967329, "size": 251, "status": 207, "resp_headers": {"Expires": ["Thu, 19 Nov 1981 08:52:00 GMT"], "X-Request-Id": ["HJmnXPuHzu39BTCaatuT"], "X-Debug-Token": ["HJmnXPuHzu39BTCaatuT"], "Referrer-Policy": ["strict-origin-when-cross-origin"], "Dav": ["1, 3, extended-mkcol, access-control, calendarserver-principal-property-search, nextcloud-checksum-update, nc-calendar-search, nc-enable-birthday-calendar"], "Content-Security-Policy": ["default-src 'none';"], "Date": ["Sun, 06 Nov 2022 12:47:13 GMT"], "Server": ["Caddy", "nginx/1.20.2"], "X-Powered-By": ["PHP/7.4.26"], "Vary": ["Brief,Prefer"], "Content-Encoding": ["gzip"], "Content-Type": ["application/xml; charset=utf-8"], "Cache-Control": ["no-store, no-cache, must-revalidate"], "X-Content-Type-Options": ["nosniff"], "X-Frame-Options": ["SAMEORIGIN"], "Pragma": ["no-cache"], "Alt-Svc": ["h3=\":443\"; ma=2592000"]}}

5. What I already tried:

se my issue description

6. Links to relevant resources:

1 Like

You can remove this, this was only needed in Caddy v1.

Yuo have reverse_proxy twice in your site. Only the first one will do anything! Remove the other one.

Ah, that explains it then. Sometimes, Docker enables a userland proxy, which has the side effect of making the TCP packets look like they’re coming from the Docker daemon itself. See dockerd | Docker Docs. You can turn that off in your /etc/docker/daemon.json which should fix the problem of Caddy not seeing your real client IP.

There’s a long thread about the problem here Document how to get real remote client ip for service running in container · Issue #15086 · moby/moby · GitHub

2 Likes

I tried to add userland-proxy false to daemon.json incl reboot but the logs did not change.
The long threat includes some solutions with trafik settings. Would this be possible with caddy too?

Did you reboot the docker daemon itself? You need to do that for changes to take effect.

I’m not sure what else to suggest. You’re sure you don’t have some other TCP proxy of somekind in front of Caddy? No Cloudflare or whatever?

Yes I restarted the deamon itself too.

Your question makes me thinking. Due to a DS-Lite I only have a IPv6 Address. So I am using a Virtual Server with a revers ssh tunnel to get use of it’s fixed IPv4 address. Can this be an issue in my case?

That could be it. I’m not an expert on that aspect though. I’m not sure.

Can you try to make a request to your container with curl from the same machine? If you do, your logs should probably show something like 127.0.0.1 instead, if Docker is not the problem and something else is.

I missed something, sorry.

My error log from post 3 lasted till 06th Nov. I changed then the docker command and added to the docker comand for caddy-container from post 3 “–net=host”

This lead to a different but not solved log:

handled request {"request": {"remote_ip": "127.0.0.1", "remote_port": "34130", "proto": "HTTP/1. 1", "method": "GET",

This Entry change from docker ip to 127.0.0.1

The change in docker daemon.json did not show an effect.

I think this is a limitation of using SSH tunnels – I asked around and that’s the likely culprit. It looks like it comes from localhost, because technically it is, since the SSH tunnel is acting as a proxy.

I’m not sure what to suggest. Maybe you could try wireguard? Might work more transparently than an SSH tunnel.

2 Likes

This topic was automatically closed after 30 days. New replies are no longer allowed.