- Used Zammad version: 5.1.x (latest version available on 10/03/2022)
- Used Zammad installation type: self-hosted Zammad on Ubuntu 20.04, installed/updated via apt using .deb packages
- Operating system: Ubuntu 20.04
- Browser + version: Firefox (latest version available on 15/03/2022)
- 5th failed attempt to log into Zammad should result in ban by fail2ban
- Zammad allows repeated failed login attempts, but the failures are not logged with the exploiting IP address.
Steps to reproduce the behavior:
- Try repeatedly to log into Zammad via the Web interface, using the wrong password.
Question I’m asking:
I’m running a self-hosted Zammad instance on Ubuntu 20.04, with Nginx reverse proxy.
I want to protect it against repeated failed login attempts with fail2ban. But, after a failed login attempt, the log file /opt/zammad/log/production.log does not contain a line reporting a login failure and the IP address concerned.
That means I can’t easily use a regex to get fail2ban to monitor production.log and identify a failed login attempt with the IP concerned.
How can I use fail2ban to protect my Zammad, or is there some other equivalent solution or add-on I can use? (I do not want to use Nginx’s HTTP auth to lock access to the instance.)
Thanking you in advance for any help,
TL;DR: You can’t.
Zammad automatically locks affected user accounts on too many failed attempts.
Your statement that the production log does not contain failed logins is not correct btw. I’ve checked that for you to be sure:
Thank you for the reply. In fact, it can be seen in your screenshot of the logs that the failed login attempt is not reported WITH THE OFFENDING IP ADDRESS. So that makes it impossible to feed an IP address to Fail2Ban so that it can ban the user after X failed attempts.
It would be cool if the logging also recorded the IP address with the failed login.
You can (and probably should) resolve this at the NginX level instead of Zammad. Repeated HTTP 401 Unauthorized responses on POST’ing requests to the signin URL from the same originating IP should be the trigger for your Fail2Ban rule. This would also work around a bot trying out various accounts with only a few tries per account (so without actually locking the account). This is an example from my NginX logging on one of my internal testing machines (hence the RFC1918 IP in the request):
Hello Dennis, thank you for this piece of lateral thinking. I will mull it over and figure out how I could implement it… If ever you happened to have a fail2ban jail you use with that, I’d be very interested to see it… Or what approach do you use, please?
All best wishes,
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.