фильтрация спама в промышленных масштабах и наших измышлениях.

Приветствую!

Разрешите опубликовать в данной рассылке свой обобщенный опыт работ по построению систем фильтрации больших объемом спама.

Уже прошли те времена, когда спам рассылали студенты, купившие dialup карточку для модема, сейчас же этим занимаются на профессиональной основе люди, чьи сервера стоят в датацентрах, рассылающие спам через огромное количество хостов BOTNET'a.

В качестве небольшого отступления разрешите некоторые рассуждения о спаме и спамерах, которых я бы разделил на ~ 3 категории:

1. "Массовики-затейники" - ~ 80% спама. Рассылка идет "широким" фронтом, спам заливается "бери больше, кидай дальше". Одна из самых больших головных болей провайдеров, т.к. сильно нагружает спам-фильтры и еще сильнее почтовые backend'ы.

Легко, просто и эффективно режется.

2. "Опытные" - сложно оценить их процентном выражении, но "чем дальше в лес, тем злее партизаны": ~ 5-15%. Эти спамеры продают ограниченные "тематические" рассылки, стараются верифицировать базы получателей, прогнять перед рассылкой образцы на популярных фильтрах, слегка модифицировать спам в процессе рассылки. В общем народ успешно учится, и думается, что в обозримом будущем доставят достаточно хлопот, т.к. AFAIK, принципиально новые алгоритмы фильтрации появляются совсем не часто.

Спам от них режется относительно нормально, с достаточной степенью эффективности.

3. "Профи" - их совсем немного, но.. упорные и достают. Предположительно знают "кому и как лить", научились пробивать SMTP time фильтры, сильно "шуметь" в теле письма, эффективно модифицировать графику и показывать прочие прелести современных программных возможностей. Думается, что выходцы из ИТ среды. Спама от них немного в общей массе.

Поток он них режется непросто и не всегда успешно. Заставляют таки думать и дают идеи :-)

Сам спам предлагаю также разделить на 2 потока:

• "достоверный" - определенный с _очень_ высокой степенью достоверности,
• "вероятный" - нет _полной_ уверенности, что это именно спам.

Цена ошибки определения/не доставки письма в каждом случае разная. Для кого-то потерянное письмо - это потеря миллионного контракта, для сущий пустяк. Всем не угодить (!), и по этой причине в дальнейших рассуждених о допустимых ошибках работы системы фильрации я буду отталкиваться от уровня ошибок false positives (легитимное письмо распознается как спам) совершаемых человеком - цифре, по разным оценкам, ~0.4-1.0% . Уровень ошибок false negatives (нераспознанный спам), по мнению автора не столь критичен, если он остается в допустимых нормах, а именно 1..10 спам-писем в ящик в день.

Лирическое отступление закончено, давайте поговорим о терминах.

Промышленной системой фильтации спама предлагаю считать SMTP систему, способную обрабатывать почтовый поток в 50-100 msg/sec, фильрующую спам с относительно высоким средним показателем (> 90%) и стабильно работающую на высоких и пикующих нагрузках (1-10k SMTP сессий), расположенную на более-менее стандартном провайдерском 1U 2 Xeon сервере.

Критически важные качества такой системы:

- максимально легкий пропуск легитимного трафика, - максимально осложненный пропуск спам-трафика.

Типичной промышленной задачей предлагаю считать обработку входящего почтового потока и в соответствии с политикой фильтрации спама блокировать "достоверный" спам и производить разметку (спам-флаг в хидерах письма) "вероятного" спама, чтобы пользователь мог его верифицировать (спам-папка в почтовом клиенте). Это просто пример; политики, разумеется, могут быть любыми.

Политика приема писем почтовой системой в виде диалемы

... "принять .?. нельзя .?. не принять" ...

должна решаться в каждом случае по-разному, мнение же автора в том, что возможно не принимать достоверный спам, который составляет до 50-70% трафика в общем почтовом потоке, оставаясь при этом с допустимо низким уровнем ошибок.

Традиционно среднестатистические SMTP системы строятся по приблизительно следующей схеме:

[приём письма]-->[постановка в очередь к антиспам-фильтру & антивирусу]-->[фильтрация]-->[постановка в очередь доставки на backend]-->[доставка в ящик пользователю].

(до приема письма может существовать в очень разных формах RBL/PTR подрезка сессий)

Схема классическая, проверенная временем и инсталляциями.

Плюсы: она успешно работает.

Минусы: такая схема имеет _радикально_ низкую производительность и в случае операторского сегмента требуется закупать _весьма_ дорогое и мощное оборудование и эксплуатировать его понимая, что бОльшая часть ресурсов уходит на паразитную нагрузку в виде спам-трафика.

Насколько это минус ? Допустим мы делаем небольшую почтовую системку, а именно покупаем за 100k$ пару midrange серверов + систему хранения. По моим (разумеется, IMHO) оценкам 75k$ мы выбросим на вете..^W спам . Решать "на сколько $" это минус - вам. Разумеется оценки могут быть разными и свое мнение экспертным я тут не считаю.

Что же предлагается автором взамен ? Ничего принципиально нового в мире антиспама, но немного другая "эшелонированная система фильрации", которая оптимизированная на производительность и эффективность и построенная на следующих ключевых принципах:

1. прохождение SMTP трафика контролируется на каждом этапе. 2. блокировка/классификация спама на каждом этапе производится _минимально_ возможными ресурсами сервера.

Вся система фильтрации разбивается на уровни. Чем "глубже" уровень в иерархии, тем более ресурсоёмкие алгоритмы применяются для анализа письма. Нижнее уровни иерархии имеют обратные связи с более верхними и "обучают" их. Приложены все усилия к тому, чтобы верхние уровни работали максимально эффективно и подрезали бОльшие объемы паразитного трафика, чем нижние экономя ресурсы системы.

Рассмотрим схему прохождения одного письма.

1. Layer #0 - Dynamic firewall, блокирующий на N часов особенно проблемные (поедающие ресурсы системы) хосты BOTNET'a.
2. Layer #1 - SMTP pre-DATA time analyzer: множество проверок, которые можно выполнить после RCPT TO, а именно: helo/A/PTR/RBL/SPF check, sender verificator, transaction delay и пр. Итогом его работы является промежуточная резолюция: принять, не принять, не принять временно.

Это уровень тоже работает после SMTP DATA, но _до_ выдачи финального 250 OK и у нас уже есть все mail body.

Можно долго спорить хорош или плох baeyes. Есть множество разных мнений, но я бы предложил оставить сейчас этот спор за рамками темы.

Мы - используем. Относительно хороший и быстрый. С baeyes database per email account + подлючаемая common bayes database, если базе пользователя мало данных.

Это тяжелая по CPU проверка и до этого уровня должно доходить не более 10-20% спам-трафика, чтобы оставаться в требуемых нам рамках производительности.

5. Layer #5 - Antivirus. Btw, простой способ отрезать фишеров.

Как видите мы дошли до конца SMTP сессии, но до сих пор не сказали 250 OK. Здесь у нас, в соответствии с политикой фильтрации, есть выбор: принять, не принять (прошу не бить RFC'ой по рукам) или отправить в "карантин", который размещается на значительно более дешевом storage'e и чистится по рассписанию.

Также замечу, что мы до сих пор не нагрузили нашу систему по I/O - fsync(2) еще не сделан и сервер не загибается по I/O от 5k SMTP сессий, а вся работа по фильтрации уже выполнена.

Осталось лишь принять решение, что делать с этим письмом.

Не думаю, что открыл для подписчиков Америку, но скромно, надеюсь, что это эссе и наш опыт будет кому-нибудь интересен. Буду рад комментариям и критике.

P.S.
На подобных принципах построен наш Spamguard - http://www.naunet.ru/s/service/spamguard/ и мы будем рады сотрудничеству.

P.P.S.
Пожалуйста, не бейте за рекламу - не смог удержаться :-)

--
С уважением,
Андрей Стаценко,
Наунет СП. Получено Thu Oct 04 14:07:26 2007