Using Zimbra’s DoSFilter and Failed Login Lockout Policy Together

Using Zimbra’s DoSFilter and Failed Login Lockout Policy Together

Zimbra’s DoSFilter (Denial of Service Filter) is a mechanism to throttle or block IP addresses that have a repeated number of failed logins to your Zimbra system.  Zimbra’s Classes of Service include a Failed Login Lockout policy that will put a mailbox in Locked Out mode, hopefully before a brute force attack is successful.  The two together can improve system security and protect legitimate users, but only if configured appropriately.

DoSFilter is generally easier to configure than fail2ban in multiserver systems, because in a multi-server system the logger host is usually one of the mailbox servers, but you want to do the fail2ban blocking on the MTA and Proxy servers.  Making all that work is complex, and if you are running Network Edition, Zimbra Support can help you troubleshoot DoSFilter; with fail2ban you are on your own.  On single server Zimbra systems, fail2ban works fine, but you’ll need to source up to date Zimbra “jail” configuration files, so yet another reason to favor DoSFilter over fail2ban.

To use fail2ban to block IPs that abuse Zimbra’s Postfix Submission port (587/tcp), please see my separate blog post on that subject.

Challenge:
Since the DoSFilter configurations are made via the commandline only, but the Failed Login Lockout Policy can be configured via the Admin Console, often what I encounter is well-intentioned system administrators who inadvertently cause their users mailboxes to be locked out by the near continuous brute force attacks we all experience.

Solution:
The trick is to make DoSFilter your first line of defense:  Have DoSFilter block or throttle IP addresses before the Failed Login Lockout Policy kicks in.

In this way, your legitimate users won’t get locked out on account of a brute force attack from someplace else.

Steps To Implement:
Let’s first configure DoSFilter to throttle, for 30 minutes, bad actors who have produced more than 10 failed logins; as well as bad actors who try to overwhelm our server with more than 100 requests per second.  As the zimbra user, just run:

zmprov mcf zimbraHttpDosFilterDelayMillis 20
zmprov mcf zimbraHttpDosFilterMaxRequestsPerSec 250
zmprov mcf zimbraInvalidLoginFilterDelayInMinBetwnReqBeforeReinstating 30
zmprov mcf zimbraInvalidLoginFilterMaxFailedLogin 10
zmprov mcf zimbraInvalidLoginFilterReinstateIpTaskIntervalInMin 5

The above will take care of throttling individual misbehaving IP addresses, but now we want to lock out a mailbox for an hour, if there are more than 15 failed login attempts (from anywhere) within a one hour period.  For every Class of Service on your system, in the Admin Console navigate to Home > Configure > Class of Service > (each class of service) > Advanced > Failed Login Policy and set the parameters thus:

If you are in a large organization, and you have branch offices with large numbers of users who repeatedly keep trying bad passwords, there’s a chance that DoSFilter could wind up throttling the entire branch.  In that case, you’ll be pressured to “white list” those branch IP addresses (typically the WAN IP of the branch office router) from DoSFilter.  This is also done from the commandline only. If your branch office WAN IP is 35.171.80.173, you would run as the zimbra user:

zmprov mcf +zimbraHttpThrottleSafeIPs 35.171.80.173/32

These three steps, enabling DoSFilter, setting a Failed Login Policy at a higher threshold, and whitelisting your branch office WAN IPs, will go a long way to blocking bad actors while still keeping Zimbra available to legitimate users.

Identifying Bad Actors Causing DoSFilter IP Blocking:
Once DoSFilter kicks in and starts throttling an IP address, it can be nice to know which IP address(es) DoSFilter is throttling, and who is causing the issue.  This knowledge can take on some urgency when the Help Desk starts getting a flood of calls from a branch office, whose users are being pummeled with “Network Service Errors” as a result of one or more users repeatedly retrying a bad password.

Unfortunately, there is no UI for this in the Admin Console like there is for Locked Out accounts, so we need to go to the commandline on our mailbox server(s).  As the zimbra user, you can run:

cat ~/log/mailbox.log | grep "suspended, for repeated failed login."

and you’ll get a list of the IP addresses DoSFilter is currently blocking.  Now, we need to find out who is causing the blocking, so again as the zimbra user you can run:

cat ~/log/mailbox.log | grep "authentication failed"

and you’ll get a list of all the authentication failures. Look for the “oip=<IP address>”  section of most lines (“oip” means “Original IP Address”,  i.e. the IP address that DoSFilter will choose to block when bad requests exceed the threshold).  Match the oip address to the IP that DoSFilter is blocking, and you’ll have discovered the user(s) causing DoSFilter to trigger.

If you succumb to the pressure to whitelist the branch office IP address, to avoid DoSFilter applying to the branch at all (see above), just remember that the revised whitelisting does not take effect until you restart the mailbox service.

 

If you’d like help reviewing and improving your Zimbra security posture, get in touch with us by filling out the form below!

 

Hope that helps,
L. Mark Stone
Mission Critical Email
19 October 2018; Updated 5 August 2019 and 3 August 2020

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.