DCC для CGP
В заметке Greylisting для CGP я давал ссылку на dcc-cgp help'ер, который реализует проверку входящих сообщений через технологию DCC. Как оказалось, сайт автора (http://sk.simtel.ru/DCC/DOC/DownLoad.html) уже некоторое время недоступен.
Потому я выложил дистрибутив у себя: http://kocmuk.ru/download/dcc-cgp. К сожалению, этот дистрибутив накатывается на новые версии DCC с ошибкой. Потому там же я выложил свой dcc-cgp.1.3.103.patch. Этот патч надо применить уже после всех патчей самого dcc-cgp.
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
Greylisting для CGP
Как я уже писал чуть раньше в заметке: «Эффективность решений по борьбе с нежелательными сообщениями», различные технологии борьбы с нежелательными сообщениями имеют разный коэффициент эффективности. Кроме всем известных и часто используемых: DNSBL, SPF и прочего, я попробовал использовать DCC (Distributed Checksum Clearinghouse). Сама по себе технология не нова и не забыта. Яндекс.Cпамооборона работает по сходному принципу: сообщение превращается в шинглы (в контрольные суммы, по терминологии DCC), шинглы (суммы) отправляется на сервер хранения и сервер возвращает ответ. На основании этого ответа можно, либо принять сообщение, либо отвергнуть как массовую рассылку. Как показали тесты, технология «Серые списки» (англ. Greylisting) так же показала себя достаточно эффективно. По моим данным, поток спама упал в 2 раза (на 50%).
Для реализации технологии Greylisting и DCC для CommuniGate (CGP) можно применить «DCC interface for CommuniGate®Pro server» от Spam-Killer.Simtel.Ru
Под linux cобирается это достаточно просто:
- берём исходный код DCC
- берём исходный код DCC-CGP (он представляет собой несколько патчей для DCC)
- патчим DCC по инструкции от DCC-CGP
- собираем DCC и получаем сам DCC клиент и сервер, и DCC-CGP helper, который подключается в CGP так же как обычный helper
С этого момента в CGP доступны серые списки и контекстный антиспам фильтр на базе DCC. Как настроить сам DCC для работы с серыми списками и реализовывать антиспам защиту, я уже описывал ранее в заметке: DCC (Distributed Checksum Clearinghouse)
Фильтрация и принятие решения о приёме или об отказе принять почтовое сообщение может происходить синхронно и асинхронно. В синхронном режиме процесс проверки происходит во время SMTP-диалога с отправляющей стороной. Асинхронная работа заключается в том, что письмо принимается в любом случае, SMTP-диалог завершается успешно, а далее происходит принятие решения о доставке или отказе в доставке сообщения в ящик пользователя.
В каждом этом методе есть плюсы и минусы. Синхронный режим заставляет отправляющую сторону оставаться подключенной к нашему серверу в течении всего периода принятия решения, что тратит наши ресурсы (память, открытые сокеты). Асинхронный режим позволяет быстро завершить SMTP-диалог, освободить ресурсы, а уже потом заняться анализом сообщения.
Минусом асинхронного режима является ситуация, когда мы принимаем решение — отказать в доставке. В таком случае сообщение об ошибке доставки (bounce message) уходит на адрес отправителя. Распространенный ход при отправке спама — это подделка адреса отправителя. В результате этого, мы отправляем ошибку о доставке на поддельный адрес, который ничего не знает про исходное сообщение. А при большом потоке таких писем на наш сервер, мы можем попросту «завалить» чей-то ящик своими ошибками о доставке.
В настоящее время серверные ресурсы достаточно не дороги, потому синхронный режим выглядит более успешным. Мы не принимаем тех сообщений, что нам не нравится. Спам остаётся у спамера. Мы не копим очереди с 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(zmailer.org) у нас не популярен. Порывшись в русском сегменте сети, я нашёл более-менее подробный рассказ про ZMailer только в статье Игоря Ченцова: «Борьба со СПАМ-ом на примере почтового сервера zmailer».
Для больших высоконагруженных почтовых систем подходят далеко не все методы борьбы со спамом и вирусами. К сожалению, но гибкий и достаточно универсальный SpamAssassin с ядром на Perl становится узким местом, при большом потоке почты. Приходится или экстенсивным методом наращивать железо или искать другие методы решения задач.
Здесь я хочу рассказать, как организовать проверку на вирусы и некоторые типы борьбы со спамом в промышленных масштабах, с потоком почты более 5'000'000 писем в сутки.
DCC (Distributed Checksum Clearinghouse)
Некоторое время назад, исследуя средства, которыми сейчас борются со спамом, я натолкнулся на DCC (Distributed Checksum Clearinghouse). Основная идея этой методики заключается в том, что на каждое, приходящее на почтовый сервер письмо, вычисляется контрольная сумма (checksum). Далее эта сумма передаётся на распределённый DCC-сервер хранения этих сумм. В ответ почтовый сервер получает данные о количестве уже существующих таких же сумм на DCC-сервере. Получив этот ответ, почтовый сервер может принять решение о дальнейшей судьбе этого письма: пропустить, отвергнуть или пометить как подозрительное.
Эта технология антиспама хорошо работает, когда есть общее распределённое хранилище сумм, и много клиентов, которые сообщают в этот сервер суммы своих писем. Спам обычно рассылается большим количеством одинаковых писем. И если несколько почтовых серверов сообщили о том, что какое-то письмо с такой контрольной суммой уже прошло большое количество раз, то наш сервер может попросту отвергнуть его, как массовую рассылку. При подсчёте контрольных сумм используется несколько параметров письма, но основные и чаще всего используемые это: Body, Fuz1 и Fuz2. Body — это контрольная сумма тела письма, а для подсчёта Fuz1 и Fuz2 используется fuzzy механизм, который позволяет игнорировать некоторые аспекты письма, которыми пользуются спамеры для усложнения обнаружения таких рассылок (hashbuster).
(статистика с сайта DCC )
Для общения MTA с DCC-сервером используется DCC-клиент, который получает на вход письмо от почтового сервера, высчитывает контрольные суммы, передаёт их DCC-серверу, получает от него ответ, анализирует ответ и сообщает MTA как поступить с письмом. DCC-клиент чаще всего устанавливается непосредственно на почтовый сервер, а DCC-сервер чаще всего удалённый. Давайте попробуем установить DCC и настроить его для разных типов работы.
