<div dir="ltr"><div>Thank you very much!</div><div><br></div><div>I didn't know about auth_policy, and I can see that an auth_policy server</div><div>would be ideal for me.</div><div><br></div><div>I could transfer a lot of the logic to that server and dispense with most (and</div><div>maybe even all) of my logfile monitoring.</div><div><br></div><div>I'm already using RBL with postfix, and it will probably indeed be helpful</div><div>with dovecot, as well.</div><div><br></div><div>As for immediate triggering against impossible auth attempts, I guess I could</div><div>come up with some sort of dictionary of these kinds of terms.</div><div><br></div><div>I very much appreciate all these ideas.</div><div><br></div><div><br></div><div><br></div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div><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></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 25, 2022 at 6:03 PM Joseph Tam <<a href="mailto:jtam.home@gmail.com">jtam.home@gmail.com</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">On Tue, 24 May 2022, Hippo Man wrote:<br>
<br>
Late to this party.<br>
<br>
> * Hacker makes numerous login attempts one after the other with various<br>
> passwords, and without disconnecting in between attempts. I've seen 10 and<br>
> more of these repeated attempts rapidly during a single imap or pop3<br>
> connection.<br>
<br>
Maybe this settings helps?<br>
<br>
auth_failure_delay = 5 secs<br>
<br>
I get lots of BFD, and although they have no chance of guessing a password<br>
this way, it produces an annoying amount of rubbish in my logs. This slow<br>
them down to either reduce the volume of attempts (and logs), but also<br>
gives you ample time to enact a countermeasure.<br>
<br>
> I will get the latest dovecot source code and modify it so that dovecot<br>
> will disconnect after "N" failed imap or pop3 login attacks, where "N" is<br>
> some sort of configuration variable (with a default of zero, meaning do not<br>
> disconnect). I will then use this personal version of dovecot with "N" set<br>
> to a fairly low value (probably 1!).<br>
<br>
1, in my opinion, is really too low. This can lockout a legitimate user<br>
with a simple typo, or network hiccough.<br>
<br>
It would be better to externalize this, rather than bake it into dovecot.<br>
Have you considered<br>
<br>
<a href="https://doc.dovecot.org/configuration_manual/authentication/auth_policy/" rel="noreferrer" target="_blank">https://doc.dovecot.org/configuration_manual/authentication/auth_policy/</a><br>
<br>
> Furthermore, I will continue to automatically monitor the logs and<br>
> perform the same iptables DROP actions for the failed login attempts.<br>
> The combination of these two actions will give me the behavior that I<br>
> desire.<br>
<br>
You can also preempt many BFD runs without resorting to one-strike-you're-out<br>
policy<br>
<br>
1) Look up connecting host in RBL and do a prememptive block<br>
e.g. <a href="http://bl.websitewelcome.com" rel="noreferrer" target="_blank">bl.websitewelcome.com</a>, <a href="http://bl.blocklist.de" rel="noreferrer" target="_blank">bl.blocklist.de</a>, <a href="http://dnsbl.darklist.de" rel="noreferrer" target="_blank">dnsbl.darklist.de</a><br>
are some examples of brute force DNSRBLs. You'll find many of<br>
attacking IPs are represented on one of these lists.<br>
<br>
2) Triggerimmediate block against authentication attempts that<br>
can not possibly be real (e.g. "mysql", "testuser", "nagios", etc.)<br>
<br>
Joseph Tam <<a href="mailto:jtam.home@gmail.com" target="_blank">jtam.home@gmail.com</a>><br>
</blockquote></div>