Интеграция антиспама DSPAM в ZMailer
Аналогично интеграции DSPAM для CGP в режиме добавления заголовков, можно использовать эту технологию для интеграции DSPAM-a для ZMailer MTA.
Обязательным условием интеграции является модификация исходного кода dspam, для перевода его в режим добавления только заголовков. Для этого надо наложить модификацию: dspam_addheader.patch
План интеграции такой:
DSPAM для CGP v1.0.1
Обновил dspam-cgp.c до версии 1.0.1.
Добавлен традиционный для CGP заголовок вида: X-Junk-Score: 90 [XXXX]. Его удобно использовать для применения различных действий к письмам с разным уровнем «вероятности» спама. Этот заголовок автоматически используется в разделе «Упрощённые Правила по Обработке Спама». Так же это можно использовать и в своих правилах вида:
Header Field is X-Junk-Score:*[XXXX* Store in Junk Discard
Подробнее о том как использовать этот заголовок можно прочитать на сайте CGP в описании настроек для фильтра CGPSpamCatcher.
Для задания граничных точек уровня вероятности используется массив чисел:
/* Defines the bar score ranges. By default the following ratios are used:
* digital Bar score
* 0 []
* 1-49 [X]
* 50-70 [XX]
* 71-89 [XXX]
* 90-94 [XXXX]
* 95-99 [XXXXX]
* 100 [XXXXXX]
*/
int BARSCORERANGES[] = {0,49,70,89,94,99,100, -1};
Вероятность может быть от 0 до 100. Количество диапазонов может быть любым. Вероятность вычисляется исходя из результатов, которые сообщает dspam. Пока мне кажется оптимальным такое распределение вероятностей. Но вы можете сами изменить их, отредактировав BARSCORERANGES[]. Конечный «-1» всегда должен присутствовать последним элементом, он используется для определения конца массива.
О том как изменить dspam и использовать его для CGP читать в предыдущей статье: DSPAM для CGP в режиме добавления заголовков
DSPAM для CGP в режиме добавления заголовков
DSPAM — это свободное программное обеспечение, представляющее собой статистический спам фильтр.
Проект DSPAM, который некоторое время оказался заброшенным, вот уже больше полугода активно развивается dspam-сообществом. В 2007 году его бывший автор Jonathan Zdziarski передал свои права компании Sensory Networks. А в январе 2009 года компания Sensory Networks объявила, что перестаёт заниматься этим проектом и полностью передала все права dspam-сообществу.
Про настройку, обучение и работу с dspam-ом есть много статей, я хочу написать об изменениях, которыми пользуюсь я для связки dspam-а и CGP.
Белые списки для 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>».
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
Фильтрация и принятие решения о приёме или об отказе принять почтовое сообщение может происходить синхронно и асинхронно. В синхронном режиме процесс проверки происходит во время 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).
