Pull to refresh

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

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


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

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

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

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

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

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

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

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

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

Установка Policyd.
Как уже было сказано выше, установить policyd не составит труда даже для не самого продвинутого администратора почтовой системы. По адресу проекта [1] всегда можно скачать исходник наиболее свежей версии системы (на данный момент, это версия 1.80). Размер архива очень маленький и составляет всего 63 килобайта. Пользователи системы gentoo могут так же найти ebuild по адресу [2]. Полагаю, в довольно скором времени пакет 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, требуется её установка и выдача необходимых прав. Установить БД проще всего из файла-схемы, входящей в архив. Делается это простой командой:

root:/usr/src/policyd-v1.80 /# 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 работает в режиме daemon’а и делает логирование через syslog, то и вывод команды stats окажется в лог-файле.

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

[1] — policyd.sourceforge.net
[2] — bugs.gentoo.org/show_bug.cgi?id=112261

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

Articles