Меню

Policyd web administration настройка

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

В Zimbra управление серыми списками возможно через плагин Pilicyd. Как установить плагин с web-интерфейсом можно прочитать в статье Установка плагина Policyd с web-интерфейсом в Zimbra.

После установки плагина доступ к управлению можно получить по ссылке http://mail.example.org:7780/webui/index.php.

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

Создание правила Greylisting

Логика работы Greylisting заключается в том, что при первоначальной попытке доставить письмо в вашу систему, сервер-получатель обрывает соединение, а серверу отправителю выдаётся сообщение о временной недоступности вашего сервера.

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

Если через оговоренный промежуток времени (Greylist Period) или позднее отправитель снова попытается отправить письмо, то Policyd в случае наличия триплета, доставит данное письмо получателю, отметив триплет как успешный. Следующие сообщения от отправителя будут приниматься без задержек (при наличии успешного триплета).

После того как количество удачных триплетов от отправителя станет больше определенного значения (AWL After Count) его адрес добавится в белый список, где будет храниться определенное количество секунд (AWL For Period).

Аналогичная ситуация с черным списком (Auto-Blacklisting).

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

$ zmprov mcf zimbraCBPolicydGreylistingEnabled TRUE

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

Как посмотреть результат работы Policyd Greylisting

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

# cat /opt/zimbra/log/cbpolicyd.log | grep «module=Greylisting»

Как видно сначала письмо откинуто (action=defer) по причине занесения в серый список (reason=greylisted), затем спустя несколько минут уже принято (action=pass), все последующие письма от info@itzx.ru с адреса 94.58.111.82 будут приняты сразу.

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

Оптимизация работы Policyd

Параметры сервера

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

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

Например для Small mailserver:

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.

Периодическая очистка базы данных

Для автоматической очистки базы добавьте в crontab задание:

Скрипт для очистки таблицы session_tracking

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

Для этого создайте скрипт:

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также:  Настройка радио на японской магнитоле

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

Настроим модуль 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

При таких настройках контроля доступа, письма на ящик vip@example.com будут приходить без ограничений Policyd. На все другие ящики письма с домена 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

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

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

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

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

для Small mailserver:

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

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

Читайте также:  Настройка hear на басы

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

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

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

Ограничение количества отправки сообщений в 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) для ограничения пропускной способности.

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

Источник

Эффективная технология борьбы со спамом.

Едва ли кто-то ещё не знает, что такое спам и не имеет желания от него избавиться. У тех, кто при этом является «хозяином» корпоративного почтового сервера, наконец-то, появилось более менее эффективное средство от спамеров.

Речь идёт о технологии gray listing (серые списки). Если говорить упрощенно, то суть технологии заключается в проверке соответствия страндартам противоположного сервера, а так же в контроле скорости передачи писем. Почтовый сервер отправителя должен при получении 4xx ошибки попробовать отправить письмо поздже. Спаммеры же обычно игнорируют эту ошибку и пытаются отправить следующее письмо от другого отправителя и на другой адрес в почтовом домене. В результате чего все их попытки не соответвующие этому условию отбрасываются.

Желающих уяснить все тонкости технологии я отправляю к поисковым системам, которые дадут ссылки на исчерпывающую информацию, так как полное и подробное описание займёт неоправданно много места.

Policyd.
Каждая технология имеет множество реализация от разработчиков. Не исключение и технология серых списков. Я хочу рассказать об одной из наиболее удачных реализаций – policyd. Эта программа проще всего устанавливается вместе с популярным почтовым сервисом postfix и, как будет видно ниже, подключается буквально за пару секунд.

Суть работы policyd заключается в ведении списков соединений из внешнего мира с почтовым сервером. При первоначальной попытке доставить на нашу систему какое-либо письмо, соединение обрывается в самом начале, а отправляющей системе выдаётся сообщение о временной недоступности почтовой системы и предлагается попробовать доставить сообщение позднее. В тоже время, информация об отправителе попадает в базу данных MySQL. В базу записывается адрес отправителя, получателя и ip отправляющей системы. В системе Policyd такие записи называются «триплеты» (triplets).

Если через оговоренный промежуток времени (или позднее) отправитель снова попытается доставить сообщение, то policyd, проверив и убедившись в наличии информации о первом соединении, позволит Postfix принять сообщение и выполнить с ним необходимые действия по доставке письма в почтовый ящик пользователя.

Читайте также:  Как в clover configurator настройки

Все последующие похожие сообщения от этого отправителя пользователю нашей системы будут доставляться уже без задержки, а счётчик удачных доставок будет инкрементно увеличиваться. Когда количество удачных доставок (тех самых триплетов) от системы отправителя до нашей перейдёт рубеж в 500 соединений с одного домена в другой (эта величина так же может регулироваться в конфиге), ip отправляющей системы попадёт в белые списки и в дальнейшем не будет фильтроваться.

Если же повторная отрпавка сообщения не состоится, то начнёт действовать следующий сценарий. Количество несостоявшихся соединений с ip системы так же будет считаться и когда триплетов с нулевым значением станет более 500 – ip системы так же попадёт в списки. Но на этот раз в чёрные. После этого все соединения с этого адреса будут обрываться сразу, выдавая ошибку 550, что безусловно съэкономит ресурсы и трафик почтовой системы.

Думаю, вы уже поняли в чем суть технологии. Как известно, большая часть спаммерского софта не обрабатывает ошибку отправки и не выполняет повторную отправку. Это и сильная, и слабая одновременно сторона серых списков. Дело в том, что спамм сообщения отправленные с полноценных систем, устанавливающих полноценные smtp соединения и обрабатывающих их по всем правилам, будут доставлены так же, как и легитимные сообщения. Причины для этого вполне прозрачны – Policyd не занимается анализом содержимого сообщения. Он контролирует только соединение и либо допускает его, либо обрывает.

Однако, никто не мешает вторым фронтом защиты поставить spamassassin или dspam (что будет лучше). То есть любую систему, работающую по сигнатурам сообщений (bayes так называемым).

Установка Policyd.
Как уже было сказано выше, установить policyd не составит труда даже для не самого продвинутого администратора почтовой системы. По адресу проекта [1] всегда можно скачать исходник наиболее свежей версии системы (на данный момент, это версия 1.80). Размер архива очень маленький и составляет всего 63 килобайта. Пользователи системы gentoo могут так же найти ebuild по адресу [2]. Полагаю, в довольно скором времени пакет policyd попадёт в основное дерево портежей.

Сборка не требует предварительной конфигурации, а вывод команды make содержит необходимые пояснения.

Possible options are:

make build
make install | install-strip
make upgrade
make clean

для собственно установки. По-умолчанию, программа будет установлена в /usr/local/policyd. В этом каталоге будут размещены 4 файла. Где:
cleanup – программа очистки устаревшей информации из базы данных;
policyd – собственно сервис Policyd;
policyd.conf – конфигурационный файл;
stats (в gentoo эта команда называется policyd_stats) – программа для показа статистики работы Policyd.

Так как Policyd работает с базой данных MySQL, требуется её установка и выдача необходимых прав. Установить БД проще всего из файла-схемы, входящей в архив. Делается это простой командой:

Комментарии, полагаю, излишни.

К слову, stats запускается в виде:

Причем, стоит обратить внимание на то, что если у вас Policyd работает в режиме daemon’а и делает логирование через syslog, то и вывод команды stats окажется в лог-файле.

Удачного вам противостояния спаму.

(с) akeeperКоршунов Алексей.
Впервый опубликовано в электронном приложении к журналу «Системный администратор» под названием OSA.

Источник