a recent pull request in the SWAG container introduces an nginx-unauthorized fail2ban jail:
in general it seems like a great idea, but I have some trouble tweaking the configurations based on the classic workflow of an authorized HTTP connection.
what I mean is, an authorized user will most often still trigger a 401 line in the logs, will it not?
if I use curl to manually GET/POST the desired URL with the provided authentication, then I will get a correct reply right away, i.e. 200 or so, and that is fine.
if instead I am using a webbrowser, it is my understanding that the browser will:
first try unauthenticated, thus generating a 401 log line,
then see the 401 reply, thus showing a user/pass dialog to the user,
finally GET what it was supposed to get, but with proper authentication.
in other words, is there a way to make sure that I personally do not participate in the 401 lines that this new jail is supposed to patrol?
my question is whether it is correct to assume that perfectly authorized clients will inevitably produce 401 lines, too, or whether there is a way around such an issue.
i have the same problem. i can’t use photoprism (Docker Hub) with this jail. i log in, switch a path in the application on the subdomain and i am banned. i don’t get why because i don’t know a lot about the configuration of fail2ban. But i’m glad i found this thread and now i have to research how to disable this jail (even on swag container updates) or how to add some headers in the proxy-confs that can change that behaviour or how to whitelist a url?.. no idea.
For now i just added a much higher retry amount in for the nginx-authorized in the jail.local file and mount my custom jail.local in my docker-compose