<div dir="ltr"><div>I'm sorry, but I am not seeing the behavior that you describe.</div><div><br></div><div>My iptables rule which blocks IP addresses is at the highest precedence, and</div><div>in fact, it is my *only* iptables rule. I repeatedly and regularly see that this</div><div>rule does not terminate nor block existing connections. It only blocks *future*</div><div>connections by the IP addresses that it references.<br></div><div><br></div><div>This is my one and only iptables rule (where "drop-list" is an ipset list).<br></div><div><br></div><div>iptables -I INPUT -m set --match-set drop-list src -j DROP</div><div><br></div><div>As soon as I detect a "bad" login attempt, I cause the following command to run:</div><div><br></div><div></div><div>ipset add drop-list aaa.bbb.ccc.ddd -exist</div><div>(where aaa.bbb.ccc.ddd is the offending IP address)</div><div><br></div><div>Perhaps there is a delay before the iptable rule takes effect whenever the</div><div>ipset list is updated. Or perhaps this is some sort of behavior that only exists</div><div>on earlier linux versions such as debian-8, which I am running.</div><div><br></div><div>In any case, I often see activity on existing connections that continues after</div><div> this ipset command is invoked for those connections' IP addresses.<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div><div>-- <br> <a href="mailto:hippoman@gmail.com" target="_blank">hippoman@gmail.com</a><br> Take a hippopotamus to lunch today.<br></div></div></div></div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 26, 2022 at 3:34 PM Bernardo Reino <<a href="mailto:reinob@bbmk.org">reinob@bbmk.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 26 May 2022, Hippo Man wrote:<br>
<br>
> [...]<br>
><br>
> I also read your other message where you referred to a stackexchange <br>
> conversation about killing existing connections. That conversation confirms <br>
> what I have observed in my own environment: that iptables offers no way to <br>
> terminate an already established connection.<br>
><br>
> Also, "conntrack" is mentioned in that discussion, but I haven't been able<br>
> to get<br>
> conntrack to work on my debian-8 system.<br>
<br>
If you use fail2ban or something which adds a rule to block an ip address using <br>
iptables or nftables, it will work.<br>
<br>
You have been already told that if you have a rule allowing established/related <br>
connections having a higher precedence than the blocking rule, then obviously <br>
the blocking will not work.<br>
<br>
I use nftables, and have "ct state established,related accept" at the very <br>
bottom of my ruleset (just before the default action: drop).<br>
<br>
For fail2ban I use a script which adds the ip to a nftables set (aptly named <br>
fail2ban), and I have the rule "ip saddr @fail2ban drop" near the top of the <br>
ruleset.<br>
<br>
I just tested blocking myself (ssh instead of imaps, but there should not be any <br>
difference) and the block is immediate.<br>
<br>
Good luck!<br>
<br>
</blockquote></div>