Hi,
Sorry for the delay in replying. Been having a few mail problems ironically! Gmail smtp server stopped working!
On 23/09/2019 4:13 PM, Bernd Petrovitsch via dovecot wrote:
It's not directly a solution within dovecot but "fail2ban" exists.
Yes, I have fail2ban, but that bans based on IP address. And most mail password attacks these days are distributed, and although fail2ban will try to spot them it doesn't do a very good job. I thought denying any logins without the @domain.com part would be an additional layer. I understand that there's no way these attempts could log in, its just that there are so many attempts logged, that it fills up 90% of my logs with noise, and prevents me from seeing the other important events.
Are users able to login without the @domain part?
No. All valid mail accounts are in the form user@domain.com
There is also sshguard that will do the same thing. One of these should probably be running anyway as they help mitigate issues where someone keep hammering on your system, however in the days of DDOS, they are less helpful than they used to be.
I'll take a look at sshguard, although it looks like its retroactive too: it waits for the events to be logged and then bans based on what it finds in the logs. I was intending to do something more proactive, at the dovecot layer, and ideally just silently drop them. Or throw the attempts into a different log perhaps. Just thinking out loud at this point. For the sake of completeness, there's also my personal favourite, CSF, which in my opinion does a better job than fail2ban, but still not exactly what I envisaged.
you can add username_filter = *@domain.com or deny-passdb before actual passdb with username_filter = !*@domain.com https://doc.dovecot.org/configuration_manual/authentication/password_databas...
This is more like what I had in mind. Let me try this out and I'll report back.
P.