От каждого по максимуму, каждому – по минимуму. Разграничение доступа к устройствам в Windows.

(c)oded by offtopic@mail.ru 2004

Современные компьютеры содержат в себе массу потенциально небезопасных устройств. К примеру, центральный процессор может обрабатывать команды вируса, на жестком диске или в оперативной памяти может находиться код rootkit, а сетевая карта может использоваться для доставки к компьютеру трафика атаки DDoS.

Но кроме базовых устройств производители зачастую встраивают в системы дополнительные компоненты, без которых вполне можно обойтись. Это и приводы внешних накопителей, такие как гибкие диски и CD-ROM и внешние коммуникационные порты (USB, COM, LPT). Можно выделить две основные угрозы, связанные с использованием подобных устройств. Это возможность организации неконтролируемого канала утечки информации из корпоративной сети, а так - нарушение целостности Trusted Computer Base.

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

Физический контроль

Существует множество методов контроля использования подобных устройств. Самый простой – физически отключить их. Но если это применимо к таким устройствам как приводы CD-ROM или Floppy-drive, то с USB, COM и другими портами дело обстоит сложнее, хотя в принципе их можно отключить в BIOS. Однако если мы отключим USB-порт в BIOS, мы не сможем использовать никакие из USB устройств, например – Smartcard с USB интерфейсом.

Ещё один минус физического отключения – усложнение процесса восстановления систем в случае сбоев, когда эти устройства (например, привод CD-ROM) необходимы. Кроме того, администратор, прогуливающийся по комнатам с единственным на компанию приводом CD-ROM, обычно вызывает зависть и другие, резко отрицательные эмоции у коллектива. Если не верите – попробуйте вынуть CD у своих сослуживцев.

Альтернативные пути

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

Дальнейшее изложение основано на следующих предположениях:

- сеть развернута на основе Active Directory;

- в качестве клиентов используются Windows XP и выше (хотя большая часть рекомендаций подойдет и для Windows 2000),

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

- учетная запись локального администратора заблокирована или пароль её периодически меняется;

- решена проблема физической безопасности компьютеров.

Вариант #1. Все или ничего

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

Реализовать такой подход очень просто. Дело в том, что в Windows процессы не работают напрямую с устройством, но взаимодействуют посредством вызовов API с его драйвером. И успешность того или иного вызова определяется наличием драйвера устройства в системе. Но даже если драйвер был установлен, его можно отключить, после чего доступ к устройству буден невозможен. В дальнейшем, под термином устройство будет подразумеваться именно виртуальное устройство Windows, если из контекста не вытекает обратное.

Простейший способ провести операцию отключения устройства – воспользоваться утилитой Device Manager. Зайдите в систему от учетной записи с административными привилегиями, выполните команду devmgmt.msc, нажмите правой кнопкой на устройстве (например, приводе CD-ROM) и выберете пункт Disable в контекстном меню. В появившемся диалоговом окне нажмите кнопку Yes, после чего запустите «Проводник». О, чудо! Привод CD-ROM исчез из доступных устройств. Причем пользователи со стандартным уровнем привилегий не будут иметь возможности его подключить, хотя вполне сумеют воспользоваться кнопкой Play на передней панели устройства для прослушивания аудио дисков.

Однако вручную отключать устройства с помощью графического интерфейса на всех компьютерах в сети не очень удобно. Можно конечно написать собственную утилиту, выполняющую эти действия, но это слишком сложный путь. Гораздо легче воспользоваться готовой утилитой devcfg, описанной в Q311272 и доступной для загрузки на сервере Microsoft [3].

Эта утилита представляет собой полнофункциональный аналог Device Manager, позволяющий манипулировать устройствами (т.е. их драйверами) из командной строки.

Нас в принципе интересуют три опции этой утилиты:

- найти устройство (devcfg.exe find *CDROM*);

- отключить устройство (devcfg.exe disable *CDROM*);

- подключить устройство (devcfg.exe enable *CDROM*).

Пытливому читателю, интересующемуся тем, «где лежат» драйверы я посоветую посетить ключи реестра HKLM\SYSTEM\CurrentControlSet\Control\Class и HKLM \SYSTEM\CurrentControlSet\Control\DeviceClasses.

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

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

devcfg.exe disable *CDROM*

devcfg.exe disable *floppy* … и так далее.

Сценарии входа в систему пользователей, наоборот, включают устройства:

devcfg.exe enable *CDROM*

devcfg.exe enable *floppy*

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

Сценарии загрузки Windows (Startup Scripts) обрабатываются в контексте безопасности учетной записи компьютера (т.е. Local System) и имеют возможность модифицировать параметры любых устройств. Сценарии входа в систему (Logon Scripts) работают с привилегиями учетной записи текущего пользователя и соответственно, устройства будут подключены, если пользователь имеет на это должные права. По умолчанию они присутствуют у членов группы Administrators.

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

Если возникает необходимость создать сценарий входа в систему для локальной, а не доменной учетной записи, можно воспользоваться рекомендациями, приведенными в статье [4] (см. script.vbs).

Вариант #2. Different Strokes for Different Folks

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

Что бы реализовать это законное желание мы создаем группы безопасности для каждого из типов устройств, например Copm Floppy , Comp CDROM и т.д. Затем в каждую группу включаем те машины, устройства на которых необходимо отключить. Например, в группу Comp Floppy войдут учетные записи тех машин, использование FDD на которых запрещено политикой безопасности.

Затем в качестве сценария загрузки в групповых политиках домена (или других групповых политиках высокого уровня) указывается сценарий devcmcfg.vbs (см. Сырец #1) с ключом disable.

В пользовательских политиках, этот же сценарий указывается в качестве сценария входа в систему (ключ enable). Он же, но с ключом disable используется в качестве Logoff Script.

Сырец #1. Сценарий devcmcfg.vbs

Сценарий, в зависимости от значения аргумента командной строки вызывает функцию DisableDev для отключения устройств или EnableDev для их включения. Функция DisableDev вызывает функцию VerifyGroupMembers, для проверки членства компьютера в группе безопасности, и в случае, если компьютер присутствует в группе – отключает соответствующее устройство. Массивы

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

Не забудьте исправить константы Domain и path таким образом, что бы они указывали на ваш домен и путь к утилите devcfg (подобные вещи довольно выгодно хранить на DFS домена, пускай себе реплицируется).

Вариант #3. Нет придела совершенству!

Однако все равно, нас не покидает ощущение, что могло бы быть и лучше. Например – не лишней была бы возможность разрешать различным пользователям одного и того же компьютера доступ к различным устройствам, или давать доступ к CD пользователям, не имеющим права администратора.

К сожалению, используя описанный выше подход это сделать невозможно, поскольку возможностью загружать и выгружать драйверы устройств определяются наличием у учетной записи пользователя всего одной привилегии - “ Load and Unload Device Drivers” (SeLoadDriver Privilege). Пользователь, имеющие подобные привилегии имеет возможность загружать и выгружать любые драйверы в системы (включая и тесно связанные с безопасностью, например драйвер персонального межсетевого экрана).

Кроме того, некоторые устройства, например USB поддерживают такую неприятную возможность, как PnP. Дополнительно, мы можем захотеть заблокировать возможность использования USB-Flash дисков, но при этом использовать различные USB-Token для аутентификации, но они обращаются к одному и тому же устройству - USB Root Hub.

Здесь на выручку приходит то обстоятельство, что с драйверами связаны компоненты пользовательского уровня – системные службы (HKLM\SYSTEM\CurrentControlSet\Services). А управления правами на системные службы – тривиальная задача для любого грамотного администратора Windows.

Стандартным подходом в данном случае является использование Security Configuration Manager (SCM) и шаблонов безопасности [5], однако в этой ситуации они неприменимы. К сожалению, у меня не получилось заставить SCM через групповые политики менять разрешения на службы с типом Kernel-mode device driver (Type=1).

Однако с этим прекрасно справляется утилита sc.exe из стандартной поставки Windows Server 2003 и Windows XP. Запущенная с параметром sc sdset она позволяет устанавливать списки контроля доступа для любых системных служб (в рамках привилегий запустившего пользователя, естественно). Разрешения задаются в виде строки на языке SDDL [7], свободно писать на котором могут только люди, читающие Base64 без словаря. Поэтому, для их формирования разумно воспользоваться теми же шаблонами безопасности, задав соответствующие разрешения в оснастке Security Templates, а затем просмотрев их в notepad.

Подобный подход использован в ещё одной модификации Startup/Logon/Logoff сценария devcfg.vbs (см. Сырец #2).

Сырец #2. Сценарий devcfg.vbs

В этом сценарии добавился ещё один массив – Services, содержащий системные службы, соответствующие тому или иному устройству. В массиве Groups на этот раз содержатся группы пользователей, имеющие разрешение на работу с тем или иным типом устройств.

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

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

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

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

Использование этого подхода позволяет, например не отключать драйвер USB, а заблокировать службу USBSTOR [8], отвечающую за монтирование переносимых носителей. Для этого в массив Services надо добавить запись USBSTOR и соответствующую по порядку пустую запись в массив Drivers, а так же группу безопасности пользователей подключаемых USB-носителей в массив Groups.

После всего

Приведенные примеры только демонстрация прикладного использования некоторых методов управления доступом в ОС Windows. Весь приведенный код имеет статус PoC. Автор не несет никакой ответственности за использования данных рекомендаций и очень не рекомендует давать разрешения стандартным пользователям совершать манипуляции с системными службами и драйверами. В статье умышленно рассказывается «как», но не затрагивается вопрос «почему». Это вызвано ограничением формата статьи, кроме того - ответы на большую часть вопросов можно найти, прочитав приведенные сноски.

Вполне можно совместить вариант #2 c вариантом #3, что остается в качестве домашнего задания читателям.

[1] Gartner: Модные usb устройства - серьезная угроза корпоративной безопасности. http://www.securitylab.ru/46290.html

[2] Валерий Марчук, «Защита информационных активов с помощью DeviceLock».http://www.osp.ru/win2000/2004/03/046.htm

[3] DevCon Command Line Utility Alternative to Device Manager. http://support.microsoft.com/default.aspx?scid=kb;en-us;311272

[4] Сергей Гордейчик, «Локальная угроза». http://www.osp.ru/win2000/2003/03/056.htm

[5] Сергей Гордейчик, «Всё и сразу». http://www.osp.ru/win2000/2003/01/070.htm

[6 ] Device Driver Tools and Settings. http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us/W2K3TR_drvr_tools.asp

[7] Security Descriptor Definition Language. http://msdn.microsoft.com/library/en-us/secauthz/security/security_descriptor_definition_language.asp

[8] Disable the Use of USB Storage Devices in Windows XP. http://support.microsoft.com/default.aspx?scid=kb;en-us;823732