[Dovecot] SQL/LDAP Lockouts?

[Wouter Van Hemel]

On Fri, 10 Dec 2004, Ben Beuchler wrote:

> On Fri, Dec 10, 2004 at 11:29:42AM -0600, Ben Beuchler wrote:
>
>>> 1) If you get a good auth, you're in
>>> 2) If you get a bad auth, or the response takes more than n
>>> milliseconds/seconds, try the next password
>>
>> Is there any reason to make tarpitting logic non-persistent?  It seems a
>> robust implementation would keep track of IPs that have failed logins.
>> Removing the record, of course, at the first successful login.
>
> This would, of course, be potentially vulnerable to a distributed
> attack...
>
>

That depends on how smart the tarpit routine is. And I think you already 
need many thousands of machines before you can fill up a simple buffer 
with ips, in case of a very dumb tarpit algorithm. IPs don't take up so 
much space. IMHO, it's still better to try and slow them down (and perhaps 
protect the other services on the machine with the delays, so you can e.g. 
still receive email). Perhaps persistent caching would make things too 
complicated, the point is to slow them down, even if they have to do only 
2/3 of their attempts with tarpit delay, you already succeeded.

It does look quite difficult to brute force over the internet, without any 
capable admin noticing millions of failed logins. Over an intranet it 
would probably be faster though, and they might be in before it's noticed.

My experience tells me at least SMTP tarpitting does help protect the 
servers when "#&%@! spammers visit your MTA instead of your baseball bat.