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.
Ndrou
All 2 comments
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
on 13 Nov 2016
This will be related to #272 and could actually be implemented then if we succeed.
kaiyou
on 24 Sep 2017
Related issues
Angedestenebres
路
3Comments
c-holtermann
路
3Comments
fabiorauber
路
3Comments
v1ru535
路
4Comments
styxlab
路
4Comments
Most helpful comment
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.ymlto 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.