Closed davze closed 2 weeks ago
We log failed auth attempts, so you should be able to use the logs to get failed authentication attempts. Besides, the actual api response should be a 403, and I think that's the request you should use for fail2ban, not some GUI request. If you only watch for the request serving the HTML, I could still make as many api auth requests as I want
Just to clarify: The bug report was not about failed login attempts. I got seperate (working) filters for that. The problem is about the wrong status code being returned when accessing files that are not present. In my example a bot is probing for a wordpress login page (wp-login.php). I think the immich server should respond with status 404 instead of 200.
@davze Then it's a duplicate of #8590 :P
The bug
Not sure if it can be called a bug, but I'm not sure either if it is wanted behavior.
In my setup immich is sitting behind a caddy reverse proxy. To expose it as safely to the www as possible I have a multi layered security setup. One of the layers is a an aggressive fail2ban filter to ban bots that are probing for admin interfaces. If a bot is trying to access to many non existing filepaths and generates to many HTTP 403 or 404 errors it gets banned. At the current state immich is showing a custom error page to the bot but the reverse proxy (and my fail2ban filter) is just getting a status 200 from the immich server because it successfully serves the bot with the custom error page. Is it possible to send the right HTTP status (403/404) to the reverse proxy.
Logs are from caddy.
The OS that Immich Server is running on
Debian
Version of Immich Server
v1.103.1
Version of Immich Mobile App
v1.103.1
Platform with the issue
Your docker-compose.yml content
Your .env content
Reproduction steps
Relevant log output
Additional information
No response