Modify apache config to record forwarded IPs

[XenoPhage]

If you run this container behind a proxy, the access logs show the IP of the proxy and not the client. This can be corrected by updating the /etc/apache2/sites-enabled/000-default.conf config as follows:

<VirtualHost *:80>
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
	#ServerName www.example.com

	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html

	# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
	# error, crit, alert, emerg.
	# It is also possible to configure the loglevel for particular
	# modules, e.g.
	#LogLevel info ssl:warn

	ErrorLog ${APACHE_LOG_DIR}/error.log

	LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
	LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" proxy
	SetEnvIf X-Forwarded-For "^.*\..*\..*\..*" forwarded
	CustomLog ${APACHE_LOG_DIR}/access.log combined env=!forwarded
	CustomLog ${APACHE_LOG_DIR}/access.log proxy env=forwarded

	# For most configuration files from conf-available/, which are
	# enabled or disabled at a global level, it is possible to
	# include a line for only one particular virtual host. For example the
	# following line enables the CGI configuration for this host only
	# after it has been globally disabled with "a2disconf".
	#Include conf-available/serve-cgi-bin.conf
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Can this container be updated to do this by default instead of having to either rebuild it or add a volume?

[tianon]

Most of this configuration comes directly from Debian's default configuration -- we only make minor changes to it, if at all (and all of that comes from the php image, not something added in wordpress).

[XenoPhage]

Understood. This is simply a replacement config file to handle proxied communications with the container, which I would expect is a pretty common use case, and still provide the client IPs for logging purposes.

[hudsantos]

Also interested in a solution like this. But the /etc/apache2/apache2.conf says:

# Note that the use of %{X-Forwarded-For}i instead of %h is not recommended.
# Use mod_remoteip instead.

Also the snippet suggested by @XenoPhage and another form @brainlid on this issue didn't work for me.
So, I'm also still looking for another solution to tackle this.
As soon as I find something new I'll follow up here.

[gingerlime]

Also facing this problem using https://github.com/jwilder/nginx-proxy and wordpress in docker. The headers (X-Forwarded-For, X-Real-IP, X-forwaded-Proto etc) are being passed from nginx-proxy to the wordpress container correctly, but the logs still show the proxy's internal IP rather than the external client.

[chrisbloemker]

@gingerlime have you solved your issue yet? I'm running into a similar situation using Traefik. All the wordpress containers behind traffic are showing the internal IP of traefik rather than the external IP. This makes plugins useless that work by IP, aka whitelisting, security-based plugs etc. Still looking for a solution as I'm not convinced that the problem lies at the proxy level but rather the wordpress container level (apache).

[gingerlime]

@chrisbloemker It definitely looks like it's due to the way apache is set up for wordpress in docker. I haven't solved it yet (didn't find the time and it's not urgent for me, but I would definitely hope to find a simple solution).

[chrisbloemker]

@gingerlime I agree, I'm running a handful of wordpress containers and just realized this issue. I need to fix asap, but I'm not experienced with nginx and not so much apache :/ I'll keep looking. I'm surprised there's not much else talk on this problem. If I find a solution I'll keep you updated.

[gingerlime]

I think the changes that @XenoPhage originally suggested should work, but didn't get a chance to look at what it means to apply them in practice or test it.

[hudsantos]

I am also looking for a solution on it. Still facing this and didn't found a clever solution. Not a big problem here but should be better if the logged IP address was the external rather than the internal.

[XenoPhage]

FYI : This is pretty easy to test live without rebuilding a container if you want. Take the config file I provided above and docker cp it into your container :

docker cp 000-default.conf wordpresscontainer:/etc/apache2/sites-enabled/000-default.conf

And then just restart the container. Be careful not to remove (docker rm) the container first or it'll wipe out that change. Once it's restarted, check the logs and you can see whether the real IP is coming through or not.

If you want to make the change "permanent" you can use a docker volume to replace the file on start, or you can rebuild the container. The former solution works better if you want to continue getting updates from upstream, otherwise you have to monitor and rebuild on your own.

[gingerlime]

Thanks for the suggestion @XenoPhage. I managed to get the volume solution working for me.

In case it helps others, I'm using docker-compose and this is more or less how I overwrite the apache config in my docker-compose.yml

version: '3'
services:
  ...
  my_wordpress:
    image: wordpress:5
    environment:
      ...
    volumes:
      - /path/to/wordpress:/var/www/html
      - /path/to/000-default.conf:/etc/apache2/sites-enabled/000-default.conf

[XenoPhage]

For completeness, here's what I use for my wordpress containers. Note: This works for multisite as well if that's your thing.

version: '3.6'
services:
  wordpress:
    image: wordpress:latest
    container_name: wordpress
    restart: always
    volumes:
      - /srv/wordpress/wp-content:/var/www/html/wp-content:Z
      - /srv/wordpress/docker-php-upload-size.ini:/usr/local/etc/php/conf.d/docker-php-upload-size.ini:Z
      - /srv/wordpress/wp-config.php:/var/www/html/wp-config.php:Z
      - /srv/wordpress/.htaccess:/var/www/html/.htaccess:Z
      - /srv/wordpress/000-default.conf:/etc/apache2/sites-enabled/000-default.conf:Z
    labels:
      traefik.docker.network: "web"
      traefik.enable: true
      traefik.port: 80
      traefik.protocol: "http"
      traefik.frontend.rule: "Host:myblog.example.com"
      traefik.frontend.headers.customResponseHeaders: "X-Clacks-Overhead: GNU Terry Pratchett"
    networks:
      web:
        aliases:
          - wordpress
      database:
networks:
  web:
    external:
      name: web
  database:
    external:
      name: database

[chrisbloemker]

I will have to try that, @XenoPhage good suggestion. Slightly off topic, out of curiosity, what are the benefits to bind mounting the /srv/wordpress I'm assuming that would be a distributed FS like gluster or something if you're running multiple nodes?