Кто-то отправляет фишинговые письма, которые выглядят так, будто они от вашей компании. Ваши клиенты их получают. Вы сделали всё правильно — SPF, DKIM, DMARC с p=reject, весь аппарат — и письма всё равно приходят.
Это один из самых обескураживающих моментов в безопасности почты, потому что стандартный совет уже выполнен, и он не сработал. Это не потому, что вы что-то неправильно настроили. Это потому, что большинство объяснений DMARC тихо умалчивают, что он не покрывает, а разрыв намного шире, чем люди ожидают.
Вот как на самом деле работает спуфинг, что ваша защита реально останавливает, и чего она никогда не была предназначена касаться.
SMTP был построен на системе чести
Причина, по которой спуфинг вообще возможен, сводится к конструктивному решению 1982 года. SMTP, протокол, перемещающий электронную почту, не имеет встроенной концепции доказательства того, кто вы есть. Вы подключаетесь к почтовому серверу и заявляете, кто вы. Сервер принимает ваше слово.
Хуже того — есть два отдельных поля «от», и они не имеют друг к другу никакого отношения.
Отправитель конверта. Это часть самого разговора SMTP, отправленная в команде MAIL FROM. Используется для обработки отказов — куда возвращаются ошибки. Получатель никогда его не видит.
Заголовок From. Это строка внутри содержимого сообщения, и именно её отображает почтовый клиент. Это то, на что реально смотрят ваши пользователи.
Эти два поля устанавливаются независимо, и ничего в протоколе не требует, чтобы они совпадали. Это не баг — легитимные сервисы постоянно полагаются на это. Ваш провайдер рассылок устанавливает отправителя конверта на собственный адрес обработки отказов, пока заголовок From показывает ваш бренд. Списки рассылки делают то же самое. Это нормально.
Но это также означает: любой может поставить что угодно в заголовок From. Ввести и отправить. Протоколу всё равно. Это и есть всё это целиком. Подмена домена — не эксплойт и не уязвимость, это SMTP, работающий как задумано.
Неудобная правда о SPF
Именно здесь ломается большинство понимания.
SPF проверяет отправителя конверта. Не заголовок From.
Прочитайте это снова, потому что это влечёт последствие, которое люди находят по-настоящему удивительным: злоумышленник может отправить вам сообщение с идеально проходящим результатом SPF и полностью подделанным видимым адресом From. Он просто устанавливает отправителя конверта на домен, которым легитимно владеет, с валидной SPF-записью, и устанавливает заголовок From на ваш.
SPF проходит. Он не лжёт — сообщение действительно пришло с сервера, авторизованного для домена конверта. SPF ответил на вопрос, который ему задали, правильно. Вопрос просто был не тем, который имел значение.
SPF сам по себе практически не даёт защиты от видимого спуфинга домена. Домен с безупречной SPF-записью и без DMARC широко открыт. Именно поэтому «у нас есть SPF» не является ответом на «может ли кто-то нас подделать».
У DKIM есть зеркальный пробел: он доказывает, что сообщение подписано каким-то доменом и не было изменено, но валидная подпись от attacker-domain.example на сообщении, утверждающем, что оно от вас, всё равно является валидной подписью.
DMARC — это та часть, что закрывает оба пробела, требуя выравнивания: домен, прошедший SPF или DKIM, должен совпадать с доменом в видимом From. Это и есть реальная защита. SPF и DKIM — входные данные; выравнивание — механизм.
Если вы не уверены, где сейчас находится ваш домен, проверка опубликованных записей SPF, DKIM и DMARC — это двухминутное упражнение, и типичная находка — домен с SPF и без политики DMARC, который ощущается защищённым, но не является таковым.
Что DMARC при p=reject реально останавливает
Отдадим должное. С p=reject и работающим выравниванием вы закрыли спуфинг точного домена. Никто не может отправить почту с @yourdomain.com в видимом From и получить её принятие любым получателем, соблюдающим DMARC. Это реальная и значительная победа, и это единственный самый ценный контроль безопасности почты, доступный в принципе.
Это также даёт вам видимость. Агрегированные отчёты показывают вам каждый источник, пытающийся отправить от вашего имени.
Теперь часть, о которой говорят недостаточно.
На что DMARC вообще никак не влияет
Спуфинг отображаемого имени. Это большая проблема, и она полностью обходит DMARC.
У строки From письма есть две части: отображаемое имя и адрес. Почтовые клиенты показывают отображаемое имя заметно и часто вообще скрывают адрес — особенно на мобильных устройствах, где места на экране мало.
Так что злоумышленник отправляет:
From: Ramil Mastiyev <billing@totally-unrelated-domain.example>Ваш получатель видит «Ramil Mastiyev». Это всё. Это то, что на экране.
А DMARC? DMARC оценивает totally-unrelated-domain.example — реальный домен From. Злоумышленник владеет им, правильно настроил SPF и DKIM, и DMARC проходит. Чисто. Ваша политика неактуальна, потому что вашего домена вообще нет в поле From. Он в текстовой метке, на которую DMARC не смотрит, а пользователи не могут перестать читать.
Ваша политика p=reject не провалилась здесь. Она просто не была задействована. Это самая распространённая форма компрометации деловой переписки, и каждая конфигурация DMARC на земле слепа к этому.
Домены-двойники. Злоумышленник регистрирует rnarinadns.io (это r-n, не m) или yourdomain.co, или your-domain.com. Затем он настраивает на нём SPF, DKIM и DMARC — правильно, потому что хочет, чтобы его фишинг аутентифицировался. Всё проходит, для его домена, что и есть именно то, что стандарты предполагают.
DMARC защищает домен. Он ничего не говорит о доменах, которые просто похожи на него. Нет механизма для «это похоже на чужой», потому что его и не могло быть.
Скомпрометированные легитимные аккаунты. Если у злоумышленника есть валидные учётные данные для реального почтового ящика на вашем домене, всё, что он отправляет, аутентифицируется идеально. Это реально от вас. Каждая проверка проходит, потому что каждая проверка должна пройти. Аутентификация почты отвечает на вопрос «пришло ли это от авторизованного отправителя» — а скомпрометированный аккаунт и есть авторизованный отправитель.
Спуфинг поддомена, если вы оставили дверь открытой. У DMARC есть отдельный тег политики поддомена, sp=. Если вы установили p=reject, но никогда не установили sp=, поддомены наследуют политику родителя — обычно нормально. Но если вы установили sp=none (или это сделал шаблон провайдера), то invoices.yourdomain.com не защищён, пока родитель выглядит запертым. Стоит проверить, что на самом деле публикует ваша запись, а не то, что вы думаете, что она публикует.
Защита от пробелов
Поскольку DMARC структурно не может это покрыть, вам нужны другие инструменты:
Для доменов-двойников: следите за логами Certificate Transparency. Это самая недоиспользуемая система раннего предупреждения в безопасности. Каждый публично доверенный TLS-сертификат логируется публично в момент выпуска. Фишинговым операциям нужен HTTPS, чтобы выглядеть легитимно — поэтому они получают сертификат, и он попадает в публичный лог до того, как они что-либо отправляют.
Поиск в логах CT сертификатов, выданных для имён, похожих на ваш домен, выявит двойника ещё на этапе настройки, обычно за дни до запуска кампании. Вы получаете заблаговременное предупреждение об атаке, которая ещё не произошла, из публичного набора данных, бесплатно. Делайте это периодически — это один из немногих контролей, который вообще ловит двойников.
Для спуфинга отображаемого имени: это в основном проблема клиента и обучения. Некоторые почтовые провайдеры теперь помечают отображаемые имена, не совпадающие с известными контактами. Помимо этого, всё сводится к тому, знают ли ваши люди проверять реальный адрес, а не метку — что является по-настоящему сложной просьбой на телефоне.
Для скомпрометированных аккаунтов: это безопасность идентификации, а не аутентификация почты. MFA, мониторинг учётных данных, обнаружение аномалий в паттернах отправки. Ничто в DNS вам здесь не поможет.
Для входящей подозрительной почты: читайте заголовки. Когда сообщение, претендующее на то, что оно от вас (или от поставщика, или банка), доходит до кого-то и что-то кажется не так, сырые заголовки решают вопрос. Анализатор заголовков письма покажет, что на самом деле аутентифицировалось, для какого домена, и совпадает ли прошедший домен с видимым — что и есть именно то различие, на котором строится атака, рассчитывая, что вы не будете проверять.
Честное резюме
| Атака | Останавливает ли DMARC? |
|---|---|
Спуфинг точного домена (@yourdomain.com в From) |
Да, при p=reject |
Спуфинг отображаемого имени (Ваше Имя <attacker@elsewhere>) |
Нет — другой домен, проходит собственный DMARC |
Домен-двойник (yourdomaln.com) |
Нет — это другой домен со своей собственной валидной политикой |
| Скомпрометированный аккаунт на вашем домене | Нет — он аутентифицируется, потому что он реальный |
| Спуфинг поддомена | Только если sp= установлен правильно |
DMARC при p=reject необходим, ценен и стоит усилий. Это не решение проблемы фишинга. Он закрывает одну конкретную дыру — ту, где кто-то помещает ваш точный домен в поле From — и эта дыра была стоящей того, чтобы её закрыть.
Но когда кто-то говорит вам, что он «решил проблему спуфинга» с помощью DMARC, то, что он на самом деле сделал — это заставил злоумышленников использовать четыре техники выше вместо этого. Что является прогрессом. Просто это не конец разговора, и разрыв между «DMARC развёрнут» и «мы защищены от фишинга» — это то место, где сейчас живёт большинство успешных атак.