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
You might want to provide some logs from your nginx instance to show what IPās itās banning. As the jail shouldnāt block any local subnets so if nginx is seeing something different , something with your network setup is a miss (could be using nat hairpin).
that is not the point.
I am allowed to connect to my reverse proxy from the internet, am I not?
indeed, with a dynamic IP that changes over time, so that it cannot be whitelisted, I am bound to generate some 401 lines that inevitably lead to fail2ban banning me.
it might be that other users have other issues, but my original post was because of this. AFAIK, you will always see a 401 line before you are able to successfully authenticate.
Or you can just argue against me.
It would be nice just to see some nginx logs first of what IPās are actually getting banned then we can access what is happening.
Unfortunately we donāt have the time to discuss hypothetical scenarios. Please reproduce the issue, show us the logs along with specific instructions on how to reproduce (so we can reproduce on our end), then weāll look into it.
these are not hypothetical scenarios, that is how the HTTP exchange works.
a web browser will first fetch the page, thus generating the 401 access code, then realize it needs to authenticate, and finally it will authenticate, thus generating a 200 status code.
so even if you are authorized, you are polluting the access.log file with many 401 lines.
do you want to reproduce it? just visit a webpage protected by HTTP auth and look at your own logs.
as a consequence, unless the creators of the jail want to elucidate us with respect to the logic behind this, the jail is best left disabled by default.
only those that know for sure that they can be protected by IP whitelisting should enable this.
well, then you can try this on your own setup ā do you generate 401 lines?
if so, then itās only a matter of tweaking the parameters, e.g. allowing X times in the past Y minutes, and you might get locked out yourself if, of course, you are not protected by IP whitelisting and you have allowed the unauthorized jail.
some people might compulsively check their own dashboard, maybe from new connections from their android phone which does not remember the āauthorization requiredā status of pages after the browser has been closed.
I understand quite often you get annoyed by people complaining but not attaching logs, but this is not one of those cases ā if you take some time to read through, you will easily follow along without the need for detailed logs.
Iāll keep it short and mark it as solved for other users.
The fact of the matter is, while you think this might be an issue, this thread is the only place that weāve had any sort of mention that there are issues. Your theory of why it could be an issue and the issues mentioned by @joesen and @pedrom34.
I would expect more of an uproar about this moronic change if it was causing issues for the 28k+ installs that swag has had since this PR was submitted. Another factor to consider that if you havenāt got your client IPās passing through to your logs correctly, every connection will look like the same IP so of course it will seem like lots of 401 requests and fail2ban triggering a ban.
Anyways, @pedrom34 / @joesen - please provide some info about your setup/logs/app youāre proxying and we can help look at it. Jumping on our discord is always good as there are tons of people there that are always willing to help.
Wow. That kinda escalated quickly
I really didnāt want to start a fire by digging up this topic. Sorry about that.
I took a look at my logs, and it seems itās DavX5 on my android phone (Iām hosting baikal on my server) and a transmission client on both android and on my pc that generate the 401 errors. And for DavX5, it generate 6 or 7 401 on a minute.
I donāt understand why as the credentials are provided on those apps, and for instance DavX5 is connecting to the server without any issue.
Iām on my phone right now but Iāll post logs and details tomorrow morning.
I also have a synology nas (192.168.0.4) running a webdav server.
Everything is running smoothly.
For the logs and conf of swag, I cannot publish more than 2 links, so youāll find here:
nginx-unauthorized.log for today;
jail.local conf for fail2ban, I deactivated the unauthorized jail as it kept on locking me out;
the dav subdomain proxy conf I use to connect to my baikal server with DavX5 and Thunderbird;
the transmission subdomain proxy conf I use to connect to haugene container from transdroid client on android and transmitter client on firefox on windows;
the webdav subdomain proxy conf I use.
I can provide other logs or details, just tell me what do you need.
