 |
|
|
|
DLP-системы DeviceLock в банках. Взаимодействие и безопасность компонентов. Часть 2
DLP-системы DeviceLock в банках Вторая статья цикла описывает особенности сетевого взаимодействия компонентов и механизмы обеспечения собственной безопасности компонентов в DeviceLock Endpoint DLP Suite Программный комплекс DeviceLock Endpoint DLP Suite разработан российской компанией «Смарт Лайн Инк». Он предназначен для управления доступом пользователей ОС семейства Windows к периферийным устройствам хранения и обработки данных, каналам сетевых коммуникаций, а также для контроля действий пользователей с устройствами и сетевыми протоколами (чтение, запись файлов, форматирование) и контроля содержимого переданных файлов и данных. Возможности продукта и механизмы управления им описаны подробно на сайте разработчика и в руководстве пользователя. Данный цикл статей [1] посвящен описанию неочевидных нюансов, с которыми мы столкнулись в практике использования DeviceLock Endpoint DLP Suite в банковской корпоративной среде и которые необходимо учитывать при развертывании и эксплуатации программы в достаточно большом домене. Давайте рассмотрим особенности сетевого взаимодействия компонентов комплекса DeviceLock Endpoint DLP Suite. Использование фиксированных сетевых портов По умолчанию компоненты 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 Endpoint DLP Suite. Защита агента от нарушения целостности Разработчики DeviceLock предусмотрели несколько эшелонов защиты компонентов программы от несанкционированного доступа и модификации, в том числе при взаимодействии друг с другом. К их чести нужно отметить, что защита целостности не идет в ущерб доступности: предусмотрены процедуры out-of-band management, позволяющие в экстренных ситуациях менять настройки доступа к устройствам, снимать защиту от модификации с агентов DeviceLock. Первый эшелон защиты сервера и агента DeviceLock – отключение так называемой Default Security. До отключения этого режима любой пользователь с повышенными привилегиями, позволяющими устанавливать/удалять программы и менять параметры запуска служб, сможет просматривать настройки агента DeviceLock и логи на своей машине, если является администратором, менять настройки агента, удалять его. Отключение Default Security означает включение списков доступа к агенту DeviceLock. В список могут включаться как доменные, так и локальные учетные записи пользователей/групп. Привилегированные учетные записи, вплоть до администраторов домена, не смогут модифицировать/удалять агент, если не будут включены в список доступа. В частности, они не смогут поставить на той же машине «враждебный» агент 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, не удаляя операционную систему, – манипулировать параметрами реестра. На этот случай разработчики предусмотрели второй эшелон защиты – режим Unhook protection. В этом режиме агент DeviceLock не позволит пользователям отключить защиту критичных для сервиса веток реестра и файлов, таким образом, делая невозможным отключение DeviceLock с помощью утилит-руткитов (таких, как, например, Kernel Detective). В режиме Unhook protection агент DeviceLock при нарушении целостности вызывает завершение работы Windows синим экраном смерти. Третий эшелон защиты – это мониторинг активности агентов и восстановление целостности их настроек с помощью модуля «Мониторинг» сервера DeviceLock. В частности, модуль будет уведомлять, что удаленный агент замолчал, если злоумышленники все-таки узнали имя сервера/IP-адрес и порт и загасил коммуникации на них. Авторизация при взаимодействии сервера и агентов DeviceLock может быть построена не только на членстве учетной записи, под которой запущен сервер DeviceLock, в списке доступа агента DeviceLock. Может использоваться несимметричная пара криптографических ключей. Секретный (private) ключ секретной пары хранится на сервере, с ним сопоставляются открытые (public) ключи, хранящиеся на агентах. Если открытый ключ, предъявленный агентом, соответствует секретному ключу, предъявленному сервером, сервер принимает запрос агента. Это называется аутентификацией по сертификату, она имеет приоритет, т.е. используется в первую очередь, но если она не проходит, то осуществляется аутентификация по учетной записи. Если не проходит и она, выдается ошибка подключения. Надо заметить, что даже если обе указанных аутентификации пройдут, это не гарантирует успеха, т.к. отказ в доступе сервера к удаленному агенту может случиться от самой операционной системы. Поэтому рекомендуется в настройках запуска службы сервера DeviceLock использовать учетную запись с большими привилегиями в домене. Лучше не давать слишком большие права (domain admin, enterprise admin), а создать учетную запись, имеющую права администратора на машинах определенного типа в домене/OU (например, только типа workstations). *** В следующей статье цикла мы рассмотрим некоторые нюансы задания DLP-политик для контроля устройств и каналов сетевых коммуникаций в DeviceLock Endpoint DLP Suite.
|
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
