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@gmail.com
 Take a hippopotamus to lunch today.




On Thu, May 26, 2022 at 3:34 PM Bernardo Reino <reinob@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!