Демистификация записи DMARC

Опубликовано: 2021-08-18

Стандарт DMARC (Domain-based Message Authentication, Reporting & Conformance) - лучший инструмент, который есть у производителей для борьбы с фишинговыми атаками, нацеленными на клиентов путем подмены их собственных доменов. Но внедрение DMARC может очень быстро запутать.

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

Что такое теги DMARC?
Теги DMARC - это язык стандарта DMARC. Они говорят получателю электронной почты (1) проверить DMARC и (2) что делать с сообщениями, не прошедшими аутентификацию DMARC.

Обязательные теги DMARC
Есть только два обязательных тега DMARC: «v:» и «p:».

v: Версия . Этот тег используется для идентификации записи TXT как записи DMARC, чтобы получатели электронной почты могли отличить ее от других записей TXT. Тег v: должен иметь значение «DMARC1», и он должен быть указан как первый тег во всей записи DMARC. Если значение не совсем соответствует «DMARC1» или тег v: не указан первым, вся запись DMARC будет проигнорирована получателем.

Пример: v = DMARC1

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

  1. p = none: владелец домена не запрашивает никаких конкретных действий с почтой, не прошедшей аутентификацию и согласование DMARC.
  2. p = quarantine: владелец домена желает, чтобы почта, не прошедшая проверку подлинности и согласования DMARC, рассматривалась получателями почты как подозрительная. Это может означать, что получатели помещают электронное письмо в папку спама / нежелательной почты, отмечают его как подозрительное или внимательно изучают это письмо.
  3. p = reject: владелец домена требует, чтобы получатели почты отклонили электронное письмо, которое не прошло проверку подлинности и согласования DMARC. Отклонение должно происходить во время транзакции SMTP. Это самая строгая политика, обеспечивающая высочайший уровень защиты.

Учитывая приведенную выше информацию, наиболее простой пример записи DMARC мог бы быть: v = DMARC1; p = нет.

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

  • rua: указывает, куда следует отправлять сводные отчеты DMARC. Отправители указывают адрес назначения в следующем формате: rua = mailto: [электронная почта защищена]
  • ruf: указывает, куда следует отправлять отчеты DMARC. Отправители указывают адрес назначения в следующем формате: ruf = mailto: [электронная почта защищена]

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

  • adkim: указывает на строгое или мягкое выравнивание идентификатора DKIM. По умолчанию расслаблено.
  • aspf: указывает на строгое или мягкое выравнивание идентификатора SPF. По умолчанию расслаблено.
  • rf: Формат отчетов об ошибках сообщений. По умолчанию используется формат сообщения об ошибках аутентификации или «AFRF».
  • ri: количество секунд, прошедшее между отправкой сводных отчетов отправителю. Значение по умолчанию - 86 400 секунд или день.
  • pct: процент сообщений, к которым должна применяться политика DMARC. Этот параметр позволяет постепенно внедрять и тестировать влияние политики.
  • fo : Определяет, о каких типах уязвимостей аутентификации и / или выравнивания сообщается Владельцу домена.
  • Последний fo: tag имеет четыре значения:
  • 0: генерировать отчет об ошибке DMARC, если все базовые механизмы аутентификации не дают согласованного результата «пройден». (Дефолт)
  • 1: Сгенерировать отчет об ошибке DMARC, если какой-либо базовый механизм аутентификации произвел нечто иное, чем согласованный результат «пройден».
  • d: создать отчет о сбое DKIM, если у сообщения есть подпись, не прошедшая оценку, независимо от ее выравнивания.
  • s: генерировать отчет об ошибке SPF, если сообщение не прошло оценку SPF, независимо от его выравнивания.

Хотя по умолчанию установлено значение «fo = 0», Return Path рекомендует клиентам использовать fo: 1 для генерации наиболее полных отчетов об ошибках, обеспечивая гораздо более детальную видимость канала электронной почты.

Ниже приведен пример записи DMARC. Основываясь на том, что вы уже узнали, попробуйте расшифровать каждый тег:

v = DMARC1; p = отклонить; fo = 1; rua = mailto: [электронная почта защищена]; ruf = mailto: [электронная почта защищена]; rf = afrf; pct = 100

А как насчет субдоменов?
Последний тег DMARC, который мы обсудим сегодня, - это тег sp:, который используется для обозначения запрошенной политики для всех поддоменов, в которых почта не проходит проверку подлинности и согласования DMARC. Этот тег применим только к доменам верхнего уровня (доменам организационного уровня). Это наиболее эффективно, когда владелец домена хочет указать разные политики для домена верхнего уровня и всех поддоменов.

Для следующих сценариев мы будем использовать домен верхнего уровня «domain.com» и поддомен «mail.domain.com», чтобы проиллюстрировать варианты использования.

  1. Владелец домена хочет применить политику отклонения для «domain.com», но политику карантина для «mail.domain.com» (и всех других поддоменов). Тогда запись DMARC для «domain.com» будет включать «v = DMARC1; p = отклонить; sp = карантин ». Это эффективная стратегия, если организации необходимо поддерживать отдельную политику DMARC для домена верхнего уровня и всех поддоменов.
  2. Владелец домена хочет применить политику отклонения для «mail.domain.com» (и всех других поддоменов), но не применять политику отклонения для «domain.com». Тогда запись DMARC для «domain.com» будет включать «v = DMARC1; p = нет; sp = отклонить ». Это была бы эффективная стратегия борьбы с атаками по словарю в случае, если домен верхнего уровня не готов применять политику, но мошенники подменяют поддомены, такие как mail.domain.com, abc.domain.com, 123.domain. com, xyz.domain.com и т. д. Установка тега sp: для отклонения защитит организацию от этих атак по словарю, нацеленных на субдомены, без воздействия на почту, отправляемую с домена верхнего уровня, «domain.com».

Теперь, когда вы понимаете ДНК записи DMARC, узнайте больше о том, какие виды атак она блокирует, а какие нет в Отчете об угрозах электронной почты .