thr3ads.net - dovecot - Force TCP socket disconnect on imap login failure? [May 2022]

If this information is useful, please help other people find it:
Share via:

Hippo Man

2022-May-24 20:12 UTC

Force TCP socket disconnect on imap login failure?

Thank you very much. Yes, I did some manual tests via gdb to close the fd
of a connected socket, and indeed the dovecot behavior is not desirable:
this seems to crash dovecot. So I agree that this is not a good approach.

I have already been doing the following for the past year or so: as soon as
I detect (via my own, homegrown fail2ban-like log monitoring utility) what
I deem to be attempts to log in via imap or pop3 with a dictionary password
attack, I immediately do a DROP via iptables. Yes, this will block all
future connection attemps from the same host, but unfortunately, it doesn't
stop the following scenario, which regularly occurs on my server ...

* Hacker connects via imap or pop3 to my server.
* 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.

Simply using iptables to DROP or REJECT the connection does not prevent
those repeated login attempts during the original imap or pop3 session.
Again, this only prevents *future* connections via that host.

So, this is what I am now planning to do ...

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!). 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.

If this modified, personal version of dovecot actually works the way I am
hoping, I will make a patch available here or wherever is appropriate.

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


On Tue, May 24, 2022 at 5:13 AM Paul Kudla (SCOM.CA Internet Services Inc.)
<paul at scom.ca> wrote:
>
> closing a socket can leave a process in an undertimed state pending how
> the code reacts
>
> blocking in the background via iptables would just stop traffic and the
> process should die cleanly.
>
> programming 101, network connections at best dont like the plug being
> pulled once they start to talk but if the connection just dies off then
> it is just a network timeout error with no real harm being done.
>
> just a thought.
>
>
>
> Happy Tuesday !!!
> Thanks - paul
>
> Paul Kudla
>
>
> Scom.ca Internet Services <http://www.scom.ca>
> 004-1009 Byron Street South
> Whitby, Ontario - Canada
> L1N 4S3
>
> Toronto 416.642.7266
> Main 1.866.411.7266
> Fax 1.888.892.7266
> Email paul at scom.ca
>
> On 5/23/2022 9:25 PM, John Tulp wrote:
> >
> > i googled a little, i was just curious about your question.
> >
> > found a stackoverflow question which, answered, says that using gdb
one
> > can close the fd, after using lsof to find it out.
> >
> > oh, and your iptables command... you have the address aaa. etc with a
> > -d, i think you mean the source ip address of the connection, -s,
> > right ?
> >
> > if you want, i can provide that link.
> >
> >
> >
> > On Mon, 2022-05-23 at 17:16 -0400, Hippo Man wrote:
> >> OOPS! I incorrectly copied and pasted the iptables command in my
> >> previous message. Here is the correct iptables command:
> >>
> >> iptables -I INPUT -p tcp -m multiport --destination-port 143,993
-d
> >> aaa.bbb.ccc.ddd -j DROP
> >>
> >>
> >> This command successfully blocks *future* connections to ports 143
and
> >> 993 from that IP address, but as I mentioned, it doesn't kill
the
> >> currently open connection.
> >>
> >>
> >>
> >> --
> >>   hippoman at gmail.com
> >>   Take a hippopotamus to lunch today.
> >>
> >>
> >>
> >>
> >> On Mon, May 23, 2022 at 4:54 PM Hippo Man <hippoman at
gmail.com> wrote:
> >>
> >>          Thank you, but fail2ban doesn't do what I need. Here
is
> >>          why ...
> >>
> >>
> >>          I have used fail2ban and also my own homegrown log
monitor
> >>          program for this purpose. In both cases, I can detect the
> >>          failed imap logins and then cause the following command
to be
> >>          run ...
> >>
> >>
> >>          iptables -I INPUT -p tcp --destination-port
aaa.bbb.ccc.ddd -j
> >>          DROP
> >>
> >>
> >>          However, this does not drop connections that are existing
and
> >>          already open. It will only drop *future* connections from
that
> >>          IP address to port 143.
> >>
> >>
> >>
> >>          This is why I want to kill the existing connection. Even
after
> >>          that "iptables" command is issued, the entity
which is
> >>          connected to the imap port can continue to send more and
more
> >>          imap commands.
> >>
> >>
> >>          If I can drop the TCP connection as soon as an imap login
> >>          fails and also issue that kind of "iptables"
command, then the
> >>          client would have to reconnect in order to retry other
login
> >>          attempts. Those future connections would then be
successfully
> >>          blocked by that iptables rule.
> >>
> >>
> >>          And even if I issue a "tcpdrop" command instead
of just the
> >>          "iptables" command, it doesn't kill the
already-open
> >>          connection. It just force-blocks future connections.
> >>
> >>
> >>          I'm thinking of patching the dovecot source code to
create a
> >>          personal version which immediately disconnects from the
socket
> >>          after login failure. Of course, I would prefer not to do
that,
> >>          if there is another way to accomplish this.
> >>
> >>
> >>
> >>          --
> >>           hippoman at gmail.com
> >>           Take a hippopotamus to lunch today.
> >>
> >>
> >>
> >>
> >>          On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins
> >>          <jhp at jhprins.org> wrote:
> >>
> >>                  Look at fail2ban.
> >>                  Should be able to do that for you.
> >>
> >>                  Jan Hugo
> >>
> >>
> >>                  On 5/23/22 21:11, 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.
> >>                  >
> >>
> >>
> >
> >
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20220524/45e7436c/attachment.htm>

John Hardin

2022-May-25 01:55 UTC

head link

Force TCP socket disconnect on imap login failure?

On Tue, 24 May 2022, Hippo Man wrote:
> I have already been doing the following for the past year or so: as soon as
> I detect (via my own, homegrown fail2ban-like log monitoring utility) what
> I deem to be attempts to log in via imap or pop3 with a dictionary password
> attack, I immediately do a DROP via iptables. Yes, this will block all
> future connection attemps from the same host, but unfortunately, it
doesn't
> stop the following scenario, which regularly occurs on my server ...
>
> * Hacker connects via imap or pop3 to my server.
> * 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.
>
> Simply using iptables to DROP or REJECT the connection does not prevent
> those repeated login attempts during the original imap or pop3 session.
> Again, this only prevents *future* connections via that host.
It should block all subsequent packets received from that IP address, 
immediately. An in-process connection would appear (to the client) to 
hang.

Either there is an ACCEPT rule for related traffic somewhere in the chain 
before your new DROP rule, which is matching first and allowing the 
existing connection's packets through, or your DROP rule is malformed and 
not actually matching the traffic.


-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin at impsec.org                         pgpk -a jhardin at impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
  724 days since the first private commercial manned orbital mission (SpaceX)

Stuart Henderson

2022-May-25 08:00 UTC

head link

Force TCP socket disconnect on imap login failure?

On 2022-05-24, Hippo Man <hippoman at gmail.com>
wrote:> * 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.
"numerous" and "rapidly" sounds wrong; between
auth_failure_delay (in a single
connection) and the penalty mechanism for all connections from an IP address
(https://doc.dovecot.org/configuration_manual/authentication/auth_penalty/)
it should soon get beyond "rapidly".

Is there something in your config that disables this? Or is your idea of
"rapidly" just different to mine?

Joseph Tam

2022-May-25 22:02 UTC

head link

Force TCP socket disconnect on imap login failure?

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>

dovecot - May 2022 - Force TCP socket disconnect on imap login failure?

Force TCP socket disconnect on imap login failure?

Force TCP socket disconnect on imap login failure?

Force TCP socket disconnect on imap login failure?

Force TCP socket disconnect on imap login failure?