This topic there got a bit out of hand but I’m running into the same issues. I’m using gitea behind the swag reverse proxy. Whenever one does any git actions that require a login e.g. git push it will as per protocol create at least one 401 request to check whether a login is required. This leads to the effect that fail2ban is banning my IP at the second git interaction.
I also opt for the unauthorized filter be removed or much more relaxed.
Much like was requested in the other thread, without the relevant info being shared, we will not make changes. You can read through the other thread to see what information is required for us to even entertain this.
Okay so this is the same argument then… You set as default to ban 401 requests which are part of official standards.
Please read up on authorization negotiation via NTLM, which is used not only by git.
Now I don’t understand why you want logs from me to prove protocol behavior. You can simply try it out yourself with a git server doing any actions via http/https.
I can fix this easily myself but you might want to consider changing a general reverse proxy to not block such applications. Or if you don’t want to support it, delete the gitea sample conf as this application gets ridiculous with fail2ban over http(s).
The 401 (Unauthorized) response message is used by an origin server
to challenge the authorization of a user agent. This response MUST
include a WWW-Authenticate header field containing at least one
challenge applicable to the requested resource.
That means HTTP authentication must generate a 401 response unless a client knows the supported authentication schemes. That was also mentioned in the other thread, but someone dismissed this as exotic behavior nobody has seen before. I would also assume that others don’t run into the fail2ban since HTTP auth creates just once this 401. Git, on the other hand, does such a login with every interaction to a remote server, thus creating many more of the 401 responses.
But like I said I fixed it, it is up to you whether you want to fix this in the default container.
HTTP transactions will definitely pollute the logs with lots of 401 codes that do not mean unauthorized but rather, as already explained, not yet authorized.
actual banning behavior of the same jail will change a lot if, say:
someone uses very short-term-memory browsing sessions and keeps re-authenticating to the same domains, or
just authenticates once and then keeps cookies forever;
one implements strict fail2ban configs;
one browses from dynamic IPs without chance of whitelisting oneself.
it is clear that the LSIO team will not investigate without further logs.
still, I agree that no logs are needed (for this specific issue) and that this depends only on the protocol and is completely in plain sight, and not at all an exotic behavior.
sorry for the intrusion, and I promise not to get inflamed like in the other thread.
