"-j REJECT --reject-with
tcp-reset" instead of DROP
are valid ideas
consider that if you update (in the background) and block the connection
then dovecot (or any other process) should just block the traffic and
timeout to close the connection anyways
fyi ??
Happy Tuesday !!!
Thanks - paul
Paul Kudla
Scom.ca Internet Services <http://www.scom.ca>
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3
Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
Email p...@scom.ca
On 5/24/2022 12:18 AM, Péter Márton wrote:
Just for clarification (this probably won't help achieve your primary
goal to reset the connections):
Iptables can block future connections _and_ stop existing connections
to receive (and send) packets (even the command you posted). What it
can't do is closing existing connections (sending a FIN).
If the example you show can not block existing connections you have
somewhere before the chain a RELATED, ESTABLISHED rule with ACCEPT as
target. This is a common mistake. Your fail2ban rules have to come
_before_ you check for related and established connections.
I never tested this, but you could try using "-j REJECT --reject-with
tcp-reset" instead of DROP. Then at least a RST would be sent.
Hippo Man <hippo...@gmail.com> ezt írta (időpont: 2022. máj. 23., H, 23:17):
OOPS! I incorrectly copied and pasted the iptables command in my previous
message. Here is the correct iptables command:
iptables -I INPUT -p tcp -m multiport --destination-port 143,993 -d
aaa.bbb.ccc.ddd -j DROP
This command successfully blocks *future* connections to ports 143 and 993 from
that IP address, but as I mentioned, it doesn't kill the currently open
connection.
--
hippo...@gmail.com
Take a hippopotamus to lunch today.
On Mon, May 23, 2022 at 4:54 PM Hippo Man <hippo...@gmail.com> wrote:
Thank you, but fail2ban doesn't do what I need. Here is why ...
I have used fail2ban and also my own homegrown log monitor program for this
purpose. In both cases, I can detect the failed imap logins and then cause the
following command to be run ...
iptables -I INPUT -p tcp --destination-port aaa.bbb.ccc.ddd -j DROP
However, this does not drop connections that are existing and already open. It
will only drop *future* connections from that IP address to port 143.
This is why I want to kill the existing connection. Even after that "iptables"
command is issued, the entity which is connected to the imap port can continue to send
more and more imap commands.
If I can drop the TCP connection as soon as an imap login fails and also issue that kind
of "iptables" command, then the client would have to reconnect in order to
retry other login attempts. Those future connections would then be successfully blocked
by that iptables rule.
And even if I issue a "tcpdrop" command instead of just the "iptables" command,
it doesn't kill the already-open connection. It just force-blocks future connections.
I'm thinking of patching the dovecot source code to create a personal version
which immediately disconnects from the socket after login failure. Of course, I
would prefer not to do that, if there is another way to accomplish this.
--
hippo...@gmail.com
Take a hippopotamus to lunch today.
On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins <j...@jhprins.org> wrote:
Look at fail2ban.
Should be able to do that for you.
Jan Hugo
On 5/23/22 21:11, Lloyd Zusman wrote:
I'm running dovecot 2.2.13 under Debian 8.
I'd like to force an immediate TCP socket disconnect after any imap login
attempt that fails.
Right now, if invalid credentials are supplied during an imap login, the client
can keep retrying logins with different credentials. However, I want to prevent
that from occurring by causing the socket connection to be closed as soon as
there is any failed login attempt.
I haven't been able to find any dovecot configuration setting which could
control this behavior, but I'm hoping that I just missed something.
Thank you very much for any suggestions.
--
hippo...@gmail.com
Take a hippopotamus to lunch today.
