Защита от спама сервера Zimbra при помощи плагина Policyd

Zimbra – почтовый сервер, который использует Postfix в качестве движка для MTA. Поэтому в нем существует возможность установки плагина Policyd, который включает в себя несколько модулей.

  • Access Control – ограничение приема/пересылки писем по спискам доступа (списки могут быть различными – на основе названия домена, учетной записи пользователя, почтового адреса, ip-адреса или подсети);
  • HELO/EHLO Checks – организация белых и черных списков;
    SPF Checks – поведение сервера, если сервер-отправитель не прошел проверку SPF-записи;
  • Greylisting – организация серых списков;
  • Quotas – при помощи данного модуля можно ограничить количество принятых/отправленных сообщений в единицу времени;
  • Accounting – при помощи данного модуля можно также ограничивать количество отправленных сообщений и количество отправленных килобайт.

Установка плагина Policyd с web-интерфейсом в Zimbra

Cначала убедимся, что установлен sqlite

rpm -qa | grep sqlite

Далее нужно активировать Policyd

su zimbra
zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd

Активируем web-интерфейс Policyd, создадим символьную ссылку:

ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui

Отредактируем конфиг:

mcedit /opt/zimbra/data/httpd/htdocs/webui/includes/config.php

$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";

Перезапускаем сервисы Zimbra и Zimbra Apache:

su zimbra -c "zmcontrol restart"
su zimbra -c "zmapachectl restart"

Зайти в управление можно по адресу

http://DNSИмяПочтовогоСервера:7780/webui/index.php

По умолчанию доступ к интерфейсу ничем не ограничен. Закроем доступ с использованием htaccess. Создадим файл .htaccess:

mcedit /opt/zimbra/data/httpd/htdocs/webui/.htaccess

AuthUserFile "/opt/zimbra/data/httpd/htdocs/webui/.htpasswd"
AuthGroupFile /dev/null
AuthName "User and Password"
AuthType Basic
<LIMIT GET>
 require valid-user
</LIMIT>

Создаём файл с паролями

cd /opt/zimbra/data/httpd/htdocs/webui
/opt/zimbra/common/bin/htpasswd -cb .htpasswd ИмяПользователя ПарольПользователя

Редактируем httpd.conf

mcedit/opt/zimbra/conf/httpd.conf

#добавляем в конец файла
Alias /webui /opt/zimbra/data/httpd/htdocs/webui/
<Directory /opt/zimbra/data/httpd/htdocs/webui/>
 AllowOverride AuthConfig
 Order Deny,Allow
 Allow from all
</Directory>

Перезапукаем сервер Apache:

su zimbra -c "zmapachectl restart"

Теперь при входе на http://DNSИмяПочтовогоСервера:7780/webui/index.php будет запрос имени и пароля.

Настройка списков доступа (Access Control) в Policyd

Далее речь пойдет о запрете доступа на основании списков доступа (Access Control). По умолчанию создаются 2 группы (Policies\Groups) в которые предлагается заносить внутренние домены (internal_domains) и внутренние ip-адреса (internal_ips).

Кроме групп, создаются политики, которые применяются в порядке очереди. Политики с меньшим приоритетом применяются раньше.

Default – в данную политики попадают все;
Default Outbound – исходящая почта, применяется к письмам, источник которых внутренний (%internal_ips, %internal_domains), а назначение внешнее (!%internal_domains);
Default Inbound – входящая почта, источник не внутренний (!%internal_ips, !%internal_domains), назначение внутренние домены (%internal_domains);
Default Internal – внутренняя почта, источник и назначение – внутренние домены.

Знак процента (%) перед именем означает принадлежность к группе, восклицательный знак (!) - отрицание.

Настроим модуль Access Control. Для примера, имеем почтовый сервер mail.example.com, обслуживающий зону example.com. Требуется запретить прием писем от домена itzx.ru на все ящики домена example.com, кроме ящика vip@example.com, письма на его должны приходить без ограничений.

Создадим группы (Policies – Groups):

Группа bad_senders которая будет содержать те домены, с которых не будет пропускаться почта

Группа users_without_restrictions, письма для членов этой группы будут приходить без ограничений, даже от bad_senders

Создаем политики (Policies – Main). Политики применяются в зависимости от приоритета, сначала выполнится политика с приоритетом 10, затем 20

Политика Accept all mail for VIP для почты, которая предназначается членам группы users_without_restrictions (щелкните на политику и выберете Action – Members)

Политика Reject mail from bad_domains для почты исходящей из доменов в группе bad_senders

Обязательно нужно убедиться, что везде стоит Disabled: no (группы, политики, правила и т.д.)

При таких настройках контроля доступа, письма на ящик vip@example.com будут приходить без ограничений Policyd. На все другие ящики письма с домена itzx.ru будут отклоняться. Пользователь отправитель получит:

<test@example.com>: host mail.example.com[62.220.58.71] said: 554 5.7.1
<info@itzx.ru>: Sender address rejected: Sorry, you are bad_senders (in
reply to RCPT TO command)

На сервере получателе в логах почты будет примерно следующие:

cat /var/log/maillog | grep "Sorry"

Jan 23 14:38:02 ns4 postfix/smtpd[13266]: NOQUEUE: reject: RCPT from mail.itzx.ru[87.250.241.193]:
554 5.7.1 <info@itzx.ru>: Sender address rejected: Sorry, you are bad_senders; from=<info@itzx.ru> 
to=<test@example.com> proto=ESMTP helo=<mail.itzx.ru>

Настройка серых списков (Greylisting) в Zimbra при помощи Policyd

Серые списки (англ. Greylisting) – способ автоматической блокировки спама, основанный на том, что если почтовый сервер получателя отказывается принять письмо и сообщает о «временной ошибке», сервер отправителя обязан позже повторить попытку.

Для начала заполним группы internal_ips и internal_domains, которые создаются после установки (Policies – Groups). Добавляем локальные подсети и домены, которые обслуживает ваш почтовый сервер.

По умолчанию помимо прочих создаётся политика Default Inbound, в нее попадают письма, отправленные извне, и предназначенные для нашего сервера

Создадим правило проверки серых списков (Greylisting – Configure – Action: Add) для политики Default Inbound (параметр Link to policy)

Логика работы Greylisting заключается в том, что при первоначальной попытке доставить письмо в вашу систему, сервер-получатель обрывает соединение, а серверу отправителю выдаётся сообщение о временной недоступности вашего сервера. Данные об отправителе попадают в базу данных Policyd, такая запись называется «триплет» (triplet), данные могут заноситься на основе ip-адреса отправителя или его подсети (за это отвечает параметр Track).

Если через оговоренный промежуток времени (Greylist Period) или позднее отправитель снова попытается отправить письмо, то Policyd в случае наличия триплета, доставит данное письмо получателю, отметив триплет как успешный. Следующие сообщения от отправителя будут приниматься без задержек (при наличии успешного триплета). После того как количество удачных триплетов от отправителя станет больше определенного значения (AWL After Count) его адрес добавится в белый список, где будет храниться определенное количество секунд (AWL For Period). Аналогичная ситуация с черным списком (Auto-Blacklisting).

Включим использование Greylisting в Zimbra

su zimbra
zmprov mcf zimbraCBPolicydGreylistingEnabled TRUE

Перезапускаем плагин Policyd

su zimbra -c "zmcbpolicydctl restart"

Посмотреть результат работы Greylisting можно по логам

cat /opt/zimbra/log/cbpolicyd.log | grep "module=Greylisting"

Теперь посмотрим, что добавилось в базу данных:

Чтобы оптимизировать работу плагина следует установить параметры в соответствии с рекомендациями:

Small mailserver: 2, 2, 4, 10, 1000
 Medium mailserver: 4, 4, 12, 25, 1000
 Large mailserver: 8, 8, 16, 64, 1000

для Small mailserver:

su zimbra
zmprov mcf zimbraCBPolicydMinServers 2
zmprov mcf zimbraCBPolicydMinSpareServers 2
zmprov mcf zimbraCBPolicydMaxSpareServers 4
zmprov mcf zimbraCBPolicydMaxServers 10
zmprov mcf zimbraCBPolicydMaxRequests 1000
zmcbpolicydctl restart

Описание параметров можно найти в файле

/opt/zimbra/conf/cbpolicyd.conf.in

Периодическая очистка базы данных Policyd специальной утилитой.
Для автоматической очистки базы добавим в crontab задание

35 3 * * * /opt/zimbra/cbpolicyd/bin/cbpadmin –config=/opt/zimbra/conf/cbpolicyd.conf –cleanup >/dev/null

При большой активности сервера таблица session_tracking может сильно разрастись и ее придётся периодически чистить, например раз в день. Для этого создаем скрипт

mcedit /opt/zimbra/scripts/purge_cbpolicyd_daily.sql

delete from session_tracking where ((strftime('%s','now') - UnixTimestamp) > 86400);
vacuum;

Добавим задание в zimbra.crontab:

su - zimbra
crontab -e 

0 0 * * * cat /opt/zimbra/scripts/clean_cbpolicyd_daily.sql sqlite3 /opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb

Ограничение количества отправки сообщений в Policyd

При помощи модуля Policyd Quotas, можно настроить ограничение по количеству сообщений за определенное время, например, сделать так чтобы за 1 час пользователи могли посылать не более 100 сообщений.

Создадим политику Rate limit sending message (Policies – Main – Action: add) и добавим в свою доменную зону (Policies – Main – Action: Members)

Затем создадим для этой политики правило квоты Rate Limit 100 (Quotas – Configure – Action: add)

Будем отслеживать (Track) по типу user@domain, с периодичностью в 1 час (Period), для почты, которая отправляется во вне (Link to policy: Rate limit sending message), в случае превышения лимита письма будут отклонены (Verdict: Reject), отправителю будет выдано соответствующее сообщение (Data: Sorry, your rate limit quota has been exceeded).

Теперь необходимо создать для нового правила лимиты (Quotas – Configure – Action: Limits). Кроме количества сообщений (MessageCount) можно также устанавливать предел по количеству отправленных байт (MessageCumulativeSize) для ограничения пропускной способности.

Посмотреть результат работы ограничения по квотам можно по логам:

cat /var/log/maillog | grep "Sorry"