Обзор основных методов борьбы со спамом
Сергей Супрунов (amsand@rambler.ru)
Думаю, ты в курсе, что такое спам. Еще полбеды, если ты просто пользователь – трафик сейчас не столь дорог (а при желании львиную долю спама можно удалять прямо на сервере), плюс трата пары-тройки минут на вычистку "мусора" не так уж и критична (да и Thunderbird через недельку обучения будет исправно сортировать его основную массу сам). Однако если твоя задача – обеспечивать работу почтового сервера, обслуживающего сотни, а то и тысячи пользователей, тогда эта статья для тебя.
Содержание:
- Что беречь – трафик или нервы?
- Чужие здесь не ходят
- Черные дыры
- Серые от злости
- Перезвони мне
- Игры больших мальчиков
- Бритвой по горлу
- Статистика знает все
- Убийца спама
- Заключение
- Боковые выносы
Что беречь – трафик или нервы?
Спам вреден по двум основным причинам – он увеличивает входящий трафик и отнимает время. С учетом этого, средства борьбы со спамом, коих придумано уйма, можно разделить на две категории – ориентированные на снижение трафика и ставящие своей первоочередной задачей снижение нагрузки на конечного получателя. И поэтому, выбирая тот или иной инструмент, прежде всего, ответь на вопрос: "А чего я, в первую очередь, хочу добиться – чтобы у бухгалтера в почтовом ящике не было мусора, или чтобы фирма платила за интернет в два раза меньше, чем сейчас?".
Начнем, пожалуй, с борцов за чистоту интернет-канала.
Одна из наиболее простых и до сих пор популярных идей – непосредственный запрет на прием почты с IP-адресов, замеченных в рассылке спама. На заре интернета эта операция выполнялась вручную. Админ, обнаружив у себя нежелательную рассылку, пытался убедить владельца соответствующей сети прекратить это безобразие (администраторы почтовых серверов для приема жалоб даже специальные ящики заводили – abuse). Если это не помогало, то IP-адрес отправителя помечался в файле access почтового сервера как REJECT.
В наши дни ручная борьба совершенно бесполезна. Но access-файл помогает только в редких случаях – когда ты точно знаешь все серверы, с которых должна приходить нужная почта, вся остальная корреспонденция отбрасывается без промедления.
Поэтому дальнейшим развитием данной идеи стали "черные" списки – когда неблагонадежные IP-адреса целенаправленно собираются специальными компаниями или сообществами пользователей и предоставляются остальным. Поскольку такие списки довольно динамичны – в них постоянно кто-то попадает, кого-то исключают и т.д., то наиболее простым способом их "распространения" явилась система DNS.
Смысл блокировки по "черным" спискам на основе DNS довольно прост – на некоем сервере (например, ) поднимается DNS-сервер, который хранит у себя не традиционные "зоны", а информацию по спамерским IP-адресам. Т.е. запросив у такого сервера поиск по специальному адресу, включающему IP отправителя, и получив положительный ответ, можно делать вывод, что адрес засвечен, как спамерский.
Многие почтовые серверы умеют работать с такими "черными" списками. Например, в Sendmail соответствующие настройки могут выглядеть следующим образом:
FEATURE(blacklist_recipients)dnl FEATURE(`dnsbl', `relays.ordb.org')dnl FEATURE(`dnsbl', `dul.ru')dnl FEATURE(`dnsbl', `bl.spamcop.net')dnl
Одним из недостатков DNSBL является их грубый подход – убивать, так все. Однако случаются ситуации, когда через сервер крупного провайдера передается как официальная почта крупного банка, так и рекламные рассылки от какого-нибудь юнца, подключенного по ADSL. Занести адрес такого сервера в "черный" список – значит лишить серьезных пользователей услуги электронной почты; не заносить – тысячи пользователей будут страдать от спама.
Второй недостаток – в условиях широкого использования "одноразовых" зомби-сетей такие списки становятся не слишком-то полезны. Поэтому эволюция двинулась дальше, и стали появляться другие методы.
Интересно, а как спамер будет реагировать на ошибки доставки? Как показывает практика, редко кто утруждает себя следованию стандартам, получив временную ошибку 4xx. А вот нормальные серверы честно перемещают письмо в очередь и повторяют попытку, спустя несколько десятков минут. На этом и основана идея использования "серых" списков – greylisting.
Одна из простейших реализаций для Sendmail – milter-greylist. Устанавливается стандартно из портов, в sendmail.mc добавляется единственная строка:
INPUT_MAIL_FILTER(`miltergreylist', `S=local:/var/milter-greylist/milter-greylist.sock, F=, T=S:4m;R:4m')dnl
Тонкую настройку (например, выставить тайм-ауты, занести некоторые серверы в "белый" список и т.д.) можно выполнить в /usr/local/etc/mail/greylist.conf.
Более функциональное средство реализации грейлистинга (работает в OpenBSD и FreeBSD) – spamd. Этот фильтр полагается в своей работе на файервол pf. Принцип действия его таков: pf заворачивает соединения, адресованные на 25-й порт, на другой, прослушиваемый демоном spamd (обычно 8025). Если адрес отправителя фигурирует в "черном" списке (на сей раз это статический файл, который нужно периодически обновлять), то для него будет выполняться стандартный SMTP-диалог, но с задержкой в 1 секунду после каждого символа, а дойдя до этапа DATA, спамер получит ошибку 550 или 450 (зависит от ключей запуска демона). Для неизвестных адресатов реализуется стандартная процедура грейлистинга, т.е. отклонение с ошибкой 451 "Сервис временно недоступен".
В FreeBSD установка spamd из дерева портов выполняется тривиально:
# cd /usr/ports/mail/spamd # make install
Настройка сводится к добавлению в правила pf трех строк:
table <spamd-white> persist no rdr inet proto tcp from <spamd-white> to any port 25 rdr pass inet proto tcp from any to any port 25 -> 100.100.100.100 port 8025
В таблицу <spamd-white> будут попадать адреса, подтвердившие свою приверженность протоколу (этим они заслужили право соединяться непосредственно с 25-м портом). Остальные будут отданы на растерзание spamd (100.100.100.100 здесь адрес, на котором работает демон, в идеале он должен быть 127.0.0.1). Кроме того, не забудь проверить, что в /etc/rc.conf обеспечивается автозапуск демона и поддержка pf:
pf_enable="YES" pf_flags="" pflog_enable="YES" pfspamd_enable="YES" pfspamd_flags="-g -G 25:4:864 -v"
Последней строкой задаем нужные параметры работы (грейлистинг, таймауты и подробный вывод). Замечу, что spamd можно использовать и исключительно в режиме "черных" списков (без ключей ′-g′ и ′-G′).
Хорош грейлистинг своей "правильностью" – он не нарушает никаких стандартов, поэтому практически исключает ложные срабатывания. И в то же время довольно существенно экономит трафик, отсеивая немало спама еще на подступах к серверу. Правда, его эффективность обратно пропорциональна эффекту, оказываемому на спамеров (как ни парадоксально это звучит), поскольку подобная защита обходится достаточно легко, если в этом возникнет необходимость.
Еще одна идея борьбы со спамом сводится к попытке, прежде чем принять сообщение, выяснить легитимность отправителя. Одна из реализаций – встречная проверка отправителя, или "обратный звонок" (callback). Суть проста – входящее сообщение задерживается на этапе DATA и предпринимается имитация отправки сообщения по адресу, указанному в строке FROM. Если удаленный сервер не выдаст ошибку после отправки ему строки RCPT TO с этим адресом, то адрес считается существующим, и прием сообщения продолжается. Если же сервер сообщит, что такого пользователя не существует, принимаемое сообщение будет отвергнуто.
Идея хороша, но чревата проблемами. Например, что будет, если на обоих серверах настроен callback? Для обхода этого используют пустое поле FROM, но тут выплывает другая неприятность – некоторые обучают свои почтовики убивать такие письма без суда и следствия. А если один сервер защищается "обратным звонком", а другой – грейлистингом? Да и дополнительным SMTP-сессиям не каждый сервер будет рад.
Из разряда "экономистов" трафика следует также отметить такие системы как SPF, майкрософтовский Sender-ID и Yahoo DomainKeys (DK). Суть их сводится к тому, что в DNS-зоне домена легальные почтовые серверы помечаются особым образом (текстовым полем или размещением публичного ключа), так что получатель может проверить, предусматривает ли администратор домена отправку почты с конкретного IP-адреса.
Однако организационные сложности пока не позволяют этим системам распространиться достаточно широко, поэтому полагаться на них не стоит (в milter-greylist есть опция nospf – если она не активирована, то отправители, прошедшие проверку по SPF, будут рассматриваться как занесенные в "белый" список. См. также sip-milter).
Со средствами, отсекающими спам на подлете, все ясно. Они здорово экономят трафик, но рубят всю почту на корню, идущую с неблагонадежных адресов (исключением является разве что грейлистинг, оставляющий отправителю второй шанс). Поэтому для компаний, для которых потеря почты критична, они не всегда подходят. К тому же, если адрес спамера еще нигде не засветился, то и блокироваться он не будет (опять-таки, кроме грейлистинга). Так что переходим к другой группе инструментов, задача которых – экономить нервы пользователей.
Одной из первых идей был сигнатурный анализ по принципу антивирусных пакетов – в базе накапливается информация о спамерских письмах; клиент, получив письмо, рассчитывает его сигнатуру и отсылает на сервер для сличения; в случае положительного ответа письмо отклоняется. Наиболее известной системой, работающей по такому принципу, является Razor.
После установки (она потянет за собой несколько Perl-модулей) анализатор можно сразу использовать. Беда только в том, что сам он с почтой ничего делать не умеет, полагаясь на таких помощников, как procmail:
# vi /etc/procmail.conf :0 Wc | razor-check :0 Waf /var/razor/carantine
Вместо помещения в карантин можно ограничиться модификацией темы/заголовков: используй для этого formail. Зарегистрировавшись в системе (выполняется командой "razor-admin -register"), ты станешь ее участником и сможешь также отсылать в базу свои образцы спама или указывать на ложные срабатывания.
Очевидно, что для расчета сигнатуры письмо нужно принять полностью (или, по крайней мере, его значительную часть), плюс ко всему, расчеты требуют вычислительных затрат. В условиях "графического" и "вариативного" спама сигнатурные анализаторы, даже несмотря на использование "нечетких сигнатур", становятся не слишком полезны. А с учетом высоких скоростей рассылки их эффективность падает еще больше.
Сколько времени у тебя уходит, чтобы понять, спам перед тобой или письмо от приятеля? Думаю, менее секунды, причем зачастую достаточно взгляда на заголовок. Значит, спам отличается от обычной почты (удивительное открытие, не так ли?). Ну и что мешает искать эти отличия автоматически? В принципе, ничего, и фильтры на основе байесового классификатора пытаются это доказать.
В их основе лежит классификация письма, путем анализа его лексического состава, используя теорему Байеса. Упрощенно это сводится к следующему предположению: если ранее 989 писем из 1000 со словом "виагра" были спамом, то следующее письмо с этим словом будет спамом с вероятностью 98,9%. Эффективность повышается за счет использования нескольких слов, их цепочек и т.д. Понятно, что для работы фильтр должен знать, какие слова ранее встречались в спаме, а какие – в нормальной почте, т.е. необходимо обучение.
Инструментов, реализующих идею лексического анализа, немало. Одним из наиболее интересных представителей является DSPAM.
Работает он между MTA и ящиками пользователей, подменяя собой агент локальной доставки (LDA). Есть возможность включить его между ящиком и пользователем (в связке с POP3-прокси), что также дает некоторые преимущества. Установка из портов сложности не вызывает (главное – осмысленно отмечать нужные опции), конфигурирование сводится к редактированию в /usr/local/etc/dspam.conf опций подключения СУБД (саму базу тоже нужно подготовить, в документации этот момент освещен достаточно подробно), выбору реального LDA и (при желании) настройке используемых алгоритмов анализа. Возможно, придется повозиться с настройкой CGI-модуля, который очень требователен к правам доступа (я для упрощения жизни обычно использую виртуальный хост в Apache с включенным suexec). В завершении – обеспечить автозапуск демона при старте системы и добавить в sendmail.mc такие строки:
define(`LOCAL_MAILER_PATH', `/usr/local/bin/dspam')dnl define(`LOCAL_MAILER_ARGS', `dspam "--deliver=innocent,spam" --user $u -d %u')dnl
Преимуществом DSPAM является удобный CGI-модуль, позволяющий выполнять значительную часть административных работ через веб-интерфейс, но самое главное – обеспечивающий подобным интерфейсом пользователей, которые смогут самостоятельно обучать свою "часть" фильтра, работать со своим карантином и т.д.
Однако помимо того, что почта будет приниматься полностью, потребуется уйма места для хранения баз, вычислительные ресурсы процессора. Но самое худшее – это необходимость постоянно следить за актуальностью данных и активно участвовать в обучении фильтра. Вряд ли бухгалтер захочет ежедневно проверять состояние своего карантина, так что данная работа, скорее всего, ляжет на плечи сисадмина.
Наиболее известный инструмент защиты от спама – SpamAssassin. Он пытается объединить под одной крышей большинство из ныне существующих методов – от "черных" списков и SPF до сигнатур и байесового анализа. Плюс ко всему, каждое сообщение прогоняется им по сотням "правил" – регулярных выражений, призванных выявить характерные признаки спама (такие как большое число цифр в адресе отправителя, нехарактерная кодировка и язык и т.д.). Собственно говоря, проверка другими методами тоже оформляется в виде правил. В случае если письмо соответствует правилу, к его "счету" добавляется определенный балл. При превышении некоторого порога письмо помечается как спам (их удалением SpamAssassin, вопреки названию, не занимается – это забота других инструментов: procmail, почтового клиента и т.д.).
Установить его можно из портов, или как обычный Perl-модуль – через CPAN. К Sendmail он подключается через milter (который инсталлируется отдельно; я обычно использую spamass-milter из коллекции портов):
INPUT_MAIL_FILTER(`spamassassin', `S=local:/var/run/spamass-milter.sock, F=, T=S:4m;R:4m')dnl
После установки следует сверить список правил (в /usr/local/share/spamassassin) со своими предпочтениями, выставить в /usr/local/etc/mail/spamassassin/local.cf осмысленное значение "порога срабатывания", подходящие баллы для тех или иных правил, включить дополнительные возможности типа байесового анализа и AWL (автоматического "белого" списка). Кроме того, если включен байесовый анализ, нужно провести обучение фильтра, скормив ему образцы "хороших" и "плохих" писем:
# sa-learn --ham goodmails # sa-learn --spam badmails
Если функцию разбирательства с отмеченной почтой не планируется взвалить на пользователей, то придется позаботиться об этом самому – либо используя procmail, либо с помощью иных дополнительных средств. В частности, в качестве универсального решения можно рассмотреть использование Amavisd-new, который, помимо подключения SpamAssassin и ряда антивирусных пакетов, способен выполнять кое-какую фильтрацию (например, по расширениям вложений) и самостоятельно.
Высокая гибкость и настраиваемость делают SpamAssassin стандартом де-факто в борьбе со спамом. Однако платить за это приходится огромными вычислительными затратами (Perl, как-никак) и повышенным вниманием к настройкам и обучению.
Как видишь, средств борьбы со спамом – целое множество. Некоторые из них довольно хороши. Другие способны превратиться в проблему, гораздо большую, чем сам спам. Но в любом случае ситуация не безнадежна. Другой вопрос, что результат будет напрямую зависеть от прилагаемых усилий – легко и быстро избавиться от спама в ближайшем будущем вряд ли удастся.
INFO
-
На сайте (ныне являющимся вотчиной Лаборатории Касперского) можно получить немало сведений о нынешних тенденциях развития спама, статистику за тот или иной период, информацию о новых приемах рассылки нежелательной почты и приемах борьбы, статьи аналитиков и т.д. Ну и море информации о спаме ты найдешь в январском "Спеце".
WWW
- – один из самых популярных «черных» списков
- – страничка программы milter-greylist
- – сайт, посвященный грейлистингу
- – сайт Razor
- – страница, посвященная spamd
- – сайт системы DSPAM
- – официальная страница SpamAssassin
Статья опубликована в апрельском номере журнала "Xakep" за 2007 год.





