Force TCP socket disconnect on imap login failure?

didar nosferatu at purlo.in
Tue May 24 11:22:51 UTC 2022


On Mon, May 23, 2022 at 03:11:46PM -0400, Lloyd Zusman wrote:
> I'm running dovecot 2.2.13 under Debian 8.
> 
> I'd like to force an immediate TCP socket disconnect after any imap login
> attempt that fails.
> 
> Right now, if invalid credentials are supplied during an imap login, the
> client can keep retrying logins with different credentials. However, I want
> to prevent that from occurring by causing the socket connection to be
> closed as soon as there is any failed login attempt.
> 
> I haven't been able to find any dovecot configuration setting which could
> control this behavior, but I'm hoping that I just missed something.
> 
> Thank you very much for any suggestions.
> -- 
>  hippoman at gmail.com
>  Take a hippopotamus to lunch today.

I read the whole thread and other's suggestion.

On Linux using ipsets with iptables; sets/maps with nftables is more efficient.

Paul Kudla's response is pretty much on the mark and his solution is quiet
thorough.

Your requirement of closing the socket on bad auth attempt is always best done
from the application in question rather than using other tools like - it works, but
it is a workaround. Your suggestion of making changes to dovecot itself will
only create extra work for you, you will have to patch upstream every time there
is a new release. Out of tree customizations should really be maintained only
under extreme situations.

Instead you can look at nginx imap proxy which will allow you to close the
connection on bad auth before it even reaches over to dovecot. However, you will
have to write some code to make it work. I have not tried doing it myself, but,
I can think of using perl mojolicious + redis which re-uses Paul's ideas to do
the job.

And finally my personal opinion about blocking, I do not believe in them
anymore. A decade ago I used to use iptables "recent" module to restrict SSH
access. Now, brute force login attempts are so ubiquitous and distributed
against all availables services that it just isn't worth indulging in the
cat-and-mouse game. Instead I go with the belief that users will get
cracked/hacked eventually, so what can I do to minimize the pain when that
happens? How fast can I recover their emails from backup? How can I segregate
the compromised account from affecting other systems? These are the questions
that I ponder upon, but that's just me.

I hope this helps some how.

Take care,
Didar

-- 
Demand the establishment of the government in its rightful home at Disneyland.


More information about the dovecot mailing list