Fail2ban breaks as there is no longer a unauthorized.log

[golles]

First of all, many thanks for this tool and all the effort everyone is putting into this!

---

Expected Behavior

I generally tend to update my containers often and in the case of swag I do check the logs to see which config files have changed.
With the changes to nginx.conf (nginx.conf.sample) I noticed the config for unauthorized.log has been removed.
Earlier this week I was investigating an issue and noticed I still had these unauthorized log files so I removed them.

After running fail2ban-client status today I got an issue saying that it couldn't connect to the server. After checking the logs I noticed these 2 lines:

2022-10-16 21:22:30,724 fail2ban.filterpoll     [318]: WARNING Too many errors. Remove file '/config/log/nginx/unauthorized.log' from monitoring process
2022-10-16 21:22:30,725 fail2ban.filter         [318]: INFO    Removed logfile: '/config/log/nginx/unauthorized.log'

That made me realise that this could be a problem, so I restored the following config from the history:

    # Saves unauthorized log messages to a separate log file
    map $status $unauthorized {
        default 0;
        ~^401  1;
    }
    access_log /config/log/nginx/unauthorized.log combined if=$unauthorized;

and it seems fail2ban-client status is OK again.

I guess that the above config shouldn't have been taken out? As the jail is still there: https://github.com/linuxserver/docker-swag/blob/master/root/defaults/fail2ban/jail.local#L55-L59

I also had some warnings after the change (a while ago), and had restored these 2 lines to make them go away

    # Set defaults.
    types_hash_max_size 2048;
    variables_hash_max_size 2048;

Current Behavior

See above

Steps to Reproduce

N/A

Environment

OS: Ubuntu 22.04.1 LTS
CPU architecture: x86_64
How docker service was installed: official docker repo

Command used to create docker container (run/create/compose/screenshot)

Docker logs

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[golles]

I don't think this should be auto closed, hence this reply

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nemchik]

I need to review this. Sorry for not getting to it sooner. I understand the issue, but I want to determine what the best fix is.

[HannesJo0139]

Sorry if I'm wrong but I think you missed that the unauthorized jail has been updated to use error.log. For me fail2ban works like a charm.

[nemchik]

It looks like out of the box we actually have the conf shipping with:

[nginx-unauthorized]
enabled  = true
port     = http,https
filter   = nginx-unauthorized
logpath  = /config/log/nginx/access.log

This may make more sense to use the error.log instead of the access.log, assuming 401 are recorded as errors. I will look into confirming this later.

[HannesJo0139]

Ohh, right I seem to have looked in the wrong line. Error.log would probably make more sense but the jail works nevertheless.

Status for the jail: nginx-unauthorized
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     4
|  `- File list:        /config/log/nginx/access.log
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

[golles]

I've just checked and 401s are logged in the access.log

[HannesJo0139]

I thought that is clear since my jail has entries Total failed: 4 :D

[drizuid]

closing this as we cannot reproduce.

[laur89]

Why does swag no longer log 401-s into unauthorized.log, i.e. why was the map $status $unauthorized mapping removed?

[nemchik]

401 is one of many errors that nginx can put in the access.log file. As far as f2b is concerned there's two scenarios:

1. watch two files, parse two or more regex patterns in two files
2. watch one file, parse two or more regex patterns in one file

There isn't a real big concern with either, but if we're separating out 401 why not also 400, 403, 405, 418, 429, or heck maybe even 404 or some of the 5xx series? I will admit 401 is probably the most common concern among the ones above, but the only benefit to separating 401 is for a human to look at the file without needing to grep the access.log.

The main reason the separation was removed from swag specifically was to align swag with our base image's nginx confs which defines access logging here
https://github.com/linuxserver/docker-baseimage-alpine-nginx/blob/b066d87d4ec7e7bbcaefa1fbf32c75ef2aefdfb5/root/defaults/nginx/nginx.conf.sample#L75-L76

All of our nginx based images use the same top level nginx.conf. A large number of those images are for apps where we suspect it's highly unlikely that the average user would bother checking logs at all, and none of them include fail2ban except swag.

We also have a standalone fail2ban image that has its own confs that looks for 401 in the access.log file
https://github.com/linuxserver/fail2ban-confs/blob/44f470319232692fe7cfac41216128e4731f2f36/jail.d/nginx-unauthorized.conf#L9

Technically it would be possible to use the standalone fail2ban confs in swag, we just never made it around to bringing them over officially.

Anyway, I hope this context helps as to why we made the change in question.