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