Как настроить MTA-STS и TLS-RPT: предотвращение перехвата электронной почты

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

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

Свяжитесь с нами Заказать демонстрацию

Содержание

    1. Агент по пересылке почты - Районная транспортная безопасность (MTA-STS)
    2. Обеспечение шифрования с помощью MTA-STS
    3. Анатомия атаки MITM
    4. Файл политики МТА-СТС
    5. Как опубликовать файл политики MTA-STS
    6. Запись DNS MTA-STS
    7. Настройка MTA-STS для вашего домена
    8. CПроблемы ручного развертывания MTA-STS
    9. Как протестировать и проверить настройку MTA-STS
    10. Услуги PowerDMARC по хостингу МТА-СТС
    11. Отчетность SMTP TLS (TLS-RPT)
    12. Защита передачи электронной почты с помощью MTA-STS
    13. Часто задаваемые вопросы

Mail Transfer Agent-Strict Transport Security (MTA-STS) устраняет эту проблему, требуя установления зашифрованных TLS-соединений между отправляющими и принимающими почтовыми серверами и отказывая в доставке, если безопасный канал не может быть установлен. Вместо того, чтобы надеяться на использование шифрования, MTA-STS обеспечивает его принудительное применение, что делает его незаменимым для организаций, стремящихся внедрить MTA-STS в рамках своей стратегии обеспечения безопасности электронной почты.

шифрование tls

Агент по пересылке почты - Районная транспортная безопасность (MTA-STS)

MTA-STS, как и следует из названия, представляет собой протокол, который обеспечивает зашифрованную передачу сообщений между двумя почтовыми серверами SMTP. MTA-STS указывает отправляющим серверам, что электронные письма должны отправляться только через зашифрованное соединение TLS и не должны доставляться вообще, если безопасное соединение не установлено с помощью команды STARTTLS. Повышая безопасность электронных писем при передаче, MTA-STS помогает смягчить последствия атак «человек посередине» (MITM), таких как атаки понижения версии SMTP и атаки подделки DNS.

Подробнее

Обеспечение шифрования с помощью MTA-STS

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

Чтобы понять, как работает шифрование при доставке электронной почты, рассмотрим пример почтового сервера, отправляющего сообщение на адрес [email protected]. Отправляющий агент передачи почты (MTA) сначала выполняет DNS-запрос, чтобы получить записи MX для powerdmarc.com, определяя, какие почтовые серверы отвечают за прием сообщения. Затем отправляющий MTA подключается к одному из этих серверов и проверяет, поддерживает ли он шифрование TLS, используя команду STARTTLS. Если TLS доступен, электронное письмо отправляется по зашифрованному соединению. Если нет, отправляющий сервер не может установить безопасное соединение и, без принудительного выполнения, может вернуться к отправке сообщения в виде обычного текста.

MTA-STS изменяет это поведение доставки, применяя строгие требования безопасности при обмене данными между серверами:

MTA-STS дает указание почтовым серверам-отправителям доставлять сообщения только через соединение, зашифрованное с помощью TLS. Если шифрование не может быть установлено, сообщение не доставляется вообще. Это устраняет бесшумный переход на открытый текст, который делает возможным перехват.

Получающий почтовый сервер должен представить действительный сертификат TLS, а доменное имя в этом сертификате должно совпадать с доменом, определенным в политике MTA-STS. Это гарантирует, что отправляющий сервер общается с правильным адресатом, а не с поддельным хостом.

Политики MTA-STS извлекаются через HTTPS с безопасного веб-сервера. Извлечение политики через зашифрованный и аутентифицированный канал предотвращает изменение или подделку инструкций политики злоумышленниками во время передачи.

Благодаря применению шифрования и проверке как сертификатов, так и инструкций политики, MTA-STS блокирует атаки SMTP downgrade, основанные на удалении или изменении команды STARTTLS. Серверы отправки больше не принимают небезопасные резервные варианты, когда должно существовать безопасное соединение.

услуги мта снтс
хостинговая система MTA STS

MTA-STS реализуется путем публикации записи DNS, которая направляет отправляющие почтовые серверы на получение файла политики из указанного поддомена. Доступ к файлу политики осуществляется через HTTPS, проверяется с помощью сертификатов TLS и содержит утвержденные имена хостов почтовых серверов получателя. Протокол предписывает отправляющим SMTP-серверам требовать зашифрованное соединение и проверять, что домен, указанный в сертификате TLS, соответствует домену, определенному в файле политики. Если MTA-STS принудительно применяется, в случае невозможности согласования зашифрованного канала сообщение не доставляется вообще.

Анатомия атаки MITM

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

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

Атака на понижение SMTP

Предупреждающие знаки

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

Еще одним признаком является нестабильная работа почтовой службы. Письма могут проходить через незнакомые серверы, а в журналах могут отображаться подключения к хостам, которые не соответствуют опубликованным MX-записям предполагаемого получателя. В более сложных случаях сообщения поступают в измененном виде, урезанными или перенаправленными через промежуточные системы без четкого объяснения.

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

Все эти сигналы помогают выявить активность MITM, которая в противном случае осталась бы незамеченной при нормальном потоке электронной почты.

Файл политики МТА-СТС

Файл политики MTA-STS представляет собой простой текстовый файл, который выглядит следующим образом:

версия: STSv1
режим: обеспечение исполнения
mx1.powerdmarc.com
mx2.powerdmarc.com
mx3.powerdmarc.com
макс. возраст: 604800

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

Файл политики использует пары «ключ-значение», причем каждое значение кодируется в отдельной строке текстового файла, как показано выше. Размер этого файла может достигать 64 КБ. Имя файла политики должно быть mta-sts.txt. Файлы политик необходимо обновлять каждый раз, когда вы добавляете или изменяете почтовые серверы в своем домене.

Примечание: Настройка MTA-STS в режиме принудительного исполнения может привести к тому, что некоторые сообщения электронной почты не будут доставляться Вам. Поэтому рекомендуется установить режим политики на тестирование и выбрать низкий max_age, чтобы удостовериться, что все работает правильно, прежде чем переходить к принудительному исполнению политики. Мы рекомендуем настроить TLS-RPT для вашей политики в тестовом режиме, а также получать уведомления в случае отправки писем открытым текстом. 

MTA-STS-Policy

Как опубликовать файл политики MTA-STS

Для того, чтобы опубликовать файл политики MTA-STS, веб-сервер, на котором расположен ваш файл, должен быть опубликован:

  • Поддержка HTTPS/SSL

    Файл политики должен обслуживаться через веб-сервер с поддержкой HTTPS, чтобы обеспечить его безопасную загрузку почтовыми серверами.

  • Используйте сертификат, выданный доверенным центром сертификации.

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

  • Разместите файл на выделенном поддомене mta-sts.

    Необходимо настроить общедоступный веб-сервер с добавлением субдомена mta-sts к вашему домену, который используется исключительно для публикации политики MTA-STS.

  • Поместите файл политики в необходимый каталог.

    Файл политики должен иметь имя mta-sts.txt и быть опубликован в каталоге .well-known на поддомене mta-sts.

  • Убедитесь, что файл политики общедоступен по правильному URL-адресу.

    Отправляющие MTA должны иметь возможность получить файл из места, форматированного как
    https://mta-sts.yourdomain.com/.well-known/mta-sts.txt без аутентификации или перенаправлений.

хостинговая система MTA STS

Запись DNS MTA-STS

Запись TXT DNS для MTA-STS публикуется в DNS вашего домена, чтобы указать, что ваш домен поддерживает протокол MTA-STS, и для сигнала об обновлении кэшированных значений в MTA в случае изменения политики. Запись MTA-STS DNS помещается в субдомен. _mta-sts как внутри: _mta-sts.powerdmarc.com. Запись TXT должна начинаться с v=STSv1, а также "id" значение может содержать до 32 буквенно-цифровых символов, включенных следующим образом:

 v=STSv1; id=30271001S00T000;

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

Для этого используется DNS-запись MTA-STS: 

  • Укажите поддержку MTA-STS для домена
  • Сигнализируйте MTA для повторного получения политики через HTTPS, если политика изменена.

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

Настройка MTA-STS для вашего домена

Для того, чтобы включить MTA-STS для вашего домена, вам необходимо:

  • Добавить DNS-запись типа имени в mta-sts.example.comнаправленный на веб-сервер с поддержкой HTTPS, который является хостингом файл политики MTA-STS.

  • Добавить DNS-запись типа txt или cname по адресу _mta-sts.example.com который определяет поддержку MTA-STS для вашего домена.

  • Установите веб-сервер с поддержкой HTTPS с действующим сертификатом для вашего домена.

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

поиск записей spf запись иконка powerdmarc

Проблемы ручного развертывания MTA-STS

Ручное развертывание MTA-STS требует не только публикации одной записи DNS. Оно требует координации веб-инфраструктуры, сертификатов, политик и постоянного обслуживания, что может создать ряд проблем, если не управлять этим процессом тщательно.

  • Требование к веб-серверу с поддержкой HTTPS

    Политики MTA-STS должны размещаться на общедоступном сервере HTTPS с действительным сертификатом TLS. Это требует обеспечения инфраструктуры, правильной настройки TLS, своевременного обновления сертификатов и обеспечения высокой доступности.

    Решение: Организации с ограниченной веб-инфраструктурой могут снизить сложность, используя хостинговый сервис MTA-STS, который автоматически управляет серверами и сертификатами.

  • Текущее ведение файлов политик

    Любые изменения в конфигурации почтового сервера требуют обновления файла политики MTA-STS. Если файл устарел, легитимные электронные письма могут не доставляться после включения принудительного применения.

    Решение: Централизованное управление политиками или автоматизированные инструменты помогают обеспечить немедленное и точное применение обновлений.

  • Обновления записей DNS и контроль версий

    Запись MTA-STS TXT должна обновляться с новым значением id каждый раз, когда изменяется политика. Отсутствующие или неверные обновления могут задержать обновление политики и привести к несогласованному применению.

    Решение: Автоматизация снижает риск человеческой ошибки и обеспечивает соответствие записей DNS изменениям политики.

  • Ограниченная видимость сбоев в доставке

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

    Решение: Платформы отчетности, которые анализируют и визуализируют отчеты TLS, упрощают обнаружение сбоев и быстрое реагирование на них.

  • Более высокие операционные расходы и затраты на координацию

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

    Решение: Команды должны оценить, есть ли у них время и опыт для долгосрочного обслуживания MTA-STS или же управляемый подход лучше соответствует их операционным приоритетам.

Как протестировать и проверить настройку MTA-STS

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

  • Проверка распространения DNS

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

  • Доступность файла политики

    Убедитесь, что файл политики MTA-STS доступен по HTTPS в ожидаемом месте в поддомене mta-sts. Доступ к файлу должен быть возможен без перенаправлений, требований аутентификации или ошибок сертификата. Любое прерывание доступа может помешать отправляющим серверам получить политику.

  • Проверка поддержки TLS

    Убедитесь, что все MX-хосты, перечисленные в политике, поддерживают TLS и предоставляют действительные сертификаты, соответствующие требованиям политики. Успешное согласование TLS гарантирует, что после включения принудительного применения шифрованные соединения будут устанавливаться стабильно.

Услуги PowerDMARC по хостингу МТА-СТС

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

  • Мы поможем вам опубликовать записи о ваших именах всего за несколько кликов.

  • Мы берем на себя ответственность за обслуживание веб-сервера и хостинг сертификатов.

  • Благодаря нашим услугам MTA-STS, размещенным на хостинге, развертывание с вашей стороны сводится к простой публикации нескольких записей DNS.

  • Вы можете мгновенно и легко вносить изменения в политику MTA-STS через панель инструментов PowerDMARC, без необходимости вручную вносить изменения в DNS.

  • Услуги PowerDMARC по хостингу MTA-STS соответствуют RFC и поддерживают новейшие стандарты TLS.

  • От создания сертификатов и файла политики MTA-STS до внедрения политики - мы поможем вам избежать огромных сложностей, связанных с принятием протокола.

Отчетность SMTP TLS (TLS-RPT)

Чтобы сделать соединение между двумя взаимодействующими SMTP-серверами более безопасным и зашифрованным с помощью TLS, был введен протокол MTA-STS, который обеспечивает шифрование и предотвращает доставку электронных писем в виде открытого текста, когда невозможно установить безопасное соединение. Однако одна проблема остается нерешенной: как уведомлять владельцев доменов, когда на удаленных серверах возникают проблемы с доставкой электронной почты, вызванные сбоями TLS. Здесь на помощь приходит TLS-RPT, дополняющий MTA-STS, предоставляя диагностические отчеты, которые поддерживают мониторинг и устранение неполадок в связи серверов, таких как истекшие сертификаты TLS, неправильная настройка почтового сервера или сбои в переговорах TLS.

Отчеты TLS помогают обнаружить и отреагировать на проблемы при доставке по электронной почте с помощью механизма отчетности в виде JSON-файлов. Эти JSON-файлы могут быть сложными и неразборчивыми для нетехнического человека.

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

 

powerdmarc tls rpt

Что делает TLS-RPT

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

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

Отчеты TLS-RPT генерируются и отправляются совместимыми агентами передачи почты, как правило, ежедневно, обеспечивая постоянный контроль за состоянием безопасной доставки электронной почты.

json-графики

Как включить эту функцию

TLS-RPT включается путем публикации записи DNS TXT в необходимом месте _smtp._tls для вашего домена. Эта запись сигнализирует о поддержке отчетности TLS и указывает место назначения, куда должны доставляться диагностические отчеты.

Запись TXT определяет один или несколько адресов отчетности, обычно электронную почту или конечные точки HTTPS, которые используются почтовыми серверами, соответствующими требованиям, для отправки данных TLS-RPT. После создания записи отчетность начинается автоматически без каких-либо изменений в поведении почтового сервера.

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

Подробнее

Защита передачи электронной почты с помощью MTA-STS

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

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

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

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

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

Панель управления PowerDMARC позволяет автоматически настроить MTA-STS и TLS-RPT для вашего домена, опубликовав всего три записи CNAME в DNS вашего домена. От размещения файлов политики и сертификатов MTAS-STS до обслуживания веб-сервера - мы позаботимся обо всем этом в фоновом режиме, без необходимости внесения каких-либо изменений в DNS. Развертывание MTA-STS с вашей стороны с помощью PowerDMARC сокращается до нескольких кликов.

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

Рекомендуется всегда устанавливать режим политики MTA-STS следующим образом тестирование на начальных этапах развертывания, чтобы вы могли контролировать деятельность и получить видимость экосистемы электронной почты, прежде чем переходить к более агрессивной политике, например, к принудительному применению. Таким образом, даже если электронная почта не отправляется по зашифрованному TLS соединению, она все равно будет отправляться открытым текстом. Однако убедитесь, что вы включили TLS-RPT, чтобы получать уведомления, если это произойдет.

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

Следует отметить, что, хотя MTA-STS гарантирует, что электронная почта передается по зашифрованному TLS соединению, в случае, если защищенное соединение не согласовано, электронная почта может вообще не быть доставлена. Однако это необходимо, поскольку это гарантирует, что электронная почта не будет доставляться по незашифрованному пути. Чтобы избежать таких проблем, рекомендуется сначала установить политику MTA-STS в тестовом режиме и включить TLS-RPT для вашего домена, прежде чем переходить в режим принудительного исполнения MTA-STS. 

Вы можете легко изменить режим MTA-STS с панели управления PowerMTA-STS, выбрав желаемый режим политики и сохранив изменения без необходимости внесения каких-либо изменений в DNS.

Вы можете отключить MTA-STS для своего домена, установив режим политики «none» (нет), тем самым указав MTA, что ваш домен не поддерживает протокол, или удалив запись MTA-STS DNS TXT. 

Записи MX для файла политики MTA-STS должны включать записи для всех принимающих почтовых серверов, используемых вашим доменом.

Запланируйте демонстрацию сегодня
защищённая электронная почта Powerdmarc

15-дн. пр. версияЗаказать демо