Как обезопасить почтовый трафик SMTP | Windows IT Pro/RE | Издательство «Открытые системы»

Ssl-сертификат на почтовом сервере кодирование email – идеальная связка для защиты частной переписки

Если вы хотите гарантировать, что ваша переписка надежно защищена от посторонних глаз, установите SSL-сертификат на свой почтовый сервер, а также дополнительно защитите все свои письма с помощью S/MIME-сертификата. В таком случае даже взлом почтовых серверов (вашего или любого другого, по которому пересылаются письма) не приведет к раскрытию содержания вашей переписки.

В нашем магазине LeaderSSL вы всегда можете приобрести SSL-сертификаты для почтового сервера, а также S/MIME-сертификаты по самым выгодным ценам.

Установка ssl на почтовые серверы – обязательный минимум

Сертификаты, установленные на почтовые серверы, решают сразу несколько задач, в числе которых:

• Идентификация и верификация почтового сервера, к которому производится подключение
• Защита пересылаемых писем от перехвата (в процессе передачи писем от браузера или почтового клиента к серверу и обратно)

Отсутствие SSL-сертификата на почтовом сервере – серьезный пробел, поскольку в этом случае злоумышленники могут провести атаку MITM (Man In The Middle) для перехвата ваших сообщений.

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

Как установить ssl-сертификат на почтовый домен?

Включение starttls

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

Чтобы включить TLS для всего исходящего почтового трафика на выбранном виртуальном сервере SMTP, следует перейти на вкладку Delivery на странице Properties виртуального сервера. Затем нужно щелкнуть кнопку Outbound Security — на экране появится одноименное окно (см. Экран 5).

Необходимо установить флажок TLS encryption и нажать ОК. Однако следует помнить, что эта настройка проявит себя только при обмене сообщениями Exchange с хостами, поддерживающими TLS. Установленное ограничение имеет нежелательный эффект, который выражается в том, что почтовые сообщения, отправленные на другие хосты (без поддержки TLS), остаются в очереди на доставку неограниченное время или до тех пор, пока не истечет интервал повторной отправки и не будет получен отчет о невозможности доставки отправленного сообщения (Nondelivery Report — NDR).

Самый разумный подход — использовать коннекторы SMTP с поддержкой TLS для указанных доменов. Практически во всех ситуациях лучше ограничивать исходящий трафик для тех доменов, о которых наверняка известно, что они поддерживают TLS. Установить, поддерживает ли домен TLS, можно в режиме telnet по состоянию 25-го порта почтового сервера домена, запустив команду SMTP EHLO из командной строки.

Если в ответе присутствует STARTTLS, значит, домен поддерживает TLS. Самый простой способ организовать использование TLS заключается в создании коннекторов SMTP для доменов, поддерживающих TLS. Сделать это можно в контейнере ESM Routing Groups. При создании нового коннектора (или изменении свойств существующего) необходимо выполнить два очень важных действия: убедиться, что на вкладке Address Space домены указаны верно, и установить поддержку TLS на вкладке Advanced (для этого нужно перейти на вкладку Advanced, щелкнуть Outbound Security и установить флажок TLS encryption).

Активизация TLS для входящего трафика не сложнее только что описанной процедуры. Требуется перейти на вкладку Access в окне свойств виртуального сервера и щелкнуть Communication в командной группе Secure Communication. В окне Security, как показано на Экране 6, можно включить поддержку TLS с длиной ключа 40 разрядов (по умолчанию) или указать использование длины ключа 128 разрядов, что я и рекомендую сделать.

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

Для чего необходим tls/ssl сертификат при рассылке писем, влияет ли он на доставляемость писем?

Запрос на ssl-сертификацию

Прежде чем начать использовать TLS с SMTP, необходимо получить и установить сертификат для SMTP-сервера. Если у вас уже имеется собственный центр сертификации, Certificate Authority (CA), запрос на получение SSL-сертификата не вызывает затруднений, если же нет, тогда необходимо сохранить запрос на сертификат в файле и передать его в предпочтительный CA.

О том, как установить Microsoft CA или воспользоваться внешним CA для инфраструктуры открытого ключа (Public Key Infrastructure — PKI), рассказано в статье Certificate Services в справочнике Windows Server Help. Предположим, что у нас есть доступ к CA и необходимо составить запрос и установить сертификат SSL для работы с Microsoft Outlook Web Access (OWA), IMAP, POP или SMTP.

Базовый механизм выдачи сертификатов для всех перечисленных протоколов одинаков, хотя в настоящей статье рассматривается только SMTP. Процедуру запроса сертификата мы инициируем из Exchange System Manager (ESM). В окне дерева ESM нужно отыскать свой сервер и выбрать Protocols и SMTP.

Затем следует открыть контекстное меню виртуального сервера и выбрать Properties; на вкладке Access появится кнопка Certificate, которая включается всякий раз при запуске ESM на сервере Exchange. Поскольку открытый ключ, относящийся к данному сертификату, генерируется на локальной машине, сертификат, созданный на станции администратора, не имеет никакого смысла.

Для формирования запроса на получение сертификата при работе с OWA можно использовать Internet Services Manager (ISM) 5.0. Однако задействовать ESM для запроса POP- или IMAP-сертификата проще, поскольку эти сертификаты можно затребовать непосредственно в диалоговом окне Properties виртуального сервера, так что мы им и воспользуемся. Чтобы затребовать сертификат, нужно просто щелкнуть Certificate.

Защита email – важное дополнение

Один из самых популярных методов защиты email – это S/MIME кодирование. Применение стандарта S/MIME позволяет гарантировать, что прочитать письмо сможет только предполагаемый получатель письма. Кодирование письма производится при помощи публичного ключа.

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

Использование ca независимой компании

Если выбран режим Prepare the request now, but send it later для сертификации через центр CA, находящийся за пределами сети, или через автономный CA, который не интегрирован в Active Directory (AD), дальнейшая процедура будет выглядеть несколько иначе.

После получения информации о географическом положении мастер предложит сохранить конфигурацию запроса в файле. Содержимое файла — открытый (незашифрованный) текст в формате Base64 Encoded Pkcs #10. После сохранения этого файла необходимо передать его в соответствующий центр CA, обычно через Web-интерфейс.

Детали самого интерфейса зависят от CA. Так, например, различают интерфейсы от Thawte, VeriSign и Comodo?s InstantSSL, выглядят они по-разному. На большинстве Web-сайтов независимых центров сертификации имеется набор инструкций по заполнению требования на сертификат.

Microsoft CA также принимает запросы PKCS #10 через Web-интерфейс. Вот как протекает процесс обращения в CA и установка полученного сертификата.

Использование transport layer security

Из-за того что при отправлении почтовых сообщений в стандарте SMTP не используется ни шифрование, ни процедура аутентификации, любое сообщение является доступным для просмотра. Решения на стороне клиента, такие, например, как Secure MIME (S/MIME) или Pretty Good Privacy (PGP), могут помочь решить проблему защиты почты, но они требуют участия в этой процедуре самих пользователей.

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

Microsoft Exchange Server предусматривает несколько способов обеспечения безопасности почтового трафика. Один из них состоит в обязательном использовании Secure Sockets Layer (SSL) for SMTP для имеющихся соединений. Однако применение этого способа вызывает некоторые проблемы.

По умолчанию все серверы SMTP используют 25-й порт. Но если для 25-го порта применяется SSL, то остальные серверы, не поддерживающие SSL, уже не смогут установить соединение с данным сервером через 25-й порт. А если воспользоваться нестандартным номером порта, остальные серверы вообще не смогут обнаружить его.

Проблему можно попытаться обойти. Команда STARTTLS (она входит в состав Extended SMTP — ESMTP) позволяет клиенту и серверу SMTP распознать факт применения Transport Layer Security (TLS) для обычного SMTP-соединения. Участник соединения на любом его конце может провести аутентификацию своего партнера или же TLS-соединение может использоваться исключительно как секретный канал связи. Как бы то ни было, у такого подхода есть три важных преимущества.

• Отсутствует пересечение с остальными серверами и клиентами. Те клиенты, которые поддерживают функцию STARTTLS, могут ее использовать; те, кто не может, продолжают работать с незащищенным трафиком SMTP.
• Гибкость решения. Если клиент может задействовать TLS с SMTP, сервер автоматически запрашивает TLS-подключения при обращении к остальным серверам и сам откликается на запросы о TLS-соединении. Предположим, что какой-либо внешний сервер запустил процесс согласования абонентов, в этом случае почта автоматически становится защищенной. Тем не менее я бы посоветовал администраторам заставлять пользователей включать параметр SSL/TLS на почтовом клиенте.
• TLS-шифрование SMTP защищает заголовки сообщений, это дополнительная степень защиты от программ-анализаторов трафика, без которой злоумышленник смог бы без труда установить, кто и как часто связывается друг с другом.

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

Подтверждение запроса на получение сертификата

Если проверить статус самого первого запроса на получение сертификата, может оказаться, что статус запроса — pending (в процессе решения). Тогда администратор должен подтвердить обработку запроса. Это довольно типичная ситуация, поскольку при установке центра сертификации Windows Certificate Authority (CA) в автономном режиме выдача сертификатов задерживается до тех пор, пока администратор не выдаст соответствующее разрешение (подтверждение).

Таковы установки CA по умолчанию. Для проверки статуса и подтверждения запроса используется оснастка Microsoft Management Console (MMC) Certification Authority, которую необходимо запустить на сервере — центре CA. Чтобы проверить состояние ожидающих выполнения запросов для подтверждения или отказа от их дальнейшей обработки, нужно выполнить следующие действия.

Получение сертификата

Когда кнопку Certificate щелкают на сервере, у которого отсутствует сертификат для специфического протокола, ESM запускает IIS Certificate Wizard. Эта программа проверяет, не запрашивался ли когда-либо SSL-сертификат с помощью Microsoft IIS. Чтобы запросить сертификат для применения в Exchange, необходимы административные привилегии на сервере Exchange, а используемая учетная запись должна иметь право запрашивать сертификат от CA.

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

Если решено модифицировать существующий сертификат, мастер сертификации предложит сделать выбор между возобновлением сертификата, удалением сертификата с виртуального сервера и запросом на получение нового сертификата. Допустим, нам нужен запрос на получение нового сертификата. После щелчка Create a new certificate выполняется следующая процедура.

• На странице Delayed Or Immediate Request следует выбрать использование Remote Procedure Call (RPC), чтобы отослать запрос в CA, если он включен, или сохранить запрос в формате Public-Key Cryptography Standards (PKCS) #10 – стандартном формате для запроса сертификата. Если имеется собственный внутренний CA и он функционирует, нужно выбрать Send the request immediately to an online certification authority и нажать Next. При использовании внешнего центра CA или если внутренний CA выключен, необходимо выбрать Prepare the request now, but send it later и нажать Next для генерации файла PKCS #10, который впоследствии будет отослан в CA.
• Мастер предлагает заполнить имя и длину ключа сертификата, как показано на Экране 1. Хотя Windows 2000 поддерживает работу с ключами длиной 512 разрядов, они слишком коротки для обеспечения безопасной работы; всегда следует выбирать длину ключа по крайней мере 1024 разряда. Затем нужно щелкнуть Next.

Проблемы при работе с tls

После засекречивания исходящего трафика нужно обратить внимание на серверные очереди. Некоторые системы (в основном это касается вариаций на тему UNIX Sendmail) будут отказываться устанавливать TLS-соединения с системами, которые имеют «самоподписанные» сертификаты, тогда как другие вначале воспримут STARTTLS, но затем по разным причинам не смогут выполнить условий и настроек безопасности.

Если после включения TLS обнаружилось, что для почтовых сообщений при отправке их на определенную систему создаются резервные копии, нужно проверить, не происходит ли это из-за сбоев TLS. В таком случае следует установить, почему TLS дает сбой. Необходимо проверить журналы SMTP и журналы System и Application. Если это не прояснит ситуацию, нужно связаться с администратором удаленной системы.

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

Поль Робишо — старший системный архитектор компании EntireNet, имеет сертификаты MCSE и MCT. С ним можно связаться по адресу: getting-started@robichaux.net.

Установка сертификата ssl через zimbra certificate manager (интерфейс командной строки)

Пакет Zimbra имеет инструмент

«zmcertmgr»

для управления сертификатами SSL.

Для версии 8.6 или ниже этот инструмент должен выполняться как root. Запустите эту команду в терминале, чтобы переключиться с пользователя по умолчанию на корень:

sudo su

Начиная с версии 8.7 этот инструмент должен запускаться как пользователь zimbra. Запустите эти команды, чтобы переключиться с пользователя по умолчанию на пользователя zimbra:

sudo su su zimbra

1. Чтобы начать процесс установки, вам необходимо временно загрузить файл сертификата SSL (server_domain_com.crt) и файл пакета CA (server_domain_com.ca-bundle) в любую папку на ваш сервер хостинга. В этом примере файлы SSL загружены в каталог /opt/.

2. Убедитесь, что ваш сертификат, полученный от центра сертификации, соответствует закрытому ключу, созданному вместе с CSR:

/opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key /opt/server_domain_com.crt /opt/server_domain_com.ca-bundle

Результат должен выглядеть так:

3. Разверните свой коммерческий сертификат.

/opt/zimbra/bin/zmcertmgr deploycrt comm /opt/server_domain_com.crt /opt/server_domain_com.ca-bundle

Успешный вывод должен выглядеть так:

4. Убедитесь, что правильный сертификат был развернут.

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Например, информация о сертификате PositiveSSL будет выглядеть так:

5. Чтобы применить изменения, вам необходимо перезапустить службы Zimbra, такие как пользователь zimbra:

sudo su su zimbra

Когда пользователь по умолчанию переключится на пользователя zimbra, запустите эту команду, чтобы перезапустить службы:

zmcontrol restart

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

Цифровая подпись – способ верификации электронных писем при пересылке

Еще один важный аспект технологии S/MIME – добавление цифровых подписей к вашим письмам. Цифровая подпись дает следующие преимущества:

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

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