Direct Connect. Дисишка. Локалка и люди. Стронг и все-все-все.

Олдфаги, ещё помните такое? Представьте, на просторах Интернета оно ещё живое и всеми конечностями держится за своё существование. Как именно — вопрос отдельный.

Я тут на досуге решил научить работать DC через TLS. А что? Инфы на хабах полно, а протокол текстовый, читается Яровой, при необходимости, влёт.

В-общем, модно и злободневно.

Итак, что нужно, чтобы задействовать шифрование в Direct Connect?

Для этого требуется, во-первых, ADCs хаб (NMDCs хабов не существует).

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

Во-вторых, нужен современный правильно настроенный DC клиент. Стронг не подойдёт, ага.

Как настроить DC клиент для работы на ADCs хабе?

В настройках клиента нужно заглянуть в раздел Encryption, он же Security & certificates или Безопасность.

Излишне упоминать, что при использовании активного режима TCP порт для TLS также должен быть проброшен.

DC++

Обратите внимание, личные сообщения также можно отправлять по зашифрованному каналу, "мимо" хаба.

AirDC++

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

ApexDC++

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

Так или иначе, это лучший вариант для использования вместо напрочь устаревшего StrongDC++.

FlylinkDC++

Самый строгий и самый неадекватный. Перевод опций безопасности (как и в AirDC++) ошибочен, а по умолчанию клиент игнорирует безопасные соединения и разрешает обычные, что...неразумно.

В случае успешной установки соединения с помощью TLS (например, при скачивании файллиста) колонка Cipher или Шифр в окошке передач будет заполнена.

Тут очень много шума с этого http://pikabu.ru/story/esli_vyi_ne_paranoik_yeto_eshche_ne_z...

Надо прояснить. Затеряется в говне, ну да похуй. Комменты там посмотрел первую сотню, разоблачения не нашёл. Короче. В любимо ведре есть такая штука.

У красноглазиков такое тоже есть, но как всегда, с задродским оттенком (скрин не мой)

Что это? А это такая штука. Сейчас объясню. Зашли на любимый вк. А там у хрома такое жирное "Надёжный". Что это значит? А это значит, что передавая данные на этот сервер вы шифруете (возможно даже подписываете сверху своим) данные через его сертификат (на самом деле симметричным ключём, но это детали на пару статей).

UPD (сюда ибо логика)

Тут вроде непонятно нихрена. Ещё раз - вот зашифровали. Расшифровать вы НЕ сможете не имея приватного ключа. Ключ есть только у сервера, а сертификат - это способ доставки публичных ключей. Расшифровать не сможет никто. Абсолютно. Даже небо (нашей планете около 4 млрд лет, а для расшифровки надо где-то 20 их).

А здесь мы видим. Сертификат. И цепочку подписей. Так вот, в зависимости от политики вам надо доверять либо а) просто сертификату, б) корневому сертификату, в) предку сертификата. Понятно, что а) проще просто разослать домашний прон, б) и в) особо не отличаются, но вектора атак на б) проще чем на в).

К чему вообще этот осёл тут разорался? Да к тому, что человек чёт там опубликовал, а люди особо даже не удивились. Типа ну. Да. Всё возможно. Так вот, нихуя не всё возможно. Скорее даже нихуя не возможно. Что товарищу перед этим надо сделать, чтобы вообще магия стала возможна? Да очень просто - во все компы вставить по своему сертификату. В доверенные (первый скрин). Типа такого (снова чужая пикча)

Тогда я не я, корова не моя, браузер верно подчинится, а вы сольёте свои данные. Что делать, чтобы этого не произошло? Пара аббревиатур: BYOD, SSH, VPN. Ну и банальная внимательность. Живите дружно и защищайте свою приватность!

P.S. Я не спорю, что потенциально ЦРУ, ЗОГ и рептилоиды всё про нас знают. Однако это уже религиозная война, матан говорит, что если у вас в запасе 20 миллиардов лет, то можно. А так - нельзя. Ещё Шеннон сформулировал, а Ривест с Шамиром и Аделманом предложили рабочий вариант (до сих пор пользуемся).

Итак, как я кому-то обещала:

Настройка TLS на Exchange 2010/2013

Протокол TLS (Transport Layer Security — безопасность транспортного уровня) – это такая новая версия SSL. И то и другое - криптографические протоколы, обеспечивающие защищенную передачу данных в сети с помощью сертификатов безопасности для шифрования каналов связи.

Когда это бывает нужно в exchange – когда вы хотите, чтобы почта между вами и вашим партнером шифровалась и её было бы трудно расшифровать. Ну, как обычно: если у вас паранойя, это ещё не значит, что за вами не следят ;)

Наш пример выглядит как-то вот так:

Наша половина левая. У нас (mydomain.ru) два exchange сервера с ролью Hub-Transport (доменные имена ex01 и ex02) и два edge-сервера (доменные имена ed01 и ed02), через которые идет внешняя почта. Для edge-серверов созданы соответственно MX-записи в DNS зоне, которая смотрит вовне. У наших «друзей» (frienddomain.ru) всё аналогично, но может быть и по-другому, для настройки нашей половины это не принципиально.

Я рассматриваю ситуацию, когда почта уже настроена и ходит вовне, но пришло время параноиков.

Общий алгоритм:

Запросить SSL-сертификат

Подписать его в центре сертификации

Подгрузить его в exchange и связать с SMTP

Сделать коннекторы с TLS

Включить в send-коннекторе обязательный запрос TLS

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

Большая часть манов на английском начинается с того, что у вас из воздуха появляется сертификат. Обратитесь к администратору безопасности – как я «люблю» такие фразы. Нам придется справляться и за загадочного администратора.

Заходим на edge-сервер ed01 и смотрим текущие сертификаты. Это вам радикально пригодится, если сломаете почту – чтобы вернуть старый сертификат, придется указать его номер.

/из-под админа открываем консоль exchange powershell на edge-сервере/

Get-ExchangeCertificate | fl

Теперь создаем CRC – Certificate Signing Request (тоже на edge, в той же консоли exchange powershell):

New-ExchangeCertificate -GenerateRequest -Domainname ed01.mydomain.ru,mail-server1.mydomain.ru -PrivateKeyExportable $True >>c:\ed01req.txt

В текстовом файле будет простыня символов – она нам нужна на следующем этапе.

Подпись SSL-сертификата

То, что мы создали раньше – лишь запрос, теперь надо получить подписанный сертификат. Если у вас в компании всё круто и вы можете подписать его доверенным центом сертификации – здорово. Но нам хватит и самоподписанного.

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

Надо найти сервер, на котором стоит роль центра сертификации (Active Directory Certification Services). Этот сервер точно должен быть, если вы настаивали работу почты через owa или просто вне домена (exchange activesync). У нас это условный сервер DB01 и висит центр сертификации на порту 8080 (потому что 80 уже чем-то оприходован) http://db01.mydomain.ru:8080/certsrv/). Заходить на него надо из-под учетки доменного админа или с аналогичными правами.

Выбрать «Request a certificate»

Выбрать «Or, submit an advanced certificate request»

Выбрать «Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.»

В поле ввода скопировать простыню символов из первого пункта.

Нажать «Submit», выбрать точку «DER Encoded» и скачать сертификат. Получаем файл ed01.cer

Шаблон должен быть "WebServer". Если поля для выбора шаблона, как на картинках в мане нет, то в поле атрибутов указать"CertificateTemplate:WebServer".

Загрузка SSL-сертификата на почтовик

Копируем сертификат в корень диска C:\ на edge-сервер ed01 (для определенности. На самом деле – куда угодно).

На edge-сервере из консоли exchange powershell от доменного админа:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\ed01.cer -Encoding byte -ReadCount 0)) -PrivateKeyExportable $true -Password:(Get-Credential).password | Enable-ExchangeCertificate -Services SMTP

Соглашаемся с заменой сертификата. На этом моменте упадет внешняя почта на данном edge-сервере. Выпадет warning о том, что потеряна подписка на AD, сделайте новую с помощью EdgeSubscription:

Перезагружаем сервер edge (чисто эмпирическое наблюдение, наверное, хватит ребута службы транспорта).

После перезагрузки в консоли exchange powershell создаем новую подписку:

New-EdgeSubscription –FileName c:\edge_subscr.xml

Созданный xml-файл копируем на сервер exchange ex01 в корень диска C:\

Теперь на сервере exchange (вообще-то на сервере с ролью Hub-Transport) подтверждаем подписку:

Для Exchange 2010: Зайдем в консоль управления Exchange -> раздел Конфигурация организации -> действие New Edge Subscription.

В Exchange 2013 надо делать загрузку из консоли powershell:

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\edge_subscr.xml" -Encoding Byte -ReadCount 0)) -Site "S000"

Сайт тут – сайт Active Directory, где у вас находятся почтовик с edge.

Если ed01 был связан и с ex02 – повторяем на нем аналогично.

Можно еще пнуть синхронизацию: Start-EdgeSynchronization

И да, еще раз перегружаем edge (но можно и просто ребутнуть службу, вероятно), минут через 10 починится внешняя почта.

Мануал говорит: на этом этапе сервер уже будет предлагать TLS. Неправда, не верьте.

Создаем коннекторы отправки и получения

На edge-сервере ed01 создаем коннектор получения (Receive Connector). Вот здесь уже хватает инструкций, можно выбрать на свой вкус. Как определить IP MX серверов у друзей:

nslookup –type=MX frienddomain.ru

В коннектор добавляем MX серверов тех друзей, с которыми настраивали TLS. И мы добавляем еще свой Wi-Fi, дабы с него проверить, что строчка 250-STARTTLS появляется.

Как проверить, что кому надо будет предлагаться TLS – откуда-нибудь извне домена (с того вайфая, чей адрес указали в коннекторе) заходим в обычную консоль и набираем:

telnet mail-server1.mydomain.ru 25

EHLO localhost

В выводе должна появиться строчка «250-STARTTLS». (где-то посередине).

Создать из консоли edge-сервера коннектор отправки не получится – его надо создавать на сервере с ролью hub-transport (exchange). На 2013 - в web-консоли. А на Edge он автоматом приедет по подписке (минут через 5).

Send-Connector на Exchange:

Поскольку, FQDN можно указать только один, делаем два аналогичных коннектора.

Коннекторы надо создавать симметрично, в обоих доменах, для которых настраивается TLS.

Включаем обязательный запрос TLS в Send-Connector

На сервере exchange из exchange powershell ("EdgeSync - TLS_to_frienddomain" – Это имя нашего коннектора):

Set-SendConnector "EdgeSync - TLS_to_frienddomain" -RequireTLS 1

Это делаем с обоих сторон. Перезапускаем службу транспорта на edge и проверяем.

Get-SendConnector "EdgeSync - TLS_to_frienddomain" | fl

Иииии, всё повторяем для второго edge ed02.

Собственно, вопрос для тех, кто в теме: лучше делать два send-коннектора, где указывать разный FQDN и распространять каждый из них на оба edge, или на каждый edge распространять свой коннектор только со своим FQDN?

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