Защита потока SMTP-сообщений между различными организациями сервера Exchange 2007

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

Основы

Важно ли защищать SMTP-трафик между разными Exchange-серверами? Проведем простой тест. Запустите ваш любимый анализатор трафика сети. Для примера я использовал Microsoft Network Monitor 3.0. Во время работы программы, запустите сессию Telnet на 25-м порту вашего Exchange-сервера и отправьте сообщение через Telnet. Остановите трассировку и отфильтруйте трафик по протоколу SMTP. Что вы видите? Правильно, весь процесс аутентификации SMTP-сессии передан в явном виде.

Рисунок 1: Трассировка сети с помощью Netmon

Рисунок 2: Оправка SMTP-сообщения через Telnet

Итак, мы видим необходимость внедрения защиты между этими Exchange-серверами. Какое решение следует принять? Есть возможность использовать IPSEC между этими Exchange-серверами, но что это будет значить для нас? При внедрении IPSEC вам придется использовать, как минимум, предварительно распространяемые ключи. Это хорошо, если у вас немного Exchange-серверов. Другим решением при внедрении использования IPSEC между несколькими серверами являются сертификаты, но если вы решите внедрить сертификаты, вам потребуется PKI (Public Key Infrastructure – Инфраструктура открытого ключа).

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

Сервер Exchange 2007 использует несколько методов для обеспечения целостности и сообщений и шифрования сообщений.

• Mutual TLS (Двухсторонний протокол TLS)
• Opportunistic TLS (Гибкий протокол TLS)
• Direct Trust (Прямое доверие)
• Domain Security (Безопасность домена)

Двухсторонний протокол TLS

Протокол TLS (Transport Layer Security – Защита транспортного уровня), наследник протокола SSL, используется для шифрования потока сообщений сервера Exchange 2007. Термин «Двухсторонний» означает, что оба Exchange-сервера, участвующие в процессе транспортировки сообщений, будут проверять сертификат TLS до установления соединения. Двухсторонний TLS внедряется в тех системах, где отправитель и получатель перед отправкой данных проходят двухстороннюю аутентификацию.

Гибкий протокол TLS

Гибкий протокол TLS – это нововведение сервера Exchange 2007. Сервер Exchange 2007 пытается защитить поток сообщений с другими Exchange-серверами или иными системами обмена сообщениями. Также он пытается установить TLS-сессию с другой системой обмена сообщениями в форме анонимного TLS-запроса. В этом и состоит отличие от сервера Exchange 2003, где нужно было вручную включать TLS между разными Exchange-серверами.

Прямое доверие

Весь поток сообщений автоматически шифруется, проходя между Exchange-серверами, не взирая на роль сервера (Центральный транспорт или Граничный транспорт). Прямое доверие не использует сложный сертификат X.509; вместо этого используется прямое подтверждение в форме наличия сертификата в Active Directory. Не важно, используете ли вы собственные сертификаты или внутренний центр сертификации.

Безопасность домена

Безопасность домена – это комбинация различных методик и функций, например управление сертификатами, функциональность коннекторов Exchange-сервера и поведение клиентов, таких как Microsoft Outlook 2007. Главной целью безопасности домена при работе с сервером Exchange 2007 также является установление безопасного соединения с помощью двухстороннего TLS.

Внедрение безопасности TLS

Для защиты потока сообщений с помощью двухстороннего TLS вы можете использовать серверы с ролью Центральный транспорт (Hub Transport) или, если есть, сервер с ролью Граничный транспорт (Edge Server).

Прежде всего, вам нужно установить доверительные отношения на основе сертификатов между двумя организациями Exchange. Как минимум, вы должны добавить сертификат корневого центра сертификации из внешнего центра сертификации в хранилище доверенных корневых центров сертификации на Центральном или Граничном транспорте. Если у вас несколько Граничных или Центральных транспортов, лучше будет внедрить доверительные отношения на основе сертификатов между центрами сертификации или добавить сертификат корневого центра сертификации из внешнего центра сертификации в хранилище доверенных корневых центров сертификации с помощью Групповых политик. Ниже показан сертификат корневого центра сертификации организации B.

Рисунок 3: Сертификат корневого центра сертификации другой организации

Имя субъекта

Имя субъекта играет важную роль в при использовании сертификатов в сервере Exchange 2007. Имя субъекта TLS-сертификата используется службами, связанными с DNS. Эти службы вызывают имя субъекта сертификата и сравнивают его с именем в запросе. Хорошим примером является ISA-сервер, который публикует сайты Outlook Web Access или Outlook Anywhere при использовании HTTPS-сопряжения, где имя сертификата должно точно совпадать с именем в URL, использующимся для доступа к OWA или Outlook Anywhere. Поле Subject Name (Имя субъекта) в сертификате привязывает сертификат к единственному серверу или отдельному имени домена.

Ниже в таблице дан обзор часто использующихся относительно различающихся имен (Relative Distinguished Names – RDN).

Имя Аббревиатура Тип Макс. размер Частота\Макс.\Рекомендовано в сертификате\запрос Порядок в субъекте

Country/Region (Страна/Регион)	C	ASCII	2	1\1	1
Domain Component (Компонент домена)	DC	ASCII	255	Много	1
State or Province (Штат или область)	S	Unicode	128	1	2
Locality (Населенный пункт)	L	Unicode	128	1	3
Organization (Организация)	O	Unicode	64	11	4
Organizational Unit (Подразделение)	OU	Unicode	64	Много\Много	5
Common Name (Имя)	CN	Unicode	64	Много\1	6

Таблица 1: Часто использующиеся относительно различающиеся имена

Запрос сертификата

Теперь нужно запросить сертификат с помощью оболочки Exchange Management Shell. Файл запроса сертификата можно использовать для получения сертификата от внутреннего центра сертификации.

Рисунок 4: Запрос сертификатов Exchange-сервера

Откройте web-консоль центра сертификации и примите запрос на сертификат с помощью кодированного по алгоритму base-64 CMC или PKCS#10 файла.

Рисунок 5: Включение сертификата через web-консоль

Ниже на рисунке показан пример файла запроса сертификата. Если ваш браузер не разрешает открывать файлы, вы можете скопировать и вставить весь текст файла запроса в раздел запроса сертификата web-консоли.

Рисунок 6: Файл запроса сертификата

Подтвердите запрос сертификата.

Рисунок 7: Подтверждение запроса сертификата

Ниже на рисунке вы видите выпущенные внутренним центром сертификации сертификаты.

Рисунок 8: Выданные сертификаты

Импорт сертификата

При импорте сертификата важно использовать оболочку Exchange Management Shell.
Import-ExchangeCertificate -Path c:\certificates\import.pfx | Enable-ExchangeCertificate -Services SMTP

Рисунок 9: Импорт сертификата

Сделайте домен domaene.tld безопасным списком домена с помощью оболочки Exchange Management Shell
Set-TransportConfig -TLSReceiveDomainSecureList domaene.tld

Рисунок 10: Включение безопасного списка домена

Включение безопасности домена на коннекторе-отправителе SMTP с именем "Outbound"

Set-SendConnector Outbound -DomainSecureEnabled:$True

Рисунок 11: Включение безопасности домена в консоли Exchange Management Console

Включение безопасности домена на коннекторе-получателе с именем "Inbound"

Set-ReceiveConnector Inbound -DomainSecureEnabled:$True -AuthMechanism TLS

Обратите внимание:
Почтовые сообщения, успешно доставленные через защищенный поток сообщений, в Outlook 2007 показаны как сообщения с использованием безопасности домена ("Domain Secure").

Заключение

Как вы поняли, внедрение безопасного потока SMTP-сообщений между серверами Exchange 2007 в разных организациях Exchange 2007 не сложно, и вам не нужны сложные решения, наподобие внедрения IPSEC между этими серверами.