Skip to content
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

Closed
Ndrou opened this issue Nov 13, 2016 · 2 comments
Closed

Brute force protection #116

Ndrou opened this issue Nov 13, 2016 · 2 comments
Milestone

Comments

@Ndrou
Copy link

@Ndrou 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
@kaiyou
Copy link
Member

@kaiyou 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 (https://hub.docker.com/r/superitman/fail2ban/). 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.

@kaiyou
Copy link
Member

@kaiyou 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
nextgens added a commit to nextgens/Mailu that referenced this issue Jan 27, 2021
- this should help with Mailu#116
- this replaces Mailu#1612
@nextgens nextgens mentioned this issue Jan 27, 2021
2 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants