Навигация
Системное Администрирование Решения на открытых кодах Структура сети Компьютерные сети малых предприятий Сеть с централизованным управлением Управление с помощью групповых политик Организация почтового обслуживания Взаимодействие с глобальной сетью Безопасность Виртуализация Парядок настройки и определения неисправностей Средства управления системами Автоматизация установки программного обестичения Решение проблем с компьютером Разное
 
 
Избранное
Pathping. Traceroute на стероидах.
FreeNAS: создаём сетевое хранилище (NAS)
Iperf - утилита для тестирования пропускной способности сети.
Средство против «сетевой слепоты»
Преимущества и недостатки RAID 6
Дисковые массивы RAID
Надежнее, чем RAID 5
Унификация корпоративных коммуникаций
Exchange и SAN: не все так просто
Cisco против Meru
 
 
Организация почтового обслуживания » Spam - Основные методы борьбы со спамом

Думаю, ты в курсе, что такое спам. Еще полбеды, если ты просто пользователь. Трафик сейчас не столь дорог (а при желании львиную долю спама можно удалять прямо на сервере), да и трата нескольких минут на вычистку мусора не так уж и критична (Thunderbird через недельку обучения будет исправно сортировать основную его массу сам). Однако если твоя задача - обеспечивать работу почтового сервера, обслуживающего сотни, а то и тысячи пользователей, тогда эта статья для тебя.

Что беречь - трафик или нервы?

Спам вреден по двум основным причинам - он увеличивает входящий трафик и отнимает время. С учетом этого средства борьбы со спамом, коих придумано уйма, можно разделить на две категории: ориентированные на снижение трафика и ставящие своей первоочередной задачей снижение нагрузки на конечного получателя. И поэтому, выбирая тот или иной инструмент, прежде всего спроси себя: «А чего я, собственно, хочу добиться: чтобы у бухгалтера в почтовом ящике не было мусора или чтобы фирма платила за интернет в два раза меньше, чем сейчас?»

Начнем, пожалуй, с борцов за чистоту интернет-канала.

Чужие здесь не ходят

Одна из наиболее простых и до сих пор популярных идей - непосредственный запрет на прием почты с IP-адресов, замеченных в рассылке спама. На заре интернета эта операция выполнялась вручную. Админ, обнаружив у себя нежелательную рассылку, пытался убедить владельца соответствующей сети прекратить это безобразие (администраторы почтовых серверов для приема жалоб даже специальные ящики заводили - abuse). Если это не помогало, то IP-адрес отправителя помечался в файле access почтового сервера как REJECT.
В наши дни ручная борьба совершенно бесполезна. Но access-файл тоже помогает только в редких случаях. Когда ты точно знаешь все серверы, с которых должна приходить нужная почта, вся остальная корреспонденция отбрасывается без промедления.

Поэтому дальнейшим развитием этой идеи стали черные списки - когда неблагонадежные IP-адреса целенаправленно собираются специальными компаниями или сообществами пользователей и предоставляются остальным. Поскольку такие списки довольно динамичны (в них постоянно кого-то добавляют, а кого-то исключают), то наиболее простым способом их распространения явилась система DNS.

Черные дыры

Суть блокировки по черным спискам на основе DNS довольно проста - на некоем сервере (например, spamcop.net) поднимается 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-диалог, но с задержкой в одну секунду после каждого символа, а, дойдя до этапа DATA, спамер получит ошибку 550 или 450 (зависит от ключей запуска демона). Для неизвестных адресатов реализуется стандартная процедура грейлистинга, то есть отклонение с ошибкой 451 «Сервис временно недоступен».

В FreeBSD установка spamd из дерева портов выполняется тривиально:
# cd /usr/ports/mail/spamd
# make install

Настройка сводится к добавлению в правила pf трех строк:

table persist
no rdr inet proto tcp from to any port 25
rdr pass inet proto tcp from any to any port 25 -> 100.100.100.100 port 8025

В таблицу будут попадать адреса, подтвердившие свою приверженность протоколу (этим они заслужили право соединяться непосредственно с 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, как-никак) и повышенным вниманием к настройкам и обучению.

Заключение

Как видишь, средств борьбы со спамом - великое множество. Некоторые из них довольно хороши. Другие способны превратиться в проблему, гораздо большую, чем сам спам. Но в любом случае ситуация не безнадежна. Другой вопрос, что результат будет напрямую зависеть от прилагаемых усилий. Легко и быстро избавиться от спама в ближайшем будущем вряд ли удастся.

Автор Сергей Супрунов
Опубликовано в апрельском номере журнала Хакер




 
 
 
 
Поиск по сайту
Google Поиск


Яндекс поиск
 
 
Полезное
 
 
 
 
 
systemzone.ru 2014