Azure MFA for RDG

Двухфакторная аутентификация клиентов Remote Desktop Gateway при помощи Azure Multi-Factor Authentication

Про пользователей и методы защиты

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

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

Решение с использованием терминального сервера и Remote Desktop Gateway (RDG) более гибкое, можно настроить высокий уровень безопасности. Данный способ позволяет предотвратить передачу данных из облака, но накладывает ограничения на работу пользователя и не полностью решает проблему аутентификации, скорее это DLP решение.

Возможно лучшим способом гарантировать, что под учетной записью пользователя не работает злоумышленник, является двухфакторная аутентификация. Настройка MFA от Microsoft и Google для клиентского VPN — способ хороший, но, во-первых, он требует наличия CISCO ASA, что не всегда легко реализуемо, особенно в бюджетных облаках, а во-вторых, работа через VPN неудобна. Работа с терминальной сессией через RDG значительно комфортнее, да и SSL протокол шифрования выглядит более универсальным и надежным, чем VPN от CISCO.

Решений с двухфакторной аутентификацией на самом терминальном сервере много, вот пример настройки бесплатного решения — http://servilon.ru/dvuhfaktornaya-autentifikaciya-otp/. Это решение, к сожалению, не работает через RDG.

Преимущества Microsoft Azure Multi-Factor Authentication Server (MFAS) описаны в вышеупомянутой статье, поэтому приводить повторно я их не буду, а начнём сразу с настроек.

Чтобы не увеличивать объём данной статьи, опустим первоначальную установку и настройку RDG сервера, который авторизует пользователей по логину и паролю.

Для ясности приведем схему аутентификации RDG запроса при использовании Azure MFA. На сервере RDG запущенна роль Network Policy Server (NPS), позволяющая перенаправлять Radius запросы. Сервер MFA будет развернут в отдельной виртуальной машине во внутренней структуре предприятия.

Shema RDG zapros

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

Установка и настройка Azure Multi-Factor Authentication Server

Создание поставщика аутентификации в портале Microsoft Azure

Заходим в Microsoft Azure (учетная запись должна иметь подписку или установлена триальная версия) и находим Multi-Factor Authentication (MFA).

На данный момент управление MFA не добавлено в новую версия портала Azure, поэтому откроется старая версия портала.

Для создания нового поставщика многофакторной проверки подлинности необходимо слева внизу нажать «СОЗДАТЬ -> Службы приложений -> Active directory -> Поставщик многофакторной проверки подлинности -> Быстрое создание». Указать имя и модель использования.

От модели использования зависит как будет начисляться оплата, либо по количеству пользователей, либо по количеству аутентификаций.

sozdanie postavshika mpp

После создания MFA отобразится в списке. Далее переходим к управлению, нажав соответствующую кнопку.

azure active directory

Переходим в загрузки и скачиваем MFA сервер

download MFA

Развертывание MFA сервера

Устанавливать MFA сервер необходимо на виртуальную машину отличную от RDG сервера. Поддерживаются ОС старше Windows Server 2008 или Windows 7. Для работы необходим Microsoft .NET Framework 4.0.
Должны быть доступны адреса по 443 порту:

  • https://pfd.phonefactor.net;
  • https://pfd2.phonefactor.net;
  • https://css.phonefactor.net.

Устанавливаем MFA сервер, при установке отказываемся от мастера настроек.

При первом запуске необходимо ввести данные от учетной записи, которые надо сгенерировать на странице загрузки сервера.

dannye ot uchetnoj zapisi

Далее добавляем пользователей. Для этого переходим в раздел Users и нажимаем на Import from Active Directory, выбираем пользователей для импорта.

new MFA users

new MFA users

При необходимости можно настроить автоматическое добавление новых пользователей из АД:

«Directory Integration -> Synchronization -> Add», а т.ж. добавить каталог, который будет автоматически синхронизироваться по указанному интервалу времени.

add synchronization item

Проведем тест работоспособности MFA сервера. Переходим в раздел Users. Для своей учетной записи указываем номер телефона (если еще не задан) и выбираем способ аутентификации «Звонок телефона». Нажимаем кнопку Test и вводим логин, пароль. На телефон должен прийти вызов. Отвечаем на него и нажимаем #.

test users MFA

Настройка MFA сервера на работу с Radius запросами

Переходим в раздел Radius Authentication и ставим галочку «Enable RADIUS Authentication».

Добавляем нового клиента, указывая IP адрес NPS сервера и общий секретный ключ. Если аутентификация должна проводиться для всех пользователей, ставим соответствующую галочку (в данном случае все пользователи должны быть добавлены на MFA сервер).

Так же необходимо убедиться, что указанные для соединения порты соответствуют портам, указанным на NPS сервере и их не блокирует брандмауэр.

radius authentication

Переходим на вкладку Target и добавляем Radius сервер.

radius authentication target

Примечание: Если в сети нет центрального NPS сервера, IP адреса Radius клиента и сервера будут одинаковыми.

Настройка RDG и NPS сервера на работу совместно с MFA

Шлюз удаленных рабочих столов необходимо настроить на отправку Radius запросов на сервер MFA. Для этого открываем свойства шлюза и переходим на вкладку «RDG CAP Store», выбираем «NPS работает на центральном сервере» и указываем адрес MFA сервера и общий секретный ключ.

RDG CAP store

Далее производим настройку NPS сервера. Разворачиваем раздел «Клиенты и серверы Radius -> Удаленные группы серверов Radius». Открываем свойства группы «TS gateway server group» (группа создаётся при настройке RDG) и добавляем наш MFA сервер.

При добавлении, на вкладке «Load Balancing» увеличиваем лимиты времени ожидания сервера. Выставляем «Число секунд без ответа, после которого запрос считается отброшенным» и «Число секунд между запросами, после которого сервер считается недоступным» в диапазоне 30—60 секунд.

На вкладке «Authentication/Accounting» проверяем правильность указанных портов и задаем общий секретный ключ.

RDG Authentication/Accounting

RDG Authentication/Accounting

Теперь перейдем в раздел «Клиенты и серверы Radius -> Клиенты Radius» и добавим MFA сервер, указав «Friendly name», адрес и общий секрет.

Radius Friendly name

Переходим в раздел «Политики -> Политики запросов на подключение». В данном разделе должна быть политика, созданная при настройке RDG. Эта политика направляет запросы Radius на MFA сервер.

Дублируем политику и заходим в ее свойства. Добавляем условие сопоставляющее «Client Friendly Name» c «Friendly name», заданным в предыдущем шаге.

Radius policy properties

На вкладке «Settings» меняем поставщика услуг аутентификации на локальный сервер.

Radius policy properties settings

Данная политика будет гарантировать то, что при получении Radius запроса от MFA сервера, запрос будет обработан локально, что избавит от зацикливания запросов.

Проверяем что данная политика размещена над исходной.

NPS policy

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

Установка SDK, веб-службы мобильного приложения и пользовательского портала

Подключение к данным компонентам производиться по HTTPS протоколу. Поэтому, на сервера где они будут развернуты, необходимо установить SSL сертификат.

Пользовательский портал и веб-служба мобильного приложения используют пакет SDK для связи с сервером MFA.

Установка SDK

SDK устанавливается на сервер MFA и требует наличия IIS, ASP.NET, Basic Authentication, которые необходимо предварительно установить, используя Server Manager.

Для установки SDK переходим в раздел Web Service SDK в Multi-Factor Authentication Server и нажимаем кнопку установить, следуем мастеру установки.

Web Service SDK в Multi-Factor Authentication Server

Установка веб-службы мобильного приложения

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

Файл установки службы находиться в папке C:\Program Files\Azure Multi-Factor Authentication на компьютере с установленным MFA. Запускаем установщик и следуем мастеру установки. Для удобства пользователей можно заменить имя виртуального каталога «MultiFactorAuthMobileAppWebService» на более короткое.

После установки заходим в папку C:\inetpub\wwwroot\MultiFactorAuthMobileAppWebService и изменяем файл web.config. В данном файле необходимо задать ключи WEB_SERVICE_SDK_AUTHENTICATION_USERNAME и WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD, отвечающие за учетную запись, входящую в группу безопасности PhoneFactor Admins. Эта учетная запись будет использоваться для подключения к SDK.

edit web.config

В этом же файле необходимо указать URL адрес по которому доступен SDK.

Примечание: Соединение с SDK производиться по SSL протоколу, поэтому необходимо ссылаться на SDK по имени сервера (указанному в SSL сертификате), а не по IP адресу. Если обращение осуществляется по локальному имени, нужно добавить в hosts файл соответствующую запись, чтобы использовать SSL сертификат.

edit web.config

Добавляем URL, по которому доступна веб-служба мобильного приложения, в приложение Multi-Factor Authentication Server в раздел Mobile App. Это необходимо для правильной генерации QR кода в пользовательском портале для подключения мобильных приложений.

Также в этом разделе можно установить галочку «Enable OATH tokens», что позволить использовать мобильное приложения как Software token, для генерации одноразовых паролей на основании времени.

Установка пользовательского портала

Для установки требуется IIS, ASP.NET и роль совместимости мета базы IIS 6 (для IIS 7 или более поздней версии).

Если портал устанавливается на сервере MFA, достаточно в Multi-Factor Authentication Server перейти в раздел User Portal, нажать кнопку установить и следовать мастеру установки. Если компьютер присоединен к домену, то при установке будет создан пользователь, входящий в группу безопасности PhoneFactor Admins. Этот пользователь необходим для защищённого соединения с SDK.

MFA UserPortal

При установке на отдельный сервер, необходимо скопировать файл установки с сервера MFA (файл установки располагается в папке C:\Program Files\Multi-Factor Authentication Server). Произвести установку и отредактировать файл web.config в расположение C:\inetpub\wwwroot\MultiFactorAuth. В данном файле необходимо изменить ключ USE_WEB_SERVICE_SDK со значения false на true. Указать данные учетной записи, входящей в группу PhoneFactor Admins в ключах WEB_SERVICE_SDK_AUTHENTICATION_USERNAME и WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD. И указать URL адрес SDK службы, не забывая при необходимости поправить hosts файл, чтобы работал SSL протокол.

Добавляем URL, по которому доступен пользовательский портал в приложение Multi-Factor Authentication Server в раздел User Portal.

Демонстрация работы Azure MFA для аутентификации RDG подключений

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

Первым делом, пользователю понадобиться зайти на пользовательский портал и указать свой номер телефона (если не указан в AD) и привязать к аккаунту мобильное приложение. Заходим на портал под своей учетной записью и вводим ответы на секретные вопросы (они нам понадобятся в случае восстановления доступа к аккаунту).

MFA UserPortal test

Далее выбираем метод аутентификации, в нашем случае мобильное приложение и нажимаем кнопку «Создать код активации». Будет сгенерирован QR код, который надо отсканировать в мобильном приложении.

MFA UserPortal test

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

MFA UserPortal test

Примечание: Список настроек, которые может менять пользователь через портал, задаётся администратором в приложении Multi-Factor Authentication Server.

Далее рассмотрим подключение через RDG.

Создаем RDP подключение, указываем наш шлюз и подключаемся.

RDP connection

RDP connection

Вводим данные учетной записи для авторизации на RDG сервере.

RDP connection

Подтверждаем запрос в мобильном приложении

RDP connection

Вводим данные учетной записи для авторизации на подключаемой машине и ожидаем подключения.

RDP connection

RDP connection

Примечание: Если телефон оснащен датчиком отпечатка пальца, приложение Authenticator предложит связать PIN код с отпечатком пальца, чтобы в последующем подтверждать аутентификацию простым прикосновением к телефону.

Способы аутентификации, которые предлагает Azure MFA:

    • Звонок телефона

    • нажатие #
    • ввод PIN кода и нажатие #
    • SMS – можно использовать OTP или OTP + PIN

    • One-Way – полученный код необходимо ввести в дополнительное поле при авторизации
    • Two-Way – полученный код необходимо отправить обратно SMS сообщением
    • Мобильное приложение

    • Простое подтверждение
    • Для подтверждения необходимо ввести PIN код
  • OATH token – при авторизации необходимо будет ввести в дополнительное поле код с экрана токена. В качестве токена можно использовать мобильное приложение.

Способы SMS One-Way и OATH token не являются универсальными, так как требуют дополнительного поля для ввода кода при авторизации.

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

На портале Azure в панели управления MFA можно включить возможность, позволяющую пользователям отмечать пришедший запрос на аутентификацию как мошеннический. Также возможна автоматическая блокировка пользователя при получении данного сообщения и отправка email уведомления службе поддержки.

MFA portal

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

MFA portal

MFA portal

В панели управления Azure MFA есть отчет отображающий уведомления о мошенничестве:

Report Azure MFA

Если необходимо узнать IP адрес, с которого была инициализирована RDP сессия, можно посмотреть логи RDG сервера в Event Viewer. Если второй фактор аутентификации не был пройден, событие будет иметь статус Error, а в описании будет указан IP адрес, с которого устанавливалось RDP соединение.

MFA error 23003

Ссылки по статье:

Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS
User Portal
Mobile App Web Service

C уважением коллектив компании Servilon

Другие статьи на тему двуфакторной аутентификации

Azure MFAS

Настройка Microsoft Azure Multi-Factor Authentication Server (MFAS) в качестве второго фактора аутентификации

Почему именно MS Azure?

  1. Лучшая интеграция с AD, что очень удобно, когда для VPN используется та же учетная запись, что и для остальных ресурсов.
  2. Разные типы аутентификации, звонок, SMS приложение и офлайн OTP код.
  3. Простота настройки.
  4. Высокая надежность и доверие.

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

Настройка Microsoft Azure

Приведенные ниже шаги предполагают, что у Вас имеется подписка или же установлена триальная версия Microsoft Azure.

Перейдем непосредственно к настройке:

  1. Заходим на портал управления Azure.

Azure active directory

  1. Переходим на вкладку Active Directory -> Поставщики многофакторной проверки подлинности -> Быстрое создание. Указываем необходимые параметры и далее «создать».

Azure создать

После создания, будет доступна кнопка «Управление», переходим:

Azure Управление

  1. Переходим в загрузки. Скачиваем MULTI-FACTOR AUTHENTICATION SERVER.

Также нужно создать учетную запись для активации сервера.

Azure создание учётной записи

Для установки данного сервера понадобится .NET Framework 2.0.

Важно: Устанавливать рекомендуется на отдельную VM. При установке пропускаем мастер настройки.

Функции сервера: синхронизация пользователей с AD, RADIUS server для Cisco ASA, отправка запросов на авторизацию по второму фактору, прием и обработка ответов от клиентов, авторизация пользователей.

Может устанавливаться как на серверные версии, так и на клиентские.

  1. При первом запуске активируем с помощью ранее сгенерированной учетной записи (от репликации на данном этапе отказываемся).
  2. Настраиваем интеграцию пользователей между AD и нашим сервером. Во вкладке Directory Integration добавляем каталог, который будет синхронизироваться с AD и настраиваем параметры синхронизации:

Azure synchronization item

MFAS

  1. В AD создаем пользователя и синхронизируем Базу пользователей с MFAS:
    а) создаем тестового пользователя и указываем номер телефона:

MFAS user test

б) Сохраняем, нажимаем кнопку «Test..» во вкладке Users. Вводим учетные данные пользователя:

Test user

в) На указанный телефон получаем звонок, нажимаем «#». Об успешном завершении теста свидетельствует сообщение:

one-time passcode

Также проверить авторизацию можно через SMS. Для этого, в настройках клиента, необходимо указать способ авторизации Text message – One-Way – OTP. В данном случае MFAS запросит OTP, который в виде SMS придет Вам на телефон.

81

Для того, что бы связать пользователя с мобильным устройством, на котором установлен Azure Authenticator, понадобится развернуть и настроить User Portal (Инструкция по установке и настройке User Portal).

Так же необходимо дополнительно установить и настроить Mobile Portal:

а) Переходим в директорию C:\Program Files\Multi-Factor Authentication Server

б) Выбираем необходимую версию и устанавливаем.

в) После установки редактируем файл:

С:\Inetpub\wwwroot\MultiFactorAuthMobileAppWebService\Web.conf

Находим параметры:

WEB_SERVICE_SDK_AUTHENTICATION_USERNAME
WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD

И меняем значения аналогично параметрам User Portal.

Также в разделе pfup, параметр <valuе>… </valuе> изменяем по аналогии с User Portal — <valuе>…</valuе>. В нашем случае «EXTERNALFQDN» — это mfa.servilon.com

Стоит отметить, что для работы User Portal необходимо:

– Запись во внешней DNS зоне, которая будет указывать на User Portal.

– Доверительные отношения с сервером. В идеале — это «белый» сертификат выписанный для «EXTERNALFQDN».

  1. После установки и настройки, для корректной работы User Portal, вводим URL на портал во вкладке «User Portal» и, если авторизация для доменных пользователей, указываем Primary authentication – Windows Domain.

MFAS user portal

  1. Во вкладке Mobile App вводим URL Mobile App Web Service и устанавливаем галочку Enable OATH tokens, если хотим использовать мобильное устройство как Software token.

Принцип работы APP:

  • В режиме Token

APP Token

  • В стандартном режиме без PIN

APP без PIN

  1. После того как портал настроен, для привязки мобильного устройства, переходим по ссылке User Portal, в данном случае

MFA user log in

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

  1. В меню Activate Mobile App переходим в Generate Activation Code. Генерируем новый код активации и в результате получаем:

MFA Active mobile app

На мобильном устройстве должно быть установлено приложение Azure Authenticator (ссылки для iOSAndroid иWindows Mobile).

Запускаем приложение – нажимаем + и считываем QR код. В результате учетная запись подвязывается к мобильному устройству:

Проверка на сервере:

MFAS edit user

Теперь можно поэкспериментировать с различными режимами аутентификации и посмотреть, в чем же отличие режима Standard от «OATH token».

MFAS edit user

Настройка Radius

Для аутентификации пользователей AnyConnect Cisco ASA может использовать сторонний Radius сервер. Для этого на ASA необходимо настроить AAA Server, а на MFAS настроить Radius клиент:

MFAS Radius

MFAS Radius

Настройка CISCO ASA

Так как используется доменная аутентификация, ASA должна иметь доверительные отношения с доменом. А также рекомендуется использовать «белый» сертификат для VPN gateway. В нашем случае – vpn.servilon.co

На ASA рекомендуем настроить AnyConnect VPN gateway с локальной аутентификацией. Убедиться, что подключение работает, после чего приступить к настройке аутентификации через Radius.

После чего настраиваем RADIUS. Переходим на Configuration / Remote Access VPN / AAA/Local Users / AAA Server Groups и создаем группу:

edit AAA server

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

edit AAA server group

Тестируем связку с RADIUS сервером:

Test AAA server

При успешном тесте, на ранее настроенном «AnyConnect Connection Profiles» меняем аутентификацию с локальной на новую группу:

AnyConnect Connection Profiles new group

Настройка профиля:

  1. Сменить таймаут:

AnyConnect Connection Profiles editor

  1. Указать FQDN для Anyconnect gateway.

AnyConnect Connection Profiles editor

Для того, чтобы протестировать подключение с аутентификацией в стандартном режиме и режиме OATH token, подключаемся к FQDN и вводим доменные учетные данные

FQDN

Получаем запрос на ввод кода с мобильного приложения:

991

Если же используется стандартный режим без PIN, то в приложение придет запрос на подтверждение аутентификации:

MFAS confirmation

После проверки второго фактора происходит аутентификация пользователя. Аутентификация успешна:

Successful authentication

В данной статье рассмотрен пример настройки двухфакторной аутентификации пользователей для приложения Cisco AnyConnect, но данная схема может быть реализована для любых сервисов, поддерживающих аутентификацию посредством протокола Radius.

Другие статьи на тему MS Azure

Two Factor Authentication

Двухфакторная аутентификация для терминальных серверов

Грамотный подход к обеспечению IT безопасности в плане авторизации на своих серверах внутри компании и за ее пределами, подразумевает целый ряд мер, таких как: обеспечение уникальности имени пользователя, требований сложности и плановую замену пароля, неразглашение учетных данных сторонним лицам и т.д. Но зачастую бывает так, что пользователь быстро забывает про все это, и для своего удобства вешает бумажку с логином и паролем на видном месте, например, на своем мониторе. Что может оказаться вполне удобным для злоумышленника, желающего получить доступ к данным.

Конечно, существует целый ряд мер, в том числе административных, чтобы данная ситуация не привела к утечке информации. Мы же рассмотрим другой подход.

Радикальным решением является применение двухфакторной аутентификации, основанной на генерации одноразовых паролей.

Одноразовый пароль (англ. one time password, OTP) это пароль, действительный только для одного сеанса аутентификации.

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

Используемые продукты

В качестве примера, рассмотрим реализацию внедрения OTP пароля, основанном на проекте multiOTP – опенсорсовом софте PHP, умеющим работать на стандартных алгоритмах, которые хорошо себя зарекомендовали в индустрии обеспечения многофакторной аутентификации (HOTP, TOTP, OCRA).

Для обеспечения дополнительного поля ввода OTP пароля в окне входа в систему Windows будем использовать плагин MultiOneTimePassword-CredentialProvider.

Пользователь будет генерировать одноразовые пароли у себя на мобильном устройстве с помощью  Google Authenticator.

Установка multiOTP

Скачиваем продукт multiOTP и размещаем содержимое папки windows (из скачанной директории) в корень системного диска: C:\multiotp.

Вся настройка происходит через командную строку. Запускаем CMD от имени администратора и переходим в нашу директорию:

cmd help

Далее приводится список команд для настройки и синхронизации сервиса multiOTP с Active Directory:

  1. C:\multiotp>multiotp -config default-request-prefix-pin=0

Ввод ПИН-кода по умолчанию, при создании новых пользователей (1 | 0)

  1. C:\multiotp>multiotp -config default-request-ldap-pwd=0

Использование пароля Active Directory вместо ПИН-кода по умолчанию(1 | 0)

  1. C:\multiotp>multiotp -config ldap-server-type=1

Выбор сервер AD/LDAP (1=Active Directory | 2=standart LDAP )

  1. C:\multiotp>multiotp -config ldap-cn-identifier=»sAMAccountName»

CN идентификатор пользователя (sAMAccountName, eventually userPrincipalName)

  1. C:\multiotp>multiotp -config ldap-group-cn-identifier=»sAMAccountName»

CN идентификатор группы (sAMAccountName for Active Directory)

  1. C:\multiotp>multiotp -config ldap-group-attribute=»memberOf»

Атрибут, определяющий принадлежность к группе

  1. C:\multiotp>multiotp -config ldap-ssl=0

Использование SSL соединения по умолчанию (0 | 1)

  1. C:\multiotp>multiotp -config ldap-port=389

Порт подключения (389 = standart | 636 = SSL connection)

  1. C:\multiotp>multiotp -config ldap-domain-controllers=servilon.com,ldaps://192.168.254.10:389

Указываем сервер(а) Active Directory

  1. C:\multiotp>multiotp -config ldap-base-dn=»DC=SERVILON,DC=COM»

Указываем суффикс домена

  1. C:\multiotp>multiotp -config ldap-bind-dn=»CN=Administrator,CN=Users,DC=servilon,DC=com»

Аккаунт, под которым подключаемся к AD DS.

  1. C:\multiotp>multiotp -config ldap-server-password=»P@$$w0rd»

Пароль, под которым подключаемся к AD DS.

  1. C:\multiotp>multiotp -config ldap-in-group=»OTP»

Группа, пользователи которой будут использовать OTP для входа на сервер.

  1. C:\multiotp>multiotp -config ldap-network-timeout=10

Таймаут ожидания синхронизации в секундах.

  1. C:\multiotp>multiotp -config ldap-time-limit=30

Таймаут смены OTP пароля на новый.

  1. C:\multiotp>multiotp -config ldap-activated=1

Включение поддержки AD/LDAP сервисом multiotp.

  1. C:\multiotp>multiotp -debug -display-log -ldap-users-sync

Синхронизация пользователей с AD/LDAP. Последнюю команду необходимо запускать каждый раз при добавлении новых пользователей или настроить в виде запуска скрипта по расписанию.

Если все команды введены корректно и сервер AD/LDAP доступен, то последняя команда должна показать синхронизацию и создание новых пользователей для сервиса multiotp:

cmd sync

Настройка Google Authenticator

Теперь необходимо передать уникальный ключ пользователя на устройство пользователя. Удобней всего это сделать через QR код. Для этого нам необходимо установить web-server который нам поможет в просмотре и регистрации пользователей. Просто заходим в папку multiotp и запускаем webservice_install.cmd, после чего должен открыться браузер с консолью администрирования. После входа, мы можем создать нового локального пользователя или просмотреть список существующих, что весьма полезно:

multiOTP web console

Но самое главное, вэб-консоль поможет нам зарегистрировать пользователя на мобильном устройстве. Нажимаем “Print” в строке необходимого пользователя и на новой вкладке мы видим QR код, сгенерированный для данного пользователя:

multiotp web console user

Сканируем полученный QR код с помощью Google Authenticator. Регистрация завершена.

Как видите все просто, можно например, переслать QR код пользователю почтой и он сам справится с регистрацией. Если все прошло успешно, та на экране мобильного устройства будет доступен OTP пароль, который обновляется каждые 30 секунд:

Google authenticator

Установка MultiOneTimePassword-CredentialProvider

Теперь необходимо указать нашему серверу Terminal дополнительно использовать OTP пароль при аутентификации пользователя. Для этого запускаем ранее скачанный установщик MultiOneTimePassword-CredentialProvider, где нам требуется лишь указать установку Default Provider и папку с сервисом multiotp:

MultiOneTimePassword provider

MultiOneTimePassword provider conf

Важно! После установки CredentialProvider, пользователи, которые не получили настройку OTP не смогут зайти на сервер. Поэтому необходимо позаботится чтобы у учетной записи администратора был также настроен OTP пароль.

Результаты

login

Теперь наш сервер Terminal получил дополнительный уровень безопасности в виде внедрения OTP пароля на базе бесплатного решения проекта multiOTP и multiOTP-Credential Provider.

Данное решение вполне можно развернуть и на самом ПК пользователя, выставив барьер для злоумышленника при попытке входа на рабочем месте сотрудника.

Другие статьи на тему двуфакторной аутентификации

it outsoursing control logo

ИТ-Аутсорсер под колпаком

Меры безопасности при внедрении ИТ-аутсорсинга в компании.

Задача – не бояться, а контролировать

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

it outsoursing control

Переход на аутсорсинг ИТ потребует от компании пересмотра  организации рабочего процесса с целью установления взаимодействия с  ИТ-службами. Кроме того компании следует учитывать риски, связанные с передачей контроля своих структур (администрировании серверов, сетей, всех ключевых учетных данных и т.д) сторонней ИТ-службе и ее сотрудникам. Другими словами, компания предоставляет существенные рычаги управления своим бизнесом посторонней компании, в надежности которой нет 100% гарантии.

Как минимизировать возникающие риски? Этот вопрос изучен глубже, чем может показаться на первый взгляд. Для минимизации возникающих рисков есть несколько мер контроля: организационные и технические.
К организационным мерам относятся создание в организации подразделения “IT Government” – своеобразного «правительства», и определение его полномочий, как то: координация действий подрядчиков, надзор за ними и при необходимости влияние на их действия, вплоть до отмены и блокировки.

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

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

Компания Сайт Продукты
TSFactory (США) https://www.tsfactory.com/ RecordTS – аудит и запись терминальных сессий (Terminal Services, Citrix, vWorkSpace)
ObserveIT (США-Израиль) http://www.observeit.com/ Visual session recording – аудит, алертинг и запись пользовательских сессий на Windows- и Unix-серверах
СensorNET (Великобритания-США) https://www.censornet.com/ Desktop Monitoring – онлайн-мониторинг, аудит и запись действий пользователей.
BalaBit (США-Венгрия) https://www.balabit.com/ Shell Control Box – аппаратно-программный комплекс контроля, аудита и записи удаленных сессий

Предлагаем детальнее рассмотреть  самое интересное, на наш взгляд, решение  —  BalaBit Shell Control Box.

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

SCB—инструмент наблюдения за администраторами серверов и процессами администрирования серверов посредством управления зашифрованными подключениями, используемыми в администрировании серверов.

SCB полностью контролирует подключения SSH, RDP, Telnet, TN3270, Citrix ICA и VNC, создавая четкий набор функций и контролируемый уровень доступа для администраторов.

BalaBit Shell Control Box – возможное решение

Из представленного выше списка Shell Control Box выделяется тем, что не является просто набором агентов для клиентских и серверных машин. Shell Control Box (SCB)—это самостоятельное устройство, осуществляющее контроль, мониторинг и аудит удаленного административного доступа к серверам, которое полностью прозрачно и независимо от клиентов и серверов.

SCB—инструмент для осуществления наблюдения за администраторами серверов и процессами администрирования серверов посредством управления зашифрованными подключениями, используемыми в администрировании серверов. SCB полностью контролирует подключения SSH, RDP, Telnet, TN3270, Citrix ICA и VNC, создавая для работы администраторов соответствующую среду с четкими границами. В число наиболее значимых характеристик SCB входит следующее:

  • Возможность отключения нежелательных каналов и функций (например, переадресация
    портов TCP, передача файлов, VPN и т. д.);
  • Контроль за использованием выбранных методов аутентификации;
  • Требование внешней аутентификации на шлюзе SCB;
  • Внедрение авторизации с возможностью мониторинга и аудита в режиме реального времени;
  • Аудит выбранных каналов в зашифрованных, снабженных метками времени и цифровой
    подписью аудит-трейлов;
  • Получение информации о принадлежности пользователей к той или иной группе через базу
    данных LDAP;
  • Проверка ключей и сертификатов хоста серверов, к которым получен доступ SCB, настраивается и управляется при помощи любого современного веб-браузера.

Посмотрим на возможную схему включения SCB в ИТ-инфраструктуру компании:

Схема включения SCB

(В данной схеме компания использует в качестве мониторинга один сервер(Сервер1) с помощью продукта SCB с целью уменьшения количества хостов в оплачиваемой лицензии. К остальным серверам(Сервер 2-4) ИТ-администратор подключается через Сервер 1).

Наш SCB сервер настроен в качестве шлюза удаленных рабочих столов. При попытке получить доступ к серверу, администратор проходит аутентификацию на сервере SCB и, в случае успеха, дополнительную проверку на сервере. Далее, администратор с подконтрольного сервера выполняет различные подключения к другим серверам, которые также фиксируются сервером SCB.

Весь административный и контрольный функционал Shell Control Box доступен через веб-интерфейс:

Shell Control Box

Shell Control Box

После того, как сервер SCB сконфигурирован, весь трафик, проходящий через него, автоматически записывается. SCB имеет единый интерфейс для просмотра и изменения конфигурации, отчетов, аудит-трейлов.

Shell Control Box

SCB предоставляет возможность просмотреть аудит прошлых подключений, а также мы можем экстренно завершить текущие подключения к серверам или наблюдать за действиями удаленных администраторов в режиме on-line

Shell Control Box audit

Для удобного просмотра Аудит-трейлов на любом компьютере существует Audit Player, который позволяет просматривать сохраненные ранее видеозаписи подключений. Скриншот ниже демонстрирует просмотр видео на Audit Player, когда удаленный администратор выполнил RDP сессию с сервера, который находится под мониторингом, на другой сервер в сети:

Audit Player

Рассмотрим пример. В процессе рабочего дня произошла незапланированная остановка бизнес-критического сервиса. Нам известно время, когда это произошло, и сервер, который отвечает за этот сервис.

Заходим на веб-интерфейс в раздел поиска. Выставляем нужную нам дату, время, тип протокола:

Shell Control Box test

Находим нужную нам сессию.

Shell Control Box test

Мы можем выполнить быстрый просмотр после рендеринга и, при необходимости, скачать видеозапись rdp-подключения.

Shell Control Box test

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

Сделаем выводы

На примере функциональности BalaBit Shell Control Box мы постарались продемонстрировать, как создать дополнительное звено безопасности, обеспечивающее полноценный контроль и аудит ИT-компаний, выполняющих работы по обслуживанию серверов, с возможностью наглядной демонстрации выполняемых действий на серверах.

Может показаться, что такой строгий аудит в отношении ИТ-подрядчика разрушает доверительные отношения при предоставлении услуг, но на самом деле ситуация ровно обратная – любое доверие, как известно из старой русской пословицы, должно быть подкреплено прозрачностью и возможностью проверки, и качественные ИТ-аутсорсеры должны всячески приветствовать такие меры контроля со стороны клиента, поскольку они, в случае добросовестности подрядчика, позволяют еще лучше продемонстрировать эту добросовестность и закрепить доверительные партнерские отношения заказчика и аутсорсера. Мы как компания-аутсорсер кровно заинтересованы в том, чтобы наш клиент чувствовал себя в безопасности при работе с нами. Более того, мы готовы бесплатно разворачивать продукты подобного рода (разумеется, официально приобретенные) у заказчиков.

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

Другие статьи на тему ИТ-аутсорс

2f-authentication

Защита почты двуфакторной аутентифакцией

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

Что такое двухфакторная аутентификация и как она поможет?

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

SMS

Как работает двухфакторная аутентификация по SMS — достаточно много информации в интернете.

На мой взгляд, если потенциальная монетизация взлома вашего аккаунта не превышает 1000$, то такая защита вполне приемлема. В случае же если вы хотите защитить данные, представляющие большую ценность, то SMS не совсем подходящий способ. Может так случится, что ваш мобильный телефон будет похищен или заменена SIM, и, к тому времени как вы это заметите, вся ваша переписка уже будет скачана злоумышленником с сервера. Все помнят публикацию переписки Навального из учетной записи Gmail, которая была защищена подобным образом. Недавняя атака на пользователей мобильного клиента сбербанка наглядно продемонстрировала уязвимость этого способа.

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

Мобильное приложение

Аутентификация через мобильное приложение решает проблему защиты SIM карты от копирования или похищения и удобнее для путешествующих. Но остальные проблемы остаются.

OTP

ОТП (One Time Password) устройства предоставляют, наверное, самую высокую степень защиты из всех способов. Особенно надежны те устройства, на которых необходимо ввести ПИН код перед использованием. Не зря все заботящиеся о своей репутации банки используют только их для клиентских финансовых операций.

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

Защита с помощью сертификата

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

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

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

Сертификаты могут быть как привязаны к USB токену (популярное решение у Российских банков), так и к пользовательскому устройству – на наш взгляд, более подходящее решение для корпоративных пользователей.

Естественно, данная технология применима только для корпоративной почты и является одним из компонентов в комплексе мер по защите информации.

Итак, что же можно защищать — почту на MS Exchange Server и клиентов, работающих с ней по active Sync и OWA. К огромному сожалению, MS Outlook в текущей версии не поддерживает данное решение.

Технически, двухфакторная аутентификация с использованием сертификата опирается на корпоративную инфраструктуру открытых ключей (PKI). Чтобы предоставить устройству доступ, системный администратор устанавливает выписанный пользователю сертификат, содержащий приватный ключ без возможности экспорта.  После этой операции пользователь уже может использовать веб интерфейс Exchange (OWA). Перейдя по соответствующей ссылке, пользователь получает запрос сертификата как первого фактора аутентификация, после чего вводит свои учетные данные в вэб-форме как второй фактор и получает доступ к своей учетной записи.

Чтобы иметь возможность использовать двухфакторную аутентификацию, мобильные устройства должны поддерживать протокол ActiveSync 12 и выше. На данный момент его поддерживают устройства:

  • Apple iPhone/iPad с версией iOS 6.x и выше
  • смартфоны и планшеты на Android 4.1.2 и выше
  • устройства с Windows Phone 7 и выше

Системный администратор предприятия, при помощи iPhone Configuration Utility (iPCU), устанавливает на устройства Apple заранее подготовленный профиль, содержащий все необходимые данные учетной записи и сертификаты пользователя и центра сертификации.

На устройствах под управлением Android и Windows Phone администратор устанавливает подготовленные цепочки сертификатов и производит настройку учетной записи пользователя, указывая, каким сертификатом пользователь будет авторизоваться. Для больших организаций процесс может быть автоматизирован при помощи выделенного Mobile Device Management (MDM) ПО, которое может управлять устройствами на различных платформах, например, BES 12.

Другие статьи на тему двуфакторной аутентификации

Ferma VDI

Установка белого сертификата на ферму VDI

Описание проблемы

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

Remote Desktop Connection error

Такая ситуация связана с тем, что внутренние сертификаты домена не являются доверенными для внешних пользователей. И зачастую внутреннее доменное имя отличается от внешнего.

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

Для решения поставленной проблемы необходимо использовать «белый» сертификат, выписанный доверенным Certificate Authority для фермы VDI. Имя данного внешнего сертификата и имена компьютеров VDI должны совпадать.

Решение Проблемы

Для начала нам понадобится wildcard сертификат вида *.yourcompany.com, приобретенный у доверенного центра сертификации.

Добавление нового DNS Суффикса в домене:

В DNS на контроллере домена добавляем новую Active Directory Integrated зону yourcompany.com, которая будет обслуживать внутренние запросы для новых имен серверов и виртуальных машин фермы VDI.

Для поддержания в домене дополнительного доменного суффикса необходимо внести изменения в атрибут msDS-AllowedDNSSuffixesна уровне домена. Необходимо добавить внутреннее и внешнее имена домена как значения атрибута, например, yourcompany.local иyourcompany.com.

На уровне домена создаем новую групповую политику для указания DNS суффиксов, которые будут добавляться к коротким именам машин при DNS запросах.

22

Следующую политику необходимо включить и добавить через запятую значения внутреннего доменного имени и внешнего доменного имени: Computer Configuration \ Policies \ Administrative Templates \ Network\ DNS Clien\ DNS suffix search list.

Установка сертификата на RD сервера

Перед созданием VDI фермы необходимо выполнить смену DNS суффикса планируемых RD серверов на имя внешнего домена. Для этого перейдем в свойства компьютера и выберем изменить имя компьютера. В окне изменения имени компьютера необходимо нажать на кнопку More… и задать новый первичный DNS суффикс компьютера — yourcompany.com.

Далее создаем новую ферму VDI, основываясь на выбранных серверах Microsoft Windows Server 2012 R2.

Информацию по данной процедуре можно легко найти в сети.

После того, как pfx файл сертификата будет на руках, можно приступить к установке его на новую VDI ферму.

На сервере RD Connection Broker переходим Server Manager -> Remote Desktop Services -> Overview. В поле Deployment Overview ввыпадающем списке TASKS выбираем Edit Deployment Properties.

Открываем вкладку Certificates и устанавливаем необходимый сертификат *.yourcompany.com для всех сервисов фермы. Добавление производится по одному за действие. Выбираем существующий сертификат, указываем его путь на файловой системе и пароль.

После чего данные сертификаты будут установлены на серверах VDI, но не на виртуальных машинах. В реестре на Connection Broker сервере появится SSLCertificateSHA 1Hash REG_BINARY параметр со значением thumbprint сертификата по следующему адресу:<

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp.

Данный параметр отвечает за выбор сертификата, который будет использоваться при установке RDP сессии. Это параметр необходимо будет установить и на клиентские машины.

Машины

Для использования белого сертификата на виртуальных машинах необходимо:

  • Установить сертификат на все машины в персональное хранилище сертификатов компьютера.
  • Установить права на чтение ключа сертификата для Network Service каждой машины.
  • Иметь SSLCertificateSHA1Hash REG_BINARY параметр со значением thumbprint сертификата.
  • Виртуальные имена машин должны совпадать с именем сертификата, т.е. иметь суффикс yourcompany.com

Создадим новую групповую политику на уровне Organizational Unit, выделенного для компьютерных аккаунтов виртуальных машин фермы VDI.

Данная политика должна выполнить Startup Script ExportVDICert.bat на виртуальных машинах.

В указанном скрипте используются утилиты certutilи FindPrivateKey от Microsoft. Certutil является встроенной утилитой, FindPrivateKey предоставляется в качестве Samle tool для разработчиков и может быль скомпилирован самостоятельно. Скрипт необходимо расположить внутри политики.

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

Текст скрипта:


certutil -f -p "" -importpfx "" NoExport
c:
mkdir "c:\TempCertSecurity"
cd "c:\TempCertSecurity"
xcopy "" "c:\TempCertSecurity"
FindPrivateKey.exe My LocalMachine -t "" -a > tmp.txt
set /p myvar= < tmp.txt
del tmp.txt
del FindPrivateKey.exe
cd \
rd "c:\TempCertSecurity"
cacls.exe %myvar% /E /G "NETWORK SERVICE":R"

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

Следующая часть политики касается установки параметра SSLCertificateSHA1Hash. Необходимый ключ настраивается черезPreferences \ Windows Settings \ Registry

Для централизованного изменения Primary DNS суффикса виртуальных машин в политике необходимо включить Primary DNS suffix и установить его как внешнее доменное имя.com.

После перезагрузки, машина получит новый FQDN, соответствующий белому сертификату.

После проведения данных операций, пользователи больше не увидят надоедливые предупреждения безопасности.

bitlocker logo

Настройка Bitlocker с TPM на Hyper-V 2012 R2

В данной статье мы рассмотрим настройку Bitlocker с поддержкой TPM-модуля в среде Hyper-V 2012 R2 Server Core.

Bitlocker – встроенная в Windows утилита, позволяющая защитить данные при помощи шифрования. Bitcloker использует алгоритм AES с ключом 128 бит, для большей безопасности данных длина ключа может быть увеличена до 256 бит. Хранение и целостность ключа шифрования, по умолчанию, обеспечивает модуль TPM. Данный модуль представляет собой чип, встроенный в материнскую плату компьютера, который при загрузке компьютера проверяет запускаемый код, подсчитывает значение хэша и сохраняет в специальных регистрах, называемых PCR (Platform configuration registers). Более подробно с работой TPM и Bitlocker можно ознакомиться на официальном сайте Microsoft — https://technet.microsoft.com/ru-ru/magazine/2007.06.bitlocker.aspx

Подготовка сервера Hyper-V 2012 R2 Server Core

Как правило, поддержка TPM в Windows выключена. Включается она в настройках BIOS’a. В нашем случае мы используем Core версию операционной системы, и поэтому проверить включен ли TPM или нет стандартной оснасткой Device Manager не получится. Для этого воспользуемся модулем для Powershell, который разработали в Microsoft Partner & Customer Solutions Blog: https://technet.microsoft.com/ru-ru/magazine/2007.06.bitlocker.aspx
Устанавливаем модуль с помощью команды:


Ipmo .\ScriptName.psd1 –Verbose

PS C:\> Ipmo .\DeviceManagement.psd1 -Verbose

VERBOSE: Loading module from path

'C:\DeviceManagement.psd1'.

VERBOSE: Importing cmdlet 'Disable-Device'.

VERBOSE: Importing cmdlet 'Enable-Device'.

VERBOSE: Importing cmdlet 'Get-Device'.

VERBOSE: Importing cmdlet 'Get-Driver'.

VERBOSE: Importing cmdlet 'Get-NUMA'.

VERBOSE: Importing cmdlet 'Install-DeviceDriver'.

Просмотреть все оборудование в системе можно командой:


Get-Device | Sort-Object -Property Name | ft Name, DriverVersion

Если модуль TPM включен, то он отобразится в списке оборудования:


PS C:\> Get-Device | Sort-Object -Property Name | ft Name, DriverVersion

…

Trusted Platform Module 1.2             6.3.9600.16384

Управление настройками TPM в операционной системе Hyper-V 2012 R2 Server Core происходит при помощи специальных командлетов, которые активируются командой:


dism /online /enable-feature /FeatureName:tpm-psh-cmdlets

PS C:\> dism /online /enable-feature /FeatureName:tpm-psh-cmdlets

Deployment Image Servicing and Management tool

Version: 6.3.9600.16384

Image Version: 6.3.9600.16384

Enabling feature(s)

[==========================100.0%==========================]

The operation completed successfully.

Детальное описание всех TPM-коммандлетов — http://blogs.technet.com/b/wincat/archive/2012/09/06/device-management-powershell-cmdlets-sample-an-introduction.aspx

Просмотреть параметры TPM можно с помощью команды:

PS C:\ > Get-TPM

Настройка предохранителей.

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

Для настройки предохранителей воспользуемся системной утилитой: manage-bde

Добавляем в качестве предохранителя модуль TPM командой:


manage-bde –protectors –add C: -tpm

PS C:\Users\Administrator> manage-bde -protectors -add G: -tpm

BitLocker Drive Encryption: Configuration Tool version 6.3.9600

Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Key Protectors Added:

TPM:

ID: {BC0479C0-96DB-42D4-8C28-957385B9D8D9}

PCR Validation Profile:

0, 2, 4, 8, 9, 10, 11

После того, как предохранитель ключа добавился, включаем процесс шифрования командой:


manage-bde –on –recoverypassword C:

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

Просмотреть процесс шифрования диска после перезагрузки сервера можно командой:


manage-bde.exe -status C:

PS C:\> manage-bde.exe -status C:

BitLocker Drive Encryption: Configuration Tool version 6.3.9600

Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume C: []

[OS Volume]

Size:                 464.44 GB

BitLocker Version:   2.0

Conversion Status:   Fully Encrypted

Percentage Encrypted: 100.0%

Encryption Method:   AES 128

Protection Status:   Protection On

Lock Status:         Unlocked

Identification Field: Unknown

Key Protectors:

TPM

Numerical Password

Другие статьи на тему BitLocker

Агентство безопасности может захватить весь Skype-трафик

Документ Агентства национальной безопасности опубликованный на этой неделе в немецком журнале Der Spiegel, предоставленным бывшим АНБ подрядчиком Эдвардом Сноуденом показывает, что агентство имеет полный доступ к передаче голоса, видео, текстовых сообщений и обмена файлами от конкретных лиц в услугах компании Microsoft Skype.

Полный контроль голосового трафика начался в феврале 2011 года для «Skype In» и «Skype Out» — звонков между пользователями Skype.  Характер сбора данных Skype был написан в документе АНБ в августа 2012 под названием «Руководство пользователя для PRISM Skype Collection.» В документе подробно, описывается как захватить голосовые сообщений Skype с помощью системы «NUCLEON», а также обсуждается, как найти текстовый чат и другие данные, передаваемые между клиентами.

Уязвимость IE открывает дверь для мощных фишинговых-атак

Баг, описанный как универсальный кросс-сайт уязвимых сценариев, был раскрыт в субботу. Дэвид Лео, исследователь консалтинговой фирмы безопасности под названием Deusen. Сообщение Лео включает в себя ссылку на доказательства правильного концепта эксплойта, который демонстрирует атаку, используя сайт dailymail.co.uk в качестве цели.

При открытии в Internet Explorer 11, используется страница, которая предоставляет пользователю ссылку. Когда пользователь переходит по ссылке, открывается в новом окне сайт dailymail.co.uk но через 7 секунд контент сайта заменен надписью “Hacked by Deusen.” Фейковая страница загружается из внешнего домена, но в адресной строке браузера продолжает отображать www.dailymail.co.uk, что означает, что метод может быть использован для создания надежных фишинговых-атак.

У спецслужб есть ключи к шифрованию используемого в Skype

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

Источник: Кто, как и зачем прослушивает ваши разговоры и читает переписку

Google Chrome программа постоянно прослушивает микрофон компьютера

Как сообщает Гардиан, Гугл устанавливает на компьютеры пользователей Google Chrome программу, постоянно прослушивающую микрофон компьютера.
Исходный код программы не доступен, не смотря на то, что она устанавливается с браузером Chromium – браузера с открытым кодом, являющегося основой для Google Chrome.

По заявлению Google, программа не активна до того момента как будет произнесена фраза Ok, Google. Верить ли этому заявлению — личное дело пользователей.
Мы рекомендуем пользователям настроить разрешение на доступ в интернет только для тех программ, которые авторизованы пользователем, как это описано в статье.

Пользователи услуги от «Сбербанка» стали жертвами мошенников

Десятки тысяч пользователей услуги «Мобильный банк» от «Сбербанка» стали жертвами мошенников, которые пользовались уязвимостью операционной системы Android. Об этом со ссылкой на неназванный источник сообщили в МВД России.

По словам агентства, пострадали «40-50 тысяч» клиентов. При этом источники в нескольких региональных ведомств рассказали FlashNord, что количество пострадавших варьируется от 150 до 400 в зависимости от субъекта Федерации.

Помимо этого сообщается о задержании трех групп мошенников, одна из которых, работавшая в Самаре, похитила около 200 млн рублей. Агентство не уточняет, работали ли эти группы по одной схеме или нет.

Способ мошенничества, о котором рассказал собеседник FlashNord, ссылаясь на источник CNews. Злоумышленники распространяли вирус-троянец через сайты «для взрослых» – на телефон жертвы устанавливался фальшивый Flash-проигрыватель. Его невозможно было удалить, если пользователь предоставил программе права администратора.

Чтобы проверить, подключен ли зараженный телефон к «Мобильному банку», вирус отправлял запрос баланса. При этом как исходящее, так и ответное SMS-сообщения скрывались от пользователя. Если баланс на привязанной к телефону карте Сбербанка составлял более нескольких тысяч рублей, мошенники при помощи SMS-запросов пытались перевести средства на номера «Билайн» и Tele2.

Как результат — двухфакторная система аутентификации, не дает надлежащую защиту данных.

Пользователи MACBOOK, IPAD, IPHONE И ANDROID были беззащитны перед атаками

Группа экспертов по информационной безопасности, с участием корпорации Microsoft, обнаружила уязвимость, позволяющую хакерам взламывать сайты и расшифровывать данные, работающие между этими веб-сайтами, мобильными устройствами на платформах Apple iOS, Google Android и компьютерами на базе Apple OS X.

Как заявил изданию Ars Technica Мэттью Грин (Matthew Green), криптограф, научный сотрудник Университета Джона Хопкинса, уязвимы все устройства на Android, iOS и OS X. При этом проблема не касается устройств на базе Windows и Linux.

Из российских сайтов в этот список попали vesti.ru, alfabank.ru, labirint.ru, subscribe.ru, artlebedev.ru и др. Из американских — americanexpress.com, bloomberg.com, businessinsider.com, nsa.gov, fbi.gov, connect.facebook.net и др.

Уязвимость в технологии шифрования трафика SSL/TLS существует более 10 лет, и до сих пор не была замечена. Все это время миллионы пользователей оставались беззащитны к действиям хакеров.
Обнаруженная уязвимость, получившая кодовое имя FREAK и стандартную маркировку CVE-2015-0204, позволяет хакерам вставлять пакеты в трафик, заставляющие источник трафика понижать уровень шифрования данных путем перехода на 512-битный ключ. После этого хакеры, перехватывая трафик, могут расшифровать его, воспользовавшись мощностями облачных провайдеров, например Amazon (Amazon Web Services).

Производитель sim-карт опроверг кражу данных спецслужбами

Крупнейший производитель SIM-карт опроверг кражу данных спецслужбами.

Нидерландская компания Gemalto в ходе предварительного расследования не обнаружила кражи АНБ ключей шифрования SIM-карт. Об этой краже неделей раньше рассказал экс-сотрудник АНБ Эдуард Сноуден.

Результаты расследования Gemalto представила в среду на своем сайте.  По данным компании, она пережила две изощренные атаки на свою компьютерную сеть, в 2010 и 2011 годах – предположительно со стороны американского Агентства национальной безопасности (АНБ) и британских спецслужб.

Об этих атаках рассказал на прошлой неделе перебежчик АНБ Эдвард Сноуден сайту the Intercept. Из опубликованных Сноуденом документов следовало, что у британских и американских спецслужб есть ключи шифрования SIM-карт Gemalto – и возможность прослушивать телефонные разговоры и перехватывать пересылку данных абонентов без ведома операторов мобильной связи.

Это не так, согласно результатам расследования Gemalto. «Атаки против Gemalto вскрыли только офисную компьютерную сеть и не могли привести к массивной краже ключей шифрования SIM-карт», – заявила компания. К 2010 году Gemalto уже развернула систему безопасной пересылки данных своим клиентам, и только «редкие исключения в этой схеме могли привести к краже». И, даже если бы такая кража произошла, с помощью ключей спецслужбы смогли перехватить только трафик сетей 2G – а не 3G и 4G. По данным The Intercept, спецслужбы использовали результаты взлома Gemalto в Йемене, Индии, Сербии, Иране, Исландии, Сомали, Пакистане и Таджикистане.

«Даже если бы ключи шифрования были перехвачены спецслужбами, польза от них была бы ограниченной, – заявила Gemalto в сообщении, – большинство SIM-карт в этих странах было препейд-картами с коротким периодом жизни, 3–6 месяцев». Технологии 2G были разработаны еще в 80-х г одах и в 2010 году считались слабыми и морально устаревшими – потому большинство операторов усилили защиту с помощью специальных алгоритмов.

Gemalto выпускает до 2 млрд SIM-карт ежегодно, которые покупают 450 операторов мобильной связи в мире, в том числе – крупнейшие американские AT&T,  T-Mobile, Verizon, Sprint.