10 лет успеха:2006-2016
8 (800) 500-92-06
Бесплатный звонок из регионов

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

Главная / Статьи / DMARC для защиты корпоративной почты

DMARC – Domain-based Message Authentication, Reporting and Conformance (аутентификация сообщений, предоставление отчётов и проверка соответствия на базе доменного имени). Это относительно новая технология (утверждена в качестве RFC 7489 в марте 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-отчёты. Пример DMARC-отчёта. Значение по умолчанию отсутствует.
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.

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

Критика DMARC

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

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

А в стандарте DKIM (вернее в его подстандарте ADSP RFC 5617) описан 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>


При перепубликации статьи установка активной индексируемой гиперссылки на источник - сайт TENDENCE.RU обязательна!

880 просмотров