Главная | Контакты | Настройки СМЕНИТЬ ПАЛИТРУ:

Главная > Интернет > Домен

DMARC для защиты электронной почты

DMARC – Domain-based Message Authentication, Reporting and Conformance (аутентификация сообщений, предоставление отчётов и проверка соответствия на базе доменного имени). Это относительно новая технология (утверждена в качестве RFC 7489 - https://tools.ietf.org/html/rfc7489 в марте 2015 года), призванная уменьшить количество подделок сообщений электронной почты, снизить количество фишинговых писем и способствовать борьбе со спамом.

Схема функционирования проверки DMARC в корпоративной почте

Как настроить DMARC?

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

Шаг 1. SPF – настройка Sender Policy Framework

Наилучшей практикой для большинства почтовых доменов будет следующая SPF-политика:

IN TXT "v=spf1 a mx -all"

где v=spf1 – зарезервированное имя механизма авторизации, a и mx разрешают приём почты с A- и MX-записей, описанных в доменной зоне отправителя, а политика по умолчанию -all требует безоговорочно отклонять приём сообщений со всех других адресов. За информацией о более детальной настройки SPF следует обратиться к отдельной статье по этому вопросу «SPF — применение в почтовых серверах и массовых рассылках».

Шаг 2. DKIM – настройка Domain Keys Identified Mail

Настройка DKIM несколько более сложная, чем SPF, так как подразумевает внесение уникальных изменений в каждое отправляемое сообщение. Значит, без настроек самого почтового сервера или установки дополнительного ПО не обойтись. В Linux это может быть, например, пакет OpenDKIM, который будучи установленным в режиме milter (mail filter) осуществляет подписание всех исходящих через него сообщений доменными ключами.

После настройки ПО необходимо опубликовать открытую часть ключа DKIM (public key) в DNS-зоне защищаемого домена. Запись должна иметь тип TXT и может выглядеть подобным образом:

dkimselector._domainkey IN TXT "v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCX6lXGcAh7J5DfH9fBmHMAMiMaWN3GPD6+t7IaDACNcd4NDYYwi3VTXQxtqbPlB68ZnH7BLHefST+uiXZB
RJffSJjqMlpylGGJ5wmTrgAg2LJ5iohd21LfwOQsDoAuwx295JzyZi89Cfa7zs/vnoWUdd8wEEHOEteSeUE/ejHuqQIDAQAB"
_adsp._domainkey IN TXT "dkim=discardable"

Шаг 3. Собственно настройка DMARC

Настройка DMARC весьма несложная и подобна указанию записи SPF. В DNS-зону защищаемого домена вносится дополнительная TXT-запись предопределённого наименования _dmarc Например, для домена корпоративной почты example.com DMARC-запись должна называться _dmarc.example.com Содержимое этой записи регламентируется следующими операторами:

ОператорОписаниеПримерОбязательный Принимаемые значенияЗначение по умолчанию
v Версия протокола v=DMARC1 Да Пока может быть только DMARC1. Других значений в настоящее время не определено, зарезервировано для будущих версий протокола. Не применимо — обязательный оператор.
p Политика домена p=reject Да none — не предпринимать действий, может использоваться для получения отчётов;
quarantine — направлять не прошедшие проверку сообщения в карантин (или в папку «Спам»);
reject — отклонять сообщения;
Не применимо — обязательный оператор.
adkim Режим проверки соответствия DKIM-подписей adkim=s Нет r (relaxed) — разрешены частичные совпадения, например для поддоменов основного домена;
s (strict) — только точные совпадения разрешены;
r
aspf Режим проверки SPF aspf=s Нет r (relaxed) — разрешены частичные совпадения, например для поддоменов основного домена;
s (strict) — только точные совпадения разрешены;
r
pct Процент сообщений, к которым в случае не прохождения проверки будет применяться политика pct=50 Нет Оператор может использоваться для постепенного развёртывания политики DMARC. Например, сначала указывается pct=1 для того чтобы убедиться, что все легитимные сообщения достигают получателей, далее увеличивается до 100. 100
sp Политика для поддоменов sp=reject Нет none — не предпринимать действий, может использоваться для получения отчётов;
quarantine — направлять не прошедшие проверку сообщения в карантин (или в папку «Спам»);
reject — отклонять сообщения;
Значение по умолчанию отсутствует.
fo Настройка условий, при которых сообщения, не прошедшие проверку, будут попадать в отчёты fo=1 Нет 0 — записывать попытку в отчёт, если не прошла ни SPF, ни DKIM проверка;
1 — записывать попытку в отчёт, если не прошла либо SPF, либо DKIM проверка;
d — записывать попытку в отчёт, если не прошла DKIM проверка;
s — записывать попытку в отчёт, если не прошла SPF проверка;
0
rua Email для получения агрегированных отчётов rua=mailto:root@example.com Нет Адрес(а) электронной почты, на который почтовые серверы с поддержкой DMARC будут отправлять XML-отчёты. Значение по умолчанию отсутствует.
ruf Email для получения детализированных отчётов ruf=mailto:root@example.com Нет Адрес(а) электронной почты, на который почтовые серверы с поддержкой DMARC будут отчёты с детализацией по сообщениям, не прошедшим DKIM/SPF-проверки. Значение по умолчанию отсутствует.
rf Формат отправляемого администратору агрегированного XML-отчёта. rf=iodef Нет Принимаемые значения afrf (Authentication Failure Reporting Format) и iodef (Incident Object Description Format). afrf
ri Частота получения агрегированных отчётов в XML ri=604800 Нет Интервал получения отчётов указывается в секундах, 86400 — для суток, 604800 — для недели и т.д. 86400 (сутки)

Для большинства почтовых доменов с правильно настроенными и корректно функционирующими SPF и DKIM наилучшим вариантом настройки DMARC будет:

_dmarc IN TXT "v=DMARC1; p=reject;"

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

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

Критика DMARC

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

Например, в политике SPF присутствует оператор all, задав которому значение «-» можно запретить приём всех сообщений в неавторизованных IP-адресов/доменных имён. Аналог в DMARC – p=reject;

А в стандарте DKIM (вернее в его подстандарте ADSP RFC 5617 - https://tools.ietf.org/html/rfc5617) описан Author Domain Signing Practices, который в случае значения dkim=discardable предписывает отклонять неподписанные/подписанные неверно сообщения. Нынешний аналог в DMARC опять же p=reject;

Если бы все отправители опубликовали у себя эти политики, а все почтовые серверы при получении проверяли бы эти записи, то во внедрении нового стандарта DMARC не возникло бы особой необходимости. К сожалению, многолетняя практика использования SPF и DKIM показывает, что отправители неохотно публикуют запретительные политики (если публикуют их вообще), а серверы-получатели зачастую игнорируют при приёме почты даже явные запреты. Так, например, почтовый сервер mail.ru не учитывает значение политики ADSP при проверке подписи DKIM, что делает возможным отправку на почтовые ящики этого сервиса фишинговых сообщений даже от имени доменов с политикой dkim=discardable. Это, конечно же, является игнорированием RFC со стороны mail.ru (т.н. rfc ignorant).

Остаётся лишь надеяться, что подобная участь не постигнет DMARC и эта технология будет широко внедрена и повсеместно станет применяться согласно стандартам RFC.

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

Пример отчёта DMARC

<?xml version="1.0" encoding="UTF-8" ?>
 <feedback>
  <report_metadata>
    <org_name>Название сервиса</org_name>
    <email>Email-адрес отправителя</email>
    <extra_contact_info>Контактная информация — сайт, телефон</extra_contact_info>
    <report_id>4037169972434315646</report_id>
    <date_range>
      <begin>1470518900</begin>
      <end>1470416399</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>s</adkim>
    <aspf>s</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>127.0.0.1</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>fail</result>
      </dkim>
      <spf>
        <domain>spammer.net</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

Проверить DMARC-запись

Материал взят с сайта: https://www.tendence.ru/articles/dmarc-dlya-zashchity-korporativnoj-pochty

Настройка DMARC
Как прописать DMARC: путеводитель с примерами
DMARK - Википедия


Главная > Интернет > Домен