June 10, 2019 at 12:39Zimbra and Mail Bomb Defense
Email bombing is one of the oldest types of cyber attacks. At its core, it resembles a regular DoS attack, but instead of a wave of requests from different ip-addresses, a shaft of emails is sent to the server, which in huge quantities arrive at one of the mail addresses, due to which the load on it increases significantly. Such an attack can lead to the inability to use the mailbox, and sometimes even can lead to the failure of the entire server. The long history of this type of cyberattack has led to a number of positive and negative consequences for system administrators. The positive factors include a good knowledge of email bombing and the availability of simple ways to defend against such an attack.
An important feature of this cyberattack is that it is almost impossible to use for profit. Well, the attacker sent a shaft of emails to one of the mailboxes, well, he didn’t allow the person to use email normally, well, the attacker hacked someone’s corporate mail and started mass mailing thousands of emails all over the GAL, because of which the server either crashed or started to slow down so that it became impossible to use it, and what next? Converting such a cybercrime into real money is almost impossible, so simply email bombing is currently quite rare and system administrators when designing infrastructure may simply not remember the need to protect against such a cyber attack.
Nevertheless, in spite of the fact that email bombing itself is a rather senseless commercial activity, it is often an integral part of other, more complex and multi-stage cyberattacks. For example, when hacking mail and using it to hijack an account in a public service, attackers often “bomb” the victim's mailbox with meaningless letters so that the confirmation message gets lost in their stream and goes unnoticed. Email bombing can also be used as a means of economic pressure on the enterprise. Thus, the active bombardment of the public mailbox of an enterprise, for which applications from customers are received, can seriously complicate the work with them and, as a result, can lead to equipment downtime, outstanding orders, as well as loss of reputation and lost profit.
That is why the system administrator should not forget about the likelihood of conducting email bombing and always take the necessary measures to protect against this threat. Given that this can be done even at the stage of building the mail infrastructure, as well as the fact that it takes the system administrator very little time and labor, objective reasons in order not to provide their infrastructure with protection from email bombing, simply does not remain . Let’s take a look at how the protection against this cyber attack is implemented in the Zimbra Collaboration Suite Open-Source Edition.
At the heart of Zimbra is Postfix - one of the most reliable and functional Open Source Mail Transfer Agents at the moment. And one of the main advantages of its openness is that it supports a wide variety of third-party solutions for expanding functionality. In particular, Postfix fully supports cbpolicyd, an advanced cybersecurity utility for the mail server. In addition to protecting against spam and creating whitelists, blacklists, and gray lists, cbpolicyd allows the Zimbra administrator to set up SPF signature verification, as well as set limits for receiving and sending emails or data. They can provide reliable protection against spam and phishing emails, as well as protect the server from email bombing.
The first thing that is required from the system administrator is the activation of the cbpolicyd module, which is preinstalled in the Zimbra Collaboration Suite OSE on the infrastructure MTA server. This is done using the command zmprov ms `zmhostname` + zimbraServiceEnabled cbpolicyd. After that, you will need to activate the web interface in order to be able to comfortably manage cbpolicyd. To do this, you need to enable connections on web port number 7780, create a symbolic link using the command ln -s / opt / zimbra / common / share / webui / opt / zimbra / data / httpd / htdocs / webui , and then edit the settings file using the command nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php , where you need to register the following lines:
After that, it remains only to restart the Zimbra and Zimbra Apache services using the zmcontrol restart and zmapachectl restart commands. After that, you will have access to the web interface at example.com : 7780 / webui / index.php . The main nuance is that the entrance to this web interface is not protected in any way, and in order to prevent unauthorized persons from entering it, you can simply close the connections on port 7780 after each entrance to the web interface.
Quotas for sending emails, which can be set thanks to cbpolicyd, allow you to protect yourself from the flow of letters coming from the internal network. Such quotas allow you to set a limit on the maximum number of letters that can be sent from one mailbox to one unit of time. For example, if the managers of your company send an average of 60-80 emails per hour, then, given the small margin, you can set a quota of 100 emails per hour. In order to exhaust such a quota, managers will have to send one letter every 36 seconds. On the one hand, this is enough to fully work, and on the other hand, with such a quota, attackers who gain access to the mail of one of your managers will not arrange email bombing or mass spam attacks at the enterprise.
In order to set such a quota, it is necessary to create a new restriction policy for sending letters in the web interface and specify that it act both on letters sent within the domain and on letters acting on external addresses. This is done as follows:
After that, it will be possible to specify in more detail the restrictions associated with sending letters, in particular, set the time interval after which the restrictions will be updated, as well as the message that the user who exceeds his limit will receive. After that, you can set the restriction on sending letters. It can be set both as the number of outgoing letters, and as the number of bytes of transmitted information. In this case, with letters that are sent in excess of the designated limit, do differently. So, for example, you can simply delete them immediately, or you can save them so that they go immediately after updating the limit for sending messages. The second option can be used when identifying the optimal limit for sending emails by employees.
In addition to restrictions on sending letters, cbpolicyd allows you to configure a limit on receiving letters. Such a restriction, at first glance, is an excellent solution for protection against email bombing, but in fact the establishment of such a limit, even if large, is fraught with the fact that under certain conditions an important letter may not reach you. That is why it is highly discouraged to include any restrictions for incoming mail. However, if you still decide to take a chance, to approach the setting of the limit of incoming messages you need to approach with special attention. For example, you can limit the number of incoming letters from trusted counterparties so that if their mail server was compromised, it would not carry out a spam attack on your company.
In order to protect yourself from the shaft of incoming messages during email bombing, the system administrator should do something smarter than simply restricting incoming mail. Such a solution could be the use of gray lists. The principle of their action is that the first attempt to deliver a message from an unreliable sender, the connection to the server is abruptly interrupted, which is why the delivery of the message fails. However, if in a certain period the unreliable server again attempts to send the same message, the server does not disconnect and its delivery is successful.
The meaning of all these actions is that programs for automatic mass mailing of emails usually do not verify the success of the delivery of the sent message and do not attempt to send it a second time, while the person will surely make sure whether his letter was sent to the address or not.
You can also enable gray lists in the cbpolicyd web interface. In order for everything to work, it is necessary to create a policy that would include all incoming letters addressed to users on our server, and then create a Greylisting rule based on this policy, where you can configure the interval during which cbpolicyd will wait for a repeated response from an unknown sender. Usually it is 4-5 minutes. At the same time, gray lists can be configured so that all successful and unsuccessful attempts to deliver letters from different senders are taken into account and, based on their number, a decision is made to automatically add the sender to the white or black lists.
We draw your attention to the fact that the use of gray lists should be approached with maximum responsibility. It will be best if the use of this technology goes hand in hand with the constant maintenance of white and black lists in order to exclude the possibility of losing letters that are really important for the enterprise.
In addition, adding SPF, DMARC, and DKIM checks can help protect against mail bombing. Often, letters received during the mail bombing process do not pass such checks. How to do this was described in one of our previous articles .
Thus, protecting yourself from such threats as email bombing is quite simple, and you can do this even at the stage of building the Zimbra infrastructure for your enterprise. However, it is important to constantly ensure that the risks from using such protection never exceed the benefits you receive.
For all questions related to the Zextras Suite, you can contact the representative of Zextras Katerina Triandafilidi by e-mail katerina@zextras.com
An important feature of this cyberattack is that it is almost impossible to use for profit. Well, the attacker sent a shaft of emails to one of the mailboxes, well, he didn’t allow the person to use email normally, well, the attacker hacked someone’s corporate mail and started mass mailing thousands of emails all over the GAL, because of which the server either crashed or started to slow down so that it became impossible to use it, and what next? Converting such a cybercrime into real money is almost impossible, so simply email bombing is currently quite rare and system administrators when designing infrastructure may simply not remember the need to protect against such a cyber attack.
Nevertheless, in spite of the fact that email bombing itself is a rather senseless commercial activity, it is often an integral part of other, more complex and multi-stage cyberattacks. For example, when hacking mail and using it to hijack an account in a public service, attackers often “bomb” the victim's mailbox with meaningless letters so that the confirmation message gets lost in their stream and goes unnoticed. Email bombing can also be used as a means of economic pressure on the enterprise. Thus, the active bombardment of the public mailbox of an enterprise, for which applications from customers are received, can seriously complicate the work with them and, as a result, can lead to equipment downtime, outstanding orders, as well as loss of reputation and lost profit.
That is why the system administrator should not forget about the likelihood of conducting email bombing and always take the necessary measures to protect against this threat. Given that this can be done even at the stage of building the mail infrastructure, as well as the fact that it takes the system administrator very little time and labor, objective reasons in order not to provide their infrastructure with protection from email bombing, simply does not remain . Let’s take a look at how the protection against this cyber attack is implemented in the Zimbra Collaboration Suite Open-Source Edition.
At the heart of Zimbra is Postfix - one of the most reliable and functional Open Source Mail Transfer Agents at the moment. And one of the main advantages of its openness is that it supports a wide variety of third-party solutions for expanding functionality. In particular, Postfix fully supports cbpolicyd, an advanced cybersecurity utility for the mail server. In addition to protecting against spam and creating whitelists, blacklists, and gray lists, cbpolicyd allows the Zimbra administrator to set up SPF signature verification, as well as set limits for receiving and sending emails or data. They can provide reliable protection against spam and phishing emails, as well as protect the server from email bombing.
The first thing that is required from the system administrator is the activation of the cbpolicyd module, which is preinstalled in the Zimbra Collaboration Suite OSE on the infrastructure MTA server. This is done using the command zmprov ms `zmhostname` + zimbraServiceEnabled cbpolicyd. After that, you will need to activate the web interface in order to be able to comfortably manage cbpolicyd. To do this, you need to enable connections on web port number 7780, create a symbolic link using the command ln -s / opt / zimbra / common / share / webui / opt / zimbra / data / httpd / htdocs / webui , and then edit the settings file using the command nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php , where you need to register the following lines:
$ DB_DSN = "sqlite: /opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$ DB_USER = "root";
$ DB_TABLE_PREFIX = "";
After that, it remains only to restart the Zimbra and Zimbra Apache services using the zmcontrol restart and zmapachectl restart commands. After that, you will have access to the web interface at example.com : 7780 / webui / index.php . The main nuance is that the entrance to this web interface is not protected in any way, and in order to prevent unauthorized persons from entering it, you can simply close the connections on port 7780 after each entrance to the web interface.
Quotas for sending emails, which can be set thanks to cbpolicyd, allow you to protect yourself from the flow of letters coming from the internal network. Such quotas allow you to set a limit on the maximum number of letters that can be sent from one mailbox to one unit of time. For example, if the managers of your company send an average of 60-80 emails per hour, then, given the small margin, you can set a quota of 100 emails per hour. In order to exhaust such a quota, managers will have to send one letter every 36 seconds. On the one hand, this is enough to fully work, and on the other hand, with such a quota, attackers who gain access to the mail of one of your managers will not arrange email bombing or mass spam attacks at the enterprise.
In order to set such a quota, it is necessary to create a new restriction policy for sending letters in the web interface and specify that it act both on letters sent within the domain and on letters acting on external addresses. This is done as follows:
After that, it will be possible to specify in more detail the restrictions associated with sending letters, in particular, set the time interval after which the restrictions will be updated, as well as the message that the user who exceeds his limit will receive. After that, you can set the restriction on sending letters. It can be set both as the number of outgoing letters, and as the number of bytes of transmitted information. In this case, with letters that are sent in excess of the designated limit, do differently. So, for example, you can simply delete them immediately, or you can save them so that they go immediately after updating the limit for sending messages. The second option can be used when identifying the optimal limit for sending emails by employees.
In addition to restrictions on sending letters, cbpolicyd allows you to configure a limit on receiving letters. Such a restriction, at first glance, is an excellent solution for protection against email bombing, but in fact the establishment of such a limit, even if large, is fraught with the fact that under certain conditions an important letter may not reach you. That is why it is highly discouraged to include any restrictions for incoming mail. However, if you still decide to take a chance, to approach the setting of the limit of incoming messages you need to approach with special attention. For example, you can limit the number of incoming letters from trusted counterparties so that if their mail server was compromised, it would not carry out a spam attack on your company.
In order to protect yourself from the shaft of incoming messages during email bombing, the system administrator should do something smarter than simply restricting incoming mail. Such a solution could be the use of gray lists. The principle of their action is that the first attempt to deliver a message from an unreliable sender, the connection to the server is abruptly interrupted, which is why the delivery of the message fails. However, if in a certain period the unreliable server again attempts to send the same message, the server does not disconnect and its delivery is successful.
The meaning of all these actions is that programs for automatic mass mailing of emails usually do not verify the success of the delivery of the sent message and do not attempt to send it a second time, while the person will surely make sure whether his letter was sent to the address or not.
You can also enable gray lists in the cbpolicyd web interface. In order for everything to work, it is necessary to create a policy that would include all incoming letters addressed to users on our server, and then create a Greylisting rule based on this policy, where you can configure the interval during which cbpolicyd will wait for a repeated response from an unknown sender. Usually it is 4-5 minutes. At the same time, gray lists can be configured so that all successful and unsuccessful attempts to deliver letters from different senders are taken into account and, based on their number, a decision is made to automatically add the sender to the white or black lists.
We draw your attention to the fact that the use of gray lists should be approached with maximum responsibility. It will be best if the use of this technology goes hand in hand with the constant maintenance of white and black lists in order to exclude the possibility of losing letters that are really important for the enterprise.
In addition, adding SPF, DMARC, and DKIM checks can help protect against mail bombing. Often, letters received during the mail bombing process do not pass such checks. How to do this was described in one of our previous articles .
Thus, protecting yourself from such threats as email bombing is quite simple, and you can do this even at the stage of building the Zimbra infrastructure for your enterprise. However, it is important to constantly ensure that the risks from using such protection never exceed the benefits you receive.
For all questions related to the Zextras Suite, you can contact the representative of Zextras Katerina Triandafilidi by e-mail katerina@zextras.com