In principle, you can protect yourself from brute force using standard Zimbra OSE tools. Password security policy settings allow you to set the number of failed password attempts, after which the potentially attacked account is blocked. The main problem with this approach is that situations arise in which the accounts of one or more employees may be blocked due to a brute force attack, to which they have nothing to do, and the resultant simple work of the employees can cause big losses to the company. That is why this option of protection against brute force is best not to apply.
To protect against brute force, a special tool called DoSFilter is much better, which is built into Zimbra OSE and can automatically disconnect from Zimbra OSE via HTTP. In other words, the principle of operation of DoSFilter is similar to the principle of operation of PostScreen, only used for another protocol. Originally designed to limit the number of actions that a single user can perform, DoSFilter can also provide protection against brute force. Its key difference from the built-in tool in Zimbra is that after a certain number of unsuccessful attempts, it does not block the user himself, but the IP address from which multiple attempts are made to log into one or another account. Thanks to this, the system administrator can not only protect himself from brute force, but also avoid blocking company employees by simply adding the internal network of his company to the list of trusted IP addresses and subnets.
The big plus of DoSFilter is that in addition to numerous attempts to log into one or another account, using this tool you can automatically block those cybercriminals who took possession of the authentication data of the employee, and then successfully logged into his account and started sending hundreds of requests to the server.
You can configure DoSFilter using the following console commands:
- zimbraHttpDosFilterMaxRequestsPerSec - With this command you can set the maximum number of connections allowed for one user. By default, this value is 30 connections.
- zimbraHttpDosFilterDelayMillis - Using this command, you can set the delay in milliseconds for connections that exceed the limit set by the previous command. In addition to integer values, the administrator can specify 0 so that there is no delay at all, and also -1 so that all connections that exceed the specified limit are simply interrupted. By default, this value is -1.
- zimbraHttpThrottleSafeIPs - Using this command, the administrator can specify trusted IP addresses and subnets that will not be affected by the above restrictions. Note that the syntax of this command may vary depending on the desired result. So, for example, by entering the command zmprov mcf zimbraHttpThrottleSafeIPs 127.0.0.1 , you completely rewrite the entire list and leave only one IP address in it. If you enter the command zmprov mcf + zimbraHttpThrottleSafeIPs 127.0.0.1 , then the IP address you entered will be added to the white list. Similarly, using a subtraction sign, you can remove any IP from the list of allowed.
Note that DoSFilter can cause a number of problems when using the Zextras Suite Pro extensions. In order to avoid them, we recommend increasing the number of simultaneous connections from 30 to 100 using the command zmprov mcf zimbraHttpDosFilterMaxRequestsPerSec 100 . In addition, we recommend adding the internal network of the enterprise to the list of allowed. This can be done using the command zmprov mcf + zimbraHttpThrottleSafeIPs 192.168.0.0/24 . After making any changes to DoSFilter, be sure to restart the mail server using the zmmailboxdctl restart command.
The main disadvantage of DoSFilter is that it works at the application level and therefore can only limit the ability of attackers to perform various actions on the server, without limiting the ability to connect to the north. Because of this, requests for authentication or sending letters sent to the server, although they are obviously failures, will still be a good old DoS attack that cannot be stopped at such a high level.
In order to completely secure your corporate server with Zimbra OSE, you can use a solution such as Fail2ban, which is a framework that can constantly monitor information system logs for repeated actions and block the intruder by changing the firewall settings. Blocking at such a low level allows you to disable attackers right at the stage of IP-connection to the server. Thus, Fail2Ban can perfectly complement the protection built with DoSFilter. Let’s find out how you can make Fail2Ban friends with Zimbra OSE and thereby increase the security of your enterprise’s IT infrastructure.
Like any other enterprise-class application, Zimbra Collaboration Suite Open-Source Edition maintains detailed logs of its work. Most of them are stored in the / opt / zimbra / log / folder as files. Here are just a few of them:
- mailbox.log - Jetty mail service logs
- audit.log - authentication logs
- clamd.log - antivirus logs
- freshclam.log - antivirus update logs
- convertd.log - attachment converter logs
- zimbrastats.csv - server performance logs
Zimbra logs can also be found in the /var/log/zimbra.log file, where the logs of Postfix and Zimbra itself are maintained.
In order to protect our system from brute force, we will monitor mailbox.log , audit.log and zimbra.log .
In order for everything to work, you must have Fail2Ban and iptables installed on your server with Zimbra OSE. If you use Ubuntu, you can do this using the dpkg -s fail2ban commands , but if you use CentOS, you can verify this using the yum list installed fail2ban commands . In the event that you do not have Fail2Ban installed, then installing it will not be a problem, since this package is in almost all standard repositories.
After all the necessary software is installed, you can proceed to configure Fail2Ban. To do this, create the configuration file /etc/fail2ban/filter.d/zimbra.conf , in which we write regular expressions for Zimbra OSE logs that will correspond to incorrect login attempts and trigger Fail2Ban mechanisms. Here is an example of the contents of zimbra.conf with a set of regular expressions corresponding to various errors generated by Zimbra OSE when an authentication attempt fails:
# Fail2Ban configuration file [Definition] failregex = \[ip=<HOST>;\] account - authentication failed for .* \(no such account\)$ \[ip=<HOST>;\] security - cmd=Auth; .* error=authentication failed for .*, invalid password;$ ;oip=<HOST>;.* security - cmd=Auth; .* protocol=soap; error=authentication failed for .* invalid password;$ ;oip=<HOST>;.* security - cmd=Auth; .* protocol=imap; error=authentication failed for .* invalid password;$ \[oip=<HOST>;.* SoapEngine - handler exception: authentication failed for .*, account not found$ WARN .*;ip=<HOST>;ua=ZimbraWebClient .* security - cmd=AdminAuth; .* error=authentication failed for .*;$ ignoreregex =
Once the regular expressions for Zimbra OSE have been compiled, it's time to start editing the configuration of Fail2ban itself. The settings for this utility are located in the /etc/fail2ban/jail.conf file. Just in case, we’ll backup it using the command cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf.bak . After that, let's bring this file to the following form:
# Fail2Ban configuration file [DEFAULT] ignoreip = 192.168.0.1/24 bantime = 600 findtime = 600 maxretry = 5 backend = auto [ssh-iptables] enabled = false filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] sendmail-whois[name=SSH, dest=admin@company.ru, sender=fail2ban@company.ru] logpath = /var/log/messages maxretry = 5 [sasl-iptables] enabled = false filter = sasl backend = polling action = iptables[name=sasl, port=smtp, protocol=tcp] sendmail-whois[name=sasl, dest=support@company.ru] logpath = /var/log/zimbra.log [ssh-tcpwrapper] enabled = false filter = sshd action = hostsdeny sendmail-whois[name=SSH, dest=support@ company.ru] ignoreregex = for myuser from logpath = /var/log/messages [zimbra-account] enabled = true filter = zimbra action = iptables-allports[name=zimbra-account] sendmail[name=zimbra-account, dest=support@company.ru ] logpath = /opt/zimbra/log/mailbox.log bantime = 600 maxretry = 5 [zimbra-audit] enabled = true filter = zimbra action = iptables-allports[name=zimbra-audit] sendmail[name=Zimbra-audit, dest=support@company.ru] logpath = /opt/zimbra/log/audit.log bantime = 600 maxretry = 5 [zimbra-recipient] enabled = true filter = zimbra action = iptables-allports[name=zimbra-recipient] sendmail[name=Zimbra-recipient, dest=support@company.ru] logpath = /var/log/zimbra.log bantime = 172800 maxretry = 5 [postfix] enabled = true filter = postfix action = iptables-multiport[name=postfix, port=smtp, protocol=tcp] sendmail-buffered[name=Postfix, dest=support@company.ru] logpath = /var/log/zimbra.log bantime = -1 maxretry = 5
Although this example is quite universal, it’s worth explaining some parameters that you might want to change when setting up Fail2Ban yourself:
- Ignoreip - with this parameter you can specify a specific ip or subnet, the address from which Fail2Ban should not check. Typically, the internal network of the enterprise and other trusted addresses are added to the ignored list.
- Bantime - The time for which the intruder will ban. Measured in seconds. A value of -1 means an unlimited ban.
- Maxretry - The maximum number of times that one ip address can try to access the server.
- Sendmail - A setting that allows you to automatically send email alerts about the operation of Fail2Ban.
- Findtime - A setting that allows you to set the time interval after which the ip address can again try to access the server after the maximum number of failed attempts has been exhausted (maxretry parameter)
After saving the file with Fail2Ban settings, it remains only to restart this utility using the service fail2ban restart command . After a restart, the main Zimbra logs will constantly be monitored for regular expression matching. Thanks to this, the administrator will be able to virtually eliminate any possibility of an intruder entering not only the Zimbra Collaboration Suite Open-Source Edition mailboxes, but also protect all services running within the Zimbra OSE, as well as be aware of any attempts to gain unauthorized access.
For all questions related to the Zextras Suite, you can contact the representative of the Zextras company Ekaterina Triandafilidi by e-mail katerina@zextras.com