Защита от непрошеной почты и перехвата учетных данных пользователя (фишинга) с помощью кода отправителя
В ответ на растущую угрозу получения непрошеных сообщений производится разработка множества технологий идентификации и фильтрации. Для обеспечения эффективности своей работы они полагаются на процедуру получения ответа на такие вопросы о каждом сообщении электронной почты, как вопрос о том, кто является его отправителем. Однако на подобный вопрос ответить непросто. Сообщения электронной почты обычно отправляются через Интернет без какой-либо проверки подлинности отправителя или компьютера, действующего от его лица. На самом деле отправить электронное сообщение под чужим именем довольно просто, а автоматического метода защиты от сообщений с целью перехвата учетных данных просто не существует.
Протокол SMTP (Simple Mail Transfer Protocol), который используется для отправки и получения электронных сообщений, никогда не был предназначен для проверки подлинности отправителя сообщения. Подобная технологическая недоработка позволяет указать любое имя и адрес в качестве данных отправителя. В результате для обеспечения соответствия фактического отправителя заявленному меры фильтрации содержимого и защиты от непрошеных сообщений не могут полагаться только на сведения, содержащиеся в заголовке сообщения.
Компенсировать эту технологическую брешь призваны, в частности, меры проверки подлинности сообщений. При использовании проверки подлинности сообщений обе системы обмены сообщениями — и отправляющая, и получающая — проверяют соответствие домена, откуда они были фактически отправлены, заявленному в них домену отправки. Это облегчает эффективную фильтрацию отправляемых в адрес организации непрошеных сообщений, при этом обеспечивая доставку законных сообщений адресатам.
В настоящий момент существуют два общедоступных для использования подхода к проверке подлинности электронных сообщений: «Sender ID Framework, SIDF» (система кода отправителя) и «DomainKeys Identified Mail, DKIM» (идентификация почты ключом домена). SIDF является решением, построенным на основе протокола Интернета и получившимся в результате объединения «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 показан пример данного процесса.
Рис. 1 Проверка записей SPF для входящих сообщений
После того, как сообщение размечено, механизм 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 в следующей последовательности:
Домен отправителя (или наиболее поздний объект, произведший отправку сообщения в поток почты, поскольку почтовые системы могут законно пересылать сообщения от имени почтовых серверов) определяется путем поиска в указанной последовательности первого определения ранее упомянутых заголовков. Если ни один из этих заголовков не найден, то механизм 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 Management Shell, как показано на рис. 3.
Рис. 2 Exchange Management Console. Управление агентом кода отправителя в Exchange Server 2007
Рис. 3 Включение кода отправителя с помощью средства Exchange Management Shell
Состояние агента (включен или выключен) указывается в диалоговом окне «Sender ID Properties» (Свойства кода отправителя). На вкладке «Action» (Действие) можно осуществить настройки, подобные тем что имеются в Exchange Server 2003 (см.рис. 4).
Рис. 4 Свойства действий агента кода отправителя в Exhange Server 2007
В отношении внедрения и функций кода отправителя между серверами 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 Management Shell. Например, для принудительной настройки агента кода сообщения на действие «Отклонить сообщение» для сообщений с кодом состояния 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 Management Shell. Например, чтобы исключить домен contoso.com из списка фильтра кода получателя, следует выполнить следующую команду:
Таким же образом, для того чтобы исключить сообщения, отправленные к указанным получателям Exchange Server из списка фильтра кода отправителя, можно использовать следующую команду:
В Exchange Server 2007 значения настроек кода отправителя, заданные с помощью командлетов "Exchange Management Shell" и недоступные в графическом интерфейсе, могут быть выведены на экран с помощью команды Get-SenderIDConfig, выполненной в средстве Exchange Management Shell, как показано на рис. 6.
Рис. 6 Командлеты настроек кода отправителя
Средство Exchange Management Shell можно использовать для того чтобы выполнить проверку IP-адреса и соответствующего имени домена вручную. Чтобы выполнить проверку состояния кода отправителя, введите следующую команду:
Если домен не существует, то на экран выводится результат, как показано на рис. 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 (на английском языке).
Авторы:
Крейг Шпицле (Craig Spiezle) в настоящее время является директором отдела Technology Strategy and Planning for Windows Live Safety в корпорации Майкрософт. Работая в качестве менеджера по продуктам проверки подлинности электронных сообщений, Крейг активно способствовал внедрению кода отправителя в данной отрасли. Начав работу в корпорации Майкрософт в 1992 году, Крейг занимал несколько управленческих должностей, включая должности в отделе международного маркетинга, отделе стратегий поддержки продуктов, отделе работы с оригинальными производителями, а также в отделе освоения новых рынков.
Александр Николаев (Alexander Nikolayev) работает менеджером программ в корпорации Майкрософт и является ответственным за протоколы серверной стороны, компонент «Transport Core» (ядро транспортировки), а также компоненты серверов Exchange Server и Windows Server для борьбы с непрошеной почтой. Александр имеет диплом магистра бизнеса, выданный университетом Мэри (University of Mary). Прочесть сообщения Александра можно в Интернет-дневнике группы Exchange по адресу: blogs.technet.com/exchange.
