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 <[email protected]> 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. > > -- > [email protected] > Take a hippopotamus to lunch today. > > > On Mon, May 23, 2022 at 4:54 PM Hippo Man <[email protected]> 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. >> >> -- >> [email protected] >> Take a hippopotamus to lunch today. >> >> >> On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins <[email protected]> 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. >>> >>> -- >>> [email protected] >>> Take a hippopotamus to lunch today. >>> >>>
