Внедрение DMARC для защиты корпоративного домена от спуфинга

Привет, Хабр! В этом посте мы снова поговорим о проблеме подделки отправителя (или так называемом спуфинге). В последнее время такие случаи очень участились: подделывается все: письма со счетами за ЖКХ, из налоговой инспекции, банков и так далее. Решить эту проблему помогает настройка строгой DMARC-политики. Мы как почтовая служба проверяем все приходящие к нам письма на DMARC начиная с февраля 2013 года. Мы были первым в рунете почтовым сервисом, поддержавшим стандарты DMARC. Однако чтобы минимизировать число поддельных писем, этого, к сожалению, недостаточно. Главное, чтобы строгий DMARC был поддержан на стороне отправителя. Вот почему мы не устаем качать эту тему, ведем активную разъяснительную работу и всячески призываем всех включать у себя строгий DMARC.

Позитивные сдвиги уже есть: с каждым месяцем мы видим прирост числа корпоративных отправителей, прописавших DMARC, на десятки процентов. Однако безусловно, еще есть над чем работать. Практика показывает, что IT-культура находится на очень разном уровне. Кто-то слышал краем уха про DMARC, но пока не собирается его внедрять. Есть и такие, для кого факт, что в транспортных протоколах электронной почты отсутствует какая-либо проверка и защита адреса отправителя, до сих пор является настоящим откровением. Кроме того, поддержка DMARC — задача непростая. Только на первый взгляд кажется, что достаточно опубликовать запись в DNS, и не требуется никакого дополнительного софта или технических средств. На практике в крупной компании с многочисленными потоками электронной почты и развесистой структурой почтовых доменов все гораздо сложнее. И есть моменты, которые следует предусмотреть и продумать заранее. Именно для таких сложных случаев мы написали эту статью, постаравшись собрать в ней все нюансы.

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

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

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

1. Проведите ревизию легитимных писем от вашего домена и его поддоменов

Типичные упущения в этом процессе:

• коммерческие письма, отправляемые через внешних поставщиков услуг по рассылке;
• внутренние списки рассылки;
• перенаправления почты с ящиков пользователей;
• технологические письма, формируемые серверами и оборудованием;
• отчеты о доставке (DSN) или о невозможности доставки (NDR) писем.

Для каждой категории писем необходимо внедрить SPF и выяснить возможность или невозможность подписи писем с использованием DKIM.

2. Внедрите SPF для основного домена и его поддоменов

Часто можно услышать, что SPF защищает адрес отправителя от подделки. Это не так. SPF контролирует только адрес SMTP-конверта, который не видит пользователь. При этом большое количество доменов до сих пор не внедрили его, и многие стороны не поддерживают переадресацию почты, совместимую с SPF. По этой причине чаще всего используется нейтральная политика SPF (neutral, ?) или мягкое блокирование (soft reject, ~). Для совместного использования с DMARC не имеет значения, какая именно дефолтная политика (neutral ?, soft reject ~ или reject -) SPF будет использована. Мы не рекомендуем использовать политику reject (-) за исключением особо требовательных к безопасности доменов, так как это может негативно сказаться на доставке легитимных писем непрямыми способами, например через пересылки или списки рассылки. Хотя большая часть получателей не блокирует письма по SPF даже при публикации строгой политики, а использует SPF в рамках весовых классификаторов. Вопреки устоявшемуся мнению, именно такой режим SPF чаще всего применяется на практике, и он полностью соответствует рекомендациям стандарта.

Можно дать следующие рекомендации по внедрению SPF:

• Не забывайте, что SPF проверяется для домена из адреса envelope-from (он же MAIL FROM и Return-Path). Для того чтобы SPF можно было использовать для аутентификации отправителя сообщения, домен в envelope-from должен совпадать с доменом заголовка From с точностью до организационного домена (т. е. до домена второго уровня в .ru или .com). Использование неправильных адресов для envelope-from — одна из самых частых ошибок конфигурации сервера, CMS и серверных скриптов.
• В SMTP некоторые категории писем (NDR, DSN) имеют пустой адрес envelope-from. Для таких писем аутентификация производится по домену, который SMTP-сервер отправителя использует в команде HELO/EHLO и который, как правило, совпадает с каноническим именем сервера. Некорректные имена в команде HELO — это еще одна распространенная проблема. Убедитесь, что доменное имя в HELO правильное, и пропишите для него соответствующую SPF политику например, mailserver.example.org. TXT "v=spf1 a -all". В сообщениях о невозможности доставки в адресе отправителя можно либо вообще не указывать домен (например From: mailer-daemon:;) или использовать домен, совпадающий с доменом HELO с точностью до домена организации (обычно это домен второго уровня, например From: Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript ).
• Не забывайте, что SPF не действует на поддомены. Необходимо внедрять его для каждого поддомена или прибегать к wildcards DNS.
• SPF имеет ограничение на 10 разрешений имен для одной записи. Поэтому следует минимизировать использование элементов, приводящих к дополнительным разрешениям, таких как mx и include. Например, для элемента mx требуется один дополнительный запрос на получение самой MX-записи и по одному запросу на каждый сервер в MX-записи для получения его IP-адреса по имени.

3. Опубликуйте DMARC-запись с политикой none для основного домена и поддоменов

Пример такой записи:

_dmarc.example.com. TXT "v=DMARC1;p=none;rua=mailto:
 Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
 ;ruf=mailto:
 Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
 ;fo=s"

Запись инструктирует получателя отправлять на адрес Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript ежедневные статистические отчеты. Из отчетов будут видны все IP-адреса, с которых производилась рассылка писем от имени вашего домена, и статус авторизации SPF, DKIM и DMARC для этих писем. Особенно внимательно следите за письмами с ваших IP-адресов. Проконтролируйте по отчетам, не упустили ли вы какие-то категории писем или их источники в своей ревизии. При необходимости скорректируйте SPF. Некоторые получатели могут слать отчеты по отдельным случаям проблем с SPF (fo=s) на адрес ruf, эти отчеты пригодятся для идентификации проблемных рассылок.

Типичные проблемы и рекомендации:

• Мы не советуем публиковать политику даже с тегом none до того, как для основных потоков писем будет внедрен хотя бы один из механизмов аутентификации SPF или DKIM.
• Запись должна начинаться именно с v=DMARC1, и регистр букв имеет значение.
• Некоторые клиенты DNS показывают обратные слеши перед точками с запятой v=DMARC1\;p=none — но в записях DNS-зоны обратный слеш добавлять, как правило, не требуется.
• Адреса rua/ruf должны принадлежать тому же организационному домену, для которого публикуется политика, либо принимающий домен должен опубликовать специальную политику, показывающую согласие на прием репортов. Не получится принимать репорты на адреса, например, публичных почт.
• Если вы еще не закончили внедрение DKIM, то вы будете получать достаточно много нарушений DMARC с IP-адресов публичных почт (Mail.Ru, Gmail, Hotmail/Outlook, Yahoo и т. п.). Это связано с тем, что пользователи данных сервисов часто используют перенаправления в другие ящики, и это приводит к нарушению аутентификации SPF. Устраняется проблема внедрением подписи DKIM.
• Есть неплохие инструменты для визуализации отчетов DMARC. Dmarcian предоставляет платные и бесплатные (для небольших объемов почты) сервисы, и удобный удобный бесплатный инструмент XML-To-Human Converter для просмотра DMARC-отчетов. Agari и proofpoint также предлагают коммерческие сервисы для внедрения и поддержки DMARC.

4. Внедрите DKIM

Рекомендации:

• Убедитесь, что генерируемые серверами письма соответствуют рекомендациям по структуре, кодировкам и количеству заголовков, иначе возможна ситуация, что при передаче почтовым релеем письмо будет изменено для приведения его в соответствие со стандартами (чаще всего происходит разбивка длинных строк), отчего нарушится DKIM-сигнатура.
• Используйте ключ длиной 1024 или 2048 бит.
• Убедитесь что ваш DNS-сервер поддерживает разрешение больших записей. Обычно для этого помимо доступа к серверу по порту UDP/53 необходимо дополнительно разрешить доступ по TCP/53. Убедитесь что TXT-запись с ключом DKIM корректно разрешается из внешних сетей.
• Используйте режим канонизации relaxed/relaxed, он реже приводит к проблемам, связанным с нормализацией письма при передаче.
• Не подписывайте заголовки, которые меняются при доставке письма (такие как Received: и Return-Path:), убедитесь, что обязательные заголовки (Date:, Message-ID:, From:) формируются до наложения DKIM-подписи
• Внедрите DKIM на всех источниках писем для всех поддоменов.
• Используйте отдельные селекторы с отдельными ключами для внешних источников (провайдеров услуг по рассылке почты), чтобы была возможность отозвать ключ при необходимости.
• Для DMARC необходимо, чтобы домен, используемый в DKIM-подписи, совпадал с точностью до организационного домена с доменом из заголовка From. При этом могут присутствовать и другие DKIM-подписи, но они будут игнорироваться.
• Контролируйте внедрение DKIM по статистическим отчетам от внешних сервисов.
• Используйте fo=1 в политике DMARC, это позволит получать forensic-репорты по всем проблемам с SPF и DKIM, даже для писем, проходящих авторизацию DMARC.

5. Начните переключение на строгую политику

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

Можно начать с включения политики reject на 10% (p=reject; pct=10), чтобы отследить потенциальные проблемы по ошибкам доставки. Но долго держать такую политику не рекомендуется: на оставшиеся 90 % срабатываний будет применяться политика quarantine, и можно пропустить единичные проблемы.

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

Можно внедрять политику, отличную от политики основного домена, на отдельные поддомены, публикуя для них отдельные политики или указав в политике основного домена (p=none; sp=reject): политика sp будет действовать на поддомены, которые не публикуют собственную политику.

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

6. Тюнинг политики DMARC

Ниже приведен разбор некоторых необязательных полей DMARC-записи, примеры и рекомендации по их использованию.

p (p=reject) — политика DMARC. Указывает получателю, как поступать с письмами, не проходящими аутентификацию. Может принимать значения none (доставлять письма получателю), quarantine (доставлять письма в папку «Спам») и reject (не принимать письма).

sp (sp=quarantine) — политика для поддоменов, не публикующих самостоятельной политики. Если поддомен имеет собственную политику DMARC, то sp на него не влияет. При отсутствии поля sp в записи DMARC для поддоменов, не имеющих собственной политики, применяется политика из поля p.

pct (pct=20) — процент писем, на которые действует данная политика. Например, при задании политики reject с pct=20 к полученному письму с вероятностью 20 % будет применена политика reject и с вероятностью 80 % — политика quarantine.

rua (rua=mailto: Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript ) — адрес, на который получатели будут отправлять аггрегированный (статистический) отчет. Адрес должен принадлежать тому же организационному домену. Мы рекомендуем обязательно публиковать адрес для аггрегированных отчетов и следить за ними как минимум на этапе внедрения политики DMARC.

ruf (ruf=mailto: Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript ) — адрес, на который будут отправляться forensic-отчеты (т. е. исследовательские) по отдельным письмам. По умолчанию forensic-репорты отправляются только по нарушениям DMARC. Можно использовать опцию fo для регулирования поведения. В настоящее время относительно небольшое количество получателей отправляет forensic-отчеты.

fo (fo=1) — по каким нарушениям отправлять уведомления. fo=0 (поведение по умолчанию) отправляет отчеты, только когда не прошли обе аутентификации: SPF и DKIM. fo=1 — когда не проходит любая из аутентификация, даже если проходит альтернативный метод. fo=s шлет forensic-репорты на проблемы с SPF-аутентификаций. fo=d — на проблемы DKIM.

adkim (adkim=r) — режим проверки соответствия DKIM-домена. По умолчанию используется режим r (relaxed) и должен совпадать только организационный домен. В строгом (s) режиме требуется полное совпадение домена из адреса отправителя с доменом из DKIM-сигнатуры. Имеет смысл использовать строгое соответствие домена, если часть ваших поддоменов делегирована недоверенным сторонам.

aspf (aspf=r) — аналогично для домена из envelope-from, для которого проверяется SPF и From. При aspf=s эти домены должны полностью совпадать для прохождения аутентификации SPF.

ri (ri=86400) — желательный интервал получения аггрегированных отчетов (в секундах). По умолчанию отчеты отправляются раз в сутки, но некоторые получатели (не все, т.к. поддержка данного параметра сервером не является обязательной) поддерживают отправку отчетов с более короткими интервалами. На этапе внедрения политики можно попробовать использовать меньшие ri, например ri=3600.

Источник - https://habr.com/ru/companies/vk/articles/315778/