Как Office 365 использует инфраструктуру политики отправителей (SPF) для предотвращения спуфинга

Exchange Online
 

Последнее изменение раздела:2016-12-15

Сводка. В этой статье описано, как Office 365 использует запись TXT инфраструктуры политики отправителей (SPF) в DNS, чтобы гарантировать, что конечные почтовые системы доверяют сообщениям, отправленным из вашего личного домена. Это относится к исходящей почте, отправленной из Office 365. Сообщения, отправленные из Office 365 получателю в Office 365, всегда проходят проверку SPF.

Запись TXT инфраструктуры политики отправителей — это запись DNS, которая помогает предотвратить спуфинг и фишинг путем проверки доменного имени, с которого отправляются сообщения. Инфраструктура политики отправителей проверяет источники сообщений, сверяя IP-адрес отправителя с предполагаемым владельцем отправляющего домена.

ПримечаниеПримечание.
Рабочая группа IETF признала типы записей SPF устаревшими в 2014 г. Вместо них для публикации данных инфраструктуры политики отправителей необходимо использовать записи TXT в службе DNS. Далее в этой статье для простоты используется термин "запись SPF TXT".

Администраторы доменов публикуют данные инфраструктуры политики отправителей в записях типа TXT в DNS. Эти данные позволяют определить уполномоченные серверы исходящей почты. В свою очередь, конечные почтовые системы проверяют, были ли сообщения отправлены уполномоченными серверами исходящей почты. Если вы уже знакомы с инфраструктурой политики отправителей или работаете с простым развертыванием, и вам нужно только определить, что именно необходимо включить в запись типа TXT инфраструктуры политики отправителей в DNS для Office 365, то вы можете перейти к статье Настройка инфраструктуры политики отправителей в Office 365 для предотвращения спуфинга. Если у вас нет развертывания, целиком размещенного в Office 365, либо вас интересуют дополнительные сведения о том, как работает инфраструктура политики отправителей или как устранять связанные с ней неполадки в Office 365, читайте дальше.

Заметка о безопасностиСистема безопасности Примечание.
Раньше, если вы также использовали SharePoint Online, в личный домен нужно было добавить другую запись SPF TXT. Этого больше не требуется. Это изменение необходимо для того, чтобы уведомления SharePoint Online не попадали в папку нежелательной почты. Не нужно сразу вносить изменения, но если появится сообщение о слишком большом количестве операций поиска (too many lookups), измените запись SPF TXT, как описано в статье Настройка инфраструктуры политики отправителей в Office 365 для предотвращения спуфинга.

В этой статье

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

Каждая запись SPF TXT содержит объявления типа записи, IP-адреса, которым разрешено отправлять сообщения из домена, и внешние домены, которым разрешено отправлять сообщения от его имени, а также правило принудительного применения. В допустимой записи SPF TXT должны присутствовать все три элемента. В этой статье описано, как создать запись SPF TXT, и представлены рекомендации по работе со службами в Office 365. Кроме того, представлены ссылки на инструкции по работе с регистратором доменов для публикации записей в службе DNS.

Рассмотрим базовый синтаксис правила для инфраструктуры политики отправителей:

v=spf1 <IP-адрес> <правило принудительного применения>

Допустим, для домена contoso.com имеется следующее правило инфраструктуры политики отправителей:

v=spf1 <IP-адрес №1> <IP-адрес №2> <IP-адрес №3> <правило принудительного применения>

В этом примере правило инфраструктуры политики отправителей разрешает почтовому серверу получать сообщения только со следующих IP-адресов для домена contoso.com:

  • IP-адрес №1

  • IP-адрес №2

  • IP-адрес №3

Это правило инфраструктуры политики отправителей указывает почтовому серверу получателя, что если сообщение поступает из домена contoso.com, но не с одного из этих IP-адресов, то сервер получателя должен применять к этому сообщению правило принудительного применения. Обычно используется одно из следующих правил:

  • Серьезный сбой. В конверт сообщения добавляется отметка "серьезный сбой", а затем соблюдается политика нежелательной почты, настроенная на сервере для этого типа сообщений.

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

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

В следующих примерах показано, как инфраструктура политики отправителей работает в различных ситуациях. В этих примерах contoso.com является отправителем, а woodgrovebank.com — получателем.

Инфраструктура политики отправителей лучше всего работает с прямыми маршрутами от отправителя к получателю, например:

Схема, на которой показано, как инфраструктура политики отправителей проверяет подлинность электронной почты, отправляемой непосредственно с сервера на сервер.

Когда woodgrovebank.com получает сообщение, то оно проходит проверку инфраструктуры политики отправителей и проверку подлинности, если IP-адрес №1 указан в записи SPF TXT для contoso.com.

Допустим, злоумышленнику удалось найти уязвимость в домене contoso.com:

Схема, на которой показано, как инфраструктура политики отправителей проверяет подлинность электронной почты, отправляемой с поддельного сервера.

Так как IP-адрес №12 не указан в записи SPF TXT для домена contoso.com, сообщение не проходит проверку инфраструктуры политики отправителей, а получатель может отметить его как нежелательное.

Главный недостаток инфраструктуры политики отправителей состоит в том, что она не работает с пересылаемыми сообщениями. Допустим, пользователь домена woodgrovebank.com настроил правило пересылки, которое отправляет все сообщения в учетную запись outlook.com:

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

Изначально сообщение проходит проверку инфраструктуры политики отправителей в домене woodgrovebank.com, но не проходит ее в outlook.com, так как IP-адрес №25 не указан в записи SPF TXT для домена contoso.com. Затем outlook.com может отметить сообщение как нежелательное. Чтобы обойти эту проблему, используйте инфраструктуру политики отправителей вместе с другими методами проверки подлинности, например DKIM и DMARC.

В запись SPF TXT можно добавлять не только IP-адреса, но и домены. Для этого используются операторы include. Например, для домена contoso.com может потребоваться включить все IP-адреса почтовых серверов на доменах contoso.net и contoso.org, которые принадлежат той же организации. Для этого на домене contoso.com публикуется запись SPF TXT следующего вида:

IN TXT "v=spf1 include:contoso.net include:contoso.org -all"

Когда сервер получателя обнаруживает эту запись в службе DNS, он также ищет в записи SPF TXT домен contoso.net, а затем — contoso.org. Если сервер обнаружит в записях еще один оператор include для contoso.net или contoso.org, он выполнит и его. Во избежание атак типа "отказ в обслуживании" для одного сообщения допускается не более 10 DNS-запросов. Каждый оператор include представляет дополнительный DNS-запрос. Если в сообщении более 10 таких запросов, оно не проходит проверку инфраструктуры политики отправителей. По достижении этого предела (в зависимости от того, как настроен сервер получателя) получатель может получить сообщение о том, что сообщение вызывает слишком много запросов, или о том, что достигнуто максимальное количество прыжков для сообщения. Советы по избежанию этих ошибок см. в разделе Устранение неполадок: советы и рекомендации по инфраструктуре политики отправителей в Office 365.

Если во время настройки Office 365 была настроена почта, то уже создана запись SPF TXT, которая определяет серверы обмена сообщениями Майкрософт как доверенный источник почты для домена. Скорее всего, эта запись выглядит следующим образом:

v=spf1 include:spf.protection.outlook.com -all

Если ваша организация целиком размещена в Office 365, то есть у вас нет локальных почтовых серверов, которые отправляют исходящую почту, для Office 365 необходимо опубликовать только эту запись SPF TXT.

При гибридном развертывании (то есть когда одни ящики электронной почты размещены локально, а другие — в Office 365), а также если вы пользователь автономной службы Exchange Online Protection (иными словами, ваша организация использует EOP для защиты локальных почтовых ящиков), необходимо добавлять исходящие IP-адреса для каждого из локальных пограничных почтовых серверов к записи SPF TXT в службе DNS.

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

Сведения о доменах, которые необходимо включить для Office 365, см. в статье Внешние записи DNS для Office 365. Следуйте пошаговому руководству по обновлению записей инфраструктуры политики отправителей (TXT) для своего регистратора доменных имен. Если ваш регистратор не указан, вам потребуется связаться с ним в личном порядке, чтобы узнать, как обновить запись.

Синтаксис типичной записи SPF TXT для Office 365 выглядит следующим образом:

v=spf1 [<ip4>|<ip6>:<IP address>] [include:<domain name>] <enforcement rule>

Например:

v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 include:spf.protection.outlook.com -all

где:

  • v=spf1 — обязательный параметр. Он определяет тип записи как SPF TXT.

  • ip4 указывает, что используются IP-адреса версии 4. ip6 указывает, что используются IP-адреса версии 6. При использовании IP-адресов IPv6 ip4 в примерах следует заменить на ip6. Можно также указать диапазоны IP-адресов с использованием нотации CIDR, например ip4:192.168.0.1/26.

  • IP address — это IP-адрес, который требуется добавить к записи SPF TXT. Как правило, это IP-адрес сервера исходящей почты для организации. Вы можете указать несколько серверов исходящей почты. Дополнительные сведения см. в разделе Пример. Запись SPF TXT для нескольких локальных серверов исходящей почты и Office 365.

  • domain name — это домен, который требуется добавить в качестве надежного отправителя. Список доменных имен, которые следует включить для Office 365, см. в статье Внешние записи DNS для Office 365.

  • Как правило, используется одно из указанных ниже правил принудительного применения.

    • -all

      Указывает на серьезный сбой. Если вам известны все разрешенные IP-адреса для домена, укажите их в записи SPF TXT и используйте квалификатор -all (серьезный сбой). Кроме того, если используется только инфраструктура политики отправителей, то есть не используются DMARC и DKIM, то рекомендуется использовать квалификатор -all. Рекомендуем всегда использовать этот квалификатор.

    • ~all

      Указывает на мягкий сбой. При отсутствии полного списка IP-адресов следует использовать квалификатор ~all (мягкий сбой). Кроме того, если используется DMARC с параметром p=quarantine или p=reject, вы можете использовать квалификатор ~all. В противном случае используйте квалификатор -all.

    • ?all

      Указывает на нейтральное состояние. Этот квалификатор используется при тестировании инфраструктуры политики отправителей. Не рекомендуем использовать его в рабочем развертывании.

Если вся почта отправляется из Office 365, используйте следующую запись SPF TXT:

v=spf1 include:spf.protection.outlook.com -all

В гибридной среде, если IP-адрес локального сервера Exchange Server — 192.168.0.1, чтобы настроить правило принудительного применения для инфраструктуры политики отправителей на серьезный сбой, создайте следующую запись SPF TXT:

v=spf1 ip4:192.168.0.1 include:spf.protection.outlook.com -all

При наличии нескольких серверов исходящей электронной почты необходимо включить IP-адрес для каждого почтового сервера в записи SPF TXT и отделить каждый IP-адрес пробелом, за которым следует выражение "ip4:". Например:

v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 ip4:192.168.0.3 include:spf.protection.outlook.com -all

После создания записи SPF TXT добавьте ее в свой домен, выполнив действия, описанные в статье Настройка инфраструктуры политики отправителей в Office 365 для предотвращения спуфинга.

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

Для личного домена можно создать только одну запись SPF TXT. Создание нескольких записей приводит к ситуации циклического перебора и сбою инфраструктуры политики отправителей. Чтобы избежать этого, вы можете создать отдельные записи для каждого поддомена. Например, создайте одну запись для домена contoso.com и еще одну для поддомена bulkmail.contoso.com.

Если перед доставкой сообщения электронной почты выполняется более 10 DNS-запросов, почтовый сервер получателя сообщит о постоянной ошибке (permerror), а сообщение не пройдет проверку инфраструктуры политики отправителей. Сервер получателя также может отправить отчет о недоставке, включающий ошибку примерно следующего содержания:

  • Превышено максимальное количество прыжков для сообщения.

  • Для сообщения потребовалось слишком много запросов.

Некоторые записи SPF TXT для сторонних доменов поручают серверу получателя выполнять большое количество DNS-запросов. Например, на момент написания этой статьи запись домена Salesforce.com содержит 5 операторов include:

v=spf1 include:_spf.google.com
include:_spfblock.salesforce.com
include:_qa.salesforce.com
include:_spfblock1.salesforce.com
include:spf.mandrillapp.com mx ~all

Чтобы избежать ошибки, вы можете реализовать политику, согласно которой (к примеру) для отправки массовых рассылок все должны использовать специальный поддомен. Затем вы можете задать для поддомена отдельную запись SPF TXT, включающую массовые рассылки.

В некоторых случаях, таких как пример с доменом salesforce.com, необходимо указывать домен в записи SPF TXT, но в остальных случаях сторонний поставщик уже создал поддомен специально для этой цели. Например, для домена exacttarget.com создан поддомен, который необходимо использовать с записью SPF TXT:

cust-spf.exacttarget.com

При включении сторонних доменов в запись SPF TXT необходимо согласовать со сторонним поставщиком, какой домен или поддомен будет использоваться, чтобы соблюдать ограничение в 10 запросов.

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

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

 
Показ: