Как я уже писал чуть раньше в заметке: «Эффективность решений по борьбе с нежелательными сообщениями», различные технологии борьбы с нежелательными сообщениями имеют разный коэффициент эффективности. Кроме всем известных и часто используемых: 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-адреса получателей. Если по этим данным уже можно принять решение об отказе в приёме сообщения — надо это делать на ранней стадии.

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

Читать полностью »

Honeypot (от англ. — «горшочек с медом»), в компьютерной терминологии — это приманка для злоумышленника. Задача Honeypot — подвергнуться атаке или несанкционированному исследованию, что позволит изучить стратегию злоумышленника и определить круг средств, с помощью которых могут быть нанесены удары по реальным объектам безопасности. Реализация Honeypot не принципиальна, это может быть как специальный выделенный сервер, так и один сетевой сервис, задача которого — привлечь внимание хакеров.

В применении к почте такие ловушки называют «email trap» или «spam trap». Задача таких ловушек — привлечь к себе спамера и начать получать спамерские рассылки в большом количестве. Анализируя приходящие в эти ловушки сообщения и их источники, можно адаптироваться к поведению спамеров и эффективно защищать реальные почтовые системы.

Давайте рассмотрим реальный пример построение honeypot (spamtrap) с использованием DCC (Distributed Checksum Clearinghouse).

Читать полностью »

MTA ZMailer(zmailer.org) у нас не популярен. Порывшись в русском сегменте сети, я нашёл более-менее подробный рассказ про ZMailer только в статье Игоря Ченцова: «Борьба со СПАМ-ом на примере почтового сервера zmailer».

Для больших высоконагруженных почтовых систем подходят далеко не все методы борьбы со спамом и вирусами. К сожалению, но гибкий и достаточно универсальный SpamAssassin с ядром на Perl становится узким местом, при большом потоке почты. Приходится или экстенсивным методом наращивать железо или искать другие методы решения задач.

Здесь я хочу рассказать, как организовать проверку на вирусы и некоторые типы борьбы со спамом в промышленных масштабах, с потоком почты более 5'000'000 писем в сутки.

Читать полностью »

Zmscanner — это модульный фильтр для почтовых систем Zmailer и Sendmail. Архитектура этого фильтра позволяет использовать его на высоко-нагруженных почтовых системах (>1'500'000 писем в сутки). Модульность фильтра позволяет гибко конфигурировать его функциональность, добавляя нужные вам модули и отключая не нужные.

Автор: Eugene Crosser
Домашняя страница:  http://www.average.org/zmscanner
Дополнительные модули: 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). Основная идея этой методики заключается в том, что на каждое, приходящее на почтовый сервер письмо, вычисляется контрольная сумма (checksum). Далее эта сумма передаётся на распределённый DCC-сервер хранения этих сумм. В ответ почтовый сервер получает данные о количестве уже существующих таких же сумм на DCC-сервере. Получив этот ответ, почтовый сервер может принять решение о дальнейшей судьбе этого письма: пропустить, отвергнуть или пометить как подозрительное.

Эта технология антиспама хорошо работает, когда есть общее распределённое хранилище сумм, и много клиентов, которые сообщают в этот сервер суммы своих писем. Спам обычно рассылается большим количеством одинаковых писем. И если несколько почтовых серверов сообщили о том, что какое-то письмо с такой контрольной суммой уже прошло большое количество раз, то наш сервер может попросту отвергнуть его, как массовую рассылку. При подсчёте контрольных сумм используется несколько параметров письма, но основные и чаще всего используемые это: Body, Fuz1 и Fuz2. Body — это контрольная сумма тела письма, а для подсчёта Fuz1 и Fuz2 используется fuzzy механизм, который позволяет игнорировать некоторые аспекты письма, которыми пользуются спамеры для усложнения обнаружения таких рассылок (hashbuster).

(статистика с сайта DCC )

Для общения MTA с DCC-сервером используется DCC-клиент, который получает на вход письмо от почтового сервера, высчитывает контрольные суммы, передаёт их DCC-серверу, получает от него ответ, анализирует ответ и сообщает MTA как поступить с письмом. DCC-клиент чаще всего устанавливается непосредственно на почтовый сервер, а DCC-сервер чаще всего удалённый. Давайте попробуем установить DCC и настроить его для разных типов работы.

Читать полностью »