closing a socket can leave a process in an undertimed state pending how the code reacts

blocking in the background via iptables would just stop traffic and the process should die cleanly.

programming 101, network connections at best dont like the plug being pulled once they start to talk but if the connection just dies off then it is just a network timeout error with no real harm being done.

just a thought.



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/23/2022 9:25 PM, John Tulp wrote:

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.



--
  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.
                 >


Reply via email to