Защита от нежелательной почты и фишинга с помощью кода отправителя

В ответ на растущую угрозу получения нежелательных сообщений производится разработка множества технологий идентификации и фильтрации. Для обеспечения эффективности своей работы они полагаются на процедуру получения ответа на такие вопросы о каждом сообщении электронной почты, как

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

Протокол SMTP, который используется для отправки и получения электронных сообщений, никогда не был предназначен для проверки подлинности отправителя сообщения. Подобная технологическая недоработка позволяет указать любое имя и адрес в качестве данных отправителя. В результате для обеспечения соответствия фактического отправителя заявленному меры фильтрации содержимого и защиты от нежелательных сообщений не могут полагаться только на сведения, содержащиеся в заголовке сообщения.

Компенсировать эту технологическую брешь призваны, в частности, меры проверки подлинности сообщений. При использовании проверки подлинности сообщений обе системы обмены сообщениями — и отправляющая, и получающая — проверяют соответствие домена, откуда они были фактически отправлены, заявленному в них домену отправки. Это облегчает эффективную фильтрацию отправляемых в адрес организации нежелательных сообщений, при этом обеспечивая доставку законных сообщений адресатам.

В настоящий момент существуют два общедоступных для использования подхода к проверке подлинности электронных сообщений: «Sender ID Framework, SIDF» (система кода отправителя) и «DomainKeys Identified Mail, DKIM» (идентификация почты ключом домена). SIDF является решением, построенным на основе протокола IP и получившимся в результате объединения «Sender Policy Framework, SPF» (система политик отправителя) и «Microsoft Caller ID for E-Mail» (идентификатор отправителя электронной почты, разработанный корпорацией Майкрософт). В апреле 2006 года IETF опубликовала спецификации кода отправителя — RFC 4405-4408. Объединение промышленных и коммерческих организаций, включая и корпорацию Майкрософт, основываясь на факторах, включающих в себя коммерческую и производственную ценность, стабильность, степень разработки, легкость развертывания, минимальное влияние на производительность обработки входящего и исходящего потоков электронных сообщений, а также способность взаимодействия с экосистемой среды электронных сообщений организаций и поставщиков услуг Интернета, рекомендует развертывание системы SIDF.

Подход DKIM является объединением спецификаций «Yahoo! DomainKeys» (доменных ключей Yahoo!) и «Identified Internet Mail, IIM» (идентификация Интернет-почты) корпорации Cisco Systems Inc. В январе 2006 года IETF одобрила создание рабочей группы по DKIM, и в настоящий момент данная спецификация находится в процессе рассмотрения в IETF.

Несмотря на отсутствие идеального решения по борьбе с нежелательными сообщениями, SIDF представляет собой весомую инициативу отрасли в целом по борьбе с фальсифицированными доменами. В результате данная организация стала ключевым компонентом в снижении объема нежелательной почты и сетевых атак с целью перехвата учетных данных (фишинга), а также увеличения степени доверия работы в сети. Организации во всем мире присоединяются к инициативе SIDF быстрыми темпами. Сегодня уже более 5,5 миллионов различных компаний и владельцев доменов опубликовали записи SPF и более чем 600 миллионов пользователей защищены системой SIDF. В настоящий момент более трети мирового ежедневного объема электронных сообщений проходит проверку подлинности и соответствует требованиям SIDF.

Развитие и всемирное использование SIDF было бы невозможным без вклада и поддержки множества организаций и компаний, включая AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign, а также многих других.

Код отправителя. Общие сведения

Некоторые из проведенных в индустрии исследований показывают, что более 95 процентов сообщений для перехвата учетных данных пользователя отправляются из фальсифицированных доменов и имеют фальсифицированного отправителя или адрес электронной почты. Это является именно той проблемой, где SIDF выделяется своим методом обработки сообщений для защиты от нежданной почты. Сама по себе система SIDF не решит проблему нежелательных сообщений, однако она вносит значительный вклад в минимизацию последствий таких сообщений и фишинг-атак. Система SIDF не предотвращает отправку нежелательных сообщений. Однако она облегчает их обнаружение. Система помогает отправителям электронных сообщений защитить свои доменные имена, репутацию и торговые марки. Она предоставляет обширную базу для принятия решений при использовании фильтров на основе репутации и образа действий отправителя при отправке электронных сообщений.

Код отправителя производит попытку удостовериться в том, каждое электронное сообщение в действительности пришло с того адреса, который заявлен в сообщении в качестве адреса отправки. Это производится с помощью проверки адреса сервера, отправляющего электронную почту, по зарегистрированному списку серверов, которым владелец домена разрешил отправлять электронную почту. Проверка производится автоматически поставщиком услуг Интернета или почтовым сервером получателя, до того как сообщение попадает в папку "Входящие" пользователя.

Обратите внимание, что ни одна из систем — ни код отправителя, ни иные механизмы проверки подлинности — не заменяют собой системы фильтрации содержимого. Механизмы SIDF и DKIM не производят сканирования действительного содержания сообщения. Вместо этого проверка извещает почтовую систему входящих сообщений о том, может ли сообщение считаться отправленным от того отправителя, который в нем заявлен. Поскольку большинство нежелательных сообщений и сообщений для перехвата учетных данных пользователя действительно отправляются не из тех доменов, которые указываются, данный подход может быть полезным для автоматического определения этих сообщений и их отделения в потоке входящей почты.

При использовании механизма SIDF запись SPF содержит простую текстовую запись всех серверов исходящей почты с указанием домена и соответствующих IP-адресов. Организация публикует запись SPF в свой файл зон DNS-сервера, который затем проверяется почтовым сервером получателя. Настроить запись SPF можно быстро, без особых усилий и бесплатно. Средство «Sender ID Framework SPF Record Wizard» (мастер записи SPF системы кода отправителя) содержит пошаговые инструкции по наблюдению за почтовыми серверами домена и созданию специальных записей, готовых к отправке. (Подробные сведения о публикации записи SPF доступны по адресу: microsoft.com/senderid (на английском языке). Программа находится по адресу microsoft.com/senderid/wizard.)

Сервер входящих сообщений SMTP запрашивает наличие записи SPF у файла зон в DNS, расположенного в домене. При наличии записи производится проверка IP-адреса отправляющего сервера по списку IP-адресов. В случае обнаружения сообщение считается прошедшим проверку подлинности. С другой стороны, в случае если сведения записи SPF о домене отправителя не совпадают с IP-адресом отправления, то сообщение считается не прошедшим проверку подлинности, что приводит к назначению ему отрицательной оценки и вероятности его перемещения в папку нежелательных сообщений. На рис. 1 показан пример данного процесса.

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

Возможности развертывания кода отправителя

Проверка подлинности исходящих сообщений с помощью SIDF не требует каких-либо изменений инфраструктуры, обновлений программного обеспечения и не зависит от ПО клиента и сервера. Однако организациям, которым необходимо внедрить проверку подлинности входящих сообщений для защиты компании и сотрудников, потребуется обновить системы входящих сообщений и средства «Агент передачи сообщений» (MTA) и осуществить развертывание программного обеспечения или устройств, которые поддерживают механизм SIDF. Большинство ведущих поставщиков ПО для борьбы с нежелательной почтой, а также поставщиков коммерческих и бесплатных MTA, включая Microsoft® Exchange Server и Exchange Hosted Filtering, предлагают интегрированные решения.

Корпорация Майкрософт внедрила SIDF во все свои продукты для обмена сообщениями, включая Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express, а также почтовый клиент с возможностью совместной работы Office Outlook.

Однако даже корпорация Майкрософт получает нежелательную почту и не является исключением среди остальных получателей нежелательных сообщений. Ежедневно корпорация Майкрософт получает примерно 15 миллионов сообщений, а в течение недавних спам-атак мы наблюдали объем сообщений от двух до четырех раз больше. В подобной среде путь к успешной защите от нежелательной почты заключается в постоянном применении и внедрении доступных технологий.

Корпорация Майкрософт использует внутреннее решение Exchange Server для защиты от нежелательной корреспонденции на основе фильтра кода получателя приложения Exchange Server 2003 и агент кода отправителя приложения Exchange Server 2007. В обеих версиях приложения Exchange Server состояние кода отправителя основано на оценке записи кода отправителя, расположенной на соответствующих серверах DNS. Действительный домен отправки определяется с помощью анализа заголовков сообщения RFC 2822 в следующей последовательности:

1. Resent-Sender
2. Resent-From
3. Sender
4. From

Домен отправителя (или наиболее поздний объект, произведший отправку сообщения в поток почты, поскольку почтовые системы могут законно пересылать сообщения от имени почтовых серверов) определяется путем поиска в указанной последовательности первого определения ранее упомянутых заголовков. Если ни один из этих заголовков не найден, то механизм SIDF использует значение SMTP RFC 2821 MAIL FROM.

Настройка кода отправителя

В Exchange Server 2007 включение агента кода отправителя возможно на тех серверах, где установлена роль «пограничный транспортный сервер». Если агент кода отправителя включен, то он будет фильтровать сообщения, поступающие через соединители приема и обрабатывать весь входящий (из внешних источников) поток сообщений, которые не прошли проверку подлинности. В Exchange Server 2003 состояние кода отправителя сохраняется в пути между серверами в метке EXCH50, в Exchange Server 2007 это состояние также добавлено к метаданным сообщения. В конечном назначении метаданные сообщения и метка преобразуются в свойство MAPI для будущего использования клиентом.

Настройки фильтрации кода отправителя в Exchange Server 2003 производится в меню "Message Delivery Properties" и состоит в назначении способа обработки приложением Exchange Server сообщений, не прошедших проверку подлинности.

Для того чтобы включить код отправителя в Exchange Server 2007 достаточно открыть панель Exchange Management Console (Панель управления Exchange) сервера, для которого установлена роль «пограничный транспортный сервер», перейти на вкладку «Anti-spam», далее перейти к пункту «Sender ID» (Код отправителя) и в панели «Actions» (Действия) нажать кнопку «Enable» (Включить) или «Disable» (Выключить) агента кода отправителя, как показано на рис. 2. Кроме того, для включения или отключения кода отправителя можно использовать среду управления Exchange, как показано на рис. 3.

Рис. 2 Exchange Management Console. Управление агентом кода отправителя в Exchange Server 2007

Состояние агента (включен или выключен) указывается в диалоговом окне «Sender ID Properties» (Свойства кода отправителя). На вкладке "Действие" содержатся параметры, подобные тем, что имеются в Exchange Server 2003 (см.рис. 4).

В отношении внедрения и функций кода отправителя между серверами Exchange Server 2003 и Exchange Server 2007 больших различий нет, фильтр кода отправителя (в Exchange Server 2003) и агент кода отправителя (в Exchange Server 2007) для извлечения и проверки используют одинаковый базовый алгоритм. Диапазон возможных действий также одинаков: «Удалить сообщение» (без извещения пользователя), «Отклонить сообщение» (ответ протокола SMTP уровня 500) и «Поставить метку с результатом проверки кода отправителя и продолжить обработку». Последнее действие является принятым по умолчанию в обеих версиях Exchange Server.

В Exchange Server 2007 оба кода состояния FAIL и TempError могут вызвать действие «Отклонить сообщение» (в Exchange Server 2003 это действие может быть вызвано только кодом состояния FAIL). Поскольку сообщения с кодом состояния TempError по умолчанию принимаются системой, отмечаются результатом проверки кода отправителя и обрабатываются, то для вызова действия «Отклонить сообщение» необходимо настроить агент кода сообщения явным образом.

Возможность такой настройки не предоставляется в графическом интерфейсе, поэтому для настройки действий для кода состояния TempError необходимо использовать среду управления Exchange. Например, для принудительной настройки агента кода сообщения на действие «Отклонить сообщение» для сообщений с кодом состояния TempError запустите следующий командлет агента кода отправителя:

Set-SenderIDConfig -TempErrorAction Reject

Диапазон результатов состояния кода отправителя и возможных действий в Exchange Server 2007 и фильтра кода отправителя в Exchange Server 2003 одинаков и показан на рис. 5.

Сервер Exchange (в случае соответствующей настройки) будет производить удаление только тех сообщений, которые не прошли проверку подлинности с помощью кода отправителя. Получение других результатов не будет приводить к удалению сообщений. Входящие сообщения, проверка которых привела к результатам Neutral, None, SoftFail, TempError или PermError, будут помечаться соответствующими метками и передаваться для дальнейшей проверки на законность. В некоторых случаях, когда сообщение безнадежно испорчено и в нем отсутствует адрес FROM IP, оно не может иметь отметку состояния кода отправителя. В подобной ситуации не производится его отклонение. Вместо этого оно передается для дальнейшей обработки без отметки состояния кода отправителя, однако для уведомления это событие заносится в журнал.

Exchange Server 2007 позволяет с легкостью определять домены отправителей и получателей Exchange Server, для которых не требуется проводить проверку кода отправителя. Данная возможность настройки также доступна только с помощью среды управления Exchange. Например, чтобы исключить домен contoso.com из списка фильтра кода получателя, следует выполнить следующую команду:

Set-SenderIDConfig -BypassedSenderDomains contoso.com

Таким же образом, чтобы отменить фильтрацию по коду отправителя для сообщений, отправленных указанным получателям Exchange Server, можно использовать следующую команду:

Set-SenderIDConfig -BypassedRecipients user@contoso.com

В Exchange Server 2007 значения настроек кода отправителя, заданные с помощью командлетов среды управления Exchange и недоступные в графическом интерфейсе, могут быть выведены на экран с помощью команды Get-SenderIDConfig, выполненной в среде управления Exchange, как показано на рис. 6.

Среду управлениям Exchange можно использовать, чтобы выполнить быструю проверку IP-адреса и соответствующего имени домена вручную. Чтобы выполнить проверку состояния кода отправителя, введите следующую команду:

Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>

Если домен не существует, то на экран выводится результат, как показано на рис. 7.

Рис. 7 Состояние проверки элемента "Адрес" кода отправителя

Преимущества использования кода отправителя

Помимо очевидных преимуществ при проверке подлинности электронных сообщений и снижения количества получаемой пользователями нежелательной почты, SIDF как протокол предлагает иные преимущества. Во время его разработки корпорация Майкрософт ориентировалась на несколько ключевых моментов, включающих в себя производительность, цену, развертывание, масштабируемость и возможность взаимодействия.

Механизм SIDF производит проверку подлинности отправителя сообщения, после чего позволяет применить оценку репутации отправителя. В результате этого достигается возможность уменьшения объема нежелательных и фальсифицированных сообщений, а также улучшается пропускная способность для законных сообщений от известных и доверенных отправителей. Создание записи SPF производится бесплатно, поэтому это легко может сделать любая организация, которая пожелает соответствовать требованиям SIDF. Организации, которые хотят соответствовать требованиям нового стандарта, должны иметь для этого соответствующие возможности. Обеспечить соответствие требованиям SIDF так же легко, как произвести публикацию записи SPF.

При разработке стандарта SIDF учитывалось требование максимальной совместимости с существующим программным обеспечением. Он может использоваться с множеством архитектур обмена электронными сообщениями, а также широким спектром клиентского и серверного программного обеспечения. Для того чтобы обеспечить эффективную работу, любая служба проверки подлинности должна удовлетворять потребностям крупного поставщика услуг Интернета так же легко, как и потребностям малого домашнего почтового сервера. SIDF может поддерживать от одного до тысяч почтовых серверов; к этому следует добавить тех, кто предоставляют свои почтовые серверы для других организаций.

С 18 по 19 апреля 2007 года корпорация Майкрософт и отраслевой консорциум из 30 организаций и партнеров проводят встречу «Authentication & Online Identity Summit» в г. Бостон, штат Массачусетс. Двухдневная программа встречи предполагает обзор практических случаев применения и обсуждение технической стороны механизма кода отправителя с подробным описанием коммерческой ценности проверки подлинности сообщений. Для получения дополнительных сведений см. веб-узел aotalliance.org/summit2007. Кроме того, для получения дополнительных сведений, включая сведения о средствах и ресурсах, см. microsoft.com/senderid и microsoft.com/exchange (на английском языке).