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. -- hippoman at gmail.com Take a hippopotamus to lunch today. On Mon, May 23, 2022 at 4:54 PM Hippo Man <hippoman at 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. > > -- > hippoman at gmail.com > Take a hippopotamus to lunch today. > > > On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins <jhp at 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. >> -- >> hippoman at gmail.com >> Take a hippopotamus to lunch today. >> >> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20220523/4ebc4fd1/attachment.htm>
i googled a little, i was just curious about your question. found a stackoverflow question which, answered, says that using gdb one can close the fd, after using lsof to find it out. oh, and your iptables command... you have the address aaa. etc with a -d, i think you mean the source ip address of the connection, -s, right ? if you want, i can provide that link. On Mon, 2022-05-23 at 17:16 -0400, 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. > > > > -- > hippoman at gmail.com > Take a hippopotamus to lunch today. > > > > > On Mon, May 23, 2022 at 4:54 PM Hippo Man <hippoman at 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. > > > > -- > hippoman at gmail.com > Take a hippopotamus to lunch today. > > > > > On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins > <jhp at 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. > > > > > > -- > > hippoman at gmail.com > > Take a hippopotamus to lunch today. > > > >
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 <hippoman at 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. > > -- > hippoman at gmail.com > Take a hippopotamus to lunch today. > > > On Mon, May 23, 2022 at 4:54 PM Hippo Man <hippoman at 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. >> >> -- >> hippoman at gmail.com >> Take a hippopotamus to lunch today. >> >> >> On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins <jhp at 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. >>> >>> -- >>> hippoman at gmail.com >>> Take a hippopotamus to lunch today. >>> >>>
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. > > -- > hippoman at gmail.com > ?Take a hippopotamus to lunch today. > > > On Mon, May 23, 2022 at 4:54 PM Hippo Man <hippoman at 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. > > -- > hippoman at gmail.com > ?Take a hippopotamus to lunch today. > > > On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins <jhp at 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. >> >> -- >> hippoman at gmail.com >> ?Take a hippopotamus to lunch today. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20220524/01af8f13/attachment-0001.htm>