APP_PROXIES works for Audit Log but does not work for NGinx error.log

[jducaud]

Describe the Bug

Setting the APP_PROXIES to * allows the Audit Log of BookStack to display the real IP address of the user.

In the security-topic documentation we can see:

An option is available to log failed login events to a log file which is useful to identify users having trouble logging in, track malicious login attempts or to use with tools such as Fail2Ban.

This option is LOG_FAILED_LOGIN_MESSAGE (set, as advised, to "Failed login for %u").

So one could logically think - as Fail2Ban is only effective if it has access to the IP address of the attacker - that APP_PROXIES and LOG_FAILED_LOGIN_MESSAGE are the perfect combo to track repeated failed login attempts.

That is not the case. The APP_PROXIES option works for Audit Log (as advertized in the BookStack 21.10 release notes), and the LOG_FAILED_LOGIN_MESSAGE option yields a message in the NGinx error.log as expected:

2022/08/03 22:55:12 [error] 226#226: *6 FastCGI sent in stderr: "PHP message: Failed login for john.doe@gmail.com" while reading response header from upstream, client: 172.23.0.1, server: _, request: "POST /login HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "book.myserver.org", referrer: "https://book.myserver.org/login"

But they do not yield an NGinx error message which can be used by Fail2Ban, as 172.23.0.1 is a Docker bridge interface IP address, not the user real address.

Steps to Reproduce

1. In the docker-compose.yml file, set APP_PROXIES to *
2. In the docker-compose.yml file, set LOG_FAILED_LOGIN_MESSAGE to "Failed login for %u"
3. Generate and start your containers (BookStack and MariaDB)
4. Try to log in with bad credentials into BookStack
5. Have a look at the NGinx error.log file

Expected Behaviour

Setting both APP_PROXIES and LOG_FAILED_LOGIN_MESSAGE should yield a message with the real IP address of the user in the NGinx error.log file.

We could also imagine that beside the %u variable in the failed login message, there could also be a %i variable for the IP address.

Screenshots or Additional Context

No response

Browser Details

Firefox 103.0 (64-bit) - Windows 11 Home (10.0.22000)

Exact BookStack Version

22.07.1 (LinuxServer.io 22.07.1-ls29)

PHP Version

7.4.26

Hosting Environment

• Synology DS218+ DSM 6.2.4-25556 Update 6
• DSM NGinx 1.16.1 (https://book.myserver.org -> http://localhost:9580)
• DSM Docker 20.10.3: docker-compose.yml:
  • services: image: lscr.io/linuxserver/bookstack, ports: 9580:80, networks: bookstack_mariadb
  • services: image: lscr.io/linuxserver/mariadb, ports: 3306:3306, networks: bookstack_mariadb
  • networks: bookstack_mariadb, driver: bridge

[ssddanbrown]

Hi @jducaud,
I don't want to complicate the LOG_FAILED_LOGIN_MESSAGE system if possible, since it's really a rarely used feature.
I think the fundamental request can be achieved on the nginx side like described here:

https://serverfault.com/questions/896130/possible-to-log-x-forwarded-for-to-nginx-error-log

[jducaud]

Hi @ssddanbrown,

Thank you for this link. Luckily, the Nginx version of the LinuxServer.io BookStack container has been built with the ngx_http_realip_module! So I added to the server context of Nginx the following lines:

	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;
	real_ip_recursive on;

And it worked. The Nginx error.log now displays the real user IP address. Thank you very much for your advice.

If I may, I would say that the BookStack documentation I quoted should be fixed. Indeed, in any case, the LOG_FAILED_LOGIN_MESSAGE option is not useful for Fail2Ban. Thanks to the APP_PROXIES option, it could have been useful for Fail2Ban but it is actually not. My feeling about this LOG_FAILED_LOGIN_MESSAGE option is that it has no real-life use and has missed its original intended purpose. Too bad.

Anyway, you brilliantly saved me. Thank you again!

[ssddanbrown]

Good to know things are working

Thanks to the APP_PROXIES option, it could have been useful for Fail2Ban but it is actually not. My feeling about this LOG_FAILED_LOGIN_MESSAGE option is that it has no real-life use and has missed its original intended purpose. Too bad.

I don't really understand. What makes you say this? How does it miss the intended purpose?

[jducaud]

When I say "the LOG_FAILED_LOGIN_MESSAGE option (...) has no real-life use and has missed its original intended purpose", I refer to the BookStack documentation (security topic):

Failed Access Logging: An option (LOG_FAILED_LOGIN_MESSAGE) is available to log failed login events to a log file which is useful to identify users having trouble logging in, track malicious login attempts or to use with tools such as Fail2Ban.

The original intent - if I read correctly - was to allow the use of tools such as Fail2Ban. Well, the LOG_FAILED_LOGIN_MESSAGE option is useless for tools such as Fail2Ban, as it does not provide a way to get the real IP address of the user/attacker in the logs.

That makes me think this option has only made half of the trip. It yields a message (calling the php error_log function) in the Nginx error.log file but only provides a %u variable, useless to effectively ban an IP address. The other half of the trip has to be done by the elegant workaround you gave me (Nginx real-IP module).

[ssddanbrown]

The LOG_FAILED_LOGIN_MESSAGE option does not log an IP address itself, since it almost always logs to locations that themselves will contain the IP address. The nginx addition here was only needed because you're in a proxy-based setup. This is not a required step in a non-proxy setup.

Stating My feeling about this LOG_FAILED_LOGIN_MESSAGE option is that it has no real-life use and has missed its original intended purpose. Too bad misses the fact that option has indeed provided a way to use Fail2Ban to track failed login attempts, something which would be more difficult without this feature.

[jducaud]

I do agree with you that there is no problem when using BookStack upfront (not in a container and not behind a reverse proxy). But am I the only person who wants to use BookStack in a Docker container, behind a reverse proxy? Is this setup so uncommon and twisted that it is completely out of topic regarding the BookStack documentation? I do not think so. Two containerized versions of BookStack are proposed as links (LinuxServ.io and solidnerd) and there is even an option (APP_PROXIES) which deals with proxy-based setups (at least for the Audit Log feature).

Nonetheless I admit that saying this option has "no real-life use" was wrong (as it has - as you pointed - at least one use case).