Мне удалось подтвердить, что злоумышленники отправляют электронные письма с несуществующих поддоменов основного домена моей компании.
Скажем, мой основной домен - foo.com. Электронная почта отправляется из этого базового домена из моей собственной почтовой системы. Благодаря партнерским отношениям с поставщиком службы поддержки, компанией электронной коммерции (витрины) и поставщиком CX / NPS, у меня также есть три действительных уникальных поддомена, с каждого из которых поступает электронная почта (shop.foo.com, support.foo.com, и feedback.foo.com.
У меня есть полный DMARC с DKIM для всех 4. С неоценимой помощью DMARCian (служба агрегирования отчетов и отчетов DMARC) я подтвердил, что существует несколько источников повторяющейся электронной почты из других поддоменов, которых не существует. Например, какой-то неавторизованный и неизвестный объект в VN отправляет электронную почту с news.foo.com и enews.foo.com. Другой источник - рассылка с sales.foo.com. Последнее особенно беспокоит, потому что содержание нескольких электронных писем от этого злоумышленника, которые нам переадресовали, наносит серьезный ущерб моей компании (мы думаем, что за ним стоит иностранный конкурент на нашей жесткой рыночной нише).
К сожалению, мои текущие политики DMARC - либо мониторинг, либо карантин; Я не могу использовать политику отказа (это еще одна битва).
Я рассматриваю возможность создания записей SFP и DMARC для этих несуществующих поддоменов без разрешенных отправителей и политики отклонения.
Я не уверен, насколько это было бы эффективно. Я также не могу придумать никаких недостатков, кроме небольшой дополнительной работы по его настройке и последующему обслуживанию, когда злоумышленники начинают использовать различные поддельные поддомены. Мы всегда на шаг отстаем от плохих парней, а?
Итак ... есть ли какие-то недостатки в том, что я собираюсь сделать, о которых я не думал? Как вы думаете, оно того стоит? Или есть лучший подход к борьбе с этими поддельными поддоменами?
Основная проблема здесь в том, что борьба с подделкой электронной почты - это работа и отправителя, и получателя. Если получатель принимает почту с несуществующих имен хостов, скорее всего, он также не будет проверять SPF, DKIM или DMARC. Кроме того, путь добавления этих записей был бы бесконечным, если бы они были необходимы.
Вы утверждаете, что у вас есть полный DMARC, но p=none или даже p=quarantine не полностью обеспечивают соблюдение политик DMARC. Если вы не можете применить строгую политику для своего домена, но можете сделать это для подчиненных, sp тег (RFC 7489, 6.3) может вам помочь.
sp: Запрошенная политика получателя почты для всех поддоменов (обычный текст; НЕОБЯЗАТЕЛЬНО). Указывает политику, которую должен применить Получатель по запросу Владельца домена. Это относится только к поддоменам запрашиваемого домена, но не к самому домену. Его синтаксис идентичен синтаксисуpтег, определенный выше. Если отсутствует, политика, указанная вpтег ДОЛЖЕН применяться для поддоменов. Обратите внимание, чтоspбудет игнорироваться для записей DMARC, опубликованных на поддоменах организационных доменов, из-за эффекта механизма обнаружения политик DMARC, описанного в Раздел 6.6.3.
Как вы сказали, у вас есть DKIM для всех поддоменов, отправляющих почту, ваша политика может быть, например,
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; sp=reject;"
Если у вас есть поддомены, которые вы используете для отправки почты, но не можете использовать reject, вы можете переопределить sp=reject с явной менее строгой политикой для поддомена:
_dmarc.no-dkim.example.com. IN TXT "v=DMARC1; p=quarantine;"
Предположим, получатель не будет принимать электронную почту от несуществующих имен хостов, как и должно быть. Поскольку SPF не наследуется, как DMARC, вам понадобится соответствующий SPF TXT запись для каждого существующего A запись. Если вы не собираетесь отправлять почту из sub.example.com вообще, это будет:
sub.example.com. IN TXT "v=spf1 -all"
Или, если бы сам хост мог отправлять почту с @sub.example.com:
sub.example.com. IN TXT "v=spf1 +a -all"
вы можете настроить SPF -все и DMARC отвергать политика для этих идентифицированных поддельных поддоменов, чтобы предотвратить попадание поддельных писем в те почтовые ящики ESP, которые проверяют SPF / DMARC. Но это не долгосрочное решение.
Имеет смысл поработать над перемещением всего домена на отклонение, если это возможно. Я полностью понимаю эту проблему, поскольку я работаю в мире DMARC последние 4+ года. Могу я как-нибудь помочь с этим?
Кстати, вот хороший инструмент, который поможет вам проверить, как разные ESP обрабатывают поддельные электронные письма, поступающие из домена, защищенного с помощью DMARC. отвергать -> https://dmarc-tester.com.
Например. Microsoft помещает поддельные письма в спам, Яндекс не поддерживает DMARC, поэтому помещайте их во входящие
Ты можешь сделать p=quarantine;sp=reject для вашего платного домена (который DMARC вызывает Организационный домен), а затем создайте индивидуальный p=quarantine записи для поддоменов, на которые вы хотите отправлять почту.
sp=reject указывает на subdomain полицетворение отвергать почта без выровнен SPF или DKIM. Он заменяется любой записью DMARC для точного FQDN субдомена, поэтому требуются отдельные записи, указанные выше.
Как вы предложили, в качестве альтернативы вы можете создать DMARC p=reject записи для каждого обнаруженного недопустимого домена, как указано в ваших отчетах DMARC, хотя это может показаться бить крота если эти поддельные имена хостов регулярно меняются.
Боковое примечание: авторизация SPF (или проверка DKIM) нужна только для того, чтобы проходить DMARC. Если вы просто хотите отказаться от всего, вам не нужны ни SPF, ни DKIM:
Домен без SPF или DKIM всегда будет активировать свою политику DMARC.
В более общем случае, когда у вас есть произвольные поддомены, которым необходимо отправлять почту, допустимую для DMARC, несмотря на злоупотребления со стороны других произвольных поддоменов (независимо от того, существуют ли они), вы можете контролировать исходящую почту с помощью Смарт-хост SMTP что DKIM-подписывает отправляемую почту. С помощью расслабленный DMARC выравнивание, письмо с From заголовок, использующий рассматриваемый домен (или любой поддомен), будет заблокирован DMARC, если он не подписан этим интеллектуальным хостом или другой настройкой DKIM или SPF.
Ваша цель - создать такую запись DMARC *:
v=DMARC1;p=reject;sp=reject;adkim=r;rua=blah@dmarcian.com;
* Обратите внимание, что вы не можете начать с reject политики! Вы должны начать с p=none;sp=none или p=quarantine;sp=quarantine и просматривать отчеты, поступающие на rua= адрес, чтобы убедиться, что вы не блокируете легальную почту.
sp=reject (что подразумевается p=reject но мы делаем это явным для ясности) гарантирует, что subdomain пolicy по умолчанию reject если у этого поддомена нет собственной записи DMARC.
adkim=r (который используется по умолчанию, но здесь снова явно присутствует для ясности) гарантирует, что соответствие авыравнивание для DKIM возможно рelaxed (достаточно сопоставления по домену платного уровня; см. ссылки выше для упрощенного сопоставления).
Установите выделенный почтовый ретранслятор, через который должна проходить вся почта поддоменов. Этот почтовый ретранслятор должен аутентифицировать своих пользователей, чтобы избежать открытое реле вопросы. Он также предлагает возможность переключаться между различными Селекторы DKIM для каждой учетной записи, что позволяет вам контролировать несколько доменов платного уровня с надлежащим разделением.
Поскольку все действительные поддомены независимо передают DMARC или отправляют почту через согласованный смарт-хост с DKIM-подписью, вы должны быть в безопасности при обновлении до p=reject;sp=reject, но вы должны некоторое время наблюдать за отчетами DMARC, прежде чем вносить это изменение.