Custom container/access log file (fail2ban)

[Glareascum]

Is it possible to specify a custom log file location? I'd like to put baikal under the eye of fail2ban, so I need a log to scan and apply some rules to avoid brute force attacks.

[ckulka]

Hi @Glareascum , do you use Nginx or Apache and can you use the container logs, or do you need the actual access log files?

Assuming fail2ban can not consume container logs out of the box, I can think of three solutions:

Consume container JSON log files

The access log is printed to the container logs, are stored in /var/lib/docker/containers/<container id>/<container id>-json.log unless you changed your logging driver, e.g. to journald (something I would personally actually recommend, it helps with disk space filling up with log files).

The container id changes every time you start a new one, so I don't know if you can just consume all container logs and filter in fail2ban, or if fail2ban has an overall better way of consuming Docker container logs.

Mount log folder

If you don't need the access log in the container logs, I would mount /var/log/apache2 or /var/log/nginx to a local folder and then consume log files from there. It's the simplest solution, but since the logs are no longer sent to stdout and stderr, your container logs will now be empty - which might be acceptable for you though.

Log to multiple files

If you want to keep the container logs and additionally output access logs to a separate file, you need to do the following:

1. Copy the /etc/nginx/nginx.conf contents to a new local file
2. Add an additional access_log directive underneath the existing one
3. Mount the additional logging folder into the container
4. Mount the customised nginx.conf file into the container

On Apache you might get away with mounting a new configuration file in /etc/apache2/conf-enabled with the the following line combined with step 3:

CustomLog /var/log/apache-custom/access.log vhost_combined

Failed login attemps (updated from replies)

Baikal version 0.9.1 (and earlier versions probably too) logs and returns HTTP status 200 codes even when logins fail, so the access logs by themselves cannot be used to detect failed logins.

I think this would require a code change in Core/Frameworks/BaikalAdmin/WWWRoot/index.php#L65-L66 to set the HTTP status code to something like 403.

[Glareascum]

Thank you for your reply.
I've mounted /var/log/nginx to a local folder and tried to read both error.log and access log.

In access.log I've the real IP address which i can use with fail2ban, however it doesn't tell me if I failed to login or I've accessed the admin panel (I see always HTTP 200):
"POST /admin/ HTTP/1.1" 200 2517 "https://dav.mydomain.com/admin/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36" "MYREALIP"

In error.log I've the failed requests, but unfortunately I don't see the real IP but I assume the one that is seen by docker, in this case 172.18.0.1 which is wrong
[error] 19#19: *17 FastCGI sent in stderr: "PHP message: user admin authentication failure for Baikal" while reading response header from upstream, client: 172.18.0.1, server: _, request: "POST /admin/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "dav.mydomain.com", referrer: "https://dav.mydomain.com/admin/"

Am I missing something?

Thanks again

[ckulka]

No, you're not missing anything... looks like Baikal returns HTTP status 200 even when the login failed.

If I had to guess, then there needs to be a new line in Core/Frameworks/BaikalAdmin/WWWRoot/index.php#L65-L66 to set the status to something like 403.

That code change is not something we should fix in this Docker image though, I'd open an issue (or even better a PR) over at sabre-io/baikal. Maybe they also know of a better way to handle this.

[Glareascum]

Thank you very much, i really appreciate that. Hope they will "fix" this soon.