New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Brute force protection #116

Ndrou opened this Issue Nov 13, 2016 · 2 comments


2 participants
Copy link

Ndrou commented Nov 13, 2016

It could be interesting to integrate Fail2ban to protect from brute force attack on SMTP/POP3/IMAP protocols.

Ideally, a log viewer could be added on admin web interface.

@kaiyou kaiyou added the feature label Nov 13, 2016


This comment has been minimized.

Copy link

kaiyou commented Nov 13, 2016

Given the current architecture, this is very difficult to implement: not all users have the same Docker logging configuration, etc.

We could distribute a docker-compose.yml to force logging to specific files then parse these files, but I doubt this would please many users, most of which are used to their Docker logging tools and maybe remote logging systems (Gelf, etc.)

So in the current state of things, it is not Mailu's responsibility to handle logs and display them, even if I would like to be able to detect some events in the future and produce statistics (see #86). You are more than welcome to add some Wiki documentation about setting up ELK logging or any other fancy system to display logs in a Web interface.

Regarding lockout and bruteforce protection, I agree as well: we need something. Account lockout is a must-have for many regulations even if I dislike it. Rate limiting and IP-based lockouts are better and we will have to implement them.

Currently, your only option is to have Fail2ban installed on your host and parsing Docker logs. Some Docker images are using the host network stack to run Fail2ban inside a container, but I would definitely not recommend this ( Again, any contribution to the documentation about setting this up is welcome.

Eventually, we should be able to concentrate critical operations like authentication and authorized client maps in a single container that could perform rate limiting with a Redis backend for instance.


This comment has been minimized.

Copy link

kaiyou commented Sep 24, 2017

This will be related to #272 and could actually be implemented then if we succeed.

@kaiyou kaiyou modified the milestones: 2.0, 1.5 Sep 28, 2017

@kaiyou kaiyou closed this in 19fe73b Oct 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment