Спуфинг почты как бороться
Конкуренты могут отправлять e-mail от вашего имени. Как сделать это невозможным? SPF, DKIM, DMARC — Защита от спуфинга
Любой конкурент или мошенник может подделать e-mail адрес отправителя и рассылать письма от вашего имени.
Как сделать это невозможным?
Есть бесплатный способ, который используют крупные компании. И вы можете также.
Как? Разбираемся с вопросами далее.
Проблематика
Поддельные письма по электронной почте получали практически все пользователи.
Spoofing attack — атака, при которой обманщик успешно маскируется под другого отправителя.
Spoof с английского переводится как обман.
Цели атак самые разные:
Почему? Технически протокол отправки электронной почты не предусматривает аутентификацию пользователей. А значит, нет способа устранить фальсификации на этапе отправки писем.
Никаких проблем нет разослать письма от имени support@google.com или support@yandex.ru. Только поддельные письма от Google или Яндекс блокируются на принимающем сервере.
Если подделать адрес отправителя обычной компании, которая не использует механизмы защиты, то риск успешного завершения атаки определенно есть.
Чтобы почтовые сервера блокировали поддельные письма от конкретного доменного имени надо просто выполнить комплекс мер по защите.
Механизмы защиты доступны для любого сайта бесплатно.
Если вопрос с защитой не решен, то ничего не мешает атакам на бренд завершиться успешно.
Практика показывает, что такие рассылки проводятся часто и являются эффективными. Масштаб:
Как мошенники подделывают письма? При спуфинге цепочка коммуникации подделывается на всех этапах:
Как наносится ущерб? Конкуренты могут сделать e-mail рассылку от вашего адреса электронной почты. В содержании письма указать информацию, которая компрометирует бренд. Или даже устроить провокацию.
Пример рассылки, которую мошенники использовали, чтобы нанести ущерб MegaIndex:
Попытка атаки завершилась провалом. Аккаунты мошенников в облачных сервисах, используемых для отправки писем были, быстро заблокированы.
Даже если бы рассылка состоялась, письма были бы заблокированы принимающими серверами.
MegaIndex защищен от подобных атак.
Рекомендую защитить свои доменные имена, чтобы исключить все риски.
Как сделать так, чтобы письма от имени определенного доменного имени мог отправлять только владелец?
Разбираемся подробно с механизмами защиты.
Как бороться с фальшивыми рассылками?
Любой достойный сайт должен обладать защитой от рассылок с использованием поддельных электронных адресов.
Есть три ключевых механизма для борьбы с поддельными рассылками:
1 — SPF (Sender Policy Framework)
SPF — политика безопасности, которая позволяет задать список допустимых источников для отправки писем.
SPF позволяет проверить подлинность именно источника, с которого отправлено электронное письмо.
Инструкция SPF прописывается в виде строки TXT на сервере доменных имен.
В строке указывается список источников, с которых владелец разрешает отправку электронных писем. К примеру, перечень IP адресов.
Если письмо приходит от сервера с любым другим IP, то авторизация не выполняется.
Полный перечень доступных записей по ссылке — SPF syntax.
2 — DKIM (Domain Keys Identified Mail)
DKIM — защита адреса электронной почты от подделывания с использованием пары ключей шифрования.
Как работает? Этапы:
Открытый ключ используется принимающим сервером для расшифровки.
Для проверки письма на подлинность требуются оба ключа: DKIM-Signature и Public key. Принимающий сервер сопоставляет контент из BODY и HEADERS.
Если проверка выполняется успешно, то письмо проверяется на спам и направляется во входящие.
Если какого-то из ключей нет или ключ подделан, письмо блокируется.
Закрытый ключ прописывается в технических заголовках, поэтому никакого дополнительного текста в содержании письма не появляется.
Синтаксис строки DKIM:
3 — DMARC (Domain-based Message Authentication, Reporting and Conformance)
DMARC — политика для почтовых серверов о принятии мер к скомпрометированным электронным письмам.
Инструкция политики DMARC:
Синтаксис строки DMARC:
Есть другие виды атак.
Часто соперники по поисковой выдаче размещают спамные внешние ссылки на конкурентные сайты, поскольку плохие ссылки мешают продвижению.
Найти опасные ссылки позволяет MegaIndex:
Выводы
Практически в любом бизнесе рассылки электронных писем входят в список главных инструментов коммуникации от имени бренда.
Конкуренты или мошенники могут подделывать e-mail отправителя.
Атака с подменой адреса отправителя называется спуфингом.
Провести атаку просто. Потенциальной риск нанесения ущерба бизнесу и репутации бренда значимый.
Если атака организована мошенниками, обычно целью является хищение персональных данных.
Если атака организована конкурентами, обычно целью является дискредитация бренда или бизнеса.
Важно защитить адрес электронной почты от происков конкурентов.
Для надежной защиты надо использовать связку из механизмов SPF, DKIM, DMARС.
Все бесплатно.
Механизмы поддерживаются почтовыми сервисами Google, Яндекс, Yahoo, Mail.ru, Ukr.net и Microsoft.
Любой способен настроить защиту электронного адреса самостоятельно. Никаких трат не требуется.
Есть вопросы или дополнения по теме? Есть мнения? Напишите в комментариях.
На внедрение не требуется специальных навыков. Если есть интерес к теме, разъясню как создать электронную почту на доменном имени бесплатно и как установить защиту для электронного адреса на практике.
Предотвращение спуфинга адресов и защита электронной почты при помощи SPF-записи
Разумно настроенная SPF-запись снизит вероятность спуфинга доменного имени и защитит ваши сообщения преждевременной пометки «спам».
Спуфинг – это создание почтовых сообщений с поддельным адресом отправителя; такая атака очень проста, поскольку у многих почтовых серверов ненадёжная аутентификация.
Как правило, такую подмену используют для рассылки спама и фишинг-писем, чтобы ввести получателя в заблуждение по поводу происхождения сообщения.
Существует множество методов защиты от спуфинга, среди которых стоит отметить SPF, Sender ID, DKIM и DMARC. SPF (или Sender Policy Framework) – это расширение для проверки электронной почты, которое позволяет подтвердить подлинность доменного имени отправителя.
На сегодняшний день почти весь спам отправляется с поддельного адреса. Почтовые серверы, ставшие жертвами таких злоумышленников, часто страдают от последствий таких действий: их репутация испорчена, а их владельцы должны тратить свое время на сортировку рикошетов или исключение IP-адреса из черных списков.
SPF – это открытый стандарт, позволяющий предотвратить подделку адреса. SPF позволяет администраторам определять хосты, которые могут отправлять сообщения с данного домена, путём создания SPF-записей (или TXT-записей) в настройках DNS. Затем эти записи используются почтовыми обменниками для проверки хоста, отправляющего почту с этого домена.
Преимущества SPF-записей
Добавление записи SPF в настройки DNS – это лучший способ предотвратить использование своего домена для рассылки спама. Кроме того, SPF-запись уменьшает количество реальных сообщений, отмеченных как спам или возвращённых почтовым сервером получателя. К сожалению, SPF не может гарантировать стопроцентной эффективности, так как не все почтовые провайдеры проверяют их.
Пример SPF-записи
Записи SPF добавляются в настройки DNS как TXT-записи, определяющие SMTP-серверы для данного домена.
TXT @ «v=spf1 a include:_spf.google.com
Рассмотрим компоненты этой записи подробнее:
all – обозначает, что этот список является исчерпывающим и никакие другие серверы не могут отправлять сообщения с этой электронной почты.
Компоненты записи SPF
Запись SPF содержит номер версии SPF и строку, задающую:
SPF-клиенты игнорируют TXT-записи, которые не начинаются с номера версии (v=spf1 …).
Запись SPF может определять 0 или больше механизмов. Механизмы используются для описания наборов хостов, которые могут использовать домен для отправки сообщений. В записи SPF включают следующие механизмы:
all | ip4 | ip6 | a | mx | ptr | exists | include
В качестве префикса для механизмов можно использовать следующие ключи:
Если ключ не указан, по умолчанию применяется +.
Также SPF-запись может содержать 1 или 2 модификатора.
Процесс оценки SPF-записи состоит из двух этапов: сначала оцениваются все механизмы и классификаторы, а затем все модификаторы.
Механизмы
Механизмы all
Как правило, механизмы all задаются с ключом в конце записи SPF.
Модификаторы
Модификаторы являются обязательным компонентом записи. Каждая SPF-запись может содержать только один модификатор. Записи без модификаторов будут проигнорированы.
Модификатор redirect перенаправляет запрос на другой домен.
Таким образом, SPF-запись для домена example.com может заменить SPF-запись текущего домена. Модификатор redirect полезен в тех случаях, когда одну запись SPF нужно использовать на нескольких доменах.
Модификатор exp добавляет описание записи SPF:
Если SPF-запрос выдает результат FAIL, запрашивается это описание, которое позволяет предоставить пользователю больше информации.
Эти дополнительные объяснения, как правило, хранятся в логе SPF. Например:
Данная строка может содержать любую полезную информацию для пользователей, чей запрос не был выполнен. Это позволяет направить пользователей к веб-странице с дальнейшими указаниями.
Заключение
SPF-записи не являются обязательным компонентом настройки DNS. Однако такие записи очень полезны, так как они настраивают работу SPF-фильтров (если функция доступна на почтовом сервере), позволяют защитить сервер от спуфинг-атак и предотвращают подделку почтового адреса.
Спуфинг почты как бороться
Вопрос
Не удалось выполнить доставку следующим получателям или группам:
rovena40890@rambler.ru
В ходе доставки этого сообщения по указанному адресу электронной почты возникла проблема. Попытайтесь повторно отправить это сообщение. Если проблема будет возникать снова, обратитесь в службу технической поддержки.
Организация inmx.rambler.ru отклонила сообщение.
При этом данный сотрудник по этому адресу ничего не отправлял и в логах Exchange тоже нет сведений о такой отправке. Я так понимаю, это спуфинг? Как с этим бороться?
Ответы
Не удалось выполнить доставку следующим получателям или группам:
При этом данный сотрудник по этому адресу ничего не отправлял и в логах Exchange тоже нет сведений о такой отправке. Я так понимаю, это спуфинг? Как с этим бороться?
Что это такое и как с этим бороться вкратце рассмотрено господином Нагаевым вот здесь.
От себя порекомендую почитать дополнительно Email Backscatter для большего понимания картины.
Все ответы
ИМХО с вашей стороны никак. С этим (как раз успешно) борется в вашем случае рамблер. Никто не мешает отправлять почту кому угодно и с какого угодно адреса, вопрос в принимающей стороне.
Ну, конечно, если у вас всё корректно настроено (DKIM, SPF and etc)
ИМХО с вашей стороны никак. С этим (как раз успешно) борется в вашем случае рамблер. Никто не мешает отправлять почту кому угодно и с какого угодно адреса, вопрос в принимающей стороне.
Ну, конечно, если у вас всё корректно настроено (DKIM, SPF and etc)
SPF никаким образом не защищает от спуфинга, его задача в другом. Он проверяет лишь домен из конвертного заголовка MAIL FROM. Заголовок from самого сообщения при этом не играет вообще никакой роли, там может быть что угодно, а ведь именно этот заголовок видит юзер.
DKIM заголовок from тоже не проверяет, а лишь гарантирует, что он и ряд других заголовков не были изменены или подделаны. Получив подписанное сообщение, вы можете быть уверены лишь в том, что оно подписано действительно тем ключом, селектор которого указан в заголовках. При этом DKIM не говорит что делать с сообщением, у которого подпись пришла битая или её вообще нет.
В ситуации тс надо поднимать DMARC, который как раз отвечает за валидацию заголовков from и их сопоставление с проверками DKIM и SPF.
Exchange из коробки об этих протоколах вообще ничего не знает, как максимум Exchange Online. Чтобы подписывать сообщения, надо ставить стороннее ПО, либо пускать почту через пограничные шлюзы, который умеют подписывать сообщения, например шлюзы с Postfix (https://blog.bissquit.com/unix/debian/prostejshij-relay-na-postfix-dlya-exchange-server/ ). Это только если речь об отправке, а для анализа принимаемых сообщений вам нужен антиспам, лучше сторонний (https://blog.bissquit.com/mail-servers/exchange-server/antispam-dlya-exchange/ )
Защита от спуфинга в EOP
Стал доступен улучшенный портал Microsoft 365 Defender. Этот новый интерфейс портала Microsoft 365 Defender объединяет Defender для конечной точки, Defender для Office 365, Microsoft 365 Defender и другие решения. Узнайте о новых возможностях.
Область применения
В организациях Microsoft 365 с почтовыми ящиками в Exchange Online и в автономных организациях Exchange Online Protection (EOP) без почтовых ящиков Exchange Online служба EOP включает функции для защиты организации от поддельных отправителей.
В EOP доступны следующие технологии против спуфинга:
Проверка подлинности электронной почты: неотъемлемой частью любых усилий по борьбе со спуфингом является использование аутентификации электронной почты (также известной как проверка электронной почты) записями SPF, DKIM и DMARC в DNS. Вы можете настроить эти записи для своих доменов, чтобы почтовые системы назначения могли проверять достоверность сообщений, которые, как утверждают, были отправлены в ваших доменах. Для входящих сообщений Microsoft 365 требует проверки подлинности электронной почты для доменов отправителей. Дополнительные сведения см. в статье Поверка подлинности электронной почты в Microsoft 365.
EOP анализирует и блокирует сообщения, которые не могут быть аутентифицированы с помощью комбинации стандартных методов аутентификации электронной почты и методов репутации отправителя.
Аналитика спуфинга. Просмотрите поддельные сообщения от отправителей во внутренних и внешних доменах за последние 7 дней и либо разрешите, либо заблокируйте этих отправителей. Дополнительные сведения см. в статье Аналитика спуфинга в EOP.
Разрешить или заблокировать поддельных отправителей в списке разрешенных или заблокированных клиентов. При переопределении решения в аналитике спуфинга поддельный отправитель становится вручную разрешающим или блокирующим элементом, который отображается только на вкладке Спуфинг в списке разрешенных или заблокированных клиентов. Вы также можете вручную создать разрешающие или заблокированные записи для поддельных отправителей до того, как они будут обнаружены с помощью спуфинга. Дополнительные сведения см. в статье Управление списком разрешенных или заблокированных клиентов в EOP.
Политики защиты от фишинга. В EOP и Microsoft Defender для Office 365 политики защиты от фишинга содержат следующие параметры защиты от спуфинга:
Примечание. Политики защиты от фишинга в Defender для Office 365 содержат дополнительные средства защиты, в том числе защиту от олицетворения. Дополнительные сведения см. в статье Монопольные параметры в политиках защиты от фишинга в Microsoft Defender для Office 365.
Отчет об обнаружении подделки. Для получения дополнительной информации см. статью Отчет об обнаружении подделки.
Примечание. Организации Defender для Office 365 также могут использовать способы обнаружения в режиме реального времени (план 1) или обозреватель угроз (план 2) для просмотра сведений о попытках фишинга. Дополнительные сведения см. в статье Исследование угроз и реагирование на них в Microsoft 365.
Как спуфинг используется при фишинговых атаках
Поддельные сообщения имеют следующие негативные последствия для пользователей:
Поддельные сообщения обманывают пользователей: Поддельное сообщение может заставить получателя щелкнуть ссылку и отказаться от своих учетных данных, загрузить вредоносное ПО или ответить на сообщение с конфиденциальным содержимым (известное как компрометация деловой электронной почты или BEC).
Следующее сообщение является примером фишинга, в котором используется поддельный отправитель msoutlook94@service.outlook.com:
Это сообщение не пришло с service.outlook.com, но злоумышленник подделал поле заголовка От, чтобы оно выглядело так, как оно было. Это была попытка обмануть получателя, щелкнув ссылку изменить ваш пароль и отказавшись от его учетных данных.
Следующее сообщение является примером BEC, который использует поддельный почтовый домен contoso.com:
Сообщение выглядит законным, но отправитель подделан.
Пользователи путают настоящие сообщения с поддельными: Даже пользователи, которые знают о фишинге, могут с трудом увидеть разницу между реальными и поддельными сообщениями.
Следующее сообщение является примером сообщения о сбросе реального пароля из учетной записи Microsoft Security:
Это сообщение в самом деле от Майкрософт. Но поскольку реальное сообщение о сбросе пароля трудно отличить от поддельного, пользователи могут игнорировать сообщение, сообщить о нем как о спаме или ошибочно сообщить о нем в Майкрософт как о фишинге.
Различные виды подмены
Microsoft различает два разных типа поддельных сообщений:
Спуфинг внутри организации, который также называется спуфингом самому себе. Ниже приведены примеры.
Отправитель и получатель находятся в одном домене:
От: chris@contoso.com
Кому: michelle@contoso.com
Отправитель и получатель находятся в поддоменах одного домена:
От: laura@marketing.fabrikam.com
Кому: julia@engineering.fabrikam.com
Отправитель и получатель находятся в разных доменах, принадлежащих одной организации (то есть оба домена настроены как принятые домены в одной организации):
От: отправитель @ microsoft.com
Кому: получатель @ поисковой системой bing.com
Пробелы используются в адресах электронной почты, чтобы предотвратить сбор спамботов.
Сообщения, которые не проходят составную аутентификацию из-за подделки внутри организации, содержат следующие значения заголовка:
reason=6xx обозначает подделку внутри Организации.
Междоменный спуфинг: домены отправителя и получателя отличаются и не имеют отношения друг к другу (они также называются внешними доменами). Ниже приведены примеры.
От: chris@contoso.com
Кому: michelle@tailspintoys.com
Сообщения, которые не проходят составную аутентификацию из-за междоменной спуфинга, содержат следующие значения заголовков:
reason=000 указывает, что сообщение не прошло явную проверку подлинности электронной почты. reason=001 означает, что сообщение не прошло неявную проверку подлинности электронной почты.
Если вы получили сообщение *compauth=fail reason=### _ и вам нужно узнать о составной проверке подлинности (compauth) и значениях, связанных со спуфингом, см. статью _Заголовки сообщений для защиты от спама в Microsoft 365* либо непосредственно перейдите к кодам reason.
Проблемы с защитой от спуфинга
Известно, что списки рассылки (также называемые списками обсуждений) имеют проблемы с антиспуфингом из-за способа пересылки и изменения сообщений.
Например, Марта Артемьева (martemyeva@contoso.com) заинтересована в наблюдении за птицами, присоединяется к списку рассылки birdwatchers@fabrikam.com и отправляет в список следующее сообщение:
От: «Марта Артемьева»
Кому: Список обсуждений наблюдателей за птицами
Тема: Отличный отчет о наблюдении за голубыми сойками на вершине горы Рейнир на этой неделе
Кто-нибудь хочет посмотреть птиц на этой неделе на горе Рейнир?
Сервер списка рассылки принимает сообщение, изменяет его содержимое и передает его членам списка. Воспроизводимое сообщение имеет тот же адрес отправителя (glaureano@contoso.com), но в строку темы добавляется тег, а нижний колонтитул добавляется в конец сообщения. Этот тип изменений распространен в списках рассылки и может привести к ложным срабатываниям при подделке.
От: «Марта Артемьева»
Кому: Список обсуждений наблюдателей за птицами
Тема: [BIRDWATCHERS] Отличный отчет о наблюдении за голубыми сойками на вершине горы Рейнир на этой неделе
Кто-нибудь хочет посмотреть птиц на этой неделе на горе Рейнир?
Это сообщение было отправлено в список обсуждения для любителей птиц Birdwatchers. Вы можете отменить подписку в любое время.
Чтобы помочь сообщениям списка рассылки проходить проверку на спуфинг, выполните следующие действия в зависимости от того, управляете ли вы списком рассылки:
Ваша организация владеет списком рассылки:
Попробуйте установить обновления на сервере списка рассылки для поддержки ARC: http://arc-spec.org.
Вашей организации не принадлежит список рассылки:
Попросите сопровождающего списка рассылки настроить аутентификацию электронной почты для домена, с которого пересылается список рассылки.
Когда достаточное число отправителей сообщат владельцам доменов о том, что им следует настроить записи для проверки подлинности электронной почты, это заставит их действовать. Хотя корпорация Майкрософт также работает с владельцами доменов в отношении необходимости публикации требуемых записей, лучше всего работает то, когда отдельные пользователи просят делать это.
Создайте правила входящих в своем почтовом клиенте для перемещения сообщений в папку «Входящие». Вы также можете попросить администраторов настроить переопределения, как описано в статьях Аналитика спуфинга в EOP и Управление списком разрешенных и запрещенных клиентов.
Используйте список разрешенных и запрещенных клиентов, чтобы создать переопределение для списка рассылки, чтобы оно считалось законным. Дополнительные сведения см. в статье Добавление разрешений в список разрешенных и запрещенных клиентов.
Если ничего не помогло, вы можете сообщить об этом сообщении Microsoft как о ложном срабатывании. Для получения дополнительной информации см. Отчет о сообщениях и файлах в Microsoft.
Соображения по поводу защиты от спуфинга
Если вы являетесь администратором, который в настоящее время отправляет сообщения в Microsoft 365, вам необходимо убедиться, что ваша электронная почта должным образом аутентифицирована. В противном случае она может быть помечена как спам или фишинг. Дополнительные сведения см. в разделе Решения для законных отправителей, отправляющих электронную почту без проверки подлинности.
Отправители, внесенные в список надежных отправителей пользователя (или администратора), будут обходить части стека фильтрации, в том числе защиту от спуфинга. Дополнительные сведения см. в статье Безопасные отправители в Outlook.
Администраторам следует избегать (по возможности) использование списка разрешенных отправителей или списков разрешенных доменов. Такие отправители обходят всю защиту от спама, спуфинга и фишинга, а также проверку подлинности отправителя (SPF, DKIM, DMARC). Подробнее см. в статье Использование списков разрешенных отправителей и списков разрешенных доменов.