understanding dovecot director passdb configuration

[Aki Tuomi]

You might as well consider something slightly more fresh. 2.2.10 is
rather old already.

And you should also turn on consistent hashing option.

I'd recommend putting dovecot as proxy in front of the directors, and do
any brute force deterring there. You can use e.g. weakforced here if you
are using 2.2.27+, but dovecot already does some deterring by stalling
failed logins.

Dovecot always does asynchronous logins, as the imap-login and auth
process are separate.

Aki

On 26.02.2018 09:41, Kalyana sundaram wrote:
> Hey All
> I am very new to dovecot ecosystem. Found the software really robust
> and secure. Kudos to the team!!!
> We are setting up dovecot imap servers sharing a single nfs mount
> point. So to avoid nfs cache issues, we are setting up dovecot
> director. We are using dovecot version 2.2.10. While going through the
> documentation of dovecot director I stumbled across the following
> lines in passdb configuration https://wiki2.dovecot.org/Director
>
> "Note that while this is the simplest director configuration, users
> will be assigned to a backend before they have been authenticated.  A
> director configured this way can be attacked by sending it a large
> number of unknown users.  To prevent this, the director should be
> configured to authenticate the user and might make use of a master
> password to log into the backend servers."
>
>
> I understand on static passdb config dovecot assigns a user to a
> machine in the list of  backends by using
> md5(username)%number_of_mail_servers. But other than this calculation
> it does not incur any other resources. It does have tcp connection
> with the system which is trying to do bruteforce. If we move to
> authenticating users directly at the director server, the director
> servers imap-login director service should be anyways loaded on an
> attack. Is it anything to do that the imap-login will contact auth
> process asynchronously and keep itself free?  I am pretty sure I am
> overlooking some point on the above statement. Can somebody throw some
> light on that?
>
> -- 
> Kalyanasundaram
> http://blogs.eskratch.com/
> https://github.com/kalyanceg/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dovecot.org/pipermail/dovecot/attachments/20180226/f264c075/attachment.html>