Zimbra Collaboration Suite Open-Source Edition has several powerful information security tools in its arsenal. Among them - a solution to protect the mail server from attacks by botnets, ClamAV - an antivirus that can scan incoming files and letters for malware infection, as well as one of the best spam filters today. However, these tools are unable to protect Zimbra OSE from this type of attack, such as brute force. Not the most elegant, but still quite effective password brute force using a special dictionary is fraught not only with the likelihood of a successful hack with all the ensuing consequences, but also with the creation of a significant load on the server that processes all unsuccessful attempts to hack the server with Zimbra OSE.
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 unsuccessful password entry attempts, after which the potentially attacked account is blocked. The main problem with this approach is that there are situations 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 resulting downtime in the work of employees can bring big losses to the company. That is why it is best not to use this option of protection against brute force.
To protect against brute force, a special tool called DoSFilter is much better suited, which is built into Zimbra OSE and can automatically terminate the connection to Zimbra OSE via HTTP. In other words, the principle of DoSFilter is similar to the principle of PostScreen, only it is used for a different protocol. Originally designed to limit the number of actions a single user can take, DoSFilter can also provide protection against brute force. Its key difference from the tool built into Zimbra is that after a certain number of unsuccessful attempts, it blocks not 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 employees of the enterprise by simply adding the internal network of his enterprise to the list of trusted IP addresses and subnets.
The big advantage of DoSFilter is that in addition to numerous attempts to log into one or another account, using this tool, you can automatically block those intruders who took possession of the employee's authentication data, and then successfully logged into his account and began 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 per user. By default, this value is 30 connections.
- zimbraHttpDosFilterDelayMillis - With this command, you can set a delay in milliseconds for connections that will exceed the limit specified by the previous command. In addition to integer values, the administrator can specify 0 to have no delay at all, as well as -1 to simply terminate all connections that exceed the specified limit. 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 restrictions listed above. 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 will completely overwrite the entire list and leave only one IP address in it. If you enter the command zmprov mcf +zimbraHttpThrottleSafeIPs 127.0.0.1, the IP address you entered will be added to the whitelist. Similarly, using the subtraction sign, you can remove any IP from the allowed list.
Note that DoSFilter can create a number of problems when using 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 that you add the company's internal network to the allowed list. You can do this with the command zmprov mcf +zimbraHttpThrottleSafeIPs 192.168.0.0/24. After making any changes to DoSFilter, be sure to restart the mail server with the command zmmailboxdctl restart.
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 server. Because of this, requests sent to the server for authentication or sending letters, although they will obviously fail, will still be a good old DoS attack, which 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 repetitive actions and block the intruder by changing the firewall settings. Blocking at such a low level allows you to disable intruders right at the stage of the IP connection to the server. Thus, Fail2Ban can perfectly complement the protection built with DoSFilter. Let's find out how you can make friends with Fail2Ban 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 keeps detailed logs of its work. Most of them are stored in the folder /opt/zimbra/log/ in the form of files. Here are just a few of them:
- mailbox.log - Jetty mail service logs
- audit.log - authentication logs
- clamd.log - antivirus operation logs
- freshclam.log - antivirus update logs
- convertd.log - attachment converter logs
- zimbrastats.csv - server performance logs
Also Zimbra logs can be found in the file /var/log/zimbra.log, where the logs of Postfix and Zimbra itself are kept.
In order to protect our system from brute force, we will monitor mailbox.log, audit.log и zimbra.log.
In order for everything to work, you need to have Fail2Ban and iptables installed on your Zimbra OSE server. In the event that you are using Ubuntu, you can do this using the commands dpkg -s fail2ban, if you are using CentOS, then you can check this using the commands yum list installed fail2ban. 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 start configuring Fail2Ban. To do this, you need to create a configuration file /etc/fail2ban/filter.d/zimbra.conf, in which we write regular expressions for the Zimbra OSE logs, which will match invalid login attempts and trigger the Fail2Ban mechanisms. Here is an example of the contents of zimbra.conf with a set of regular expressions corresponding to various errors issued in 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 =After the regular expressions for Zimbra OSE are compiled, it's time to start editing the configuration of Fail2ban itself. The settings for this utility are located in the file /etc/fail2ban/jail.conf. Just in case, we will make a backup copy of it using the command cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf.bak. After that, we will 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, [email protected], [email protected]]
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, [email protected]]
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, [email protected] ]
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, [email protected]]
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, [email protected]]
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, [email protected]]
logpath = /var/log/zimbra.log
bantime = -1
maxretry = 5While this example is pretty generic, it's worth explaining some of the settings you might want to change when configuring Fail2Ban yourself:
- Ignoreip - using this parameter, you can specify a specific ip or subnet, addresses from which Fail2Ban should not check. As a rule, the internal network of the enterprise and other trusted addresses are added to the list of ignored ones.
- Bantime - The time for which the offender will be banned. Measured in seconds. A value of -1 means an indefinite 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 notifications 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 unsuccessful attempts has been exhausted (maxretry parameter)
After saving the file with the Fail2Ban settings, it remains only to restart this utility using the command service fail2ban restart. After restarting, the main Zimbra logs will be constantly monitored for regular expressions. Thanks to this, the administrator will be able to virtually eliminate any possibility of an attacker penetrating not only Zimbra Collaboration Suite Open-Source Edition mailboxes, but also protect all services running within Zimbra OSE, and be aware of any attempts to gain unauthorized access.
For all questions related to Zextras Suite, you can contact the Representative of Zextras Ekaterina Triandafilidi by e-mail [email protected]
Source: habr.com