• Внедрение Инфраструктуры Открытых Ключей на основе Windows Server. Сетевой ответчик, особенности настройки.

    Степан Москалев, Леонид Шапиро

     

    В предыдущих статьях нашего цикла [1], [2], [3] мы разобрались установкой нашей двухуровневой иерархии центров сертификации, получив вполне рабочий вариант, который уже можно использовать корпоративной среде с некоторыми оговорками, поскольку речь пока еще не шла об отказоустойчивости и доступности, не все решено с центрами распространения, но об этом речь пойдет позже. Так или иначе, получается масштабируемая среда, которую в дальнейшем можно развивать.

    Вполне очевиден один «тонкий» момент, а именно, сам CRL может стать узким местом. Ведь информация об этом списке должна быть у всех клиентов.

    Со временем список отзыва сертификатов будет расти, особенно если мы будем внедрять различные типы сертификатов и количество пользователей системы будет увеличиваться. Сертификаты надо будет отзывать, например, если пользователь покидает компанию, и его сертификат надо аннулировать, или же сертификат скомпрометирован и нуждается в отзыве. Такой сертификат, верней, его серийный номер помещается в список отзыва сертификатов (CRL), который должен быть опубликован и доступен клиентам на Distribution Point – центре распространения. Обычно это WEB сервер и LDAP каталог.

    Кроме основного или базового списка отзыва, может быть также использован и разностный или Delta CRL. Он содержит аннулированные сертификаты, которые были отозваны после публикации предыдущего базового списка. Использование Delta CRL позволяет сократить объем передаваемых клиенту данных [4].

    Дело в том, что CRL кешируется на клиенте, чтобы не загружать избыточно канал связи, и его не надо загружать при каждой проверке сертификата. Соответственно, имея кешированным базовый CRL, нам будет достаточно получить только разностный список отзыва. Когда же будет опубликован новый базовый CRL, то его придется снова скачивать.

    Теперь давайте вспомним, что делается, для проверки не отозван ли сертификат. Проверяется поле сертификата CRL Distribution Point (CDP), которое и содержит информацию о месте расположения списка отзыва сертификатов, за которым нам и предстоит обратиться.

    Вот тут и возникает сложность, список может быть большим, да и клиентов, которым он нужен, может быть существенное количество.

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

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

    В сущности, мы используем файл-серверную технологию, и возникает вопрос, как бы тут перейти к клиент-серверной, можно ли проверить статус сертификата, не загружая весь CRL каждый раз при проверке?

    Оказывается, такое решение уже давно есть и называется «сетевой ответчик» или online responder Online Certificate Status Protocol (OCSP) [5]. Эта функциональность есть в составе центра сертификации Microsoft [6].

    Как он работает? В отличие от списков отзыва сертификатов (CRL), которые распространяются периодически и содержат сведения обо всех отозванных и приостановленных сертификатах, сетевой ответчик обрабатывает только отдельные запросы от клиентов о состоянии сертификата. Объем получаемых данных на один запрос остается постоянным вне зависимости от возможного количества отозванных сертификатов. Это позволяет снизить накладные расходы при проверках сертификатов. Однако ссылка на OCSP Online Responder должна быть включена в проверяемый сертификат. Дополнительно можно указать OCSP, Online Responder через групповые политики [7].

    Суть работы OCSP простая. См. Рисунок 1.  Клиент для проверки статуса сертификата отправляет запрос на OCSP Responder с указанием серийного номера проверяемого сертификата. Online Responder на своей стороне проверяет статус сертификата и возвращает этот статус клиенту. Сначала ответчик OCSP определяет, имеет ли он кешированные ответы для одного и того же запроса. Если да, то он может отправить ответ клиенту.

    Если нет уже кэшированного ответа, тогда ответчик OCSP проверяет, есть ли у него локальный кешированный список отзыва CRL. Если да, то по нему он проверит статус сертификата, и отправит ответ клиенту, который будет подписан сертификатом OCSP. Если кешированного списка отзыва нет, то тогда OCSP сам обратится по указанному в CDP расширении сертификата пути, проанализирует полученную информацию и отправит окончательный ответ клиенту [8].

    Рисунок 1 Алгоритм работы OCSP

     

    Использовать протокол OCSP умеют только клиенты под управлением Windows Vista и выше. Предыдущие ОС могут его поддерживать только за счёт сторонних компонентов [8].

    Очевидно, использование этой технологии целесообразно, особенно в больших компаниях.

    Во многих ситуациях сетевой ответчик оказывается более эффективным при проверке статуса сертификата по сравнению с использованием обычных списков отзыва. У нас есть очевидные основания чтобы его внедрить.

    • Наличие удаленных клиентов, использующих медленные каналы связи.
    • Инфраструктура должна обеспечивать высокую производительность при проверке состояния сертификатов, например массовая аутентификация пользователей в сети, использование шифрованного почтового обмена и т. п.
    • Организации необходимы эффективные средства для распространения данных отзыва для сертификатов, выпущенных не Microsoft CA, а сторонним центром сертификации.
    • Компания ограничивает возможность просмотра всего списка отзыва сертификатов, предоставляя только требуемую для проверки отдельных запросов статуса сертификата информацию.

    Для установки роли сетевой ответчик необходимо выбрать сервер. Роль сетевого ответчика может быть установлена как на сервер центра сертификации, так и на отдельный сервер.

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

     

    Приступим к установке OCSP.

    Начнем с настройки на стороне издающего сервера сертификатов.

    Заходим на сервер учетной записью пользователя, обладающей правами Enterprise Admin и переходим к установке.

    1. Запустите Server Manager. Нажмите ToolsCertification Authority.
    2. Нажмите правой кнопкой мыши на Certificate Templates и выберите
    3. Выберите шаблон OCSP Response Signing и измените свойства
    4. На вкладке Security добавьте учётную запись компьютера, на котором устанавливается OCSP и дайте ей права Read, Enroll и Auto Enroll.
    5. Нажмите OK для принятия изменений в шаблоне OCSP Response Signing.
    6. На вкладке General посмотрите продолжительность действия сертификата Validity period: (по умолчанию стоит 2 недели, если OCSP сервер не будет членом домена, то есть смысл в увеличении данного параметра (выдача будет производиться в ручном режиме)).
    7. Закройте Certificate Templates.
    8. Нажмите правой кнопкой мыши на Certificate Templates и выберите New – Certificate Template to Issue.
    9. Выберите шаблон OCSP Response Signing и нажмите
    10. Запустите Windows PowerShell [8].
    11. Для добавления путей публикации OCSP в Authority Information Access (AIA) выполните следующую команду:

    Add-CAAuthorityInformationAccess http://pki.nwtraders.msft/ocsp -AddToCertificateOcsp -Force

    1. Перезагрузите службу сертификатов: Restart-Service CertSvc

     

    Теперь можно приступать к установке Online Responder на сервере Веб сервере.

     

    1. Выполните установку OCSP при помощи PowerShell, для чего запустите Windows PowerShell.
    2. Для установки роли выполните следующую команду: Install-WindowsFeature ADCS-Online-Cert -IncludeManagementTools
    3. Выполните следующую команду: Install-ADcsOnlineResponder
    4. Нажмите Y
    5. Запустите Server Manager.
    6. Нажмите ToolsInternet Information Services Manager.
    7. Нажмите на имени сервера.
    8. Нажмите Sites.
    9. Нажмите Default Web Site.
    10. Убедитесь в наличии сайта OCSP.
    11. В Server Manager.
    12. Нажмите Tools – Online Responder Management.
    13. Нажмите правой кнопкой мыши на Revocation Configuration и выберите Add Revocation Configuration.
    14. В окне Add Revocation Configuration на вкладе Getting Started With Adding A Revocation Configuration нажмите Next.
    15. В окне Add Revocation Configuration на вкладе Name The Revocation Configuration введите имя конфигурации (оно может быть любое) IssuingCA01 и нажмите Next.
    16. В окне Add Revocation Configuration на вкладе Select CA Certifícate Location выберите Select a certificate for an Existing enterprise CA и нажмите Next.
    17. В окне Add Revocation Configuration на вкладе Choose CA Certificate выберите Browse CA certificates published in Active Directory и нажмите Browse.
    18. В окне Select Certification Authority выберите сертификат издающего центра и нажмите кнопку OK.
    19. Нажмите Next.
    20. В окне Add Revocation Configuration на вкладе Select Signing Certificate выберите Automatically select a signing certificate и установите флаг Auto-Enroll for an OCSP signing certificate нажмите Next. См. Рисунок 2

     

    Примечание   IssuingCA01 в данном случае имя используемого издающего центра сертификации.

    Рисунок 2 Выбор сертификата

    21. В окне Add Revocation Configuration на вкладе Revocation Provider нажмите Provider….

    22. Убедитесь, что в окне Revocation Provider Properties в области Base CRLs: (область Delta CRLs: пока оставляем без изменений) путь http стоит первым. См. Рисунок 3.

     

    Рисунок 3. Пути к спискам отзыва

    23. В окне Revocation Provider Properties в области Delta CRLs: нажмите кнопку ADD… и введите маршрут http://pki.nwtraders.msft/PKI/IssuingCA01+.crl нажмите кнопку OK.

    24. В окне Revocation Provider Properties в области Delta CRLs: нажмите кнопку ADD… и введите маршрут:///CN=IssuingCA01,CN=ICA01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=Nwtraders,DC=msft?deltaRevocationList?base?objectClass=cRLDistributionPoint нажмите кнопку OK.

     

    Примечание: Маршруты удобно взять из утилиты pkiview.msc запустив ее на издающем центре сертификатов. pki.netraders.msft – путь, используемый в тестовом примере.

    25. Нажмите кнопку OK.

    26. В окне Add Revocation Configuration на вкладе Revocation Provider нажмите Finish.

    Установка OCSP завершена.

    Проверка работы Online Responder

    1. В Server Manager.
    2. Нажмите Tools – Online Responder Management.
    3. Нажмите левой кнопкой мыши на Online Responder: Nwtraders.msft.
    4. Убедитесь, что напротив IssuingCA01 стоит статус Working. См. Рисунок 4.

     

    Примечание: websrv1.nwtraders.msft – используемый в примере сервер WEB.

    Рисунок 4 Проверка работоспособности

     

    5. Нажмите левой кнопкой мыши на Array Configuration и нажмите на имени WEB сервера. См. Рисунок 5.

     

    Рисунок 5. Просмотр свойств сертификата

    6. Нажмите левой кнопкой мыши на View Signing Certificate и посмотрите свойства сертификата:

    • Кем выдан.
    • Кому выдан.
    • Срок действия.
    • Какой шаблон использован при выдаче.

     

    См. Рисунок 6,  Рисунок 7

     

    Рисунок 6. Свойства сертификата. Вкладка “General”

     

    Рисунок 7. Свойства сертификата. Вкладка “Details”

    7. Зайдите на сервер издающего удостоверяющего центра с правами администратора сервера «nwtraders\Administrator».

    Запустите из командной строки утилиту pkiview.msc.

    8. Уберитесь в наличии пути OCSP Location#1 в настройках издающего центра сертификатов

    9. Посмотрите статус напротив пути OCSP Location#1.

     

     

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

     

    Продолжение следует…

     

    Статья опубликована в журнале “Системный Администратор”

     

    Литература

    [1] Шапиро Л. Внедрение инфраструктуры открытых ключей на основе Windows Server 2016. Часть 1. Предварительный этап. / «Системный администратор», № 1-2, 2018 г. – С. 23-27. URL: http://samag.ru/archive/article/3576.

    [2] Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 2. RootCA / «Системный администратор», № 3, 2018 г. – С. 16-19. URL: http://samag.ru/archive/article/3605

    [3] Москалев С., Шапиро Л. Инфраструктура открытых ключей в Windows Server 2016. Часть 3. Установка и настройка издающего центра сертификации (Issuing CA)/ «Системный администратор», № 7-8, 2018 г. – С. 26-28. URL: http://samag.ru/archive/more/184

    [4] PKI Design Considerations: Certificate Revocation and CRL Publishing Strategies https://blogs.technet.microsoft.com/xdot509/2012/11/26/pki-design-considerations-certificate-revocation-and-crl-publishing-strategies/

    [5] Online Certificate Status Protocol https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol

    [6] Certification Authority Guidance https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11)

    [7] PKI Design Considerations: Certificate Revocation and CRL Publishing Strategies https://blogs.technet.microsoft.com/xdot509/2012/11/26/pki-design-considerations-certificate-revocation-and-crl-publishing-strategies/

    [8] PowerShell Documentation https://docs.microsoft.com/en-us/powershell/

    • Установка и настройка корневого центра сертификации (RootCA)

      Степан Москалев

      Леонид Шапиро

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

      • Атаки DDoS и выбор средств противостояния. Построение тестового стенда.

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

        • Атаки DDoS и методы противодействия

          Вряд ли найдется хоть одно предприятие, независимо от его сферы деятельности, где не применяются интернет технологии. Для многих компаний невозможность или трудности работы в сети приводят к катастрофическим последствиям, чем не преминули воспользоваться злоумышленники и конкуренты, проводя целый комплекс атак, приводящих к весьма серьезным неприятностям. Так что же это за атаки и почему они нередко оказываются весьма успешными? Как им противостоять? В качестве примера возьмем интернет-магазин как наиболее простой и понятный вариант. Пусть достигнуты отличные результаты, интернет-магазин имеет успех. Вдруг вы заметили сокращение объема заказов. Стали поступать жалобы от постоянных клиентов, что сайт магазина не отвечает или работает крайне медленно. Эта ситуация начинает повторяться все чаще. Наконец, практически все время к магазину становится невозможно получить доступ. В чем же дело? Вы оказались слишком успешны. Вам объявили кибервойну! Следует иметь в виду, что ни одна из сфер деятельности не осталась без внимания злоумышленников. Атакам подвергаются не только интернет-магазины, но и финансовая сфера, сайты учебных заведений, медицинских учреждений, некоммерческих организаций и многие другие. Надо сказать, что нечестные методы конкурентной борьбы стали гораздо совершеннее, и развитие IT технологий не только предоставило нам новые эффективные инструменты ведения бизнеса, но и создало новое оружие для борьбы с ним. Можно весьма эффективно уничтожать конкурентов, не прибегая к еще недавно столь популярным методам «грубой силы». Теперь на службе у преступников информационные технологии… Здесь речь идет о DDoS атаках, жертвами которых мы и оказались.

          • Внедрение Инфраструктуры Открытых Ключей на основе Windows Server 2016

            Внедрение собственной инфраструктуры открытых ключей часто становится одной их задач, которую приходится решать ИТ отделам предприятия. Причины этого вполне объяснимы: тут и вопросы безопасной аутентификации, защиты передаваемых и хранимых данных, потребность в использовании электронной цифровой подписи, и другое. Далеко не всегда эти задачи могут быть решены средствами внешних поставщиков, несмотря на очевидную тенденцию развития облачных решений.

            • Microsoft DirectAccess 2012: DirectAccess и Windows 8

              ed31_earth_in_my_room

              В прошлой статье я постарался в понятной форме рассказать о технологии DirectAccess, о ее плюсах и минусах. Теперь, как и обещал, расскажу о том, каким образом настроить сервер DirectAccess в базовой конфигурации для работы только с клиентами Windows 8. Что значит в базовой конфигурации? Это когда у вас есть Windows Server 2012 на котором будет поднята роль для DirectAccess и  клиенты (с операционной системой Windows 8 Enterprise) имеющие  прямое подключение к интернету . В базовой конфигурации не будет использоваться инфраструктура открытых ключей (PKI) и  используется только одна входная точка (сервер DirectAccess), подключенная в одном сайте Active Directory. Так же в базовую конфигурацию не могут входить дополнительные опции, такие как двухфакторная аутентификация (OTP Auth), проверка доступа к сети (NAP). Ну и самое важное – в ней не могут использоваться клиенты Windows 7.

              • Microsoft DirectAccess 2012: Введение

                ed31_earth_in_my_room

                Время не стоит на месте, и мы, что бы не отставать от современного ритма, должны быть активными и мобильными. Для организаций любого уровня становится все  более важным иметь простой и  безопасный способ подключения удаленных и мобильных клиентов к внутренней сети предприятия. Одной из распространенных технологий удаленного доступа  является  VPN, хотя можно было обойтись и без него, используя  прямые подключения средствами RDP, Radmin, Ammyy и тому подобных вещей. Теперь в списке появляется значимая альтернатива – Microsoft DirectAccess 2012. Число 2012 говорит нам о том, что это сервис включенный в новую редакция сервера Windows Server 2012. Это важно, потому что DirectAccess уже был реализован в 2008 R2, но с кучей нюансов и серьезных требований к инфраструктуре предприятия, где внедряли DirectAccess 2008 R2. Именно поэтому  я специально сказал, что только теперь появилась альтернатива для удаленного подключения клиентов, и сейчас объясню почему.

              • Главная Networks, Virtualization, Без рубрики, Новое Virtualization, VMware, виртуализация
                • Виртуальные сети в VMware vSphere. Standard vSwitch — часть 2

                  Продолжаем знакомиться с вирутальной сетевой инфраструктурой VMware vSphere. В этом посте мы рассмотрим расширенный функционал, предлагаемый VMware для vSwitch.

                  Начнем с функций обеспечения безопасности:

                  • Security
                    • * Promiscuous mode enable/disable
                    • * MAC Address Change enable/disable
                    • * Forged Transmit enable/disable

                  Promiscuous Mode

                  Wikipedia описывает Promiscuous mode как «неразборчивый» режим, в котором сетевая плата позволяет принимать все пакеты независимо от того, кому они адресованы. Этот режим используется в анализаторах сетевого трафика. Однако у нас не конкретная машина и сетевой адаптер, а vSwitch – L2 коммутатор. Хотя в целом режим похож, но он куда ближе к Port mirroring, пересылке всего трафика с указанного порта на выделенный, к которому подключают анализатор. При включении Promiscuous Mode на уровне vSwitch (портгруппы) vNIC (сетевой интерфейс ВМ) получает все пакеты, проходящие через vSwitch (портгруппу). Попробую это проиллюстрировать.

                • Главная Networks, Virtualization, Без рубрики VMware, виртуализация
                  • Виртуальные сети в VMware vSphere. Standard vSwitch – часть 1.

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

                    Ключевой компонент виртуальной сетевой инфраструктуры vSphere – vSwitch, виртуальный L2 коммутатор. vSwitch бывает двух типов – Standard vSwitch, и c выходом vSphere 4.0 появился vNetwork Distributed vSwitch (vDS). Мы будем рассматривать Standard vSwitch, присутствующий в любой редакции vSphere, в том числе и бесплатной.

                    vSwitch работает под управлением гипервизора (vmkernel) и отвечает за все сетевые операции хоста, в том числе он обеспечивает прохождение управляющего трафика. Все сетевые компоненты ESX(i) хоста подключаются к vSwitch через “портгруппы”, о которых мы поговорим позже. Также обращаю ваше внимание, что по умолчанию разговор пойдет об устройстве сети в ESX, на 95% совпадающем с ESXi.

                  • Главная Networks, Windows, Без рубрики, Новое Active Directory, Windows 2008 R2
                    • Вопросы по Active Directory + Ответы

                      logo Нашел в себе силы написать ответы на вопросы. Старался как можно полнее и яснее ответить на эти вопросы. Но сами понимаете, это достаточно трудно, да и если все детально описывать, то получится очередной resource kit. Пытался больше сосредоточиться на вопросах связанных с логикой работы AD, на другие вопросы предоставил ссылки в конце статьи. Большинство решений по вопросам проверены на практике или на стендах, на другие отвечал с использованием теории или логики. Будем верить, что теория не врет. По неясным вопросам готов пояснить дополнительно в комментариях («Истина рождается в споре»).