Increasingly we are seeing distributed brute force login attacks on our Zimbra hosting environment, as well as on our on-premises customers’ Zimbra systems.
These login attempts typically come from 10 to 20 or so different IP addresses from around the globe, and are infrequent enough that Zimbra’s Denial of Service filter is not tripped, but the mailbox does get locked out from too many total bad login attempts. Increasingly, our customers are requiring their users to have Zimbra’s Two-Factor Authentication enabled, so to date no data breaches have occurred, but mailboxes are still getting locked out.
It’s incredibly frustrating and disruptive to the end user when their mailbox gets locked out. A Zimbra admin then has to set that status to Active, but unfortunately the mailbox gets locked out again shortly thereafter for as long as the distributed attack remains in progress.
There is a simple way to stop this from happening entirely, but there are some preliminary steps you need to take first…
Basic Zimbra Hardening Against Brute Force Attacks
In a previous blog post, I show how to use Zimbra’s Account Lockout Policy in conjunction with Zimbra’s Denial of Service filter. This works well when the brute force login attack comes from a single IP address, but it doesn’t protect against distributed attacks from multiple IP addresses. It also doesn’t protect against SMTP-Auth attacks on ports 587 and 465. For automated SMTP-Auth attack mitigation, we recommend using Fail2Ban on your MTA servers, as described in this blog post.
Be aware that many user accounts have lots of email aliases, including the Zimbra Global Admin account, which gets the postmaster@yourdomain.com alias by default. Bad actors frequently try logging in with well-know aliases as well as variations on a known user’s real name, so we configure Zimbra to allow logins only when users use their “real” email address, by running this command on every mailbox server (and restarting mailboxd):
zmlocalconfig -e alias_login_enabled=false
If you haven’t yet enabled 2FA for your users, now is the time to do so. Some of our customers require 2FA for all of their employees, and we see that multiple large providers are strongly encouraging 2FA. Salesforce recently announced that they will be making 2FA mandatory in the near future. Further, the annual Verizon data breach report (as well as data breach reports from other vendors) report that, had 2FA been in place, the overwhelming majority of email-driven data breaches would have been avoided.
We fully expect that 2FA will become mandatory in the near term, so we strongly suggest our customers deploy 2FA broadly now.
After you’ve done all of the above, you are now ready for the clever part…
Lets say John Doe’s mailbox john.doe@mydomain.com is getting repeatedly locked out through no fault of John’s. An admin looks through mailbox.log, and sees login attempts from ~20 different IP addresses that WHOIS shows belong to 10 or more different countries. Ugh…
Zimbra Hardening Against Distributed Brute Force Attacks
So here’s the strategy:
- First, rename John’s account to something no outsider will likely guess, e.g. john-tennisball.doe@mydomain.com.
- At the same time, add John’s original email as an alias.
zmprov ra john.doe@mydomain.com john-tennisball.doe@mydomain.com zmprov aaa john-tennisball.doe@mydomain.com john.doe@mydomain.com
So far, we’ve accomplished two things: Bad actors can no longer lock out John’s account when they try to log in as john.doe@mydomain.com (because we don’t allow alias logins any more), and; even though we’ve renamed his mailbox, John can continue to receive inbound email on his old, publicly known email address. No need to reprint his business cards, change his email signature, etc.
That’s great for keeping his account from getting locked out by bad actors, and maintaining uninterrupted inbound email, but what about outbound email? We don’t want John’s “tennis ball” email address to become publicly known. To solve that problem, John needs to make a few changes to his Preferences in the Zimbra Web Interface.
First, John needs to go to Preferences > Accounts > Accounts section and click the “Add Persona” button, to create a new Persona that uses the john.doe@mydomain.com email address.
Next, John needs to scroll down to the Primary Account Settings section on that same Preferences page, and set the “Choose what appears in the ‘From’ field of email messages” with his name and his now aliased john.doe@mydomain.com email address.
Finally, in that same section, John needs to click the “Set the ‘Reply-to” field of email messages to:” and set it exactly as above, using his name and his now aliased john.doe@mydomain.com email address.
Together, the above steps take care of both Inbound and Outbound email. If John uses an IMAP email client, he’ll need to configure the email client to do the same as above.
In other words, John should never give anyone his “tennis ball” email address, and he should never use his “tennis ball” email address for anything other than logging in to Zimbra!
We’ve had to utilize this process several times with a few of our customers who have an international presence, and it works well. But the Internet is global, so even if you have just local customers, vendors and suppliers, I challenge you to go check out the IP addresses for all of the failed logins in your mailbox.log and /var/log/zimbra.log files, and I’d wager that you will find IP addresses from around the globe. And if not, I’m sorry to say it will only be a matter of time.
Please stay safe, and let us know if you would like help with hardening your Zimbra system by filling out the form below:
Hope that helps,
L. Mark Stone
Mission Critical Email LLC
8 February 2021
The information provided in this blog is intended for informational and educational purposes only. The views expressed herein are those of Mr. Stone personally. The contents of this site are not intended as advice for any purpose and are subject to change without notice. Mission Critical Email makes no warranties of any kind regarding the accuracy or completeness of any information on this site, and we make no representations regarding whether such information is up-to-date or applicable to any particular situation. All copyrights are reserved by Mr. Stone. Any portion of the material on this site may be used for personal or educational purposes provided appropriate attribution is given to Mr. Stone and this blog.
