On Wed, 25 May 2022, Hippo Man wrote:
iptables (linux) & pf firewall (freebsd) do drop the packets immediately
as the tables are updated.
In my case, that is not occurring. After issuing the iptables DROP command,
the client can continue to send more and more login attempts. Only when the
client disconnects does the block of the socket seem to work for that IP
address. I continue to see numerous instances of this behavior.
I'm running debian 8. Perhaps the iptables on this nearly obsolete version
of linux do not behave in the way that you have experienced.
Many firewall keep a side cache of estalished connection. Either implicitly
or explicitly, an established TCP session will do an end-run around your
rules.
conntrack seems to be the iptables utility you need to flush
a connection cache:
https://www.systutorials.com/docs/linux/man/8-conntrack/
e.g. conntrack -D -s x.x.x.x
However, even this may not be enough as dovecot may send an outgoing
packet (being oblivious to firewall rules), which could re-establish
a connection as firewall rules typically allow free egress, and can
automatically create missing state entries. I'm not sure how this is
typically handled -- maybe an outbound block rule is required to handle
this niche case to finally drive a stake through a BFD connection's
heart.
(more stuff:
https://unix.stackexchange.com/questions/646663/iptables-how-kill-established-connection-except-for-an-ip).
Joseph Tam <jtam.h...@gmail.com>
