GrAnd CMS Master
Joined: 21 Oct 2005 Posts: 766 Location: г. Коломна
|
Posted: 24 Apr 2013 13:21 (Wed) Post subject: Детектор массовых рассылок (почти что ТЗ) |
|
|
Вначале хотел это написать в "Предложения по дальнейшему развитию проверок". Но потом передумал. Ибо это может быть реализовано внешними подключаемыми dll (через вызов внешнего антиспама) или программами (через вызов приложения в сортировщике). Так что, просто опишу концепцию. Может быть кто-то заинтересуется:
Идея не нова. Я ее обкатывал в конце 2007 года, когда пользователям приходили сотни писем спама в сутки, встроенный антиспам не справлялся, несмотря на все изощренные правила, а внешний антиспам SO-1024 еще не существовал.
Сейчас у меня вся входящая почта предварительно фильтруется на шлюзе при помощи SO-1024 (хоть он официально и не существует, как бы), так что эту идею я забросил. Но вот в последнюю неделю поток спама настолько резко возрос. что SO-1024 уже не справляется. Хорошо, что по PTR сейчас можно львиную долю отсекать. Но все равно кое что через все четыре барьера (PTR, SO-1024, проверка числа получателей, проверки встроенным антиспамом) просачивается.
Так вот, идея заключалась в детекции массовых рассылок по некоторым критериям.
Дело в том, что у спамеров разветвленные ботнеты, включающие тысячи хостов и адресов. А рассылки ограничены. Да и фантазии и технических возможностей не хватает давать каждому письму оригинальные темы, имя отправителя и получателя. Вот и получается, что письмо с одинаковой темой может прийти с разных адресов. Или почтовые адреса отправителей будут разными, а имена одинаковыми. Или то же самое для получателей - email разные, а имена одинаковые. И всё это можно комбинировать с разными весами.
Я провел тогда эмуляцию работы такого самообучающегося детектора. Работал он отдельно по полям "From:" и "To:". По "Subject:" не стал эмулировать, как и по IP и командам "MAIL FROM:" и "RCPT TO:". Просто брал логи CMS, эмулятор просматривал их и самообучался.
Обучение только по одному полю "From:" по логам за месяц дало эффективность более 30%. Т.е. фильтр мог отсеивать около трети спама.
Обучение по полю "To:" было слабее: через 2 недели достигло максимума отсева 10-11% и далее колебались в этих пределах. Это связано с тем, что количество адресатов-получателей в домене было сильно ограничено, поэтому фильтр не мог достоверно определить массовую рассылку в разные адреса.
Объединение этих критериев, а так же учет других полей, адресов в командах и IP-адресов могло дать очень значительный эффект.
Суть метода обучения следующая (на примере анализа поля "From:"):
1. В процессе обучения и работы фильтра создается БД соответствий имен отправителей и их адресов.
Данная информация извлекается из полей "From:" писем.
2. Кортеж БД имеет следующие поля:
Field - 0 для поля "From:", 1 для "To:" и "Cc:", если оно тоже будет проверяться и т.д.;
Name - имя отправителя/получателя, извлеченное из этих полей без
лидирующих и замыкающих пробелов, приведенное к одному регистру (не обязательно).
Addr - адрес отправителя/получателя, извлеченный из этих полей (то, что в угловых скобках).
Flag - признак списка. 0 - "белый" список, 3 - "черный" список, 1 и 2 - серые списки разной степени подозрительности.
Date - дата и время последнего обновления.
3. Перед началом обучения в БД находятся только записи "белого" списка. Для них даже не нужны адреса - только имена.
4. Каждое письмо обрабатывается следующим образом:
4а. Из поля "From:" извлекаются имя и адрес. Для "To:" и "Cc:", возможно, это придется сделать несколько раз по очереди.
4б. Если имени нет, то поле пропускается - обрабатывать нечего.
4в. Если имя есть, то ищется в БД.
4г. Если имя в БД не найдено, то оно добавляется с флагом признаком списка "1" - "светло-серый" список (общий список). Так же в БД записывается адрес, если он есть.
4д. Если имя найдено, то сравниваются адреса - записанный и
свежеизвлеченный. Дальше варианты:
Адреса совпадают. Флаг признака в БД изменяется следующим образом:
0 --> 0 (не изменяется),
1 --> 1 (не изменяется),
2 --> 1 (восстанавливается),
3 --> 3 (не изменяется).
Адреса не совпадают. Новый адрес записывается в БД (обновляется). Флаг признака изменяется следующим образом:
0 --> 0 (не изменяется),
1 --> 2 (переносится в подозрительные),
2 --> 3 (переносится в "черный" список как дважды подозрительный и сразу блокируется),
3 --> 3 (не изменяется).
Ну вот в принципе и все. Только еще надо при выполнении п. 4д сначала проверить дату последнего обновления записи. Если она устарела, то считать флаг признак не 2, а 1. Значения флагов 0, 1, 3 не изменяются.
Раз все списки хранятся в одной БД, то перенести имя из "черного" списка в "белый" проще не бывает - просто заменяем флаг на "0".
Хорошо бы иметь несколько режимов работы этого фильтра:
Обучение - имена из "черного" списка не блокируются.
Контроль - перевод в "черный" список оповещается.
Фон - никаких лишних телодвижений, кроме лога. _________________ Все, что началось хорошо, закончится плохо.
Все, что началось плохо, закончится еще хуже.
Если вам кажется, что все идет хорошо, значит вы чего-то не замечаете.
Если все закончилось хорошо, то, значит, это еще не конец! |
|