- PVSM.RU - https://www.pvsm.ru -
A Thief on the Run [1] by Manweri
Привет! В этом посте мы снова поговорим о проблеме подделки отправителя (или так называемом спуфинге). В последнее время такие случаи очень участились: подделывается все: письма со счетами за ЖКХ, из налоговой инспекции, банков и так далее. Решить эту проблему помогает настройка строгой DMARC-политики. Мы как почтовая служба проверяем все приходящие к нам письма на DMARC начиная с февраля 2013 года. Мы были первым в рунете почтовым сервисом [2], поддержавшим стандарты DMARC. Однако чтобы минимизировать число поддельных писем, этого, к сожалению, недостаточно. Главное, чтобы строгий DMARC был поддержан на стороне отправителя. Вот почему мы не устаем качать эту тему, ведем активную разъяснительную работу и всячески призываем всех включать у себя строгий DMARC.
Позитивные сдвиги уже есть: с каждым месяцем мы видим прирост числа корпоративных отправителей, прописавших DMARC, на десятки процентов. Однако безусловно, еще есть над чем работать. Практика показывает, что IT-культура находится на очень разном уровне. Кто-то слышал краем уха про DMARC, но пока не собирается его внедрять. Есть и такие, для кого факт, что в транспортных протоколах электронной почты отсутствует какая-либо проверка и защита адреса отправителя, до сих пор является настоящим откровением. Кроме того, поддержка DMARC — задача непростая. Только на первый взгляд кажется, что достаточно опубликовать запись в DNS, и не требуется никакого дополнительного софта или технических средств (подробнее в нашей статье DMARC: защитите вашу рассылку от подделок [3]). На практике в крупной компании с многочисленными потоками электронной почты и развесистой структурой почтовых доменов все гораздо сложнее. И есть моменты, которые следует предусмотреть и продумать заранее. Именно для таких сложных случаев мы написали эту статью, постаравшись собрать в ней все нюансы.
Мы хотим поделиться собственным опытом внедрения DMARC и всеми граблями, на которые мы наступили (зачеркнуто) теми рекомендациями, которые мы выработали при взаимодействии с крупными компаниями и государственными учреждениями. Мы рассмотрим только внедрение политики DMARC для защиты доменного имени. Внедрение серверной части DMARC для защиты пользователей корпоративного почтового сервера от поддельных писем — это отдельный, совершенно самостоятельный и независимый процесс.
DMARC — это политика действий с пришедшими письмами, у которых в поле From используется публикующий политику домен. DMARC позволяет не только указать, как поступать с такими письмами, но и собрать статистику от всех получателей, поддерживающих серверную часть DMARC.
Основной проблемой является то, что DMARC требует авторизации всех легитимных писем. А для этого необходимо не просто внедрить методы авторизации (в качестве базовых протоколов используются SPF и DKIM), но и добиться того, чтобы для всех без исключения легитимных писем с обратными адресами домена проходила авторизация. Поэтому внедрение DMARC стоит начинать с нижеследующего пункта.
Типичные упущения в этом процессе:
Для каждой категории писем необходимо внедрить SPF и выяснить возможность или невозможность подписи писем с использованием DKIM.
Часто можно услышать, что SPF защищает адрес отправителя от подделки. Это не так. SPF контролирует только адрес SMTP-конверта, который не видит пользователь. При этом большое количество доменов до сих пор не внедрили его, и многие стороны не поддерживают переадресацию почты, совместимую с SPF. По этой причине чаще всего используется нейтральная политика SPF (neutral, ?
) или мягкое блокирование (soft reject, ~
). Для совместного использования с DMARC не имеет значения, какая именно дефолтная политика (neutral ?
, soft reject ~
или reject -
) SPF будет использована. Мы не рекомендуем использовать политику reject (-
) за исключением особо требовательных к безопасности доменов, так как это может негативно сказаться на доставке легитимных писем непрямыми способами, например через пересылки или списки рассылки. Хотя большая часть получателей не блокирует письма по SPF даже при публикации строгой политики, а использует SPF в рамках весовых классификаторов. Вопреки устоявшемуся мнению, именно такой режим SPF чаще всего применяется на практике, и он полностью соответствует рекомендациям стандарта.
Можно дать следующие рекомендации по внедрению SPF:
mailserver.example.org. TXT "v=spf1 a -all"
. Проверьте, что в сообщениях о невозможности доставки не используется домен или используется домен, совпадающий с доменом HELO с точностью до второго уровня.
mx
и include
. Например, для элемента mx
требуется один дополнительный запрос на получение самой MX-записи и по одному запросу на каждый сервер в MX-записи для получения его IP-адреса по имени.Пример такой записи:
_dmarc.example.com. TXT "v=DMARC1;p=none;rua=mailto:rua@example.com;ruf=mailto:ruf@example.com;fo=s"
Запись инструктирует получателя отправлять на адрес rua@example.com
ежедневные статистические отчеты. Из отчетов будут видны все IP-адреса, с которых производилась рассылка писем от имени вашего домена, и статус авторизации SPF, DKIM и DMARC для этих писем. Особенно внимательно следите за письмами с ваших IP-адресов. Проконтролируйте по отчетам, не упустили ли вы какие-то категории писем или их источники в своей ревизии. При необходимости скорректируйте SPF. Некоторые получатели могут слать отчеты по отдельным случаям проблем с SPF (fo=s
) на адрес ruf
, эти отчеты пригодятся для идентификации проблемных рассылок.
Типичные проблемы и рекомендации:
none
до того, как для основных потоков писем будет внедрен хотя бы один из механизмов аутентификации SPF или DKIM.v=DMARC1;p=none
— но в записях DNS-зоны обратный слеш добавлять, как правило, не требуется.Рекомендации:
fo=1
в политике DMARC, это позволит получать forensic-репорты по всем проблемам с SPF и DKIM, даже для писем, проходящих авторизацию DMARC.Не используйте подолгу политику quarantine, так как она может маскировать имеющиеся проблемы. Обязательно следите за журналами сервера и отчетами о невозможности доставки писем на предмет ошибок, связанных с DMARC. Стандарт рекомендует получателям, внедряющим серверную часть DMARC, обязательно указывать его как причину в сообщении об ошибке, поэтому для идентификации проблемы можно использовать «DMARC» как ключевое слово в сообщении об ошибке. По журналам сервера вы увидите проблему гораздо раньше, чем по отчетам.
Можно начать с включения политики на 10% (p=reject; pct=10
), чтобы отследить потенциальные проблемы по ошибкам доставки, так как агрегированные репорты приходят только спустя некоторое время. Но долго держать такую политику не рекомендуется: на оставшиеся 90 % срабатываний будет применяться политика quarantine, и можно пропустить единичные проблемы.
Можно внедрять политику, отличную от политики основного домена, на отдельные поддомены, публикуя для них отдельные политики или указав в политике основного домена (p=none; sp=reject
): политика sp будет действовать на поддомены, которые не публикуют собственную политику.
Когда все поддомены будут переведены на строгую политику, можно убрать политики поддоменов — или же оставить, на ваше усмотрение. Влияет это только на генерацию репортов в соответствии со сложившейся практикой (в стандарте данный момент не обговорен). Если поддомен публикует свою политику, на нее станут приходить отдельные репорты; если отдельной политики нет, то отчеты по поддомену будут включаться в отчет родительского домена.
Ниже приведен разбор некоторых необязательных полей 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:ruamailbox@example.com
) — адрес, на который получатели будут отправлять аггрегированный (статистический) отчет. Адрес должен принадлежать тому же организационному домену. Мы рекомендуем обязательно публиковать адрес для аггрегированных отчетов и следить за ними как минимум на этапе внедрения политики DMARC.
ruf (ruf=mailto:rufmailbox@example.com
) — адрес, на который будут отправляться 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
.
Мы очень рады, что владельцы доменов начали задумываться о защите своего доменного имени в электронной переписке. Если у вас есть вопросы или вам требуются советы либо помощь с настройкой SPF, DKIM, DMARC, обращайтесь по адресу dmarc_support@corp.mail.ru [11] или задайте вопрос здесь. Мы надеемся, что вместе сможем сделать электронную почту безопасней для всех пользователей.
Автор: Mail.Ru Group
Источник [12]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/dns-2/212500
Ссылки в тексте:
[1] A Thief on the Run: http://manweri.deviantart.com/art/A-Thief-on-the-Run-577760957
[2] первым в рунете почтовым сервисом: https://corp.mail.ru/ru/press/releases/8736/
[3] DMARC: защитите вашу рассылку от подделок: https://habrahabr.ru/company/mailru/blog/170957/
[4] NDR: https://ru.wikipedia.org/wiki/%D0%92%D0%BE%D0%B7%D0%B2%D1%80%D0%B0%D1%89%D1%91%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D0%B8%D1%81%D1%8C%D0%BC%D0%BE
[5] DSN: https://tools.ietf.org/html/rfc1894
[6] wildcards DNS: https://en.wikipedia.org/wiki/Wildcard_DNS_record
[7] Dmarcian: https://dmarcian.com/
[8] XML-To-Human Converter: https://dmarcian.com/dmarc-xml/
[9] Agari: https://www.agari.com/
[10] ReturnPath: https://returnpath.com/
[11] dmarc_support@corp.mail.ru: mailto:dmarc_support@corp.mail.ru
[12] Источник: https://habrahabr.ru/post/315778/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.