<div dir="ltr"><div>Thank you very much. Yes, I did some manual tests via gdb to close the fd of a connected socket, and indeed the dovecot behavior is not desirable: this seems to crash dovecot. So I agree that this is not a good approach.</div><div><br></div><div>I have already been doing the following for the past year or so: as soon as I detect (via my own, homegrown fail2ban-like log monitoring utility) what I deem to be attempts to log in via imap or pop3 with a dictionary password attack, I immediately do a DROP via iptables. Yes, this will block all future connection attemps from the same host, but unfortunately, it doesn't stop the following scenario, which regularly occurs on my server ...</div><div><br></div><div>* Hacker connects via imap or pop3 to my server.</div><div>* Hacker makes numerous login attempts one after the other with various passwords, and without disconnecting in between attempts. I've seen 10 and more of these repeated attempts rapidly during a single imap or pop3 connection.<br></div><div><br></div><div>Simply using iptables to DROP or REJECT the connection does not prevent those repeated login attempts during the original imap or pop3 session. Again, this only prevents *future* connections via that host.</div><div><br></div><div>So, this is what I am now planning to do ...</div><div><br></div><div>I will get the latest dovecot source code and modify it so that dovecot will disconnect after "N" failed imap or pop3 login attacks, where "N" is some sort of configuration variable (with a default of zero, meaning do not disconnect). I will then use this personal version of dovecot with "N" set to a fairly low value (probably 1!). Furthermore, I will continue to automatically monitor the logs and perform the same iptables DROP actions for the failed login attempts. The combination of these two actions will give me the behavior that I desire.<br></div><div><br></div><div>If this modified, personal version of dovecot actually works the way I am hoping, I will make a patch available here or wherever is appropriate.<br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br> <a href="mailto:hippoman@gmail.com" target="_blank">hippoman@gmail.com</a><br> Take a hippopotamus to lunch today.<br></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 24, 2022 at 5:13 AM Paul Kudla (<a href="http://SCOM.CA">SCOM.CA</a> Internet Services Inc.) <<a href="mailto:paul@scom.ca">paul@scom.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
closing a socket can leave a process in an undertimed state pending how <br>
the code reacts<br>
<br>
blocking in the background via iptables would just stop traffic and the <br>
process should die cleanly.<br>
<br>
programming 101, network connections at best dont like the plug being <br>
pulled once they start to talk but if the connection just dies off then <br>
it is just a network timeout error with no real harm being done.<br>
<br>
just a thought.<br>
<br>
<br>
<br>
Happy Tuesday !!!<br>
Thanks - paul<br>
<br>
Paul Kudla<br>
<br>
<br>
Scom.ca Internet Services <<a href="http://www.scom.ca" rel="noreferrer" target="_blank">http://www.scom.ca</a>><br>
004-1009 Byron Street South<br>
Whitby, Ontario - Canada<br>
L1N 4S3<br>
<br>
Toronto 416.642.7266<br>
Main 1.866.411.7266<br>
Fax 1.888.892.7266<br>
Email <a href="mailto:paul@scom.ca" target="_blank">paul@scom.ca</a><br>
<br>
On 5/23/2022 9:25 PM, John Tulp wrote:<br>
> <br>
> i googled a little, i was just curious about your question.<br>
> <br>
> found a stackoverflow question which, answered, says that using gdb one<br>
> can close the fd, after using lsof to find it out.<br>
> <br>
> oh, and your iptables command... you have the address aaa. etc with a<br>
> -d, i think you mean the source ip address of the connection, -s,<br>
> right ?<br>
> <br>
> if you want, i can provide that link.<br>
> <br>
> <br>
> <br>
> On Mon, 2022-05-23 at 17:16 -0400, Hippo Man wrote:<br>
>> OOPS! I incorrectly copied and pasted the iptables command in my<br>
>> previous message. Here is the correct iptables command:<br>
>><br>
>> iptables -I INPUT -p tcp -m multiport --destination-port 143,993 -d<br>
>> aaa.bbb.ccc.ddd -j DROP<br>
>><br>
>><br>
>> This command successfully blocks *future* connections to ports 143 and<br>
>> 993 from that IP address, but as I mentioned, it doesn't kill the<br>
>> currently open connection.<br>
>><br>
>><br>
>><br>
>> -- <br>
>> <a href="mailto:hippoman@gmail.com" target="_blank">hippoman@gmail.com</a><br>
>> Take a hippopotamus to lunch today.<br>
>><br>
>><br>
>><br>
>><br>
>> On Mon, May 23, 2022 at 4:54 PM Hippo Man <<a href="mailto:hippoman@gmail.com" target="_blank">hippoman@gmail.com</a>> wrote:<br>
>><br>
>> Thank you, but fail2ban doesn't do what I need. Here is<br>
>> why ...<br>
>> <br>
>> <br>
>> I have used fail2ban and also my own homegrown log monitor<br>
>> program for this purpose. In both cases, I can detect the<br>
>> failed imap logins and then cause the following command to be<br>
>> run ...<br>
>> <br>
>> <br>
>> iptables -I INPUT -p tcp --destination-port aaa.bbb.ccc.ddd -j<br>
>> DROP<br>
>> <br>
>> <br>
>> However, this does not drop connections that are existing and<br>
>> already open. It will only drop *future* connections from that<br>
>> IP address to port 143.<br>
>> <br>
>> <br>
>> <br>
>> This is why I want to kill the existing connection. Even after<br>
>> that "iptables" command is issued, the entity which is<br>
>> connected to the imap port can continue to send more and more<br>
>> imap commands.<br>
>> <br>
>> <br>
>> If I can drop the TCP connection as soon as an imap login<br>
>> fails and also issue that kind of "iptables" command, then the<br>
>> client would have to reconnect in order to retry other login<br>
>> attempts. Those future connections would then be successfully<br>
>> blocked by that iptables rule.<br>
>> <br>
>> <br>
>> And even if I issue a "tcpdrop" command instead of just the<br>
>> "iptables" command, it doesn't kill the already-open<br>
>> connection. It just force-blocks future connections.<br>
>> <br>
>> <br>
>> I'm thinking of patching the dovecot source code to create a<br>
>> personal version which immediately disconnects from the socket<br>
>> after login failure. Of course, I would prefer not to do that,<br>
>> if there is another way to accomplish this.<br>
>> <br>
>> <br>
>> <br>
>> --<br>
>> <a href="mailto:hippoman@gmail.com" target="_blank">hippoman@gmail.com</a><br>
>> Take a hippopotamus to lunch today.<br>
>> <br>
>> <br>
>> <br>
>> <br>
>> On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins<br>
>> <<a href="mailto:jhp@jhprins.org" target="_blank">jhp@jhprins.org</a>> wrote:<br>
>> <br>
>> Look at fail2ban.<br>
>> Should be able to do that for you.<br>
>> <br>
>> Jan Hugo<br>
>> <br>
>> <br>
>> On 5/23/22 21:11, Lloyd Zusman wrote:<br>
>> <br>
>> > I'm running dovecot 2.2.13 under Debian 8.<br>
>> > I'd like to force an immediate TCP socket disconnect<br>
>> > after any imap login attempt that fails.<br>
>> ><br>
>> > Right now, if invalid credentials are supplied<br>
>> > during an imap login, the client can keep retrying<br>
>> > logins with different credentials. However, I want<br>
>> > to prevent that from occurring by causing the socket<br>
>> > connection to be closed as soon as there is any<br>
>> > failed login attempt.<br>
>> ><br>
>> > I haven't been able to find any dovecot<br>
>> > configuration setting which could control this<br>
>> > behavior, but I'm hoping that I just missed<br>
>> > something.<br>
>> ><br>
>> > Thank you very much for any suggestions.<br>
>> ><br>
>> ><br>
>> > --<br>
>> > <a href="mailto:hippoman@gmail.com" target="_blank">hippoman@gmail.com</a><br>
>> > Take a hippopotamus to lunch today.<br>
>> ><br>
>> <br>
>> <br>
> <br>
> <br>
</blockquote></div>