Just a few comments.
- The below commands drops ALL future connections to the IMAP ports and
not just the one from that specific IP address.
- It all depends on the ordering of the rest of your iptables rules. A
lot of iptables setups have an accept related / established in the top
of the INPUT chain and then indeed the traffic will continue as long as
the connection is established. If you put a correct drop rule in the top
of your iptables INPUT chain it will block all traffic including any
related/established.
Fail2Ban is able to insert such a drop rule in the top of the INPUT
chain and thereby block all further tries.
This is exactly how I have setup my fail2ban and it works.
The first few lines of my iptables input chain look like this:
29M 2249M f2b-dovecot tcp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 110,143,993,995
9969K 2545M f2b-sasl tcp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 25,465
9691K 2788M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
134M 257G ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
Jan Hugo Prins
On 5/23/22 23:16, Hippo Man wrote:
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.
