ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Security-alerts
Security-Alerts mailing list archive (security-alerts@yandex-team.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-alerts] FYI: Антиспам "своими руками": плюсы и минусы



> ________________________________
> 
> 
> Антиспам "своими руками": плюсы и минусы
> 
> 
> Евгений Митрофанов, ИД Independent Media, 
> доклад на конференции "Проблема спама и ее решения" 
> 
> Необходимость защиты 
> 
> 
> Электронная почта является одним из основных способов 
> коммуникации как между сотрудниками издательского дома, так и 
> между внештатными авторами, а также для общения с читателями. 
> Специфика применения электронной почты состоит в том, что 
> адреса почтовых ящиков публикуются как в печатных, так и в 
> электронных СМИ. Для спамеров не составляет труда добавить 
> адреса в свои базы и использовать их в дальнейшем. 
> 
> Впервые проблема борьбы со спамом остро возникла четыре года 
> назад. Наша компания использовала MS Exchange в качестве MTA, 
> количество почтовых адресов было чуть больше тысячи. 
> Фильтрация входящих писем отсутствовала полностью. Более 
> того, одним из побочных эффектов использования MS Exchange 
> было то, что письма на несуществующие адреса принимались 
> сервером и потом отправлялись обратно как часть DND сообщений. 
> 
> Использование sendmail и модуля milter-sender для фильтрации спама 
> 
> 
> Первым шагом в борьбе с нежелательной почтой явилась 
> установка дополнительных релеев, через которые бы проходила 
> вся почта. В качестве ОС использовалась одна из 
> разновидностей UNIX систем с открытым кодом FreeBSD, в 
> качестве MTA - всем известный sendmail. 
> 
> Указанный MTA имеет возможность подключения дополнительных 
> фильтров через программный интерфейс milter (mail filter), 
> что и было сделано - к нему был подцеплен milter-sender. 
> Назначение фильтра вытекает из его названия. Фильтр 
> осуществляет проверку отправителя письма, в частности, 
> проверяется следующее: 
> 
> *     IP-адрес отправителя не должен принадлежать к блоку 
> зарезервированных адресов (из RFC 3330 и 3513); 
> *     IP-адрес отправителя не должен числиться в RBL; 
> *     IP-адрес отправителя должен иметь PTR запись в обратной зоне; 
> *     адрес отправителя должен иметь правильный формат; 
> *     домен отправителя должен существовать; 
> *     хотя бы один из MX серверов отправителя должен быть 
> доступен и готов принимать почту на адрес отправителя. 
> 
> Стандартная конфигурация MTA также была изменена следующим 
> образом: при приеме писем из Интернета происходила проверка 
> существования получателя в Active Directory. 
> 
> После запуска релеев в эксплуатацию объем входящего почтового 
> трафика значительно уменьшился. Количество спама сократилось, 
> но оно все еще оставалось достаточно высоким. Таким образом, 
> можно было констатировать, что подход, основанный только на 
> проверке отправителя, не эффективен против спама. 
> 
> Использование SpamAssassin для фильтрации спама 
> 
> 
> Вторым шагом стала установка системы анализа содержимого и 
> заголовков письма. После ознакомления с существующими на тот 
> момент продуктами, было принято решение использовать 
> SpamAssassin и модуль milter-spamc для взаимодействия с sendmail. 
> 
> Принцип работы SpamAssassin следующий: все письмо, включая 
> заголовки, подвергается анализу. Его цель - поиск 
> определенных признаков спама. Учитываются как "неправильные" 
> и/или "фальсифицированные" заголовки, так и присутствие 
> определенных слов, фраз и их сочетаний. Далее происходит 
> сложение весов всех признаков. Если сумма больше 
> определенного значения, которое устанавливается 
> администратором, то письмо считается спамом. 
> 
> Тестовые прогоны SpamAssassin показали, что предложенная 
> схема деления всего потока на спам и не-спам не подходит. 
> Частично это было связано с тем, что SpamAssassin не 
> рассчитан на русскоязычных пользователей, и слишком велики 
> были пропуски спам-писем даже после коррекции весов и 
> добавления компенсирующих признаков. Более того, регулярные 
> выражения для поиска ключевых слов и фраз необходимо было 
> писать дважды (первый раз для кодировки koi8-r, второй - для 
> windows-1251), что также усложняло процесс конфигурирования. 
> 
> В результате доработки весь поток стал делиться на три группы 
> (соответственно, существовало не два, а три диапазона, на 
> попадание в которые проверялась общая сумма весов признаков): 
> 
> *     хорошие письма - письмо доставлялось адресату без изменений; 
> *     подозрительные письма - письмо доставлялось адресату с 
> пометкой "СПАМ" и попадало в специальный ящик для 
> подозрительных писем, содержимое которого использовалось в 
> дальнейшем администратором почтового сервера для подстройки 
> фильтров SpamAssassin; 
> *     спам - в этом случае письмо конечному адресату не 
> доставлялось, а попадало в другой специальный ящик, доступ к 
> которому был только у администратора почтовой системы. 
> 
> В первые два месяца с начального момента запуска указанной 
> схемы средний диапазон (с подозрительными письмами) 
> постепенно сужался путем добавления новых признаков и 
> подстройки весов. В итоге, данная схема успешно работала и 
> показала высокое качество фильтрации нежелательной почты. 
> Количество ложных срабатываний и пропущенных писем также было 
> приемлемым. 
> 
> Основным недостатком описанной выше схемы являлась постоянная 
> необходимость анализа подозрительных писем с целью выделения 
> общих признаков и подбора весов. Процесс этот довольно 
> трудоемкий и не отличается оперативностью. Разбор и анализ 
> одного письма отнимал до получаса, в зависимости от уловок, 
> используемых спамерами. Если же возникали более приоритетные 
> задачи, то процесс разбора откладывался. Таким образом, в 
> начале спам-рассылок нескольким письмам обычно удавалось 
> прорываться до того, как конфигурация SpamAssassin менялась 
> соответствующим образом. Более того, некоторые нежелательные 
> письма отфильтровать оказалось невозможно. 
> 
> Greylisting как альтернативное решение защиты от спама 
> 
> 
> Протокол SMTP, который используется для передачи электронных 
> писем, имеет возможность в случае временного отказа в приеме 
> письма предпринять попытку отправить его позже. Если письмо 
> не удалось отправить в первый раз, то оно попадает в очередь 
> и хранится там, при этом сервер периодически предпринимает 
> попытки отправить его повторно. 
> 
> Спамеры обычно пытаются решить задачу рассылки писем как 
> можно большему количеству адресатов. При этом они используют 
> самодельный софт, работающий на их же машине, не утруждая 
> себя тонкостями реализации протокола SMTP и обработкой 
> нестандартных ситуаций, возникших во время SMTP-сессии. 
> Частично это связано с тем, что количество адресатов в 
> рассылке исчисляется миллионами, а соответствующими объемами 
> устройств хранения спамеры не располагают. Аналогичная 
> ситуация наблюдается и в случае, когда рассылающая спам или 
> зараженные письма машина является частью зомби-сети. 
> 
> Типичный самодельный "отправляльщик" работает по принципу 
> "соединился, выдал в канал заранее сформированную 
> последовательность SMTP-команд (зачастую не дожидаясь даже 
> приветствия сервера, - позже мы к этому вернемся) и закрыл 
> соединение". Повторных попыток отправить письмо адресату не 
> предпринимается, а очередь отсутствует за ненадобностью. 
> 
> Подход к приему писем, когда первая попытка заканчивается 
> временным отказом, получил название "greylisting" (серый 
> список). Но отказы в приеме каждого нового письма с первого 
> раза ведут к увеличению почтового трафика и вносят 
> значительные задержки в доставке писем, поэтому современные 
> реализации используют два списка: серый и белый. Если не 
> вдаваться в детали, то алгоритм работы такого 
> модифицированного серого списка можно представить следующим образом: 
> 
> *     В начале каждой новой SMTP-сессии происходит поиск 
> триплекса "IP-адрес отправителя, почтовый адрес отправителя и 
> почтовый адрес получателя" в белом списке. Если он там 
> существует, то письмо проходит без задержек. 
> *     Далее происходит поиск триплекса в сером списке. Если 
> он там найден, то письмо также проходит, а триплекс 
> переносится в белый список. 
> *     В противном случае триплекс запоминается в сером 
> списке, а удаленной стороне возвращается сообщение о 
> временной недоступности сервиса (обычно еще указывается, 
> через какое время можно предпринять повторную попытку 
> отправить письмо). 
> 
> Администратор сервера задает время жизни триплекса в сером и 
> белом списках, по истечении этого времени запись из списка 
> удаляется. Такой подход позволяет значительно сократить 
> объемы служебного почтового трафика, обусловленного работой 
> серого списка. Более того, только первое письмо доходит до 
> адресата с задержкой, остальные же доставляются сразу (в 
> случае, когда существует соответствующий триплекс в белом списке). 
> 
> В качестве программной реализации описанного выше алгоритма 
> был выбран свободно распространяемый код milter-greylist. 
> Указанное ПО является фильтром, который через 
> milter-интерфейс получает от sendmail и анализирует команды 
> SMTP-сессии. Помимо модифицированного серого списка 
> milter-greylist обладает следующими дополнительными возможностями: 
> 
> *     При наличии двух и более почтовых релеев возможно 
> настроить milter-greylist таким образом, чтобы серый и белый 
> списки синхронизировались между серверами; это позволяет 
> отслеживать как попытки обхода системы, так и осуществлять 
> корректную обработку случая, когда один из принимающих 
> почтовых серверов недоступен (например, находится на 
> техническом обслуживании). 
> *     При правильно настроенной SPF-записи у отправителя 
> возможно автоматическое занесение триплекса в белый список, 
> что позволяет свести к нулю задержки для "правильных" доменов. 
> *     Возможно ручное управление белым списком - добавление 
> определенных получателей и/или отправителей, их доменов или 
> IP-адресов в белый список, что бывает необходимо для "борьбы" 
> с неправильно настроенными почтовыми серверами, а также для 
> обработки исключений (например, адресов abuse и postmaster, 
> которые должны иметь возможность принимать всю почту). 
> 
> Одновременно с запуском серого списка конфигурация sendmail 
> была модифицирована следующим образом: введено ограничение на 
> одновременное количество SMTP-сессий с одного IP-адреса, и 
> добавлена задержка между открытием SMTP-соединения и выводом 
> приветствия сервером. Если с первым все понятно, то второе 
> требует небольших комментариев. 
> 
> В RFC 2821, раздел 4.3.1, сказано, что отправляющая сторона 
> после установления соединения должна ждать до тех пор, пока 
> сервер получателя не выдаст приветствие. Честные почтовые 
> сервера так и поступают, чего нельзя сказать о самодельном 
> программном обеспечении, предназначенном для массовых 
> рассылок или распространения вирусного кода. Как было сказано 
> выше, такие отправители не анализируют ответы принимающего 
> сервера, а, следовательно, не проверяют, было ли это 
> приглашение или нет, нарушая требования стандарта. 
> 
> Задержка приветствия позволяет отказать подобным клиентам в 
> обслуживании. В начале SMTP-соединения sendmail ждет 
> определенное время, прежде чем выдать приветствие клиенту. 
> Если в этот период времени от клиента что-то пришло, то 
> sendmail выдает предупреждение и блокирует прием письма. 
> 
> Отказ от SpamAssassin и замена его на milter-greylist 
> позволила добиться высокого уровня отсева нежелательной 
> входящей почты. При этом временные затраты на поддержку 
> системы были сведены к минимуму. Необходимость в постоянном 
> анализе и модификации конфигурации SpamAssassin при этом отсутствует. 
> 
> Результаты
> 
> 
> Подводя итоги, обратимся к цифрам. На настоящий момент 
> входящий почтовый трафик составляет порядка трех Гигабайт в 
> день. Весь этот объем распределяется между тремя тысячами 
> электронных ящиков. Результаты разбора лог-файлов почтовых 
> серверов представлены в таблице ниже (только входящая почта, 
> логи на одни сутки): 
> 
> писем, шт     писем, %%        комментарий    
> 140960        100.0   всего попыток передать почту    
> 16194         11.5    принято и доставлено    
> 61968         44.0    отказано в приеме; причина - 
> отправитель или получатель не существуют (milter-sender)      
> 25866         18.3    отказано в приеме; причина - активность 
> клиента до выдачи приглашения         
> 23399  16.6    отказано в приеме; причина - IP-адрес клиента 
> не имеет записи в обратной зоне       
> 7981  5.7     временно отказано в приеме; причина - триплекс 
> добавлен в серый список (milter-greylist)     
> 5229  3.7     SMTP-сессия прервана по тайм-ауту       
> 323   0.2     отказано в приеме; причина - письмо содержит вирус      
> 
> Как видно из таблицы, примерно одной трети входящих 
> SMTP-сессий отказывается в приеме писем в момент установления 
> соединения, а половине всех входящих сессий позже: после 
> проверок, которые требуют обращения во внешний мир. Низкий 
> процент временных отказов в приеме обусловлен тем, что 
> большинство писем отбрасывается раньше и очередь до проверок 
> milter-greylist не доходит. Этим же обусловлен низкий процент 
> писем с вирусами. 
> 
> Что касается прошедших все фильтры и доставленных в ящик 
> писем, то из них примерно 2-7% являются спамом. В последнее 
> время наметилась печальная тенденция - этот процент неуклонно 
> растет, что свидетельствует о появлении новой технологии 
> рассылки спама. 
> 
> Заключение
> 
> 
> После четырех лет эксплуатации разнообразных систем 
> фильтрации почты я могу сказать, что ни один из методов не 
> являлся абсолютным фильтром, но все они с переменным успехом 
> спасали от спама. 
> 
> В самом начале все ограничивалось использованием черных 
> списков, которые были просты в настройке, не требовали 
> обслуживания, и, что самое важное, имели высокий показатель 
> отсева нежелательных писем. Сейчас же система фильтрации 
> почты состоит из нескольких компонентов, каждый из которых 
> является независимой от других подсистемой, со всеми 
> вытекающими отсюда последствиями. Поддержка такого "зоопарка" 
> является не простым занятием, но главная проблема в другом. 
> Спамеры уже перешли на новый качественный уровень. Они 
> научились создавать письма, которые обходят все используемые 
> фильтры. Подробный разбор заголовков выявил следующие 
> закономерности: либо письма идут с существующих почтовых 
> адресов, либо для рассылки используются бесплатные почтовые 
> сервера. Поймать подобные письма возможно только в случае 
> использования систем анализа содержимого письма. Одной из 
> подобных систем является SpamAssasin, но он не подходит для 
> фильтрации русского спама, а также для спама, в котором 
> информация подается в виде рисунка. 
> 
> Спамеры постоянно совершенствуют свои программы, что-то 
> изобретая и модифицируя. Следовательно, для победы в борьбе с 
> ними необходимо постоянно совершенствовать систему 
> фильтрации, постоянно следить за технологиями, используемыми 
> как спамерами, так и для борьбы с ними. Противостоять 
> сообществу спамеров один человек уже не в состоянии. 
> 
> В чем выход? Я полагаю, что настало время применения 
> специализированных антиспам-продуктов, которые используют 
> комбинированные методы отсева нежелательной почты, дополняя 
> их уникальными технологиями анализа содержимого письма. 
> 
> ________________________________
> 
> 
> 
> (C) "Лаборатория Касперского" 
> <http://redirect.subscribe.ru/inet.safety.spamtest,26891/20061
> 221100624/n/m4696343/-/www.kaspersky.ru> , 1997 - 2005        
> 



 




Copyright © Lexa Software, 1996-2009.