На разборе учебной рассылки мне показали письмо, отправленное от адреса компании ей же самой. Оно дошло во «Входящие». Без пометок, без папки «Спам», с правильным именем отправителя в списке писем.
Первое, что я подумал, - что-то не настроено. Полез в DNS: SPF на месте, ключ DKIM опубликован, подписи ставятся. Запись DMARC тоже нашлась. Всё, что положено, - есть.
Оказалось, что настроено всё правильно и работает как задумано. Просто задумано не то, что от этого ждут, - а в записи DMARC стояло значение, которое ничего не запрещает.
SPF проверяет не тот адрес, который вы видите
В письме два разных адреса отправителя, и это не ошибка, а устройство протокола.
Первый - конвертный, он же MAIL FROM, он же Return-Path. Его сообщает отправляющий сервер во время SMTP-сессии, и туда уходят уведомления о недоставке. Пользователь его не видит.
Второй - заголовок From внутри самого письма. Именно он показан в почтовом клиенте.
SPF - это список серверов, которым разрешено отправлять почту от домена. Проверяется по нему конвертный адрес. На заголовок From SPF не смотрит вообще.
Отсюда и весь фокус: отправитель ставит конвертный адрес на своём домене, где SPF, разумеется, проходит, а в заголовок From пишет ваш адрес. Проверка успешна и не про то.
Одна оговорка: при пустом конвертном адресе - так отправляются уведомления о недоставке - SPF проверяет имя, которым сервер представился в команде HELO.
DKIM устроен иначе: он подписывает заголовки и тело, и From в подпись обычно входит. Но DKIM отвечает только на вопрос «подпись верна», а не на вопрос «а тот ли домен подписал». Письмо, подписанное доменом атакующего и содержащее From с вашим доменом, - это письмо с корректной подписью.
То есть обе проверки отрабатывают штатно и обе оставляют заголовок From без внимания. Не потому, что недоработаны, - просто этот заголовок не входит в область их проверки.
Связывает их DMARC
Он добавляет к этому одно условие: домен, по которому прошла проверка, должен совпадать с доменом в заголовке From. Это совпадение называют выравниванием (alignment), и именно его в SPF и DKIM по отдельности нет.
Важная деталь, которую при чтении обычно пропускают: нужны не обе проверки сразу. Письмо проходит DMARC, если хотя бы одна из двух и прошла, и оказалась выровнена с доменом из From.
И второе, что делает DMARC: говорит принимающей стороне, что делать с письмом, которое условие не выполнило. Запись лежит в DNS и читается одной командой:
$ dig +short TXT _dmarc.github.com "v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1"
p= - политика для самого домена: none, quarantine или reject. sp= - отдельная политика для поддоменов. rua= - адрес для сводных отчётов. ruf= - адрес для подробных отчётов по отдельным письмам; в них попадают фрагменты чужой переписки, поэтому включать его стоит осознанно.
Отдельно про pct=. Это доля писем, к которым применяется политика. pct=100 означает «ко всем». А вот pct=20 при p=reject означает не то, что кажется: к четырём письмам из пяти применится не reject, а следующая по мягкости политика, то есть quarantine. Отвергнуты они не будут. Значение по умолчанию - 100, но его часто занижают на время внедрения и забывают вернуть.
И ещё два параметра - adkim и aspf - задают строгость выравнивания. По умолчанию r (relaxed) - сверяются организационные домены, то есть подпись example.com выравнивается и с адресом mail.example.com в From. Значение s (strict) требует точного совпадения.
p=none - это не защита
Вот здесь и была причина. У домена стояло p=none.
p=none означает буквально: «проверяйте, присылайте мне отчёты, но письмо доставляйте как обычно». Никакой фильтрации. Запись есть, отчёты идут, панель мониторинга рисует зелёное - а письмо от вашего имени доходит во «Входящие».
Режим этот придуман не зря: включать reject вслепую опасно. У любой компании почта уходит не только с основного почтового сервера - рассылки, счета из бухгалтерской программы, уведомления от систем мониторинга, письма от сервиса поддержки. Часть из них шлётся так, что выравнивания нет, и переход на reject их убивает. Поэтому p=none - это стартовая позиция, из которой смотрят отчёты и чинят своих отправителей.
Проблема в том, что на стартовой позиции остаются годами. Пункт «настроить DMARC» в чек-листе закрыт, а защиты нет.
Поддомены проверяются не тем параметром, о котором думают
Тонкость, на которой ловятся и те, кто дошёл до reject. Политика поддоменов задаётся параметром sp=. Если его нет, поддомены наследуют p=. А если он есть и в нём none, то все поддомены, у которых нет собственной записи _dmarc, остаются без защиты:
v=DMARC1; p=reject; sp=none;
Для атакующего разницы почти никакой: адрес noreply@mail.вашдомен выглядит для получателя ровно так же убедительно, как noreply@вашдомен. Проверять sp= надо отдельно, потому что своей записи у поддомена обычно нет и в выводе dig для него будет пусто - а пусто здесь означает «действует правило родителя», а не «ничего не настроено».
Домен, с которого не шлют писем
Отдельный случай - домены, которые вообще не отправляют почту: припаркованные, купленные на будущее, оставшиеся от старого бренда. Их регулярно забывают, и они удобны для подделки именно потому, что настоящей почты с них нет и жалоб не будет.
Для них есть готовая конфигурация, и она видна на example.com:
$ dig +short TXT example.com | grep spf "v=spf1 -all" $ dig +short TXT _dmarc.example.com "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s" $ dig +short TXT '*._domainkey.example.com' "v=DKIM1; p=" $ dig +short MX example.com 0 .
v=spf1 -all - отправлять не может никто. p=reject вместе с sp=reject и строгим выравниванием - отвергать и за домен, и за поддомены.
Запись DKIM здесь стоит на маске *._domainkey, и это принципиально: пустой p= отзывает ключ только того селектора, для которого запись опубликована. Поставив её на selector1, вы закроете подделку ровно под selector1 и оставите открытыми все остальные имена селекторов.
Последняя строка - нулевая MX-запись: одна точка вместо имени сервера означает «этот домен почту не принимает». Четыре записи. Ставятся один раз, обслуживания не требуют.
Что этим не закрывается
DMARC защищает ваш домен в заголовке From. Он ничего не может сделать с похожим доменом: вашдомен-support.com, вашдомен.co, а также с именем, в котором одна из букв заменена на визуально неотличимую из другого алфавита - на странице такой подмены не видно вовсе, в этом и смысл приёма. У таких доменов свой DMARC и свои валидные подписи, и с точки зрения протокола всё в порядке.
Он не влияет на отображаемое имя. Строка From: "Иван Петров, финансовый директор" <noreply@чужойдомен.com> - валидна, и во многих клиентах на телефоне видно только «Иван Петров, финансовый директор».
Он не помогает, если письмо пришло с настоящего взломанного ящика внутри вашей же компании.
И он ничего не решает во внутренней пересылке: письмо, попавшее внутрь и пересланное через список рассылки, обычно теряет выравнивание, поэтому у списков рассылки есть свои механизмы, и с ними придётся разбираться отдельно.
Порядок внедрения
Опубликовать запись с p=none и адресом для отчётов. Отчёты приходят в XML, читать их глазами тяжело - нужен любой разборщик, свой или готовый.
Смотреть отчёты и находить в них своих отправителей, которые не проходят выравнивание. Агрегированные отчёты приходят раз в сутки, и на сбор картины уходит от пары недель в небольшой компании до квартала в тех, где есть сезонные рассылки. Их всегда больше, чем ожидаешь: почти в каждой компании есть система, про которую никто не помнил, что она шлёт письма.
Починить их. Достаточно, чтобы у каждого отправителя работал хотя бы один выровненный механизм: либо он попадает в ваш SPF, либо подписывает письма ключом вашего домена. Только после этого двигать политику. Переходить сначала на quarantine, а не сразу на reject.
И отдельно, сразу и без ожидания, - закрыть теми же четырьмя записями все домены, с которых почта не отправляется. Там ждать нечего: ломать нечего.
Что посмотреть у себя
Прочитать свою запись _dmarc и посмотреть на значение p=. Если none - политика не применяется, и это главный вывод статьи.
Посмотреть, есть ли sp=. Нет - поддомены наследуют p=; есть со значением none - поддомены открыты.
Перебрать домены, которые числятся за компанией, и проверить каждый, а не только основной. Забытые домены как раз и остаются без записей.
Проверить, приходят ли отчёты по адресу из rua=. Ящик, который никто не открывал год, - обычное дело, и тогда p=none не даёт даже той пользы, ради которой его ставили.