Force TCP socket disconnect on imap login failure?

Hippo Man hippoman at gmail.com
Thu May 26 20:48:48 UTC 2022


I'm sorry, but I am not seeing the behavior that you describe.

My iptables rule which blocks IP addresses is at the highest precedence, and
in fact, it is my *only* iptables rule. I repeatedly and regularly see that
this
rule does not terminate nor block existing connections. It only blocks
*future*
connections by the IP addresses that it references.

This is my one and only iptables rule (where "drop-list" is an ipset list).

iptables -I INPUT -m set --match-set drop-list src -j DROP

As soon as I detect a "bad" login attempt, I cause the following command to
run:

ipset add drop-list aaa.bbb.ccc.ddd -exist
(where aaa.bbb.ccc.ddd is the offending IP address)

Perhaps there is a delay before the iptable rule takes effect whenever the
ipset list is updated. Or perhaps this is some sort of behavior that only
exists
on earlier linux versions such as debian-8, which I am running.

In any case, I often see activity on existing connections that continues
after
this ipset command is invoked for those connections' IP addresses.

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




On Thu, May 26, 2022 at 3:34 PM Bernardo Reino <reinob at bbmk.org> wrote:

> On Thu, 26 May 2022, Hippo Man wrote:
>
> > [...]
> >
> > 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.
>
> If you use fail2ban or something which adds a rule to block an ip address
> using
> iptables or nftables, it will work.
>
> You have been already told that if you have a rule allowing
> established/related
> connections having a higher precedence than the blocking rule, then
> obviously
> the blocking will not work.
>
> I use nftables, and have "ct state established,related accept" at the very
> bottom of my ruleset (just before the default action: drop).
>
> For fail2ban I use a script which adds the ip to a nftables set (aptly
> named
> fail2ban), and I have the rule "ip saddr @fail2ban drop" near the top of
> the
> ruleset.
>
> I just tested blocking myself (ssh instead of imaps, but there should not
> be any
> difference) and the block is immediate.
>
> Good luck!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dovecot.org/pipermail/dovecot/attachments/20220526/a3cb699b/attachment-0001.htm>


More information about the dovecot mailing list