 |
|
|
|
Sender Policy Framework как средство борьбы со спамом
Sender Policy Framework как средство борьбы со спамом Интернет разрабатывался как закрытая военная сеть, со временем сеть стала открытой, всплыли просчеты, результат которых – DOS-атаки, подделка имен DNS, черви, спам и многое другое. Все это реалии сегодняшнего Интернета. Технология Sender Policy Framework – лишь одна из попыток исправить ситуацию. Технологии борьбы со спамом в RFC Изменить действующие технологии в глобальном масштабе уже невозможно. Это потребует колоссальных затрат, как временных, так и финансовых. Поэтому все наработки появляются в виде расширений к уже действующим протоколам. Так, Sender Policy Framework (структура политики отправителя) является еще одним расширением к протоколу отправки электронной почты SMTP (Simple Mail Transfer Protocol). Протокол SMTP, заменивший в 80-х годах UUCP, не поддерживает единой схемы авторизации пользователя при отправке сообщения. В результате можно легко отправить сообщение, указав в команде MAIL FROM произвольный, в том числе и несуществующий почтовый адрес отправителя. Такое поведение нормально, ведь изначально протокол предусматривал и ситуацию, когда автор сообщения и его отправитель не одно и то же лицо. Да и понятие отправителя SMTP весьма запутанно. Под этот термин попадают заголовки From, Sender, Resent-From и даже Envelope-from (заголовок, вырабатываемый почтовыми программами). Результатом стало появление нескольких рекомендаций и дополнений к SMTP. Так, в RFC 2505 от февраля 1999 года, который так и назывался «Anti-Spam Recommendations for SMTP MTAs» дана оценка спаму как явлению, заговорили о необходимости борьбы со спамом, который в то время уже достиг высокого уровня. И дано 13 рекомендаций, выполнение которых поможет уменьшить количество спама. В частности рекомендовалось подтверждение FQDN (Fully Qualified Domain Name) отправителя сообщения, то есть проверка address -> name должна соответствовать name -> address, и обсуждены все проблемы, которые могут возникнуть при такой проверке. Все события должны регистрироваться, в SMTP-серверах должна быть заложена возможность блокировки узла, сети или конкретного отправителя. Именно отсюда берет начало закат эры open relay-серверов, так как первым пунктом рекомендации говорится о необходимости аутентификации пользователя перед отправкой сообщения. Кстати в этом же году 1 марта открытым форумом ISP (http://www.ofisp.org) был одобрен документ «Нормы пользования сетью» (Acceptable Use Policy), который регламентировал нормы работы в сети, в том числе и ограничение на информационный шум (спам) и был обязателен для всех пользователей. Следующий вполне логичный этап – появление специального расширения Simple Authentication and Security Layer (SASL), которое позволяет клиенту SMTP указать серверу механизм аутентификации, произвести обмен по выбранному протоколу аутентификации для идентификации отправителя путем нового вызова «AUTH». Все это описано в RFC 2554 «SMTP Service Extension for Authentication», вышедшем в марте 1999 года (то есть через месяц после RFC 2505). Параллельно развивались многочисленные фильтрационные методы, использующие статистический анализ содержания письма (здесь наиболее популярны решения, работающие по алгоритму, основанному на теореме Байеса), системы определения признаков массовости сообщения, а также различные варианты цветных списков: DNS Black List (DNSBL), серый и белый списки. Технология Sender Policy Framework Технология Sender Policy Framework (SPF) является открытым стандартом и определена в RFC 4408 «Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1» или SPFv1, который был опубликован в апреле 2006 года. Начало разработок датировано июнем 2003 года (хотя были и предшественники), тогда проект имел другое название – Sender Permitted From или SMTP+SPF. После распада группы MTA Authorization Records in DNS (MARID), которая занималась продвижением стандарта, название было сменено (февраль 2004 года). В июле 2005 года SPF был одобрен группой, занимающейся стандартизацией Интернета IESG (Internet Engineering Steering Group) для эксперимента IETF (Internet Engineering Task Force) и оформлен в виде рабочего проекта – draft (http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-02.html). Сама технология была разработана Менгом Уэнгом (Meng Weng), основателем компании POBOX, некоторое время вся информация по SPF размещалась на сайте http://spf.pobox.com. В настоящее время проект сменил прописку [4]. До весны 2004 года разработки велись вяло. Затем технология получила широкую известность, а крупные компании вроде Google, Altavista, AOL, Amazon, еBay, GMX, W3C и другие, как сговорившись, разом объявили о ее внедрении. Все это сопровождалось изрядной шумихой и мощной рекламной кампанией, и некоторое время создавалось впечатление, что спам будет побежден. После первой публикации появилось несколько вариантов на тему SPF, несколько отличавшихся между собой, поэтому вариант RFC 4408 принято называть Classic SPF. Суть новой технологии проста. Администратор почтового домена с помощью специальной SPF-записи в DNS-зоне перечисляет «разрешенные» адреса, с которых может отправляться почта. То есть, например, администратор домена example.org указывает, какие машины уполномочены отсылать электронную почту, адрес «MAIL FROM» у которой заканчивается на «@example.org». Сервер, получивший сообщение из этого домена, сверяет IP-адрес с SPF-записью. Если отправитель указан в списке «разрешённых» адресов, то письмо считается прошедшим проверку. Иначе, в зависимости от используемой политики сообщение отвергается или помечается как подозрение на спам. Кроме этого, RFC настоятельно рекомендует проверять и тождество поля «HELO». Проверка SPF дает некоторую вероятность того, что адрес отправителя не был подделан, которую затем можно учесть в правиле антиспамового фильтра. Конечно, спамеру ничего не стоит создать свой домен, в котором разрешить отправку сообщений с любого адреса, но это требует дополнительных капиталовложений, временных затрат и некоторой легализации. Это способно усложнить жизнь спамеру, особенно на фоне ужесточения законодательства по отношению к спаму. К тому же сегодня львиная доля спама уходит с взломанных компьютеров и с поддельными обратными адресами, а SPF как раз и нацелена на идентификацию подобной почты. После того как технология стала известной, появилось несколько публикаций как на российских, так и западных ресурсах, в которых показана низкая эффективность SPF (приблизительно от 1 до 3%). Учитывая, что интерес в настоящее время несколько поутих, сегодня часто приходится слышать мнение о том, что по причине низкой эффективности SPF в ее использовании нет смысла. Все не так просто как кажется на первый взгляд. Есть несколько моментов, о которых следует помнить. Самое главное, что SPF – это все-таки коллективная система, то есть, для наиболее эффективной ее работы необходимо, чтобы почтовые системы отправителя и получателя ее использовали. И чем больше будет таких систем, тем больше вероятность того, что сообщения спамеров, отправленные якобы из вашего домена, будут отсеяны. А на раннем этапе развития массовым распространением SPF как раз и не могла похвастаться. С другой стороны, технология SPF является как бы зеркальным отражением DNSBL. Задача последней – «очернить» отправителя сообщения. Для этого все спамерские адреса (или заподозренные в таковых действиях) заносятся в базу, если письмо отправлено с адреса, имеющегося в этой базе, оно отвергается. Проблема состоит в том, что адреса спамеров отследить нереально, а вот случаи, когда в списки блокировки попадали нормальные отправители, известны. В SPF не пытаются отследить спамеров, наоборот, ресурсы, разрешенные с точки зрения этой технологии, можно представить как некий аналог «белого» списка. Поэтому SPF можно рассматривать не как попытку «очернить» отправителя, а наоборот, указать, что отправитель легален и с точки зрения администратора домена имеет полное право отсылать электронные сообщения. Если сервер клиента взломан и с него некоторое время рассылался спам, то изъять адрес из черного списка на порядок труднее, чем «разрешить» отправлять почту с помощью SPF. Одной из проблем использования SPF является его применение при пересылке (forward) сообщений, когда в процессе пересылки один из почтовых доменов не будет указан как разрешенный. Такие случаи не редки, пересылка используется для сбора сообщений в одном почтовом ящике или для резервирования. Если весь процесс происходит внутри организации, решить эту задачу можно отключением проверки SPF на всех серверах, кроме входного, и внесением резервных почтовых серверов в SPF-списки. С «внешними» корреспондентами ситуация не так проста. Большинство предложенных сегодня решений (подмена отправителя, передача дополнительной информации о реальном отправителе и другие) предполагают модификацию ПО. Хотя ее можно решить за счет более тонкой настройки политик SPF с использованием механизма exists, то есть установить, что сообщениям, полученным напрямую, доверять больше, пересланным – меньше. Исходя из сказанного технологию SPF ни в коем случае нельзя называть универсальным средством борьбы со спамом. Только при совместном использовании с другими решениями она будет эффективна. Особенно на фоне того, что крупные игроки уже ее используют. В заголовке сообщения, пришедшего с Mail.ru на Gmail, можно найти такую строку:
Что свидетельствует об использовании SPF обоими. Анализируя спам в нескольких своих почтовых ящиках за несколько месяцев, могу сказать, что в узлах, использующих SPF, никогда не встретишь сообщения, отправленного с адресов вроде mail.ru, gmail.com и прочих, то есть тех, которые поддерживают SPF. Там, где эта технология не используется, можно встретить сообщения с любых адресов. Интерпретация результата В RFC 4408 определено несколько возможных результатов проверки легитимности адреса отправителя в процессе SMTP-запроса (в скобках указаны классификаторы, которые используются в правилах):
Публикация SPF-политики Для проверки легитимности отправителя система SPF требует три параметра: HELO, MAIL FROM и его IP-адрес. Ключевыми компонентами такой системы является наличие SPF-записи и поддержка расширения почтовым сервером. Разберем сначала, что должен сделать администратор домена, чтобы поддержать у себя SPF. Включить поддержку SPF в DNS очень просто. Запись – это простая строка в базе данных DNS, содержащая директивы. Например, в BIND и совместимых с ним по формату текстовой записи зоны серверов описание политики будет выглядеть так: example.com. IN TXT "v=spf1 +mx ip4:192.168.0.0/24 a:mail.example.com -all" то есть:
Так было в первоначальном варианте, но последующая эксплуатация показала, что использование TXT не оптимально. Поэтому был предложен новый тип записи – SPF. Политика в нем выглядит аналогично: example.com. IN SPF "v=spf1 +mx ip4:192.168.0.0/24 a:mail.example.com -all" Хотя для совместимости RFC рекомендует использовать одновременно оба этих поля. Как видно из примера, отношение владельца к определенному адресу указывается с помощью классификаторов, о которых говорилось выше. Классификатор Pass ("+") устанавливается по умолчанию, и его можно опускать при записи, хотя для наглядности его лучше все-таки использовать. Если владелец домена определил известные ему ресурсы, а права остальных четко устанавливать не хочет, то в правиле, написанном выше, можно использовать «~all» или «?all» вместо явного запрета «-all». Как раз случай создания «белого» списка с помощью SPF. Причем обратите внимание, что все указанное после all тестироваться не будет, поэтому all должно стоять в записи последним. По данным википедиа (http://en.wikipedia.org/wiki/Sender_Policy_Framework), согласно проведенным исследованиям всего около 5% доменов com и net использует SPF, да и то в виде «v=spf1 ?all». Не в этом ли секрет низкой эффективности? В RFC определено ряд механизмов (mechanism), позволяющих описать объекты, которым разрешено или запрещено отсылать почту. К основным относятся all и include. Об all сказано выше, а механизм include позволяет администратору определить несколько административно независимых областей и не описывать правила для каждой. Например, рассмотрим такое правило: example.com. IN TXT "v=spf1 +mx include: example.net include:example.org -all" Теперь если будет принято сообщение, отправленное из домена example.com, будет произведена проверка SPF-записей и в доменах example.net и example.org. Если отправка почты с этого адреса хотя бы в одном из них разрешена, письму будет присвоен статус Pass. Хотя здесь есть интересный момент, ведь показанная выше запись и записи в доменах example.net и example.org могут иметь правило -all. Как должен вести себя механизм SPF? В рекомендациях этот момент описан просто, только явное совпадение правила («if-pass») в доменах, указанных с помощью include, приведет к остановке процесса поиска и выдаче результата. Кстати, если в этих доменах не будет SPF-записи, появится ошибка PermError. Другой вид механизма, определенный в RFC как «designated sender», позволяет указать в политике диапазон адресов отправителя сообщений. Возможно несколько вариантов:
Если количество серверов невелико, то при составлении SPF записи можно воспользоваться ресурсом [5] (см. рис. 1). Делается это просто: вводите домен и нажимаете «Begin», будет проанализирован ответ DNS-сервера и предложено заполнить остальные поля. После нажатия на «Continue» будет сгенерирована запись для BIND и tinydns (djbdns), а также даны некоторые пояснения на английском.
Рисунок 1. Создание SPF-политики с помощью веб-формы
Рисунок 2. Политика, созданная с помощью веб-формы Проверить правильность SPF-записей можно одним из инструментов, описанных на странице Tools [6]. Возможны два варианта: отсылка почтового сообщения, либо указание адреса и отправителя, в специальной форме на сайте (см. рис. 3). Кроме того, в репозитарии Ubuntu нашелся пакет spfqtool (SPF Query Tool). С его помощью можно также проверить правильность SPF-записи, введя все три параметра IP-адрес (-i), почтовый адрес (-s) и узел HELO (-h):
Рисунок 3. Тестирование SPF-записи Включение поддержки SPF в Postfix На странице [7] приведен список серверов, изначально поддерживающих технологию SPF. Это Communigate Pro, Courier, Exim, Kerio MailServer и другие. Здесь же даны ссылки на расширения и патчи, позволяющие включить такую поддержку в почтовый сервер или клиент. В список последних попали такие популярные продукты, как Postfix, Qmail, Sendmail, Exchange, Lotus Domino, Thunderbird, PowerDNS и другие. Для примера разберем, как подключить SPF к Postfix. На странице [7] для Postfix доступно несколько патчей, некоторые из них потребуют перекомпиляции. Если таковое не планируется, лучше всего подойдет пакет на Perl – postfix-policyd-spf-perl. Для его работы потребуется наличие Mail::SPF и NetAddr::IP (о последнем в README почему-то ничего не сказано). Устанавливается он обычным образом: $ perl -MCPAN -e shell cpan> install Mail::SPF cpan> install NetAddr::IP cpan> q Скачиваем, распаковываем, копируем пакет на место: $ wget –c http://www.openspf.org/blobs/postfix-policyd-spf-perl-2.002.tar.gz $ tar xzvf postfix-policyd-spf-perl-2.002.tar.gz $ sudo cp postfix-policyd-spf-perl/postfix-policyd-spf-perl/uar/lib/perl/ $ perl /usr/lib/perl/policyd-spf-perl В файл /etc/postfix/master.cf добавляем следующую строку: policy unix - n n - - spawn user=nobody argv=/usr/bin/perl /usr/lib/perl/policyd-spf-perl И в файле /etc/postfix/main.cf редактируем политику smtpd_recipient_restrictions, добавив две строки: smtpd_recipient_restrictions = ... reject_unauth_destination check_policy_service unix:private/policy ... Перезапускаем Postfix: $ sudo /etc/init.d/postfix restart Этот скрипт является аналогом spfqtool, поэтому если его запустить в командной строке, можно протестировать SPF-запись (запустить вручную нужно в любом случае, чтобы убедиться в отсутствии ошибок): $ perl /usr/lib/perl/policyd-spf-perl Кроме описанных во врезках технологий были еще две: Designated Mailers Protocol (DMP), http://www.pan-am.ca/dmp) и Reverse Mail Exchanger (RMX), http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-03.txt. По принципу работы они напоминают SPF, но в последнее время о них ничего нового не слышно. Спам победить трудно, еще в RFC 2505 сказано, что только комбинация юридических и технических методов, вероятно, даст наилучший результат. С юридической точки зрения дело сдвинулось, в некоторых странах спам объявлен вне закона. Технически возможность идентифицировать пользователя с помощью SPF или подобных решений не сможет полностью уничтожить спам, но способна остановить его значительную часть. Проблема одна: сегодня только малая часть доменов использует SPF-записи, либо отнекивается правилом вроде ~all. Вывод напрашивается сам. Успехов! Приложение Sender ID Беглое знакомство с технологией SenderID (Sender ID: Authenticating E-Mail), предлагаемой компанией Microsoft, может вызвать ощущение дежа-вю. Такое впечатление, что это SPF в вольном пересказе студента-троечника. Здесь есть все то же, что и в SPF, только для идентификации источника сообщений будет использован метод Purported Responsible Address (PRA, предположительный ответственный адрес), которому посвящен целый RFC 4407 «Purported Responsible Address in E-Mail Messages». Разница между отправителем в SPF и загадочным PRA в SenderID заключается в том, что первые проверяют адрес отправителя сообщений, а вторые – запись о регистрации адреса последнего отправителя, то есть источник сообщения на последнем этапе пересылки. Если такового нет, то получается SPF=Sender ID. Краткое описание работы Sender ID на сайте Microsoft до боли напоминает SPF (а чтобы понять, что хотели сказать RFC, потребуется, как минимум, пара бутылок пива). Появление Sender ID в свое время вызвало просто невероятный шквал критики, особенно со стороны сообщества Open Source. Эксперты, входящие в рабочую группу MARID, решили, что использование в качестве стандартов технологий, которые могут оказаться запатентованными, неприемлемо. Противоречивые условия лицензирования, к тому же некоторое время не доступные для общественности, и несовместимость с классическим SPF привели к тому, что от использования в своих продуктах Sender ID сразу же отказались сообщества разработчиков Apache, Debian, SendMail, QMail, Exim и другие. В конце октября 2004 года была представлена обновленная версия Sender ID, в разработке которой участвовал Менг Уэнг. Она уже была частично совместима с SPF и поддерживала оригинальный синтаксис SPF (при записи spf2.0/mfrom,pra поддерживаются оба стандарта). Как бы то ни было, еще до принятия решения IETF новая технология уже раскручивалась вовсю, и вскоре ее поддерживали все почтовые серверы Microsoft, включая службы MSN Mail и Hotmail. Sender ID был одобрен одновременно с SPF в RFC 4406, в котором сказано, что за успехом или неудачей обеих технологий будет вестись наблюдение в течение последующих 2 лет. После чего будет принято решение об едином стандарте. Чуть позже было объявлено, что Sender ID включен в программу Microsoft Open Specification Promise (обещание открытых спецификаций), то есть обязательство не подавать в суд ни на кого, кто будет использовать данную технологию и совместимую с GPL. Хотя вывод один, в мире больших денег борьба со спамом никого не интересует. Common Access Card Весьма интересная разработка Министерства обороны США, потихоньку становящаяся на гражданские рельсы. Суть ее такова. Каждый военнослужащий и гражданский персонал этого министерства имеет «типовую карту доступа» (Common Access Card, http://www.cac.mil), построенную на основе смарт-карты со встроенным микропроцессором, в которой записаны цифровые сертификаты PKI с информацией о пользователе. Такая карта используется как удостоверение личности, для аутентификации и доступа к компьютерным сетям (Army Knowledge Online – AKO), печати и сканирования документов и в том числе для подтверждения полномочий при отправке почтовых сообщений. Каждый житель США имеет Social Security number (SSN) состоящий из 9 цифр (первые 3 указывают на регион проживания, ходят слухи, что 2 средние цифры указывают на этническую принадлежность), поэтому при желании CAC можно легко использовать для аутентификации пользователя в Интернет. Специалисты сходятся во мнении, что использование технологии вроде САС несколько усложнит незаконный доступ к ресурсам, но отнюдь не сможет ему воспрепятствовать. Кроме того, карты могут изнашиваться и ломаться, устройства считывания не работать и прочее, что скажется на доступе к ресурсам вполне легальных пользователей.
|
СЕРГЕЙ ЯРЕМЧУК, 
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
