DCC для CGP
В заметке Greylisting для CGP я давал ссылку на dcc-cgp help'ер, который реализует проверку входящих сообщений через технологию DCC. Как оказалось, сайт автора () уже некоторое время недоступен.
Потому я выложил дистрибутив у себя: http://kocmuk.ru/download/dcc-cgp. К сожалению, этот дистрибутив накатывается на новые версии DCC с ошибкой. Потому там же я выложил свой dcc-cgp.1.3.103.patch. Этот патч надо применить уже после всех патчей самого dcc-cgp.
UPD 24/08/2010: сделал тарболл с модифицированной версией dcc-cgp и работающими патчами для dcc-1.3.130. Описание изменений в новом топике.
INSTALLATION
dcc-cgp requires CommuniGate Pro version 4.0 or higher (4.1 or higher preferred).
Installation of dcc-cgp takes several steps. The following step-by-step instructions should enable you to get the filter working on your system.
- The latest dcc-cgp tarball is available from Simtel.Ru.
- The latest dcc-dccd.tar.Z tarball is available from http://www.dcc-servers.net/dcc/source/.
- Extracting the source distribution will create a directory named "dcc-dccd- " where the source resides. Change current directory to it and extract dcc-cgp source distribution to this directory
- Apply patch to «configure» and «Makefiles» by execution the following command:
«patch < dcc-CGP.patch», or «gpatch < dcc-CGP.patch».
On Linux apply: «patch -l -u -t -p0 < dcc-CGP.patch». - Apply patch to «Makefile» for all non-FreeBSD systems by execution the following command:
«patch < dcc-CGP-nonFreeBSD.patch», or «gpatch < dcc-CGP-nonFreeBSD.patch».
On Linux apply: «patch -l -u -t -p0 < dcc-CGP-nonFreeBSD.patch». - Apply patch to «Makefile» for new version of DCC by execution the following command:
«patch < dcc-cgp.1.3.115.patch», or «gpatch < dcc-cgp.1.3.115.patch».
On Linux apply: «patch -l -u -t -p0 < dcc-cgp.1.3.115.patch». - And now install DCC software on your system following documentation. Also install any auxiliary programs you want to use, such as «rrdtool» for example.
- ... follow README
UPD 05/04/2009: обновил мой патч с dcc-cgp.1.3.99.patch до dcc-cgp.1.3.103.patch
UPD 26/08/2009: обновил мой патч с dcc-cgp.1.3.103.patch до dcc-cgp.1.3.115.patch
UPD 24/08/2010: сделал тарболл с модифицированной версией dcc-cgp и работающими патчами для dcc-1.3.130. Описание изменений в новом топике.
Фильтрация и принятие решения о приёме или об отказе принять почтовое сообщение может происходить синхронно и асинхронно. В синхронном режиме процесс проверки происходит во время SMTP-диалога с отправляющей стороной. Асинхронная работа заключается в том, что письмо принимается в любом случае, SMTP-диалог завершается успешно, а далее происходит принятие решения о доставке или отказе в доставке сообщения в ящик пользователя.
В каждом этом методе есть плюсы и минусы. Синхронный режим заставляет отправляющую сторону оставаться подключенной к нашему серверу в течении всего периода принятия решения, что тратит наши ресурсы (память, открытые сокеты). Асинхронный режим позволяет быстро завершить SMTP-диалог, освободить ресурсы, а уже потом заняться анализом сообщения.
Минусом асинхронного режима является ситуация, когда мы принимаем решение — отказать в доставке. В таком случае сообщение об ошибке доставки() уходит на адрес отправителя. Распространенный ход при отправке спама — это подделка адреса отправителя. В результате этого, мы отправляем ошибку о доставке на поддельный адрес, который ничего не знает про исходное сообщение. А при большом потоке таких писем на наш сервер, мы можем попросту «завалить» чей-то ящик своими ошибками о доставке.
В настоящее время серверные ресурсы достаточно не дороги, потому синхронный режим выглядит более успешным. Мы не принимаем тех сообщений, что нам не нравится. Спам остаётся у спамера. Мы не копим очереди с bounce message у себя на сервере и не заваливаем ими не виновные сервера и ящики. Все довольны!
В синхронном режиме можно выделить два этапа принятия решения: ранний этап (early rejection) и поздний (rejection). Разница между ними в том, что ранний этап происходит до начала передачи основного тела сообщения(DATA), а поздний этап происходит, когда всё письмо уже принято и отправляющая сторона ждёт от нас завершающего ответа. Отклонение сообщения на раннем этапе позволяет сэкономить трафик и ресурсы нашего сервера. Мы не приняли еще само сообщение, но у нас уже есть ip-адрес передающей стороны, email-адрес отправителя и email-адреса получателей. Если по этим данным уже можно принять решение об отказе в приёме сообщения — надо это делать на ранней стадии.
Давайте на примере суточной статистика одного почтового сервера рассмотрим эффективность разных типов борьбы с нежелательными сообщениями на разных стадиях.
DCC Honeypot — ловушка для спамеров
Honeypot (от англ. — «горшочек с медом»), в компьютерной терминологии — это приманка для злоумышленника. Задача Honeypot — подвергнуться атаке или несанкционированному исследованию, что позволит изучить стратегию злоумышленника и определить круг средств, с помощью которых могут быть нанесены удары по реальным объектам безопасности. Реализация Honeypot не принципиальна, это может быть как специальный выделенный сервер, так и один сетевой сервис, задача которого — привлечь внимание хакеров.
В применении к почте такие ловушки называют «email trap» или «spam trap». Задача таких ловушек — привлечь к себе спамера и начать получать спамерские рассылки в большом количестве. Анализируя приходящие в эти ловушки сообщения и их источники, можно адаптироваться к поведению спамеров и эффективно защищать реальные почтовые системы.
Давайте рассмотрим реальный пример построение honeypot (spamtrap) с использованием DCC (Distributed Checksum Clearinghouse).
MTA (zmailer.org) у нас не популярен. Порывшись в русском сегменте сети, я нашёл более-менее подробный рассказ про ZMailer только в статье Игоря Ченцова: .
Для больших высоконагруженных почтовых систем подходят далеко не все методы борьбы со спамом и вирусами. К сожалению, но гибкий и достаточно универсальный SpamAssassin с ядром на Perl становится узким местом, при большом потоке почты. Приходится или экстенсивным методом наращивать железо или искать другие методы решения задач.
Здесь я хочу рассказать, как организовать проверку на вирусы и некоторые типы борьбы со спамом в промышленных масштабах, с потоком почты более 5'000'000 писем в сутки.
Zmscanner — модульный фильтр для MTA Zmailer
Zmscanner — это модульный фильтр для почтовых систем Zmailer и Sendmail. Архитектура этого фильтра позволяет использовать его на высоко-нагруженных почтовых системах (>1'500'000 писем в сутки). Модульность фильтра позволяет гибко конфигурировать его функциональность, добавляя нужные вам модули и отключая не нужные.
Автор:
Домашняя страница:
Дополнительные модули: http://kocmuk.ru/zmscanner
:
Автор: Eugene Crosser
- check_ct (входит в zmscanner) — позволяет использовать регулярные выражения, для фильтрации сообщений по «Content-Type». Вы можете заблокировать HTML сообщения или сообщения с опасными вложениями (*.exe, *.pif и подобные).
- zms_dehtml (отдельный модуль) — преобразует HTML сообщение в текстовый вид, для дальнейшего анализа следующими фильтрами.
- zms_pcre (отдельный модуль) — PCRE библиотека от Philip Hazel используется для фильтрации писем по регулярным выражениям. Анализируется только текстовое тело письма. Для анализа HTML сообщений следует использовать модуль zms_dehtml для преобразования HTML в текстовый вид.
- zms_clamav (отдельный модуль) — используется библиотека антивируса ClamAV для проверки вложений на вирусы.(Замечание: сам clamd демон не используется, проверка идёт через низкоуровневые вызовы библиотеки).
Авторы: kocmuk.ru и Mike Fandorin
- zms_dcc (отдельный модуль) — адаптер Zmailer и Sendmail MTA к DCC-клиенту. Позволяет организовать проверку входящей почты через контекстный антиспам фильтр Distributed Checksum Clearinghouse (DCC). А так же возможность использовать DCC greylisting механизм для Zmailer.
- zms_restage (отдельный модуль) — PCRE библиотека используется для фильтрации писем по регулярным выражениям. Анализируются: EHLO/HELO, env_From, env_To и wholeRFC822 сообщение. Фильтр позволяет задать условия передачи сообщений для обработки в другие программы (”| exec”).
DCC (Distributed Checksum Clearinghouse)
Некоторое время назад, исследуя средства, которыми сейчас борются со спамом, я натолкнулся на DCC (Distributed Checksum Clearinghouse). Основная идея этой методики заключается в том, что на каждое, приходящее на почтовый сервер письмо, вычисляется контрольная сумма (checksum). Далее эта сумма передаётся на распределённый DCC-сервер хранения этих сумм. В ответ почтовый сервер получает данные о количестве уже существующих таких же сумм на DCC-сервере. Получив этот ответ, почтовый сервер может принять решение о дальнейшей судьбе этого письма: пропустить, отвергнуть или пометить как подозрительное.
Эта технология антиспама хорошо работает, когда есть общее распределённое хранилище сумм, и много клиентов, которые сообщают в этот сервер суммы своих писем. Спам обычно рассылается большим количеством одинаковых писем. И если несколько почтовых серверов сообщили о том, что какое-то письмо с такой контрольной суммой уже прошло большое количество раз, то наш сервер может попросту отвергнуть его, как массовую рассылку. При подсчёте контрольных сумм используется несколько параметров письма, но основные и чаще всего используемые это: Body, Fuz1 и Fuz2. Body — это контрольная сумма тела письма, а для подсчёта Fuz1 и Fuz2 используется fuzzy механизм, который позволяет игнорировать некоторые аспекты письма, которыми пользуются спамеры для усложнения обнаружения таких рассылок (hashbuster).
(статистика с сайта )
Для общения MTA с DCC-сервером используется DCC-клиент, который получает на вход письмо от почтового сервера, высчитывает контрольные суммы, передаёт их DCC-серверу, получает от него ответ, анализирует ответ и сообщает MTA как поступить с письмом. DCC-клиент чаще всего устанавливается непосредственно на почтовый сервер, а DCC-сервер чаще всего удалённый. Давайте попробуем установить DCC и настроить его для разных типов работы.
