Главная | Контакты | Настройки

СМЕНИТЬ ПАЛИТРУ:

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

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

Как настроить 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 Содержимое этой записи регламентируется следующими операторами:

Для большинства почтовых доменов с правильно настроенными и корректно функционирующими 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-запись