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!