June 27, 2019 at 13:48Zimbra and server overload protection
Email has solidified itself as a standard for business communication. Due to the high economic efficiency of emails, as well as a number of features associated with quoting text and attaching attachments, it is emails that are the best suited for the role of a universal way for document exchange and polite business communication. These same features have become the reason why spammers are so fond of email. As a result, today e-mail is a huge raging ocean of spam, in the waters of which only occasionally business letters are found. That is why one of the primary tasks of the administrator of any mail server is protection against spam mailings. Let's take a look at what you can do with this in the Zimbra Collaboration Suite Open-Source Edition.
Despite the free solution, Zimbra OSE is able to provide the system administrator with a ton of extremely effective tools to solve the problem of receiving unwanted emails. We already wrote about such utilities as Amavis, SpamAssassin, ClamAV and cbpolicyd, which allow you to reliably filter incoming mail by filtering out spam mails, as well as infected and phishing emails. Nevertheless, their key drawback is that they all work with already received mail messages and spend system resources on filtering useless messages, which can always be found much better. But what if your enterprise was caught in the eye of a large botnet that constantly throws your mail server in such large quantities of junk emails that filtering them alone will take up the lion's share of MTA server capacity?
In theory, you can protect yourself from this by connecting a cloud service to filter incoming mail, but in practice this method of protection is not suitable for every enterprise, because in this case you will have to entrust third parties with processing not only spam, but also business correspondence, which is not always safe, and often directly contrary to the company's security policy. In addition, there are risks associated with the reliability of the cloud spam filter. The way out of this situation may be the organization of server protection on its own. Especially for these purposes, Zimbra had a built-in utility Postscreen, which is designed to protect the mail server from letters sent by botnets, without loading the mail server.
The essence of the work of Postscreen is that this utility scans all requests for connecting to the mail server and does not allow those clients that it seems suspicious to connect to the server. Since, according to statistics, about 90% of spam in the world is sent by botnets, Postscreen is often used as the first degree of protection for a mail server from unwanted mailings. Thanks to this, the mail server can work stably without overloads even in the face of strong spam attacks from large botnets.
The principle of operation of Postscreen is quite simple, the utility is able to carry out a number of simple checks of incoming letters before transferring them to the mail server or other services that conduct a more in-depth and detailed verification of incoming letters. Each of the checks, respectively, may be passed, but may not be passed. Based on the results of each of the checks, Postscreen can apply one of three actions at the choice of the Zimbra administrator: Drop , Ignore or Enforce . The Drop action forcibly disconnects from the client in case the verification fails, the Ignore actionallows you to ignore the results of the verification when making the final decision, but at the same time collect information and statistics about the checks, and the Enforce action allows you to take into account the results of the checks when making the final decision, but at the same time continue to perform all the tests that are planned by the system administrator.
The simple principle of operation does not mean ease of use and configuration. The fact is that a misconfigured Postscreen may become the reason why a number of messages that are important for the enterprise will not reach the addressee. That is why it is necessary to approach the setup of such a powerful tool as Postscreen with great care and constantly test it for behavior in certain situations.
Postscreen in Zimbra is included initially, but many may not be happy with the initial configuration. Now we will look at the best option for configuring Postscreen in terms of security and risk-free. Its essence is that after the failure of any of the checks, Postscreen will not disconnect from the client without talking, but will conduct all the checks to the end and if these checks fail, it will give an error message. This will notify the living sender of the non-delivery of the message if Postscreen accepts it as spam. This is achieved by setting the enforce value in the parameters of the checks. It is this value that allows you to complete the started checks to the end, without breaking the connection with the client at the first failure, but at the same time, upon completion, still block the spam email,
In order to enable the necessary checks, you need to enter the following commands:
zmprov mcf zimbraMtaPostscreenDnsblSites 'b.barracudacentral.org = 127.0.0.2 * 7' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org = 127.0.0. [10; 11] * 8' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org = 127.0.0. [4..7] * 6' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org = 127.0.0.3 * 4' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org = 127.0.0.2 * 3'
This command allows you to add a DNS check of incoming connections to the two most popular public spam databases and rate letters depending on which database the sender address is found in. The more penalized “stars” a client gets, the more likely he is a spammer
zmprov mcf zimbraMtaPostscreenDnsblAction enforce
This command determines the action that is performed as a result of passing the DNS check. In this case, the test result is remembered, and the letter itself continues to undergo further tests.
zmprov mcf zimbraMtaPostscreenGreetAction enforce
Since in the SMTP protocol, after a direct connection, the server is the first to start communication with the client and, accordingly, Postscreen can send a greeting to the client. Due to the fact that many spam clients, without waiting for the end of the greeting, begin to send commands, they can be easily recognized. This command allows you to take into account the results of this test, but at the same time continue to perform further tests.
zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop
As part of this test, Postscreen allows you to filter out connections that do not come from email clients. Since they do not send any letters, you can safely disconnect them from the server without any fear.
zmprov mcf zimbraMtaPostscreenPipeliningAction enforce
This check is based on the fact that by default in the SMTP protocol the client can send only one command at a time and then wait for the server to respond to this command. However, many spam bots behave differently by sending a lot of commands without waiting for a response from the server. This allows you to identify spam bots almost unmistakably.
In principle, these checks for Postscreen will be more than enough to cut off the bulk of spam bots from the server and achieve a significant reduction in the load on your mail server. At the same time, living people will receive a message that their letter has not been delivered, which significantly reduces the risk of losing important messages due to Postscreen settings. In the event that this happens, you can add a trusted sender to the Postscreen whitelist. In order to create white and black lists of Postscreen, you must first create the file / opt / zimbra / conf / postfix / postscreen_wblist .
We will add a list of allowed and forbidden ip-addresses and subnets in the CIDR table format to it. For example, block the subnet 121.144.169. *, But allow the connection to a single ip-address from this subnet:
We draw your attention to the importance of the order of entries. The fact is that Postscreen will scan the file with whitelists and blacklists until the first match, and if the blocked subnet is before the allowed ip address, then the check will simply not reach the record that this ip address is added to the white list and connection the server will not happen.
After the file with white and black lists is edited and saved, you can enable the corresponding check using the following commands:
Now, Postscreen, in addition to the checks we have already set, will also access the file with white and black lists, which will allow the administrator to easily resolve issues with the inability to connect reliable senders to the server.
For all questions related to the Zextras Suite, you can contact the representative of Zextras Katerina Triandafilidi by e-mail katerina@zextras.com
Despite the free solution, Zimbra OSE is able to provide the system administrator with a ton of extremely effective tools to solve the problem of receiving unwanted emails. We already wrote about such utilities as Amavis, SpamAssassin, ClamAV and cbpolicyd, which allow you to reliably filter incoming mail by filtering out spam mails, as well as infected and phishing emails. Nevertheless, their key drawback is that they all work with already received mail messages and spend system resources on filtering useless messages, which can always be found much better. But what if your enterprise was caught in the eye of a large botnet that constantly throws your mail server in such large quantities of junk emails that filtering them alone will take up the lion's share of MTA server capacity?
In theory, you can protect yourself from this by connecting a cloud service to filter incoming mail, but in practice this method of protection is not suitable for every enterprise, because in this case you will have to entrust third parties with processing not only spam, but also business correspondence, which is not always safe, and often directly contrary to the company's security policy. In addition, there are risks associated with the reliability of the cloud spam filter. The way out of this situation may be the organization of server protection on its own. Especially for these purposes, Zimbra had a built-in utility Postscreen, which is designed to protect the mail server from letters sent by botnets, without loading the mail server.
The essence of the work of Postscreen is that this utility scans all requests for connecting to the mail server and does not allow those clients that it seems suspicious to connect to the server. Since, according to statistics, about 90% of spam in the world is sent by botnets, Postscreen is often used as the first degree of protection for a mail server from unwanted mailings. Thanks to this, the mail server can work stably without overloads even in the face of strong spam attacks from large botnets.
The principle of operation of Postscreen is quite simple, the utility is able to carry out a number of simple checks of incoming letters before transferring them to the mail server or other services that conduct a more in-depth and detailed verification of incoming letters. Each of the checks, respectively, may be passed, but may not be passed. Based on the results of each of the checks, Postscreen can apply one of three actions at the choice of the Zimbra administrator: Drop , Ignore or Enforce . The Drop action forcibly disconnects from the client in case the verification fails, the Ignore actionallows you to ignore the results of the verification when making the final decision, but at the same time collect information and statistics about the checks, and the Enforce action allows you to take into account the results of the checks when making the final decision, but at the same time continue to perform all the tests that are planned by the system administrator.
The simple principle of operation does not mean ease of use and configuration. The fact is that a misconfigured Postscreen may become the reason why a number of messages that are important for the enterprise will not reach the addressee. That is why it is necessary to approach the setup of such a powerful tool as Postscreen with great care and constantly test it for behavior in certain situations.
Postscreen in Zimbra is included initially, but many may not be happy with the initial configuration. Now we will look at the best option for configuring Postscreen in terms of security and risk-free. Its essence is that after the failure of any of the checks, Postscreen will not disconnect from the client without talking, but will conduct all the checks to the end and if these checks fail, it will give an error message. This will notify the living sender of the non-delivery of the message if Postscreen accepts it as spam. This is achieved by setting the enforce value in the parameters of the checks. It is this value that allows you to complete the started checks to the end, without breaking the connection with the client at the first failure, but at the same time, upon completion, still block the spam email,
In order to enable the necessary checks, you need to enter the following commands:
zmprov mcf zimbraMtaPostscreenDnsblSites 'b.barracudacentral.org = 127.0.0.2 * 7' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org = 127.0.0. [10; 11] * 8' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org = 127.0.0. [4..7] * 6' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org = 127.0.0.3 * 4' zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org = 127.0.0.2 * 3'
This command allows you to add a DNS check of incoming connections to the two most popular public spam databases and rate letters depending on which database the sender address is found in. The more penalized “stars” a client gets, the more likely he is a spammer
zmprov mcf zimbraMtaPostscreenDnsblAction enforce
This command determines the action that is performed as a result of passing the DNS check. In this case, the test result is remembered, and the letter itself continues to undergo further tests.
zmprov mcf zimbraMtaPostscreenGreetAction enforce
Since in the SMTP protocol, after a direct connection, the server is the first to start communication with the client and, accordingly, Postscreen can send a greeting to the client. Due to the fact that many spam clients, without waiting for the end of the greeting, begin to send commands, they can be easily recognized. This command allows you to take into account the results of this test, but at the same time continue to perform further tests.
zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop
As part of this test, Postscreen allows you to filter out connections that do not come from email clients. Since they do not send any letters, you can safely disconnect them from the server without any fear.
zmprov mcf zimbraMtaPostscreenPipeliningAction enforce
This check is based on the fact that by default in the SMTP protocol the client can send only one command at a time and then wait for the server to respond to this command. However, many spam bots behave differently by sending a lot of commands without waiting for a response from the server. This allows you to identify spam bots almost unmistakably.
In principle, these checks for Postscreen will be more than enough to cut off the bulk of spam bots from the server and achieve a significant reduction in the load on your mail server. At the same time, living people will receive a message that their letter has not been delivered, which significantly reduces the risk of losing important messages due to Postscreen settings. In the event that this happens, you can add a trusted sender to the Postscreen whitelist. In order to create white and black lists of Postscreen, you must first create the file / opt / zimbra / conf / postfix / postscreen_wblist .
We will add a list of allowed and forbidden ip-addresses and subnets in the CIDR table format to it. For example, block the subnet 121.144.169. *, But allow the connection to a single ip-address from this subnet:
# Rules are evaluated in the order as specified.
# Blacklist 121.144.169. * Except 121.144.169.196.
121.144.169.196/32 permit
121.144.169.0/24 reject
We draw your attention to the importance of the order of entries. The fact is that Postscreen will scan the file with whitelists and blacklists until the first match, and if the blocked subnet is before the allowed ip address, then the check will simply not reach the record that this ip address is added to the white list and connection the server will not happen.
After the file with white and black lists is edited and saved, you can enable the corresponding check using the following commands:
zmprov mcf zimbraMtaPostscreenAccessList "permit_mynetworks, cidr: / opt / zimbra / conf / postfix / postscreen_wblist"
zmprov mcf zimbraMtaPostscreenBlacklistAction enforce
Now, Postscreen, in addition to the checks we have already set, will also access the file with white and black lists, which will allow the administrator to easily resolve issues with the inability to connect reliable senders to the server.
For all questions related to the Zextras Suite, you can contact the representative of Zextras Katerina Triandafilidi by e-mail katerina@zextras.com