Force TCP socket disconnect on imap login failure?

[Hippo Man]

Follow-up:

I have tested dovecot's auth-policy mechanism, and I got it to work.

However, I see now that even this auth-policy mechanism doesn't give dovecot
any way to *kill* an existing connection. It can allow dovecot to reject
login
attempts, and it can cause external activities to be performed based on the
results of authentication, but terminating a connection is not something
which
can be accomplished via auth-policy.

I also read your other message where you referred to a stackexchange
conversation about killing existing connections. That conversation confirms
what
I have observed in my own environment: that iptables offers no way to
terminate
an already established connection.

Also, "conntrack" is mentioned in that discussion, but I haven't been able
to get
conntrack to work on my debian-8 system.

Therefore, I think I will have to go forward with my idea of creating my
own,
personal version of dovecot which optionally allows the killing of
connections
after "N" failed login attempts (where "N" is configurable).

But in any case, the auth-policy mechanism allows me to deal with login
issues more efficiently than monitoring log messages, and I will now switch
some (all?) of my dovecot-based log-monitoring activites to auth-policy.

Thank you again for *all* your suggestions and help!

-- 
 hippoman at gmail.com
 Take a hippopotamus to lunch today.


On Wed, May 25, 2022 at 9:00 PM Hippo Man <hippoman at gmail.com> wrote:

> Thank you very much!
>
> I didn't know about auth_policy, and I can see that an auth_policy server
> would be ideal for me.
>
> I could transfer a lot of the logic to that server and dispense with most
> (and
> maybe even all) of my logfile monitoring.
>
> I'm already using RBL with postfix, and it will probably indeed be helpful
> with dovecot, as well.
>
> As for immediate triggering against impossible auth attempts, I guess I
> could
> come up with some sort of dictionary of these kinds of terms.
>
> I very much appreciate all these ideas.
>
>
>
>
> --
>  hippoman at gmail.com
>  Take a hippopotamus to lunch today.
>
>
> On Wed, May 25, 2022 at 6:03 PM Joseph Tam <jtam.home at gmail.com> wrote:
>
>> On Tue, 24 May 2022, Hippo Man wrote:
>>
>> Late to this party.
>>
>> > * Hacker makes numerous login attempts one after the other with various
>> > passwords, and without disconnecting in between attempts. I've seen 10
>> and
>> > more of these repeated attempts rapidly during a single imap or pop3
>> > connection.
>>
>> Maybe this settings helps?
>>
>>         auth_failure_delay = 5 secs
>>
>> I get lots of BFD, and although they have no chance of guessing a password
>> this way, it produces an annoying amount of rubbish in my logs.  This slow
>> them down to either reduce the volume of attempts (and logs), but also
>> gives you ample time to enact a countermeasure.
>>
>> > I will get the latest dovecot source code and modify it so that dovecot
>> > will disconnect after "N" failed imap or pop3 login attacks, where "N"
>> is
>> > some sort of configuration variable (with a default of zero, meaning do
>> not
>> > disconnect). I will then use this personal version of dovecot with "N"
>> set
>> > to a fairly low value (probably 1!).
>>
>> 1, in my opinion, is really too low.  This can lockout a legitimate user
>> with a simple typo, or network hiccough.
>>
>> It would be better to externalize this, rather than bake it into dovecot.
>> Have you considered
>>
>>
>> https://doc.dovecot.org/configuration_manual/authentication/auth_policy/
>>
>> > Furthermore, I will continue to automatically monitor the logs and
>> > perform the same iptables DROP actions for the failed login attempts.
>> > The combination of these two actions will give me the behavior that I
>> > desire.
>>
>> You can also preempt many BFD runs without resorting to
>> one-strike-you're-out
>> policy
>>
>>         1) Look up connecting host in RBL and do a prememptive block
>>         e.g. bl.websitewelcome.com, bl.blocklist.de, dnsbl.darklist.de
>>         are some examples of brute force DNSRBLs.  You'll find many of
>>         attacking IPs are represented on one of these lists.
>>
>>         2) Triggerimmediate block against authentication attempts that
>>         can not possibly be real (e.g. "mysql", "testuser", "nagios",
>> etc.)
>>
>> Joseph Tam <jtam.home at gmail.com>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dovecot.org/pipermail/dovecot/attachments/20220526/f74569b6/attachment.htm>