Zimbra and protection from mail bombing
Mail bombing is one of the oldest forms of cyber attacks. At its core, it resembles the usual DoS attack, only instead of a wave of requests from different ip-addresses, a shaft of emails is sent to the server, which in large quantities arrive at one of the email 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 cyber attack has led to a number of positive and negative consequences for system administrators. Positive factors include well-studied mail bombing and the availability of simple ways to defend against such an attack. The negative factors include a large number of publicly available software solutions for conducting these types of attacks and the ability for an attacker to reliably protect against detection.
An important feature of this cyber attack is that it is almost impossible to use for profit. Well, the attacker sent an e-mail shaft to one of the mailboxes, he didn’t give the person to use e-mail properly, the attacker hacked someone’s corporate e-mail and started sending thousands of letters to the whole GAL, which caused the server to crash or slow down so that it became impossible to use it, and then what? It is almost impossible to convert such a cybercrime into real money, therefore, just mail bombing is now quite a rare phenomenon and system administrators in infrastructure design may simply not recall the need to protect against such a cyber attack.
')
Nevertheless, despite the fact that mail bombing itself is rather meaningless from a commercial point of view, it is often part of other, more complex and multi-stage cyber attacks. 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 letter gets lost in their stream and goes unnoticed. Also, mail bombing can 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 may seriously hamper work with them and, as a result, may lead to equipment downtime, unfulfilled orders, as well as loss of reputation and loss of profits.
That is why the system administrator should not forget about the likelihood of mail bombing and always take the necessary measures to protect against this threat. If we take into account that this can be done at the stage of building the postal infrastructure, as well as the fact that it takes up a little time and labor from the system administrator, there are no objective reasons for not providing your infrastructure with protection from mail-bombing . Let's look at how 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 Mail Transfer Agent open source software at the moment. And one of the main advantages of its openness is that it supports a wide variety of third-party solutions for extending functionality. In particular, Postfix fully supports cbpolicyd, an advanced utility for ensuring the cybersecurity of the mail server. In addition to spam protection and the creation of white, black and gray lists, cbpolicyd allows the Zimbra administrator to configure SPF signature verification, as well as set limits on the reception and sending of emails or data. They can both provide reliable protection against spam and phishing emails, as well as protect the server from mail-bombing.
The first thing that the system administrator needs is to activate the cbpolicyd module, which is pre-installed in the Zimbra Collaboration Suite OSE on the infrastructure MTA server. This is done with 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 allow connections on the 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 write 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 at all, and in order to prevent unauthorized persons from entering it, you can simply close the connections on port 7780 after each login to the web interface.
Email quotas that can be set by cbpolicyd allow you to protect yourself from the flow of emails 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 per unit of time. For example, if the managers of your enterprise send on average 60-80 emails per hour, then you can, given the small margin, set them 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 have access to the mail of one of your managers will not arrange mail bombing or mass spam attacks in the enterprise.
In order to establish such a quota, you need to create a new mail restriction policy in the web interface and specify that it act both on letters sent within the domain and on letters acting to 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 a time interval, after which the restrictions will be updated, as well as a message that will be received by the user who has exceeded his limit. After that, you can set the very restriction on sending letters. It can be specified both as the number of outgoing letters and as the number of bytes of information transmitted. In this case, with letters that are sent above the designated limit, do differently. 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 during the detection of the optimal limit value for sending emails by employees.
In addition to the restrictions on sending emails, cbpolicyd allows you to configure a limit on how to receive emails. Such a restriction, at first glance, is an excellent solution for protection against mail-bombing, but in fact setting such a limit, even a large one, is fraught with the fact that in certain conditions an important letter may not reach you. That is why it is not recommended to include any restrictions for incoming mail. However, if you still decide to take a risk, you need to approach the setting of the limit of incoming messages with special attention. For example, you can limit the number of incoming letters from trusted counterparties, so that if their mail server is compromised, it will not spam your company.
In order to protect against the shaft of incoming messages when mail-bombing, the system administrator should undertake something smarter than a simple restriction of incoming mail. Such a solution could be the use of gray lists. The principle of their operation lies in the fact that the first attempt to deliver a message from an unreliable sender, the connection with the server is abruptly interrupted, which is why the delivery of the letter fails. However, if, during a certain period, an unreliable server again attempts to send the same letter, the server does not terminate the connection and its delivery is successful.
The point of all these actions is that the programs for automatically sending mass e-mails usually do not check 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 graylists in the cbpolicyd web interface. In order for everything to work, you need to create a policy that would contain all incoming emails addressed to users on our server, and then, based on this policy, create a Greylisting rule where you can configure an interval during which cbpolicyd will wait for a second response from an unfamiliar the sender. It is usually 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, the decision was 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 is worth looking with maximum responsibility. It would be best if the use of this technology will go hand in hand with the constant maintenance of white and black lists, in order to exclude the possibility of losing the letters that are really important for the enterprise.
In addition, adding SPF, DMARC, and DKIM checks can help protect against mail bombing. Often letters that arrive in the process of mail bombing such checks do not pass. How to do this was described in one of our previous articles .
Thus, it is quite simple to protect yourself from such a threat as mail-bombing, and this can be done even during the construction phase of the Zimbra infrastructure for your enterprise. However, it is important to constantly ensure that the risks of using such protection never exceed the benefits you receive.
An important feature of this cyber attack is that it is almost impossible to use for profit. Well, the attacker sent an e-mail shaft to one of the mailboxes, he didn’t give the person to use e-mail properly, the attacker hacked someone’s corporate e-mail and started sending thousands of letters to the whole GAL, which caused the server to crash or slow down so that it became impossible to use it, and then what? It is almost impossible to convert such a cybercrime into real money, therefore, just mail bombing is now quite a rare phenomenon and system administrators in infrastructure design may simply not recall the need to protect against such a cyber attack.
')
Nevertheless, despite the fact that mail bombing itself is rather meaningless from a commercial point of view, it is often part of other, more complex and multi-stage cyber attacks. 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 letter gets lost in their stream and goes unnoticed. Also, mail bombing can 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 may seriously hamper work with them and, as a result, may lead to equipment downtime, unfulfilled orders, as well as loss of reputation and loss of profits.
That is why the system administrator should not forget about the likelihood of mail bombing and always take the necessary measures to protect against this threat. If we take into account that this can be done at the stage of building the postal infrastructure, as well as the fact that it takes up a little time and labor from the system administrator, there are no objective reasons for not providing your infrastructure with protection from mail-bombing . Let's look at how 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 Mail Transfer Agent open source software at the moment. And one of the main advantages of its openness is that it supports a wide variety of third-party solutions for extending functionality. In particular, Postfix fully supports cbpolicyd, an advanced utility for ensuring the cybersecurity of the mail server. In addition to spam protection and the creation of white, black and gray lists, cbpolicyd allows the Zimbra administrator to configure SPF signature verification, as well as set limits on the reception and sending of emails or data. They can both provide reliable protection against spam and phishing emails, as well as protect the server from mail-bombing.
The first thing that the system administrator needs is to activate the cbpolicyd module, which is pre-installed in the Zimbra Collaboration Suite OSE on the infrastructure MTA server. This is done with 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 allow connections on the 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 write 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 at all, and in order to prevent unauthorized persons from entering it, you can simply close the connections on port 7780 after each login to the web interface.
Email quotas that can be set by cbpolicyd allow you to protect yourself from the flow of emails 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 per unit of time. For example, if the managers of your enterprise send on average 60-80 emails per hour, then you can, given the small margin, set them 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 have access to the mail of one of your managers will not arrange mail bombing or mass spam attacks in the enterprise.
In order to establish such a quota, you need to create a new mail restriction policy in the web interface and specify that it act both on letters sent within the domain and on letters acting to 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 a time interval, after which the restrictions will be updated, as well as a message that will be received by the user who has exceeded his limit. After that, you can set the very restriction on sending letters. It can be specified both as the number of outgoing letters and as the number of bytes of information transmitted. In this case, with letters that are sent above the designated limit, do differently. 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 during the detection of the optimal limit value for sending emails by employees.
In addition to the restrictions on sending emails, cbpolicyd allows you to configure a limit on how to receive emails. Such a restriction, at first glance, is an excellent solution for protection against mail-bombing, but in fact setting such a limit, even a large one, is fraught with the fact that in certain conditions an important letter may not reach you. That is why it is not recommended to include any restrictions for incoming mail. However, if you still decide to take a risk, you need to approach the setting of the limit of incoming messages with special attention. For example, you can limit the number of incoming letters from trusted counterparties, so that if their mail server is compromised, it will not spam your company.
In order to protect against the shaft of incoming messages when mail-bombing, the system administrator should undertake something smarter than a simple restriction of incoming mail. Such a solution could be the use of gray lists. The principle of their operation lies in the fact that the first attempt to deliver a message from an unreliable sender, the connection with the server is abruptly interrupted, which is why the delivery of the letter fails. However, if, during a certain period, an unreliable server again attempts to send the same letter, the server does not terminate the connection and its delivery is successful.
The point of all these actions is that the programs for automatically sending mass e-mails usually do not check 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 graylists in the cbpolicyd web interface. In order for everything to work, you need to create a policy that would contain all incoming emails addressed to users on our server, and then, based on this policy, create a Greylisting rule where you can configure an interval during which cbpolicyd will wait for a second response from an unfamiliar the sender. It is usually 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, the decision was 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 is worth looking with maximum responsibility. It would be best if the use of this technology will go hand in hand with the constant maintenance of white and black lists, in order to exclude the possibility of losing the letters that are really important for the enterprise.
In addition, adding SPF, DMARC, and DKIM checks can help protect against mail bombing. Often letters that arrive in the process of mail bombing such checks do not pass. How to do this was described in one of our previous articles .
Thus, it is quite simple to protect yourself from such a threat as mail-bombing, and this can be done even during the construction phase of the Zimbra infrastructure for your enterprise. However, it is important to constantly ensure that the risks of using such protection never exceed the benefits you receive.
Source: https://habr.com/ru/post/455525/
All Articles