Policyd как средство борьбы со спамом 0

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

Примечание: Статья была впервые опубликована в электронном издании «Open Source» (выпуск №013 от 03.11.2006). Ее размещение на nixp.ru производится в соответствии с разрешением со стороны редакции и автора материала.

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

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

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

Policy Daemon

Каждая технология имеет множество реализация от разработчиков. Не исключение и технология серых списков. Я хочу рассказать об одной из наиболее удачных реализаций — Policy Daemon (Policyd). Эта программа проще всего устанавливается вместе с популярным почтовым сервисом Postfix и, как будет видно ниже, подключается буквально за пару секунд.

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

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

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

В общем, суть технологии должна быть понятна. Как известно, большая часть спамерского софта не обрабатывает ошибку отправки и не выполняет повторную отправку. Это и сильная, и слабая одновременно сторона серых списков. Дело в том, что спам-сообщения, отправленные с систем, устанавливающих полноценные SMTP-соединения и обрабатывающих их по всем правилам, будут доставлены так же, как и легитимные сообщения. Причины для этого вполне прозрачны — Policyd не занимается анализом содержимого сообщения. Он контролирует только соединение и либо допускает его, либо обрывает. Однако, никто не мешает вторым фронтом защиты поставить Spamassassin или Dspam (что будет лучше), т.е. есть любую систему, работающую по сигнатурам сообщений (так называемым правилам Bayes).

Установка Policyd

Как уже было сказано выше, установить Policyd не составит труда даже для не самого продвинутого администратора почтовой системы. С сайта проекта всегда можно скачать исходник наиболее свежей версии системы (на данный момент, это версия 1.80). Размер архива скромен и составляет всего 63 килобайта. Пользователи системы Gentoo могут так же найти ebuild на bugs.gentoo.org (полагаю, в довольно скором времени пакет Policyd попадет в основное дерево портежей).

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

root:/usr/src/policyd-v1.80 /# make
Possible options are:
make build
  make install | install-strip
  make upgrade
  make clean

Соответственно, для установки выполняем:

# make build
# make install 

По умолчанию программа будет установлена в /usr/local/policyd. В этом каталоге разместятся 4 файла, где:

• cleanup — программа очистки устаревшей информации из базы данных;
• policyd — сам сервис Policyd;
• policyd.conf — конфигурационный файл;
• stats (в Gentoo эта команда называется policyd_stats) — программа для показа статистики работы Policyd.

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

# mysql -p < DATABASE.mysql

После чего остается только зайти в mysql и выдать права пользователю для Policyd:

mysql grant all on policyd.* to postfix@localhost identified by 'somepassword';

Теперь мы можем добавить обращение к Policyd в конфигурационный файл Postfix. Делается это в main.cf следующим образом. В строку:

smtpd_recipient_restrictions =

добавляется обращение к нашему сервису серых списков:

check_policy_service inet:127.0.0.1:10031

Разумеется, это обращение к сервису Policyd по умолчанию. Если вы хотите назначить другой адрес или порт, то здесь необходимо указать ваши параметры.

Для того, чтобы срабатывал cleanup очистки триплетов и списков, необходимо добавить в crontab следующую строку:

0 * * * * /usr/local/policyd/cleanup -c /usr/local/policyd/policyd.conf

Или же разместить аналогичный по функциональности bash-скрипт в каталоге /etc/cron.hourly. (В случае с пакетом для Gentoo, установка необходимого скрипта в /etc/cron.hourly происходит автоматически.)

После этого установку Policyd можно считать завершенной.

Настройка Policyd

Вся настройка Policyd производиться в файле /usr/local/policyd/policyd.conf. В данной статье я обращаю внимание в первую очередь на работу именно с серыми списками, но сама программа имеет несколько больше настроек и возможностей. Если информация о них будет востребована, возможно, я напишу еще одну дополнительную статью о том, как ими пользоваться наиболее эффективно. Пока же обратим внимание на самые важные параметры конфигурационного файла…

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

В первую очередь, это настройки доступа к базе данных MySQL. Переменные MYSQLHOST, MYSQLDBASE, MYSQLUSER и MYSQLPASS имеют настолько «говорящие» названия, что пояснять их смысл, я думаю, не стоит.

FAILSAFE позволяет (или не позволяет) policyd пропускать письма при отсутствии доступа к своей базе данных. Для меня этот параметр не актуален, так как если MySQL не работает, то и Postfix не будет знать куда складывать письма.

В секции DAEMON CONFIG интересны следующие опции:

• DEBUG=3 указывает, что для начала мы бы хотели видеть весьма детальную информацию по работе Policyd.
• DAEMON=0 говорит о том, что policyd будет запускаться, как приложение, а не как сервис. Впоследствии, мы изменим этот параметр на 1.
• BINDHOST и BINDPORT указывают по какому адресу и порту будут производится обращения к Policyd.
• SYSLOG_FACILITY="LOG_MAIL | LOG_INFO» говорит о том, что информация о работе сервиса будет отражаться через syslog в том же файле (во всяком случае так в большинстве систем), где и работа самой почтовой системы.
• CONN_ACL указывает, каким сетевым адресам разрешено обращение к сервису.

Далее идут секции WHITELISTING и BLACKLISTING. Переменные в них идентичны (разумеется, за исключением названия: WHITE в одном случае и BLACK — в другом):

• WHITELISTING=1 и BLACKLISTING=1 означают включение черных и белых списков соответственно.
• AUTO_WHITELIST_NUMBER=500 и AUTO_BLACKLIST_NUMBER=500 означают, что после накопления 500 удачных (неудачных) триплетов, хост будет занесен в белый (черный) список.
• AUTO_WHITELIST_EXPIRE=7d и AUTO_BLACKLIST_EXPIRE=7d указывают, что время устаревания информации в списках — 7 дней. Каждую неделю хосты будут удаляться из обоих списков. Эта переменная у некоторых вызывает сомнение. Не все считают, что отправляющая система может стать нормальной. Но для полной автоматики работы Policyd я бы рекомендовал все же оставить эти параметры включенными.
• Опция BLACKLIST_REJECTION есть только в секции описания черных списков и содержит сообщение, которое будет выдаваться системам, находящимся в списке, при попытке доставить от них сообщение.

Теперь обратим внимание на самую важную секцию, которая содержит в себе настройки непосредственно системы серых списков (GREYLISTING):

• GREYLISTING=1 говорит о том, что мы хотим использовать серые списки.
• GREYLIST_REJECTION по аналогии с BLACKLIST_REJECTION содержит строку, которая будет передаваться отправляющей системе при первоначальной отправке сообщения.
• GREYLIST_X_HEADER=1 указывает, заносить ли x-header в каждое сообщение, которое успешно прошло через серые списки.
• TRAINING_MODE=0 необходим на стадии тестирования. Я эту опцию пропустил и не использовал. Если переменная установлена в 1 (то есть включено), то Policyd работает в тестовом режиме, когда он выводит на экран (или в лог-файл) результаты своей работы, но не мешает Postfix принимать сообщения (то есть фактически не принимает участия в работе почты).
• TRIPLET_TIME указывает, через сколько минут при повторной попытке доставки сообщения (от времени первой попытки) сообщение будет принято и доставлено.
• TRIPLET_AUTH_TIMEOUT=30d означает, что информация об успешных триплетах (доставленных) будет храниться 30 дней. Этот параметр нужен для того, чтобы все успешные триплеты не хранились вечно. Например, если всего два сообщения были от кого-то доставлены и переписка с этим человеком закончилась. Таким образом, мы делаем скромный вклад в минимизацию бесполезного мусора в базе данных.
• TRIPLET_UNAUTH_TIMEOUT=2d по аналогии означает, что информация о безуспешных триплетах (не доставленных) будет храниться 2 дня.

На этом параметры, на которые я хотел бы обратить внимание, заканчиваются. Теперь можно смело запустить Policyd и Postfix и посмотреть, что будет происходить при попытке доставки сообщений в нашу систему.

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

Заключение

Честно говоря, мне неизвестно о проблемах, которые могли бы возникнуть при установке Policyd, так как ошибаться вроде бы и негде. От себя же хочу отметить, что после установки серых списков на корпоративном сервере компании нагрузка снизилась на несколько порядков. Обращений к Spamassassin стало значительно меньше (а этот софт известен своей «быстротой», достигнутой благодаря использованию Perl) и назревший было острый вопрос апгрейда сервера неожиданно отошел на дальний план. Кроме того, благодаря тому, что вирусы рассылаются так же, как и спам, система оградилась от огромного количества вирусов, которые, зачастую, не успевает распознать почтовый антивирус.

Для того, чтобы было нагляднее насколько эффективно работает Policyd, могу сказать, что если ранее за время с ночи пятницы по утро понедельника я получал более 500-600 писем спама, то теперь их количество сократилось до вполне приемлемых 15-20.

Вот вывод команды stats из моей системы, спустя несколько дней работы:

Greylisting: Triplet information
-->
Triplets: -> 42523
Verified: -> 1811
Unverified: -> 40712

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

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

cd /usr/local/policyd
./stats --c policyd.conf

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

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