Белые списки для CGP
Наравне с технологией DNS blacklisting (DNSBL) существует технология DNS whitelisting (DNSWL). Это списки ip-адресов, хранимые с использованием системы архитектуры DNS. Но в отличии от «чёрных списков»(blacklist), которые хранят ip-адреса распространителей спама, «белые списки»(whitelist) хранят ip-адреса тех, кто в рассылках спама не замечен.
Основная идея «белых списков» — уменьшить количество ложных срабатываний остальных антиспам фильтров.
Мне показалось, что наиболее полную базу «белых адресов» имеет ресурс dnswl.org. Этот ресурс, помимо самого факта «чистоты» ip-адреса, хранит так же уровень этой чистоты(Trust Level).
Всего уровней четыре:
- High – никогда не рассылал спам;
- Medium – крайне редки случаи спама, быстро реагируют на проблемы;
- Low – иногда рассылают спам, активно реагируют на проблемы, но менее оперативно;
- None – легитимный почтовый сервер, но может рассылать спам.
Применение этого белого списка может быть таким:
- не применять технологию «серых списков» для всех ip-адресов с уровнями None-High;
- не применять технологию «черных списков» для всех ip-адресов с уровнями None-High;
- не проверять письма на спам (или проверять в меньшей степени) для ip-адресов с уровнями Medium-High.
Вся остальная почта с адресов, которых нет в DNSWL, пройдёт полную проверку.
Для CGP я написал dnswl-cgp.c фильтр (cgp helper), который делает запрос в DNSWL и добавляет в сообщение заголовок: «X-DNSWL-Status: <Trust Level>».
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-адреса получателей. Если по этим данным уже можно принять решение об отказе в приёме сообщения — надо это делать на ранней стадии.
Давайте на примере суточной статистика одного почтового сервера рассмотрим эффективность разных типов борьбы с нежелательными сообщениями на разных стадиях.
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 и настроить его для разных типов работы.
