Недавно одна кредитная организация наняла компанию, занимающуюся вопросами обеспечения безопасности, для имитации попытки взлома компьютеров своей сети. Специалисты компании успешно осуществили взлом компьютеров, для начала "подбросив" несколько USB-устройств на парковках и в "курилках" организации. Каждое устройство содержало исполняемый файл типа «троян». Сотрудники кредитной организации обнаружили большую часть устройств, подключили их к своим рабочим компьютерам и запустили исполняемый файл. Хотя нельзя быть уверенным в том, что ваши сотрудники или партнеры никогда не будут запускать файлы с найденных устройств, можно предотвратить возникновение описанной ситуации с помощью политик ограничения запуска программ Software Restriction Policies (SRP).
Политики SRP находятся в ведении службы Group Policy, которую можно использовать для ограничения запуска приложений на компьютерах с системами Windows Vista, Windows Server 2003 и Windows XP. Можно рассматривать политики SRP как аналог набора правил брандмауэра. В данном случае вы можете создать более общее правило, запрещающее или разрешающее запуск приложений, для которых не создано отдельных правил. Например, можно настроить общее правило, разрешающее запуск любых программ, и при этом отдельным правилом запретить запуск программы «Пасьянс». Или вы можете начать настройку с запрета запуска любых приложений и далее создавать правила SRP, разрешающие запуск конкретных приложений.
Можно создавать различные типы правил SRP, в том числе правило для зоны, правило для пути, правило для сертификата и правило для хеша. После небольшого обзора базовых понятий политик SRP я вкратце расскажу, как создавать правило каждого типа, но основное внимание будет уделено наиболее эффективному типу - правилам для хеша.
Исходные настройки
Вы можете настраивать политики SRP через разделы User или Computer службы Group Policy. Подобная гибкость позволяет применять политики к группам компьютеров или пользователей. Например, можно применить политику SRP, запрещающую пользователям играть в "Сапера" или "Пасьянс", к организационной единице, включающей сотрудников бухгалтерии. С другой стороны, можно применить политику SRP к группе компьютеров в общедоступной лаборатории колледжа, чтобы ограничить набор приложений, которые может устанавливать каждый, кто использует системы в тестовой лаборатории.
Чтобы активировать политики SRP, сначала создайте или отредактируйте объект Group Policy Object (GPO) и перейдите в окно Computer (или User) Configuration->Windows Settings->Security Settings->Software Restriction Policies. После этого щелкните правой кнопкой мыши на узле Restriction Policies и выберите пункт New Software Restriction Policies в контекстном меню.
После того, как вы активируете политики SRP, необходимо будет выбрать используемый уровень безопасности, Unrestricted или Disallowed. По умолчанию включен уровень Unrestricted, который разрешает запуск любых приложений, кроме запрещенных. И наоборот, режим Disallowed запрещает запуск любых приложений, кроме тех, для которых созданы исключения. Имейте в виду, что система Windows Vista предполагает третий уровень безопасности, Basic User, который вынуждает все приложения, кроме отдельно настроенных, работать с уровнем привилегий Basic User. Но так как эта статья посвящена запрету запуска приложений, мы не будем рассматривать уровень Basic User.
При серьезном подходе к ограничению использования неавторизованного программного обеспечения в организации рекомендуется выбирать уровень безопасности Disallowed. Для использования уровня Unrestricted требуется информация о том, какое именно программное обеспечение может быть запущено, что напоминает угадывание номеров лотерейных билетов. Хотя уровень Unrestricted может хорошо работать в безопасном окружении, где руководство просит вас отключить пользователям встроенные в систему Windows игры, его трудно задействовать в каком-либо решении с повышенными требованиями к безопасности. Однако если вы хотите заблокировать небольшое число приложений, не блокируя полностью компьютеры организации, стоит использовать уровень Unrestricted.
Для переключения политик SRP в уровень Disallowed перейдите в узел Software Restriction Policies->Security Levels и дважды щелкните на политике Disallowed. В появившемся окне Disallowed Properties, см. экран 1, просто установите флажок в поле Set as Default. Система Windows выдаст сообщение о том, что выбранный уровень является более безопасным, чем текущий, и некоторые программы могут быть закрыты. Щелкните на кнопке OK.
Рисунок 1: Установка уровня Disallowed в качестве уровня безопасности, используемого по умолчанию
По умолчанию в политиках SRP изначально существуют исключения для всех приложений, размещенных в папках %SystemRoot% и %SystemRoot%\System32. Вы можете просмотреть эти исключения в окне Additional Rules для каждой политики. Эти правила предоставляют операционной системе минимальную функциональность, даже если выбран уровень безопасности Disallowed. Однако такие исключения дают злоумышленнику возможность скопировать исполняемый файл в одну из этих папок. Правила по умолчанию не делают различий между приложениями, например между cmd.exe и rootkit.exe, они лишь разрешают выполнение всех программ, размещенных в данных папках. Разрешения NTFS предоставляют некоторую защиту, не давая пользователям скопировать посторонние приложения в эти папки и запустить их. Но для того, чтобы по-настоящему защитить систему, необходимо заменить эти общие правила более жесткими.
Имейте в виду, что вы можете использовать политики SRP на компьютерах, которые не входят в рамки Active Directory (AD) (например ноутбуки), создав шаблон безопасности на основе компьютера использующего SRP и применив этот шаблон к локальной политике. Необходимо убедиться в том, что шаблон позволяет запускать утилиту Secedit, чтобы вы могли сделать отмену изменений или при необходимости обновить политику SRP.
Настройка общих политик
В узле Software Restriction Policies можно настроить следующие общие политики, которые определяют, каким образом система Windows применяет политики SRP: принуждение, назначенные типы файлов и доверенные издатели. Давайте рассмотрим каждый тип общих политик.
Принуждение. Принудительная политика используется для того, чтобы политики SRP применялись не только к исполняемым файлам типа «.exe», «.vbs» и всем остальным файлам, прописанным как исполняемые политики назначенных типов файлов, но и к библиотекам «.dll». Диалоговое окно Enforcement Properties, показанное на экране 2, позволяет применять политику SRP и к членам группы локальных администраторов.
Рисунок 2: Настройка политики принуждения для SRP
Для усиления безопасности необходимо включить в политику принуждения все типы программных файлов и применить ее ко всем пользователям. Однако создание отдельных правил для тысяч файлов «.dll» в стандартной комплектации Windows может потребовать нескольких недель работы. За исключением случаев, когда вам требуется максимально закрыть систему, более практичным и при этом достаточно надежным решением является использование политики принуждения без указания библиотек.
Имейте в виду, что в политику принуждения необходимо включить локальных администраторов. Если на компьютере требуется запустить приложение, не разрешенное в списках политик SRP, администратор может временно переместить систему в организационную единицу, на которую не распространяются данные политики.
Назначенные типы файлов. Политика назначенных типов файлов представляет собой список всех расширений - помимо стандартных расширений «.exe», «.dll» и «.vbs» - которые система Windows рассматривает как исполняемый код. На экране 3 изображено окно Designated File Types Properties. Если ваша организация использует тип файлов, не указанный в этом списке, например файлы Perl, вы можете добавить тип файла из этого диалогового окна.
Рисунок 3: Назначение исполняемых типов файлов
Доверенные издатели
Политика доверенных издателей используется для того, чтобы не дать пользователям добавить на свои системы новых доверенных издателей. Например, когда пользователи пытаются загрузить приложение с web-сайта компании Adobe, система спрашивает, хотят ли они сделать это приложение доверенным. Настройки политики определяют, кто может принимать решение о том, каким издателям доверять: конечные пользователи, локальные администраторы или корпоративные администраторы. Для обеспечения максимальной безопасности назначать доверенных издателей разрешается только корпоративным администраторам (как это сделать, показано на экране 4). Политика доверенных издателей также позволяет вам инициировать проверку списка отмененных сертификатов (CRL), чтобы выявить подлинность любого сертификата.
Рисунок 4: Предоставление прав на назначение доверенных издателей
Запрет или разрешение приложений
Теперь, когда мы познакомились с основными политиками SRP, давайте рассмотрим 4 типа правил, которые можно использовать для разрешения или запрета исполнения приложений: для зоны, для пути, для сертификата и для хеша.
Правила для зоны. Правила для зон Internet используются для ограничения или разрешения исполнения загруженных файлов «.msi» (для Windows Installer), в зависимости от зоны, из которой получен файл. Так как это правило применяется только к файлам «.msi», загруженным пользователями из Internet, этот тип политик SRP используется реже, чем остальные.
Для создания правила для зоны Internet щелкните правой кнопкой мыши на узле Additional Rules и выберите в контекстном меню пункт New Internet Zone Rule. Выберите Зону Internet и установите Уровень Безопасности в значение Unrestricted или Disallowed. В правиле для зоны Internet, настройка которого показана на экране 5, исполнение файлов «.msi», полученных из зоны Restricted sites, запрещено (уровень Disallowed).
Рисунок 5: Установка ограничений на зоны Internet
Правила для пути
Правила для пути позволяют указать папку или полный путь к приложению, которое может или не может быть выполнено. Недостатком правила для пути является то, что оно опирается исключительно на путь или на имя файла. Например, на экране 6 изображено правило для пути, которое разрешает запуск службы Outlook Express. Злоумышленники могут просто переименовать файл, содержащий вредоносный код, в «msimn.exe» и скопировать его в папку C:\Program Files\Outlook Express\msimn.exe. Так как задействуется правило для пути, файл, содержащий вредоносный код, считается разрешенным и может быть выполнен. Имейте в виду, что при настройке нескольких правил для пути приоритет будет иметь более «узкое» правило. Например, правило для пути C:\directory\application.exe будет иметь приоритет перед правилом для пути C:\directory\.
Рисунок 6: Настройка правила для пути
Правила для сертификата
Правила для сертификата основаны на сертификатах, подписанных издателями. Основная проблема здесь заключается в том, что вам необходимо указать подписанный издателем сертификат. Кроме того, вы не можете использовать правило для сертификата, если требуется по-разному настроить политики для нескольких приложений одного и того же издателя. Например, вы не можете использовать данное правило, чтобы запретить сотрудникам играть в «Пасьянс», так как все игры, поставляемые вместе с Windows, подписаны тем же издателем, что и ключевые компоненты операционной системы, такие как служба IE.
Чтобы создать правило для сертификата, щелкните правой кнопкой мыши на узле Additional Rules и выберите пункт New Certificate Rule. Щелкните на кнопке Browse, укажите сертификат издателя (файл типа «.crt» или «.cer»), установите уровень безопасности в значение Unrestricted (или Disallowed) и щелкните на кнопке OK.
Правила для хеша. Правила для хеша я считаю лучшим типом политик SRP. Они не требуют от вас указания сертификата издателя, не берут за основу правила для зон Internet, и, так как для идентификации исполнительного файла они используют вычисленную контрольную сумму (хеш), злоумышленник не может запустить вредоносный код под новым именем в обход этого правила.
Правила для хеша используют контрольную сумму, рассчитанную для определенного файла. Например, блокирующее правило, использующее хеш программы notepad.exe из системы Windows 2003, не будет влиять на работу приложения «notepad.exe», поставляемого с системой XP Professional. А правило, использующее хеш программы notepad.exe из системы XP, не заблокирует приложение «notepad.exe», входящее в состав системы Vista. Хотя приложения, поставляемые с операционными системами, генерируют разный хеш в зависимости от версии системы, другие приложения - такие как Microsoft Word или Mozilla Firefox - генерируют одинаковую контрольную сумму вне зависимости от того, на какую систему они установлены:Vista, Windows 2003 или XP.
Для вычисления хеша необходим доступ к бинарному исполняемому файлу на том компьютере, где вы настраиваете объект GPO. Если вы создаете объект GPO на контроллере домена (DC), вы можете добавить сетевой диск на моделируемую систему, используя общую папку администратора, такую как \\XP-REF-SYS\C$. После этого выбор исполняемого файла сводится к его поиску на сетевом диске.
При конфликте правил SRP правила для хеша имеют приоритет перед всеми другими. Также имейте в виду, что файлы, которые вы переименовываете или перемещаете в другое место, сохраняют свои контрольные суммы. Поэтому, если вы используете правило для блокирования файла, например исполняемого модуля вируса, оно сработает даже в случае, если кто-то изменил имя вируса.
Основной недостаток использования правил для хеша с политикой Disallowed заключается в том, что формирование исходного набора разрешенных приложений требует массы времени. Также нельзя забывать про необходимость обновления контрольной суммы каждый раз, когда изменяется версия приложения или устанавливается новое программное обеспечение. Для запуска обновленного приложения необходимо создать новое правило. Имейте в виду, что лучше создавать новые правила для обновленных приложений, чем менять под них старые, так как в вашей сети одновременно могут сосуществовать различные версии одного продукта. Со временем вы удалите правила для старых версий приложений.
Для создания правил для хеша, щелкните правой кнопкой мыши на узле Additional Rules службы Group Policy и выберите пункт Hash Rule. В появившемся окне New Hash Rule щелкните на кнопке Browse и выберите приложение, для которого хотите создать правило. При выборе приложения система Windows автоматически вычислит контрольную сумму файла, как показано на экране 7, и отобразит свойства файла в окне File information .
Рисунок 7: Создание правила для хеша
Настройка и отладка политик SRP
При создании политик SRP необходимо завести временную организационную единицу в службе AD и приписать к данной единице создаваемый объект GPO. После этого вы можете поместить туда тестовые учетные записи пользователей и компьютеров на время, необходимое вам для отладки политик SRP. После тестирования политик объекта GP можно прикрепить его к организационной единице, в которую входят реальные учетные записи пользователей и компьютеров. Убедитесь, что вы тщательно протестировали политики SRP - в лаборатории IT отдела и с пробной группой пользователей - прежде чем внедрять их в вашу организацию. Политики SRP имеют сложную структуру, и вы вряд ли сможете безошибочно настроить их с первого раза.
Если вам необходимо отладить ошибку в настройках политик SRP, можно просмотреть события, вызванные этими политиками (события под номером 865, 866 и 867), в локальном журнале компьютера. Также вы можете активировать более сложное отслеживание политик SRP, добавив строку LogFileName в следующий подраздел реестра: HKEY_LOCAL_MACHINE\SOFTWARE\ Policies\Microsoft\Windows\Safer\ CodeIdentifiers. Строка LogFileName содержит путь к каталогу, в котором будет храниться файл журнала.
Следуйте правилам
Используя политики SRP, вы сможете запретить запуск в вашей системе нежелательных приложений - от отвлекающих игр до вирусов. Любая система (и Vista, и Windows 2003, и XP) предоставляет множество возможностей, которые позволят создать идеальные политики для вашей организации. Хотя реализация политики SRP исключительно на правилах для хеша требует большой работы, эти правила являются наиболее эффективными при защите компьютеров. Если бы кредитная организация из нашего примера реализовала политику SRP, согласно рекомендациям, приведенным в этой статье, внедренный «троян» никогда бы не был запущен, так как он не входил бы в список разрешенных приложений, организованный с помощью правил для хеша.