Гибрид, SMTP, безопасность и Best Practices.

За три месяца ваш покорный слуга превратился из chaotic hater в самого настоящего поклонника облачных решений от Microsoft. Не будем его сильно за это бить, оставим, так сказать, на его совести и спишем на впечатлительность неокрепшего разума. Бог бы с ним…

Проделывая первые робкие шаги в облачных делах под чутким руководством съевших на этом собаку наставников, натолкнулся на очень забавное веяние… Почти все статьи, доклады, презентации, не говоря уже об официальной документации вендора, идут по пути наименьшего сопротивления. Т.е. везде и всюду нам предлагают самые наипростейшие сценарии по известному в народе методу NNF (Next-Next-Finish).

Итак, о чем печаль на этот раз?

Сценарий у нас такой, и он строгий, т.е. никаких «если бы, да кабы»:

Мы имеем гибридную организацию Office 365 + Exchange Organization On-Premises

Входящие потоки почты проходят через облако и никаких сторонних подключений к земле нет, либо для них созданы соответствующие Connector’ы с явным ограничением по IP-адресам.

Что же нам предлагает Microsoft? А предлагают они нам вполне очевидные вещи:

Создать два коннектора в облаке (From On-Prem, To On-Prem)

Обязательно использовать TLS, причем в большинстве документов предлагается не mandatory (в Exchange оно mutual TLS, когда серверы ВЗАИМНО аутентифицируются с помощью сертификатов, к которым ещё и есть ряд требований), как оно по науке должно бы быть, а opportunistic (обычный STARTTLS, можешь — хорошо, не можешь — тоже хорошо), как оно быть не должно.

На земле, следовательно коннектор отправки в облако, где смарт-хостом выступает (по дефолту) .mail.onmicrosoft.com, с таким же opportunistic TLS, и коннектор приёма из облака (наш пациент), что на данный момент самое интересное, с защитой подключения с помощью файрвола. Да-да, они прямо так и советуют: посмотрите в специальную статью базы знаний, там прописаны IP-адреса наших серверов в облаке, вот их и занесите  либо в RemoteIPRange на коннекторе, либо в ACL на файрволле. Другими словами, разрешите подключение ТОЛЬКО с этих адресов.

Эти же адреса можно посмотреть командой Get-HybridMailFlowDatacenterIPs, но статья КВ считается референсной, т.е. то что написано там — более правда, чем то, что отдает вам консоль.

И вы должны подписаться на RSS этой статьи, чтобы, не дай боженька, диапазон изменится и вы, как в жопу ужаленный, должны бежать и править ACL на файрволе (ну или RemoteIPRange на коннекторе). А если у вас файрволлами рулит несколько другая команда, как часто бывает у больших ребят, да ещё и ITIL в полный рост, и change management доведённый до абсурда (что тоже часто бывает у больших ребят), то сбои в работе почты вы можете испытывать довольно долго. Вопрос: какого собственно резона?

На мой взгляд (и он совпадает со взглядами моих более опытных коллег) в этом дополнительном уровне сложности нет совершенно никакой необходимости. Mandatory TLS защитит мой принимающий сервер ничуть не хуже, чем любой самый распрекрасный файрволл. Все, что мне нужно — указать требования к наличию имени mail.protection.outlook.com в настройках коннектора и научить его подставлять правильный сертификат взамен.

Делаю я это относительно просто:

$Certificate = Get-ExchangeCertificate -Thumbprint "0123456789ABCDEF0123456789ABCDEF01234567"
$CertificateName = "<i>" + $Certificate.Issuer + "<s>" + $Certificate.Subject
$Office365IPRanges = @(
    "0.0.0.0-255.255.255.255"
    "::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff"
)
Set-ReceiveConnector -Identity "ServerName\From Office 365" -RequireTLS $true -TlsDomainCapabilities "mail.protection.outlook.com:AcceptCloudServicesMail" -TlsCertificateName $CertificateName -RemoteIPRanges $Office365IPRanges -AuthMechanism @("Tls") -PermissionGroups @("None")

Как можно увидеть, во-первых, коннектор теперь требует сертификат от облачных серверов с именем mail.protection.outlook.com, сам предоставляет сертификат с отпечатком 0123456789ABCDEF0123456789ABCDEF01234567 (чтобы повесить сертификат на коннектор нужно выполнить небольшие приседания, т.к. хочет оно полей Issuer и Subject, и просто подсунуть его по отпечатку, как это делается в случае с IIS и Enable-ExchangeCertificate не очень-то и получится), а самое главное, что теперь у меня нет никаких ограничений по RemoteIPRange. Другими словами, облако может хоть 20 раз в минуту менять свои IP, но пока оно не пришлёт мне правильный сертификат из доверенного центра сертификации, оно будет получать отлуп.

Кстати, заспуфить IP-адрес отправителя и выполнить атаку STRIPTLS гораздо проще, на мой взгляд, чем заспуфить сертификат (хотя с учетом поведения таких игроков, как Symantec, ничего невозможного нет…)

Ещё раз заострю внимание на том, что применять это нужно в том случае, когда вся входящая анонимная почта из интернета не проходит через данный Exchange-сервер.

Гибрид, SMTP, безопасность и Best Practices.

Гибрид, SMTP, безопасность и Best Practices.: 7 комментариев

  1. Андрей Грудцин:

    Отличная статья. Где-то за год гибридного сосуществования не было ни одного критичного изменения пула адресов облака чтобы обмен почтовым трафиком прилегал. Ваше решение с сертификатом более изящное.

  2. Тёма Синицын:

    Олежа, а почему у тебя Microsoft среднего рода?

  3. «Microsoft довно…» (с) Популярный интернет-мем :)
    На самом деле не знаю, так получилось. Поправлю при случае.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s