.

Использование фиксированных сетевых портов

По умолчанию компоненты DeviceLock при сетевом взаимодействии пытаются использовать определенные порты (TCP 9132, 9133 и 9134), но задействуют и динамическую привязку, то есть, если соответствующие порты заняты, компонент DeviceLock подключится через другой порт, который даст подсистема RPC. Если же задать фиксированный порт, который займет другая служба/приложение, компонент DeviceLock не осуществит привязку к этому порту и будет недоступен для управления. Однако в сети, разделенной на сегменты сетевыми экранами, применение фиксированных портов целесообразно. Так, если агенты находятся в защищенном сегменте, а сервер — в основной сети (агенты имеют доступ в основную сеть, а из основной сети доступ к ним ограничен), серверу для работы с агентами нужно, чтобы на сетевом экране были открыты порты TCP 139, 445, а также фиксированный порт. А для работы сервера с агентами, использующими динамическую привязку, — TCP 139, 445, 135 плюс все порты выше 1024. Для подключения консолью к агентам нужны те же порты, если в строке адреса будут указываться IP-адреса удаленных систем; те же адреса плюс UDP137, если в строке адреса будут указываться имена компьютеров, а не IP-адреса. Указанных портов достаточно в том числе для того, чтобы обновлять версию агента на удаленном компьютере.

Сетевое взаимодействие сервера и агента DeviceLock

В течение пяти минут после того, как агент DeviceLock создал записи в своем журнале (например, о вставке в USB-порт устройства), он выбирает сервер DeviceLock из списка, заданного в его настройках, чтобы передать записи на сервер для централизованного хранения. В зависимости от настройки Fast Servers First он выбирает сервер либо случайным образом, либо тот, «цена» трафика с которым (в условных единицах) наименьшая. Агент посылает серверу запрос. Сервер получает запрос и ставит его в очередь. Когда очередь подходит, сервер начинает попытки сбора журналов с агента. Если подключение удалось, то он все собирает и удаляет соответствующий компьютер из очереди. В случае ошибки подключения сервер предпринимает еще две попытки с интервалом в одну минуту, отражая их в соответствующем журнале. Если и после этих двух попыток серверу не удастся подключиться к агенту, он удалит его из очереди и снова поставит в очередь, когда тот, записав локально новую порцию журналов, пришлет ему новый запрос. Если после этого соединение будет установлено, агент передаст серверу сначала более старые записи, потом более новые.

В настройках агента DeviceLock есть параметр Traffic priority, определяющий, какую часть пропускной способности канала может занимать агент для своих целей. Оптимальным можно считать режим, когда агенту не дается больше 50%. Однако настройка работает только при условии, что на целевой системе установлена и запущена служба QoS — Quality of Service Packet Scheduler. Без службы QoS функция не работает, и агент может занимать до 100% пропускной способности.

Сетевое взаимодействие консоли и агента DeviceLock

Подключение из консоли к агенту и серверу DeviceLock происходит по портам, указанным в настройках агента и сервера. В интерфейсе консоли нет поля настроек, в котором можно указать порт, по которому она всегда будет пытаться соединяться с удаленными системами. Таким образом, консоль сначала подключается к RPC, которая выдает ей номер порта, после чего соединяется по полученному номеру порта. Можно сократить процедуру подключения консоли, явно задав порт. Порт указывается в строке адреса для подключения консоли в квадратных скобках сразу после имени/IP-адреса удаленной системы без пробелов computer_name [port]. Указание в явном виде порта при подключении консоли к серверу избавляет консоль от необходимости подключения к RPC.

Безопасность компонентов. Защита агента от нарушения целостности

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

Первый эшелон защиты сервера и агента DeviceLock — отключение так называемой Default Security. До отключения этого режима любой пользователь с повышенными привилегиями, позволяющими устанавливать/удалять программы и менять параметры запуска служб, сможет просматривать настройки агента DeviceLock и журналы на своей системе, если является администратором, менять настройки агента, удалять его. Отключение Default Security означает включение списков доступа к агенту DeviceLock. В список могут включаться как доменные, так и локальные учетные записи пользователей/групп. Привилегированные учетные записи, вплоть до администраторов домена, не смогут модифицировать/удалять агента, если они не будут включены в список доступа (см. экран 1). В частности, они не смогут поставить на той же системе «враждебный» агент DeviceLock, который разрешит доступ. В таком случае установленный DeviceLock будет считать, что его пытаются обновить, и не даст этого сделать. Более того, они не смогут поставить не только агент, но даже просто консоль. Также им не удастся соединиться с помощью враждебной консоли DeviceLock Enterprise Manager или DeviceLock Management Console, уже установленной на компьютере. Они не смогут удалить агент в безопасном режиме, прочитать его настройки, заключить из настроек, на какие серверы агент шлет журналы, и внести эти имена серверов в файл hosts, чтобы отсылка журналов прекратилась. Правда, для получения данных на модификацию файла hosts они могут перехватить трафик, если уровень аутентификации RPC понижен до 1 (rpc_c_protect_level_none). В таком случае трафик между агентами и сервером не шифруется. Это возможно при взаимодействии между сегментами сети или между доменами с разными политиками доступа. По умолчанию же соединение агента и сервера происходит на уровне аутентификации Rpc 6 (rpc_c_protect_level_pkt_privacy). Отслеживание случаев незашифрованного трафика между сервером и агентами возможно по записям «Authentication level for comp changed from 6 to 1» в журнале сервера. Для обладателей учетных записей, не внесенных в список доступа к агенту, останется один путь избавиться от агента DeviceLock, не удаляя операционную систему, — манипулировать параметрами реестра.

 

Список администраторов DeviceLock с различными правами
Экран 1. Список администраторов DeviceLock с различными правами

На этот случай разработчики предусмотрели второй эшелон защиты — режим Unhook protection. В этом режиме агент DeviceLock не позволит пользователям отключить защиту критичных для службы ветвей реестра и файлов, таким образом делая невозможным отключение DeviceLock при помощи утилит-руткитов (таких, как Kernel Detective). В режиме Unhook protection агент DeviceLock при нарушении целостности вызывает завершение работы Windows «синим экраном смерти».

Третий эшелон защиты — это мониторинг активности агентов и восстановление целостности их настроек с помощью модуля «Мониторинг» сервера DeviceLock. В частности, модуль будет уведомлять, что удаленный агент замолчал, если злоумышленники все-таки узнали имя сервера или IP-адрес и порт и заблокировали соединение с ними.

Авторизация при взаимодействии сервера и агентов DeviceLock может быть построена не только на членстве учетной записи, под которой запущен сервер DeviceLock, в списке доступа агента DeviceLock. Может использоваться несимметричная пара криптографических ключей. Секретный (private) ключ секретной пары хранится на сервере, с ним сопоставляются открытые (public) ключи, хранящиеся на агентах. Если открытый ключ, предъявленный агентом, соответствует секретному ключу, предъявленному сервером, сервер принимает запрос агента. Это называется аутентификацией по сертификату, она имеет приоритет, то есть используется в первую очередь, но если данный вариант не проходит, то осуществляется аутентификация по учетной записи. Если не проходит и она, выдается ошибка подключения. Надо заметить, что, даже если обе указанные аутентификации пройдут, это не гарантирует успеха, так как отказ в доступе сервера к удаленному агенту может произойти из-за самой операционной системы. Поэтому рекомендуется в настройках запуска службы сервера DeviceLock использовать учетную запись с большими привилегиями в домене. Лучше не давать слишком большие права (domain admin, enterprise admin), а создать учетную запись, имеющую права администратора на системах определенного типа в домене или организационной единице (например, только типа workstations).

Разблокировка доступа с помощью криптографических ключей

У криптографических ключей существует и другое применение, и оно, на мой взгляд, так важно, что с первого дня развертывания необходимо снабдить все агенты публичным криптографическим ключом. Ключи применяются для управления по вспомогательному каналу, то есть экстренного управления агентами в случае недоступности стандартных каналов управления. Представьте себе ситуацию: на компьютере установлен агент, защищенный списком доступа, в который включены только доменные учетные записи, при этом агент запрещает любой доступ к внешним устройствам. Теперь случается сетевой сбой, компьютер оказывается в автономном режиме, но вдруг срочно нужно разблокировать доступ к какому-то из внешних устройств. Настройки доступа нельзя изменить, так как невозможна регистрация под доменной учетной записью. На этот случай предусмотрена пара функций, объединенная в компоненте DeviceLock Signing Tool (см. экран 2).

 

Предоставление администратором временного доступа к устройству в DeviceLock Signing Tool
Экран 2. Предоставление администратором временного доступа к устройству в DeviceLock  Signing Tool

Первая функция — выдача временного кода доступа. Администратор DeviceLock получает от пользователя так называемый «код устройства», сгенерированный им на рабочей станции с помощью его экземпляра DeviceLock Signing Tool с использованием открытого ключа. Администратор вводит полученный код в нужное поле в своем экземпляре DeviceLock Signing Tool, загружает секретный ключ и генерирует ответный код, задавая срок или условие (завершение сеанса пользователя либо отключение устройства) прекращения его действия. Пользователь получает ответный — разблокирующий — код по телефону или другим способом, вводит его в соответствующем поле своего экземпляра DeviceLock Signing Tool и получает временный доступ к нужному устройству. Пожалуйста, перед использованием этих кодов примите во внимание два обстоятельства. Первое: код устройства генерируется на основе информации о системе, сертификате и устройстве. Идентификаторы конкретного экземпляра агента DeviceLock не используются. Это означает, что если на системе, где запущено приложение DeviceLock Signing Tool, после генерации DeviceCode будет удален агент и затем установлен агент с тем же открытым ключом, то полученный на основании кода устройства код разблокировки все еще можно будет задействовать. Второе: если пользователь, сгенерировав код устройства, закрыл приложение DeviceLock Signing Tool, то, открыв его заново и получив от администратора код разблокировки, он не сможет им воспользоваться; прерывание сеанса DeviceLock Signing Tool на стороне пользователя при ожидании разблокирующего кода от администратора недопустимо.

Вторая функция DeviceLock Signing Tool — подписывание файла настроек. Вернемся к нашему примеру. С помощью обмена кодами мы смогли получить временный доступ к «флэшке» на компьютере, отрезанном от сети. Теперь мы хотим изменить его настройки более глобально, а не только для отдельно взятого устройства. Для этого мы получаем от администратора DeviceLock файл с нужными настройками агента, подписанный секретным ключом, который применяем с помощью локального DeviceLock Signing Tool (файл DLTempAccess.cpl в установочном каталоге DeviceLock). Настройки будут применены, даже если процесс выполняется от имени ограниченной учетной записи и учетной записи, не включенной в список доступа агента DeviceLock.

Илья Кузьминов, специалист по защите информации