Пользователи постоянно загружают и запускают приложения, с которыми им не положено работать, в связи с чем в сети организации может устанавливаться вредоносное программное обеспечение. Управлять тем, какие программные средства пользователи устанавливают на своих компьютерах, в среде Windows на удивление непросто. Первый компонент решения этой проблемы состоит в том, чтобы в большинстве случаев пользователям предоставлялся наименьший объем полномочий, т. е. чтобы они не выступали в роли администраторов или опытных пользователей. Второй элемент головоломки — контроль списка программ, которые пользователи могут запускать.
Во многих решениях от независимых поставщиков реализуются функции белых или черных списков приложений. Иначе говоря, создаются списки приложений, которые можно (если они внесены в белый список) или нельзя (если они внесены в черный список) запускать на исполнение. Таким образом, затрудняется применение конечными пользователями программных кодов с «незваными гостями», которые могут нанести ущерб сети организации. Однако в целях управления исполнением приложений можно использовать политику ограниченного применения программ (SRP, известную также как Safer). Хотя в SRP не реализованы некоторые возможности решений от независимых поставщиков, например заранее составленные каталоги сигнатур приложений, используемые для блокировки или разрешения запуска последних, данная политика предоставляет возможности, которые во многих ИТ-подразделениях еще не реализованы или применяются не в полном объеме.
Как функционирует SRP
SRP применима в средах Windows Server 2008, Windows Vista, Windows Server 2003 и Windows XP. К этой функции можно обратиться через редактор групповых политик Group Policy Editor (GPE) либо в разделеComputer ConfigurationWindows Settings Security Settings, как показано на экране 1, либо в разделе User ConfigurationWindows SettingsSecurity Settings. SRP доступна как локальный объект групповых политик (GPO), так и GPO доменов. Однако, как локальный GPO, эта функция доступна лишь в качестве средства управления компьютерами. Вся мощь политик SRP проявляется в тех случаях, когда они развертываются через доменные GPO на целом ряде систем с помощью встроенных механизмов назначения групповой политики.
SRP дает возможность определять правила ограниченного использования приложений внутри GPO, и эти правила транслируются на клиентскую систему по обычным каналам групповой политики. Операционная система Windows хранит эти правила в реестре и обращается к ним всякий раз при выполнении процесса. Если соответствующее правило существует, приложение запускается или блокируется — в зависимости от того, внесено оно в белый или в черный список. SRP не применяет санкций к уже выполняющимся приложениям, даже если групповая политика применила соответствующие правила. Чтобы правило вступило в действие, необходимо перезапустить приложение.
Настройки SRP
Проиллюстрировать возможности использования SRP лучше всего на примере типового сценария. Допустим, на системе пользователя выполняется Microsoft Office и несколько деловых приложений. Я хочу, чтобы этот пользователь мог выполнять только санкционированные мною приложения, и поэтому собираюсь реализовать в политике SRP белый список.
Настройки SRP лучше всего хранить в особом объекте GPO, отдельно от других настроек политики, чтобы в случае необходимости их можно было быстро отключить. Требуется принять решение: будут ограничения использоваться применительно к компьютерам или применительно к пользователям. В первом случае ограничения на запуск приложений касаются любого пользователя, применяющего учетные записи компьютеров в службе Active Directory (AD), которые получают данные ограничения; такой вариант приемлем, к примеру, при использовании SRP на серверах терминалов. Ограничения «на пользователя» применяются к данному набору объектов «пользователь» в AD и налагаются на этих пользователей вне зависимости от того, с каких систем они регистрируются.
Итак, мы решили, к каким объектам будут применяться политики. Теперь нужно активизировать политики и приступить к их настройке. Прежде всего, запустим консоль управления групповыми политиками Group Policy Management Console (GPMC) и создадим новый объект GPO программных ограничений.
Правой кнопкой мыши щелкните на вновь созданном GPO внутри контейнера Group Policy Objects консоли GPMC и в меню выберите пункт Edit. На экране появится окно редактора GPE с выделением интересующего нас объекта GPO.
Перейдите на узел Software Restriction Policies в раздел Computer Configuration, чтобы определять политики применительно к компьютерам, или в раздел User Configurations — для определения политик «на пользователя». Правой кнопкой мыши щелкните на узле Software Restriction Policies и в контекстном меню выберите пункт New Software Restriction Policies. На правой панели экрана появится группа папок и элементов политик (см. экран 1). Возможно, вы получите сообщение о том, что политики вступят в силу только после перезагрузки системы (это верно для Windows Server 2008). Данное сообщение не вполне соответствует действительности, так как для того, чтобы начать загрузку этих политик, не требуется перезагрузка ни клиента, ни сервера.
Первое решение, которое необходимо принять применительно к этим новым элементам, касается того, какой список вы будете формировать — белый или черный. Белые списки дают возможность получить более безопасную среду, ибо они блокируют выполнение любых программ, кроме тех, что указаны явным образом. С другой стороны, для управления белыми списками требуются дополнительные усилия в зависимости от числа приложений в корпоративной сети, от того, как часто меняется список, и от того, какие методы используются для идентификации приложений. В рамках нашего примера мы будем создавать белый список.
Дважды щелкните на папке Security Levels, расположенной на правой панели редактора GPE. В системах Windows 2003 и Windows XP эта папка содержит два узла: Disallowed и Unrestricted. В Windows Server и Vista добавляется третий узел — Basic User. Узел Unrestricted (режим черного списка) имеет небольшую пометку, указывающую на то, что данный режим применяется по умолчанию. Чтобы перейти в режим белого списка, дважды щелкните на узле Disallowed и нажмите кнопку Set as Default. На экране появится запрос на подтверждение; подтвердите ваш выбор и закройте диалоговое окно, чтобы продолжить работу.
Basic User — это функция, добавленная в версии Windows Vista. В режиме Basic User у пользователей, которые являются администраторами своих рабочих станций или доменов AD, из всех приложений, выполняемых на их системах, удаляются административные маркеры. В сущности, они лишаются возможности выполнять какие-либо программы с полномочиями администраторов. Незаметно для пользователей функция SRP модифицирует маркер процесса в каждом приложении, запущенном пользователем, добавляя инструкцию об отмене разрешения представителям следующих групп безопасности:
- администраторы;
- администраторы сертификатов;
- администраторы схемы;
- администраторы предприятия;
- администраторы доменов.
Basic User можно представить как механизм для выявления ситуаций, когда администраторы действительно выступают в роли администраторов. Возможно, в вашей организации имеется ряд компьютеров, содержащих конфиденциальные данные о клиентах, и администраторам время от времени приходится регистрироваться на этих системах. В таких случаях вы можете установить режим Basic User в качестве режима по умолчанию для упомянутых систем, чтобы пользователи не могли выполнять приложения с расширенными полномочиями.
Указание параметров SRP
Пришло время установить кое-какие общие параметры. Если вы перейдете обратно в папку верхнего уровня внутри данной политики, то увидите три узла: Enforcement, Designated File Types и Trusted Publishers. Дважды щелкните на узле Enforcement. На экране появится диалоговое окно Enforcement Properties, показанное на экране 2. Это окно дает возможность выбрать режим SRP при обработке ее правил.
Первый параметр диалогового окна позволяет выбрать одну из двух возможностей: SRP реализует правила применительно к приложениям или к приложениям и всем зависимым от них библиотекам DLL. По умолчанию (прежде всего, из соображений быстродействия) используется вариант с реализацией правил только применительно к вызывающему приложению. Однако, если у вас вызывают беспокойство файлы DLL как возможные каналы для атаки, можете распространить действие правил и на них, выбрав пункт All Software Files.
Параметр Enforcement Properties позволяет указывать, требуется ли применять политики SRP, перечисленные в данном объекте GPO, ко всем пользователям вообще, или ко всем, за исключением членов локальной группы администраторов. По умолчанию администраторы исключаются, а значит, не подвергаются заданным ограничениям. Используйте этот режим по умолчанию, если только не возникнет потребность в том, чтобы к администраторам применялись те же правила, что и к обычным пользователям.
Определите расширения файлов, которые SRP будет рассматривать как исполняемые типы в узле Designated File Types. Первоначально вы увидите ожидаемые расширения файлов: .exe,.bat,.msi и т. д. К этому списку можно добавлять расширения других типов файлов, которыми предстоит управлять. Но если, к примеру, вы уже создаете правило, блокирующее работу программы Microsoft Excel, включать в список расширение .xls не имеет смысла.
Третий параметр узла Software Restriction Policies — это параметр Trusted Publishers. Данный узел дает возможность управлять характеристиками элементов управления ActiveX. Вы можете предоставить или не предоставлять пользователям право определять издателя того или иного элемента управления ActiveX как надежного. Если такое право получают обычные пользователи, вы в итоге лишаете себя возможности отслеживать, какие издатели элементов ActiveX заслуживают доверия.
Кроме того, параметр Trusted Publishers позволяет определять, должна ли система Windows проверять, не отозваны ли сертификаты и действительны ли отметки времени перед тем, как устанавливать элемент управления ActiveX, подписанный тем или иным пользователем. Если издатели ваших легитимных элементов управления ActiveX добросовестно поддерживают актуальность своих сертификатов, задействовать этот параметр, по-видимому, не стоит.
Типы правил для управления выполнением приложений
Теперь давайте заглянем в самое сердце SRP — а именно рассмотрим правила, регулирующие выполнение реального приложения. В SRP предусмотрено четыре типа правил:
- правила для хеша;
- правила для пути;
- правила сертификата;
- правила для сетевой зоны.
Вероятно, в 99% случаев вы будете использовать в своих целях правила для хеша или правила для пути. Правила сертификата дают возможность санкционировать или ограничивать выполнение в зависимости от того, подписан ли код тем или иным издателем. К сожалению, многие создатели легитимных приложений не подписывают свой код, поэтому сфера применения данного правила ограничена.
Правила для сетевой зоны позволяют администратору контролировать использование файлов Windows Installer; в сущности, речь идет о возможности определения, из какой зоны браузера Internet Explorer должны поступать файлы .msi, которые может выполнять пользователь. Увы, как правило, вредоносные программы не поступают к нам с удобными файлами Windows Installer, поэтому данная функция имеет весьма ограниченное применение. Но если по какой-то причине у вас возникнет потребность ограничить возможность установки файлов .msi, это правило вам пригодится.
Мы еще не касались правил для хеша и правил для пути. Давайте посмотрим, как они работают и как мы можем использовать их.
Правила для хеша
Как уже говорилось, при использовании белых списков блокируется запуск всех исполнимых файлов, кроме тех, которые получают явную санкцию на выполнение. Существует два способа формирования правил, санкционирующих запуск исполнимых файлов. Правило для хеша — это способ идентификации приложения по уникальному хешу, сгенерированному средствами SRP. Первоначально в качестве применяемого по умолчанию алгоритма хеширования специалисты Microsoft использовали алгоритм MD5, но в версии Windows Vista переключились на более новый алгоритм SHA-256. При создании правила хеша в средах Server 2008 или Windows Vista операционная система сохраняет обе версии хеша для обеспечения обратной совместимости.
При использовании правил для хеша администратор получает возможность управлять приложениями, невзирая на все уловки, предпринимаемые пользователями для обхода ограничений. Это значит, что правила для хеша, по-видимому, наиболее полезны в сценариях с черными списками. Представим себе такую ситуацию. Вы хотите, чтобы пользователи не могли запускать игру Solitaire (sol.exe) в среде Windows XP. Вам нужно в редакторе GPE создать новое правило для хеша. Правой кнопкой мыши щелкните на узле Additional Rules, расположенном на правой панели, и в раскрывшемся меню выберите пункт New Hash Rule. В диалоговом окне New Hash Rule нажмите кнопку Browse и выберите элемент C:WindowsSystem32sol.exe. После этого щелкните ОК. Как показано на экране 3, теперь можно для уровня безопасности вызвать настройку Disallowed, чтобы пользователи не могли запускать данное приложение.
Теперь, даже если пользователи перенесут исполнимый файл sol.exe в другое место или дадут ему другое имя, правило для хеша обеспечит соблюдение наложенного вами ограничения. Правила для хеша полезны при использовании с приложениями, которые изменяются не слишком часто; нужно иметь в виду, что, если приложение изменяется вследствие применения обновления или программного исправления, изменяется и значение хеша приложения, так что вам придется вновь формулировать правило для хеша. Отмечу, что при указании исполнимого файла, который следует контролировать, нужно использовать ту версию приложения, которая установлена на целевых системах. Так, если вы хотите ограничить использование игры Solitaire на системах Windows XP SP3, найдите в списке соответствующую версию исполнимого файла, выполняемого на системе Windows XP SP3, и пусть SRP вычисляет хеш на ее основе.
Правила для пути
Правила для пути — самые полезные и мощные из всех четырех типов правил SRP. Используя их, вы можете указать путь к файлам с целью разрешить или запретить их выполнение (или перевести систему в режим Basic User), и все приложения, расположенные по этому адресу, переводятся под управление SRP. Создать правило для пути просто, достаточно в редакторе GPE правой кнопкой мыши щелкнуть на папке Additional Rules и в раскрывшемся меню выбрать пункт New Path Rule, а затем ввести путь к каталогу, где требуется создать правило.
Главное достоинство правил для пути состоит в том, что они могут принимать множество форм. Правило для пути может быть весьма простым, например:
Sol.exe or Sol.* or S*.*
Это правило лишает пользователей возможности выполнения файла sol.exe, исполнимых файлов с именем Sol и любыми файловыми расширениями, а также всех находящихся в папке Designated File Types программ, названия которых начинаются с буквы s. Разумеется, правило для пути может содержать и фактический путь к файлу, например C:Program FilesMicrosoft Office. В этом примере правило будет регулировать использование всех приложений, размещенных внутри папки Microsoft Office, включая дочерние папки. В правилах для пути можно также указывать пути в соответствии с положениями соглашения об именовании UNC. Так, вы можете указать, что выполняться будут только приложения, находящиеся по адресу MyServerApps. Отмечу, что правило для пути MyServerApps разрешается в любое представление этого же пути (например, 10.5.1.1Apps, или P:, где P указывает на MyServerApps).
Наконец — и, возможно, это самый эффективный способ работы с правилами — вы можете создавать правила пути для реестра. Мы не всегда знаем, где именно установлено то или иное приложение. К примеру, по умолчанию программа Yahoo! Messenger устанавливается в каталоге C:Program FilesYahoo!Messenger, но пользователь мог сохранить ее в другом месте. Как создать правило, применимое к приложению вне зависимости от того, в каком каталоге оно установлено? Вот здесь-то нам на помощь и приходят правила пути реестра.
Правило пути реестра — это ссылка на адрес в реестре, который указывает на путь в файловой системе. В нашем примере при установке приложения Messenger это приложение создает в разделе HKEY_LOCAL_MACHINESOFTWAREYahoo Essentials параметр реестра MainDir, который содержит путь к каталогу, где размещается Messenger. Правило пути реестра создается для того, чтобы приложение Yahoo! Messenger не могло запускаться, т. е. с той же целью, с какой создаются другие правила для пути. На экране 4 показано, как будет выглядеть такое правило.
Обратите внимание, что вводить нужно весь путь реестра вплоть до значения, содержащего путь к файлу, на который вы хотите наложить ограничение; при этом путь реестра должен быть заключен в символы процента (%). В реестре это значение отображается как C:Program FilesYahoo!. При оценке правила для пути SRP просматривает реестр в поисках пути к приложению Messenger и управляет всеми приложениями, расположенными на этом пути.
Еще одна замечательная сфера применения правил пути реестра — блокировка выполнения кода, который пользователь загрузил в виде присоединенного файла или с помощью Web-браузера. Пример: вы хотите, чтобы пользователи не выполняли приложения внутри браузера Internet Explorer без предварительного сохранения соответствующего файла. Когда пользователь нажимает кнопку Open в диалоговом окне загрузки, IE использует путь к временному каталогу загрузки в разделе реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoft WindowsCurrentVersionInternet SettingsCachePathsDirectory. Если вы создадите правило пути реестра к данному каталогу и присвоите ему значение Disallowed, ни один из типов приложений, находящихся в папке Designated File Types, не сможет выполняться из этого приглашения Open.
Правила для пути, созданные Microsoft
Когда вы будете впервые создавать новую политику SRP внутри объекта GPO, то заметите, что операционная система Windows автоматически создает правила пути реестра на узле Additional Rules внутри редактора GPE. Эти заранее созданные правила пути реестра определяют все приложения внутри каталогов C:Windows, а также C:Program Files (или по всему маршруту на пути к этим хорошо известным папкам) как не подвергающиеся ограничениям. Думаю, специалисты Microsoft сделали это для того, чтобы администраторы, впервые составляя белый список, не совершали непреднамеренной ошибки и не препятствовали корректному выполнению компонентов операционной системы.
Тем не менее вам все-таки лучше не упускать из виду эти заранее составленные правила, ибо, если вы попытаетесь создать настоящий белый список, то вряд ли захотите дать санкцию на выполнение всех программ, находящихся в каталогах C:Windows и C:Program Files. Если вы решите удалить эти заранее заданные правила, обязательно проведите тщательное тестирование. Более того, если вы хотите изменить их, я рекомендую удалять только правило Program Files и оставить без изменения правило C:Windows; таким образом вы исключите возможность блокировки приложений, играющих ключевую роль в функционировании операционной системы.
Взаимодействие политик SRP
Если вы определяете политики SRP в нескольких объектах GPO, необходимо знать, как они будут взаимодействовать друг с другом. Если говорить об общих параметрах (применяется ли модель белый список или черный список, какие типы файлов используются, каковы настройки надежных издателей и т. д.), важно иметь в виду, что фактически будет применяться та настройка, которая обрабатывается последней в процессе обработки групповой политики на клиентской системе. Однако, в сущности, происходит слияние правил. Ситуация может оказаться весьма запутанной: к примеру, правило для пути и правило для хеша могут войти в противоречие друг с другом. В этом случае в силу вступает более конкретное правило.
Рассмотрим пример. Допустим, у нас имеется правило для хеша, блокирующее запуск файла C:Windows egedit.exe, и правило для пути, санкционирующее выполнение всех программ, размещенных в каталоге C:Windows. Применяться будет правило для хеша: оно более конкретно, ибо указывает на определенный файл. Таким образом, файл regedit.exe будет заблокирован, даже если все остальные файлы каталога C:Windows получат санкцию на выполнение. Главный вывод: старайтесь избегать «наложения» правил при работе с несколькими GPO.
Включите в арсенал SRP
SRP — мощный механизм управления выполнением приложений на системах Windows, не требующий использования дорогостоящих решений от независимых поставщиков. Для реализации этого механизма нужно проделать определенную работу, и он не обеспечивает защиты от неумелого обращения, зато администратор может творчески подойти к делу и подобрать соответствующие правила для пути и даже для хеша, а также правила сертификата, чтобы создать среду, в которой пользователи могут запускать лишь проверенные программы. Я рекомендую всем администраторам, которые стараются искоренить привычку пользователей загружать и запускать непроверенные коды, взять на вооружение политики SRP и попытаться тем самым повысить безопасность работы в своих сетях.
Даррен Мар-Элиа (dmarelia@windowsitpro.com) — редактор Windows IT Pro, технический директор и учредитель компании SDM Software