DKIM и DMARC в Office 365 (часть 3)
- DKIM и DMARC в Office 365 (часть 2)
Внедрение DMARC
Как я упоминал в предыдущих частях этой серии статей, Office 365 уже полностью поддерживает входящую проверку DKIM, а исходящая подпись DKIM появится очень скоро. Таким образом, на момент написания этой статьи все, что мы можем сделать, — это настроить записи DMARC.
Во-первых, нам нужно иметь запись SPF (помните, что у нас пока не может быть записи DKIM). Для моего домена у меня уже есть следующая запись SPF:
фигура 1
В нем говорится, что только Office 365 может отправлять электронные письма с . Любая почта с этого домена, отправленная откуда-либо еще, приведет к сбою проверки SPF (если, конечно, IP-адрес не подделан). Чтобы убедиться в этом, я отправил электронное письмо из своего локального развертывания на почтовый ящик в моем клиенте Office 365 и подтвердил, что это действительно не удалось:
фигура 2
Также обратите внимание на dmarc=no, что означает отсутствие записи DMARC для домена .
Теперь нам нужно настроить запись DMARC. Итак, давайте начнем с публикации политики DMARC с , чтобы мы могли сначала собрать данные. Ниже представлена запись Microsoft DMARC, опубликованная в записи TXT для :
Рисунок 3
Как вы можете видеть на снимке экрана выше, Microsoft в настоящее время не предпринимает никаких действий. Он просто отслеживает и отправляет свои отчеты DMARC обратно в Agari, стороннюю организацию.
В моем случае я создал следующую запись DMARC:
Рисунок 4
В записи выше у нас есть следующие явные теги:
ярлык | ценность | Объяснение |
никто | Политика, применяемая к электронной почте, не прошедшей проверку DMARC. Может быть «нет», «карантин» или «отклонить». Ни один из них не используется для сбора отзывов и получения информации, не влияя на существующие потоки. | |
mailto:[адрес электронной почты защищен] | Список URI для получателей, на которые отправляются отзывы в формате XML. Обратите внимание, что это не список адресов электронной почты, поскольку DMARC требует список URI вида «mailto:[email protected]». |
Таблица 1
И следующие неявные теги (по умолчанию, если не объявлены):
ярлык | дефолт | объяснение |
р | Указывает для подписей DKIM. «r» — « », а «s» — . Облегченный режим позволяет доменам DKIM d=, прошедшим проверку подлинности, которые совместно используют общий домен организации с заголовком электронной почты — домен From:, проходить проверку DMARC. Строгий режим требует точного соответствия между доменом DKIM d= и заголовком письма — домен From:. | |
р | Задает для SPF. «r» — « », а «s» — . Облегченный режим позволяет доменам, прошедшим проверку подлинности SPF, которые совместно используют общий домен организации с заголовком электронной почты — домен From:, проходить проверку DMARC. Строгий режим требует точного соответствия между доменом SPF и заголовком письма — домен From:. | |
р = значение | Политика, применяемая к электронной почте из поддомена этой записи DMARC, не прошедшей проверку DMARC. Этот тег позволяет владельцам доменов явно публиковать политику субдоменов с подстановочными знаками. | |
0 | Варианты судебной отчетности. Возможные значения: «0» для создания отчетов, если базовые механизмы аутентификации не могут дать результат прохождения DMARC, «1» для создания отчетов, если механизмы не работают, «d» для создания отчета, если не удалось проверить подпись DKIM, «s», если СПФ не удалось. | |
никто | Список URI для получателей, на которые отправляются отчеты Forensic. | |
афрф | Формат отчетов для отдельных отчетов Forensic. Может быть либо «afrf», либо «iodef». | |
86400 | Интервал отчетов о том, как часто вы хотели бы получать сводные отчеты XML. Скорее всего, вы будете получать отчеты один раз в день независимо от этой настройки. | |
100 | Тег процента указывает получателям применять политику только к электронной почте, которая не проходит проверку DMARC X раз. Например, «pct=25» указывает получателям применять политику «p=» в 25% случаев к электронной почте, не прошедшей проверку DMARC. ПРИМЕЧАНИЕ. У вас должна быть политика «карантин» или «отклонение», чтобы процентный тег мог что-либо делать. |
Таблица 2
Как только эта запись будет опубликована, все получатели, поддерживающие DMARC, включая Office 365, начнут проверять DMARC и отправлять отчеты. Если я снова запущу тот же тест и отправлю электронное письмо от пользователя из моего локального Exchange на почтовый ящик в моем клиенте Office 365, DMARC теперь завершится ошибкой (поскольку теперь у меня есть запись DMARC и потому что SPF не работает). Также обратите внимание, что для действия установлено значение :
Рисунок 5
Разница в том, как Office 365 реализует DMARC, заключается в том, как он обрабатывает сообщения, не прошедшие проверку DMARC для входящих сообщений. Если политика DMARC указывает , EOP помечает сообщение как спам, а не отклоняет его, то есть обрабатывает и одинаково. Это связано с тем, что существует легитимная почта, которая не проходит проверку DMARC. Например, отправка почты в списки рассылки, которая ретранслируется всем участникам списка. Этот тип почты по-прежнему не пройдет проверку DMARC, но будет помечен как спам. Пользователи по-прежнему могут получать их в свои почтовые ящики, добавляя надежных отправителей или администраторы создают правило транспорта Exchange (ETR) для этих конкретных отправителей. Когда рабочая группа DMARC добавит поддержку этих типов сообщений, EOP будет ее поддерживать. Но пока это просто так.
Хотя они обрабатываются одинаково, мы все же можем различить их, так как EOP установит уровень достоверности фишинга на 8 в случае, если сообщение не пройдет проверку DMARC с действием отклонения, что означает, что сообщение является фишинговым. Это указывается в заголовке и в поле . Когда эта функция будет реализована, это отключит такие функции в сообщении, как «Ответить», «Ответить всем», «Вложения» и «Ссылки», чтобы пользователь не мог выполнять с ним какие-либо действия. Предполагается, что действие отклонения должно держать сообщения подальше от пользователей. EOP не может полностью исключить их, но отключение функций сообщения близко к достижению того же результата. На данный момент, по крайней мере для моего арендатора, еще не настроен для этого сценария.
Кроме того, в этих случаях EOP переопределяет действие и указывает, что он сделал это в заголовках, помещая в поле , например:
Рисунок 6
Это означает, что сообщение не прошло проверку DMARC и политика была , но EOP отменила действие и вместо этого пометила его как спам. Как упоминалось выше, надежный отправитель или ETR все еще могут переопределить это.
Что касается Gmail, когда действие настроено на карантин, оно помещает электронное письмо в папку пользователя. Когда действие настроено на отклонение, оно просто отбрасывает электронное письмо и отправляет отправителю следующий отчет о недоставке:
Рисунок 7
Гибридные среды
Сценарий, о котором следует помнить, предназначен для организаций, использующих гибридное развертывание Exchange, в котором записи MX указывают на локальную среду, а не на EOP. В этом случае сбои DMARC не применяются EOP, потому что в противном случае клиенты получили бы огромное количество ложных срабатываний. Почему? Давайте подумаем об этом:
- Сообщение отправляется от интернет-отправителя пользователю в Office 365;
- Поскольку записи MX указывают на локальную среду, сообщение доставляется на локальный сервер Exchange;
- После выполнения поиска пользователя локальный гибридный сервер перенаправляет электронное письмо в EOP;
- Ошибка SPF, так как IP-адрес подключения (к EOP) не является исходным IP-адресом, а является IP-адресом локального гибридного сервера.
Кроме того, когда сообщение не проходит DKIM, это не обязательно означает, что это произошло из-за подделки DKIM. Это могло произойти из-за того, что более старая версия Exchange изменила содержимое сообщения, что нарушило хэши тела DKIM. К сожалению, EOP не может отличить модификацию в пути от вредоносной подделки DKIM.
При сбое SPF и DKIM также произойти сбой, EOP не будет применять сбои DMARC, если основная запись MX организации не указывает на EOP (все это связано с маршрутизацией). EOP по-прежнему может определять, проходит ли сообщение DMARC при прохождении DKIM-подписи.
Отчеты DMARC
Наконец, давайте посмотрим, как выглядит отчет DMARC. Вот что вы можете ожидать:
- Участвующий почтовый провайдер будет отправлять ежедневные отчеты по электронной почте на основе того, что вы указали в теге «rua»;
- Эти отчеты будут сообщениями в формате MIME и будут включать XML-файл, содержащийся в zip-файле;
- Отчеты включают данные о сообщениях, которые прошли и/или не прошли DMARC.
Ниже приведен пример отчета DMARC с действием none:
Рисунок 8
Обратите внимание, что в нет dkim, так как я еще не реализовал DKIM.
Эти отчеты включают три раздела:
- Информация о провайдере:
- Имя почтового провайдера (google.com);
- Адрес электронной почты отправителя почтового провайдера и дополнительная контактная информация ([email protected]);
- Идентификационный номер отчета (4760398061289808876);
- Диапазон дат начала и окончания в секундах (от 1424563200 до 1424649599). Эти числа представляют собой секунды с «эпохи». Эпоха, также известная как временные метки Unix, представляет собой количество секунд, прошедших с 00:00:00 1 января 1970 года.
- DMARC-запись
- Сводка результатов аутентификации. Это важная часть (ищите области, которые показывают нейтральные, нулевые или неудачные результаты):
- IP-адрес, указанный в законном и/или мошенническом электронном письме (154.xxx.xxx.xxx);
- Количество идентифицированных IP-адресов (6);
- С домена (nunomota.pt);
- В результатах проверки подлинности DKIM перечислены домен и результат (опять же, здесь нет DKIM, поскольку я еще не реализовал DKIM);
- В результатах проверки подлинности SPF указан домен и результат (нейтральный, пройден или не пройден).
Ниже приведен аналогичный отчет, но с действием reject:
Рисунок 9
Вывод
В этой серии статей мы рассмотрели, что такое DKIM и DMARC и как они работают в Office 365.
- DKIM и DMARC в Office 365 (часть 2)