A quick test confirms that HAproxy header IP information does properly
delay the authentication failures upon successive failed login attempts
from the same IP.
And furthermore if the webmail client is delayed on the IMAP level, this
could potentially be exploited for DoS and as such may not be a good
idea after all. Even with the auth_failure_delay=2 by default this is
possible, but it's much easier to achieve the DoS if the pre-auth delay
increases to 17 seconds (maximum delay I've observed).
Is there any other brute force / DoS mitigation option for dovecot /
webmail interaction, short of fail2ban type IP blocking in a firewall
(which will not work on a machine several layers deep behind e.g. a
proxy), that isn't exclusively relying on the webmail client for such
mitigation?
Can dovecot itself temp-ban remote IPs (as reported by HAproxy protocol,
or IMAP ID x-originating-ip), perhaps with a notice to try again in X
seconds, instead of delaying them?
/Tobias
On 2016-06-24 13:27, Tobias wrote:> The wiki states that anvil's authentication penalties are skipped when
> IP is in login_trusted_networks.
> http://wiki.dovecot.org/Authentication/Penalty
>
> Is there a way to enable the authentication penalties for specific
> advertised remote IPs, when the connecting IP is in
> "login_trusted_networks", and it advertises the originating
remote IP
> via 'ID ("x-originating-ip",
"<remote-ip>")'?
>
> And with regards to HAproxy, is anvil's authentication penalties by
> default transparent with regards to the remote IP advertised in the
> proxy protocol header?
>
> /Tobias