DKIM и DMARC в Office 365 (часть 2)

• DKIM и DMARC в Office 365 (часть 3)

Что такое ДМАРК?

Спамеры часто подделывают адрес «От» в почтовых сообщениях, поэтому создается впечатление, что спам исходит от пользователя в вашем домене. Аутентификация сообщений на основе домена, отчетность и соответствие (DMARC) — это техническая спецификация, опубликованная в 2012 году и созданная группой организаций с целью помочь уменьшить количество фишинговых атак.

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

Принцип работы DMARC заключается в том, чтобы помочь получателям электронной почты определить, соответствует ли предполагаемое сообщение тому, что получатель знает об отправителе. Если нет, DMARC включает руководство по обработке «несогласованных» сообщений. DMARC не определяет, является ли электронное письмо спамом или иным образом мошенническим. Вместо этого DMARC требует, чтобы сообщения не только проходили проверку DKIM и/или SPF, но также проходили . Для SPF сообщение должно ПРОЙТИ проверку SPF, а домен в заголовке должен соответствовать домену, используемому для проверки SPF. Для DKIM сообщение должно быть подлинно подписано, а домен действительной подписи должен совпадать с доменом в заголовке В соответствии с DMARC сообщение может завершиться ошибкой, даже если оно проходит SPF или DKIM, но не выравнивается.

Еще одна замечательная особенность DMARC заключается в том, что он также предоставляет получателю электронной почты возможность сообщать отправителю о сообщениях, которые прошли или не прошли оценку DMARC. Чтобы отправитель доверял этому процессу и знал о влиянии публикации политики, отличной от (режим мониторинга, как мы увидим), получатель отправляет ежедневные сводные отчеты, указывающие отправителю, сколько писем было получено и прошли ли эти письма. SPF и/или DKIM и если они были согласованы. Это очень помогает организациям, развертывающим SPF и DKIM, поскольку они могут медленно развертывать эти функции и отслеживать их без предварительной блокировки или отклонения каких-либо электронных писем.

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

Рассмотрим пример DMARC TXT для домена , который гласит:

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

Как видите, записи DMARC следуют синтаксису «тег-значение». В следующей таблице показаны некоторые из доступных тегов:

Таблица 1

Требуются только теги и . Для политики доступны три возможных параметра политики:

• none — не предпринимать никаких действий (известный как режим монитора);
• карантин – пометить затронутые сообщения как спам;
• reject – отменить сообщение на уровне SMTP.

Режим выравнивания относится к точности, с которой записи отправителя сравниваются с подписями SPF и DKIM, причем два возможных значения — или , представленные буквами «r» и «s» соответственно. Короче говоря, расслабленный допускает частичное совпадение, например, поддомены данного домена, в то время как строгий требует точного совпадения.

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

В следующем примере, если сообщения якобы отправлены из домена и не проходят проверку DMARC, помещаются в карантин 20 % сообщений. Затем отправьте ежедневные сводные отчеты по электронной почте на адрес :

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

Внедрение DMARC

DMARC был разработан на основе реального опыта некоторых из крупнейших в мире отправителей и получателей электронной почты, использующих SPF и DKIM. Спецификация учитывает тот факт, что в большинстве случаев организации очень сложно переключиться на производство. Существует ряд методов «регулирования» обработки DMARC, чтобы все стороны могли постепенно перейти к полному развертыванию.

1. Начните с развертывания DKIM и/или SPF;
2. Убедитесь, что ваши почтовые серверы правильно выравнивают соответствующие идентификаторы;
3. Опубликовать запись DMARC с действием «нет»;
4. Проанализируйте данные, предоставленные другими получателями, и соответствующим образом измените свою инфраструктуру электронной почты;
5. Измените флаги политики DMARC с «нет» на «карантин» на «отклонить», когда вы станете более уверенными в общей конфигурации.

Использование DMARC следует наращивать медленно, применяя эти политики в указанном порядке. Во-первых, следите за своим трафиком и ищите аномалии в отчетах, например сообщения, которые еще не подписаны или, возможно, подделываются. Затем, когда вас устраивают результаты, измените параметр политики с «нет» на «карантин». Еще раз просмотрите результаты. Наконец, когда вы абсолютно уверены, что все ваши сообщения подписаны, измените параметр политики на «отклонить», чтобы в полной мере использовать DMARC. Пересмотрите отчеты, чтобы убедиться, что ваши результаты приемлемы и соответствуют ожиданиям.

Точно так же необязательный тег можно использовать для подготовки и выборки развертывания DMARC. Поскольку значение по умолчанию — 100%, использование «pct=25» в записи DMARC TXT приводит к тому, что одна четвертая часть всех сообщений, на которые распространяется политика, фактически получает решение, а не все из них. Этот параметр полезен, если вы решите помещать в карантин и отклонять почту. Начните с более низкого процента для начала и увеличивайте его каждые несколько дней. Консервативный цикл развертывания будет примерно таким:

1. Мониторить все;
2. Карантин 5%;
3. Карантин 10%;
4. Карантин 25%;
5. Карантин 50%;
6. Карантин всех;
7. Отклонить 5%;
8. Отклонить 10%;
9. Отклонить 25%;
10. Отклонить 50%;
11. Отклонить все.

В настоящее время Microsoft развертывает DMARC для Office 365. После его завершения вам не нужно будет ничего делать, чтобы включить проверку DMARC для входящей почты. Чтобы проверить, не было ли оно уже развернуто в вашем клиенте, проверьте заголовок . Если DMARC уже установлен, EOP добавит следующую информацию для проверки DMARC:

фигура 1

Параметр dmarc=<result> указывает, прошло ли сообщение DMARC или нет ( , или ). Действие=<действие> указывает, какие действия получателя должны быть основаны на результате DMARC ( , или ). В данном случае это было сообщение, отправленное из моей учетной записи Gmail в почтовый ящик моего клиента Office 365.

Как я уже упоминал, Office 365 уже полностью поддерживает входящую проверку DKIM, а исходящая подпись DKIM появится очень скоро. Таким образом, на момент написания этой статьи все, что мы можем сделать, — это настроить записи DMARC. И это то, что мы будем делать в следующей части этой серии статей.

Вывод

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

• DKIM и DMARC в Office 365 (часть 3)