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"