Что такое спуфинг электронной почты? Как это работает и как предотвратить

Спуфинг электронной почты — это подделка информации об отправителе письма, из-за чего сообщение кажется отправленным от доверенного лица или организации, хотя это не так. Это возможно потому, что оригинальный почтовый протокол SMTP был разработан без верификации отправителя. Любой сервер может заявить, что отправляет почту от имени любого домена, если только этот домен не использует SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) и DMARC (Domain-based Message Authentication, Reporting, and Conformance), чтобы помочь принимающим серверам идентифицировать неавторизованные сообщения.

Спуфинг почтовых доменов остается одним из наиболее распространенных методов, используемых киберпреступниками для выдачи себя за легитимные компании и организации. Создавая впечатление, что сообщение исходит от доверенного учреждения, киберпреступники существенно увеличивают шансы на то, что получатель откроет его, прочитает и сочтет подлинным.

Эти атаки часто используются в фишинговых кампаниях, финансовых мошенничествах, краже учетных данных и распространении вредоносного ПО. Сообщения могут содержать ссылки на поддельные сайты, вредоносные вложения или обманные запросы, цель которых — заставить пользователей поделиться конфиденциальной информацией или совершить действия, ставящие под угрозу их собственную безопасность или безопасность их организации.

Достижения в области искусственного интеллекта облегчили киберпреступникам создание более изощренных фишинговых сообщений. Они могут использовать ИИ для генерации высокоперсонализированных писем, которые имитируют стиль общения, визуальную идентичность и даже стиль письма легитимных компаний, из-за чего мошеннические сообщения становится все труднее распознать.

Влияние спуфинга выходит за рамки непосредственных жертв. Организации, чьи домены используются не по назначению, могут понести репутационный ущерб, потерять доверие клиентов и партнеров, а также столкнуться с ростом операционных рисков. В некоторых случаях отсутствие надлежащих мер защиты может даже вызвать проблемы, связанные с соблюдением нормативных требований и управлением информационной безопасностью.

Как работает спуфинг электронной почты

Каждое письмо содержит два разных адреса отправителя, и именно это разделение эксплуатирует спуфинг.

• Адрес отправителя в конверте (также называемый MAIL FROM и отраженный в заголовке Return-Path) используется почтовыми серверами для маршрутизации сообщения и обработки возвратов (bounces). Получатели обычно никогда его не видят.
• Заголовок «From» — это адрес отправителя, отображаемый во входящих у получателя. Это просто строка текста внутри сообщения, и от отправляющего сервера не требуется доказывать, что он имеет право ее использовать.

Таким образом, злоумышленник может установить заголовок «From» как billing@yourcompany.com, отправляя сообщение с совершенно стороннего сервера. Ничего не нужно взламывать: ни один почтовый ящик не скомпрометирован и ни один пароль не украден. Сообщение просто формируется с ложной информацией об отправителе и передается почтовому серверу, который его принимает.

Именно поэтому организации часто обнаруживают, что их домен подвергается спуфингу, косвенным образом: через сообщения о возврате почты, которую они никогда не отправляли, жалобы клиентов на мошеннические счета или внезапное падение доставляемости писем, вызванное ущербом для репутации их домена как отправителя.

Как определить, что электронное письмо было подделано

Поддельное сообщение во входящих может выглядеть легитимно, поэтому для проверки подлинности требуется изучить заголовки сообщения. В Gmail откройте сообщение, нажмите на меню с тремя точками в правом верхнем углу письма и выберите «Показать оригинал»; в Outlook используйте «Файл» › «Свойства» › «Заголовки интернета». Найдите строку Authentication-Results:

• Если SPF, DKIM или DMARC показывают fail, это указывает на то, что отправляющий сервер не был авторизован доменом в «адресе From».
• Return-Path, который не совпадает с видимым «адресом From», является распространенным индикатором, хотя легитимные почтовые сервисы также могут создавать такое несоответствие.
• Заголовки Received, которые указывают на инфраструктуру, не связанную с заявленным отправителем, служат весомым сигналом.

Если спуфингу подвергается ваш собственный домен, агрегированные отчеты DMARC — это самый быстрый способ подтвердить это и определить, какие серверы отправляют электронную почту с использованием вашего домена. Практическим первым шагом является настройка DMARC в режиме мониторинга, описанная ниже.

Как защитить свой почтовый домен от спуфинга: SPF, DKIM, DMARC и BIMI

Хотя спуфинг возможен из-за ограничений в оригинальных почтовых протоколах, существуют широко распространенные механизмы, которые помогают аутентифицировать сообщения и значительно снижают вероятность подделки. К ним относятся SPF, DKIM, DMARC и BIMI (Brand Indicators for Message Identification). Три основных механизма работают вместе: SPF и DKIM каждый по отдельности предоставляют сигнал, а DMARC указывает принимающим серверам, что делать, если эти сигналы не прошли проверку. BIMI позволяет логотипам компаний появляться рядом с их письмами после того, как письмо проверено с помощью SPF, DKIM и DMARC.

Записи SPF

SPF (Sender Policy Framework) — это один из фундаментальных механизмов защиты почтовых доменов. Это запись, опубликованная в DNS, которая определяет, какие серверы уполномочены отправлять сообщения от имени конкретного домена.

При получении письма сервер получателя проверяет запись SPF, связанную с доменом отправителя, чтобы убедиться, что сервер, отправивший сообщение, имеет на это право. Если проверка прошла успешно, сообщение может перейти к дополнительному анализу. В противном случае оно может быть отклонено, помещено в карантин или помечено как подозрительное, в зависимости от настроенной политики сервера получателя.

Несмотря на свою важность, сам по себе SPF недостаточен для предотвращения всех видов спуфинга. Поэтому его следует использовать в сочетании с другими технологиями аутентификации.

У SPF также есть специфическое «слепое пятно»: он проверяет отправителя в конверте, а не заголовок «адреса From», который фактически видит получатель. Письмо может пройти проверку SPF и при этом отображать поддельный «адрес From». Устранение этого пробела — задача выравнивания (alignment) DMARC.

Основные механизмы, используемые в записи SPF:

• ip4: Авторизует серверы через адреса IPv4.
• ip6: Авторизует серверы через адреса IPv6.
• a: Авторизует IP-адреса, связанные с A-записью домена.
• mx: Авторизует серверы, определенные в MX-записях домена.
• include: Позволяет авторизовать внешние службы отправки электронной почты.
• all: Определяет политику, применяемую к неавторизованным серверам.

Примеры:

Авторизует два отправляющих сервера.

Авторизует отправляющие серверы Microsoft 365 (Outlook) и сервер, чей IP-адрес связан с A-записью mail.example.com.

Авторизует серверы, определенные в MX-записях домена. Сообщения, отправленные другими серверами, получают индикацию мягкого сбоя (~all), что позволяет серверу получателя самостоятельно решить, как с ними поступить.

Важно учитывать, что неправильно настроенная запись SPF может привести к тому, что легитимные письма не дойдут до адресата. Перед публикацией или изменением записи SPF организации должны проверить конфигурацию и протестировать ее влияние на рабочие процессы доставки почты.

Два типа сбоев на практике приводят к большинству проблем с SPF. Во-первых, SPF-запись может инициировать максимум 10 DNS-запросов; каждый include: для сторонней службы рассылки потребляет как минимум один, и организации, использующие несколько маркетинговых платформ, систем работы с тикетами и CRM, регулярно превышают этот лимит, что делает всю запись недействительной. Во-вторых, SPF перестает работать при пересылке писем, поскольку сервер пересылки не указан в качестве авторизованного. И то, и другое — причины рассматривать SPF как один из сигналов среди прочих, а не как самостоятельную защиту.

DKIM (DomainKeys Identified Mail)

DKIM (DomainKeys Identified Mail) — это еще один механизм аутентификации электронной почты, который использует асимметричную криптографию для проверки подлинности и целостности отправленных сообщений. Он обеспечивает дополнительный уровень аутентификации писем, дополняя SPF и усиливая защиту от спуфинга и других атак, связанных с подделкой личных данных.

DKIM работает в два основных этапа. Сначала исходящее письмо подписывается: когда сообщение отправляется из домена с настроенным DKIM, сервер добавляет цифровую подпись в заголовки письма, сгенерированную с использованием закрытого ключа, связанного с доменом. Затем принимающий сервер извлекает открытый ключ, опубликованный в DNS домена отправителя, и проверяет подпись, подтверждая подлинность сообщения и удостоверяясь, что подписанное содержимое не было изменено во время передачи.

Этот механизм не только помогает предотвратить несанкционированное использование домена отправителя, но и укрепляет доверие к отправителю со стороны принимающих серверов. Письма из доменов с правильно настроенным DKIM имеют больше шансов пройти проверки аутентификации и могут способствовать улучшению репутации домена у почтовых провайдеров.

Настройка DKIM не является сложной, но включает в себя несколько технических шагов. Организациям следует следовать инструкциям, предоставляемым их почтовыми провайдерами, такими как Google Workspace или Microsoft 365, которые включают генерацию ключей, публикацию DNS-записей и активацию подписания сообщений.

Открытый ключ публикуется в определенном для селектора поддомене, поэтому домен может использовать несколько ключей параллельно — [BP1.1]по одному на каждую платформу отправки:[/BP1.1]

selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Используйте длину ключа не менее 2048 бит и периодически ротируйте ключи. В отличие от SPF, DKIM переживает пересылку, так как подпись путешествует вместе с сообщением.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Протокол DMARC (Domain-based Message Authentication, Reporting, and Conformance) был разработан в дополнение к этим двум технологиям. Этот протокол использует результаты проверки SPF и DKIM, позволяя владельцам доменов определять политики обработки писем, которые не соответствуют требованиям аутентификации.

В соответствии с политикой DMARC, опубликованной владельцем домена, принимающий сервер может принять (не предпринимать никаких действий), отклонить или поместить в карантин (отправить в спам) письмо, которое не соответствует установленным требованиям. Кроме того, протокол позволяет отправлять периодические отчеты администратору домена, обеспечивая видимость сбоев аутентификации и возможных попыток спуфинга. Эта информация помогает организациям контролировать использование домена и при необходимости корректировать политики безопасности.

DMARC добавляет элемент, которого SPF и DKIM не хватает самих по себе: выравнивание (alignment). Он требует, чтобы домен, проверенный с помощью SPF или DKIM, совпал с доменом в видимом поле «От» (From), что и мешает злоумышленнику выдавать себя за ваш бренд в почтовом ящике получателя.

Запись DMARC публикуется как TXT-запись по адресу _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100; adkim=s; aspf=s

Основные теги:

• p=: Политика, применяемая к сообщениям, не прошедшим проверку: none (без действий), quarantine (карантин) или reject (отклонить).
• rua=: Адрес, на который поступают сводные отчеты.
• pct=: Процент непрошедших проверку сообщений, к которым применяется политика; используется для постепенного внедрения.
• sp=: Политика для поддоменов, которые злоумышленники часто атакуют, когда защищен родительский домен.
• adkim=/aspf=: Строгость выравнивания: по умолчанию смягченная (r) или строгая (s).

Внедрение DMARC в один шаг — наиболее частая причина самостоятельной потери писем. Стандартная последовательность выглядит следующим образом:

• Опубликуйте p=none с адресом для отчетов и больше ничего не меняйте. Доставка почты останется прежней.
• Изучайте сводные отчеты в течение четырех-восьми недель, чтобы составить полную опись всех сервисов, отправляющих письма от вашего имени — маркетинг-платформы, биллинговые системы, HR-инструменты и службы поддержки часто упускаются из виду.
• Настройте аутентификацию для каждого легитимного отправителя с помощью SPF и DKIM, а также устраните ошибки выравнивания.
• Перейдите к p=quarantine, начав с низкого значения pct= и постепенно увеличивая его, одновременно отслеживая отчеты.
• Перейдите к p=reject — единственной политике, которая действительно мешает поддельным письмам доходить до получателей. Домен, постоянно находящийся в режиме p=none, находится под наблюдением, а не под защитой.

Аутентификация электронной почты теперь является требованием к доставляемости, а не просто мерой безопасности.

Начиная с 2024 года, основные почтовые провайдеры сделали аутентификацию условием доставки, а не рекомендацией. Google и Yahoo ввели требования для массовых отправителей — в общих чертах, тех, кто отправляет порядка 5 000 сообщений в день своим пользователям, — охватывающие аутентификацию SPF и DKIM, опубликованную политику DMARC, отписку в один клик для маркетинговых рассылок и сохранение уровня жалоб на спам ниже определенного порога. Впоследствии Microsoft объявила о сопоставимых требованиях для отправителей больших объемов писем на домены outlook.com.

Практическим следствием этого является то, что организации без данных средств защиты теперь сталкиваются с двумя проблемами вместо одной: их домен доступен злоумышленникам, а их легитимные рекламные, расчетные и уведомительные письма с каждым разом все чаще попадают под фильтры или отклоняются. Прежде чем планировать внедрение, уточняйте текущие пороговые значения по документации каждого провайдера, так как они продолжают ужесточаться.

BIMI

До сих пор все механизмы, рассмотренные в этой статье, работали преимущественно за кулисами, без прямого взаимодействия с конечным пользователем, получающим письмо. Хотя эти технологии необходимы для подтверждения подлинности сообщений, также важно предоставить получателям визуальный способ убедиться, что сообщение действительно принадлежит указанной организации.

Здесь на помощь приходит BIMI (Brand Indicators for Message Identification). BIMI — это стандарт аутентификации и визуальной идентификации, который позволяет организациям отображать свои логотипы рядом с письмами, отправленными с их доменов. Логотип может появляться прямо во входящих у получателя (например, рядом с именем отправителя), обеспечивая мгновенное визуальное узнавание бренда и укрепляя доверие к электронной почте.

Внедрение BIMI требует выполнения нескольких этапов, которые являются общими для большинства почтовых провайдеров. Во-первых, организации должны подготовить совместимый логотип, как правило, в формате SVG с определенными требованиями к безопасности и стандартизации, гарантируя, что изображение правильно связано с доменом отправки. Кроме того, DMARC должен быть настроен с политикой принудительного применения (p=quarantine или p=reject), что требует правильной реализации и выравнивания механизмов SPF и DKIM. В зависимости от почтового провайдера и требуемого уровня проверки также может потребоваться VMC (Verified Mark Certificate) или другой сертификат, принимаемый экосистемой BIMI. Этот сертификат должен быть выдан признанным центром сертификации, таким как DigiCert, чтобы подтвердить право собственности и подлинность используемого логотипа.

BIMI — это последний шаг, а не первый. Поскольку он зависит от уже действующего применения DMARC, к нему стоит приступать только тогда, когда цепочка SPF, DKIM и DMARC полностью завершена и стабильна.

Защита вашей организации от поддельных электронных писем, попадающих во входящие

SPF, DKIM, DMARC и BIMI защищают ваш домен от использования против других. Они никак не влияют на поддельные сообщения, поступающие во входящие ваших сотрудников с доменов, которые вы не контролируете, включая домены партнеров и поставщиков со слабой или отсутствующей аутентификацией, а также похожие домены (lookalike-домены), зарегистрированные специально для ее обхода.

Внутренняя защита — это отдельный уровень, который должен обеспечивать:

• Серверную или облачную фильтрацию почты, которая проверяет результаты SPF, DKIM и DMARC по прибытии и помещает в карантин сообщения, не прошедшие проверку, в том числе от доменов, чья собственная политика установлена только в режим мониторинга.
• Обнаружение похожих доменов и подделки отображаемого имени (display-name impersonation), когда домен отправителя аутентифицирован правильно, но был зарегистрирован так, чтобы напоминать доверенный.
• Анализ вложений и URL-адресов, поскольку поддельная информация об отправителе обычно является механизмом доставки вредоносной ссылки или документа, а не самой атакой.

ESET Mail Security и ESET Cloud Office Security применяют эти проверки к почте, поступающей на локальные серверы, а также в клиенты Microsoft 365 и Google Workspace, объединяя проверку аутентификации со средствами защиты от фишинга, спама и сканированием вложений.

Технологии и обучение: необходимое сочетание

Эти технологии, хотя и являются взаимодополняющими, играют фундаментальную роль в создании более безопасной и заслуживающей доверия среды электронной почты. Включая проверку домена отправителя, верификацию целостности сообщений и применение политик против попыток подделки, они снижают возможности для киберпреступников злоупотреблять легитимными доменами и проводить мошеннические кампании.

На практике последовательность важнее отдельных записей: опубликуйте SPF, подпишите с помощью DKIM, разверните DMARC в режиме мониторинга, прорабатывайте отчеты до тех пор, пока каждый легитимный отправитель не будет аутентифицирован, и только после этого переводите политику в режим принудительного применения. Защита, обеспечиваемая этими механизмами, выходит за рамки самой организации, поскольку помогает пользователям и клиентам выработать большее доверие к полученным сообщениям.

Однако одних технологий недостаточно. Осведомленность в вопросах кибербезопасности остается важнейшим компонентом усиления защиты компаний, сотрудников и клиентов. Поскольку угрозы подделки личных данных и социальной инженерии продолжают развиваться, каждый должен быть готов распознавать признаки мошеннических электронных писем, понимать риски, связанные с электронной связью, и применять безопасное поведение в цифровой среде.

Часто задаваемые вопросы (FAQ)

Могу ли я предотвратить подделку моей электронной почты?

Вы не можете помешать злоумышленнику указать ваш адрес в сообщении, но вы можете заставить принимающие серверы отклонять такой результат. Публикация записей SPF и DKIM и применение политики DMARC p=reject означают, что почта, утверждающая, что она отправлена с вашего домена, но не прошедшая аутентификацию, отклоняется до того, как дойдет до получателя.

Как узнать, подделывает ли кто-то мою электронную почту?

Наиболее очевидным доказательством являются сводные отчеты DMARC, в которых перечислены все серверы, отправляющие почту от имени вашего домена. Сообщения о недоставке писем, которые вы никогда не отправляли, и жалобы клиентов на неожиданные счета или сброс паролей являются обычными ранними предупреждающими признаками.

Что происходит, когда электронное письмо подделывается?

Получатель видит сообщение, которое кажется отправленным от доверенного отправителя. С вашей стороны ничего не скомпрометировано — ни к какому аккаунту нет доступа и никакие данные из ваших систем не похищены, но получатель может отреагировать на мошеннический запрос, а повторяющиеся злоупотребления наносят ущерб репутации вашего домена как отправителя и доставляемости писем.

Является ли подделка электронной почты незаконной?

Подделка информации об отправителе с целью совершения мошенничества, кражи учетных данных или распространения вредоносного ПО является уголовным преступлением в большинстве юрисдикций, а выдача себя за домен компании также может являться нарушением прав на товарный знак. Подделка отправителя сама по себе, например, при авторизованном тестировании безопасности, по своей сути не является противозаконной.