On Tue, Jan 01, 2008 at 03:46:23PM -0800, Asheesh Laroia wrote:
On Tue, 1 Jan 2008, Dean Brooks wrote:
Is there a way, or can a way be added, to add an "auth_failed_delay=10s" style option that would put in an artificial delay after a failed password attempt?
As it stands now, Dovecot seems highly vulnerable to widescale brute-force password dictionary scans.
But not if you secure access to Dovecot using e.g. fail2ban. Why is adding complexity to Dovecot better than using a dedicated tool?
Not everyone runs Linux (i.e. iptables) and Dovecot doesn't appear to have imbedded tcpwrappers support (i.e. forces you to run it under inetd which is not always desirable). One or the other is a prerequisite for fail2ban.
Plus, I don't consider adding these features "added complexity". On the contrary, I feel like ANY software that accepts incoming public TCP connections has an obligation to implement some basic controls to limit the resources it consumes. The lack of these kinds of controls are what result in most application-level DDOS attacks.
In the case of IMAP or POP, a minimum of controls would be max connections, max connections per IP and max auth failures.
Using a program to effectively "tail -f" a logfile in realtime is a hack. Logfile formats change, logfile locations change, not everyone uses syslog, etc. It also assumes that logfiles are stored in a centralized location which is often not the case in a large distributed network. Throw in network load-balancers in a server farm and something like fail2ban becomes a real headache.
Hey, it's just my opinion, but keep in mind some people are running Dovecot in very large environments, and Linux isn't even anywhere in our equation.
-- Dean Brooks dean@iglou.com